Autore: Riley Debug – specialista in debug AI e ingegnere ML ops
RAG promette di fornire ai grandi modelli di linguaggio (LLMs) informazioni aggiornate e specifiche per un determinato dominio, riducendo drasticamente le allucinazioni e migliorando l’accuratezza dei fatti. Tuttavia, questa promessa è spesso messa alla prova dalla realtà di una “recupero errato”. Quando la tua applicazione RAG fornisce un contesto non pertinente, incompleto o errato al LLM, l’output ne risente e la fiducia degli utenti si erode. Non si tratta solo di un piccolo problema; è una sfida fondamentale che può compromettere l’utilità dell’intero sistema.
Il mio obiettivo con questa guida pratica è fornirti le conoscenze e le strategie pratiche per identificare, diagnosticare e risolvere sistematicamente i problemi di accuratezza del recupero nelle tue applicazioni RAG. Andremo oltre le correzioni superficiali ed esploreremo i componenti chiave che influenzano la qualità del recupero, offrendo consigli pratici ed esempi del mondo reale. Alla fine, avrai un quadro solido per garantire che il tuo sistema RAG recuperi costantemente le informazioni più pertinenti, permettendo così al tuo LLM di brillare veramente.
Comprendere il pipeline RAG e i potenziali punti di fallimento
Prima di poter eseguire il debug efficacemente dell’accuratezza del recupero, dobbiamo avere una comprensione chiara del pipeline RAG. Esso implica generalmente diverse fasi, ognuna delle quali può essere una fonte potenziale di errore. Consideralo come una catena: una debolezza in un anello può compromettere l’intero sistema.
Le fasi chiave del recupero RAG
- Ingestione e preelaborazione dei documenti: I dati grezzi (PDF, pagine web, database) vengono raccolti, ripuliti e strutturati. Ciò include il parsing, la normalizzazione e spesso, l’estrazione di metadati.
- Suddivisione: I documenti di grandi dimensioni vengono divisi in “pezzi” o passaggi più piccoli e gestibili. Questo è cruciale poiché i modelli di incorporazione hanno limiti di token, e pezzi più piccoli consentono un recupero più preciso.
- Generazione di incorporazioni: Ogni pezzo viene convertito in un vettore numerico (un’incorporazione) utilizzando un modello di incorporazione. Queste incorporazioni catturano il significato semantico del testo.
- Memorizzazione in un database di vettori: Le incorporazioni (con i loro pezzi di testo e metadati corrispondenti) vengono memorizzate in un database di vettori, ottimizzato per una ricerca di similarità rapida.
- Incorporazione della query: Quando l’utente pone una query, questa viene anch’essa convertita in un’incorporazione utilizzando lo stesso modello di incorporazione.
- Ricerca di similarità: L’incorporazione della query è utilizzata per ricercare nel database di vettori le incorporazioni dei pezzi più simili.
- Assemblaggio del contesto: I pezzi recuperati vengono quindi assemblati e trasmessi come contesto al LLM, insieme alla query originale dell’utente.
Sintomi comuni di un’errata accuratezza 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 conoscenza. Questo spesso significa che le informazioni pertinenti non sono state recuperate.
- Risposte non pertinenti: La risposta del LLM è accurata ma non risponde direttamente alla domanda dell’utente, indicando che sono state recuperate informazioni tangenziali o non correlate.
- Risposte incomplete: Il LLM fornisce una risposta parziale, mancando dettagli chiave che esistono nei tuoi documenti di origine. Questo suggerisce che alcuni pezzi pertinenti sono stati persi durante il recupero.
- Punteggi di fiducia bassi: Se il tuo sistema RAG fornisce punteggi di fiducia per i documenti recuperati, punteggi costantemente bassi per query apparentemente pertinenti possono indicare un problema.
- Reclami degli utenti: I feedback diretti degli utenti riguardo a risposte inaccurate o inutili sono l’indicatore finale.
Diagnosi dei problemi di recupero: un approccio sistematico
Un debug efficace richiede un approccio sistematico. Non trarre conclusioni affrettate. Al contrario, isola le variabili e testa le ipotesi in ogni fase del pipeline RAG.
Fase 1: Ispezionare direttamente i pezzi recuperati
Il modo più diretto e immediato di eseguire il debug consiste nel bypassare completamente il LLM e esaminare cosa restituisce realmente il tuo recuperatore per una determinata query. La maggior parte dei client dei database di vettori o dei framework RAG consente di farlo.
Consiglio pratico: Per un campione di query problematiche, recupera i N migliori pezzi e leggili manualmente. Chiediti:
- Questi pezzi sono realmente pertinenti alla query?
- Contengono le informazioni necessarie per rispondere alla query?
- Ci sono pezzi manifestamente non pertinenti tra i N migliori?
- L’informazione è completa, o è frammentata attraverso diversi pezzi che dovrebbero idealmente essere recuperati insieme?
Esempio di codice (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"Query: {query}\n")
for i, chunk in enumerate(retrieved_chunks):
print(f"--- Pezzo {i+1} (Punteggio: {chunk.score:.4f}) ---")
print(chunk.text)
print("--------------------------------------\n")
Questa ispezione diretta fornisce un’immediata panoramica sull’origine del problema, prima della fase del LLM.
Fase 2: Valutare le strategie di preelaborazione dei documenti e di suddivisione
La qualità dei tuoi pezzi impatta direttamente il recupero. Pezzi malformati sono una causa frequente di problemi di accuratezza.
Trappole comuni e soluzioni:
- Pezzi troppo grandi: Un pezzo troppo voluminoso può contenere più argomenti, diluendo il segnale semantico di un singolo argomento. Quando la query è specifica, un grande pezzo può essere recuperato, ma la parte pertinente è sepolta, o l’incorporazione potrebbe non rappresentare con precisione le informazioni più importanti.
Soluzione: Sperimenta con dimensioni di pezzi più piccole (es. 200-500 token con un certo sovrapposizione). Utilizza strumenti che rispettano la struttura del documento (paragrafi, sezioni) piuttosto che tagli arbitrari di caratteri.
- Pezzi troppo piccoli: Se i pezzi sono troppo piccoli, informazioni critiche possono essere frammentate attraverso più pezzi, rendendo difficile per il recuperatore mettere insieme tutto il contesto necessario per una query.
Soluzione: Assicurati che i pezzi siano semanticamente coerenti. Prova a suddividere per paragrafi o gruppi di frasi. Considera di aggiungere un piccolo sovrapposizione (es. 10-20% della dimensione del pezzo) tra i pezzi per preservare il contesto attraverso i confini.
- Perdita di contesto durante la suddivisione: Titoli, intestazioni o frasi introduttive importanti possono essere separati dal contenuto che descrivono.
Soluzione: Integra metadati nei pezzi. Ad esempio, prefissa il titolo del documento o l’intestazione di sezione a ciascun pezzo derivato da quella sezione. Alcune strategie di suddivisione avanzate 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 divisore di testo paragraphs = doc_text.split('\n\n') chunks = [] for para in paragraphs: if para.strip(): # Prefissa il titolo a ciascun pezzo chunks.append(f"Titolo del documento: {doc_title}\n\n{para.strip()}") return chunks - Parsing errato dei documenti: Se il tuo parsing iniziale di PDF o altri documenti complessi fallisce, potresti trovarti con testo incompleto, sezioni mancanti o una struttura errata prima ancora che inizi la suddivisione.
Soluzione: Utilizza librerie di parsing solide (es.
pypdf,unstructured-io) e ispeziona visivamente l’output analizzato per un campione di documenti.
Fase 3: Valutare le performance del modello di incorporazione
Il modello di incorporazione è il cuore della ricerca semantica. Se non cattura fedelmente il significato dei tuoi pezzi e delle tue query, il recupero ne risentirà.
Trappole comuni e soluzioni:
- Domaine inadeguato: Un modello di incorporazione generale potrebbe non funzionare bene con gergo altamente specializzato o tecnico nel tuo campo (ad es., testi medici, legali, finanziari).
Soluzione: Considera di affinare un modello di incorporazione generale sui tuoi dati specifici del settore, oppure usa un modello di incorporazione pre-addestrato su dati simili. Valuta diversi modelli di incorporazione su un insieme di dati rappresentativo.
- Modello di incorporazione obsoleto: La comprensione del linguaggio si evolve. I modelli di incorporazione più vecchi potrebbero non catturare le sfumature tanto efficacemente quanto quelli più recenti.
Soluzione: Resta aggiornato sui nuovi modelli di incorporazione. Testa regolarmente il tuo modello attuale rispetto a nuove alternative.
- Granularità semantica insufficiente: Il modello può avere difficoltà a distinguere concetti strettamente correlati ma distinti.
Soluzione: Questo è più difficile da correggere direttamente senza affinare il modello. Tuttavia, una suddivisione migliore e l’aggiunta di metadati più precisi possono aiutare a disambiguare.
Consiglio pratico: Testa direttamente l’efficacia del tuo modello di incorporazione. Prendi una query e alcuni frammenti conosciuti come pertinenti, così come alcuni frammenti conosciuti come non pertinenti. Calcola le loro incorporazioni e misura la similarità coseno tra l’incorporazione della query e ogni incorporazione di frammento. I frammenti pertinenti dovrebbero avere punteggi di similarità significativamente più elevati.
Esempio di codice (utilizzando Hugging Face Sentence Transformers):
from sentence_transformers import SentenceTransformer, util
model = SentenceTransformer('all-MiniLM-L6-v2') # O il tuo modello di embedding 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"Query: {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
Passo 4: Ottimizzazione delle Strategie di Recupero e Configurazione del Database Vettoriale
Anche con buoni frammenti e embedding, il modo in cui interroghi il tuo database vettoriale e cosa fai con i risultati conta.
Trappole Comuni e Soluzioni:
- Selezione
top_kSotto-ottimale: Recuperare troppo pochi frammenti potrebbe fare perdere informazioni cruciali. Recuperare troppi risultati 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 prestazioni end-to-end. - Assenza di Ricerca Ibrida: La ricerca semantica pura può talvolta incontrare difficoltà con le corrispondenze esatte delle parole chiave, in particolare per entità o codici specifici.
Soluzione: Implementa una ricerca ibrida, combinando ricerca semantica e ricerca basata su parole chiave (ad esempio, BM25). Questo può migliorare la solidità per diversi tipi di query. Molti database vettoriali offrono questa capacità direttamente o tramite integrazione con motori di ricerca come ElasticSearch.
Ricerca Ibrida Concettuale:
# pseudo-code 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) # Combinare e riordinare i risultati, ad esempio, utilizzando la Fusione di Classifica Reciproca (RRF) combined_results = combine_and_rank(semantic_results, keyword_results) return combined_results[:top_k] - Filtraggio di Metadati Povero: Se i tuoi documenti hanno metadati utili (ad esempio, data, autore, tipo di documento), non utilizzarli durante il recupero è un’opportunità mancata.
Soluzione: Implementa un filtraggio dei metadati o un pre-filtraggio. Ad esempio, se una query interroga sulle “politiche recenti”, filtra i documenti per data prima della ricerca semantica.
- Problemi di Rievaluazione: Il recupero iniziale può restituire un ampio insieme di candidati. Un passaggio di rievaluazione può quindi classificare questi candidati più precisamente rispetto alla query.
Soluzione: Integra un modello di rievaluazione (ad esempio, un modello cross-encoder come
cohere/rerank-english-v3.0o un modello BERT più piccolo). I rievaluator prendono sia la query che un documento/frammento candidato come input e producono un punteggio di pertinenza, superando spesso la similarità vettoriale pura 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 velocità di ricerca e precisione di recupero (richiamo).
Strategie Avanzate per Migliorare la Precisione di Recupero
Una volta risolti i problemi fondamentali, considera queste tecniche avanzate per ulteriori miglioramenti.
Trasformazione e Espansione delle Query
Talvolta, la query iniziale dell’utente non è ottimale per un recupero diretto. Può essere troppo corta, ambigua, o usare una formulazione diversa da quella dei tuoi documenti.
- Riscrittura della Query: Usa un LLM per riscrivere la query dell’utente in diverse forme alternative o per ampliare 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 appropriati per cercare in un database di documenti. Concentrati sulle parole chiave e sui concetti pertinenti. Uscita sotto forma di lista JSON.”
- HyDE (Hypothetical Document Embedding): Genera una risposta o un documento ipotetico basato sulla query 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 query e lo spazio del documento.
- Domande di Retrogradazione: Per domande complesse, chiedi a un LLM di generare una domanda di “retrogradazione” che fornisca un contesto o un principio più ampio, e recupera documenti per le domande originali e di retrogradazione.
Recupero Multi-Vettore e Recupero del Documento Genitore
Queste tecniche mirano a superare le limitazioni dei frammenti di dimensioni fisse.
- Recupero Multi-Vettore: Invece di un’unica integrazione per frammento, genera più integrazioni per un singolo 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 del Documento Genitore: Integra e recupera frammenti più piccoli e granulari. Una volta che piccoli frammenti pertinenti sono stati identificati, recupera il loro “documento genitore” più grande o un frammento più ampio che li contiene. Questo fornisce sia precisione (proveniente da piccoli frammenti) che un contesto più ampio (proveniente da documenti genitori). Questo può essere particolarmente utile per garantire che il LLM abbia abbastanza contesto per sintetizzare una risposta.
Aggiustamento Fine del LLM per RAG
Benché l’accento sia posto sul recupero, la capacità del LLM di utilizzare il contesto recuperato è anch’essa importante. Se il LLM ha costantemente difficoltà ad estrarre risposte da documenti recuperati perfettamente pertinenti, potresti dover modificare la tua progettazione del prompt o addirittura perfezionare il LLM.
- Progettazione del Prompt: Assicurati che i tuoi inviti istruiscano chiaramente il LLM a rispondere *unicamente* in base al contesto fornito e a segnalare quando non riesce a trovare una risposta. Insisti su una risposta diretta e concisa.
- Perfezionamento delle Istruzioni: Per problemi più persistenti, perfeziona un LLM più piccolo su esempi in cui esso
Articoli Correlati
- Test di Performance dei Sistemi AI
- ChatGPT 5 Mancante? Perché Non Puoi Trovarlo (Ancora!)
- Test di Contratto dei Sistemi AI
🕒 Published: