RAG pour agents vocaux en production : stopper les hallucinations

## RAG pour agents vocaux : stopper les hallucinations en appel réel

Tous les tutoriels de « développement de chatbot RAG » que l'on trouve en ligne construisent la même chose : une zone de texte, une base de connaissances et un bot qui colle une réponse avec une petite pastille « source » en dessous. Le célèbre guide no-code de bot de voyage de Voiceflow décrit même le RAG comme « la formation d'un nouveau collaborateur ». Parfait pour un widget de site web, où l'utilisateur voit la citation et peut relire la réponse.

Un appel téléphonique n'offre rien de tout cela. Pas de pastille de citation. Pas d'historique à faire défiler. L'appelant entend une phrase parlée, en temps réel, et la considère comme un engagement que votre entreprise vient de prendre. Si votre agent invente un délai de remboursement, annonce un mauvais tarif ou confirme un rendez-vous inexistant, vous n'avez aucune note de bas de page « sources » derrière laquelle vous abriter : vous avez une promesse enregistrée.

Voici le guide RAG orienté voix que les explications génériques ignorent : un retrieval qui tient dans un budget de latence temps réel, du grounding pour des données que vous ne pouvez pas afficher, des schémas de refus et de transfert, et comment évaluer réellement les réponses parlées à la recherche d'hallucinations.

## Pourquoi l'hallucination est plus grave à l'oral

Trois éléments rendent un fait halluciné plus dangereux en appel qu'en chat :

1. **Aucune citation visible.** À l'écrit, une mauvaise réponse accompagnée d'une source cliquable invite l'utilisateur à vérifier et à se corriger. À l'oral, l'assurance du modèle *est* l'interface. Une phrase fluide et fausse sonne exactement comme une phrase fluide et juste.
2. **Temps réel, un seul essai.** Le chat permet de relire et de raisonner. L'appelant traite la parole de façon linéaire et passe à la suite. L'erreur est absorbée avant que quiconque puisse la signaler.
3. **Les engagements oraux créent une responsabilité.** « Oui, vous pouvez annuler gratuitement sous 48 heures » devient de fait votre politique — enregistrée, horodatée et parfaitement opposable en apparence. Les grands modèles de langage sont entraînés à être serviables et fluides, pas à se retenir. Ce comportement par défaut est un problème juridique au téléphone.

L'objectif du RAG ici n'est pas de « faire savant ». C'est : **ne dire que ce qui est récupérable, et refuser le reste à voix haute.**

## Architecture RAG pour un agent téléphonique : le retrieval dans le budget de latence

La contrainte dure à l'oral, c'est la latence de tour de parole. On perçoit un silence au-delà d'environ 800 ms et on se met à parler par-dessus l'agent au-delà d'environ 1,2 s. Toute votre boucle — ASR → retrieval → LLM → TTS — doit tenir dans un **budget d'environ 1 seconde** pour paraître naturelle.

Une répartition indicative pour un tour de parole :

| Étape | Budget |
|---|---|
| Finalisation de l'ASR (fin de parole) | ~150–300 ms |
| Retrieval (embedding de la requête + recherche vectorielle + reranking) | **~150–250 ms** |
| Premier token du LLM | ~300–500 ms |
| Premier audio du TTS | ~150–300 ms |

Le retrieval dispose d'environ 200 ms. Cela élimine les approches naïves que les bots textuels s'autorisent sans réfléchir :

- **Pas de retrieval multi-hop en cours de tour.** Une seule passe de retrieval par tour. Faites l'expansion de requête hors ligne ou en parallèle, jamais en séquence.
- **Préchauffez et mettez en cache les embeddings.** Calculez à l'avance les embeddings de la base de connaissances ; seule la requête de l'appelant est embarquée en direct.
- **Retrieval spéculatif.** Lancez le retrieval sur la transcription ASR *partielle* avant la fin de parole, puis confirmez. Vous récupérez 100–200 ms.
- **Streamez le LLM vers le TTS.** Commencez à prononcer la première proposition pendant que les tokens suivants se génèrent. Le grounding doit toutefois être arbitré *avant* le premier token : une phrase déjà prononcée ne se rattrape pas.

## Ancrer la réponse : chunking, reranking et citation des données de compte

