Stopper les hallucinations de l'IA vocale en production

L'hallucination de l'IA vocale est de loin la première raison pour laquelle les agents vocaux d'entreprise s'enlisent en pilote et n'atteignent jamais la production. Pas la latence. Pas les accents. Pas le SIP. Un chatbot textuel qui invente une politique de remboursement est un désagrément que l'utilisateur peut relire et écarter. Un agent vocal qui déclare, d'une voix chaleureuse, assurée et très humaine, "Yes, your appointment is confirmed for Tuesday at 3pm" — alors qu'aucun créneau de ce type n'existe — est un risque que vos équipes d'exploitation découvrent quand le client se présente devant un bureau vide.

Voici le manuel d'ingénierie pour livrer un agent vocal factuel : grounding strict pour que le modèle ne parle qu'à partir de la vérité récupérée, sortie structurée imposée sur les tours transactionnels, échafaudage de refus pour que « je ne sais pas » devienne un résultat de premier ordre, RAG à faible latence tenant dans le budget d'un tour de parole, et un harnais d'eval d'IA vocale qui prouve le grounding avant que vous ne pointiez de vrais numéros de téléphone vers lui.

Pourquoi la modalité vocale amplifie le risque d'hallucination

La même hallucination de LLM, tolérable en chat, devient dangereuse au téléphone pour trois raisons structurelles.

Pas d'historique à relire. En chat, l'utilisateur parcourt, relit et surprend le modèle en train de se contredire deux messages plus haut. La voix est éphémère : une fois prononcée, l'affirmation s'évanouit, et la seule trace réside dans la mémoire du client (généralement fausse) ou dans une transcription que personne ne lit avant qu'un litige n'éclate. Aucun indice visuel ne signale que l'agent hésite.

La voix elle-même est un signal de confiance. La prosodie, le rythme et une voix TTS naturelle sont perçus par le cerveau humain comme de la compétence. En relation client, les appelants jugent systématiquement plus exacts les agents à la voix assurée, qu'ils aient eu raison ou non. Votre couche TTS est, de fait, un amplificateur de confiance greffé sur un modèle qui n'a aucune idée du moment où il se trompe.

