Vai al contenuto
Book an audit
Capitolo 03 · 13 min

Il retrieval fatto bene

La generazione aumentata dal retrieval (RAG) è il pattern più utile e a minor rischio dell'IA applicata, e quello più spesso costruito male. La versione ingenua fa una bellissima figura in demo e fallisce in produzione per una manciata di motivi prevedibili. Questo capitolo presenta quei motivi e i loro rimedi.

“Non costringere il modello a memorizzare la biblioteca. Dagli le tre pagine di cui ha bisogno, aperte al paragrafo giusto.”

Cos'è davvero il RAG

Il RAG separa ciò che il sistema sa da ciò che il sistema dice. La conoscenza vive in un indice che controlli e puoi aggiornare ogni ora. Il modello fornisce solo il linguaggio e il ragionamento su qualunque cosa gli metti davanti. Quando arriva una domanda, cerchi nell'indice, recuperi i passaggi più pertinenti, e li metti nel prompt come contesto.

RAG: retrieval-augmented generation pipelineA pipeline from left to right: a user query is sent to a search system, which finds the most relevant chunks from a document store. Those chunks are added to the prompt and sent to the LLM, which produces an answer grounded in the retrieved context.userquerysearchvector + BM25top chunksfrom your docspromptquery + contextLLManswerINDEXthe model answers from context, not from memory
Il modello risponde a partire dai chunk recuperati, non dai suoi dati di addestramento. Aggiorni l'indice, mai il modello.

Questa è la risposta giusta a quasi tutti i problemi di "chatta con i nostri documenti", "assistente di supporto" o "base di conoscenza interna". È meno costosa del fine-tuning, aggiornabile in tempo reale, e soprattutto verificabile: puoi mostrare esattamente da quale fonte proviene la risposta.

La pipeline ingenua, e perché si rompe

La versione demo: dividi ogni documento in chunk fissi da 500 token, fai l'embedding di ciascuno, salva in un database vettoriale, fai l'embedding della query, prendi i cinque chunk più vicini, infilali nel prompt. Funziona su una FAQ ordinata e crolla su veri insiemi di documenti. Ecco dove:

  • Chunking errato: la risposta è suddivisa su due chunk, e nessuno dei due da solo è sufficiente.
  • Retrieval mancato: il passaggio pertinente non è tra i primi risultati perché la query e il documento usano parole diverse.
  • Modello di embedding sbagliato: il tuo dominio (legale, medico, gergo interno) non è ben rappresentato, quindi i vettori "simili" non lo sono davvero.
  • Contesto ignorato: il modello dispone del passaggio giusto ma risponde comunque a partire dai suoi dati di addestramento.
  • Indice obsoleto: il documento è cambiato; l'indice no.

Il pattern che funziona: ibrido + re-rank + citazioni

Tre aggiunte risolvono la maggior parte dei RAG in produzione. Primo, la ricerca ibrida: combina la similarità vettoriale con la ricerca per parole chiave vecchio stile (BM25). La ricerca vettoriale coglie il significato; la ricerca per parole chiave coglie i termini esatti (codici di errore, nomi, SKU) che i vettori sfumano. Esegui entrambe e fondi i risultati.

Secondo, il re-ranking. Recupera ampio (cinquanta candidati), poi assegna loro un punteggio con un re-ranker più preciso (e più costoso), e tieni solo i cinque migliori per il prompt. Ottieni il recall di una ricerca ampia con la precisione di una ricerca accurata.

Retrieve wide, then re-rank to a fewThree shrinking boxes from left to right: retrieve a wide net of 50 candidates, re-rank them with a more precise model, then keep only the top 5 to put in the prompt. Recall first, precision second.retrieve widetop 50re-rankcross-encoderkeep besttop 5
Getta una rete ampia per il recall, poi fai re-ranking per la precisione. Il modello vede solo i pochi passaggi più probabili a contenere la risposta.

Terzo, le citazioni. Fai citare al modello l'id del chunk che ha usato per ogni affermazione. Questo rende la risposta verificabile, ti permette di mostrare le fonti nell'interfaccia, e riduce in modo misurabile la deriva del modello rispetto al testo recuperato.

Quando il retrieval è lo strumento sbagliato

Il RAG risponde alle domande la cui risposta è scritta da qualche parte. Non aiuta con le domande che richiedono ragionamento su tutto il corpus ("quali sono i tre grandi temi di questi 10.000 ticket?"), né con il calcolo ("qual è il nostro tempo medio di risoluzione?"). Quelle richiedono aggregazione, analytics o tool (trattati nel prossimo capitolo), non retrieval.

Retrieval versus reasoningA 2-by-2 quadrant. The horizontal axis goes from retrieval-heavy to reasoning-heavy. The vertical axis goes from easy to hard. Tasks like "name a capital" and "summarise this article" sit in the easy retrieval corner; long-horizon planning sits in the hard reasoning corner.HARD ↑EASY← RETRIEVALREASONING →name a capitalsummarise this articlesolve this puzzlelong-horizon planwrite a function
Il retrieval brilla su "trova il passaggio che risponde a questo". Fatica non appena il compito si sposta verso il ragionamento su tutto in una volta.

Una riga per ciascuno

  • Il RAG separa ciò che il sistema sa (l'indice) da ciò che dice (il modello). Aggiorna l'indice, non il modello.
  • Il RAG ingenuo si rompe sul chunking, sui retrieval mancati, sugli embedding sbagliati, sul contesto ignorato e sui dati obsoleti, tutto invisibile senza eval.
  • Il pattern che funziona: ricerca ibrida + re-rank + citazioni.
  • Il RAG risponde a "trova il passaggio", non a "ragiona su tutto" o "calcola un numero"; quelli hanno bisogno di tool.

Dove andare ora

Il retrieval fatto bene · Corsi di IA · SDEN