RAG: dare una memoria esterna ai modelli linguistici

Chiedete a un modello linguistico quanto costa l’abbonamento della vostra palestra, e vi risponderà con sicurezza qualcosa di plausibile e sbagliato. Non è colpa sua: quel dato non era nei testi su cui è stato addestrato, e un modello linguistico, davanti a una domanda, non consulta niente — completa. Genera la continuazione più probabile, e quando non sa, la probabilità produce invenzioni ben scritte. Il Retrieval-Augmented Generation, RAG per gli amici, nasce esattamente per questo: dare al modello qualcosa da consultare.

Tre problemi, una radice comune

I modelli linguistici arrivano sul mercato con tre difetti strutturali. Il primo è il knowledge cutoff: l’addestramento finisce a una certa data, e tutto quello che succede dopo semplicemente non esiste per il modello. Il secondo sono le allucinazioni: quando la risposta giusta non è nei parametri, il modello non dice «non lo so» ma produce la frase statisticamente più credibile — che può essere falsa con lo stesso tono con cui sarebbe vera. Il terzo sono i dati privati: i vostri contratti, il manuale interno, i ticket dei clienti non erano nel corpus di addestramento e non ci saranno mai.

La radice è unica: il modello sa solo ciò che ha compresso nei propri pesi durante l’addestramento. Riaddestrarlo ogni volta che cambia un listino è fuori discussione, per costi e tempi. Serve un’altra strada.

L’idea in una frase

Il RAG trasforma l’interrogazione da esame a memoria a esame a libro aperto. Invece di chiedere al modello di ricordare, gli si mette sotto gli occhi — dentro il prompt — i passaggi dei documenti pertinenti alla domanda, e gli si chiede di rispondere basandosi su quelli. Lo studente è lo stesso; è cambiata la regola d’esame.

Non chiedere al modello di ricordare: dagli il libro aperto sulla pagina giusta.

Tutta l’ingegneria del RAG serve a una cosa sola: aprire il libro sulla pagina giusta, automaticamente, per qualunque domanda.

La pipeline, pezzo per pezzo

Un sistema RAG ha due fasi: una preparazione fatta una volta (e aggiornata quando i documenti cambiano) e una catena che scatta a ogni domanda.

• Chunking — i documenti vengono tagliati in blocchi («chunk») di qualche centinaio di parole. Serve perché non si può dare in pasto al modello l’archivio intero, e perché il recupero funziona meglio su unità piccole e coese: idealmente un chunk contiene un concetto.
• Embedding — ogni chunk viene trasformato in un vettore, un punto in uno spazio geometrico dove testi che parlano di cose simili finiscono vicini. È lo stesso meccanismo della ricerca semantica.
• Vector store — i vettori finiscono in un database specializzato nel trovare rapidamente i punti più vicini a un punto dato, anche tra milioni.
• Retrieval — quando arriva una domanda, anche lei viene trasformata in vettore, e il database restituisce i chunk più vicini: i candidati «pagina giusta».
• Generazione con citazioni — i chunk recuperati vengono inseriti nel prompt insieme alla domanda, con un’istruzione del tipo: rispondi usando solo queste fonti, e cita da quale passaggio viene ogni affermazione. La citazione non è cosmesi: è ciò che permette a chi legge di verificare.

Le due fasi di un RAG: l’archivio viene indicizzato una volta sola; a ogni domanda, il retrieval pesca i passaggi pertinenti e li consegna al modello insieme alla domanda.

Dove i RAG si rompono davvero

Sulla carta è lineare; in produzione, i punti di rottura sono ricorrenti e quasi mai stanno nel modello.

Chunking sbagliato. Se il taglio spezza una tabella a metà, separa una clausola dalla sua eccezione o produce blocchi-minestrone con tre argomenti dentro, il recupero porterà al modello frammenti monchi. È l’equivalente di fotocopiare il libro perdendo metà delle righe: lo studente non può che arrangiarsi. La maggior parte dei RAG deludenti si cura qui, non cambiando LLM.

Retrieval fuori tema. La vicinanza semantica non è pertinenza. Una domanda sul «recesso del contratto 2024» può recuperare paragrafi sul recesso del contratto 2021, semanticamente quasi identici e fattualmente fuorvianti. Sinonimi aziendali, sigle, nomi propri e domande che richiedono di combinare più documenti mettono in crisi la ricerca per similarità; per questo i sistemi seri affiancano filtri sui metadati, ricerca per parole chiave e un secondo passaggio di riordino dei risultati.

Contesto ignorato. Anche con i passaggi giusti nel prompt, il modello può preferire la propria memoria interna, fondere due fonti che si contraddicono o pescare male quando il contesto è lungo e il passaggio decisivo è sepolto nel mezzo. Se le fonti dicono A e il modello risponde B, il problema non è più il recupero: è l’ultimo anello, e va misurato con test appositi, non a occhio.

Quando un RAG non vi serve

Onestà dovuta: il RAG è la risposta a un problema specifico — conoscenza esterna, mutevole o privata — non un obbligo architetturale.

• Se la conoscenza è generale e stabile (spiegare un concetto, tradurre, riscrivere), il modello da solo basta.
• Se i documenti sono pochi e corti — decine di pagine — conviene metterli interi nel contesto: le finestre attuali li reggono, e vi risparmiate l’intera pipeline.
• Se la domanda è analitica («quanti ordini sopra i 500 euro nel 2025?»), serve una query su un database, non una ricerca semantica: il RAG recupera passaggi, non fa i conti.
• Se volete cambiare lo stile o il comportamento del modello, quella è materia di fine-tuning, non di recupero.

Perché vi riguarda

Quasi ogni «chatta con i tuoi documenti» che incontrerete — nell’intranet aziendale, nel gestionale, nel servizio clienti — è un RAG, e la sua qualità dipende da scelte invisibili: come sono tagliati i documenti, come è organizzato l’indice, se le citazioni sono verificabili. Sapere che la pipeline esiste vi dà le domande giuste da fare prima di fidarvi: da dove viene questa risposta? Posso vedere la fonte? Cosa succede quando la fonte non c’è? Un RAG ben fatto risponde «non lo so» quando il libro non ha la pagina. Uno fatto male improvvisa — e lo fa con l’eloquenza di chi il libro non l’ha mai aperto.