Ci sono molte domande che si possono avere riguardo a una soluzione RAG:

• Come possiamo determinare le scelte di design che massimizzano le prestazioni di recupero?
• Come facciamo a sapere quale modello di incorporamento crea la migliore rappresentazione vettoriale dei nostri documenti?
• È necessario un approccio agentico?
• Un reranker potrebbe migliorare i nostri risultati? O forse queste scelte di parametri hanno un impatto marginale?

Avere una chiara strategia di valutazione durante lo sviluppo di una soluzione basata sulla RAG è fondamentale per garantire un percorso verso la produzione di successo. Durante i progetti pilota vediamo tutti i tipi di valutazioni empiriche che a volte non sono riproducibili. Per migliorare le prestazioni di una soluzione basata su RAG in fase di sviluppo o per diagnosticare correttamente un problema di produzione, le attività di valutazione devono essere riproducibili e rapide da eseguire. Le pipeline RAG dovrebbero essere valutate in modo sistematico e costante sia per i componenti di recupero che per quelli di generazione.

Comprendere le prestazioni delle soluzioni basate sulla RAG gioca un ruolo fondamentale in varie fasi del ciclo di vita della soluzione durante:

• Fase di sperimentazione e messa a punto
• Fase di monitoraggio

Tuttavia, lo sforzo per costruire un motore di valutazione non va sottovalutato, specialmente quando si tratta di creare un dataset d'oro (verità di base) con risposte e contesti di riferimento.

In questo documento, discuteremo diversi approcci e metriche di valutazione, oltre a mettere in evidenza alcune delle risorse riutilizzabili disponibili per rendere più semplice la valutazione di queste soluzioni.

Valutazione dell'AI dall'AI

L'LLMaaJ (LLM as a Judge) è emerso come una metrica leader nell'ultimo anno per superare la sfida di costruire un motore di valutazione basato su riferimenti. È stato dimostrato che questa tecnica di valutazione produce una discreta correlazione con il giudizio umano. Ecco alcune proprietà che non possono essere quantificate da metriche e benchmark esistenti, ma che possono essere valutate dall'LLMaaJ:

• Sicurezza: i modelli stanno generando contenuti dannosi o non sicuri?
• Concretezza: nel caso del riepilogo e della Retrieval-augmented generation, l'output generato è basato su fatti presenti nel contesto di input?
• Sentimento: le risposte generate sono generalmente positive, negative o qualsiasi altro sentimento prescritto?
• Tossicità: i modelli stanno generando contenuti offensivi, aggressivi o discriminatori?
• Stile linguistico: i modelli parlano con un tono di voce informale, formale o comune? Ciò include la valutazione del sarcasmo, dell'umorismo e dell'ironia.

Ad esempio, quando si utilizza un modello di punteggio per valutare l'output di altri modelli, il prompt del punteggio dovrebbe contenere una descrizione degli attributi da valutare e la scala di valutazione, e deve essere interpolato per includere la risposta da valutare.

In questo esempio, al modello viene chiesto di valutare lo stile linguistico della risposta e di restituire una classificazione.

Sei un giudice equo e imparziale. Ti viene chiesto di classificare la risposta di un chatbot in base al suo sentimento. Valuta la risposta qui sotto ed estrai la classe corrispondente. Le classi possibili sono POSITIVA, NEUTRA, NEGATIVA. Spiega il tuo ragionamento e concludi affermando il sentimento classificato.
{{response}}

Oppure, ad esempio, di seguito è riportato un esempio generazione di prompt few-shot di valutazione guidata da LLM per attività NER (riconoscimento di entità denominate).

---------------------Prompt-------------- ----------------- Sei un valutatore professionista e il tuo compito è valutare l'accuratezza dell'estrazione di entità come Punteggio in un determinato testo. Ti verrà fornito un testo, un'entità e il valore dell'entità.
Fornisci un punteggio numerico su una scala da 0 a 1, dove 1 è il punteggio migliore e 0 è il punteggio peggiore. Usa rigorosamente valori numerici per il punteggio.

Ecco gli esempi:

Testo: Dove si trova l'ufficio IBM a New York?
Entità: nome dell'organizzazione
Valore: IBM
Punteggio: 0

