Agent vocal au téléphone : où passent réellement les millisecondes

Quand nous avons commencé à travailler sur Discall, notre plateforme d’agents vocaux téléphoniques, l’essentiel des discussions portait sur le choix du modèle de langage. C’était la mauvaise question. Ce qui fait raccrocher un appelant, ce n’est pas la qualité du raisonnement : c’est le silence.

Un blanc d’une seconde et demie au téléphone est insupportable. En visioconférence, on tolère ; au téléphone, où il n’y a aucun signal visuel, un silence long signifie « la ligne a coupé ». Les gens répètent, ou raccrochent.

Je détaille ici où passe le temps, parce que c’est le genre de décomposition qu’on ne fait généralement qu’après avoir perdu trois semaines à optimiser le mauvais poste.

Le budget de latence, poste par poste

Une réponse d’agent vocal traverse au minimum six étapes, et chacune consomme du temps.

Le transport téléphonique. L’audio arrive par le réseau de l’opérateur, transite par un fournisseur de téléphonie, puis atteint votre infrastructure. Ce trajet coûte quelques dizaines de millisecondes dans le meilleur des cas, davantage si votre serveur est loin du point d’interconnexion. C’est un poste qu’on ne peut pas optimiser par le code — seulement par le placement géographique de l’infrastructure.

La détection de fin de parole. Le système doit décider que l’interlocuteur a fini de parler. S’il attend trop, il ajoute du silence perçu. S’il coupe trop tôt, il interrompt — ce qui est bien pire. C’est le poste le plus sous-estimé, et le plus mal réglé, mais pas nécessairement le plus lourd : sa contribution dépend entièrement de ce que fait l’étage suivant.

La transcription. Convertir l’audio en texte. En mode « streaming », la transcription avance pendant que la personne parle, et le coût marginal à la fin de la phrase est faible. En mode « batch », on attend la fin puis on transcrit le tout : le délai s’ajoute intégralement.

La génération de la réponse. Le modèle de langage. C’est le poste sur lequel se concentre l’attention, et c’est rarement le pire — surtout si l’on mesure le temps jusqu’au premier token plutôt que jusqu’à la réponse complète.

Sur notre chaîne, c’est la transcription qui domine : entre le moment où quelqu’un se tait et celui où le moteur déclare son résultat définitif, il s’écoule couramment 700 à 1500 ms selon le fournisseur. Ce chiffre change complètement les priorités d’optimisation — il rend par exemple sans effet un réglage de détection de fin de parole qu’on aurait raccourci de 100 ms.

La synthèse vocale. Convertir le texte en audio. Même distinction : temps jusqu’au premier échantillon audio, ou temps jusqu’à l’audio complet.

Le retour vers l’appelant. Le trajet inverse.

Pourquoi additionner ces postes donne un mauvais résultat

L’erreur d’architecture classique consiste à enchaîner ces étapes séquentiellement : attendre la transcription complète, la passer au modèle, attendre la réponse complète, la passer à la synthèse, attendre l’audio complet, puis émettre.

Dans cette configuration, les délais s’additionnent. Et comme chaque poste a sa propre variabilité, le pire cas est bien plus mauvais que la somme des cas moyens. C’est ce qui produit ces conversations où l’agent répond correctement neuf fois puis met quatre secondes la dixième — et c’est cette dixième fois dont l’appelant se souvient.

La bonne mesure n’est donc pas la latence moyenne. C’est le 95ᵉ centile, et surtout la variance. Un agent qui répond systématiquement en 900 ms est perçu comme meilleur qu’un agent qui répond en 500 ms neuf fois sur dix et en 3 s la dixième.

Les trois optimisations qui comptent

Diffuser au fil de l’eau, à chaque étage. Dès que le modèle produit sa première phrase, on peut lancer la synthèse de cette phrase pendant que la suite se génère. Dès que la synthèse produit ses premiers échantillons, on peut les émettre. Le délai perçu devient celui du premier mot, pas celui de la réponse complète. C’est de loin le gain le plus important, et c’est un travail d’architecture, pas de configuration.

Cela impose de découper la réponse à des frontières qui s’entendent bien — fin de phrase, fin de proposition. Découper au token produit une prosodie hachée, qui donne l’impression d’un robot même quand la voix est bonne.