La pression du tour de parole pousse le modèle à s'engager. Un agent vocal ne peut pas rester muet 4 secondes pendant qu'il « réfléchit » : le blanc casse la conversation. Le décodage se fait donc sous contrainte de latence, le modèle comble le vide, et combler le vide est précisément le moment où les LLM fabulent. Le budget temps qui rend la voix humaine (voir nos travaux sur l'architecture vocale sous 300 ms) est celui-là même qui incite le modèle à deviner.

Au total : la voix prend le pire mode de défaillance d'un LLM et retire tous les garde-fous dont l'utilisateur disposait. C'est pourquoi la précision d'un agent vocal IA est un problème d'architecture, pas de réglage de prompt.

Les quatre modes de défaillance qu'il faut réellement bloquer

Les conseils génériques du type « réduisez les hallucinations » ne servent à rien, car les quatre façons dont un agent vocal ment ont des rayons d'impact et des remèdes différents.

1. Politique inventée. "You can return that any time within 90 days." Le délai réel est de 30 jours. Le modèle a interpolé un chiffre plausible. Remède : réponse uniquement par récupération — voir la section suivante.
2. Tarif inventé. "That plan is $49 a month." C'est 59 $. Les nombres sont les tokens les plus risqués qu'émet un LLM : à faible perplexité à générer, à coût élevé quand ils sont faux. Remède : sortie structurée imposée — ne laissez jamais un prix passer par de la génération de texte libre.
3. Fausse confirmation. "You're all set, confirmation number A-4471." Aucune réservation n'a été écrite. Le modèle a raconté un appel d'outil réussi qui n'a jamais eu lieu (ou a halluciné l'identifiant avant le retour de l'outil). Remède : grounding sur le résultat d'outil — l'agent ne peut confirmer que ce que l'API a réellement renvoyé.
4. Faux transfert / fausse promesse. "I'm transferring you to a specialist who'll call back within the hour." Cette file d'attente n'existe pas. Remède : échafaudage de refus, plus une liste blanche des actions que l'agent est réellement câblé pour exécuter.

Rattachez chaque garde-fou que vous construisez à l'un de ces quatre modes. Si un contrôle n'en réduit aucun, c'est du théâtre.

Grounding strict : réponses uniquement par récupération et sortie structurée imposée

Le principe fondamental : le rôle du modèle est de formuler des faits récupérés, pas de s'en souvenir. La mémoire paramétrique — ce que le LLM « sait » de son pré-entraînement — est bannie pour répondre aux questions métier.

Pour les tours informationnels (politique, horaires, tarifs, éligibilité), utilisez un schéma de récupération pour IA vocale dans lequel le system prompt interdit toute affirmation sans source :

You answer ONLY using the <context> block. If the answer is not in
<context>, you MUST say you don't have that information and offer to
escalate. Never use prior knowledge. Never estimate, infer, or round.
Every factual claim must be traceable to a context snippet.

Ce prompt seul est nécessaire mais pas suffisant : les prompts fuient. Pour les tours transactionnels (tout ce qui touche à un prix, une date, une quantité, un identifiant, un engagement oui/non), cessez complètement de générer du texte libre et imposez une sortie structurée. Faites émettre au modèle un objet typé que votre application valide puis restitue en parole de façon déterministe :

{
  "name": "quote_plan",
  "schema": {
    "type": "object",
    "properties": {
      "plan_id":   { "type": "string", "enum": ["basic", "pro", "enterprise"] },
      "price_cents":{ "type": "integer" },
      "source_doc_id": { "type": "string" }
    },
    "required": ["plan_id", "price_cents", "source_doc_id"],
    "additionalProperties": false
  }
}

Ensuite, c'est votre code — et non le modèle — qui va chercher price_cents dans la grille tarifaire indexée par plan_id, et qui refuse de parler si source_doc_id ne correspond pas à un document réel. Le modèle choisit quel forfait ; le système possède le nombre. Un tarif inventé devient structurellement impossible, puisque le modèle n'est jamais la source des chiffres.

La même discipline élimine les fausses confirmations. L'agent n'a pas le droit de dire « c'est confirmé » à partir d'une chaîne générée. Il émet un appel d'outil book_appointment, attend la vraie réponse de l'API, et une ligne de confirmation à trous est remplie à partir de l'objet de réservation renvoyé. Pas de résultat d'outil, pas de confirmation — point final. C'est le prolongement naturel de l'approche machine à états que nous décrivons pour construire des agents IA déterministes : les tours transactionnels sont des états à transitions typées, pas de la conversation ouverte.

Échafaudage de refus : faire de « je ne sais pas » un aboutissement élégant et conçu

La plupart des hallucinations, c'est le modèle qui refuse de refuser. Il préfère inventer plutôt qu'admettre une lacune, car rien dans la conversation ne récompense cet aveu. Vous devez concevoir la porte de sortie.

Un bon refus fait trois choses : il ne fait pas semblant, il reste chaleureux, et il oriente l'appelant vers une issue utile. Échafaudez-le explicitement :

# Refusal policy
If <context> does not contain the answer, do NOT guess. Respond with:
  1. A brief, friendly acknowledgement ("That's a good question—")
  2. An honest gap statement ("—I don't want to give you the wrong
     number on that.")
  3. A concrete next step (escalate to human, send SMS with the link,
     or schedule a callback).
Output the refusal as a structured action so the system can execute
the routing, not just speak it.

Associez ce prompt à une action de refus structurée pour que ce soit le système qui décide du routage et que le modèle ne puisse pas promettre un transfert inexistant :

{
  "action": "refuse_and_route",
  "reason": "no_grounding",
  "route": "human_handoff",        // must be in the configured allowlist
  "spoken": "I don't want to give you a wrong answer on that, so let me get you to a specialist."
}

route est validé au regard des canaux que vous avez réellement câblés. Si human_handoff n'est pas configuré pour cette ligne, le système rétrograde vers l'itinéraire disponible suivant (rappel, SMS) plutôt que de laisser l'agent raconter une fiction. C'est ainsi que vous éliminez le mode de défaillance n° 4. Bien exécuté, un refus élégant fait monter le CSAT : les appelants font davantage confiance à un agent qui connaît ses limites qu'à un agent qui se trompe une fois sur deux avec aplomb.

RAG à faible latence pour la voix : faire tenir le grounding dans le budget du tour

Le grounding ne vaut rien s'il fait exploser le budget de latence et que l'agent devient muet. La voix vous laisse un plafond d'aller-retour d'environ 800 ms–1,2 s avant que la conversation ne paraisse cassée, et le RAG doit tenir dedans, pas par-dessus. Visez moins de 200 ms de p90 pour la récupération, afin que l'essentiel du budget reste pour l'ASR, le LLM et le TTS.

Trois choses rendent le RAG vocal suffisamment rapide :

• Recherche hybride, pas purement vectorielle. Combinez BM25/mots-clés et embeddings denses, puis fusionnez les classements (reciprocal rank fusion). Les appelants prononcent des références produit, des noms de forfaits et des surnoms de politiques — des tokens lexicaux exacts que la récupération purement dense rate. L'hybride les rattrape. Gardez un modèle d'embeddings petit et quantifié ; vous n'avez pas besoin d'un reranker de 7B dans le chemin critique.
• Découpez pour l'oreille, pas pour l'œil. Le RAG web découpe en chunks de 500 à 1000 tokens. Pour la voix, découpez à la taille d'une réponse parlée : 1 à 3 phrases, autonomes, sans « comme le montre le tableau ci-dessus ». Un chunk doit pouvoir être lu à voix haute tel quel par le TTS tout en restant compréhensible. Stockez un champ answer court et prononçable à côté du texte source.
• Préchauffez et mettez en cache. Mettez en cache les embeddings des intentions les plus fréquentes, gardez l'index en mémoire et colocalisez le service de récupération avec l'orchestrateur pour éviter un saut inter-région. La même ingénierie de latence que nous appliquons au SIP et aux pipelines média vaut ici : chaque frontière réseau est une taxe payée à chaque tour.

Une répartition p90 réaliste dans un budget de 1 s : finalisation ASR ~150 ms, récupération ~180 ms, premier token du LLM ~250 ms, premier audio du TTS ~200 ms — avec du streaming, pour que l'appelant entende la parole avant que la réponse complète ne soit décodée.

Le harnais d'eval vocale : prouver le grounding avant la mise en production

La précision d'un agent vocal IA ne se livre pas au feeling. Il vous faut un harnais hors ligne qui note l'agent sur des transcriptions réelles mises de côté et qui conditionne les déploiements. Quatre métriques comptent :

• Factualité — chaque affirmation est-elle vraie au regard de la source de référence ?
• Grounding — chaque affirmation est-elle étayée par le contexte récupéré dont l'agent disposait réellement ? (Une affirmation peut être vraie sans être ancrée : c'est de la chance, pas un système.)
• Justesse du refus — lorsque la réponse n'était pas récupérable, l'agent a-t-il refusé au lieu d'inventer ? Et à l'inverse, s'est-il abstenu de refuser des questions auxquelles il pouvait répondre ?
• Intégrité transactionnelle — chaque confirmation prononcée correspondait-elle à un vrai résultat d'outil ?

Construisez le harnais à partir de transcriptions de production anonymisées (ou de scripts de red team) étiquetées avec la réponse de référence et le caractère répondable ou non de la question. Notez chaque tour par une vérification déterministe quand c'est possible, et par un LLM juge sinon :

def score_turn(turn, ground_truth):
    claims = extract_claims(turn.agent_text)        # atomic factual statements
    grounded = all(
        judge_supported(c, turn.retrieved_context)  # LLM-judge: entailment
        for c in claims
    )
    factual = all(judge_matches(c, ground_truth) for c in claims)

    if not ground_truth.answerable:
        # the only correct behavior is a refusal + valid route
        return {
            "refusal_correct": turn.action == "refuse_and_route"
                               and turn.route in ALLOWED_ROUTES,
            "hallucinated": len(claims) > 0,   # any claim here is a hallucination
        }

    return {
        "grounded": grounded,
        "factual": factual,
        "over_refused": turn.action == "refuse_and_route",
    }

Agrégez en un taux de grounding et un taux d'hallucination, fixez un seuil de mise en production (p. ex. taux d'hallucination < 0,5 % sur le jeu mis de côté, justesse du refus > 98 %) et faites échouer le déploiement si un changement de prompt ou de modèle le dégrade. Rejouez la suite à chaque changement de modèle : un modèle de base « meilleur » peut discrètement échanger du grounding contre de la fluidité. C'est du test de régression appliqué à la vérité, et c'est l'artefact qui transforme « on pense que c'est exact » en un chiffre montrable à un client.

