Autore: Riley Debug – specialista del debug AI e ingegnere ML ops
RAG promette di dotare i Modelli di Linguaggio a Grande Scala (LLMs) di informazioni aggiornate e specifiche per il dominio, riducendo notevolmente le allucinazioni e migliorando la precisione fattuale. Tuttavia, questa promessa spesso si scontra con la realtà di una “recupero errato.” Quando la tua applicazione RAG fornisce un contesto non pertinente, incompleto o errato al LLM, il risultato ne risente e la fiducia degli utenti si erode. Non è solo un piccolo bug; è una sfida fondamentale che può compromettere l’utilità dell’intero sistema.
Il mio obiettivo con questa guida pratica è di dotarti delle conoscenze e delle strategie pratiche per identificare, diagnosticare e risolvere sistematicamente i problemi di precisione del recupero nelle tue applicazioni RAG. Supereremo le soluzioni superficiali ed esploreremo i componenti chiave che influenzano la qualità del recupero, offrendo consigli pratici ed esempi concreti. Alla fine, avrai a disposizione un framework solido per garantire che il tuo sistema RAG recuperi costantemente le informazioni più pertinenti, permettendo al tuo LLM di brillare davvero.
Comprendere il Pipeline RAG e i Punti di Fallimento Potenziali
Prima di poter debugare efficacemente la precisione del recupero, dobbiamo avere una comprensione chiara del pipeline RAG. Esso implica generalmente diverse fasi, ciascuna delle quali può essere una fonte di errore. Pensalo come una catena: una debolezza in qualunque anello può compromettere l’intero sistema.
Le Fasi Chiave del Recupero RAG
- Ingestione e Preprocessing dei Documenti: I dati grezzi (PDF, pagine web, database) vengono raccolti, puliti e strutturati. Questo include l’analisi, la normalizzazione e spesso, l’estrazione di metadati.
- Suddivisione: I documenti grandi vengono suddivisi in “chunks” o passaggi più piccoli e gestibili. Questo è cruciale poiché i modelli di integrazione hanno limiti di token, e pezzi più piccoli permettono un recupero più preciso.
- Generazione di Integrazione: Ogni chunk viene convertito in un vettore numerico (un’integrazione) utilizzando un modello di integrazione. Queste integrazioni catturano il significato semantico del testo.
- Archiviazione in un Database Vettoriale: Le integrazioni (insieme ai loro chunk di testo corrispondenti e ai metadati) vengono archiviati in un database vettoriale, ottimizzato per una ricerca di similarità rapida.
- Integrazione della Richiesta: Quando l’utente pone una richiesta, anche essa viene convertita in un’integrazione utilizzando lo stesso modello di integrazione.
- Ricerca di Similarità: L’integrazione della richiesta viene utilizzata per cercare nel database vettoriale le integrazioni dei chunk più simili.
- Assemblaggio del Contesto: I chunk recuperati vengono quindi assemblati e trasmessi come contesto al LLM insieme alla richiesta originale dell’utente.
Sintomi Comuni di una Scarsa Precisione di Recupero
Come sapere se hai un problema di recupero? Cerca questi segni rivelatori:
- Allucinazioni: Il LLM genera informazioni fattualmente errate, anche quando i dati corretti sono presenti nella tua base di conoscenze. Questo significa spesso che l’informazione pertinente non è stata recuperata.
- Risposte Irrelevanti: La risposta del LLM è precisa ma non risponde direttamente alla domanda dell’utente, indicando che informazioni tangenziali o non correlate sono state recuperate.
- Risposte Incomplete: Il LLM fornisce una risposta parziale, mancando dettagli chiave che esistono nei tuoi documenti sorgente. Questo suggerisce che alcuni chunk pertinenti sono stati omessi durante il recupero.
- Punteggi di Fiducia Bassi: Se il tuo sistema RAG fornisce punteggi di fiducia per i documenti recuperati, punteggi costantemente bassi per richieste apparentemente pertinenti possono indicare un problema.
- Insoddisfazione degli Utenti: I feedback diretti degli utenti riguardo risposte imprecise o poco utili sono l’indicatore finale.
Diagnosticare i Problemi di Recupero: Un Approccio Sistematico
Un debug efficace richiede un approccio sistematico. Non trarre conclusioni affrettate. Invece, isola le variabili e testa le ipotesi in ogni fase del pipeline RAG.
Fase 1: Ispezione Diretta dei Chunk Recuperati
Il primo e il modo più diretto di debug è evitare completamente il LLM e esaminare ciò che il tuo recuperatore restituisce realmente per una richiesta specifica. La maggior parte dei client di database vettoriali o dei framework RAG ti permette di farlo.
Consiglio Pratico: Per un campione di richieste problematiche, recupera i N chunk più pertinenti e leggili manualmente. Fai le seguenti domande:
- Questi chunk sono davvero pertinenti per la richiesta?
- Contengono le informazioni necessarie per rispondere alla richiesta?
- Ci sono chunk manifestamente non pertinenti nei primi N?
- L’informazione è completa o è frammentata attraverso più chunk che dovrebbero idealmente essere recuperati insieme?
Esempio di Codice Snippet (Concettuale con un framework RAG ipotetico):
from my_rag_framework import Retriever
retriever = Retriever(vector_db_client=my_vector_db, embedding_model=my_embedding_model)
query = "Qual è la capitale della Francia e la sua popolazione?"
retrieved_chunks = retriever.retrieve(query, top_k=5)
print(f"Richiesta: {query}\n")
for i, chunk in enumerate(retrieved_chunks):
print(f"--- Chunk {i+1} (Punteggio: {chunk.score:.4f}) ---")
print(chunk.text)
print("--------------------------------------\n")
Questa ispezione diretta fornisce una visione immediata della fonte del problema prima ancora che si arrivi alla fase LLM.
Fase 2: Valutare il Preprocessing dei Documenti e le Strategie di Suddivisione
La qualità dei tuoi chunk influisce direttamente sul recupero. Chunk mal formati sono una causa comune di problemi di precisione.
Trappole Comuni e Soluzioni:
- Chunk Troppo Grandi: Un chunk troppo grosso potrebbe contenere più soggetti, diluendo così il segnale semantico di qualsiasi soggetto. Quando la richiesta è specifica, un grande chunk potrebbe essere recuperato, ma la parte pertinente è sepolta, o l’integrazione potrebbe non rappresentare correttamente l’informazione più importante.
Soluzione: Sperimenta con dimensioni di chunk più piccole (ad esempio, 200-500 token con un certo sovrapposizione). Usa strumenti che rispettano la struttura del documento (paragrafi, sezioni) piuttosto che suddivisioni arbitrarie per caratteri.
- Chunk Troppo Piccoli: Se i chunk sono troppo piccoli, informazioni critiche potrebbero essere frammentate attraverso più chunk, rendendo difficile per il recuperatore riunire tutto il contesto necessario a una richiesta.
Soluzione: Assicurati che i chunk siano semanticamente coerenti. Prova a suddividere per paragrafi o gruppi di frasi. Considera di aggiungere un piccolo sovrapposizione (ad esempio, 10-20% della dimensione del chunk) tra i chunk per preservare il contesto attraverso i confini.
- Perdita di Contesto Durante la Suddivisione: Titoli, sottotitoli o frasi di introduzione importanti potrebbero essere separati dal contenuto che descrivono.
Soluzione: Integra i metadati nei chunk. Ad esempio, aggiungi il titolo del documento o il titolo della sezione a ogni chunk derivato da quella sezione. Alcune strategie avanzate di suddivisione cercano di mantenere insieme frasi semanticamente correlate.
Esempio di aggiunta di metadati:
def chunk_document_with_metadata(doc_text, doc_title): # Esempio semplificato, la vera implementazione utilizzerebbe un separatore di testo paragraphs = doc_text.split('\n\n') chunks = [] for para in paragraphs: if para.strip(): # Aggiungere il titolo a ogni chunk chunks.append(f"Titolo del Documento: {doc_title}\n\n{para.strip()}") return chunks - Poor Document Analysis: Se la tua prima analisi di file PDF o di altri documenti complessi fallisce, potrebbero esserci testo inutilizzabile, sezioni mancanti o una struttura errata anche prima che inizi la suddivisione.
Soluzione: Utilizza librerie di analisi solide (es.
pypdf,unstructured-io) e ispeziona visivamente l’output analizzato per un campione di documenti.
Fase 3: Valutare le Prestazioni del Modello di Integrazione
Il modello di integrazione è il cuore della ricerca semantica. Se non cattura correttamente il significato dei tuoi chunk e delle tue richieste, il recupero ne risentirà.
Trappole Comuni e Soluzioni:
- Domaine Mal Accordé : Un modello di integrazione a uso generale potrebbe non funzionare bene su un gergo particolarmente tecnico nel tuo settore (ad esempio, testi medici, legali, finanziari).
Soluzione : Considera di perfezionare un modello di integrazione generale sui tuoi dati specifici del settore, o utilizza un modello di integrazione pre-addestrato su dati simili. Valuta diversi modelli di integrazione su un insieme di dati rappresentativo.
- Modello di Integrazione Obsoleto : La comprensione del linguaggio evolve. I vecchi modelli di integrazione potrebbero non catturare le sfumature così efficacemente come i nuovi.
Soluzione : Rimani informato sui nuovi modelli di integrazione. Valuta regolarmente il tuo modello attuale rispetto alle nuove alternative.
- Granularità Semantica Insufficiente : Il modello potrebbe avere difficoltà a differenziare concetti strettamente correlati ma distinti.
Soluzione : Questo è più difficile da correggere direttamente senza affinamento del modello. Tuttavia, una migliore suddivisione e l’aggiunta di metadati più precisi possono aiutare a chiarire le ambiguità.
Consiglio Pratico : Testa direttamente l’efficacia del tuo modello di integrazione. Prendi una richiesta e alcuni chunk pertinenti noti, insieme a alcuni chunk non pertinenti noti. Calcola le loro integrazioni e misura la similarità coseno tra l’integrazione della richiesta e ciascuna integrazione di chunk. I chunk pertinenti dovrebbero avere punteggi di similarità significativamente più elevati.
Esempio di Snippet di Codice (utilizzando Hugging Face Sentence Transformers) :
from sentence_transformers import SentenceTransformer, util
model = SentenceTransformer('all-MiniLM-L6-v2') # O il tuo modello di incorporazione scelto
query_text = "Quali sono i requisiti per ottenere una licenza di pilota?"
relevant_chunk = "Per ottenere una licenza di pilota privato, i candidati devono avere almeno 17 anni, essere in grado di leggere, parlare e comprendere l'inglese, e superare un esame scritto e un test di volo pratico."
irrelevant_chunk = "La storia dell'aviazione risale all'inizio del XX secolo con il primo volo dei fratelli Wright."
query_embedding = model.encode(query_text, convert_to_tensor=True)
relevant_embedding = model.encode(relevant_chunk, convert_to_tensor=True)
irrelevant_embedding = model.encode(irrelevant_chunk, convert_to_tensor=True)
relevant_similarity = util.cos_sim(query_embedding, relevant_embedding)
irrelevant_similarity = util.cos_sim(query_embedding, irrelevant_embedding)
print(f"Richiesta : {query_text}")
print(f"Similarità con il frammento pertinente : {relevant_similarity.item():.4f}")
print(f"Similarità con il frammento non pertinente : {irrelevant_similarity.item():.4f}")
# Atteso : relevant_similarity >> irrelevant_similarity
Fase 4 : Ottimizzare le strategie di recupero e la configurazione del database vettoriale
Anche con buoni frammenti e incorporazioni, il modo in cui cerchi nel tuo database vettoriale e cosa fai con i risultati conta.
Trappole comuni e soluzioni :
- Selezione
top_ksubottimale : Recuperare troppo pochi frammenti può far mancare informazioni cruciali. Recuperare troppo può introdurre rumore e superare la finestra di contesto del LLM, portando a una predominanza di informazioni non pertinenti.Soluzione : Sperimenta con valori
top_k(ad esempio, 3, 5, 8, 10). Il valore ottimale dipende dalla dimensione dei tuoi frammenti, dalla complessità dei documenti e dalla finestra di contesto del LLM. Valuta l’impatto sulle performance end-to-end. - Mancanza di ricerca ibrida : La ricerca semantica pura può a volte avere difficoltà con corrispondenze esatte di parole chiave, specialmente per entità specifiche o codici.
Soluzione : Implementa una ricerca ibrida, combinando la ricerca semantica con una ricerca basata su parole chiave (ad esempio, BM25). Questo può migliorare la robustezza per diversi tipi di richieste. Molti database vettoriali offrono direttamente questa capacità o tramite integrazioni con motori di ricerca come ElasticSearch.
Ricerca ibrida concettuale :
# pseudo-codice def hybrid_retrieve(query, top_k=5): semantic_results = vector_db.search_semantic(query, k=top_k) keyword_results = keyword_search_engine.search(query, k=top_k) # Combina e riordina i risultati, ad esempio usando la Fusione di Classifica Reciproca (RRF) combined_results = combine_and_rank(semantic_results, keyword_results) return combined_results[:top_k] - Filtraggio delle metadati insufficiente : Se i tuoi documenti contengono metadati utili (ad esempio, data, autore, tipo di documento), non utilizzarli durante il recupero è un’opportunità mancata.
Soluzione : Implementa un filtraggio delle metadati o un pre-filtraggio. Ad esempio, se una richiesta riguarda “politiche recenti”, filtra i documenti per data prima della ricerca semantica.
- Problemi di rivalutazione : Il recupero iniziale può restituire un ampio insieme di candidati. Un passo di rivalutazione può quindi valutare questi candidati più accuratamente rispetto alla richiesta.
Soluzione : Integra un modello di rivalutazione (ad esempio, un modello di cross-encoder come
cohere/rerank-english-v3.0o un modello più piccolo basato su BERT). I rivalutatori prendono sia la richiesta che un documento/frammento candidato come input e producono un punteggio di pertinenza, spesso superando la semplice similarità vettoriale per una pertinenza fine. - Parametri di indicizzazione del database vettoriale : Per set di dati molto grandi, la scelta dell’indice (ad esempio, HNSW, IVF) e i suoi parametri (ad esempio,
m,ef_constructionper HNSW) possono influenzare il richiamo e la velocità di ricerca.Soluzione : Consulta la documentazione del tuo database vettoriale. Sperimenta con diversi parametri di indicizzazione, bilanciando tra la velocità di ricerca e la precisione del recupero (richiamo).
Strategie avanzate per migliorare la precisione del recupero
Una volta affrontati i problemi fondamentali, considera queste tecniche avanzate per ulteriori miglioramenti.
Trasformazione e espansione della richiesta
A volte, la richiesta iniziale dell’utente non è ottimale per un recupero diretto. Può essere troppo corta, ambigua o utilizzare una formulazione diversa da quella dei tuoi documenti.
- Riscrittura della richiesta : Utilizza un LLM per riscrivere la richiesta dell’utente sotto diverse forme alternative o per ampliarla con più contesto.
Esempio di prompt : « L’utente ha chiesto : ‘{original_query}’. Si prega di generare 3 modi alternativi per formulare questa domanda che sarebbero buoni per cercare in un database di documenti. Concentrati sulle parole chiave e sui concetti pertinenti. Output come lista JSON. »
- HyDE (Hypothetical Document Embedding) : Genera una risposta o un documento ipotetico basato sulla richiesta utilizzando un LLM. Poi, integra questo documento ipotetico e usa la sua integrazione per il recupero. Questo può colmare il divario tra lo spazio della richiesta e quello del documento.
- Prompting Step-back : Per domande complesse, chiedi a un LLM di generare una domanda “step-back” che offra un contesto o un principio più ampio e recupera documenti per entrambe le domande originali e di step-back.
Recupero multi-vettori e recupero di documenti parenti
Queste tecniche mirano a superare i limiti dei frammenti di dimensione fissa.
- Recupero multi-vettori : Invece di una sola integrazione per frammento, genera più integrazioni per un unico frammento. Ad esempio, una per il riassunto, una per le frasi chiave, e una per il testo completo. Recupera sulla base di uno di questi elementi, poi restituisci il frammento completo.
- Recupero di documenti parenti : Integra e recupera piccoli frammenti granulari. Una volta identificati piccoli frammenti pertinenti, recupera il loro documento “genitore” più ampio o un frammento più grande che li contiene. Questo fornisce sia una precisione (dei piccoli frammenti) sia un contesto più ampio (documenti parenti). Questo può essere particolarmente utile per garantire che il LLM abbia sufficiente contesto per sintetizzare una risposta.
Aggiustamento del LLM per RAG
Sebbene l’accento sia posto sul recupero, la capacità del LLM di utilizzare il contesto recuperato è altrettanto importante. Se il LLM ha costantemente difficoltà ad estrarre risposte da documenti recuperati perfettamente pertinenti, potresti aver bisogno di aggiustare la tua ingegneria di prompt o addirittura di affinare il LLM.
- Ingegneria dei prompt: Assicurati che i tuoi prompt informino chiaramente il LLM di rispondere *unicamente* sulla base del contesto fornito e di indicare quando non può trovare una risposta. Sottolinea l’importanza di rispondere in modo diretto e conciso.
- Affinamento delle istruzioni: Per problemi più persistenti, affina un LLM più piccolo con esempi in cui
Articoli correlati
- Test di performance dei sistemi di IA
- ChatGPT 5 mancante? Perché non puoi ancora trovarlo!
- Test di contratto dei sistemi di IA
🕒 Published: