Tester un agent vocal IA : prouver que l’appel a produit le résultat attendu

Les tests d’agents vocaux IA ne devraient pas passer une autorisation car la transcription semble plausible. Un test défendable prouve cinq choses distinctes : l’appel s’est connecté, l’agent a répondu dans une limite spécifique au flux de travail, l’interruption a effectivement arrêté l’audio de l’assistant, chaque outil d’effet secondaire a atteint un résultat connu, et le résultat demandé par l’appelant existe en dehors de la conversation. Cette distinction est importante car les artefacts habituels répondent à des questions plus précises. Un enregistrement prouve que l’audio existait. Une transcription prouve que la reconnaissance vocale produisait du texte. Une grille d’évaluation du LLM estime si ce texte remplit un critère. Un état de la téléphonie terminale prouve que l’appel a été terminé. Aucun de ces faits ne prouve à lui seul qu’un rendez vous a été pris, qu’une annulation a été appliquée ou qu’un transfert a atteint sa destination. La norme pratique consiste à garder le simulateur et l’évaluateur de transcription, puis d’ajouter un petit reçu d’appel déterministe à côté. Une transcription fluide n’est qu’une couche de preuve La simulation vocale est utile. Le Documentation des tests vocaux actuel de Vapi décrit un véritable appel téléphonique entre l’agent cible et un agent de test, suivi d’un enregistrement, d’une transcription et d’une évaluation du LLM selon une grille d’évaluation. Cela exerce bien plus le chemin qu’un test de consigne uniquement textuel. Cela laisse encore des espaces visibles. Une transcription peut omettre la frontière exacte entre la fin de l’appelant et le début de la lecture audio. Il peut se lire clairement après que l’appelant ait par dessus l’assistant. Il peut contenir la confirmation confiante d’un outil même lorsque le système distant est en panne. La complétion téléphonique a un sens tout aussi étroit. Twilio documente queued , ringing , in progress , completed , busy , failed , no answer et canceled d’appel. Son Référence de ressources d’appel avertit également que completed signifie qu’une connexion a été établie et que l’audio a été transféré. Une personne, un IVR ou un message vocal ont peut être répondu. « Complété » est donc une preuve de transport, et non un verdict commercial. Utilisez cinq étapes à la place : Gate Preuves minimales Un échec qu’il expose Accessibilité Identification d’appel corrélée plus statut connecté ou in progress Files d’attente, pas de réponse, destination invalide Chronométrage des tours de parole L’audio utilisateur s’arrêtait à t1 ; Assistant Audio a commencé à t2 Réponse lente dissimulée par une transcription cohérente Interruption interruption utilisateur à t3 ; Assistant Audio est passé par t4 L’agent continue de parler par dessus l’appelant Effet outil ID d’opération stable et reçu de destination Temps mort suivi d’une tentative à l’aveugle non sécurisée Conséquences Contrôle indépendant du résultat promis Fin d’appel normale sans réservation, transfert ou annulation Ne combinez pas tout cela en un seul score au début. Une moyenne pondérée peut permettre à un excellent transcription de masquer un résultat manquant. Gardez la couche défaillante visible. Mesurez les limites audio, pas seulement la latence du modèle L’intervalle utile de première réponse commence lorsque l’audio de l’appelant est considéré comme terminé et se termine lorsque l’audio assistant commence réellement à jouer : Ce n’est pas la même chose que le modèle de temps jusqu’au premier jeton. Le terminaison de la parole, la transcription, l’inférence de modèles, la synthèse, le tampon et le transport téléphonique font tous partie de l’expérience de l’appelant. Mesurer un seul stade interne peut donner un effet de lente à un appel sain. L’interruption nécessite une autre observation jumelée : Le Documentation des événements serveur de Vapi expose des mises à jour de statut distinctes, des mises à jour vocales, des user interrupted , des appels d’outils et des événements de fin de service. Il note que l’interruption peut être associée à des preuves d’arrêt de la parole. D’autres fournisseurs utilisent des noms différents, mais le contrat est portable : conserver un identifiant d’appel, désactiver l’ID lorsque cela est possible, horodatages monotones, type d’événement et un petit ensemble de champs non liés au contenu. Il n’existe pas de valeur de bien universelle pour l’un ou l’autre intervalle. Le dispositif exécutable utilisé pour cet article met maxFirstResponseMs à 1200 et maxInterruptStopMs à 300, donc la règle de décision est inspectable. Ce sont des exemples de valeurs politiques, pas des normes industrielles. Calibrez avec les chemins réseau réels, les langues, les styles de parole, les besoins d’accessibilité et le coût d’une fausse défaillance. Un test de libération doit également préserver l’incertitude. Si le mode user speech stop manque, ne calculez pas la latence à partir d’un horodatage de transcription. Si l’événement d’interruption existe mais que l’arrêt assistant n’existe pas, retournez barge in failed ou insufficient evidence selon le contrat de recouvrement. Ne fabriquez jamais un intervalle sain à partir d’événements incomplets. Rejouez l’ordre de priorité des échecs avant les appels réels L’artefact compagnon contient huit flux d’appels sans contenu. Chaque événement a un horodatage relatif et seulement les champs nécessaires à la classification : Exécutez le avec : La rencontre exécutée a produit la parité exacte attendue sur huit verdicts : La priorité est importante. Vérifiez la joignabilité avant le timing car un appel non répondu ne peut pas avoir de réponse initiale significative. Vérifiez le timing et l’interruption avant les effets de l’outil car un appelant a peut être déjà subi une interaction cassée. Réconciliez l’effet de l’outil avant d’évaluer la complétion terminale, car réessayer un effet secondaire incertain peut dupliquer le travail. Exigez que le résultat soit le dernier car c’est la revendication la plus forte. Cet ordre est une règle opérationnelle, pas un classement de sévérité. Une annulation ratée peut avoir plus d’impact qu’un son lent. Acheminez la sévérité du flux de travail et la conséquence utilisateur après que la couche de preuves soit connue. Distinguez le reçu d’effet de l’outil du reçu de résultat Un agent vocal utilise souvent un outil de planification, de paiement, de billetterie ou de transfert. Le résultat de l’outil du modèle n’est pas nécessairement l’état durable de la destination. Attribuez à chaque tentative d’effet secondaire un ID d’opération stable. Conservez l’action demandée, la classe de destination, le numéro de tentative, la classe de réponse et une vérification d’effet sans contenu. Si le transport expire après la soumission, rapprochez cet ID d’opération avant de réessayer. Une seconde demande avec une nouvelle identité peut entraîner un doublon de rendez vous ou une annulation. Puis vérifiez indépendamment le résultat promis par l’appelant. Un effet d’outil peut être réel alors que le résultat utilisateur est toujours incorrect : un rendez vous existe sous le mauvais compte, un transfert est connecté à un IVR au lieu d’un opérateur, ou une annulation a modifié un élément alors que le bundle demandé reste actif. Le false complete de l’équipement est délibérément gênant. Il dispose d’un appel connecté, d’une première réponse de 600 ms, d’un reçu d’effet d’outil vérifié, et d’un statut d’appel complété. Il échoue quand même parce que outcome.verified est absent. C’est exactement le cas où une porte uniquement basée sur la transcription est susceptible de manquer. Un évaluateur LLM reste utile pour des qualités difficiles à encoder de manière déterministe : que l’agent ait reconnu sa frustration, expliqué clairement une politique ou suivi un style d’interaction. Conservez son verdict avec la couche d’évaluation des relevés de notes. Ne laissez pas cela écraser la disponibilité, les horodatages, les reçus de destination ou l’état externe. Conservez le reçu minimal respectueux de la vie privée Le classificateur n’a pas besoin d’audio ou de transcription de texte de l’appelant. Un reçu minimal peut contenir des identifiants d’appel et de tournure pseudonymes, des horodatages relatifs, des types d’événements, l’état du terminal, la version de la politique hachée, l’identifiant d’opération, ainsi que les résultats d’effets booléens et de résultats. Ne conservez les enregistrements que lorsque le consentement, la politique de conservation et la valeur de débogage les justifient. Avant la sortie, faites fonctionner le luminaire fixe pour vérifier le classificateur lui même. Ensuite, lancez un petit ensemble d’appels réels entre les opérateurs, régions, langues et comportements de l’appelant qui comptent. Examinez les distributions de seuils plutôt que de vous accorder à un appel de laboratoire propre. Enfin, rejouer les échecs de production comme de nouveaux cas de régression sans copier le contenu sensible des conversations dans la suite de test. La limitation est simple : cet artefact valide une règle de décision, pas la qualité de la reconnaissance vocale ni la disponibilité d’un prestataire. Il ne peut pas choisir de seuils pour vos appelants. Cela empêche cependant qu’une conversation soignée soit prise pour un travail vérifié. Sidewisp est actuellement en préversion privée. Son expérience publique est un site web en accès anticipé et une démonstration interactive ; La collecte et la récupération de l’agent de production et de la santé ne sont pas incluses dans le dépôt actuel du site web. La direction du produit est une couche de santé autour des temps d’exécution existants, et non une plateforme vocale, un fournisseur téléphonique ou un fixer autonome. Si ce reçu à cinq étapes correspond aux pannes que vous devez détecter, vous pouvez rejoignez la prévisualisation privée de Sidewisp et décrire le runtime de l’agent vocal que vous exploitez.