RAG voor voice agents in productie: stop hallucinaties

## RAG voor voice agents: stop hallucinaties tijdens live gesprekken

Elke tutorial over "RAG-chatbotontwikkeling" op internet bouwt hetzelfde: een tekstvak, een kennisbank en een bot die een antwoord plakt met een klein "bron"-labeltje eronder. Voiceflows populaire no-code-gids voor reisbots noemt RAG zelfs "alsof je een nieuwe medewerker inwerkt". Prima voor een widget op een website, waar de gebruiker de bronvermelding ziet en het antwoord kan herlezen.

Een telefoongesprek heeft dat allemaal niet. Geen bronlabel. Geen scrollback. De beller hoort één gesproken zin, in realtime, en beschouwt die als een toezegging die jouw bedrijf zojuist heeft gedaan. Verzint je agent een retourtermijn, noemt hij een verkeerde prijs of bevestigt hij een afspraak die niet bestaat, dan heb je geen "bronnen"-voetnoot om je achter te verschuilen — je hebt een opgenomen belofte.

Dit is de voice-first RAG-gids die de algemene uitleggen overslaan: retrieval die binnen een realtime latencybudget past, grounding voor data die je niet kunt tonen, patronen voor weigeren en doorverbinden, en hoe je gesproken antwoorden daadwerkelijk op hallucinatie evalueert.

## Waarom hallucinatie erger is bij spraak

Drie dingen maken een gehallucineerd feit gevaarlijker in een gesprek dan in een chat:

1. **Geen zichtbare bronvermelding.** In tekst nodigt een fout antwoord naast een gelinkte bron de gebruiker uit om te klikken en zichzelf te corrigeren. Bij spraak *is* de stelligheid van het model de interface. Een vloeiende foute zin klinkt precies als een vloeiende juiste zin.
2. **Realtime, één kans.** In een chat kun je herlezen en nadenken. Een beller verwerkt spraak lineair en gaat verder. De fout is al opgenomen voordat iemand hem kan markeren.
3. **Gesproken toezeggingen zijn aansprakelijkheid.** "Ja, u kunt binnen 48 uur kosteloos annuleren" is feitelijk jouw beleid — opgenomen, met tijdstempel en klinkend als iets waar men je aan kan houden. Grote taalmodellen zijn getraind om behulpzaam en vloeiend te zijn, niet om zich in te houden. Aan de telefoon is dat standaardgedrag een juridisch probleem.

Het doel van RAG is hier niet "slim klinken". Het is: **zeg alleen wat je kunt ophalen, en weiger de rest hardop.**

## RAG-architectuur voor een telefoonagent: retrieval binnen het latencybudget

De harde randvoorwaarde bij spraak is beurtlatency. Mensen merken stilte vanaf zo'n 800 ms en gaan vanaf zo'n 1,2 s door de agent heen praten. Je hele lus — ASR → retrieval → LLM → TTS — moet ongeveer in een **budget van 1 seconde** passen om natuurlijk aan te voelen.

Een ruwe verdeling voor één gesproken beurt:

| Fase | Budget |
|---|---|
| ASR-finalisatie (einde spraak) | ~150–300 ms |
| Retrieval (embedding van de query + vectorzoekopdracht + reranking) | **~150–250 ms** |
| Eerste token van het LLM | ~300–500 ms |
| Eerste audio van de TTS | ~150–300 ms |

Retrieval krijgt ongeveer 200 ms. Daarmee vallen naïeve patronen af die tekstbots zonder nadenken gebruiken:

- **Geen multi-hop-retrieval midden in een beurt.** Eén retrieval-slag per beurt. Doe query-expansie offline of parallel, nooit sequentieel.
- **Warm embeddings voor en cache ze.** Bereken de embeddings van de kennisbank vooraf; live wordt alleen de vraag van de beller ge-embed.
- **Speculatieve retrieval.** Start retrieval op het *gedeeltelijke* ASR-transcript nog vóór het einde van de spraak en bevestig daarna. Dat levert 100–200 ms op.
- **Stream het LLM door naar de TTS.** Begin de eerste deelzin uit te spreken terwijl latere tokens worden gegenereerd. De grounding moet echter *vóór* het eerste token vaststaan — een uitgesproken zinsdeel neem je niet meer terug.

