Gli agenti RAG vogliono handoff di prove

Quando una semplice applicazione RAG sbaglia, il team di solito guarda il retriever, i chunk o il prompt. Quando sbaglia un workflow RAG agentico, il problema è meno visibile. La risposta può essere passata da pianificazione, più ricerche, note salvate, analisi delegate, sintesi e verifica finale. Se questi passaggi restano solo tool call interne, la risposta può sembrare solida anche quando la catena delle prove è fragile.

La tesi è semplice: gli agenti RAG hanno bisogno di handoff di prove, non di retrieval nascosta.

Non è un altro invito ad aumentare la finestra di contesto o a cambiare vector database. Queste scelte contano, ma non risolvono il problema operativo. Chi costruisce o gestisce il sistema deve sapere cosa ogni passaggio consegna al successivo, quale claim sostiene e cosa viene ricontrollato prima che la risposta arrivi all’utente. La documentazione RAG e deep agents di LangChain descrive workflow che pianificano, recuperano documenti, salvano chunk rilevanti, analizzano fonti, sintetizzano con riferimenti e verificano i gap invece di rispondere a memoria quando servono prove: documentazione RAG di LangChain. È una base corretta. Il passo successivo è rendere esplicito il trasferimento delle prove.

La retrieval non è un passaggio privato

In molti sistemi RAG, la retrieval è trattata come impianto interno. L’utente fa una domanda, il sistema recupera documenti, il modello risponde e il prodotto mostra solo il testo finale. Può bastare per un FAQ bot ristretto, con basso rischio e domande prevedibili. Non basta quando l’agente fa ricerca.

La RAG agentica non è un singolo evento di retrieval. È una catena di decisioni. L’agente può decidere quali sotto-domande porre, quale corpus interrogare, quali chunk salvare, quali passaggi confrontare e quali lacune meritano un’altra ricerca. Se queste decisioni sono invisibili, la risposta finale diventa difficile da contestare. Un reviewer non capisce se un’affermazione sbagliata nasce da una fonte debole, da una sintesi troppo aggressiva, da memoria non verificata o da una verifica saltata.

Per questo la retrieval deve lasciare un artefatto operativo. In RAG: contratti di retrieval, non finestre più grandi il punto è definire cosa la retrieval deve restituire, non solo quanto testo il modello può leggere. Gli handoff di prove estendono quel contratto lungo tutto il workflow agentico. La domanda diventa: una volta recuperato un chunk, cosa viene passato avanti, e per sostenere quale claim?

Cosa contiene un handoff di prove?

Un handoff di prove è un piccolo pacchetto di responsabilità tra passaggi dell’agente. Deve essere abbastanza compatto da poter essere loggato, ma abbastanza specifico da reggere un audit. Al minimo dovrebbe contenere sei elementi.

Primo, la domanda utente o la sotto-domanda. Il pacchetto deve mostrare cosa il passaggio di retrieval stava cercando di risolvere. Una query vaga come “prezzi” non basta se il claim finale riguarda l’idoneità al rimborso per clienti enterprise.

Secondo, la query o l’input del tool. Questo mostra come l’agente ha tradotto la domanda in azione. Due agenti possono ricevere la stessa richiesta e cercare cose molto diverse.

Terzo, la fonte recuperata e l’identificatore del chunk. Può essere un URL, un percorso documento, una chiave nel database, un intervallo di pagine, un timestamp o un localizzatore stabile controllato dal sistema. Non serve per abbellire la risposta con link. Serve per riaprire la fonte.

Quarto, l’evidenza estratta. Non bisogna passare avanti un intero documento se al passaggio successivo servono due frasi o una riga di tabella. Va salvato l’estratto rilevante, con contesto sufficiente a evitare interpretazioni forzate.

Quinto, il claim proposto. È la frase che il passaggio successivo può usare. L’handoff deve distinguere prova e interpretazione. “La policy dice X” non è la stessa cosa di “il cliente ha diritto a Y”.

Sesto, confidenza e gap aperto. L’agente deve dire cosa resta incerto. Quel gap può attivare un’altra ricerca, una revisione umana o un rifiuto della risposta.

Dove deve avvenire la verifica?

La verifica non dovrebbe essere un rito alla fine del processo. Dovrebbe avvenire ogni volta che un claim supera un confine.

Un pattern utile è retrieval, handoff, sintesi, verifica, poi risposta. La retrieval trova materiale. L’handoff impacchetta le prove a livello di claim. La sintesi combina i claim. La verifica chiede se ogni claim nella bozza può essere ricondotto a un pacchetto. Se un claim non ha pacchetto, viene rimosso, riscritto come incertezza o rimandato alla retrieval.

Qui l’osservabilità degli agenti diventa concreta. In L’osservabilità degli agenti AI vuole contratti la traccia non è solo un log di debug. È un contratto su cosa deve essere visibile quando un agente agisce. Gli handoff di prove danno a quella traccia uno standard di contenuto. Invece di leggere una lunga sequenza di tool call, l’operatore ispeziona pacchetti di claim.

La verifica deve porre domande precise. Quali claim compaiono nella risposta finale? Quale pacchetto sostiene ogni claim? La fonte era ammessa per questo tipo di task? L’evidenza è stata recuperata in questa esecuzione o arriva da memoria precedente? La sintesi ha tratto una conclusione più forte di quanto le prove permettano? L’agente ha dichiarato l’incertezza o l’ha nascosta dietro una prosa fluida?

Come si audita una risposta RAG?

Parti da una risposta reale, non da una riprogettazione della piattaforma. Copia la risposta in una tabella. Spezzala in claim atomici. Una frase può contenere più claim, quindi conviene dividere con severità. Poi aggiungi quattro colonne: pacchetto di prove, localizzatore della fonte, esito della verifica e azione.

Per ogni claim chiedi se un reviewer può riaprire la fonte e capire perché il sistema ha scritto quella frase. Se la fonte esiste ma il legame con il claim è implicito, segna giallo. Se la fonte non esiste, segna rosso. Se l’evidenza sostiene una versione più debole del claim, riscrivi la risposta. Se l’evidenza contraddice il claim, trattalo come una classe di errore, non come un’allucinazione casuale.

Questo audit di solito mostra pattern ricorrenti. Il retriever ha trovato il documento giusto, ma la sintesi ha generalizzato troppo. L’agente ha salvato un chunk utile, ma ha perso la data del documento. Un subagente ha prodotto un buon riassunto, ma non ha allegato il localizzatore originale. La verifica finale ha controllato tono e completezza, ma non provenienza. Non sono difetti di personalità del modello. Sono difetti di handoff.

La soluzione migliore non è allungare tutte le risposte. È rendere ogni claim più responsabile. L’utente può vedere solo un paragrafo pulito e poche citazioni. Gli operatori devono vedere la catena di pacchetti dietro quel paragrafo.

Porta l’handoff dentro il prodotto

Gli handoff di prove non servono solo quando qualcosa va storto. Migliorano il modello operativo dell’intero sistema.

Un team di supporto può usarli per spiegare perché una risposta è stata rifiutata. Un reviewer compliance può campionare claim ad alto rischio senza leggere ogni traccia grezza. Un product manager può vedere quali documenti generano incertezza in modo ricorrente. Un engineer può confrontare esecuzioni diverse e capire se una modifica ha migliorato retrieval, sintesi o verifica. Un esperto di dominio può correggere l’interpretazione della fonte invece di discutere con la formulazione finale del modello.

Questo crea anche un confine più sano tra automazione e giudizio umano. L’agente recupera, impacchetta, confronta e redige. La persona ispeziona i pacchetti quando il rischio lo richiede. Il sistema non finge che linguaggio fluido significhi prova.

La call to action è piccola: audita una risposta agentica questa settimana. Traccia ogni claim fino al chunk recuperato. Se non riesci a farlo, il problema non è solo qualità della retrieval. Il problema è che il tuo agente RAG passa avanti conclusioni senza handoff di prove.