RAG per agenti vocali in produzione: basta allucinazioni

## RAG per agenti vocali: basta allucinazioni durante le chiamate

Ogni tutorial online sullo "sviluppo di chatbot RAG" costruisce la stessa cosa: una casella di testo, una knowledge base e un bot che incolla una risposta con una piccola etichetta "fonte" sotto. La popolare guida no-code di Voiceflow per i bot di viaggio arriva a definire il RAG "come formare un nuovo dipendente". Va benissimo per un widget su un sito, dove l'utente vede la citazione e può rileggere la risposta.

Una telefonata non ha nulla di tutto questo. Non c'è etichetta della fonte. Non c'è cronologia da riscorrere. Chi chiama sente una frase parlata, in tempo reale, e la considera un impegno che la tua azienda ha appena preso. Se il tuo agente si inventa una finestra di rimborso, sbaglia un prezzo o conferma un appuntamento che non esiste, non hai una nota a piè di pagina con le "fonti" dietro cui ripararti: hai una promessa registrata.

Questa è la guida al RAG in ottica voice che le spiegazioni generiche saltano: retrieval che sta dentro un budget di latenza in tempo reale, grounding per dati che non puoi mostrare, pattern di rifiuto e trasferimento e come valutare davvero le risposte parlate in cerca di allucinazioni.

## Perché l'allucinazione è più grave nella voce

Tre elementi rendono un dato allucinato più pericoloso in una chiamata che in chat:

1. **Nessuna citazione visibile.** Nel testo, una risposta sbagliata accanto a una fonte linkata invita l'utente a cliccare e a correggersi da solo. Nella voce, la sicurezza del modello *è* l'interfaccia. Una frase fluida e sbagliata suona esattamente come una fluida e giusta.
2. **Tempo reale, un solo tentativo.** La chat permette di rileggere e ragionare. Chi chiama elabora il parlato in modo lineare e va avanti. L'errore viene assorbito prima che qualcuno possa segnalarlo.
3. **Gli impegni verbali sono responsabilità.** "Sì, può disdire gratuitamente entro 48 ore" è, di fatto, la tua policy: registrata, con marca temporale e con tutta l'aria di essere vincolante. I large language model sono addestrati a essere utili e fluenti, non a trattenersi. Al telefono quel comportamento predefinito è un problema legale.

Qui l'obiettivo del RAG non è "sembrare intelligente". È: **dire solo ciò che è recuperabile e rifiutare il resto ad alta voce.**

## Architettura RAG per un agente telefonico: retrieval dentro il budget di latenza

Il vincolo duro nella voce è la latenza di turno. Le persone percepiscono il silenzio oltre i ~800 ms e iniziano a parlare sopra l'agente oltre gli ~1,2 s. L'intero ciclo — ASR → retrieval → LLM → TTS — deve stare in un **budget di circa 1 secondo** per risultare naturale.

Una ripartizione di massima per un turno parlato:

| Fase | Budget |
|---|---|
| Finalizzazione ASR (fine del parlato) | ~150–300 ms |
| Retrieval (embedding della query + ricerca vettoriale + reranking) | **~150–250 ms** |
| Primo token dell'LLM | ~300–500 ms |
| Primo audio del TTS | ~150–300 ms |

Al retrieval spettano ~200 ms. Questo elimina i pattern ingenui che i bot testuali usano senza pensarci:

- **Niente retrieval multi-hop a metà turno.** Un solo passaggio di retrieval per turno. L'espansione della query si fa offline o in parallelo, mai in sequenza.
- **Pre-riscalda e metti in cache gli embedding.** Calcola in anticipo gli embedding della knowledge base; dal vivo si calcola solo quello della domanda di chi chiama.
- **Retrieval speculativo.** Lancia il retrieval sulla trascrizione ASR *parziale* prima della fine del parlato, poi conferma. Recuperi 100–200 ms.
- **Metti in streaming l'LLM verso il TTS.** Inizia a pronunciare la prima proposizione mentre i token successivi vengono generati. Il grounding, però, va risolto *prima* del primo token: una frase già pronunciata non si può ritirare.

