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 così radicalmente le allucinazioni e migliorando l’accuratezza dei fatti. Tuttavia, questa promessa si scontra spesso con la realtà del “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 diminuisce. Non si tratta 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 precisione di recupero nelle tue applicazioni RAG. Andremo oltre le correzioni superficiali ed esploreremo i componenti chiave che influenzano la qualità del recupero, offrendo consigli praticabili 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 fare debug efficacemente della precisione di recupero, dobbiamo avere una comprensione chiara del pipeline RAG. Esso prevede generalmente più fasi, ciascuna delle quali è una potenziale fonte di errore. Consideralo come una catena: una debolezza in un anello può compromettere l’intero sistema.
Le fasi chiave del recupero RAG
- Ingestione e pre-elaborazione dei documenti: I dati grezzi (PDF, pagine web, database) vengono raccolti, puliti e strutturati. Questo include il parsing, la normalizzazione e spesso, l’estrazione di metadati.
- Suddivisione: I grandi documenti vengono suddivisi in “pezzi” o passaggi più piccoli e gestibili. Questo è cruciale poiché i modelli di embedding hanno limiti di token, e pezzi più piccoli consentono un recupero più preciso.
- Generazione di embeddings: Ogni pezzo viene convertito in un vettore numerico (un embedding) utilizzando un modello di embedding. Questi embeddings catturano il significato semantico del testo.
- Archiviazione in un database di vettori: Gli embeddings (con i loro pezzi di testo e metadati corrispondenti) vengono archiviati in un database di vettori, ottimizzato per una ricerca di similarità rapida.
- Embedding della query: Quando l’utente pone una query, questa viene anch’essa convertita in un embedding utilizzando lo stesso modello di embedding.
- Ricerca di similarità: L’embedding della query viene utilizzato per cercare nel database di vettori gli embeddings dei pezzi più simili.
- Assemblaggio del contesto: I pezzi recuperati vengono poi assemblati e trasmessi come contesto al LLM, insieme alla query 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 conoscenza. Questo spesso significa che le informazioni pertinenti non sono state recuperate.
- Risposte non pertinenti: La risposta del LLM è precisa 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 di dettagli chiave presenti nei tuoi documenti sorgente. 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 risposte imprecise o inutili sono l’indicatore finale.
Diagnosticare i 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.
Passo 1: Ispezionare direttamente i pezzi recuperati
Il modo più diretto per fare debug consiste nel bypassare completamente il LLM e esaminare ciò che il tuo recuperatore restituisce realmente per una data query. La maggior parte dei client di 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 per la query?
- Contengono le informazioni necessarie per rispondere alla query?
- Ci sono pezzi manifestamente non pertinenti tra i N migliori?
- Le informazioni sono complete, o sono frammentate in diversi pezzi che dovrebbero 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 visione sull’origine del problema, prima della fase del LLM.
Passo 2: Valutare le strategie di pre-elaborazione dei documenti e suddivisione
La qualità dei tuoi pezzi impatta direttamente il recupero. Pezzi mal formati sono una causa comune di problemi di precisione.
Trappole comuni e soluzioni:
- Pezzi troppo grandi: Un pezzo troppo voluminoso può contenere più argomenti, diluendo il segnale semantico di un argomento unico. Quando la query è specifica, un grosso pezzo può essere recuperato, ma la parte pertinente è sepolta, o l’embedding potrebbe non rappresentare con precisione le informazioni più importanti.
Soluzione: Sperimenta con dimensioni di pezzi più piccole (ad esempio, 200-500 token con un certo sovrapposizione). Utilizza strumenti che rispettano la struttura del documento (paragrafi, sezioni) invece di tagli arbitrari di caratteri.
- Pezzi troppo piccoli: Se i pezzi sono troppo piccoli, informazioni critiche possono essere frammentate in diversi pezzi, rendendo difficile per il recuperatore raccogliere 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 (ad esempio, 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, anteponi il titolo del documento o l’intestazione di sezione a ogni pezzo derivato da quella sezione. Alcune strategie avanzate di suddivisione tentano 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(): # Anteporre il titolo a ogni 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 di altri documenti complessi fallisce, potresti trovarti con testo incompleto, sezioni mancanti o struttura errata prima ancora che inizi la suddivisione.
Soluzione: Utilizza librerie di parsing consolidate (es.
pypdf,unstructured-io) e ispeziona visivamente l’output analizzato per un campione di documenti.
Passo 3: Valutare le performance del modello di embedding
Il modello di embedding è il cuore della ricerca semantica. Se non cattura fedelmente il significato dei tuoi pezzi e query, il recupero ne risentirà.
Trappole comuni e soluzioni:
- Dominio inadeguato : Un modello di incorporazione a uso generale potrebbe non funzionare bene con un gergo molto 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 dominio, oppure utilizza 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 evolve. I modelli di incorporazione più vecchi potrebbero non catturare le sfumature altrettanto efficacemente rispetto ai più recenti.
Soluzione : Rimani aggiornato sui nuovi modelli di incorporazione. Testa regolarmente il tuo modello attuale rispetto a nuove alternative.
- Granularità semantica insufficiente : Il modello potrebbe avere difficoltà a distinguere concetti strettamente correlati ma distinti.
Soluzione : Questo è più difficile da correggere direttamente senza affinare il modello. Tuttavia, un migliore frazionamento e l’aggiunta di metadati più precisi possono aiutare a disambiguare.
Consiglio pratico : Metti alla prova direttamente l’efficacia del tuo modello di incorporazione. Prendi una richiesta e alcuni frammenti noti come pertinenti, insieme ad alcuni frammenti noti come non pertinenti. Calcola le loro incorporazioni e misura la similarità coseno tra l’incorporazione della richiesta e ogni incorporazione di frammento. I frammenti pertinenti dovrebbero avere punteggi di similarità significativamente più alti.
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 20° 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
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_ksottodimensionale : Recuperare troppo pochi frammenti potrebbe far perdere informazioni cruciali. Recuperare troppi risultati può introdurre rumore e superare la finestra di contesto del LLM, portando a una prevalenza 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, specialmente 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 richieste. Molti database vettoriali offrono questa capacità direttamente o attraverso un’integrazione 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) # Combinare e riordinare i risultati, ad esempio, utilizzando la Fusione di Ranking Reciproco (RRF) combined_results = combine_and_rank(semantic_results, keyword_results) return combined_results[:top_k] - Filtraggio delle Metadati Scadente : 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 richiesta interroga sulle “politiche recenti”, filtra i documenti per data prima della ricerca semantica.
- Problemi di Rivalutazione : Il recupero iniziale può restituire un ampio insieme di candidati. Una fase di rivalutazione può quindi classificare questi candidati più precisamente rispetto alla richiesta.
Soluzione : Integra un modello di rivalutazione (ad esempio, un modello cross-encoder come
cohere/rerank-english-v3.0o un modello BERT più piccolo). I rivalutatori prendono sia la richiesta sia 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 insiemi di dati molto grandi, la scelta dell’indice (ad esempio, HNSW, IVF) e dei 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 affrontati i problemi fondamentali, considera queste tecniche avanzate per ulteriori miglioramenti.
Trasformazione e Espansione delle Richieste
Per alcuni, la richiesta iniziale dell’utente non è ottimale per una ricerca diretta. Potrebbe essere troppo breve, ambigua o utilizzare una formulazione diversa rispetto ai tuoi documenti.
- Riscrittura della Richiesta : Utilizza un LLM per riscrivere la richiesta dell’utente in diverse forme alternative o per ampliarla con più contesto.
Esempio di Prompt : “L’utente ha richiesto : ‘{original_query}’. Si prega di generare 3 modi alternativi per formulare questa domanda che siano appropriati per cercare in un database di documenti. Concentrati sulle parole chiave e sui concetti pertinenti. Output sotto forma di una lista JSON.”
- HyDE (Hypothetical Document Embedding) : Genera una risposta o un documento ipotetico basato sulla richiesta utilizzando un LLM. Dopodiché, integra questo documento ipotetico e utilizza la sua integrazione per il recupero. Questo può colmare il divario tra lo spazio della richiesta 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 di Documento Genitore
Queste tecniche mirano a superare le limitazioni dei frammenti di dimensione fissa.
- Recupero Multi-Vettore : Invece di una sola 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, quindi restituisci il frammento completo.
- Recupero di Documento Genitore : Integra e recupera frammenti più piccoli e granulari. Una volta identificati frammenti pertinenti di piccole dimensioni, recupera il loro “documento genitore” più grande o un frammento più ampio che li contiene. Questo fornisce sia precisione (derivante da piccoli frammenti) che un contesto più ampio (derivante da documenti genitori). Questo può essere particolarmente utile per garantire che il LLM abbia sufficiente contesto per sintetizzare una risposta.
Aggiustamento Fine del LLM per RAG
Anche se l’accento è posto sul recupero, la capacità del LLM di utilizzare il contesto recuperato è anch’essa importante. Se il LLM ha costantemente difficoltà a estrarre risposte da documenti recuperati perfettamente pertinenti, potresti dover rivedere la tua progettazione del prompt o persino affinare il LLM.
- Progettazione del Prompt : Assicurati che le tue istruzioni indichino chiaramente al LLM di rispondere *solo* in base al contesto fornito e di segnalare quando non riesce a trovare una risposta. Sottolinea l’importanza di una risposta diretta e concisa.
- Affinamento delle Istruzioni : Per problemi più persistenti, affina un LLM più piccolo su esempi in cui è
Articoli Correlati
- Test di performance dei sistemi AI
- ChatGPT 5 Mancante? Perché Non Puoi Trovarlo (Ancora!)
- Test di contratto dei sistemi AI
🕒 Published: