Perché un sistema RAG può rispondere male anche con un ottimo LLM

Puoi utilizzare uno degli LLM più avanzati disponibili e continuare a ottenere risposte mediocri.

Quando succede, è naturale concentrare l’attenzione sul modello: proviamo un modello più potente, cambiamo provider, aumentiamo il context window oppure interveniamo sul prompt.

In un sistema RAG, però, questa potrebbe essere la diagnosi sbagliata.

Il modello generativo si trova infatti alla fine di una pipeline composta da più elementi, ognuno dei quali può influenzare la qualità della risposta. Se le informazioni corrette non vengono recuperate, vengono frammentate male oppure arrivano insieme a troppo rumore, sostituire l’LLM potrebbe produrre miglioramenti marginali o non produrne affatto.

La domanda, quindi, non dovrebbe essere immediatamente «quale modello possiamo utilizzare al posto di questo?», ma «in quale punto del sistema stiamo perdendo qualità?»

Che cos’è un sistema RAG e come funziona

RAG significa Retrieval-Augmented Generation. L’idea di fondo è permettere a un modello generativo di costruire una risposta utilizzando informazioni recuperate da una fonte di conoscenza esterna.

In un contesto aziendale, questa fonte potrebbe comprendere procedure interne, manuali tecnici, contratti, documentazione di prodotto, knowledge base o altri repository informativi.

Da qui nasce una descrizione molto intuitiva: «Colleghiamo l’AI ai documenti aziendali».

Come semplificazione funziona. Dal punto di vista progettuale, però, nasconde quasi tutto ciò che determina la qualità del risultato.

Il modello, infatti, non consulta necessariamente l’intera knowledge base ogni volta che riceve una domanda. In una tipica architettura RAG basata anche sulla ricerca vettoriale, la conoscenza viene prima elaborata e indicizzata; successivamente, quando arriva una query, il sistema cerca di individuare le informazioni più rilevanti da inserire nel contesto dell’LLM.

Come funziona una pipeline RAG

Possiamo distinguere almeno due macrofasi.

Questa rappresentazione è volutamente semplificata: un’implementazione reale può utilizzare componenti, strategie e percorsi differenti. È però sufficiente per evidenziare un punto fondamentale.

La qualità finale non dipende da un solo componente.

Chunking: il primo punto critico di un sistema RAG

Prima ancora di parlare dell’LLM, dobbiamo chiederci cosa sia successo ai documenti.

Un PDF di cento pagine, per esempio, non può essere considerato semplicemente come un blocco indistinto di testo da recuperare. Il contenuto deve essere estratto, organizzato e, nelle architetture che lo prevedono, suddiviso in unità più piccole utilizzabili durante la ricerca.

Qui entra in gioco il chunking.

La dimensione dei chunk, le sovrapposizioni, la struttura dei documenti e il modo in cui vengono preservate le relazioni tra sezioni possono influenzare ciò che sarà possibile recuperare successivamente.

Immaginiamo una procedura aziendale nella quale una condizione viene definita alla fine di una pagina e l’eccezione a quella condizione all’inizio della successiva. Una strategia di segmentazione poco adatta potrebbe separare informazioni che, semanticamente, dovrebbero essere interpretate insieme.

Il documento originale contiene quindi la risposta corretta, ma questo non significa necessariamente che la rappresentazione utilizzata dal sistema la conservi nel modo migliore.

Avere l’informazione nella knowledge base non equivale ad averla resa correttamente recuperabile.

Retrieval: perché la ricerca semantica non basta

Una volta indicizzata la conoscenza, dobbiamo recuperarla.

La ricerca vettoriale permette di rappresentare query e contenuti attraverso embeddings e di confrontarli nello spazio vettoriale. Questo rende possibile individuare contenuti semanticamente vicini anche quando domanda e documento non utilizzano esattamente le stesse parole.

È una capacità estremamente utile, ma la similarità semantica non coincide necessariamente con la rilevanza necessaria per rispondere.

Un contenuto può essere molto vicino all’argomento della domanda e, contemporaneamente, non contenere l’informazione specifica richiesta.

È uno dei motivi per cui una pipeline RAG può affiancare alla ricerca vettoriale altre strategie. Microsoft descrive, tra le tecniche comunemente utilizzate, full-text search, vector search, hybrid search, query rewriting e reranking.

Hybrid search: combinare ricerca semantica e lessicale

La hybrid search può combinare segnali lessicali e semantici: la prima componente può essere particolarmente utile quando contano termini esatti, codici, sigle o nomi specifici; quella vettoriale può invece intercettare relazioni semantiche anche in assenza di corrispondenze testuali precise.

Non esiste, però, una strategia universalmente migliore. La scelta dipende dai dati, dalle query, dal dominio e dal tipo di risposta che il sistema deve produrre.

Ed è proprio per questo che un RAG deve essere progettato e valutato sul proprio caso d’uso.

Perché recuperare più documenti può peggiorare un RAG

Una soluzione apparentemente semplice a un retrieval debole potrebbe essere aumentare il numero di risultati recuperati.

Se cinque chunk non bastano, recuperiamone dieci. Se dieci non bastano, recuperiamone venti.

Ma più contesto non significa necessariamente contesto migliore.

Aumentando il numero di risultati possiamo migliorare la probabilità di includere l’informazione necessaria, ma possiamo contemporaneamente introdurre contenuti irrilevanti, ridondanti o persino in conflitto.

Emergono così due esigenze differenti: recuperare abbastanza informazione utile senza riempire il contesto di rumore.

È la stessa distinzione che ritroviamo nelle metriche di retrieval. La Context Recall riguarda, in termini generali, la capacità di non perdere le informazioni necessarie; la Context Precision riguarda invece la qualità e la rilevanza di ciò che viene recuperato. Framework dedicati alla valutazione dei sistemi RAG, come Ragas, mantengono infatti separate queste dimensioni.

Un sistema può quindi avere recall elevata e precision insufficiente, oppure essere molto preciso ma non recuperare una parte dell’informazione necessaria.

In entrambi i casi la risposta finale può risultare insoddisfacente, ma per ragioni diverse.

Reranking: selezionare il contesto più rilevante

Una possibile strategia consiste nel separare il recupero iniziale dalla selezione finale del contesto.

Il retriever può recuperare un insieme relativamente ampio di candidati, privilegiando inizialmente la capacità di non perdere informazioni potenzialmente importanti. Successivamente, un sistema di reranking può rivalutare quei candidati rispetto alla query e modificare il loro ordine di rilevanza.

Questo introduce un passaggio ulteriore, ma permette di distinguere due compiti: trovare contenuti potenzialmente pertinenti e stabilire quali siano realmente i migliori da fornire al modello.

Anche in questo caso, però, aggiungere un reranker non è automaticamente la soluzione. Introduce complessità, latenza e costi che devono essere giustificati dal miglioramento ottenuto.

Il principio rimane lo stesso: prima individuiamo il problema, poi scegliamo la tecnica.

Query rewriting e query decomposition

Finora abbiamo ragionato soprattutto sui documenti e sul retrieval, ma anche la domanda dell’utente può essere difficile da utilizzare direttamente come query di ricerca.

Pensiamo a una richiesta come: «Quali sono le differenze tra la procedura attuale e quella precedente per i clienti enterprise?»

Per rispondere potrebbe essere necessario recuperare informazioni da documenti diversi, identificare versioni differenti della procedura e confrontarle. Una singola ricerca potrebbe non essere sufficiente.

In casi di questo tipo possiamo intervenire prima del retrieval attraverso tecniche di query rewriting, espansione o decomposizione: la richiesta originale viene trasformata in una o più query maggiormente adatte alla ricerca delle informazioni necessarie. Anche il query rewriting rientra tra le tecniche utilizzate nelle pipeline RAG moderne.

Il punto interessante è che abbiamo aggiunto un altro possibile failure point.

Più comprendiamo l’architettura, meno ha senso attribuire automaticamente ogni risposta sbagliata al modello finale.

Come valutare un sistema RAG

Supponiamo che un assistente aziendale risponda in maniera errata a una domanda. Dire semplicemente «la risposta è sbagliata» ci dice che il sistema non ha funzionato, ma non ci dice perché.

Non sono modi diversi di formulare la stessa domanda. Stiamo misurando componenti differenti.

Framework di evaluation per applicazioni RAG distinguono proprio metriche come Context Precision, Context Recall, Response Relevancy e Faithfulness. Quest’ultima, in particolare, riguarda quanto le affermazioni della risposta siano supportate dal contesto recuperato.

Retrieval e generation devono essere misurati separatamente

Questa separazione permette di costruire una diagnosi.

Se le informazioni corrette non vengono recuperate, possiamo concentrarci su indicizzazione, chunking, query transformation, strategia di ricerca o ranking.

Se vengono recuperate correttamente, ma la risposta non le utilizza, il retrieval potrebbe non essere il problema.

Se la risposta contiene affermazioni non supportate dal contesto, dobbiamo analizzare il comportamento della fase generativa e la groundedness della risposta.

Se retrieval e generazione funzionano sui test tecnici, ma gli utenti continuano a considerare le risposte poco utili, probabilmente dobbiamo ampliare nuovamente ciò che stiamo misurando.

Quando il problema è davvero l’LLM

Immaginiamo di avere:

e di sostituire il modello:

Abbiamo migliorato l’ultimo componente senza intervenire sul punto nel quale nasce il problema.

Il nuovo modello potrebbe riuscire a gestire meglio il contesto incompleto e produrre una risposta apparentemente migliore; potrebbe anche non cambiare nulla. In entrambi i casi, però, non abbiamo ancora risolto il difetto strutturale della pipeline.

Questo non significa che la scelta dell’LLM sia secondaria.

Modelli diversi possono comportarsi diversamente nella comprensione delle istruzioni, nell’utilizzo di contesti lunghi, nella generazione, nella latenza, nei costi e in molti altri aspetti rilevanti.

Significa semplicemente che il modello deve essere valutato come componente del sistema, non utilizzato come spiegazione predefinita di qualsiasi problema del sistema.

Come migliorare le performance di un sistema RAG

Dire che un RAG permette a un’AI di rispondere utilizzando i documenti aziendali rimane una buona spiegazione introduttiva.

Progettarne uno affidabile richiede, però, un livello di ragionamento diverso.

Dobbiamo capire come rappresentare la conoscenza, come segmentarla, come indicizzarla, quali strategie di retrieval utilizzare, quante informazioni recuperare, come ordinarle, cosa fornire al modello e, soprattutto, come misurare ciascuna fase.

È qui che il problema smette di essere semplicemente «Qual è il miglior LLM?» e diventa «Quale architettura permette a questo sistema di recuperare le informazioni corrette e utilizzarle per produrre una risposta affidabile?»

Per questo, quando un sistema RAG non raggiunge le performance attese, non partirei dalla sostituzione del modello. Partirei dalla diagnosi.

Migliorare un sistema RAG non significa necessariamente trovare un LLM migliore. Significa capire dove il sistema sta perdendo qualità e solo dopo decidere su quale componente intervenire.

Domande frequenti sui sistemi RAG

Che differenza c’è tra RAG e LLM?

L’LLM è il modello che genera la risposta. Un sistema RAG aggiunge una pipeline che recupera informazioni da fonti esterne e le inserisce nel contesto utilizzato dal modello.

A cosa serve il chunking in un sistema RAG?

Il chunking suddivide i documenti in unità utilizzabili durante la ricerca. Dimensione, sovrapposizioni e struttura dei chunk influenzano quali informazioni potranno essere recuperate insieme.

Che cos’è il reranking in un sistema RAG?

Il reranking rivaluta i contenuti recuperati rispetto alla query e ne modifica l’ordine, aiutando a selezionare il contesto più rilevante da fornire all’LLM.

Come si valuta la qualità di un sistema RAG?

Retrieval e generazione vanno misurati separatamente, verificando tra l’altro Context Precision, Context Recall, Response Relevancy e Faithfulness.