Le grounding vocal manipule deux classes de données obéissant à des règles différentes.

**Connaissances statiques (politiques, tarifs, FAQ).** Découpez en petits chunks — 200 à 400 tokens — parce que les réponses parlées sont courtes et qu'un contexte surchargé pousse le modèle à faire la synthèse entre plusieurs chunks (une source d'hallucination). Appliquez toujours un **reranking** au top-k ; un reranker cross-encoder sur 20 candidats → top 3 réduit de manière mesurable les réponses issues du mauvais chunk. Donnez 2 ou 3 chunks au modèle, pas 10.

**Données de compte dynamiques (statut de commande, solde, rendez-vous).** Elles ne passent pas par la recherche vectorielle : c'est un appel de fonction en direct vers votre système de référence (via un webhook de type `make integration for ai agents`, ou une API directe). Règle : **le modèle ne peut énoncer que les valeurs de champs présentes dans la réponse de l'outil.** Si `order.status` est absent, l'agent ne peut pas en déduire « probablement expédié ». Structurez le prompt pour que les données de compte arrivent en JSON typé, et demandez au modèle de citer les champs mot pour mot.

Puisque vous ne pouvez afficher aucune source en appel, la « citation » devient une **provenance inscrite dans le prompt** : étiquetez chaque chunk récupéré avec son identifiant de source, et faites conditionner le modèle en interne sur « réponds uniquement à partir des blocs CHUNK_ID ». Vous journalisez le chunk à l'origine de la réponse parlée pour l'audit — la citation est pour *vous*, pas pour l'appelant.

## Refus et escalade : « je vous passe un conseiller » vaut mieux que deviner

Le levier anti-hallucination le plus puissant à l'oral, c'est un bon chemin de refus. Si le retrieval ne renvoie rien au-dessus d'un seuil de confiance, la bonne sortie n'est pas la meilleure hypothèse : c'est l'escalade.

Prévoyez trois issues explicites par tour, pas deux :

- **Répondre** — chunk(s) ancré(s) au-dessus du seuil → énoncer le fait ancré.
- **Clarifier** — requête ambiguë → poser une question courte et relancer le retrieval.
- **Transférer** — score de retrieval faible, hors périmètre ou frustration détectée → « je veux vous donner une réponse exacte, je vous mets en relation avec un spécialiste » + [transfert accompagné](/glossary/warm-transfer) avec le contexte.

Branchez le seuil sur le score du reranker, pas seulement sur la similarité vectorielle. Et rendez le transfert peu coûteux : un appel qui se termine par un transfert propre est une *réussite*, pas un échec. Deviner pour éviter un transfert, c'est exactement comme cela qu'on récolte la responsabilité enregistrée évoquée en première partie.

## Les schémas de prompt qui réduisent les faits inventés en appel

Les `rag prompts` vocaux sont plus stricts que les prompts de chat, car aucune source visible ne vient amortir une mauvaise réponse :

- **Interdiction de répondre de mémoire.** « Tu n'as aucune connaissance en dehors du bloc CONTEXT. Si la réponse ne s'y trouve pas, dis que tu vas vérifier ou transfère. » Énoncez-le, puis répétez-le vers la fin du [system prompt](/glossary/system-prompt) (la récence aide).
- **Règle du mot pour mot sur les données de compte.** « Cite les nombres, dates et statuts exactement tels qu'ils apparaissent dans le résultat de l'outil. N'estime jamais, n'arrondis jamais. »
- **Pas de synthèse inter-chunks pour les politiques.** « Réponds à partir du seul chunk le plus pertinent. Ne combine pas deux politiques pour en fabriquer une nouvelle. »
- **Limite de longueur parlée.** « Réponds en une ou deux phrases qu'une personne peut suivre à l'oreille. » Les réponses longues dérivent et inventent.
- **Verbe d'incertitude explicite.** Donnez au modèle une porte de sortie autorisée — « laissez-moi vous le confirmer » — pour que le refus soit un chemin de tokens disponible et non un état d'échec.

## Évaluer les sorties d'un RAG parlé

On ne met pas un RAG vocal en production au feeling. Construisez un harnais d'évaluation hors ligne sur les transcriptions :