Testo: Chiama il servizio clienti al numero 1-800-555-1234 per ricevere assistenza.
Entità: numero di telefono
Valore: +1 888 426 4409
Punteggio: 1

Testo: watsonx ha tre componenti: watsonx.ai, watsonx.data, e watsonx.governance.
Entità: nome del prodotto
 Valore: Google
 Punteggio: 0,33

 Testo: La conferenza è prevista per il 15 agosto 2024.
Entità: data
 Valore: 15 agosto 2024
 Punteggio: 1

 Testo: I miei colleghi John e Alice parteciperanno alla riunione.
Entità: nome della persona
 Valore: Alice
 Punteggio: 1

 -----------------------------------Output---------------------------------------------Punteggio: 0,67
 -------------------------------------------------------------------------------------------

La complessità dei sistemi RAG è significativamente influenzata dalla natura enigmatica dei Large Language Models (LLM), così come dai componenti complessi e interconnessi all'interno della pipeline RAG. Poiché la tecnologia continua a progredire a un ritmo senza precedenti, la valutazione di un sistema così complesso diventa un compito sempre più arduo. Per affrontare questa sfida, sono stati sviluppati numerosi parametri di riferimento e strumenti di valutazione specifici per i sistemi RAG. Queste risorse servono a fornire un approccio standardizzato e sistematico per valutare le prestazioni e l'efficacia di questi sistemi.

Ad esempio, come illustrato nella tabella sottostante (adattata da "Valutazione della Retrieval-augmented generation: un sondaggio"), esiste una vasta gamma di metodi e strumenti di valutazione della RAG, ognuno con i suoi punti di forza e applicazioni unici. Questa tabella, che non è esaustiva, serve a fornire una panoramica concisa dell'attuale landscape della valutazione RAG.

Nel contesto della componente di recupero dei sistemi RAG, sorgono diverse sfide.

In termini di componente di recupero, le sfide sorgono principalmente a causa della natura estesa e dinamica degli archivi di conoscenza prospettici, delle sfaccettature temporali dei dati e dell'eterogeneità delle fonti di informazione. Considerando queste sfide, diventa evidente che le metriche di valutazione convenzionali, come Richiamo e Precisione, sono inadeguate e poco attrezzate per fornire una valutazione completa. Al contrario, è necessario un uso di metriche più sfumate e dipendenti dal contesto che possano catturare efficacemente le complessità e le sottigliezze del processo di recupero.

Per quanto riguarda la componente della generazione, è fondamentale considerare la relazione complessa tra la precisione del processo di recupero e la qualità dell'output generato. Ciò richiede lo sviluppo e l'implementazione di metriche di valutazione complete che possano fornire una valutazione olistica e sfumata delle prestazioni del sistema.

A sua volta, la valutazione del sistema RAG nel suo complesso richiede un esame approfondito dell'impatto della componente di recupero sul processo di generazione, nonché una valutazione dell'efficacia e dell'efficienza complessiva del sistema nel raggiungere gli obiettivi previsti.

La triade RAG è un quadro di valutazione per valutare l'affidabilità e l'accuratezza contestuale delle risposte del modello linguistico di grandi dimensioni (LLM). Consiste in tre valutazioni: rilevanza del contesto, fondatezza e pertinenza della risposta. Queste valutazioni mirano a identificare le allucinazioni delle risposte LLM, verificando la rilevanza del contesto, l'affidabilità della risposta rispetto al contesto e l'allineamento delle risposte con le richieste dell'utente.

La valutazione RAG può essere ottenuta utilizzando sia metriche automatiche basate su riferimenti che metriche senza riferimento. C'è una classifica su HuggingFace che analizza quanto bene si confrontano gli LLM open-source tra loro.

Metriche di recupero

Le metriche di recupero riportate di seguito sono basate sui riferimenti, il che significa che ogni blocco deve essere identificato in modo univoco (contexts_id) e ogni domanda ha ID univoci dei contesti di verità di base.

Le metriche di valutazione basate sulla classificazione utilizzate per i sistemi di raccomandazione sono appropriate per la RAG.

MRR (Mean Reciprocal Rank)