## Het antwoord gronden — chunking, reranking en accountdata citeren

Grounding bij spraak kent twee dataklassen met verschillende regels.

**Statische kennis (beleid, prijzen, FAQ).** Chunk klein — 200 tot 400 tokens — want gesproken antwoorden zijn kort, en een opgeblazen context verleidt het model om over chunks heen te synthetiseren (een bron van hallucinatie). Pas altijd **reranking** toe op de top-k; een cross-encoder-reranker over 20 kandidaten → top 3 vermindert meetbaar de antwoorden uit de verkeerde chunk. Geef het model 2 à 3 chunks, geen 10.

**Dynamische accountdata (orderstatus, saldo, afspraak).** Die haal je niet via vectorzoeken op — dat is een live function call naar je bronsysteem (via een webhook in de trant van `make integration for ai agents`, of een directe API). Regel: **het model mag alleen veldwaarden uitspreken die in de tool-respons staan.** Ontbreekt `order.status`, dan mag de agent niet afleiden "waarschijnlijk al verzonden". Structureer de prompt zo dat accountfeiten als getypeerde JSON binnenkomen, en instrueer het model om velden letterlijk te citeren.

Omdat je in een gesprek geen bron kunt tonen, wordt "bronvermelding" **herkomst in de prompt**: label elke opgehaalde chunk met zijn bron-id en laat het model zich intern conditioneren op "antwoord alleen vanuit CHUNK_ID-blokken". Je logt welke chunk het gesproken antwoord opleverde voor audit — de bronvermelding is voor *jou*, niet voor de beller.

## Weigeren en escaleren: "ik verbind u door met een collega" verslaat gokken

De krachtigste maatregel tegen hallucinatie bij spraak is een goed weigerpad. Levert retrieval niets op boven een betrouwbaarheidsdrempel, dan is de juiste output niet de beste gok — maar escalatie.

Ontwerp drie expliciete uitkomsten per beurt, geen twee:

- **Antwoorden** — gegronde chunk(s) boven de drempel → spreek het onderbouwde feit uit.
- **Verduidelijken** — dubbelzinnige vraag → stel één korte wedervraag en haal opnieuw op.
- **Doorverbinden** — lage retrieval-score, buiten scope of gedetecteerde frustratie → "ik wil dit precies goed hebben — laat me u doorverbinden met een specialist" + [warme overdracht](/glossary/warm-transfer) mét context.

Koppel de drempel aan de reranker-score, niet alleen aan vectorgelijkenis. En maak doorverbinden goedkoop: een gesprek dat eindigt in een nette overdracht is een *succes*, geen mislukking. Gokken om een overdracht te vermijden is precies hoe je aan de opgenomen aansprakelijkheid uit de eerste paragraaf komt.

## Promptpatronen die verzonnen feiten in gesprekken terugdringen

Spraak-`rag prompts` zijn strenger dan chatprompts, omdat er geen zichtbare bron is om een fout antwoord te verzachten:

- **Verbod op antwoorden uit het hoofd.** "Je hebt geen kennis buiten het CONTEXT-blok. Staat het antwoord niet in CONTEXT, zeg dan dat je het nagaat, of verbind door." Zeg het, en herhaal het tegen het einde van de [system prompt](/glossary/system-prompt) (recentheid helpt).
- **Letterlijke veldregel voor accountdata.** "Citeer getallen, datums en statussen exact zoals ze in het tool-resultaat staan. Schat of rond nooit af."
- **Geen synthese over chunks heen bij beleid.** "Antwoord vanuit de ene meest relevante chunk. Combineer geen twee beleidsregels tot een nieuwe."
- **Maximale gesproken lengte.** "Antwoord in één of twee zinnen die iemand op gehoor kan volgen." Lange antwoorden dwalen af en verzinnen.
- **Expliciet twijfelwerkwoord.** Geef het model een toegestane uitweg — "laat me dat even voor u bevestigen" — zodat weigeren een beschikbaar tokenpad is en geen foutstatus.

## Gesproken RAG-output evalueren

Je kunt voice-RAG niet op gevoel uitrollen. Bouw een offline eval-harnas over de transcripten:

