Perché il modello non è sempre responsabile
Quando un sistema di Retrieval Augmented Generation (RAG) restituisce una risposta sbagliata, l'istinto più comune è incolpare il modello di generazione. Nella pratica, però, il modello spesso non ha nemmeno la possibilità di produrre la risposta corretta perché l'informazione necessaria non è presente nel contesto che gli viene fornito.
Ho analizzato diversi progetti RAG che, dopo un prototipo promettente, si sono arenati. I team hanno speso settimane a testare modelli più grandi, a riscrivere i prompt e a modificare le impostazioni di temperatura, senza ottenere miglioramenti significativi. Quando abbiamo tracciato ciò che il sistema recuperava realmente, abbiamo scoperto che in più della metà dei fallimenti le informazioni corrette erano assenti dal contesto restituito. Un modello migliore non può rispondere a una domanda se non vede il testo pertinente.
Il recupero è il vero prodotto
In una pipeline RAG, il modello è l'ultimo passaggio. Prima che scriva una singola parola, il sistema ha già suddiviso i documenti in chunk, li ha trasformati in embedding, ha interrogato un indice e ha classificato i risultati. Ognuno di questi passaggi può, silenziosamente, eliminare il passaggio che contiene la risposta.
Per questo motivo il debugging deve iniziare dalla parte anteriore della pipeline. Se il passaggio corretto non è presente nel set recuperato, nessuna modifica al prompt potrà salvare la risposta. Se invece è presente ma classificato al decimo posto, il problema è la fase di ranking, non la generazione.
Il ruolo cruciale del chunking
Il chunking è il colpevole più comune. Chunk troppo piccoli perdono il contesto; chunk troppo grandi seppelliscono la frase utile nel rumore. Una tabella divisa in due chunk o un'intestazione separata dal suo paragrafo possono rendere un documento corretto irricercabile.
Disallineamento tra query e documento
Il secondo sospetto è il divario tra il modo in cui gli utenti formulano le domande e il modo in cui i documenti sono scritti. Gli utenti cercano con frasi brevi e informali, mentre la documentazione utilizza un linguaggio formale. Gli embedding aiutano, ma non colmano completamente questo gap. Tecniche di riscrittura della query e l'aggiunta di una ricerca ibrida basata su parole chiave spesso risolvono i casi che gli embedding da soli non colgono.
Un ordine di debug che fa risparmiare settimane
1. Loggare i chunk recuperati per ogni query, includendo i punteggi di rilevanza.
2. Per ogni risposta errata, chiedersi: “La risposta era presente nel corpus e è stata recuperata?” Questo semplice controllo suddivide la maggior parte dei fallimenti in tre categorie:
- Dati mancanti nel corpus.
- Recupero inefficace (ranking o mancata inclusione).
- Generazione errata (prompt o modello).
Solo dopo aver consolidato il recupero, si dovrebbe ottimizzare i prompt o cambiare modello. Spesso si scopre che il modello più economico funziona perfettamente una volta che riceve il contesto corretto.
Trattare il retrieval come un sistema autonomo
Costruire test specifici per il retrieval è fondamentale. Si può creare un piccolo set di domande reali con passaggi di origine noti e misurare la frequenza con cui il passaggio corretto appare tra i primi cinque risultati. Questo indicatore fornisce una valutazione più affidabile del sistema RAG rispetto a qualsiasi demo.
In sintesi, il successo di un progetto RAG dipende più dalla qualità del recupero dei documenti che dalla potenza del modello di generazione. Investire tempo nella configurazione di chunk adeguati, nella gestione del ranking e nella corrispondenza tra query e contenuto può ridurre drasticamente i fallimenti e ottimizzare i costi operativi.