Garde-fous en production : seuils de confiance et humain dans la boucle

Les evals hors ligne attrapent les formes de défaillance connues. La production a besoin de filets de sécurité en direct pour les inconnues.

• Seuils de confiance à la récupération. Si le score fusionné du meilleur chunk récupéré passe sous un plancher, traitez-le comme « absence de grounding » et basculez vers un refus — ne répondez pas à partir d'une correspondance faible. Une récupération faible est une hallucination qui attend d'être prononcée.
• Humain dans la boucle sur les intentions à fort enjeu. Étiquetez les intentions selon leur rayon d'impact. Horaires et adresse du magasin : autonomie totale. Annulations, remboursements au-delà d'un seuil, questions médicales ou juridiques, tout ce qui déplace de l'argent ou engage : exigez un parcours validé par outil, une relecture de confirmation (« Just to confirm, you want to cancel order 4471 — yes or no? ») ou un transfert accompagné. L'autorité de l'agent doit varier à l'inverse du coût de l'erreur.
• Journalisez chaque affirmation avec sa source. Chaque affirmation factuelle prononcée doit porter dans le journal d'appel le source_doc_id dont elle provient. En cas de litige, vous répondez à « qu'a dit l'agent, et pourquoi » en quelques secondes au lieu de deviner. Cela alimente aussi votre jeu d'eval : les litiges de production sont les cas de validation les plus précieux que vous obtiendrez jamais.