- **Faithfulness** — volgt elke bewering in het antwoord uit de opgehaalde context? Scoor met een LLM als beoordelaar over (context, antwoord)-paren. Doel >0,95.
- **Groundedness / antwoordrelevantie** — gebruikte het antwoord de opgehaalde chunk, of negeerde het die en ging het freewheelen?
- **Hallucinatiepercentage** — % antwoorden met een bewering die niet in de context staat. Dit is je kerncijfer; volg het per release als een error budget.
- **Precision/recall van weigeren** — verbond hij door wanneer dat moest, en verbond hij *niet* door terwijl hij het antwoord had? Te veel weigeren verpest de klantervaring; te weinig weigeren is het aansprakelijkheidsrisico.
- **Retrieval hit@k** — voordat je het LLM de schuld geeft: controleer of de juiste chunk überhaupt is opgehaald. De meeste "hallucinaties" zijn missers in de retrieval.

Draai dit bij elke deploy op een golden set van echte gesprekstranscripten. Voeg elke hallucinatie uit productie als regressietest toe aan die set.

## Bouwen of kopen: wat Finn afhandelt versus het zelf doen

Zelf een voice-RAG-stack bouwen betekent dat je eigenaar wordt van: retrieval-infrastructuur onder de seconde, reranking, ASR/TTS-streaming, [barge-in](/glossary/barge-in), de toestandsmachine voor weigeren en doorverbinden, warme overdracht en een eval-harnas voor transcripten — en dat je dat allemaal bij elk gesprek binnen het latencybudget houdt. Dat is maandenlang `ai agent development`, geen weekendtutorial.

Finn levert de voice-groundinglaag kant-en-klaar: retrieval afgestemd op het beurtbudget, function calling op accountdata met letterlijke veld-grounding, ingebouwd weigeren plus warme overdracht, en transcripten per gesprek die je rechtstreeks je evaluatie in kunt sturen. Jij levert de kennisbank en het bronsysteem; Finn houdt de gesproken antwoorden feitelijk.

## Interne links
- `/blog/ai-voice-agent-vs-ivr-enterprise-guide` — waar deterministische IVR ophoudt en gegronde voice-AI begint
- `/blog/how-to-manage-high-call-volumes-without-hiring-more-agents-2026` — de deflectie-economie die grounding de moeite waard maakt
- `/blog/ai-voice-agent-pricing-comparison-2026` — kosten per minuut van de retrieval- + LLM- + TTS-stack
- `/blog/blog-draft-your-help-desk-ends-at-the-ticket-where-voice-ai-closes-the-loop-2026-a9e2754c` — de cirkel rondmaken na het gesprek

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

**V: Wat is RAG in een voice agent?**
A: [Retrieval-Augmented Generation](/glossary/retrieval-augmented-generation) grondt het gesproken antwoord van de agent in je eigen beleid, prijzen en accountdata die tijdens het gesprek worden opgehaald — zo spreekt hij feiten uit je kennisbank uit in plaats van gissingen van het model.

**V: Hoe voorkom je LLM-hallucinaties tijdens een telefoongesprek?**
A: Haal op en rerank vóór je antwoordt, instrueer het model om alleen vanuit de opgehaalde context te spreken, citeer accountvelden letterlijk en verbind door naar een mens zodra de retrieval-betrouwbaarheid laag is.

**V: Hoeveel latency voegt RAG toe aan een spraakbeurt?**
A: Reken op ~150–250 ms voor retrieval binnen een totale beurt van ongeveer 1 seconde. Warm embeddings voor, doe één retrieval-slag, rerank een kleine kandidatenset en start retrieval al op het gedeeltelijke ASR-transcript om binnen budget te blijven.

**V: Hoe meet je hallucinatie in gesproken antwoorden?**
A: Scoor transcripten op faithfulness en groundedness met een LLM als beoordelaar, volg het hallucinatiepercentage als een error budget en meet bij elke release de precision/recall van weigeren plus de retrieval hit@k op een golden set.

Wil je feitelijke spraakantwoorden zonder zelf de retrieval-, weiger- en evaluatiestack te bouwen? **Ontdek hoe Finn elk gesprek grondt — boek een demo op hirefinn.ai.**