एजंटची एंड-टू-एंड चाचणी करा (API)
AI एजंटवर पुनरावृत्ती करणे म्हणजे त्याच्या prompt, त्याच्या टूल्स, आणि तो अपवादात्मक परिस्थिती कशा हाताळतो यावर पुनरावृत्ती करणे. सिम्युलेशन्स API तुम्ही दिलेल्या परिस्थितीच्या prompt वापरून एजंटविरुद्ध वास्तविक कॉल चालवते. एजंट लक्ष्य केल्यास बॉट-टू-बॉट रन तयार होते; फोन नंबर लक्ष्य केल्यास SIP लूपबॅक रन तयार होते. प्रत्येक रनमधून ट्रान्स्क्रिप्ट, मूल्यांकन आणि बिलिंगसह वास्तविक कॉल लॉग तयार होतो, त्यामुळे एजंट नेमका कसा वागतो आणि त्याची किंमत किती आहे हे तुम्हाला दिसते.
यासाठी वापरा:
- प्रत्येक prompt संपादनानंतर डिप्लॉयपूर्व स्मोक चाचण्या
- CI मध्ये जोडलेले रिग्रेशन सूट्स (
test-call.completedवेबहुक → स्कोअर कमी झाल्यास बिल्ड अयशस्वी करा) - समकालिकता मर्यादांची ताण-चाचणी
एकदाच: एकच रन
curl -X POST https://api.thunderphone.com/v1/simulations \
-H "Authorization: Bearer sk_live_YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"target_type": "agent",
"target_id": 12,
"direction": "outbound",
"scenario_prompt": "You are a polite caller asking about refund policy for order 12345.",
"consent_to_charge": true
}'
फील्ड्स:
| फील्ड | प्रकार | आवश्यक | वर्णन |
|---|---|---|---|
target_type | स्ट्रिंग | होय | agent किंवा phone_number |
target_id | पूर्णांक | होय | एजंट आयडी (किंवा फोन नंबर आयडी) |
direction | स्ट्रिंग | नाही | outbound (डीफॉल्ट; चाचणी कॉलर कॉल करतो) किंवा inbound (चाचणी कॉलर उत्तर देतो) |
scenario_prompt | स्ट्रिंग | नाही | चाचणी बॉट काय म्हणतो हे नियंत्रित करते |
language / primary_language | स्ट्रिंग | नाही | चाचणी कॉलरसाठी भाषा; असमर्थित कोड नाकारले जातात |
simulator_product | स्ट्रिंग | नाही | testing (डीफॉल्ट) किंवा उबदार-ट्रान्सफर सल्ला चाचण्यांसारख्या अधिक मानवीसदृश सिम्युलेटेड कॉलरसाठी spark |
consent_to_charge | बूलियन | होय | true असणे आवश्यक आहे. अंदाजामध्ये निवडलेल्या एजंटचे आणि सिम्युलेटेड कॉलरचे, तसेच कोणत्याही टेलिफोनी लेगचे बिल आकारले जाते |
target_number | स्ट्रिंग | नाही | रिमोट बाजूसाठी E.164 ओव्हरराइड; अन्यथा प्लॅटफॉर्मचा चाचणी नंबर वापरला जातो |
mode केवळ-वाचनीय आहे आणि target_type वरून निर्धारित केले जाते: agent मुळे
mode="bot" तयार होते, तर phone_number मुळे mode="sip" तयार होते.
प्रतिसाद status="queued" मधील सिम्युलेशन रन ऑब्जेक्ट
असतो. status हे completed किंवा
failed होईपर्यंत पोल करा; call_id सेट झाल्यावर
GET /v1/calls/{call_id}/transcript द्वारे ट्रान्स्क्रिप्ट लोड करा.
बॅचेस: समांतर परिस्थिती
N परिस्थिती एकाच वेळी चालवा — प्रत्येक ज्ञात अपवादात्मक परिस्थितीवर समांतरपणे चाचणी करणाऱ्या रिग्रेशन सूट्ससाठी उपयुक्त:
curl -X POST https://api.thunderphone.com/v1/simulations/batches \
-H "Authorization: Bearer sk_live_YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"target_type": "agent",
"target_id": 12,
"direction": "outbound",
"run_count": 5,
"stagger_seconds": 2,
"scenario_prompts": [
"Ask about refund policy.",
"Ask for hours of operation.",
"Complain about a delayed shipment.",
"Ask to speak with a human.",
"Ask an unrelated trivia question."
],
"consent_to_charge": true
}'
प्रतिसादात चाइल्ड रन आयडींची run_ids सूची असते. बॅचची
स्थिती मिळवा:
curl https://api.thunderphone.com/v1/simulations/batches/{batch_id} \
-H "Authorization: Bearer sk_live_YOUR_API_KEY"
run_count ची कमाल मर्यादा 20 आहे; एजंटवर जास्त भार पडू नये म्हणून stagger_seconds स्पॉनमध्ये
अंतर ठेवते (0–60 से).
ते CI मध्ये जोडा
Simulations पेजवर
(/dashboard/simulations) रिलीज गेट संच तयार करा — एजंट निवडा, परिस्थिती स्वतः जोडा किंवा एजंटच्या
prompt वरून त्यांचे मसुदे तयार करण्यासाठी AI सह परिस्थिती तयार करा वर क्लिक करा
(पर्यायी एज-केस तपासणीसह), आणि त्यांना एका संचामध्ये गटबद्ध करा.
संच त्यातील परिस्थिती आणि एजंट, तसेच किमान उत्तीर्ण दर आणि
पर्यायी शून्य-गंभीर-अपयश नियम निश्चित करतो. उत्तीर्ण रन स्वीकारलेली
बेसलाइन बनतात; नंतरचे उत्तीर्ण→अयशस्वी संक्रमण रीग्रेशन म्हणून परत केले जाते.
CI मध्ये संस्थेची API की वापरा.
ही स्क्रिप्ट संच ट्रिगर करते, ग्रेडिंग आणि तुलना पूर्ण होईपर्यंत पोल करते,
आणि निकाल pass नसल्यास शून्येतर कोडसह बाहेर पडते:
#!/usr/bin/env bash
set -euo pipefail
: "${THUNDERPHONE_API_KEY:?Set THUNDERPHONE_API_KEY}"
: "${THUNDERPHONE_ORG_ID:?Set THUNDERPHONE_ORG_ID}"
: "${THUNDERPHONE_SUITE_ID:?Set THUNDERPHONE_SUITE_ID}"
base="https://api.thunderphone.com/v1/orgs/${THUNDERPHONE_ORG_ID}/suites/${THUNDERPHONE_SUITE_ID}"
auth="Authorization: Bearer ${THUNDERPHONE_API_KEY}"
run_id="$(curl --fail --silent --show-error -X POST "${base}/run" \
-H "$auth" -H "Content-Type: application/json" -d '{}' | jq -r '.id')"
deadline=$((SECONDS + 1800))
while (( SECONDS < deadline )); do
result="$(curl --fail --silent --show-error \
"${base}/runs/${run_id}" -H "$auth")"
status="$(jq -r '.status' <<<"$result")"
if [[ "$status" == "completed" ]]; then
jq . <<<"$result"
[[ "$(jq -r '.verdict' <<<"$result")" == "pass" ]]
exit
fi
sleep 10
done
echo "ThunderPhone suite timed out" >&2
exit 1
POST /v1/orgs/{org_id}/suites/{suite_id}/run रन आयडीसह 202 परत करते.
GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id} status,
verdict, pass_rate, critical_failure_count, आणि बेसलाइनची
regressions सूची परत करते. दोन्ही एंडपॉइंट URL मधील संस्थेला
API कीच्या संस्थेशी बांधतात.
पॅटर्न
प्रत्येक prompt साठी रीग्रेशन संच
{name, scenario_prompt, expected_outcome} ट्युपल्सची JSON फाइल ठेवा.
प्रत्येक prompt बदलानंतर, संपूर्ण संच बॅच म्हणून चालवा; प्रतिलिपी आणि
ग्रेडची मागील रनशी तुलना करा.
प्रत्येक रिलीजसाठी स्मोक चाचणी
प्रत्येक डिप्लॉयमेंटनंतर चालवायच्या पाच यशस्वी-मार्गातील परिस्थितींची एकच बॅच.
लेटन्सी-संवेदनशील असल्याने, stagger_seconds: 0 ठेवा.
लेटन्सी बेंचमार्किंग
वेगवेगळ्या उत्पादन स्तरांवर (spark,
bolt, storm-base) एकसारख्या परिस्थिती चालवा. प्रत्येक परिणामी कॉल लॉगमधील
call.graded स्कोअर आणि duration_seconds यांची तुलना करा.
पुढील पायऱ्या
प्रत्येक क्वेरी पॅरामीटर, स्थिती कोड आणि बॅच संरचना.
कालांतराने गुणवत्तेचा मागोवा घेण्यासाठी प्रत्येक चाचणी रनला स्वयंचलित स्कोअर द्या.
मानवी पुनरावलोकनासाठी विशिष्ट चाचण्या चिन्हांकित करा.
परिणाम तुमच्या CI / Slack / PagerDuty मध्ये स्ट्रीम करा.