Come misurare il successo del tuo sistema LLM basato sul RAG

Come valutare il successo del tuo sistema LLM con il metodo RAG

Utilizza le macchine per valutare le macchine

Incluso un nuovo metodo innovativo per valutare le risposte con un punteggio qualitativo e una spiegazione dettagliata.

Immagine generata da Stable Diffusion XL

La Generazione di Ricerca potenziata, o RAG, è sicuramente il caso d’uso più comune per i Modelli di Linguaggio di Ampia Dimensione (LLM) che sono emersi quest’anno. Mentre la sintesi e la generazione di testo sono spesso l’obiettivo degli utenti singoli, le aziende hanno capito che hanno bisogno della capacità di utilizzare i loro dati per sfruttare questa tecnologia. Riflettendo su come ancora utilizzo gli LLM, la generazione di testo è in alto nella lista. Voglio fare domande a Bard e fargli cercare nel web; voglio che Claude riscriva email o post del blog per rendere più interessanti i miei contenuti. Ma l’uso più entusiasmante che ho incontrato è inviare i miei dati al LLM. Voglio cercare tra le mie note, email, calendario e messaggi Slack e fare in modo che Llama funzioni come un’altra me (ma una me che può ricordare i dettagli di ciò che è successo prima di oggi).

Questo non è un post su come costruire una RAG (ce ne sono molti già disponibili… e sto lavorando a quel post per un altro giorno). Quello che esploreremo oggi è come valutare i sistemi RAG.

Come otteniamo i dati da un RAG?

Livelliamo prima di entrare nei dettagli. Quando parliamo di un RAG, ci riferiamo a due parti del sistema.

La fonte di conoscenza

Una fonte di conoscenza può essere un database vettoriale, un motore di ricerca, alcuni file di testo caricati in memoria, dati SQL o qualsiasi cosa in cui i nostri dati siano archiviati.

LLM

Una volta che abbiamo i nostri dati, li trasferiamo nel LLM. Questo avviene tramite la finestra di contesto. Quindi, in definitiva, cerchiamo, otteniamo un po’ di testo, inseriamo quel testo trovato in una prompt e passiamo la nostra domanda al LLM. Il modello quindi prende tutto da quella finestra di contesto e fornisce una risposta.

Perché è importante?

Quando parliamo di valutare un sistema RAG, dobbiamo sapere cosa valuteremo prima di definire come farlo. Possiamo vedere ora che due componenti devono essere esaminate. Il recupero iniziale dei dati è la parte più critica qui. Gli LLM, in generale, sono bravi a sintetizzare/rispondere alle domande con i dati forniti nel contesto. Quello che potrebbe mancare è la funzionalità di ricerca vera e propria.

Queste fonti di conoscenza hanno alcune limitazioni intrinseche. Ad esempio, quando si utilizzano database vettoriali per archiviare grandi file di testo, è necessario “segmentare” i dati in ingresso. Cosa significa questo? Supponiamo di avere un documento di 100 pagine, ma il database può gestire solo il salvataggio di 1 pagina alla volta. Una volta che hai caricato i tuoi documenti e vai a cercare, il database può esaminare solo una singola pagina alla volta (ok, questo è un po’ riduzionista, ma rende l’idea; è abbastanza vicino al lavoro governativo). Quando troviamo dati che corrispondono alla nostra ricerca, c’è una vera possibilità che l’intera risposta alla nostra domanda non sia presente solo su quella singola pagina. Peccato! Otteniamo solo una singola pagina! Questo è un buon esempio di perché c’è bisogno di esaminare questa parte del sistema prima di preoccuparsi dell’output del LLM.

Cosa dobbiamo valutare?

Questo non sarà la risposta che la maggior parte dei tecnologi vorrebbe sentire. Sarà necessaria una certa valutazione umana per valutare i risultati provenienti dalla fonte di conoscenza. Perché? Beh, se un’azienda sta utilizzando i propri dati e sono privati, sarà difficile automatizzare i test per verificare che i risultati della ricerca siano completamente accurati. Non temere, non deve essere tutto manuale al 100%; possiamo automatizzare parte di esso. Approfondiamo un po’ di più.

Vedo due implementazioni per questa validazione e valutazione iniziale.

La prima opzione è avere un set di domande comuni e attese per il set di dati e far verificare i risultati della ricerca a un team di QA umano. Ad esempio, se il tuo team è incaricato di costruire un chatbot di assistenza clienti per una banca, alcune domande comuni potrebbero essere: “Qual è l’importo minimo che devo mantenere sul mio conto?”, “Come faccio a effettuare un pagamento sul mio prestito?”, “A che ora apre la mia filiale?”. È ideale se i tuoi QA possono fornire sia le domande che le risposte attese in un file CSV che può essere letto in modo programmato; quindi, possiamo utilizzare alcuni dei nostri test automatizzati che tratteremo un po’ più avanti in questo post.

Se il tempo o le risorse non sono disponibili per questo, il secondo metodo prevede la ricerca e la revisione in tempo reale da parte di un team di QA. Questa è un’opzione per i primi POC e i prototipi, ma attenzione, non sarà scalabile per carichi di lavoro di produzione effettivi.

La valutazione delle risposte LLM

Una volta raggiunto un certo livello di fiducia che i dati della nostra fonte di conoscenza sono affidabili, dobbiamo assicurarci che le risposte finali siano accurate. I sistemi RAG sono ottimi per ridurre la possibilità di allucinazioni, e ciò può essere ampliato regolando le istruzioni di base. Tuttavia, potrebbe trascurare informazioni, fraintendere i dati forniti o cercare di introdurre conoscenze aprioristiche dal suo addestramento.

La valutazione di questo passaggio è simile alla valutazione della ricerca precedente. Se i team di QA possono fornire domande e risposte attese, possiamo cercare di valutare le risposte in modo programmato.

Diamo ora un’occhiata ad alcune di queste opzioni.

Framework di valutazione

È essenziale ricordare che LLM e RAG sono molto prematuri nel loro ciclo di maturità. È passato solo un anno dal debutto di ChatGPT e ogni giorno porta nuovi avanzamenti, modelli, framework e ricerche in questo campo. Detto questo, un piccolo numero di metriche sta diventando il modo standard per misurare le prestazioni di questi sistemi.

Non discuteremo dei modi per valutare il LLM di base. Ci sono cose come ARC, MMLU, HellaSwag, ecc., che mirano tutti al modello di linguaggio di base. Non è necessario eseguire queste misure da soli; puoi controllare siti come https://llm-leaderboard.streamlit.app/ e https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard per vedere come si comportano modelli diversi. Siamo interessati solo a misurare i risultati che otteniamo dai sistemi RAG.

Questo ci porta a esaminare algoritmi come ROUGE, BLEU, BLUERT e METEOR. Diamo un’occhiata più da vicino a ognuno. Includerò anche uno snippet di codice per mostrare come chiamare ciascuna metrica e qual è l’aspetto dello score di output. Importo il framework di valutazione per iniziare e includo il riferimento e la risposta che desidero valutare.

!pip install evaluate --quiet!pip install rouge_score --quiet!pip install importlib-metadata --quiet!pip install datasets==2.10.1 --quiet !pip install git+https://github.com/google-research/bleurt.git --quiet!pip install sacrebleu --quiet!pip --no-cache-dir install bert_score==0.3.9 --quiet!pip install sacremoses --quiet!pip install jiwer==2.5.1 --quiet!pip install Cython import evaluate# Se hai un corpus di traduzione e di riferimento:predictions = ["In Dungeons & Dragons, i draghi metallici sono di ottone, bronzo, rame, oro e argento. Ognuno ha le scaglie dei colori corrispondenti ai loro nomi - i draghi di ottone hanno le scaglie di ottone, quelli di bronzo hanno le scaglie di bronzo, ecc. I draghi metallici sono generalmente più benigni dei draghi cromatici nelle leggende di D&D."]references =["""I cinque draghi cromatici di base (rosso, blu, verde, nero e bianco) e i draghi metallici (rame, ottone, argento, oro e bronzo) sono apparsi nel Manuali dei mostri della quinta edizione (2014) in versione cucciolo, giovane, adulto e antico. Draghi gemma e altri draghi nuovi per la quinta edizione sono apparsi in Tesoro dei draghi di Fizban (2021)"""]

ROUGE (Recall-Oriented Understudy for Gisting Evaluation)

ROUGE è un insieme di metriche per valutare la riassunzione automatica e l’output della traduzione automatica. Si basa sul conteggio degli n-grammi sovrapposti tra l’output del sistema e i riepiloghi di riferimento.

#predictions (lista): elenco delle previsioni da valutare. Ogni previsione dovrebbe essere una stringa con i token separati da spazi.#references (lista o lista[lista]): elenco di riferimenti per ogni previsione o un elenco di diversi riferimenti per previsione. Ogni riferimento dovrebbe essere una stringa con i token separati da spazi.#rouge_types (lista): lista di tipi di rouge da calcolare. Valori predefiniti: ['rouge1', 'rouge2', 'rougeL', 'rougeLsum'].#Tipi di rouge validi:##"rouge1": punteggio basato su unigrammi (1-grammi)##"rouge2": punteggio basato su bigrammi (2-grammi)##"rougeL": punteggio basato sulla sottosequenza comune più lunga.##"rougeLSum": divide il testo usando "\n"#use_aggregator (booleano): Se True, restituisce i risultati aggregati. Valore predefinito: True.#use_stemmer (booleano): Se True, utilizza il stemmer di Porter per rimuovere i suffissi delle parole. Valore predefinito: False.rouge = evaluate.load('rouge')results = rouge.compute(predictions=predictions, references=references, use_aggregator=False)print(results)

{'rouge1': [0.3636363636363636], 'rouge2': [0.06185567010309278], 'rougeL': [0.22222222222222224], 'rougeLsum': [0.22222222222222224]}

BLEU (Bilingual Evaluation Understudy)

BLEU è una metrica per la valutazione automatica dell’output della traduzione automatica. Si basa sulla precisione degli n-grammi della traduzione candidata rispetto a un insieme di traduzioni di riferimento.

#predictions (elenco di stringhe): traduzioni da valutare.#references (elenco di elenchi di stringhe): riferimenti per ogni traduzione.#max_order (int): massimo ordine dell'n-gramma da utilizzare nel calcolo del punteggio BLEU. Valore predefinito: 4.#smooth (booleano): Se True, applica la smoothing di Lin et al. 2004. Valore predefinito: False.#bleu (float): punteggio BLEU#precisions (elenco di float): media geometrica delle precisioni degli n-grammi,#brevity_penalty (float): penalità di brevità,#length_ratio (float): rapporto delle lunghezze,#translation_length (int): lunghezza della traduzione,#reference_length (int): lunghezza del riferimentobleu = evaluate.load(“bleu”) results = bleu.compute(predictions=predictions, references=references,max_order=4)print(results)

{'bleu': 0.07342349837092484, 'precisions': [0.4262295081967213, 0.11666666666666667, 0.03389830508474576, 0.017241379310344827], 'brevity_penalty': 1.0, 'length_ratio': 20.333333333333332, 'translation_length': 61, 'reference_length': 3}

BLEURT (BLEU Regression with Transformers)

BLEURT è una metrica di valutazione per la generazione di linguaggio naturale (NLG). Si basa su BERT, che consente a BLEURT di apprendere le relazioni statistiche tra parole e frasi e di identificare i pattern nell’output di NLG.

BLEURT ha dimostrato di superare altre metriche di valutazione di NLG, come BLEU e ROUGE, in una varietà di compiti, tra cui la traduzione automatica, il riassunto e la risposta alle domande.

#output è sempre un numero compreso tra 0 e (approssimativamente) 1. #Questo valore indica quanto sia simile il testo generato rispetto ai testi di riferimento, con valori più vicini a 1 che rappresentano testi più simili.bleurt = evaluate.load("bleurt", module_type="metric")results = bleurt.compute(predictions=predictions, references=references)print(results)

{'scores': [0.6028875708580017]}

METEOR (Metric for Evaluation of Translation with Explicit ORdering)

METEOR è una metrica di valutazione automatica per l’output della traduzione automatica. Ha anche funzionalità non presenti in altre metriche, come il troncamento, la corrispondenza sinonimica e la corrispondenza esatta delle parole standard. La metrica è stata progettata per risolvere alcuni dei problemi riscontrati nella metrica BLEU più popolare e produrre anche una buona correlazione con il giudizio umano a livello di frase o segmento.

#predictions: un elenco di previsioni da valutare. Ogni previsione dovrebbe essere una stringa con i token separati da spazi.#references: un elenco di riferimenti (nel caso di un riferimento per ogni previsione), o un elenco di elenchi di riferimenti (nel caso di più riferimenti per ogni previsione). Ogni riferimento dovrebbe essere una stringa con i token separati da spazi.#alpha: parametro per controllare il peso relativo di precisione e richiamo. Il valore predefinito è 0,9.#beta: parametro per controllare la forma della penalità in funzione della frammentazione. Il valore predefinito è 3.#gamma: il peso relativo assegnato alla penalità di frammentazione. Il valore predefinito è 0,5.#outputs 0-1 - .317 è un punteggio accettabilemeteor = evaluate.load('meteor')results = meteor.compute(predictions=predictions, references=references)print(results)

{'meteor': 0.19316493313521543}

Mi è stato promesso qualcosa di nuovo!

Anche se ho la tua attenzione, vorrei presentare una nuova idea. Sebbene quei quattro algoritmi ti forniscano un punteggio quantificabile che consente al tuo team di QA di determinare rapidamente se una risposta/riassunto è simile, ci sono alcune limitazioni.

Innanzitutto, le frasi di riferimento e il risultato possono essere sufficientemente simili per rispondere alle domande degli utenti, ma possono comunque ricevere un punteggio basso. È essenziale eseguire un insieme noto di domande e risposte per stabilire una buona linea di base e confrontare le risposte future con questa linea di base.

In secondo luogo, non ti dice perché il punteggio è basso. È a causa di una penalità per la ripetizione delle parole? È perché mancano alcune parole? Il riassunto ha completamente tralasciato una parte essenziale della risposta? Non c’è un modo per saperlo.

Infine, il fatto che una risposta riceva un punteggio basso non significa necessariamente che un essere umano la considererebbe insufficiente o errata. La linea di base può essere utile per stabilire quali potrebbero essere i punteggi accettabili, ma è importante essere scettici nell’utilizzare questi punteggi per giudicare le risposte RAG.

LLMs che valutano LLMs

BLEURT ci ha introdotto all’idea che possiamo usare LLMs in qualche modo per valutare le risposte di un sistema RAG. E se sfruttassimo direttamente questo? Insegniamo a un LLM di fornire un punteggio qualitativo per la nostra risposta e fornire sia motivi puntuali che una spiegazione narrativa del punteggio assegnato. Questo ci offre il meglio dei due mondi. Possiamo estrarre un punteggio numerico da riportare agli utenti e al QA in un rapporto; possiamo anche fornire maggiori dettagli su perché una risposta ha ottenuto un punteggio basso.

Ecco un esempio di modello di prompt che può essere utilizzato per ClaudeV2. Passiamo le istruzioni su come vogliamo che il modello valuti la nostra risposta, passiamo i dati di riferimento e passiamo la risposta che abbiamo ricevuto dal nostro sistema RAG.

prompt_data = """Umano: Devi valutare un riassunto su una scala da 0 a 10, con 0 che indica totalmente scorretto e 10 che indica un riassunto perfetto del testo fornito. Spiega perché dai quel punteggio. Fornisci un elenco puntato delle principali differenze tra il riferimento e il riassunto. Fornirò un testo di riferimento indicando REF: e il riassunto da confrontare con SUMMARY:.REF:I cinque draghi cromatici di base (rosso, blu, verde, nero e bianco) e i draghi metallici (rame, ottone, argento, oro e bronzo) sono apparsi nel Manuale dei Mostri della quinta edizione (2014) nelle fasi di giovane, adulto e antico. Draghi gemma e altri draghi introdotti per la prima volta nella quinta edizione sono apparsi in Fizban's Treasury of Dragons (2021)SUMMARY:In Dungeons & Dragons, i draghi metallici sono presenti in varietà di ottone, bronzo, rame, oro e argento. Ognuno ha squame con tonalità che corrispondono al nome - i draghi di ottone hanno squame di ottone, i draghi di bronzo hanno squame di bronzo, ecc. I draghi metallici sono generalmente più benigni dei draghi cromatici nel lore di D&D.Assistente:"""

Punteggio: 5/10Spiegazione: Il riassunto cattura alcune informazioni accurate di alto livello sui draghi metallici in D&D, come l'elenco dei principali tipi e la nota sulla loro natura più benigna rispetto ai draghi cromatici. Tuttavia, tralascia molti dettagli fondamentali del testo di riferimento:- Non menziona i draghi cromatici (rosso, blu, verde, nero, bianco) che sono stati descritti.- Non menziona le diverse categorie di età (giovane, adulto, antico).- Non menziona i manuali dei mostri o Fizban's Treasury of Dragons come fonti.- Si concentra solo sui draghi metallici, mentre il testo di riferimento conteneva informazioni sia sui draghi metallici che sui draghi cromatici.Differenze principali:- Nessuna menzione dei draghi cromatici- Nessuna menzione delle categorie di età dei draghi- Nessuna menzione dei manuali dei mostri o di Fizban's Treasury of Dragons- Si parla solo dei draghi metallici, non di tutta la portata del testo di riferimento- Non trasmette la cronologia di introduzione dei draghi nei libri di quinta edizione

Eccoci qui. Se le squadre possono fornire risposte attese, possiamo alimentare le risposte degli LLM al sistema RAG per averle valutate. I vantaggi sono che non dobbiamo fare affidamento sulla conoscenza apriori dell’LLM dato che stiamo ancora fornendo i dati rilevanti. Possiamo utilizzare un LLM diverso da quello utilizzato nel sistema RAG, il che significa che possiamo anche chiedere a più modelli di valutare il nostro output per garantire una valutazione equilibrata.

Questo metodo ci fornisce anche un’ottima spiegazione di ciò che era sbagliato. In questo esempio, avevo una domanda su quali tipi di draghi esistessero nell’universo di DND. L’LLM giudicante ha correttamente identificato che non si faceva menzione dei draghi cromatici. Tuttavia, ha anche penalizzato la risposta per non includere le età dei draghi, il Manuale dei Mostri di DND o l’avventura di espansione. Queste omissioni non erano importanti per la domanda che ho fatto, ma questo permette alle squadre QA di decidere autonomamente una volta per tutte.

Dove andiamo ora?

I sistemi basati su RAG e i framework utilizzati per crearli stanno avanzando ogni giorno. Nuovi modi e meccanismi per valutarli continueranno a progredire. Ci sono persino strumenti di giganti come LangChain che possono aiutare in questo compito, come LangSmith.

Mentre aspettiamo ulteriori progressi, l’utilizzo di una combinazione di alcuni dati di convalida manuale e sia la libreria di metriche HuggingFace che gli LLM stessi ci offre un ottimo modo per iniziare a fidarci di questi sistemi.

Ricordate, una volta che avete fiducia e siete pronti a mettere in produzione il vostro nuovo RAG, la valutazione delle risposte non si ferma! Come parte degli sforzi di monitoraggio e audit di routine, dovete continuare a memorizzare domande e risposte e pianificare un intervento di feedback umano per valutare e segnalare le risposte fornite agli utenti finali. Tuttavia, questo è argomento per un altro giorno.