Valutare la Retrieval-Augmented Generation (RAG): tutto ciò che dovresti sapere
Introduzione
Retrieval Augmented Generation (RAG) è diventato un approccio ampiamente adottato per implementare applicazioni di IA generativa basate su Large Language Models (LLMs). Integrando fonti di conoscenza esterne, RAG migliora la capacità del modello di fornire risposte più accurate e contestualmente pertinenti a query specifiche. Nonostante il suo potenziale, le risposte generate da RAG non sono sempre del tutto accurate o coerenti con la conoscenza recuperata.
In un recente webinar, Stefan Webb, Developer Advocate presso Zilliz, ha esplorato le strategie di valutazione per le applicazioni RAG, concentrandosi sui metodi per valutare le prestazioni degli LLM e affrontando le sfide e le limitazioni attuali nel settore.
In questo blog, riepilogheremo i principali spunti di Stefan, inclusa una panoramica di varie architetture di pipeline RAG, framework di retrieval e valutazione, ed esempi di bias e fallimenti negli LLM.
Architettura RAG
Stefan ha iniziato il talk introducendo il concetto fondamentale di semantic search, un componente critico delle applicazioni RAG. La semantic search sfrutta i vector databases, come Milvus o Zilliz, come sistemi di archiviazione della knowledge base per i vector embeddings. Questi database consentono ricerche efficienti su unstructured data per recuperare contesti semanticamente simili pertinenti alla query di un utente. Questa capacità costituisce la spina dorsale dei sistemi RAG, garantendo che la conoscenza recuperata sia strettamente allineata alla domanda in input, migliorando così la qualità delle risposte generate.
La Figura 1 qui sotto illustra un’architettura RAG di base e naïve. In questa configurazione, il sistema recupera i documenti più pertinenti in base alla loro semantic similarity rispetto alla domanda dell’utente. Le informazioni recuperate vengono quindi formattate in un prompt strutturato, completo di istruzioni, e passate all’LLM. Il modello utilizza questo contesto per generare una risposta ben informata.
Figura 1: RAG naïve
Figura 1: RAG naïve
Sebbene la pipeline RAG di base possa recuperare documenti pertinenti e generare risposte, le sue prestazioni non sono sempre ottimali. Alcuni output possono mancare di accuratezza o pertinenza. Per affrontare queste sfide, un approccio modulare alla costruzione della pipeline RAG consente miglioramenti incrementali in ogni fase.
Di seguito (come illustrato nella Figura 2) sono riportate tecniche chiave che possono migliorare l’efficacia della pipeline.
Figura 2: Architettura modulare RAG
Figura 2: Architettura modulare RAG (Fonte)
Traduzione della query
Questo passaggio si concentra sul garantire che la query dell’utente sia compresa correttamente dal sistema. Traduce le query in un formato o una rappresentazione che si allinea al meccanismo di retrieval sottostante.
Multi-query: suddivide la query principale in più sottoquery focalizzate per recuperare informazioni diverse ma pertinenti.
Step-back: riconsidera i passaggi precedenti nella pipeline quando vengono trovati risultati insufficienti, affinando la query per un retrieval migliore.
RAG Fusion: Unisce i risultati di più query per fornire un contesto coeso e completo per il LLM.
Documenti Ipotetici (HyDE): Prevede la generazione di documenti sintetici o contesti ipotetici che possono aiutare a recuperare documenti semanticamente simili dalla base di conoscenza, migliorando il recupero per query astratte o formulate in modo poco chiaro.
Instradamento delle Query
L'approccio di Instradamento delle Query indirizza la query al meccanismo di recupero o alla fonte di conoscenza più adatta.
Instradamento Logico: Instrada le query in base a regole predefinite o operatori logici, come il filtraggio per metadati o dominio.
Instradamento Semantico: Indirizza le query in base alle loro caratteristiche semantiche al database o sistema più adatto a gestirle.
Costruzione delle Query
La Costruzione delle Query perfeziona il modo in cui le query vengono formulate per corrispondere alla struttura dei database sottostanti.
DB Relazionale: Costruisce query simili a SQL per database relazionali tradizionali.
DB a Grafo: Utilizza query Cypher di attraversamento del grafo per esplorare nodi e relazioni nei database a grafo.
DB Vettoriale: Sfrutta gli embedding per creare query vettorializzate per ricerche di similarità semantica.
Indicizzazione
L'indicizzazione migliora l'organizzazione e l'accessibilità della base di conoscenza.
Ottimizzazione dei Chunk: Suddivide i documenti in chunk significativi e recuperabili preservando il contesto.
Indicizzazione Multi-rappresentazione: Crea più rappresentazioni (ad es., semantiche, sintattiche) dei dati per diverse esigenze di recupero.
Embedding Specializzati: Usa embedding specifici del dominio per migliorare il recupero di informazioni altamente specializzate o tecniche.
Indicizzazione Gerarchica: Struttura l'indice gerarchicamente per ricerche più rapide e accurate.
Recupero
Recupera i documenti o i contesti più rilevanti per una determinata query utilizzando tecniche avanzate.
Ranking: Assegna un punteggio ai documenti recuperati in base alla rilevanza, assicurando che le corrispondenze migliori abbiano la priorità.
RAG Correttivo: Regola il ranking in base al feedback o a criteri aggiuntivi per migliorare dinamicamente i risultati.
Ri-recupero: Recupera iterativamente documenti se i risultati iniziali non soddisfano le aspettative di qualità, perfezionando il processo finché non viene trovato un risultato accettabile.
Questo approccio modulare alla costruzione di una pipeline RAG perfeziona ogni componente in modo indipendente. Affrontando sfide specifiche in ogni fase, la pipeline diventa più robusta, accurata e adattabile, migliorando in definitiva la qualità degli output generati.
Valutazione dei Foundation Model
Che si utilizzi un approccio RAG semplice o avanzato, valutare le prestazioni di ciascuna applicazione RAG è essenziale. Questa valutazione aiuta a identificare punti di forza e debolezze, garantendo l'affidabilità e la rilevanza del sistema. Tutti i LLM, indipendentemente dalla sofisticazione, richiedono una rigorosa valutazione delle prestazioni per affrontare potenziali limitazioni, bias e imprecisioni.
Valutazione delle Prestazioni
Ma come misuriamo e valutiamo le prestazioni del modello? Misurare le prestazioni di un'applicazione RAG richiede un approccio sfumato, poiché è necessario valutare diversi aspetti della pipeline. Di seguito sono riportate considerazioni e metodi chiave per una misurazione efficace delle prestazioni:
Valutazione su un Task vs. Valutazione su Se Stesso
Valutazione del Task: Misura le prestazioni del modello su un insieme predefinito di task, che spesso includono scenari multi-turn (ad es., MT-Bench) o multi-task (ad es., MMLU). Ogni task è associato a specifiche domande di ground truth e risposte di riferimento.
Autovalutazione: Si concentra sulle metriche di prestazione interne, come l’efficacia con cui il modello recupera ed elabora le informazioni senza necessariamente collegarle a un caso d’uso pratico. Questo è utile per diagnosticare le prestazioni della pipeline.
Confronto tra risposte e verità di riferimento vs. contesto
Confronto con la verità di riferimento: Valuta quanto la risposta generata corrisponda a una risposta predefinita e accurata (verità di riferimento). Questo approccio funziona bene per attività oggettive come le query basate sui fatti.
Confronto contestuale: Esamina quanto la risposta sia allineata al contesto fornito dai documenti recuperati. Questo è particolarmente importante per attività in cui la verità di riferimento non è disponibile o è soggettiva, enfatizzando coerenza e pertinenza.
Valutazione del recupero vs. valutazione dell’output dell’LLM
Valutazione del recupero: Si concentra sulla qualità dei documenti recuperati dalla pipeline. Le metriche potrebbero includere richiamo e precisione tra i documenti recuperati e la query.
Valutazione dell’output dell’LLM: Esamina la qualità dell’output finale generato dal modello linguistico, considerando fattori come coerenza fattuale e pertinenza rispetto alla query e al contesto recuperato.
Valutazione umana come “gold standard”
- La valutazione umana rimane il metodo più affidabile per valutare le prestazioni, soprattutto per attività soggettive o complesse. Gli esseri umani possono valutare aspetti sfumati come coerenza logica, tono e creatività. Tuttavia, questo approccio non scala bene a causa dei requisiti di tempo e risorse.
Usare gli LLM per valutare gli LLM (LLM-as-a-Judge)
- LLM più avanzati ed efficienti (LLM-as-a-Judge) possono essere impiegati per valutare gli output di altri LLM, in particolare quando la verità di riferimento non è disponibile. Questi modelli possono assegnare punteggi alle risposte in base a criteri predefiniti come pertinenza e correttezza, offrendo un’alternativa scalabile alla valutazione umana. Tuttavia, è necessario prestare attenzione per evitare di introdurre bias dal modello valutatore stesso.
Stefan ha proseguito la discussione affrontando due approcci alla valutazione: valutazione basata sui compiti e autovalutazione. La valutazione basata sui compiti si basa tipicamente su benchmark disponibili pubblicamente, mentre l’autovalutazione si concentra maggiormente su misure interne o introspezione, come l’esame della qualità delle risposte generate e della pertinenza delle informazioni recuperate.
Valutazione basata sui compiti: l’approccio dei benchmark
La valutazione basata sui compiti si basa sull’uso di benchmark standard disponibili pubblicamente che valutano le prestazioni del modello su una varietà di compiti. Questi benchmark spesso coprono diversi domini di conoscenza, capacità di risposta alle domande e abilità conversazionali. Alcuni esempi includono:
Benchmark basati sulla conoscenza: Questi benchmark si concentrano sulla conoscenza generale e sulla risposta a domande basate sui fatti.
MMLU: Un benchmark diversificato che testa i modelli linguistici in più domini, tra cui matematica, scienze e storia.
HellaSwag: Un benchmark progettato per misurare il ragionamento di senso comune.
ARC: Un benchmark focalizzato sulla risposta a domande con capacità di ragionamento.
Benchmark di aderenza alle istruzioni: Questi benchmark valutano la capacità del modello di seguire istruzioni e generare risposte pertinenti.
Flan: Una serie di compiti che valutano le capacità di seguire istruzioni negli LLM.
Self-instruct: Valuta la capacità del modello di generare e seguire istruzioni autogenerate.
NaturalInstructions: Un benchmark su larga scala focalizzato sulla capacità del modello di seguire istruzioni in linguaggio naturale.
Benchmark conversazionali: Questi benchmark valutano la capacità del modello di partecipare a dialoghi coerenti e pertinenti.
CoQA: Un dataset conversazionale di domanda-risposta che testa i modelli su dialoghi multi-turno.
MMDialog: Un benchmark conversazionale che si concentra sulla qualità del dialogo in vari scenari.
OpenAssistant: un benchmark di IA conversazionale che valuta la capacità del modello di sostenere conversazioni naturali.
Sebbene i benchmark forniscano criteri di valutazione standardizzati, spesso non riescono a cogliere le sfumature dell’interazione umana, come l’intelligenza emotiva, il flusso conversazionale e la sensibilità al contesto. Per esempio, una risposta potrebbe essere fattualmente corretta secondo un benchmark ma risultare comunque carente in termini di naturalezza o empatia, elementi chiave che gli esseri umani apprezzano nelle conversazioni reali. Inoltre, i benchmark potrebbero non riflettere sempre la complessità delle preferenze umane, che possono variare in base al contesto, all’intento dell’utente e al tono emotivo. Questo è il motivo per cui la valutazione umana rimane un "gold standard" nella valutazione dell’IA conversazionale, poiché tiene conto delle preferenze umane che i benchmark spesso trascurano. Tuttavia, a causa dei costi e dell’elevato impiego di risorse della valutazione umana, metodi alternativi, come la valutazione basata sull’introspezione, possono essere considerati opzioni più scalabili.
Valutazione basata sull’introspezione
La valutazione basata sull’introspezione si concentra sulla valutazione della qualità delle risposte generate dal modello e del loro allineamento con il contesto, con l’obiettivo di misurare quanto bene gli output del modello aderiscano alle aspettative stabilite dall’input. Questo tipo di valutazione può essere suddiviso in due categorie principali: Valutazione basata sulla generazione e Valutazione basata sul recupero. Di seguito sono riportati alcuni esempi di metriche rilevanti:
Valutazione basata sulla generazione
Fedeltà (Groundedness): Questa metrica misura la coerenza fattuale della risposta generata rispetto al contesto fornito. Se il modello genera affermazioni che non possono essere supportate dal contesto recuperato, tali affermazioni vengono penalizzate. La fedeltà garantisce che l’output del modello sia sia coerente sia fondato sulle informazioni fornite.
Pertinenza della risposta: Questa metrica valuta quanto bene la risposta affronti direttamente la domanda dell’utente o il contesto fornito. Una risposta altamente pertinente sarà sia accurata sia appropriata al contesto, fornendo la risposta più utile alla query.
Valutazione basata sul recupero
Rilevanza del contesto: Misura quanto siano rilevanti i documenti o i contesti recuperati rispetto alla query. Idealmente, il contesto recuperato dovrebbe contenere solo le informazioni necessarie per rispondere alla domanda. Informazioni irrilevanti o estranee possono ridurre la qualità della risposta generata.
Richiamo del contesto: Questa metrica valuta quanto bene il contesto recuperato si allinei con la verità di riferimento, spesso utilizzando risposte annotate come riferimento. Aiuta a valutare se i documenti rilevanti siano stati recuperati in primo luogo, garantendo che il modello abbia informazioni sufficienti per generare una risposta significativa.
Per le metriche di Fedeltà, Pertinenza della risposta e Rilevanza del contesto, la mancanza di una verità di riferimento rappresenta una sfida per la valutazione diretta. Tuttavia, in assenza di una verità di riferimento, un metodo alternativo consiste nell’impiegare un LLM-as-a-Judge. Un LLM potente può essere utilizzato per attribuire un punteggio a questi aspetti analizzando la coerenza, la rilevanza e il fondamento fattuale della risposta. Confrontando le risposte generate con la propria comprensione del contesto e della rilevanza, il modello può fornire una valutazione automatizzata.
Sfide e limitazioni di LLM-as-a-Judge
Sebbene l’uso di un LLM-as-a-Judge possa essere un’alternativa utile per valutare le metriche quando non è disponibile una verità di riferimento, questo approccio introduce alcune sfide e limitazioni, che devono essere affrontate. Il modello valutatore stesso può introdurre bias, che possono influenzare la qualità e l’equità della valutazione. Di seguito sono riportati alcuni bias e sfide comuni che devono essere considerati.
Bias di posizione
Il bias di posizione si riferisce alla tendenza del modello valutatore a favorire le risposte in base alla loro posizione nella classifica o all’ordine in cui appaiono. In molti casi, il modello può presumere che la prima risposta o quella con il ranking più alto sia più pertinente o accurata, indipendentemente dalla sua qualità effettiva. Questo può portare a valutazioni inaccurate, soprattutto nei casi in cui la risposta corretta è classificata più in basso a causa del bias del modello verso le posizioni di vertice.
Figura 3: Bias di posizione
Figura 3: Bias di posizione (Fonte)
Bias di verbosità
Il bias di verbosità si verifica quando il modello valutatore tende a favorire risposte più lunghe e dettagliate, anche se non sono necessariamente più accurate o pertinenti. In alcuni casi, il modello può equiparare erroneamente la verbosità alla qualità, assegnando punteggi più alti a risposte più lunghe che contengono informazioni non necessarie. Questo può distorcere il processo di valutazione, soprattutto in contesti in cui sono preferibili risposte concise e chiare.
Figura 4: Bias di verbosità
Figura 4: Bias di verbosità (Fonte)
Giudizio errato
Un’altra limitazione è la possibilità di giudizi errati. Un LLM-as-a-Judge, come qualsiasi modello, può commettere errori nel valutare la qualità o la pertinenza di una risposta. Ad esempio, può interpretare male il contesto, trascurare dettagli sottili o non riuscire a riconoscere le sfumature nella risposta, portando a risultati di valutazione errati o fuorvianti
Figura 5: Giudizio errato
Figura 5: Giudizio errato (Fonte)
Giudizio errato con Chain-of-Thought
Il ragionamento Chain-of-Thought (CoT) nella valutazione basata su LLM introduce complessi meccanismi di propagazione degli errori che possono compromettere significativamente l’accuratezza della valutazione. Ogni passaggio intermedio del ragionamento agisce come un potenziale punto di errore, in cui anche una lieve interpretazione errata o un’incoerenza logica può propagarsi in errori sempre più sostanziali nel giudizio finale. Ad esempio, se un passaggio iniziale nella catena di ragionamento fraintende una sfumatura contestuale chiave o pondera in modo errato un particolare aspetto della risposta, i passaggi successivi del ragionamento si baseranno su questa base imperfetta, amplificando esponenzialmente l’errore iniziale.
Figura 6: Giudizio errato con Chain-of-thought
Figura 6: Giudizio errato con Chain-of-thought (Fonte)
Questi bias evidenziano l’importanza di adottare strategie di valutazione che affrontino i limiti degli approcci LLM-as-a-Judge. Una soluzione è utilizzare modelli LLM specificamente sottoposti a fine-tuning per scopi di valutazione, come GroundedAI, o Flow-Judge-v0.1. Un’altra strategia è combinare le valutazioni LLM-as-a-Judge con valutazioni umane ogni volta che è possibile. I valutatori umani apportano una comprensione sfumata e una consapevolezza contestuale che i modelli automatizzati possono non avere. Anche audit regolari e miglioramenti iterativi ai modelli valutatori sono essenziali per minimizzare i bias e migliorare l’affidabilità.
Framework di valutazione open-source
Oltre alle tecniche LLM-as-a-Judge, diversi framework di valutazione open-source sono ampiamente utilizzati sul mercato per valutare le applicazioni RAG. Questi framework forniscono metodologie e strumenti strutturati per valutare efficacemente le prestazioni di recupero e generazione:
RAGAS: Un framework per valutare i sistemi RAG con metriche adattate alle applicazioni RAG.
DeepEval: Uno strumento flessibile e robusto per valutare sistemi RAG o di fine-tuning su molteplici metriche di valutazione.
ARES: Progettato per la valutazione dei modelli RAG, con enfasi sulla rilevanza del contesto, la fedeltà della risposta e la rilevanza della risposta.
HuggingFace Lighteval: Fornisce strumenti leggeri ed estensibili per valutare applicazioni RAG su molteplici backend (ad es., transformers, tgi, vllm o nanotron).
Questi framework semplificano il processo di valutazione e aiutano a standardizzare le metriche di performance tra sistemi diversi, favorendo comparabilità e miglioramento.
Conclusione
Retrieval-Augmented Generation (RAG) è un approccio trasformativo per potenziare le capacità dei Large Language Models (LLM). Tuttavia, il suo successo dipende da una valutazione robusta e da un perfezionamento continuo. Come ha evidenziato Stefan nel webinar, la pipeline RAG è complessa e comprende molteplici fasi, dalla traduzione della query alla generazione della risposta finale. Le sfide sono significative—dalla mitigazione dei bias nelle valutazioni LLM-as-a-Judge al garantire un retrieval preciso e alla generazione di risposte che soddisfino le aspettative degli utenti.
Il punto chiave è che non esiste una soluzione valida per tutti per la valutazione RAG. Raggiungere il successo richiede un approccio sfumato e multiforme che combini diverse tecniche di valutazione: benchmark basati sui task, metriche introspettive, framework di valutazione open-source e—quando fattibile—valutazione umana. Strumenti come RAGAS, DeepEval e ARES offrono un supporto prezioso, ma non sono risposte definitive. Rappresentano invece strumenti in evoluzione nel panorama in continuo avanzamento dell’IA generativa.
Guardando al futuro, il futuro di RAG risiede nella sua adattabilità e nel suo continuo perfezionamento. Man mano che i sistemi di IA diventano più sofisticati, la capacità di valutare e migliorare le loro prestazioni sarà essenziale per sbloccare il loro pieno potenziale. Affrontando le limitazioni attuali e adottando metodi di valutazione innovativi, le applicazioni RAG possono fornire costantemente informazioni accurate, contestualmente rilevanti e affidabili, guidando il progresso nel campo dell’IA.
Ulteriori letture
Continua a leggere
The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery
Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.
A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud
Milvus 2.6 marks a shift from “vector search + glue code” to a more advanced retrieval engine, and it is now Generally Available (GA) on Zilliz Cloud (a managed Milvus service).
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.