## Fare grounding della risposta: chunking, reranking e citazione dei dati di account

Il grounding vocale ha due classi di dati con regole diverse.

**Conoscenza statica (policy, prezzi, FAQ).** Fai chunk piccoli — 200–400 token — perché le risposte parlate sono brevi e un contesto gonfio spinge il modello a sintetizzare fra più chunk (una fonte di allucinazione). Applica sempre il **reranking** al top-k; un reranker cross-encoder su 20 candidati → top 3 riduce in modo misurabile le risposte tratte dal chunk sbagliato. Dai al modello 2–3 chunk, non 10.

**Dati dinamici di account (stato ordine, saldo, appuntamento).** Questi non arrivano dalla ricerca vettoriale: sono una chiamata a funzione in tempo reale verso il tuo sistema di riferimento (via un webhook in stile `make integration for ai agents`, oppure un'API diretta). Regola: **il modello può pronunciare solo i valori dei campi presenti nella risposta del tool.** Se `order.status` manca, l'agente non può dedurre "probabilmente è già spedito". Struttura il prompt in modo che i dati di account arrivino come JSON tipizzato e istruisci il modello a citare i campi alla lettera.

Dato che in chiamata non puoi mostrare una fonte, la "citazione" diventa **provenienza nel prompt**: etichetta ogni chunk recuperato con il suo id di origine e fai in modo che il modello si condizioni internamente su "rispondi solo dai blocchi CHUNK_ID". Registri a log quale chunk ha prodotto la risposta parlata per l'audit: la citazione serve a *te*, non a chi chiama.

## Rifiuto ed escalation: "le passo un collega" batte tirare a indovinare

La mossa anti-allucinazione con più leva nella voce è un buon percorso di rifiuto. Se il retrieval non restituisce nulla sopra una soglia di confidenza, l'output corretto non è la migliore ipotesi: è l'escalation.

Progetta tre esiti espliciti per turno, non due:

- **Rispondere** — chunk fondati sopra soglia → pronuncia il fatto ancorato al contesto.
- **Chiarire** — query ambigua → fai una breve domanda e ripeti il retrieval.
- **Trasferire** — punteggio di retrieval basso, fuori ambito o frustrazione rilevata → "voglio darle un'informazione precisa, la metto in contatto con uno specialista" + [trasferimento assistito](/glossary/warm-transfer) con il contesto.

Aggancia la soglia al punteggio del reranker, non solo alla similarità vettoriale. E rendi il trasferimento poco costoso: una chiamata che si chiude con un passaggio pulito è un *successo*, non un fallimento. Indovinare per evitare un trasferimento è esattamente il modo in cui ti ritrovi la responsabilità registrata di cui parla la prima sezione.

## Pattern di prompt che riducono i fatti inventati in chiamata

I `rag prompts` vocali sono più severi di quelli per la chat perché non c'è una fonte visibile ad attutire una risposta sbagliata:

- **Divieto di rispondere a memoria.** "Non hai alcuna conoscenza al di fuori del blocco CONTEXT. Se la risposta non è nel CONTEXT, di' che verificherai oppure trasferisci." Dichiaralo e ripetilo verso la fine del [system prompt](/glossary/system-prompt) (la recency aiuta).
- **Regola della citazione letterale per i dati di account.** "Riporta numeri, date e stati esattamente come compaiono nel risultato del tool. Non stimare e non arrotondare mai."
- **Nessuna sintesi tra chunk per le policy.** "Rispondi partendo dal singolo chunk più pertinente. Non combinare due policy per crearne una nuova."
- **Tetto alla lunghezza parlata.** "Rispondi in una o due frasi che una persona possa seguire a orecchio." Le risposte lunghe divagano e inventano.
- **Verbo di incertezza esplicito.** Dai al modello una via d'uscita autorizzata — "le confermo subito" — così il rifiuto diventa un percorso di token disponibile e non uno stato di errore.

## Valutare l'output di un RAG parlato

Non puoi rilasciare un RAG vocale a sensazione. Costruisci un harness di valutazione offline sulle trascrizioni:

- **Faithfulness** — ogni affermazione della risposta discende dal contesto recuperato? Assegna un punteggio con un LLM giudice su coppie (contesto, risposta). Obiettivo >0,95.
- **Groundedness / pertinenza della risposta** — la risposta ha usato il chunk recuperato o lo ha ignorato andando a braccio?
- **Tasso di allucinazione** — % di risposte che contengono un'affermazione assente dal contesto. È la tua metrica guida: monitorala a ogni release come un error budget.
- **Precision/recall del rifiuto** — ha trasferito quando doveva e *non* ha trasferito quando aveva la risposta? Il rifiuto eccessivo affossa la customer experience; quello insufficiente è il rischio legale.
- **Hit@k del retrieval** — prima di dare la colpa all'LLM, verifica che il chunk giusto sia stato effettivamente recuperato. La maggior parte delle "allucinazioni" sono mancati recuperi.

Esegui il tutto su un golden set di trascrizioni di chiamate reali a ogni deploy. Aggiungi ogni allucinazione osservata in produzione al set come test di regressione.

## Build o buy: cosa gestisce Finn e cosa comporta il fai-da-te

Costruire da soli il proprio stack RAG vocale significa farsi carico di: infrastruttura di retrieval sotto il secondo, reranking, streaming ASR/TTS, [barge-in](/glossary/barge-in), la macchina a stati di rifiuto/trasferimento, il trasferimento assistito e un harness di valutazione delle trascrizioni — e poi tenere tutto dentro il budget di latenza a ogni chiamata. Sono mesi di `ai agent development`, non un tutorial da weekend.

Finn porta il livello di grounding vocale già pronto: retrieval tarato sul budget del turno, function calling sui dati di account con grounding letterale sui campi, rifiuto e trasferimento assistito integrati e trascrizioni per singola chiamata che puoi mandare direttamente in valutazione. Tu porti la knowledge base e il sistema di riferimento; Finn mantiene fattuali le risposte parlate.

## Link interni
- `/blog/ai-voice-agent-vs-ivr-enterprise-guide` — dove finisce l'IVR deterministico e inizia la voice AI ancorata ai dati
- `/blog/how-to-manage-high-call-volumes-without-hiring-more-agents-2026` — l'economia della deflection che rende il grounding conveniente
- `/blog/ai-voice-agent-pricing-comparison-2026` — costo al minuto dello stack retrieval + LLM + TTS
- `/blog/blog-draft-your-help-desk-ends-at-the-ticket-where-voice-ai-closes-the-loop-2026-a9e2754c` — chiudere il cerchio dopo la chiamata

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

**D: Che cos'è il RAG in un agente vocale?**
R: La [Retrieval-Augmented Generation](/glossary/retrieval-augmented-generation) ancora la risposta parlata dell'agente alle tue policy, ai tuoi prezzi e ai dati di account recuperati al momento della chiamata, così pronuncia fatti presi dalla tua knowledge base invece delle ipotesi del modello.

**D: Come si prevengono le allucinazioni dell'LLM durante una telefonata?**
R: Recupera e applica il reranking prima di rispondere, istruisci il modello a parlare solo dal contesto recuperato, cita alla lettera i campi dell'account e passa a un operatore umano quando la confidenza del retrieval è bassa.

**D: Quanta latenza aggiunge il RAG a un turno vocale?**
R: Prevedi ~150–250 ms per il retrieval dentro un turno complessivo di circa 1 secondo. Pre-riscalda gli embedding, esegui un solo passaggio di retrieval, applica il reranking a un piccolo insieme di candidati e avvia il retrieval sull'ASR parziale per restare nel budget.

**D: Come si misura l'allucinazione nelle risposte parlate?**
R: Valuta le trascrizioni per faithfulness e groundedness con un LLM giudice, monitora il tasso di allucinazione come un error budget e misura precision/recall del rifiuto più l'hit@k del retrieval su un golden set a ogni release.

Vuoi risposte vocali fattuali senza costruire da zero lo stack di retrieval, rifiuto e valutazione? **Scopri come Finn ancora ogni chiamata ai tuoi dati: prenota una demo su hirefinn.ai.**