- **Fidélité (faithfulness)** — chaque affirmation de la réponse découle-t-elle du contexte récupéré ? Notez avec un LLM juge sur des paires (contexte, réponse). Cible >0,95.
- **Groundedness / pertinence de la réponse** — la réponse s'est-elle appuyée sur le chunk récupéré, ou l'a-t-elle ignoré pour improviser ?
- **Taux d'hallucination** — % de réponses contenant une affirmation absente du contexte. C'est votre indicateur phare ; suivez-le à chaque release comme un error budget.
- **Précision/rappel du refus** — a-t-il transféré quand il le fallait, et *pas* transféré quand il avait la réponse ? Trop de refus dégrade l'expérience client ; pas assez, c'est le risque juridique.
- **Hit@k du retrieval** — avant d'accuser le LLM, vérifiez que le bon chunk a seulement été récupéré. La plupart des « hallucinations » sont des échecs de retrieval.

Exécutez cela sur un golden set de transcriptions d'appels réels à chaque déploiement. Ajoutez au jeu chaque hallucination observée en production comme test de non-régression.

## Faire ou acheter : ce que Finn prend en charge

Développer votre propre stack RAG vocal, c'est assumer : une infra de retrieval en sous-seconde, le reranking, le streaming ASR/TTS, le [barge-in](/glossary/barge-in), la machine à états refus/transfert, le transfert accompagné et un harnais d'évaluation des transcriptions — puis maintenir l'ensemble dans le budget de latence à chaque appel. C'est des mois de `ai agent development`, pas un tutoriel de week-end.

Finn livre la couche de grounding vocal clés en main : un retrieval calibré sur le budget du tour de parole, du function calling sur les données de compte avec grounding mot pour mot, refus et transfert accompagné intégrés, et des transcriptions par appel que vous pouvez injecter directement dans votre évaluation. Vous apportez la base de connaissances et le système de référence ; Finn garantit des réponses parlées factuelles.

## Liens internes
- `/blog/ai-voice-agent-vs-ivr-enterprise-guide` — où s'arrête le SVI déterministe et où commence l'IA vocale ancrée
- `/blog/how-to-manage-high-call-volumes-without-hiring-more-agents-2026` — l'économie de la déflexion qui rend le grounding rentable
- `/blog/ai-voice-agent-pricing-comparison-2026` — coût par minute du stack retrieval + LLM + TTS
- `/blog/blog-draft-your-help-desk-ends-at-the-ticket-where-voice-ai-closes-the-loop-2026-a9e2754c` — boucler la boucle après l'appel

## FAQ
_Emit as FAQ JSON-LD (schema.org/FAQPage)._

**Q : Qu'est-ce que le RAG dans un agent vocal ?**
R : La [génération augmentée par récupération](/glossary/retrieval-augmented-generation) ancre la réponse parlée de l'agent dans vos propres politiques, tarifs et données de compte récupérés au moment de l'appel — il énonce ainsi des faits issus de votre base de connaissances plutôt que les suppositions du modèle.

**Q : Comment éviter les hallucinations du LLM pendant un appel téléphonique ?**
R : Faites le retrieval et le reranking avant de répondre, demandez au modèle de ne parler qu'à partir du contexte récupéré, citez les champs de compte mot pour mot et transférez à un humain dès que la confiance du retrieval est faible.

**Q : Quelle latence le RAG ajoute-t-il à un tour de parole ?**
R : Prévoyez ~150–250 ms de retrieval dans un tour total d'environ 1 seconde. Préchauffez les embeddings, faites une seule passe de retrieval, appliquez le reranking à un petit ensemble de candidats et démarrez le retrieval sur l'ASR partiel pour tenir le budget.

**Q : Comment mesurer l'hallucination dans les réponses parlées ?**
R : Notez les transcriptions en fidélité et en groundedness avec un LLM juge, suivez le taux d'hallucination comme un error budget, et mesurez la précision/le rappel du refus ainsi que le hit@k du retrieval sur un golden set à chaque release.

Envie de réponses vocales factuelles sans construire vous-même le stack retrieval, refus et évaluation ? **Découvrez comment Finn ancre chaque appel — réservez une démo sur hirefinn.ai.**