D'où vient le temps d'attente pour un appel téléphonique avec une intelligence artificielle ?
Après avoir passé par le réseau de téléphonie et le routeur SIP/PBX, l'audio est traité, et le système détermine si l'utilisateur a terminé de parler. Ensuite, un modèle interprète l'appel et utilise des outils d'entreprise. Enfin, la réponse est convertie en audio et renvoyée au téléphone. Si une recherche dans un CRM ou la création d'un ticket nécessitent un temps d'attente, cela introduit également une latence perçue. Seule la première token du modèle est prise en compte, ce qui ignore la totalité du chemin perçu par l'appelant.
Analyse de la latence de bout en bout pour le service client vocal basé sur l'IA| Étape | Début et fin de la mesure | Risques courants |
|---|
| Transmission par téléphone | Accès et sortie de la plateforme vocale | Routage des réseaux, décodage, latence et perte de paquets. |
| Détection des contours | L'utilisateur doit arrêter de parler jusqu'à ce que le système confirme la fin. | Attendre trop longtemps ou couper trop tôt. |
| Réponse type | Envoyer des données valides pour générer du contenu reproductible. | Longueur excessive du contexte, choix du modèle et raisonnement complexe. |
| Appel à un outil | Envoyer une requête API pour obtenir les résultats disponibles. | Gestion des erreurs de système, tentatives de reconnexion et file d'attente. |
| Lecture audio | Le texte ou l'audio commence à être diffusé sur le téléphone. | Mise en mémoire tampon, attente de la première lecture et arrêt de la lecture |
VAD permet de déterminer si une personne est en train de parler, tandis que la détection de contours se concentre sur la question de savoir si la personne a fini de parler.
Le VAD (détecteur d'activité vocale) est généralement basé sur le volume et la durée du silence pour déterminer le début et la fin d'une phrase. Le VAD sémantique va, de plus, évaluer si le sens de la phrase est encore en cours. Une attente plus longue réduit le risque de coupures, mais augmente la durée des silences. Une réaction trop rapide peut entraîner la coupure d'une phrase en deux, par exemple, "euh... je voudrais changer ça". Les paramètres ne peuvent pas être uniformes pour toutes les situations. Le nom, l'adresse complète, le code et la description ouverte nécessitent des tolérances différentes en termes de temps d'arrêt.
"Barge-in" fait référence au contrôle des interventions, et ne signifie pas la fin d'une séquence.
"Barge-in" permet à l'appelant de prendre la parole pendant la phase d'interaction avec l'IA et d'interrompre la réponse initiale. Cela est utile pour corriger des informations, sauter des contenus déjà présentés et raccourcir les menus. Il est important de distinguer que "Barge-in" et la capacité du système à déterminer que l'utilisateur a terminé de parler sont deux choses différentes. En général, il est souhaitable de permettre aux appelants de prendre la parole ; cependant, pour les enregistrements informatifs, les demandes d'informations obligatoires ou la confirmation de champs importants, la décision d'autoriser ou non l'interruption doit être prise en fonction des procédures de l'entreprise et des exigences légales. La désactivation de "Barge-in" partout peut rendre les conversations maladroites, tandis que son activation partout peut empêcher la lecture complète du contenu nécessaire.
Il ne suffit pas de mentionner le temps moyen de latence ; il est également important de prendre en compte les valeurs p50, p95 et les taux de variation de l'erreur.
La moyenne peut être faussée par un petit nombre d'échantillons très lents ou un grand nombre d'échantillons très rapides. p50 permet de visualiser la perception générale de la conversation, tandis que p95 permet de repérer les cas les plus problématiques, mais qui se rencontrent fréquemment. De plus, on enregistre le temps écoulé entre le début de la parole de l'utilisateur et la première réponse, le temps nécessaire à l'exécution de l'outil, les erreurs de troncature, les temps d'attente, ainsi que les interruptions non prises en compte. Chaque échantillon doit également être étiqueté avec les informations suivantes : la tâche, le réseau, la langue, et l'utilisation ou non de l'API de l'entreprise. Sans ces informations, il est difficile de distinguer les différents contextes et de localiser les problèmes.
Il est nécessaire de noter à la fois les retards et les rotations.| Éléments d'observation | Définition des événements | Objectifs de l'utilisation |
|---|
| Réponse initiale retardée | Vérification de la fin de la séquence jusqu'à ce que l'utilisateur reçoive une réponse. | Différenciation des étapes, des modèles et des attentes de synthèse. |
| En attente d'outils | L'API permet d'accéder aux résultats. | Identifier les goulots d'étranglement dans les systèmes d'entreprise ou auprès de tiers. |
| Erreur de troncature | L'utilisateur a commencé à répondre avant d'avoir terminé de poser sa question. | Ajuster les stratégies pour la détection d'activité vocale (VAD), la segmentation et les champs. |
| Erreur en attente | L'utilisateur a terminé, mais le système reste silencieux. | Vérification de la fin, dépassement du délai et état des outils |
| L'insertion a réussi. | Une fois que l'utilisateur a parlé, la réponse précédente est annulée et la nouvelle entrée est conservée. | Vérifier la cohérence entre l'annulation de la lecture et le contexte. |
Pour les tests de téléphonie, il est nécessaire de prendre en compte le bruit, l'écho, les accents et les longues lignes.
Le microphone d'un site web, utilisé dans un bureau calme, ne peut pas être considéré comme une mesure valable pour les téléphones, les voitures, les téléphones mains libres, les écouteurs Bluetooth ou les téléphones fixes. Les tests doivent couvrir au moins les bruits de fond, l'écho, l'instabilité du signal, la rapidité et la lenteur de l'élocution, les accents courants, les chiffres, les codes alphanumériques et les adresses complètes. Pour les champs importants, l'objectif n'est pas seulement d'assurer une transcription correcte, mais de vérifier si le système peut reformuler, permettre à l'utilisateur de corriger et s'arrêter en cas d'incertitude.
Lorsque vous attendez une réponse pendant une longue période, évitez de combler le silence avec des réponses artificielles.
Les API CRM, ERP ou de gestion des commandes peuvent nécessiter plusieurs secondes, voire une procédure asynchrone. Le système peut utiliser des messages courts pour indiquer l'avancement, mais ne peut pas dire « terminé » avant que les résultats ne soient disponibles. Une fois qu'un délai acceptable est dépassé, il est préférable d'établir un état "en attente de confirmation", de mettre en œuvre un traitement manuel ou d'envoyer une notification ultérieure, et d'utiliser un identifiant unique pour éviter les exécutions redondantes. Si l'optimisation du délai se fait au détriment de la précision des résultats, il ne fait que révéler plus rapidement les erreurs.
« 3 secondes » ne peut être qu'un objectif de conception, et non un niveau de service (SLA) publié par GoGoCha.
Les études de cas publiées par GoGoCha démontrent l'efficacité de l'accès téléphonique et du flux de travail de mise en relation en temps réel, mais ne présentent pas de données sur la distribution de la latence, l'environnement des réseaux de télécommunications, des exemples d'appels ou des accords de niveau de service (SLA). Il ne convient pas d'établir des objectifs de conception de produits en se basant sur des définitions et des mesures non standardisées. Les projets d'entreprise doivent redéfinir les valeurs p50, p95 et les taux d'échec dans leurs propres systèmes PBX/SIP, API et dans des conditions de pointe.