L'MRR viene utilizzato in Unitxt e misura la posizione del primo documento rilevante nei risultati di ricerca. Un MRR più alto, vicino a 1, indica che i risultati rilevanti appaiono in cima, riflettendo un'elevata qualità della ricerca. Al contrario, un MRR più basso significa prestazioni di ricerca inferiori, con le risposte rilevanti posizionate più in basso nei risultati.

Pro: sottolinea l'importanza del primo risultato pertinente, che è spesso critico negli scenari di ricerca.
Contro: una limitazione è che non penalizza il recupero per aver assegnato un basso rango ad altre verità fondamentali; non è adatto a valutare l'intera lista dei risultati recuperati, concentrandosi solo sul primo elemento rilevante.

NDCG (Normalized Discounted Cumulative Gain)

Metriche di qualità di classificazione che valutano quanto bene una lista di elementi è ordinata rispetto a una classifica ideale, in cui tutti gli elementi rilevanti sono posizionati in cima.

NDCG@k si calcola come DCG@k diviso per l'ideale DCG@k (IDCG@k), che rappresenta il punteggio di una lista perfettamente classificata di elementi fino alla posizione k. Il DCG misura la rilevanza totale degli elementi in un elenco.

varia da 0 a 1

Pro: tiene conto della posizione degli elementi pertinenti, fornendo una visione più olistica della qualità della classifica; può essere regolato per diversi livelli di classificazione (ad esempio, NDCG@k).
Contro: più complesso da calcolare e interpretare rispetto a metriche più semplici come l'MRR; richiede una classifica ideale per il confronto, che potrebbe non essere sempre disponibile o facile da definire.

MAP (Mean Average Precision)

La precisione media (MAP) è una metrica che valuta il posizionamento di ogni documento recuperato correttamente all'interno di un elenco di risultati.

È utile quando il sistema deve considerare l'ordine dei risultati e recuperare più documenti in una sola esecuzione.

Pro: considera sia la precisione che il richiamo, fornendo una valutazione equilibrata delle prestazioni di recupero; adatto per attività che richiedono più documenti pertinenti e il loro corretto ordinamento.
Contro: può essere più impegnativo in termini di calcolo rispetto a metriche più semplici; potrebbe non essere così semplice da interpretare come altre metriche, richiedendo più contesto per comprendere appieno i risultati.

Metriche di generazione

Fedeltà

Misura se l'output è basato sul contesto dato o se il modello genera risposte allucinate.

Pro: garantisce che le risposte generate siano affidabili e basate sul contesto fornito; fondamentale per le applicazioni in cui la correttezza dei fatti è fondamentale.
Contro: spesso la valutazione richiede il giudizio umano, il che la rende laboriosa e soggettiva; può non catturare completamente le imprecisioni parziali o le sottili allucinazioni.

Robustezza (insensibilità)

La robustezza è generalmente definita come la capacità della soluzione di adattarsi a diverse variazioni di input come perturbazioni dei dati come spazi bianchi, minuscole o maiuscole, tab, ecc.

La robustezza dei test è un aspetto importante del processo di valutazione e può essere raggiunto, ad esempio, utilizzando la semantica di Unitxt

Pro: garantisce che il modello funzioni in modo affidabile in varie condizioni di input; applicabilità nel mondo reale: importante per le applicazioni pratiche in cui i dati di input potrebbero non essere formattati perfettamente.
Contro: richiede test approfonditi su molte varianti, che possono richiedere molto tempo; definizione delle variazioni: difficile definire e misurare tutte le possibili perturbazioni di input.

ROUGE (Recall-Oriented Understudy for Gisting Evaluation)

Misura la qualità della generazione di testo confrontando la sovrapposizione di n-grammi, sequenze di parole e coppie di parole tra il testo generato dalla macchina e una serie di testi di riferimento. Ampiamente usato per valutare attività come il riassunto e la traduzione del testo.

Pro: consolidato e riconosciuto nella comunità NLP, che fornisce uno standard di confronto; adatto per attività in cui è importante acquisire tutte le informazioni pertinenti.
Contro: si concentra sulla sovrapposizione di n-grammi, che potrebbe non catturare la qualità o la fluidità semantica; può essere influenzato dalla lunghezza del testo generato, penalizzando potenzialmente output più brevi o concisi.

