Nei sistemi RAG si parla spesso del modello generativo: quale scegliere, quanto ragiona, quanto costa, quanto velocemente risponde. Ma in molti casi il vero collo di bottiglia è a monte. Se il sistema non recupera i documenti giusti, nel formato giusto e nell’ordine giusto, il modello produrrà risposte deboli anche se è eccellente.
È qui che emerge il limite di una visione troppo semplice del retrieval: la ricerca vettoriale da sola non basta. Gli embeddings sono potenti, ma non esauriscono il problema della rilevanza. Numeri, sigle, riferimenti normativi, metadati, aggiornamento temporale e struttura dei documenti possono richiedere strategie diverse.
In breve
- dense retrieval e ricerca lessicale catturano segnali diversi;
- BM25 resta molto forte quando contano termini esatti, codici e nomi propri;
- hybrid search combina segnali lessicali e semantici;
- reranking migliora l’ordine dei candidati recuperati;
- query rewriting, metadata filtering e RRF possono fare una grande differenza;
- retrieval e generazione vanno valutati separatamente.
Due idee diverse di ricerca
- La ricerca lessicale cerca corrispondenze tra parole e termini. Il riferimento classico è BM25.
- La ricerca semantica usa embeddings per cercare vicinanza di significato.
Le due strategie catturano aspetti differenti della rilevanza. La ricerca lessicale è eccellente quando contano parole esatte, sigle, numeri, nomi propri e formulazioni specifiche. La ricerca semantica è più forte quando la query e il documento parlano della stessa cosa con parole diverse.
BM25: un classico ancora molto competitivo
BM25 assegna un punteggio ai documenti tenendo conto della frequenza dei termini, della loro rarità nella collezione e della lunghezza del documento. In forma semplificata:
score(D,Q) = Σ IDF(q) · ((f(q,D)·(k1+1)) / (f(q,D)+k1·(1-b+b·|D|/avgdl)))
Il dettaglio matematico conta meno dell’intuizione: un termine raro e specifico pesa più di una parola comune, ma la frequenza non cresce linearmente all’infinito e la lunghezza del documento viene normalizzata.
In un archivio amministrativo, una query che contiene “DGR 1234/2025”, un codice progetto o un protocollo può essere servita meglio da BM25 che da una pura similarità semantica.
Dense retrieval: il significato oltre le parole
Nel dense retrieval, query e documenti vengono trasformati in vettori. La rilevanza viene stimata tramite vicinanza nello spazio vettoriale, spesso con similarità coseno:
sim(q,d) = (q · d) / (||q|| ||d||)
Il vantaggio è evidente: documenti semanticamente affini possono essere recuperati anche senza condividere le stesse parole. Ma la forza diventa anche un limite: dettagli lessicali fini possono perdersi, soprattutto con numeri, codici e differenze sottili tra termini simili.
Bi-encoder e cross-encoder: due livelli diversi di accuratezza
Nel dense retrieval classico si usa spesso un bi-encoder: query e documenti vengono codificati separatamente. Questo rende la ricerca molto veloce, perché i vettori dei documenti possono essere pre-calcolati.
Un cross-encoder, invece, valuta query e documento insieme. È più costoso, perché deve elaborare ogni coppia, ma può cogliere interazioni molto più precise tra i due testi. Per questo viene spesso usato come secondo stadio di reranking.
Hybrid search: unire parole e significato
Una strategia molto efficace consiste nel combinare segnali lessicali e semantici. In forma concettuale:
S(d|q) = α·S_sparse(d|q) + β·S_dense(d|q)
Il vantaggio è semplice: se una query contiene un codice preciso e una descrizione concettuale, possiamo usare entrambi i segnali invece di costringere un unico retriever a fare tutto.
Reciprocal Rank Fusion: combinare ranking diversi senza confrontare i punteggi
Un problema pratico dell’hybrid search è che i punteggi di BM25 e di un retriever vettoriale non sono necessariamente confrontabili. Una tecnica utile è la Reciprocal Rank Fusion, che combina le posizioni nei ranking invece dei punteggi grezzi.
In forma semplificata:
RRF(d) = Σ 1 / (k + rankᵢ(d))
Un documento che compare in buona posizione in più ranking tende a salire nella classifica finale, senza richiedere una calibrazione diretta dei punteggi.
Query rewriting: cercare meglio prima di cercare di più
Spesso il problema non è il retriever, ma la query. Le domande degli utenti possono essere lunghe, vaghe, contestuali o contenere riferimenti anaforici come “quello di prima”. Un sistema può quindi riscrivere la query in una forma più adatta alla ricerca.
Le strategie includono espansione con sinonimi, generazione di sotto-query, estrazione di termini chiave e trasformazione di una domanda conversazionale in una query autonoma.
Metadata filtering: la rilevanza non è solo semantica
Data, autore, versione, tipologia documentale, ente, progetto e stato possono essere decisivi. Se l’utente chiede la procedura attualmente vigente, recuperare la versione del 2022 semanticamente perfetta ma ormai superata è un fallimento.
I metadati permettono di filtrare prima del retrieval oppure di riordinare dopo. Nei sistemi aziendali questo livello è spesso più importante di quanto sembri.
Reranking: non basta trovare, bisogna riordinare
Dopo aver recuperato, per esempio, 50 candidati con BM25 e dense retrieval, un reranker più accurato può rivalutarli e selezionare i 5 o 10 documenti migliori. È un classico schema retrieve broadly, rank precisely.
Il reranking è spesso uno dei miglioramenti con il miglior rapporto qualità/costo in un sistema RAG, perché evita di inserire nel contesto documenti mediocremente rilevanti.
Chunking e struttura: il retriever non può recuperare ciò che avete distrutto
Se una clausola viene separata dalla sua eccezione durante il chunking, nessun algoritmo di ranking potrà ricostruire automaticamente il contesto originale. Lo stesso vale per tabelle, intestazioni, note e riferimenti incrociati.
Prima di ottimizzare embeddings e reranker conviene quindi verificare che la rappresentazione dei documenti sia sensata. Il retrieval eredita tutti gli errori commessi nella fase di ingestion.
Precision@k, Recall@k e MRR
- Precision@k: quota di documenti rilevanti nei primi k risultati;
- Recall@k: quota dei documenti rilevanti totali recuperati nei primi k;
- MRR: premia i sistemi che collocano il primo risultato rilevante molto in alto.
Queste metriche permettono di valutare il retrieval senza confonderlo con la qualità del generatore.
Valutare retrieval e generazione separatamente
Se la risposta finale è sbagliata, la prima domanda dovrebbe essere: il documento corretto era stato recuperato? Se la risposta è no, il problema è nel retrieval. Se sì, il problema può essere nella costruzione del contesto o nella generazione.
Mescolare tutto in una sola metrica rende difficile capire dove intervenire. Un buon sistema RAG dovrebbe quindi avere eval dedicate almeno a retrieval, groundedness e qualità finale della risposta.
Un esempio concreto
Immaginiamo una knowledge base con delibere, capitolati, verbali e manuali. L’utente chiede: “Qual è l’SLA previsto per gli interventi VIP nel servizio PDL?”.
Una ricerca vettoriale potrebbe recuperare documenti genericamente vicini al concetto di assistenza VIP. BM25 potrebbe invece valorizzare l’acronimo “SLA” e la stringa “VIP”. Un filtro per tipologia documentale può privilegiare il capitolato rispetto a un verbale. Il reranker può infine portare in cima il paragrafo che contiene esattamente il valore richiesto.
È questo il senso di un retrieval moderno: non scegliere una tecnica, ma orchestrare segnali diversi.
Dove le cose si complicano
Aumentare Recall@k recuperando più documenti può peggiorare la risposta se il contesto diventa rumoroso. Un reranker molto accurato può introdurre latenza. Filtri troppo rigidi possono escludere il documento corretto. Query rewriting troppo aggressivo può alterare l’intento dell’utente.
Il retrieval è quindi un problema multi-stadio e multi-obiettivo. Non esiste un singolo parametro “top-k” da ottimizzare una volta per tutte.
Una pipeline robusta
- analisi e riscrittura della query;
- filtri sui metadati;
- retrieval lessicale e semantico;
- fusione dei ranking;
- reranking;
- deduplicazione e diversificazione;
- costruzione del contesto;
- generazione con citazioni;
- evaluation separata di retrieval e risposta.
Un buon generatore senza buon retrieval risponde bene alle informazioni sbagliate. Un buon sistema RAG comincia sempre dalla qualità di ciò che trova.
Per approfondire
- Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze — Introduction to Information Retrieval.
- Dan Jurafsky, James H. Martin — Speech and Language Processing.
- Ricerca su DPR, ColBERT, hybrid search e cross-encoder reranking.
← Torna al percorso Dentro l’IA
Lascia un commento