Usa le macchine per classificare le macchine
Compreso un nuovo metodo innovativo per giudicare le risposte con un punteggio qualitativo e una spiegazione dettagliata.
La Research Augmented Generation, o RAG, è facilmente il caso d’uso più comune per i Large Language Models (LLM) emersi quest’anno. Sebbene il riepilogo e la generazione di testi siano spesso al centro dell’attenzione dei singoli utenti, le aziende si sono rese conto di aver bisogno della capacità di utilizzare i propri dati per sfruttare questa tecnologia. Riflettendo su come utilizzo ancora gli LLM, la generazione di testo è in cima alla lista. Voglio fare delle domande a Bard e farlo cercare sul web; Voglio che Claude riscriva le email o i post del blog per potenziare i miei contenuti. Ma l’uso più interessante che ho riscontrato è stato il convogliamento dei miei dati nel LLM. Voglio cercare nei miei appunti, e-mail, calendario e messaggi Slack e fare in modo che Llama funzioni come un altro me (ma un me che possa ricordare i dettagli di cose accadute prima di oggi).
Questo non è un post su come costruire un RAG (ce ne sono già molti là fuori… e sto lavorando su quel post per un altro giorno). Ciò che esploreremo oggi è come valutare i sistemi RAG.
Prepariamo il livello prima di finire tra le erbacce. Quando parliamo di RAG, intendiamo due parti del sistema.
La fonte della 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 siano archiviati i nostri dati.
Il LLM
Una volta che abbiamo i nostri dati, li inseriamo nel LLM. Questo viene fatto attraverso la finestra di contesto. Quindi, alla fine, cerchiamo, otteniamo del testo, materiale che ha trovato testo in un 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 valutarlo. Possiamo ora vedere che occorre esaminare due pezzi. Il recupero iniziale dei dati è la parte più critica qui. I LLM, in generale, sono ottimi nel riassumere/rispondere alle domande con i dati forniti nel contesto. Ciò che potrebbe mancare è la funzionalità di ricerca stessa.
Queste fonti di conoscenza presentano alcune limitazioni integrate. Ad esempio, quando si utilizzano database vettoriali per archiviare file di testo di grandi dimensioni, è necessario suddividere i dati in blocchi. Cosa significa? Supponiamo che tu abbia un documento di 100 pagine, ma il database può gestire solo il salvataggio di 1 pagina alla volta. Una volta caricati i documenti e avviata la ricerca, il database può esaminare solo una singola pagina alla volta (ok, questo è un po’ riduttivo, ma abbi pazienza; è abbastanza vicino per il lavoro del governo). Quando troviamo dati che corrispondono alla nostra ricerca, esiste una concreta possibilità che l’intera risposta alla nostra domanda non si trovi in quella singola pagina. Peccato! Otteniamo indietro solo una singola pagina! Questo è un buon esempio del motivo per cui è necessario esaminare questa parte del sistema prima di preoccuparsi del risultato del LLM.
Valutazione della ricerca iniziale
Questa non sarà la risposta che la maggior parte degli esperti di tecnologia vorrà sentire. Sarà necessario un certo livello di valutazione umana per valutare i risultati della tua fonte di conoscenza.
Perché? Ebbene, se un’azienda utilizza i propri dati ed è privata, sarà difficile automatizzare i test per verificare che i risultati della ricerca siano del tutto accurati. Non preoccuparti, non deve essere manuale al 100%; possiamo automatizzarne alcune parti. Scaviamo un po’ più a fondo.
Ci sono due implementazioni che vedo per questa convalida e valutazione iniziale.
La prima opzione è disporre di una serie di domande comuni e previste per il set di dati e fare in modo che un team umano di QA verifichi i risultati della ricerca. Ad esempio, se il tuo team ha il compito di creare un bot di domande e risposte del servizio clienti per una banca, alcune domande comuni potrebbero essere: “Qual è l’importo minimo che devo tenere sul mio conto?”, “Come posso effettuare un pagamento su il mio prestito?’, ‘A che ora è aperta la mia filiale?’. È l’ideale se i tuoi QA possono fornire sia le domande che le risposte previste in qualcosa di simile a un file CSV che può essere letto a livello di codice; quindi, possiamo utilizzare alcuni dei nostri test automatizzati di cui parleremo più avanti in questo post.
Se il tempo o le risorse non sono disponibili per questo, il secondo metodo prevede una ricerca e una revisione del team QA in tempo reale. Questa è un’opzione per i primi POC e i prototipi, ma attenzione, non sarà adattabile ai carichi di lavoro di produzione effettivi.
Valutazione delle risposte LLM
Una volta che abbiamo la certezza che i dati provenienti dalla nostra fonte di conoscenza sono affidabili, dobbiamo garantire che le risposte finali siano accurate. I sistemi RAG sono ottimi per ridurre la possibilità di allucinazioni e questo può essere esteso modificando il prompt sottostante. Tuttavia, può tralasciare informazioni, fraintendere i dati che gli vengono forniti o tentare di acquisire conoscenze a priori dalla sua formazione.
La valutazione di questo passaggio è simile alla valutazione della ricerca precedente. Se i team di QA possono fornire domande e risposte previste, possiamo tentare di valutare le risposte in modo programmatico.
Diamo un’occhiata ad alcune di queste opzioni ora.
È essenziale ricordare che gli LLM e i RAG sono molto presto nel loro ciclo di maturità. È passato solo un anno dal debutto di ChatGPT e ogni giorno porta nuovi progressi, modelli, strutture e ricerche in questo campo. Detto questo, una manciata di parametri stanno diventando il modo standard per misurare le prestazioni di questi sistemi.
Non tratteremo i modi per valutare il LLM di base. Ci sono cose come ARC, MMLU, HellaSwag, ecc., che prendono tutte di mira il modello linguistico sottostante. 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 i diversi modelli. A noi interessa solo misurare i risultati che otteniamo dai sistemi RAG.
Ciò ci porta a considerare algoritmi come ROUGE, BLEU, BLUERT e METEOR. Diamo uno sguardo più da vicino a ciascuno. Includerò anche un piccolo snippet di codice per come chiamare ciascuna metrica e come appare il punteggio di output. Importo il framework eval per iniziare e includo il riferimento e la risposta a cui voglio assegnare un punteggio.
!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
# If you have a translation and reference corpus:
predictions = ("In Dungeons & Dragons, the metallic dragons come in brass, bronze, copper, gold, and silver varieties. Each has scales in hues matching their name - brass dragons have brassy scales, bronze have bronze scales, etc. The metallic dragons are generally more benign than the chromatic dragons in D&D lore.")
references =("""The five basic chromatic dragons (red, blue, green, black, and white) and metallic dragons (copper, brass, silver, gold, and bronze) appeared in the fifth edition Monster Manual (2014) in wyrmling, young, adult, and ancient. Gem dragons and other new-to-fifth-edition dragons appeared in Fizban's Treasury of Dragons (2021)""")
ROSSO (Sostituto orientato al richiamo per la valutazione dei gisting)
ROUGE è un insieme di parametri per valutare il riepilogo automatico 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 (list): list of predictions to score. Each prediction should be a string with tokens separated by spaces.
#references (list or list(list)): list of reference for each prediction or a list of several references per prediction. Each reference should be a string with tokens separated by spaces.
#rouge_types (list): A list of rouge types to calculate. Defaults to ('rouge1', 'rouge2', 'rougeL', 'rougeLsum').
#Valid rouge types:
##"rouge1": unigram (1-gram) based scoring
##"rouge2": bigram (2-gram) based scoring
##"rougeL": Longest common subsequence based scoring.
##"rougeLSum": splits text using "\n"
#use_aggregator (boolean): If True, returns aggregates. Defaults to True.
#use_stemmer (boolean): If True, uses Porter stemmer to strip word suffixes. Defaults to 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)
}
BLU (Studente di valutazione bilingue)
BLEU è una metrica per la valutazione automatica del risultato della traduzione automatica. Si basa sulla precisione n-grammi della traduzione candidata rispetto a una serie di traduzioni di riferimento.
#predictions (list of strs): Translations to score.
#references (list of lists of strs): references for each translation.
#max_order (int): Maximum n-gram order to use when computing BLEU score. Defaults to 4.
#smooth (boolean): Whether or not to apply Lin et al. 2004 smoothing. Defaults to False.#bleu (float): bleu score
#precisions (list of floats): geometric mean of n-gram precisions,
#brevity_penalty (float): brevity penalty,
#length_ratio (float): ratio of lengths,
#translation_length (int): translation_length,
#reference_length (int): reference_length
bleu = 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
}
BLEURTS (Regressione BLEU con trasformatori)
BLEURT è una metrica di valutazione per la generazione del linguaggio naturale (NLG). Si basa sul BERT, che consente a BLEURT di apprendere le relazioni statistiche tra parole e frasi e di identificare modelli nell’output NLG.
BLEURT ha dimostrato di superare altri parametri di valutazione NLG, come BLEU e ROUGE, in una varietà di compiti, tra cui la traduzione automatica, il riepilogo e la risposta alle domande.
#output is always a number between 0 and (approximately 1).
#This value indicates how similar the generated text is to the reference texts, with values closer to 1 representing more similar texts.bleurt = evaluate.load("bleurt", module_type="metric")
results = bleurt.compute(predictions=predictions, references=references)
print(results)
{
'scores': (0.6028875708580017)
}
METEORA (Metrica per la valutazione della traduzione con ordinamento esplicito)
METEOR è una metrica di valutazione automatica per l’output della traduzione automatica. Presenta inoltre funzionalità non presenti in altri parametri, come la radice, la corrispondenza dei sinonimi e la corrispondenza esatta delle parole standard. La metrica è stata progettata per risolvere alcuni dei problemi riscontrati nella più popolare metrica BLEU e anche per produrre una buona correlazione con il giudizio umano a livello di frase o di segmento.
#predictions: a list of predictions to score. Each prediction should be a string with tokens separated by spaces.
#references: a list of references (in the case of one reference per prediction), or a list of lists of references (in the case of multiple references per prediction. Each reference should be a string with tokens separated by spaces.
#alpha: Parameter for controlling relative weights of precision and recall. The default value is 0.9.
#beta: Parameter for controlling shape of penalty as a function of fragmentation. The default value is 3.
#gamma: The relative weight assigned to fragmentation penalty. The default is 0.5.#outputs 0-1 - .317 is acceptable score
meteor = evaluate.load('meteor')
results = meteor.compute(predictions=predictions, references=references)
print(results)
{
'meteor': 0.19316493313521543
}
Mentre ho la tua attenzione, però, voglio presentarti una nuova idea. Anche se questi quattro algoritmi ti forniranno un punteggio quantificabile che consentirà al tuo team di QA di determinare rapidamente se una risposta/riepilogo è simile, ci sono alcune carenze.
Innanzitutto, le frasi di riferimento e il risultato potrebbero essere sufficientemente simili da rispondere alla domanda degli utenti, ma potrebbero comunque ricevere un punteggio scarso. È essenziale eseguire una serie nota 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 ne risente. È perché c’è una penalità per la ripetizione delle parole? È perché mancano alcune parole? Il riassunto ha omesso del tutto una parte essenziale della risposta? Non c’è un modo per dirlo.
Infine, solo perché una risposta riceve un punteggio basso non significa necessariamente che un essere umano considererebbe la risposta insufficiente o errata. La linea di base può essere utile in questo caso per stabilire quali potrebbero essere i punteggi accettabili, ma è importante avere un certo scetticismo quando li si utilizza per giudicare le risposte RAG.
LLM che valutano i LLM
BLEURT ci ha introdotto all’idea che possiamo utilizzare i LLM in qualche modo per valutare le risposte di un sistema RAG. E se lo sfruttassimo direttamente noi stessi? Chiediamo a un LLM di assegnare un punteggio qualitativo per la nostra risposta e forniamo sia ragioni puntate che una spiegazione narrativa del punteggio assegnato. Questo ci dà il meglio di entrambi i mondi. Possiamo estrarre un punteggio numerico da riportare agli utenti e al QA in un report; possiamo anche fornire maggiori dettagli sul motivo per cui una risposta ha ottenuto un punteggio negativo.
Di seguito è riportato un modello di prompt di esempio che può essere utilizzato per ClaudeV2. Passiamo istruzioni su come vogliamo che il modello assegni un punteggio alla nostra risposta, passiamo i dati di riferimento e passiamo la risposta che abbiamo ricevuto dal nostro sistema RAG.
prompt_data = """
Human:
You are to rate a summarization on the scale of 0-10, with 0 being completely incorrect and 10 being a perfect summzarization of the given text.
Explain why you give your score.
Give a bullet point list of major differences between the reference and the summary.
I will supply a reference text by denoting REF: and the summarization to compare against with SUMMARY:.REF:
The five basic chromatic dragons (red, blue, green, black, and white)
and metallic dragons (copper, brass, silver, gold, and bronze)
appeared in the fifth edition Monster Manual (2014) in wyrmling, young, adult, and ancient.
Gem dragons and other new-to-fifth-edition dragons appeared in Fizban's Treasury of Dragons (2021)
SUMMARY:
In Dungeons & Dragons, the metallic dragons come in brass, bronze, copper, gold, and silver varieties.
Each has scales in hues matching their name - brass dragons have brassy scales, bronze have bronze scales, etc.
The metallic dragons are generally more benign than the chromatic dragons in D&D lore.
Assistant:"""
Score: 5/10Explanation:
The summary captures some accurate high-level information about metallic dragons in D&D, such as listing the main types and noting their more benign nature compared to chromatic dragons. However, it leaves out a lot of key details from the reference text:
- Does not mention the chromatic dragons (red, blue, green, black, white) that were described.
- Does not mention the different age categories (wyrmling, young, adult, ancient).
- Does not mention the Monster Manual or Fizban's Treasury of Dragons sourcebooks.
- Only focuses on metallic dragons, while the reference text had information about both metallic and chromatic dragons.
Major differences:
- No mention of chromatic dragons
- No mention of dragon age categories
- No mention of Monster Manual or Fizban's Treasury of Dragons
- Only discusses metallic dragons, not full scope of reference text
- Does not convey the introduction timeline of dragons across 5th edition books
Eccoci qui. Se i team possono fornire le risposte previste, possiamo inserire le risposte RAG in un LLM per valutarle. I vantaggi sono che non dobbiamo fare affidamento sulla conoscenza a priori del LLM poiché stiamo ancora inserendo 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 di avere una valutazione equilibrata.
Questo metodo ci fornisce anche un’eccellente spiegazione di ciò che non andava. In questo esempio, avevo una domanda su quali tipi di draghi esistessero nell’universo DND. Il giudice LLM ha correttamente identificato che non menzionava i draghi cromatici. Tuttavia, ha anche infangato la risposta per non aver incluso l’Età dei Draghi, il Manuale dei Mostri DND o l’avventura di espansione. Tali omissioni non erano importanti per la domanda che ho posto, ma ciò consente ai team di QA di decidere da soli una volta.
I sistemi basati su RAG e i framework utilizzati per crearli avanzano ogni giorno. Anche nuovi modi e meccanismi per valutarli continueranno ad avanzare. Esistono anche strumenti di giganti come LangChain che possono aiutare in questo compito, come ad esempio LangSmith .
In attesa di ulteriori progressi, l’utilizzo di una combinazione di alcuni dati di convalida manuale e della libreria di metriche HuggingFace o degli stessi LLM ci offre un ottimo modo per iniziare a fidarci di questi sistemi.
Ricorda, una volta che hai acquisito sicurezza e sei pronto per implementare il tuo nuovo RAG in produzione, la valutazione delle risposte non si ferma! Nell’ambito delle attività di monitoraggio e controllo di routine, è necessario continuare a archiviare domande e risposte e pianificare un intervento umano per classificare e contrassegnare le risposte fornite agli utenti finali. Questo, tuttavia, è un argomento per un altro giorno.
Fonte: towardsdatascience.com
