RAG — Retrieval-Augmented Generation: Come Dare Memoria ai LLM

Cos'è: Patrick Lewis, Ethan Perez e colleghi di Facebook AI Research pubblicano a maggio 2020 il paper che formalizza il Retrieval-Augmented Generation. L'idea: invece di memorizzare tutta la conoscenza nei pesi del modello, si recuperano documenti rilevanti al momento dell'inferenza e li si inietta nel contesto. Diventato il pattern enterprise numero uno per deployare LLM su dati aziendali senza riaddestrare nulla.

Il problema fondamentale dei LLM

Un large language model apprende conoscenza dal corpus di training e la cristallizza nei propri pesi. Una volta completato il training, quella conoscenza è congelata. Se chiedi a GPT-4 di eventi accaduti dopo il suo cutoff, non sa rispondere — o peggio, inventa. Se chiedi informazioni sui tuoi documenti interni aziendali, non li ha mai visti.

Le soluzioni pre-RAG erano due: ri-addestrare periodicamente il modello (costosissimo), oppure includere tutto il testo rilevante nel prompt (limitato dalla context window, lento, inefficiente). RAG è la terza via.

L'architettura RAG di base

Il flusso RAG si divide in due fasi distinte: indicizzazione offline e retrieval + generazione a runtime.

Fase 1 — Indicizzazione: i documenti del corpus (PDF, pagine web, database, ticket di supporto, documentazione tecnica) vengono segmentati in chunk da 256–1024 token. Ogni chunk viene trasformato in un vettore ad alta dimensione tramite un modello di embedding (come text-embedding-ada-002 di OpenAI, o modelli open come BGE, E5). I vettori vengono salvati in un vector store ottimizzato per la ricerca per similarità.

Fase 2 — Retrieval e generazione: quando arriva una query dell'utente, anche quella viene convertita in vettore con lo stesso modello di embedding. Si calcola la similarità coseno tra il vettore della query e tutti i vettori nel database. Si recuperano i top-k chunk più simili (tipicamente 3–10). Questi chunk vengono inseriti nel prompt insieme alla domanda originale. Il LLM risponde basandosi sia sulla sua conoscenza parametrica sia sui documenti recuperati.

Vector store: le opzioni principali

La scelta del vector store impatta performance e scalabilità:

• Pinecone: managed cloud, zero infrastruttura, ottimo per startup. Scala a miliardi di vettori.
• Chroma: open source, gira in locale o come server, ideale per prototipazione e progetti piccoli.
• pgvector: estensione PostgreSQL. Se hai già Postgres, aggiungi la dimensione vettoriale senza un secondo sistema.
• Weaviate: open source con ricerca ibrida integrata (vettori + keyword), GraphQL API.
• Qdrant: scritto in Rust, performance eccellente, supporto payload filtering avanzato.
• FAISS (Meta): libreria C++ per similarità velocissima, usata direttamente in codice Python quando non serve persistenza.

Naive RAG, Advanced RAG, Modular RAG

La ricerca ha evoluto il pattern originale in varianti più sofisticate:

Naive RAG: il flusso descritto sopra. Funziona, ma soffre di tre problemi tipici: chunk recuperati irrilevanti (precision bassa), chunk rilevanti non recuperati (recall bassa), risposta incoerente quando i chunk si contraddicono.

Advanced RAG: aggiunge passaggi prima e dopo il retrieval. Pre-retrieval: query rewriting (riformulare la domanda per migliorare il match), HyDE (Hypothetical Document Embeddings — genera un documento ipotetico che risponderebbe alla domanda, poi cerca quello). Post-retrieval: re-ranking con un cross-encoder (riordina i chunk per pertinenza reale), compressione contestuale (estrae solo le frasi rilevanti dai chunk), fusion di risultati da query multiple.

Modular RAG: decomposizione ulteriore in moduli intercambiabili — routing (quale knowledge base interrogare?), scheduling (quante round di retrieval fare?), fusion di fonti eterogenee. Architettura adatta a sistemi di produzione complessi.

Hybrid search: vettori + keyword

La ricerca puramente vettoriale ha un tallone d'Achille: i nomi propri, i codici prodotto, i termini tecnici specifici. Se cerchi "errore NX-4402-B", un embedding potrebbe trovare documenti semanticamente simili ma non quelli che contengono esattamente quella stringa. La ricerca ibrida combina similarità vettoriale (BM25 o Elasticsearch per il lexical match) con la ricerca semantica via embedding, fondendo i risultati con algoritmi come Reciprocal Rank Fusion. Nella pratica aziendale, hybrid search supera quasi sempre la ricerca solo vettoriale.

Perché RAG è il pattern enterprise #1

Tre vantaggi strutturali spiegano l'adozione massiva:

• No re-training: i documenti si aggiornano senza toccare il modello. Aggiungi un nuovo manuale al vector store e il sistema risponde subito su quei contenuti.
• Riduczione delle allucinazioni sul dominio: il modello ha accesso al testo originale durante la generazione. Può citare fonti, le risposte sono ancorate a documenti verificabili.
• Costo: fine-tuning completo di un modello grande costa decine di migliaia di euro e richiede expertise specializzata. RAG richiede un vector store e un modello di embedding — accessibile anche a team piccoli.

I limiti reali di RAG

RAG non è la soluzione a tutto. I problemi principali:

• Context window: puoi iniettare solo un numero limitato di chunk. Per documenti lunghi o domande che richiedono sintesi su tutto il corpus, il retrieval non è sufficiente.
• Qualità del chunking: chunk troppo piccoli perdono contesto, chunk troppo grandi diluiscono il segnale. La strategia di chunking (dimensione, overlap, chunk semantici vs. fissi) ha impatto enorme sulle performance.
• Retrieval precision: se il retriever recupera chunk sbagliati, il LLM risponde su basi errate con sicurezza — peggio che non rispondere.
• Latenza: il retrieval aggiunge round-trip. Per applicazioni real-time può essere un problema.
• Conoscenza implicita: RAG funziona su documenti espliciti. La conoscenza tacita non scritta — le best practice non documentate, i "si fa così" aziendali — non è recuperabile.

RAG vs. Fine-tuning: quando usare quale

La domanda pratica più frequente. La risposta dipende dal tipo di conoscenza:

• Usa RAG quando la conoscenza è fattuale, aggiornabile, tracciabile a documenti specifici. Chatbot su knowledge base aziendale, supporto tecnico su documentazione, Q&A su database normativo.
• Usa fine-tuning quando vuoi modificare il comportamento, il tono, il formato delle risposte. Adattare il modello a uno stile di scrittura aziendale, a un dominio tecnico con terminologia molto specializzata non presente nel training set, a task strutturati (estrazione entità in formato specifico).
• Combina entrambi nei casi più sofisticati: fine-tuning per stile e comportamento, RAG per conoscenza aggiornata.

L'ecosistema nel 2024

LangChain e LlamaIndex sono i framework Python di riferimento per costruire pipeline RAG, con astrazioni per ogni componente. LangChain Expression Language (LCEL) permette di comporre retriever, prompt e modelli in pipeline dichiarative. LlamaIndex si è specializzato ulteriormente nel data ingestion e nelle query complesse su strutture dati eterogenee. Sul lato managed, tutti i cloud provider (Azure AI Search, AWS Bedrock Knowledge Bases, Google Vertex AI Search) offrono RAG as-a-service.

---