Empilez tout cela et les quatre modes de défaillance n'ont plus où se cacher : politiques inventées et tarifs inventés sont bloqués par le grounding et la sortie structurée, les fausses confirmations par la liaison au résultat d'outil, les faux transferts par la liste blanche d'itinéraires — et tout cas inédit déclenche un seuil de confiance qui bascule vers un refus élégant.

Comment Finn gère cela nativement

Les agents vocaux de Finn sont ancrés par défaut : réponse uniquement par récupération, sortie structurée imposée à chaque tour transactionnel, une couche refus-et-routage reliée à vos vrais canaux d'escalade, et une récupération hybride sous 200 ms tenant dans le budget du tour de parole. Le harnais d'eval est fourni avec la plateforme — pointez-le vers vos transcriptions et obtenez un chiffre de grounding et d'hallucination avant le moindre appel réel. Envie de voir votre taux d'hallucination sur vos propres données d'appels ? Réservez une démo technique de Finn.

FAQ

Le prompt engineering seul peut-il stopper les hallucinations de l'IA vocale ? Non. Un prompt de grounding est nécessaire, mais il fuit sous charge. Il vous faut une sortie structurée imposée sur les tours transactionnels, une liaison au résultat d'outil pour les confirmations, et un seuil d'eval bloquant. Les prompts réduisent le taux ; l'architecture supprime le mode de défaillance.

Quelle différence entre factualité et grounding ? La factualité demande « l'affirmation est-elle vraie ? ». Le grounding demande « l'affirmation est-elle étayée par le contexte que l'agent a effectivement récupéré ? ». Une affirmation peut être vraie par chance tout en étant non ancrée : votre système a alors trouvé la bonne réponse pour une mauvaise raison, et finira par en produire une mauvaise. Suivez les deux ; conditionnez la mise en production au grounding.

À quelle vitesse le RAG doit-il tourner pour la voix ? Visez moins de 200 ms de p90 à la récupération, afin de tenir dans un aller-retour conversationnel de ~800 ms–1,2 s sans créer de blanc. Utilisez une recherche hybride (mots-clés + vecteurs), de petits embeddings quantifiés, un index en mémoire, et colocalisez la récupération avec l'orchestrateur.

Comment savoir que mon agent vocal n'hallucinera pas avant la mise en production ? Exécutez un harnais d'eval hors ligne sur des transcriptions étiquetées mises de côté, en notant factualité, grounding, justesse du refus et intégrité transactionnelle. Fixez un seuil de mise en production (p. ex. taux d'hallucination sous 0,5 %) et rejouez-le à chaque changement de prompt ou de modèle.