Cos'è il RAG e quando serve davvero in un progetto di intelligenza artificiale
Il RAG è una tecnica che dà a un modello linguistico i documenti da leggere nel momento in cui riceve la domanda, invece di contare su quello che il modello ha memorizzato durante l'addestramento. La sigla sta per retrieval augmented generation. Chi si chiede cos'è il RAG di solito ci arriva da un problema molto concreto: un assistente che risponde bene sulle cose del mondo e male sui documenti di casa propria.
Il nome esce dal paper Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, pubblicato il 22 maggio 2020 da Patrick Lewis insieme ad altri undici autori. L'abstract descrive modelli che mettono insieme "pre-trained parametric and non-parametric memory for language generation": la memoria parametrica è il modello addestrato, mentre quella non parametrica, nel paper, è "a dense vector index of Wikipedia, accessed with a pre-trained neural retriever". Sei anni dopo la parte interessante resta la seconda, ed è anche l'unica su cui si può davvero mettere le mani senza riaddestrare niente. Se il dubbio è se convenga invece intervenire sul modello, ho scritto a parte quando il fine tuning di un modello serve davvero.
Come funziona il RAG, dalla domanda alla risposta
Un sistema RAG lavora in tre passaggi, e conviene tenerli distinti perché falliscono in modi diversi.
| Passaggio | Cosa succede | Cosa lo fa fallire |
|---|---|---|
| Recupero | il sistema cerca nei documenti i pezzi più pertinenti alla domanda | i pezzi recuperati non contengono la risposta |
| Aggiunta | i pezzi recuperati vengono inseriti nella richiesta insieme alla domanda | i pezzi entrano senza il contesto del documento da cui vengono |
| Generazione | il modello scrive la risposta leggendo quei pezzi | il modello legge il pezzo giusto e lo riassume male |
I primi due passaggi avvengono prima che il modello veda qualcosa, e sono codice normale: una ricerca e una concatenazione di testo. La guida di Anthropic al contextual retrieval descrive la preparazione del materiale come una divisione del corpus in pezzi "usually no more than a few hundred tokens", cioè poche centinaia di token l'uno. Un sistema RAG di per sé non è un agente, perché non decide niente e non compie azioni: recupera testo e lo passa avanti.
Quando il RAG non serve, e la soglia è già scritta
Sotto i 200.000 token di materiale il RAG non serve, e la soglia non è una stima di parte. La scrive Anthropic nella guida al contextual retrieval pubblicata il 19 settembre 2024: "If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt that you give the model, with no need for RAG or similar methods". Cinquecento pagine sono tante più di quante ne abbia in ballo un progetto medio al primo mese.
Il controllo si fa prima di scegliere qualunque database, e costa cinque minuti: si mettono tutti i documenti in una cartella e si guarda quanto pesa. Se il materiale è fatto di PDF, prima ancora va guardato se il testo si estrae in modo pulito, perché un indice costruito su testo sporco recupera pezzi sporchi, e su questo ho messo giù i passaggi in estrarre dati dai PDF aziendali. La domanda giusta da farsi al primo giorno non è quale database vettoriale usare, è se serve un indice.
Dove si rompe davvero un sistema RAG
Un sistema RAG che risponde male quasi sempre ha recuperato i pezzi sbagliati, non li ha scritti male. Anthropic ha misurato quanto pesa quella parte, riportando il tasso di fallimento del recupero sui primi venti pezzi in quattro configurazioni.
| Configurazione | Errore di recupero sui primi 20 pezzi |
|---|---|
| ricerca di base | 5,7% |
| più contesto aggiunto ai pezzi | 3,7% |
| più BM25 contestuale | 2,9% |
| più riordino dei risultati | 1,9% |
Anthropic descrive quei salti come una riduzione del tasso di fallimento del 35% con i soli contextual embeddings, del 49% aggiungendo il BM25 contestuale e del 67% con il riordino finale. Nessuna delle quattro righe cambia il modello che genera la risposta. È il motivo per cui trovo sbagliata la domanda con cui parte quasi ogni progetto, cioè quale modello usare: a parità di modello, il recupero fa tre volte meglio o tre volte peggio.
La ricetta di Anthropic, e quanto costa
La parte replicabile di quella guida sta in quattro scelte concrete. I pezzi restano di poche centinaia di token. Al modello se ne passano venti e non cinque: Anthropic scrive di aver provato "5, 10, and 20 chunks" e di aver trovato che venti è la configurazione più performante. Alla ricerca vettoriale si affianca BM25, che pesca sulle corrispondenze esatte di termine e recupera i casi in cui la somiglianza semantica sbaglia. Sugli embedding la guida dice che "Voyage and Gemini have the best embeddings of the ones we tested".
Il costo dichiarato per aggiungere il contesto ai pezzi è di 1,02 dollari per milione di token di documenti, una volta sola, e quel numero regge grazie al prompt caching: il documento si carica in cache una volta e i pezzi successivi lo riusano.
Cos'è il RAG rispetto a un'AI che legge i file da sola
Il RAG decide cosa il modello vedrà prima che il modello parta, mentre un agente che esplora i file decide mentre lavora. Sono due modelli di accesso diversi, e il secondo si è fatto strada perché è ispezionabile: quando la risposta è sbagliata si apre la cartella e si guarda, invece di interrogare una somiglianza fra vettori che nessuno può leggere.
Questo sito è un esempio della seconda strada, e non per scelta ideologica. Le misurazioni di ricerca stanno in data/seo/ come otto file JSON per circa 540 KB in tutto, le regole di scrittura stanno in .claude/skills/articolo/ divise in cinque file caricati solo quando servono, e i 66 articoli pubblicati stanno in content/blog/ come file di testo che si cercano con grep. Nessun indice, nessun database vettoriale, e finché quel materiale resta leggibile da una persona non ce n'è motivo. Sulla soglia oltre la quale una cartella scritta a mano smette di reggere ho scritto in memoria di un agente AI, e sul costo in token dell'esplorazione libera in come ridurre i token di un agente di coding.
Da cosa si parte quando il materiale non ci sta
La regola pratica che uso quando qualcuno mi porta il problema è questa: si parte dal materiale, non dall'architettura. Se sta sotto le cinquecento pagine indicate da Anthropic, dentro ci va e l'indice non si costruisce. Se non ci sta, il lavoro vero è organizzarlo e misurare il recupero prima di scegliere il database, non dopo. È esattamente il punto da cui parto quando aiuto un'azienda a far leggere all'AI i propri dati aziendali.
Il RAG non è un prodotto e non è una fase del progetto: è l'impianto idraulico. Quando funziona non lo nota nessuno, e quando non funziona tutti danno la colpa al modello.
Domande frequenti
Che differenza c'è tra il RAG e un motore di ricerca interno?
Un motore di ricerca interno restituisce una lista di documenti a una persona, che poi li apre e li legge. Il RAG restituisce frammenti di testo a un modello, che scrive la risposta al posto della persona. Cambia anche il criterio con cui si giudica il risultato: un motore di ricerca lavora bene se la cosa giusta sta nelle prime posizioni che un umano scorre, un sistema RAG lavora bene se la risposta è contenuta nei pezzi che vengono passati al modello, perché quello che resta fuori per il modello non esiste.
Il RAG si può fare senza embedding vettoriali?
Sì, e nella pratica conviene non affidarsi solo a quelli. La ricetta pubblicata da Anthropic affianca agli embedding anche BM25, un algoritmo di ricerca lessicale che pesca sulle corrispondenze esatte dei termini, e riporta risultati migliori con i due metodi insieme che con la sola ricerca semantica. La ricerca lessicale recupera proprio i casi in cui la somiglianza di significato sbaglia, come un codice prodotto o un numero di articolo.
Il RAG risolve le allucinazioni?
Il RAG riduce le risposte inventate quando il recupero funziona, perché il modello ha davanti il testo giusto invece di ricostruirlo a memoria. Non le elimina: un modello può leggere il pezzo corretto e riassumerlo male, oppure può ricevere un pezzo sbagliato e usarlo con la stessa sicurezza. Un sistema RAG sposta il problema sul recupero, non lo cancella.
Come si capisce se un sistema di AI con RAG sta recuperando i pezzi giusti?
Si registrano i pezzi di testo recuperati per una ventina di domande vere e si leggono a mano, prima di guardare la risposta finale. Se i pezzi sono quelli giusti ma la risposta è sbagliata, il problema sta nelle istruzioni date al modello. Se i pezzi sono sbagliati, nessuna riscrittura del prompt sistemerà la risposta.