Corriger la parole à la source

VoxRange fait tourner des agents IA qui répondent à de vrais appels téléphoniques en ourdou, et dans le mélange d’ourdou et d’anglais, avec des alternances constantes, que les gens parlent réellement. J’en suis l’architecte principal. Cet article porte sur une erreur que nous avons commise dans la partie « écoute » de ce pipeline, et sur la règle que j’en ai tirée.

Le symptôme

La reconnaissance vocale sur les appels en ourdou produisait régulièrement des bribes de texte en alphabet latin au milieu de transcriptions en ourdou. L’audio téléphonique à bande étroite, les langues mélangées et les noms propres rendent déjà la transcription difficile, et ces fragments aggravaient les choses : ce que dit la transcription, c’est ce à quoi l’agent répond.

La solution évidente était de nettoyer la sortie. Si un agent est configuré pour l’ourdou et qu’un fragment revient en alphabet latin, on le supprime avant que l’agent ne le voie.

Pourquoi le filtre était une erreur

Le filtre fonctionnait, au sens où les parasites disparaissaient. La vraie parole aussi.

Les appelants ne restent pas dans un seul système d’écriture. Une grande partie de l’ourdou s’écrit en lettres latines, en Roman Urdu, et beaucoup de conversations du quotidien basculent vers l’anglais le temps d’un mot ou d’une phrase entière. Un exemple inventé : « mera appointment confirm kar dein » est une demande ordinaire, et chacun de ses mots est de la vraie parole en lettres latines. Une règle qui supprime le texte en alphabet latin ne peut pas distinguer cette phrase du bruit, car au moment où elle s’exécute, la seule chose qui reste à juger est l’écriture, et l’écriture n’est pas le problème.

Nous avons annulé le filtre. Un filtre plus étroit est resté : les écritures qui ne peuvent vraisemblablement pas correspondre à de la vraie parole sur ces appels, comme les caractères cyrilliques ou CJK, sont toujours supprimées, car les retirer ne coûte rien de réel.

D’où viennent réellement les parasites

Les fragments isolés étaient le symptôme d’un dysfonctionnement de l’étape d’écoute, et c’est donc là que la correction doit se faire :

• La détection de fin de parole. La détection d’activité vocale décide quand un appelant a fini de parler. Si elle tranche trop tôt, un tour de parole est découpé en fragments, et un fragment de mot est exactement le type d’audio qu’un modèle vocal transforme en absurdité énoncée avec assurance.
• L’ancrage de la langue. Indiquer au modèle quelle langue attendre, au lieu de le laisser deviner à chaque court extrait, l’empêche de dériver vers une autre langue au moindre bruit.
• Le vocabulaire. Les noms, lieux et termes métier que le modèle n’a jamais rencontrés reviennent sous forme d’approximations. Lui fournir le vocabulaire qu’il va entendre coûte moins cher que de réparer ces approximations.

Chacune de ces mesures change ce que le modèle entend ou attend. Aucune ne jette quoi que ce soit de ce que l’appelant a dit.

La leçon associée : la dérive des réglages

La détection de fin de parole dépend d’une seule valeur : la durée de silence à attendre avant de considérer que l’appelant a terminé. Nous l’avions ajustée après des problèmes sur des appels précédents. Lors d’un appel ultérieur, elle était revenue à une valeur agressive, et l’agent coupait la parole aux appelants en pleine phrase. Les tours fragmentés à l’origine des mauvaises transcriptions étaient revenus eux aussi.

La valeur n’existait que dans l’environnement d’un serveur. Rien dans le code ni dans son historique ne conservait la valeur ajustée, donc rien ne l’empêchait de changer. Une valeur de réglage comme celle-ci doit vivre dans une configuration versionnée, à côté du code qui la lit, avec une note expliquant pourquoi elle est fixée ainsi :

# voice-runtime config, versioned with the code
# How long to wait in silence before ending the caller's turn.
# Too short cuts callers off and fragments transcripts.
END_OF_SPEECH_SILENCE_MS: <tuned value>

Le même appel a enseigné une deuxième chose. Le silence sur un tour de parole est la somme de plusieurs étapes : l’attente de la fin de parole, la transcription, la recherche (retrieval), le LLM et la synthèse vocale. Certaines étaient chronométrées, une ne l’était pas. On ne peut pas décider quoi optimiser tant que chaque étape d’un tour n’est pas mesurée, car l’étape que l’on ne mesure pas est celle sur laquelle on finira par spéculer.

Ce que je conseillerais à quelqu’un qui construit la même chose

1. Quand un modèle produit des parasites, trouvez l’étape qui les a causés avant d’écrire une règle pour les supprimer. Les filtres de sortie ne voient pas les causes.
2. Testez toute règle de nettoyage sur de la vraie parole, désordonnée, alternances de langues comprises, avant de vous y fier.
3. Conservez les valeurs de réglage dans une configuration versionnée, accompagnées d’une justification, et pas seulement dans l’environnement d’un serveur.
4. Mesurez chaque étape d’un tour de parole avant d’en optimiser une seule.