Régler la détection de fin de parole par la mesure, pas par principe. Nous sommes à 400 ms de silence avant de considérer qu’un tour est terminé, avec un plancher dur à 200 ms. Ce n’est pas un réglage d’origine : nous sommes partis plus bas, et nous l’avons remonté après avoir constaté qu’en dessous de 200 ms le détecteur déclenche sur les micro-pauses respiratoires et fragmente les dictées. Une adresse énoncée normalement se transformait en une poignée de tours de parole distincts, chacun traité comme une phrase indépendante.

Le point important est que ce réglage n’a pas coûté de latence perçue : puisque la transcription met de toute façon 700 à 1500 ms, passer de 300 à 400 ms de silence ne se voit pas. C’est exactement le genre d’arbitrage qu’on ne peut faire qu’avec les mesures de chaque étage sous les yeux.

Nous capturons également un demi-seconde d’audio avant le déclenchement du détecteur. Sans ce tampon, la première syllabe d’un énoncé se perd — ce qui est particulièrement audible sur les consonnes d’attaque, et se traduit par un mot manquant en début de phrase.

Couvrir le silence quand il devient anormal, et seulement là. Nous disposons d’un mécanisme de relance — une phrase courte du type « Un instant. » — déclenché quand la génération dépasse un seuil. Il est utile sur les cas lents, et il est désactivé par défaut sur les tours de parole ordinaires : une interjection systématique s’entend au bout de trois échanges et donne un sentiment de bavardage mécanique. La règle que nous appliquons est de meubler l’anomalie, jamais le fonctionnement normal.

Photo : domaine public (CC0).

Ce que nous mesurons, et comment

Une moyenne globale n’apprend rien. Nous instrumentons chaque étage séparément, avec un horodatage à l’entrée et à la sortie, et nous regardons la distribution plutôt que la moyenne.

Notre objectif de bout en bout est de 600 à 900 ms sur un tour de parole complet, transcription, génération et synthèse comprises. C’est une cible tenable, pas un record : en dessous, le gain n’est plus perceptible ; au-dessus, l’appelant commence à se demander si la ligne tient.

Trois indicateurs suffisent à piloter :

• le temps jusqu’au premier son émis, qui correspond à ce que l’appelant ressent ;
• le taux d’interruptions injustifiées, c’est-à-dire les fois où l’agent a coupé quelqu’un qui n’avait pas fini — le symptôme d’un seuil trop agressif ;
• le taux de reprises, quand l’appelant répète parce qu’il a cru que la ligne était coupée.

Ces deux derniers indicateurs sont importants parce qu’ils vont en sens inverse. Optimiser la latence en durcissant la détection de fin de parole améliore le premier chiffre et dégrade le deuxième. Sans les regarder ensemble, on croit progresser alors qu’on déplace le problème.

Photo : domaine public (CC0).

Ce que nous ne faisons pas

Nous ne cherchons pas la latence minimale absolue. Passé un certain seuil, le gain n’est plus perceptible, et le coût en qualité de réponse devient réel : un modèle plus petit répond plus vite et se trompe davantage. Sur un appel où l’agent doit identifier un dossier, une erreur coûte infiniment plus cher que 200 ms.

Nous ne cherchons pas non plus à masquer la latence par des interjections artificielles. Les « euh » et les « alors » ajoutés pour meubler fonctionnent quelques secondes, puis deviennent agaçants — et ils trompent l’appelant sur la nature de son interlocuteur.

Ce qu’il faut retenir

Si vous évaluez une solution d’agent vocal, ne demandez pas quel modèle elle utilise. Demandez :

• la réponse est-elle diffusée au fil de l’eau, ou attendue en entier à chaque étage ?
• quelle est la latence au 95ᵉ centile, pas en moyenne ?
• comment le seuil de fin de parole s’adapte-t-il au contexte de la question ?
• où l’infrastructure est-elle hébergée par rapport au point d’interconnexion téléphonique ?

Les réponses à ces quatre questions déterminent la qualité perçue bien davantage que le nom du modèle. C’est ce que nous avons appris en construisant Discall, et c’est ce que nous regardons en premier quand on nous demande de reprendre un agent vocal existant.