RAG non ti sta deludendo. Sei tu che deludi RAG.
Due mesi fa qualcuno mi ha inviato il suo “assistente AI potenziato da RAG” e mi ha chiesto perché continuasse a allucinare.
Mi ha raccontato con orgoglio di aver utilizzato “embeddings all’avanguardia” e “un potente database vettoriale”.
Si è scoperto che stava dividendo PDF di 40 pagine in pezzi di 200 caratteri e memorizzandoli senza metadati.
Il recupero era fondamentalmente una roulette con passaggi aggiuntivi.
Questo succede spesso. Le persone considerano RAG come una casella di controllo: “Sì, abbiamo aggiunto RAG così non allucinerà.”
Ma non funziona così. La generazione aumentata dal recupero non è una soluzione magica.
È una pipeline molto esigente che punisce la pigrizia in ogni passaggio: ingestione, recupero e richiesta.
Costruisco sistemi agenti tutto il giorno e ti dirò la stessa cosa che dico ai team di prodotto:
se il tuo recupero è scadente, il tuo “agente” è solo un costoso completamento automatico con vibe.
Cos’è realmente RAG (non la versione LinkedIn)
RAG è semplice sulla carta:
- Memorizzi i tuoi dati da qualche parte (di solito un DB vettoriale).
- Incastri le query degli utenti e i documenti in vettori.
- Recuperi le informazioni più vicine e le fornisci al modello.
Questo è tutto. Il trucco è: “Fornisci al modello un contesto rilevante nel momento giusto.”
Il problema è che ognuna di quelle parole nasconde un disastro:
- “Rilevante” – dipende dal tuo compito, dall’utente e dal livello di dettaglio.
- “Contesto” – in quale formato, quanto, quali metadati, quale fonte?
- “Momento giusto” – recuperi una volta, più volte o in un ciclo?
Quindi quando qualcuno mi dice “abbiamo costruito RAG con Pinecone e OpenAI,” è come dire
“abbiamo costruito un’auto con metallo e benzina.” Cool. Fa girare? Si ferma? Esplode?
I tre luoghi in cui le persone di solito rovinano RAG
Esaminiamo le ferite autoflitte più comuni che vedo quando debuggo i sistemi di altre persone.
1. Frammentazione come un maniacale
Se i tuoi frammenti sono sbagliati, tutto ciò che segue ne soffre. La maggior parte delle persone:
- Fa pezzi troppo piccoli: il modello vede frammenti senza contesto, oppure
- Fa pezzi troppo grandi: memorizzi metà di un capitolo e poi non riesci a inserirli tutti nel contesto
Ho recentemente visto un team dividere un documento di policy di 120 pagine in pezzi fissi di 256 token.
Nessuna sovrapposizione, nessun rispetto per i titoli, nulla. Quando abbiamo registrato il recupero per la query:
“Qual è la nostra politica di rimborso per i contratti annuali aziendali?” abbiamo ottenuto:
- Un frammento con “rimborsi” ma per conti consumatori
- Un altro frammento su “contratti aziendali” ma in una sezione diversa
- Niente che descrivesse effettivamente l’intersezione di questi due
Così il modello li ha uniti e ha inventato con sicurezza una politica ibrida che non esisteva.
Quella non è “allucinazione”. Sei tu che gli stai fornendo pezzi di puzzle non corrispondenti.
Miglior modello:
- Fraziona per struttura quando possibile: sezioni, intestazioni, gruppi di elenco.
- Aggiungi sovrapposizione (come 10–20%) in modo che i confini non diventino significato a metà.
- Memorizza i metadati: titolo della sezione, tipo di documento, data, versione, fonte.
Strumenti come langchain-text-splitters o llama-index possono aiutare, ma non penseranno per te.
Devi comunque decidere che cos’è un “unità di significato” nel tuo dominio.
2. “Usa semplicemente embeddings” come strategia di recupero
Un altro preferito: le persone infila tutto in un DB vettoriale e dicono che è fatto.
Niente filtri. Nessun backup di parole chiave. Nessun riordino. Poi si lamentano che le embeddings “non funzionano per il codice”
o “non funzionano per i ticket di supporto”.
Ho lavorato su un assistente di supporto dove abbiamo testato diverse configurazioni su 500 ticket reali di Zendesk.
Il recupero solo con embeddings (OpenAI text-embedding-3-large, top-k=5) ci ha dato l’articolo giusto nei primi 5 circa 62% delle volte.
Aggiungere una semplice ricerca basata su termini (BM25) e poi riordinare con un cross-encoder ha fatto salire la percentuale a 84%.
Stesso contenuto. Stesso modello. Solo una logica di recupero migliore.
Non hai bisogno di uno stack fancioso per fare questo:
- Usa un indice ibrido (la maggior parte dei moderni backend di ricerca supportano questo: Elastic, OpenSearch, Vespa, ecc.).
- Filtra prima per metadati: prodotto, versione, lingua.
- Riordina i tuoi primi 20–50 candidati con un cross-encoder o un passaggio “scegli i top 5” con un LLM.
E per l’amore di tutto ciò che è sensato, registra le tue query e i documenti recuperati.
Non limitarti a fissare qualche punteggio di rilevanza aggregato. Guarda esempi reali in cui fallisce.
3. Richieste come se il modello fosse psichico
La tua richiesta è parte del sistema RAG. Se il modello non capisce come usare il contesto,
ignorerà felicemente tutto e inventerà delle cose.
Buone richieste RAG fanno alcune cose noiose ma critiche:
- Spiegano che cos’è il contesto e da dove proviene.
- Dicono al modello di citare o fare riferimento a elementi nel contesto, non al suo training.
- Definiscono cosa fare quando la risposta non è nel contesto (dire “Non lo so”).
- Forniscono regole di formattazione esplicite (come schemi JSON o punti elenco).
Ecco una versione semplificata di un prompt di sistema che abbiamo inviato in produzione a gennaio 2025 per un chatbot di conformità:
- “Rispondi alle domande solo usando i documenti forniti.”
- “Se non puoi rispondere utilizzando questi, dì che non lo sai e suggerisci quale documento potrebbe aiutare.”
- “Cita sempre il titolo del documento e l’ID della sezione tra parentesi.”
Questo singolo cambiamento ha ridotto le risposte “nonsense sicure” di circa 40% nelle nostre valutazioni manuali.
Stesso stack di recupero. Solo migliori istruzioni.
RAG più agenti: dove diventa divertente e fragile
Gli agenti rendono tutto più interessante perché ora non stai solo rispondendo a una domanda.
Stai orchestrando più passaggi: cercare, leggere, decidere, agire, forse cercare di nuovo.
Le persone continuano a collegare strumenti come:
- Strumento 1: “search_kb(query) → top 5 docs”
- Strumento 2: “call_api(payload) → result”
…e poi si aspettano che l’agente sappia magicamente quando cercare di nuovo o affinare la query.
Spoiler: non lo fa. Segue semplicemente dei modelli.
Due semplici correzioni migliorano notevolmente le configurazioni agente + RAG:
- Esporre l’incertezza. Lascia che l’agente veda i punteggi di recupero, non solo il testo grezzo.
- Fornisci uno strumento “refine_search”. Uno strumento il cui scopo è letteralmente: “riscrivi la query se i risultati non sono buoni.”
Quando abbiamo aggiunto entrambi in un sistema assistente CRM alla fine del 2024, il successo delle attività su query multi-hop
(come “Trova tutti i conti in cui abbiamo violato il SLA negli ultimi 90 giorni e riassumi i modelli”)
è passato da 47% a 71%. Stesso modello. Stessi documenti. Migliori strumenti per l’agente intorno a RAG.
Smetti di indovinare. Inizia a valutare.
La differenza numero uno tra i team che fanno funzionare RAG e i team che non lo fanno è noiosa:
i buoni team valutano. Costantemente.
Al minimo dovresti voler:
-
Valutazioni di recupero: Per un insieme di query, abbiamo recuperato qualcosa che contiene davvero la risposta?
Annota 50–100 esempi a mano. Sì, a mano. Stai costruendo un sistema, non vibrazioni. -
Valutazioni della qualità della risposta: La risposta finale è corretta, radicata nel contesto e completa?
Puoi usare un altro modello come giudice, ma controlla con gli esseri umani. - Controlli delle allucinazioni: La risposta includeva affermazioni non supportate dal contesto?
Non inseguire il “perfetto”. Insegui “sappiamo esattamente come e dove fallisce.”
Una volta che hai quello, correggere RAG diventa lavoro di ingegneria invece di stregoneria.
FAQ
Quanti frammenti dovrei recuperare per ogni query?
Inizia con 5–10 e misura. Se i tuoi frammenti sono più piccoli (come 200–400 token), puoi andare più in alto.
Fai attenzione alla tua finestra di contesto: vuoi spazio per le istruzioni e la query dell’utente, non solo un muro di testo recuperato.
Quale modello di embedding e DB vettoriale dovrei usare?
Usa prima qualcosa di noioso e ben supportato. L’text-embedding-3-small di OpenAI o
l’embed-english-v3.0 di Cohere vanno bene per la maggior parte delle applicazioni.
Per l’archiviazione, qualsiasi cosa che possa fare filtri vettoriali + metadati + ricerca ibrida (Elastic, Weaviate, Qdrant, ecc.) è sufficiente.
La tua logica di recupero conta molto di più del logo sulla scatola.
Posso saltare RAG e semplicemente affinare il modello sui miei documenti?
Puoi, ma per la maggior parte dei casi aziendali è uno scambio sbagliato. L’affinamento è statico e difficile da aggiornare.
RAG ti consente di cambiare le risposte aggiornando i documenti, non i pesi.
Raccomando l’affinamento solo per stile, formattazione o quando il tuo dominio è estremamente di nicchia e relativamente stabile.
🕒 Published: