Mantieni la rotta Navigando nella valutazione delle domande basate sul LLM

Mantieni la rotta nella valutazione delle domande basate sul LLM Navigazione sicura

Perché valutare le app LLM è importante e come iniziare

Introduzione

Le Large Language Models (LLM) sono molto popolari e molte persone le stanno incorporando nelle loro applicazioni. Chatbot che rispondono a domande su database relazionali, assistenti che aiutano i programmatori a scrivere codice in modo più efficiente e copiloti che agiscono per conto tuo sono solo alcuni esempi. Le potenti capacità delle LLM ti consentono di avviare progetti con un successo iniziale rapido. Tuttavia, quando passi da un prototipo a un’app LLM completa, diventa essenziale avere un solido framework di valutazione. Un tale framework di valutazione aiuta la tua app LLM a raggiungere prestazioni ottimali e garantisce risultati coerenti e affidabili. In questo articolo, affronteremo i seguenti argomenti:

1. La differenza tra la valutazione di una LLM rispetto a una applicazione basata su LLM
2. L’importanza della valutazione dell’app LLM
3. Le sfide della valutazione dell’app LLM
4. Come iniziarea. Raccolta dati e creazione di un set di testb. Misurazione delle prestazioni
5. Il framework di valutazione dell’app LLM

Utilizzando l’esempio fittizio di FirstAidMatey, un assistente di primo soccorso per i pirati, navigheremo tra le tecniche di valutazione, le sfide e le strategie. Concluderemo con le principali conclusioni e gli spunti. Quindi, salpiamo in questo illuminante viaggio!

Valutazione di una LLM rispetto a un’app basata su LLM

La valutazione delle singole Large Language Models (LLM) come la GPT-4 di OpenAI, la PaLM 2 di Google e la Claude di Anthropic viene tipicamente effettuata con test di benchmark come MMLU. In questo articolo, tuttavia, ci interessa valutare le applicazioni basate su LLM. Queste sono applicazioni che utilizzano un LLM e contengono altri componenti come un framework di orchestrazione che gestisce una sequenza di chiamate LLM. Spesso viene utilizzato il modello Retrieval Augmented Generation (RAG) per fornire contesto al LLM e evitare allucinazioni. In breve, RAG richiede che i documenti di contesto vengano incorporati in un repository di vettori da cui è possibile recuperare le parti rilevanti e condividerle con il LLM. A differenza di una LLM, un’applicazione basata su LLM (o app LLM) è progettata per eseguire uno o più compiti specifici in modo eccellente. Trovare la giusta configurazione spesso richiede un po’ di sperimentazione e miglioramento iterativo. Ad esempio, RAG può essere implementato in molti modi diversi. Un framework di valutazione, come discusso in questo articolo, può aiutarti a trovare la migliore configurazione per il tuo caso d’uso.

FirstAidMatey è un’applicazione basata su LLM che aiuta i pirati con domande come “La mia mano si è impigliata nelle corde ed è gonfia, cosa dovrei fare, amico?”. Nella sua forma più semplice, l’Orchestrator consiste in un singolo prompt che invia la domanda dell’utente al LLM e gli chiede di fornire risposte utili. Può anche istruire il LLM a rispondere in Pirata Lingo per una comprensione ottimale. Come estensione, potrebbe essere aggiunto un repository di vettori con documentazione di primo soccorso incorporata. In base alla domanda dell’utente, la documentazione rilevante può essere recuperata e inclusa nel prompt, in modo che il LLM possa fornire risposte più accurate.

• Come configurare un sistema NL2SQL con Azure OpenAI Studio
• Dietro la rivoluzione dell’AI Paige Bailey parla di Google PaLM 2 e altro
• Personalizzare compagni di codifica per organizzazioni

Importanza della valutazione dell’app LLM

Prima di passare a come fare, vediamo perché dovresti impostare un sistema per valutare la tua applicazione basata su LLM. Gli obiettivi principali sono tre:

• Coerenza: Garantire output stabili e affidabili dell’app LLM in tutti gli scenari e individuare eventuali regressioni. Ad esempio, quando migliori le prestazioni dell’app LLM su uno specifico scenario, vuoi essere avvisato nel caso comprometta le prestazioni su un altro scenario. Quando si utilizzano modelli proprietari come la GPT-4 di OpenAI, si è anche soggetti al loro programma di aggiornamento. Con l’uscita di nuove versioni, la tua versione attuale potrebbe essere deprecata nel tempo. La ricerca mostra che passare a una nuova versione GPT non è sempre migliore. Pertanto, è importante valutare come questa nuova versione influisce sulle prestazioni della tua app LLM.
• Conoscenze: Comprendere dove l’app LLM funziona bene e dove c’è margine di miglioramento.
• Benchmarking: Stabilire standard di prestazione per l’app LLM, misurare l’effetto degli esperimenti e rilasciare nuove versioni con fiducia.

Come risultato, otterrai i seguenti risultati:

• Guadagna fiducia e soddisfazione degli utenti perché la tua app LLM si comporterà in modo coerente.
• Aumenta la fiducia degli stakeholder perché puoi mostrare quanto bene si sta comportando l’app LLM e come le nuove versioni miglioreranno quelle precedenti.
• Aumenta il tuo vantaggio competitivo poiché puoi iterare rapidamente, apportare miglioramenti e distribuire nuove versioni con fiducia.

Sfide della valutazione dell’app LLM

Dopo aver letto i benefici sopra citati, è chiaro perché l’adozione di un’applicazione basata su LLM può essere vantaggiosa. Ma prima di farlo, dobbiamo risolvere le seguenti due sfide principali:

• Mancanza di dati etichettati: A differenza delle applicazioni di apprendimento automatico tradizionali, quelle basate su LLM non hanno bisogno di dati etichettati per iniziare. Le LLM possono svolgere molte attività (come la classificazione del testo, la sintesi, la generazione e altro) immediatamente, senza dover mostrare esempi specifici. Questo è ottimo perché non dobbiamo aspettare dati ed etichette, ma d’altra parte significa anche che non abbiamo dati per verificare quanto bene l’applicazione si sta comportando.
• Possibilità di risposte valide multiple: In un’app LLM, lo stesso input può spesso avere più di una risposta corretta. Ad esempio, un chatbot potrebbe fornire diverse risposte con significati simili, oppure potrebbe essere generato del codice con identica funzionalità ma strutture diverse.

Per affrontare queste sfide, dobbiamo definire i dati e le metriche appropriate. Lo faremo nella prossima sezione.

Per iniziare

Raccolta dati e creazione di un set di test

Per valutare un’applicazione basata su LLM, utilizziamo un set di test composto da casi di test, ognuno con input e target specifici. Ciò che contengono dipende dallo scopo dell’applicazione. Ad esempio, un’applicazione di generazione di codice si aspetta istruzioni verbali come input e restituisce il codice in risposta. Durante la valutazione, gli input verranno forniti all’app LLM e l’output generato potrà essere confrontato con il target di riferimento. Ecco alcuni casi di test per FirstAidMatey:

In questo esempio, ogni caso di test contiene una domanda come input e una risposta di riferimento corretta come target. Oltre a questo, potrebbero essere aggiunte le risposte storiche e persino i feedback storici degli utenti al caso di test. Ciò consente di verificare se le risposte più recenti migliorano quelle precedenti e se i feedback degli utenti vengono affrontati. Idealmente, il tuo set di test consiste in risposte di riferimento verificate, ma se desideri confrontare rapidamente un nuovo modello con uno più vecchio, puoi utilizzare le risposte e i feedback storici come opzione.

Poiché di solito si inizia lo sviluppo di un’applicazione basata su LLM senza un dataset, è importante iniziare a costruire il set di test presto. Puoi farlo in modo iterativo aggiungendo quegli esempi su cui il modello attuale fallisce. Inizialmente, saranno gli sviluppatori a sperimentare maggiormente l’app LLM e saranno loro a aggiungere i primi casi di test basati sulle loro prove manuali. Tuttavia, è importante coinvolgere presto il business o gli utenti finali nel processo, poiché avranno una migliore comprensione dei casi di test rilevanti. Per avviare il set di test, puoi anche utilizzare un LLM per generare coppie di input-target basate, ad esempio, sulla tua base di conoscenza. Nel tempo, il set di test dovrebbe coprire l’intero spettro degli argomenti che interessano maggiormente agli utenti finali. Pertanto, è importante continuare a raccogliere feedback dagli utenti e aggiungere casi di test per gli argomenti che non performano adeguatamente o sono sottorappresentati.

Misurare la performance della valutazione

Dato il set di test, possiamo ora passare gli input all’app LLM e confrontare le risposte generate con i target. Dato che non c’è una singola risposta corretta per ogni input, non possiamo confrontare letteralmente la risposta con la risposta di riferimento. La risposta potrebbe essere formulata in modo diverso pur avendo lo stesso significato del riferimento. Tuttavia, possiamo valutare diverse proprietà della risposta, come un proxy per la qualità della risposta. Le proprietà rilevanti da testare dipendono dall’applicazione e dai dati disponibili. Ecco un elenco delle proprietà delle risposte di FirstAidMatey e di come possono essere trasformate in una metrica:

• Coerenza fattuale: Utilizzare un LLM per valutare se la risposta generata è coerente dal punto di vista fattuale rispetto alla risposta di riferimento.
• Pirateria: Utilizzare un LLM per valutare se la risposta è scritta in Pirata Lingua.
• Similarità semantica: Calcolare la similarità del coseno tra gli embeddings delle risposte generate e di riferimento. Si noti che questo è molto più economico da calcolare rispetto alla coerenza fattuale, ma potrebbe non essere correlato alle risposte corrette.
• Verbosità: Dividere la lunghezza della risposta generata per la lunghezza della risposta di riferimento. Maggiore è la verbosità, più chiacchierone si comporta l’app LLM, il che potrebbe non essere intenzione dell’app stessa.
• Latenza: Misurare il tempo impiegato dall’app LLM per generare la risposta. Ciò consente di fare il compromesso tra configurazioni più accurate, ma più lente.

A seconda del caso d’uso, potresti avere proprietà diverse o aggiuntive. Ad esempio, per un’app LLM di generazione di codice, una proprietà aggiuntiva potrebbe essere la correttezza sintattica del codice generato che potrebbe essere misurata inviando il codice attraverso un compilatore. L’immagine qui sotto illustra come una proprietà possa essere valutata utilizzando un LLM.

Una volta valutate tutte le proprietà per tutti i test, può essere calcolato il punteggio medio per ogni metrica e confrontato con le prestazioni di riferimento/obiettivo. Quando si sperimentano diverse configurazioni, ad esempio per RAG, i punteggi dei test indicano il candidato più favorevole. I compromessi tra correttezza, verbosità e latenza diventano anche chiari. Oltre ai punteggi delle metriche, i casi di errore possono fornire spunti utili per ulteriori miglioramenti. Dai un’occhiata più da vicino a alcuni dei test falliti, potrebbero fornire spunti utili per migliorare ulteriormente la tua app LLM.

Potresti chiederti: “Se l’LLM non può ottenere una risposta corretta, come possiamo fidarci che valuti la stessa risposta? Non ci sarebbe un bias verso il suo stesso output?” Infatti, questo sembra controintuitivo, ma l’idea principale qui è che la valutazione è più semplice della generazione. Considera l’analogia tra creare ed valutare un dipinto. Quando si crea un dipinto, è necessario considerare contemporaneamente diverse proprietà come composizione, colore, prospettiva, luce e ombra, texture, messaggio inteso, ecc. Valutare un dipinto, d’altra parte, ti consente di concentrarti su una proprietà alla volta; è più semplice giudicare un lavoro finito che crearne uno da zero. Lo stesso concetto si applica agli LLM: mentre generare una risposta adeguata può essere impegnativo, valutare criticamente una risposta esistente è più diretto. La valutazione diventa ancora più fattibile se è disponibile una risposta di riferimento, come nel caso della proprietà di Coerenza Fattuale.

Il framework di valutazione dell’app LLM

Mettiamo tutto insieme in questa sezione finale. L’immagine qui sotto mostra una panoramica del framework di valutazione e illustra un importante ciclo di feedback:

1. I test dell’app LLM, le proprietà e i casi di test vengono passati all’Valutatore che cicla su tutti i casi di test e passa gli input di test attraverso l’app LLM. I risultati ottenuti vengono quindi valutati ciclando sulle proprietà e raccogliendo i risultati come metriche.
2. I risultati della valutazione vengono archiviati per ulteriori analisi. Oltre alle metriche, è importante tenere traccia anche della configurazione dell’app LLM (ad esempio, l’LLM utilizzato e i parametri, i componenti e i parametri RAG utilizzati, i prompt di sistema, ecc.) in modo da poter distinguere facilmente gli esperimenti più promettenti e ottenere spunti per migliorare ulteriormente l’app. È possibile archiviare i risultati della valutazione e la configurazione dell’app LLM nel proprio database o utilizzare strumenti come MLflow che forniscono un immediato accesso a un’interfaccia user-friendly.
3. Una volta soddisfatto delle prestazioni, puoi rilasciare la nuova versione della tua applicazione, sia per utenti interni che esterni.
4. Nelle prime fasi del progetto, saranno gli sviluppatori a testare e raccogliere feedback. In seguito, il feedback può essere raccolto dagli utenti finali, sia direttamente (pollice su/giù e feedback scritto), sia implicitamente (turni di conversazione, durata della sessione, suggerimenti di codice accettati, ecc.).
5. Estendi il set di test analizzando il feedback ricevuto e aggiungi casi di test per le situazioni poco rappresentate e non gestite bene dal modello attuale.
6. Individua le tendenze nel feedback ricevuto e trasformale in miglioramenti dell’app LLM. A seconda della situazione, puoi migliorare l’orchestratore (ad esempio, creando una catena di chiamate LLM separate anziché un singolo prompt), il processo di recupero (ad esempio, migliorando gli embeddings) o l’LLM (ad esempio, modificando il modello, i parametri o considerando addirittura il fine-tuning).

Per un’illustrazione dei passaggi 1 e 2, dai un’occhiata al seguente notebook di Jupyter. Questo notebook illustra i concetti spiegati in questo articolo del blog. Puoi vedere come le proprietà, i casi di test e le versioni dell’app LLM possono essere definite e inviate all’Evaluatore. Oltre a stampare i risultati della valutazione, vengono anche registrati in un pannello di controllo di MLflow per ulteriori analisi. Sicuramente dagli un’occhiata, renderà gli argomenti trattati ancora più concreti.

Conclusioni

Valutare un’applicazione basata su LLM è una parte essenziale dello sviluppo di un’app LLM. Il framework di valutazione presentato in questo articolo del blog facilita il confronto tra gli esperimenti durante lo sviluppo, garantisce prestazioni consistenti e fornisce spunti per ulteriori miglioramenti.

La mancanza di dati etichettati, ossia la prima sfida che abbiamo affrontato, può essere risolta costruendo un set di test all’inizio e espandendolo iterativamente aggiungendo casi difficili e sottorappresentati. La seconda sfida, il fatto che spesso ci sono più risposte corrette, può essere superata guardando diverse proprietà degli output generati. Alcune di queste proprietà possono essere misurate con semplici formule o regole, mentre altre possono essere valutate con un LLM.

Infine, abbiamo scoperto un ciclo di feedback cruciale in cui i risultati della valutazione e il feedback degli utenti raccolti guidano le prestazioni dell’app LLM. In conclusione, la valutazione sistematica è la bussola che orienta la tua app LLM verso il successo!

Nota dell’autore: L’ispirazione per questo articolo del blog proviene dalla mia esperienza come Solution Architect presso Radix. Radix è un’azienda belga di intelligenza artificiale specializzata nello sviluppo di soluzioni innovative di apprendimento automatico e applicazioni per diverse industrie. Se sei interessato a saperne di più sulle applicazioni basate su LLM, ti incoraggio a visitare radix.ai o a contattarmi direttamente su LinkedIn.

<p, "se="" dell'autore.