BLEU (Bilingual Evaluation Understudy)

Misura la qualità del testo tradotto automaticamente confrontandolo con una o più traduzioni di riferimento. Valuta la precisione degli n-grammi nel testo generato rispetto ai testi di riferimento. Utilizzato principalmente per valutare la traduzione.

Pro: efficace per le attività in cui la precisione e le corrispondenze esatte sono importanti; metrica standard: ampiamente adottata nella comunità della traduzione automatica, che fornisce un benchmark per il confronto.
Contro: può penalizzare le variazioni legittime nel fraseggio che non corrispondono esattamente ai testi di riferimento; cecità da imprecisione parziale: può non cogliere appieno le imprecisioni parziali o le sottili differenze di significato.

Metriche di costo

Utilizzo di GPU/CPU

L'utilizzo della CPU è utilizzato principalmente nella fase di recupero, mentre l'utilizzo della GPU è principalmente utilizzato nella fase di generazione.

Costo delle chiamate LLM

Esempio: Costo delle chiamate API di OpenAI

Costo delle infrastrutture

Costi di storage, networking, risorse informatiche, ecc.

Costo delle operazioni

Costi derivanti da manutenzione, supporto, monitoraggio, registrazione, misure di sicurezza, ecc.

Comprensione dei risultati della valutazione

Se le metriche di recupero indicano prestazioni subottimali, eppure le metriche di generazione producono risultati favorevoli, è consigliabile: 

1. Rivedere e adattare la strategia di suddivisione in blocchi (ad esempio, dimensione dei blocchi e sovrapposizione) per bilanciare meglio contesto e pertinenza.
2. Pulire e preprocessare i dati per rimuovere rumori e informazioni irrilevanti.
3. Aggiungere metadati, come le date, ai blocchi per aiutare a filtrare e dare priorità ai dati in base a casi d'uso specifici.
4. Implementare la riclassificazione: ciò consente al sistema di recupero di perfezionare i nodi principali in base al contesto. Sia LangChain che LlamaIndex* offrono astrazioni facili da usare per il reranking.
5. Chiedere all'LLM di riformulare la domanda e riprovare, poiché domande simili per gli esseri umani potrebbero non apparire simili nello spazio di embedding.
6. Mettere a punto gli embedding con LlamaIndex per una maggiore precisione.

Al contrario, se le metriche di recupero dimostrano ottime prestazioni ma i risultati della generazione non sono ottimali, si possono prendere in considerazione le seguenti strategie per migliorare le prestazioni del modello:

1. Perfezionare il modello linguistico: personalizza il modello in base al tuo dominio mettendolo a punto su set di dati pertinenti per migliorarne l'accuratezza e la comprensione contestuale.
2. Perfezionare il prompt engineering: sperimenta la struttura e la formulazione dei prompt per guidare il modello verso output più precisi.
3. Utilizzare diverse strategie di decodifica: regola le tecniche di decodifica come la ricerca del fascio, il campionamento top-k o il campionamento del nucleo (top-p) per migliorare la qualità delle risposte generate.
4. Controllare la lunghezza della generazione: imposta i vincoli sulla lunghezza della risposta per garantire che gli output siano concisi e accurati.
5. Incorporare cicli di feedback: implementa un sistema che identifica e corregge le risposte non ottimali, consentendo un miglioramento continuo.
6. Utilizzare dialoghi a più turni: scomponi compiti complessi in interazioni a più fasi, permettendo al modello di affinare le sue risposte su più iterazioni.

Nello scenario in cui sia le metriche di recupero che quelle di generazione mostrano prestazioni inferiori, sarebbe prudente rivedere e riconsiderare le fasi iniziali della pipeline, come il miglioramento dei metadati, il perfezionamento della base di conoscenza e l'ottimizzazione del meccanismo di recupero.

Questo approccio sottolinea l'importanza di una valutazione completa e dettagliata del sistema RAG, che tenga conto dell'interazione tra componenti di recupero e generazione e dell'efficacia complessiva del sistema nel raggiungimento degli scopi e degli obiettivi previsti.