ThunderPhone 2.0 ਹੁਣ ਲਾਈਵ ਹੈ।ਸੈਲਫ਼-ਸਰਵਿਸ—2¢/ਮਿੰਟ ਤੋਂਐਲਾਨ ਪੜ੍ਹੋ

Developer cookbook

ਏਜੰਟ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਟੈਸਟ ਕਰੋ (API)

ThunderPhone 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 ਨਾਲ ਜੋੜੋ

ਸਿਮੂਲੇਸ਼ਨਜ਼ ਪੇਜ (/dashboard/simulations) ਉੱਤੇ ਇੱਕ ਰਿਲੀਜ਼ ਗੇਟ ਸੂਟ ਬਣਾਓ — ਏਜੰਟ ਚੁਣੋ, ਹੱਥੋਂ ਸਥਿਤੀਆਂ ਸ਼ਾਮਲ ਕਰੋ ਜਾਂ ਏਜੰਟ ਦੇ prompt ਤੋਂ ਉਹਨਾਂ ਦਾ ਖਾਕਾ ਤਿਆਰ ਕਰਨ ਲਈ AI ਨਾਲ ਸਥਿਤੀਆਂ ਬਣਾਓ 'ਤੇ ਕਲਿੱਕ ਕਰੋ (ਵਿਕਲਪਿਕ ਐਜ-ਕੇਸ ਪਾਸ ਨਾਲ), ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸੂਟ ਵਿੱਚ ਗਰੁੱਪ ਕਰੋ। ਇੱਕ ਸੂਟ ਆਪਣੀਆਂ ਸਥਿਤੀਆਂ ਅਤੇ ਏਜੰਟ ਦੇ ਨਾਲ ਘੱਟੋ-ਘੱਟ ਪਾਸ ਦਰ ਅਤੇ ਵਿਕਲਪਿਕ ਜ਼ੀਰੋ-ਕ੍ਰਿਟੀਕਲ-ਫੇਲਿਅਰ ਨਿਯਮ ਨੂੰ ਸਥਿਰ ਕਰਦਾ ਹੈ। ਪਾਸ ਹੋਣ ਵਾਲੀਆਂ ਰਨਾਂ ਸਵੀਕਾਰਿਆ ਬੇਸਲਾਈਨ ਬਣ ਜਾਂਦੀਆਂ ਹਨ; ਬਾਅਦ ਵਿੱਚ pass→fail ਤਬਦੀਲੀਆਂ ਨੂੰ ਰਿਗ੍ਰੈਸ਼ਨਾਂ ਵਜੋਂ ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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 ਕੁੰਜੀ ਦੇ ਸੰਗਠਨ ਨਾਲ ਬੰਨ੍ਹਦੇ ਹਨ।

ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਅਨੁਸਾਰ ਸੂਟ ਚਲਾਓ

ਏਜੰਟ ਦਾ ਸਿਮੂਲੇਟ ਟੈਬ ਖੋਲ੍ਹੋ, ਰਿਲੀਜ਼ ਗੇਟ ਸੂਟਾਂ ਚੁਣੋ, ਅਤੇ ਇੱਕ ਸੂਟ ਬਣਾਓ ਜਾਂ ਸੰਪਾਦਿਤ ਕਰੋ। ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਅਨੁਸਾਰ ਚਲਾਓ ਚਾਲੂ ਕਰੋ, ਆਵ੍ਰਿਤੀ ਅਤੇ ਸਮਾਂ ਖੇਤਰ ਚੁਣੋ, ਫਿਰ ਦਿਖਾਏ ਅਨੁਸਾਰ ਘੰਟੇ ਤੋਂ ਬਾਅਦ ਮਿੰਟ, ਸਥਾਨਕ ਸਮਾਂ, ਜਾਂ ਦਿਨ ਸੈੱਟ ਕਰੋ। ਸੂਟ ਸੁਰੱਖਿਅਤ ਕਰੋ ਚੁਣੋ। ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਅਨੁਸਾਰ ਚਲਾਓ ਨੂੰ ਅਣਚੁਣਨ ਨਾਲ ਡੈਸ਼ਬੋਰਡ ਸ਼ਡਿਊਲ ਹਟ ਜਾਂਦਾ ਹੈ।

API ਰਾਹੀਂ

ਸ਼ਡਿਊਲ ਜੋੜਨ ਜਾਂ ਬਦਲਣ ਲਈ ਸੂਟ ਨੂੰ PATCH ਕਰੋ। ਪੂਰੇ ਸੂਟ ਆਬਜੈਕਟ ਅਤੇ ਐਂਡਪੁਆਇੰਟਾਂ ਲਈ ਸੂਟਾਂ (ਰਿਲੀਜ਼ ਗੇਟਾਂ) ਵੇਖੋ।

curl -X PATCH https://api.thunderphone.com/v1/suites/{suite_id} \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "schedule": {
      "enabled": true,
      "frequency": "daily",
      "timezone": "America/Chicago",
      "hour": 6,
      "minute": 30
    }
  }'

frequency hourly, daily, ਜਾਂ weekly ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ IANA ਸਮਾਂ ਖੇਤਰ ਵਰਤੋ। ਘੰਟਾਵਾਰ ਸ਼ਡਿਊਲਾਂ ਵਿੱਚ minute ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ; ਰੋਜ਼ਾਨਾ ਸ਼ਡਿਊਲਾਂ ਵਿੱਚ hour ਅਤੇ minute; ਹਫ਼ਤਾਵਾਰ ਸ਼ਡਿਊਲਾਂ ਵਿੱਚ weekday ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਸੋਮਵਾਰ 0 ਅਤੇ ਐਤਵਾਰ 6 ਹੈ। ਸੂਟ ਜਵਾਬ ਵਿੱਚ next_run_at ਅਤੇ last_run_at ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ।

ਸਮੇਂ ਚੁਣੇ ਹੋਏ ਸਮਾਂ ਖੇਤਰ ਦੀਆਂ ਡੇਲਾਈਟ-ਸੇਵਿੰਗ ਤਬਦੀਲੀਆਂ ਅਨੁਸਾਰ ਹੁੰਦੇ ਹਨ। ਨਿਰਧਾਰਿਤ ਰਨਾਂ ਸੂਟ ਦੇ ਰਨ ਇਤਿਹਾਸ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਇਸਦੇ ਮੌਜੂਦਾ ਏਜੰਟ, ਸਥਿਤੀਆਂ, ਮਾਪਦੰਡਾਂ, ਅਤੇ ਸਵੀਕਾਰਿਆ ਬੇਸਲਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਹਰ ਬਣਾਈ ਗਈ ਟੈਸਟ ਕਾਲ test-call.completed ਜਾਰੀ ਕਰਦੀ ਹੈ; ਸੂਟ-ਪੱਧਰ ਦਾ ਕੋਈ ਪੂਰਨਤਾ ਵੈੱਬਹੁੱਕ ਨਹੀਂ ਹੈ। ਨਿਰਧਾਰਿਤ ਕਾਲਾਂ ਦਾ ਬਿਲ ਮੈਨੁਅਲ ਸੂਟ ਰਨਾਂ ਵਾਲੀ ਹੀ ਸਿਮੂਲੇਸ਼ਨ ਦਰ ਅਨੁਸਾਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੂਟ ਰਨ ਉੱਤੇ trigger: "schedule" ਦਰਜ ਹੁੰਦਾ ਹੈ।

ਸਮਾਂ ਬਦਲੇ ਬਿਨਾਂ ਸ਼ਡਿਊਲ ਰੋਕਣ ਲਈ, ਪੂਰੇ ਮੌਜੂਦਾ ਸ਼ਡਿਊਲ ਆਬਜੈਕਟ ਨੂੰ "enabled": false ਨਾਲ PATCH ਕਰੋ। frequency ਲਾਜ਼ਮੀ ਹੈ; ਛੱਡੇ ਗਏ ਸਮਾਂ ਖੇਤਰ ਅਤੇ ਸਮੇਂ ਵਾਲੇ ਫੀਲਡ ਆਪਣੇ ਡਿਫਾਲਟਾਂ 'ਤੇ ਰੀਸੈੱਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਮੌਜੂਦਾ ਮੁੱਲ ਸ਼ਾਮਲ ਕਰੋ। ਸ਼ਡਿਊਲ ਹਟਾਉਣ ਲਈ "schedule": null ਭੇਜੋ।

ਪੈਟਰਨ

ਹਰ prompt ਲਈ ਰਿਗ੍ਰੈਸ਼ਨ ਕੋਰਪਸ

{name, scenario_prompt, expected_outcome} ਟਿਊਪਲਾਂ ਦੀ ਇੱਕ JSON ਫ਼ਾਈਲ ਬਣਾਈ ਰੱਖੋ। ਹਰ prompt ਤਬਦੀਲੀ 'ਤੇ, ਪੂਰੇ ਸੈੱਟ ਨੂੰ ਬੈਚ ਵਜੋਂ ਚਲਾਓ; ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਗ੍ਰੇਡਾਂ ਦੀ ਪਿਛਲੀ ਰਨ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

ਹਰ ਰਿਲੀਜ਼ ਲਈ ਸਮੋਕ ਟੈਸਟ

ਪੰਜ ਸਫਲ-ਪਾਥ ਸਥਿਤੀਆਂ ਦਾ ਇੱਕ ਸਿੰਗਲ ਬੈਚ ਜੋ ਤੁਸੀਂ ਹਰ ਡਿਪਲੋਇ ਤੋਂ ਬਾਅਦ ਚਲਾਉਂਦੇ ਹੋ। ਇਹ ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ, ਇਸ ਲਈ stagger_seconds: 0 ਰੱਖੋ।

ਲੇਟੈਂਸੀ ਬੈਂਚਮਾਰਕਿੰਗ

ਵੱਖ-ਵੱਖ ਉਤਪਾਦ ਟੀਅਰਾਂ (spark, bolt, storm-base) ਦੇ ਵਿਰੁੱਧ ਇੱਕੋ ਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਚਲਾਓ। ਹਰ ਨਤੀਜਾ ਕਾਲ ਲੌਗ ਤੋਂ call.graded ਸਕੋਰਾਂ ਅਤੇ duration_seconds ਦੀ ਤੁਲਨਾ ਕਰੋ।


ਅਗਲੇ ਕਦਮ