RAG Techniques: una raccolta pratica da usare come laboratorio, non come ricettario
Il repository RAG Techniques raccoglie esempi di retrieval augmented generation. Come scegliere una tecnica, misurarla e non confondere una demo con una knowledge base affidabile.
Scritto da Daniel Vedovato · Revisionato il 21 luglio 2026
Articolo preparato con assistenza AI, verificato e revisionato da Daniel Vedovato.
Il retrieval è una catena di decisioni, non un interruttore
Il repository RAG Techniques raccoglie notebook ed esempi dedicati alla retrieval augmented generation. È utile a chi vuole esplorare varianti di RAG, ma va letto come un laboratorio: mostra possibili componenti e trade-off, non una configurazione universale da copiare in produzione.
Un sistema RAG affianca a un modello linguistico documenti recuperati al momento della domanda. L’idea di base è semplice, ma la qualità finale dipende da una catena: acquisizione dei file, pulizia, chunking, embedding, indice, query, reranking, prompt, citazioni e valutazione. Un errore all’inizio può essere mascherato da una risposta fluida del modello. Per questo il modo migliore di usare una raccolta di tecniche è formulare una domanda misurabile e cambiare un elemento alla volta.
La domanda più utile non è “quale RAG è il migliore?”. È “quale errore del mio recupero sto cercando di ridurre?”. Se un documento non entra mai nell’indice, un reranker non lo salverà. Se le fonti corrette arrivano nel contesto ma il modello le contraddice, il problema è nella generazione o nel prompt. Separare questi casi evita settimane di ottimizzazione casuale.
Tecniche diverse risolvono fallimenti diversi
Il chunking divide documenti lunghi in unità recuperabili. Chunk piccoli possono localizzare bene un fatto ma perdere il contesto; chunk grandi preservano la relazione fra paragrafi ma occupano più token e possono aumentare rumore. Non esiste una dimensione giusta senza conoscere il tipo di domanda e la struttura delle fonti.
Il retrieval ibrido combina segnali lessicali e semantici. Può essere utile quando nomi di prodotto, codici o riferimenti normativi devono essere trovati esattamente, mentre gli embedding aiutano per parafrasi. Il reranking rivaluta pochi candidati con un modello più costoso. Può migliorare la precisione, ma non sostituisce una buona copertura iniziale e aumenta latenza.
Query rewriting, multi-query retrieval e decomposizione della domanda cercano di recuperare materiale da più formulazioni. Sono potenti per domande complesse, ma introducono un rischio: una riformulazione errata può cambiare il significato della richiesta prima ancora che la ricerca inizi. In ambiti regolati è spesso meglio mostrare la query effettiva e mantenere un percorso di audit.
| Sintomo | Ipotesi da testare | Intervento possibile |
|---|---|---|
| La fonte giusta non appare | Indicizzazione o query insufficienti | Controllare chunk e recall top-k |
| Appaiono fonti plausibili ma sbagliate | Ranking poco preciso | Aggiungere filtro o reranker |
| La risposta ignora una fonte corretta | Contesto o istruzione debole | Ridurre rumore e imporre citazioni |
| Le citazioni non supportano l’output | Generazione non vincolata | Valutare fedeltà frase per frase |
La valutazione va costruita prima dell’ottimizzazione
Un progetto RAG serio crea un piccolo set di domande reali con risposte attese e fonti note. Le domande devono includere casi facili, sinonimi, documenti aggiornati, eccezioni e richieste a cui il sistema deve dire “non lo so”. Prima si misura il recupero: la fonte corretta compare fra i primi risultati? Poi si misura la risposta: è fedele, completa e citata? Mescolare le due misure rende difficile capire che cosa cambiare.
È utile conservare casi di fallimento. Se un aggiornamento migliora il punteggio medio ma fa sparire una procedura critica, il risultato non è pronto. Le valutazioni automatiche possono accelerare il confronto, ma devono essere campionate da una revisione umana: un giudice LLM può condividere lo stesso errore dell’assistente valutato.
Anche costo e latenza sono requisiti. Un sistema con tre query, due reranker e un modello grande può essere eccellente su venti domande offline e impraticabile in un servizio interattivo. Per ogni variante conviene registrare token, tempo p95, numero di documenti nel contesto e costo per risposta. Sono metriche di prodotto, non dettagli secondari.
Sicurezza, fonti e aggiornamenti
Una knowledge base può contenere istruzioni iniettate, informazioni personali e documenti obsoleti. Il retrieval non deve trasformare qualunque testo recuperato in comando. Il prompt deve distinguere dati e istruzioni, le fonti devono avere permessi e ogni risposta dovrebbe poter mostrare da quale versione del documento proviene. Se un contenuto viene rimosso, occorre sapere quando sparirà dall’indice e dalle cache.
Questi vincoli rendono il RAG meno spettacolare, ma più utile. L’obiettivo non è far sembrare il modello informato. È permettere a un utente di verificare una risposta e a un team di correggere la base informativa senza indovinare cosa sia accaduto.
Verdetto
RAG Techniques è una buona raccolta per esplorare componenti e costruire esperimenti controllati. Non va usata come lista di upgrade da accumulare. Il percorso efficace parte da una baseline, da domande con fonti attese e da metriche separate per retrieval e generazione. Solo dopo ha senso aggiungere tecniche più sofisticate, quando si può dire quale fallimento risolvono e quale costo introducono.