LLM Valutazione: orientare ogni decisione alle prove giuste

La valutazione LLM è la pratica di testare se un sistema a motore modello soddisfa un criterio definito su un obiettivo definito. Il utile default è semplice: nominare prima la decisione, quindi raccogliere le prove più strette che possano supportarla. Un set di dati curato può supportare una pretesa di qualità pre pubblicazione. Un confronto di base può supportare una decisione di regressione. I campioni di produzione possono rivelare la deriva di qualità del vivo. Nessuna di queste, da sola, prova che un agente fosse raggiungibile, abbia completato un effetto strumento o abbia consegnato l'artefatto promesso. Questo limite è importante perché la valutazione passata suona più ampia di quanto non sia. Un punteggio ha sempre un obiettivo, un orologio e prove mancanti. Trattarlo come un verdetto sanitario universale crea un falso verde: la risposta sembra buona mentre il processo o il risultato è rotto. Inizia con la decisione, non con la metrica. Prima di scegliere una corrispondenza esatta, un punteggio di inserimento, un giudice LLM o una piattaforma, scrivete una frase in questa forma: A Questo tempo , decidere Questa azione da Questo obiettivo utilizzando Questa prova . Questa frase fa sì che il lavoro sia in una corsia: Decisione Obiettivo Orologio Minime prove Richiesta più forte sostengabile Un candidato è abbastanza buono? Esempi curati Prima dell'impiego Dataset, punteggiatore specifico Il candidato soddisfa il criterio indicato in questo set di dati Il rilascio è diminuito? Linea di base e candidato Al rilascio Corse abbinate, soglia Il candidato non ha superato il limite di regressione nominato La qualità del vivo sta scendendo? Corsi di produzione campionati Durante il traffico campione fresco, valutazione della produzione Questo campione soddisfa o non soddisfa il criterio live L'agente e' sano? Tempo di esecuzione e lavoro previsto Al tempo di esecuzione previsto Battito cardiaco, programma, ricevuta del progresso Il tempo di esecuzione è raggiungibile e il lavoro utile si muove È successo il risultato previsto? Destino esterno Dopo il termine di effetto o di completamento Risultato di destinazione, somma di controllo, prova di accettazione L'effetto o il consegnabile esiste e passa la verifica Le ultime due righe non sono migliori valutazioni. Rispondono a domande diverse. Un valutatore può ispezionare una risposta o un tracciato; la salute operativa ha bisogno di prove sul processo che dovrebbe essere eseguito; la verifica dei risultati ha bisogno di prove provenienti dalla destinazione in cui il risultato dovrebbe esistere. La valutazione offline sostiene le richieste di pre pubblicazione limitate Guida di valutazione di OpenAI definisce un flusso di lavoro utile: indicare l'obiettivo, raccogliere un set di dati, definire le metriche, eseguire confronti e continuare a valutare le variazioni del sistema. Esso avverte anche contro le metriche generiche e la valutazione basata su vibe. L'implicazione pratica è che un punteggio offline ha bisogno di una decisione di rilascio allegata a esso. Supponiamo che un agente di supporto debba selezionare lo strumento corretto, passare l'identificatore di conto corretto e restituire una risposta conforme alle politiche. Non ridurli in una media. Utilizzare tre controlli: controlli esatti o basati su schemi per lo strumento e gli argomenti selezionati; una rubrica di qualità specifica per la risposta; un controllo deterministico per qualsiasi campo di uscita richiesto dal contratto di applicazione. Poi confrontare l'attuale candidato con il baseline di rilascio sui medesimi casi. Un candidato che migliora lo stile di risposta ma riduce l'accuratezza dell'ID dell'account non è migliore dello 0.7%. Ha scambiato una classe di fallimento con un'altra. Il cancello di rilascio dovrebbe indicare se tale commercio è consentito. Il test di regressione è quindi un uso particolare della valutazione offline, non un sinonimo di tutte le valutazioni. Richiede una linea di base stabile, casi accoppiati e una soglia legata ad un'azione di rilascio. Registrare la versione del set di dati, la versione di punteggio, il modello e la configurazione del prompt, il numero di campioni e i disaccordi. Senza questo manifesto, non si può attribuire in modo sicuro un cambiamento di punteggio. Il pavimento ragionevole può essere piccolo. Da cinque a dieci esempi attentamente esaminati per componente critico sono più utili di un grande insieme sintetico con criteri di accettazione non chiari. Espandi il set da incidenti reali, casi di margine e disaccordi tra i recensori. Un set di dati dovrebbe diventare più difficile perché il sistema ti ha insegnato dove fallisce, non perché un dashboard ricompensa il numero di casi. La valutazione online osserva il comportamento in diretta, con riferimenti più deboli I concetti di valutazione di LangSmith fa un'importante distinzione di obiettivo. Le valutazioni offline sono eseguite su set di dati e esempi, spesso con output di riferimento. Le valutazioni online sono eseguite su circuiti o fili di produzione, dove di solito non è disponibile un riferimento corretto. Questo cambia il significato del verdetto. Un valutatore online può segnalare un modello di sicurezza, un output malformato, una deriva di argomento, una scarsa soddisfazione dell'utente o una traiettoria insolita. Può anche raccogliere casi in diretta difficili per l'insieme di regressione offline. Non può ereditare in silenzio la fiducia di un test di riferimento. Il suo campione può essere obsoleto, filtrato, poco rappresentativo o segnato da un giudice che è andato alla deriva. Per ogni regola online, tenere: la politica di campionamento e le esclusioni; l'identificatore della corsa o del filo, senza perdite di contenuti sensibili; la versione dell'evaluatore e la rubrica; il tempo di osservazione e la finestra di freschezza; l'azione innescata da un errore; un percorso per la revisione umana e la cattura dei disaccordi. Documentazione del kit di sviluppo degli agenti di Google separa la valutazione della traiettoria di utilizzo degli strumenti dalla valutazione della risposta finale. Questo è utile, ma per corrispondere la traiettoria occorre la moderazione. Due agenti validi possono risolvere lo stesso compito attraverso diverse sequenze di strumenti. La corrispondenza esatta della traiettoria è appropriata quando l'ordine fa parte del contratto di sicurezza; altrimenti, verificare gli effetti richiesti e le azioni vietate piuttosto che richiedere un percorso ideale. Il monitoraggio della produzione contiene anche segnali di non valutazione. La latenza, il tasso di errore, l'uso dei token e la completezza delle tracce descrivono il comportamento del servizio. Un valutatore della qualità della risposta descrive il contenuto o il comportamento campionato. Nessuno dei due stabilisce che il lavoratore di domani sia raggiungibile. Tenere queste affermazioni separate anche se una piattaforma le mostra insieme. Il limite finale ha bisogno di ricevute, non di un altro giudice. Tre casi della cornice dell'articolo hanno prodotto la stessa trappola: un punteggio generico LLM è passato, ma l'unico verdetto difendabile è stato UNKNOWN . 1. Il caso di salute in tempo di corsa aveva un programma atteso e un record di progresso, ma nessun battito di cuore fresco. Un vecchio buon lavoro non ha dimostrato l'attuale accessibilità. 2. Il caso di effetto strumento aveva un documento di identificazione stabile, ma nessuna ricevuta dalla destinazione. Un intervallo di tempo potrebbe nascondere o nessun effetto o un effetto completato. 3. Il caso di consegna finale aveva una definizione di prova di accettazione, ma nessuna somma di controllo degli artefatti. Non c'era nulla di concreto da testare. Un giudice LLM non può riparare questi vuoti. Chiedere a un modello se un lavoratore è probabilmente vivo non crea un battito cardiaco. Chiedere se una mail è stata probabilmente inviata non crea una ricevuta del fornitore. Chiedere se un file sembra completo non dimostra che il file esista nel percorso richiesto. Preferisco prove deterministe vicino al confine: un battito cardiaco fresco e un record di disponibilità prevista; una ricevuta di progresso legata ad un ID non segreto per l'esecuzione; una chiave di idempotenza più un punto di destinazione letto per un effetto esterno; una somma di controllo, una convalida di schema, un risultato di prova o una query di destinazione per un prodotto consegnato; un ricevimento autorizzato di decisione per un'azione irreversibile. Le prove mancanti dovrebbero rimanere mancanti. UNKNOWN è uno stato operativamente utile perché percorre le indagini senza inventare successo o fallimento. Riproduce l'audit di rotta delle prove su otto casi L'artefatto ispezionabile utilizzato per questo articolo contiene otto casi decisionali. Ogni caso dichiara la decisione, le prove disponibili, il percorso atteso e il verdetto atteso. La politica centrale è deliberatamente meccanica: Il sistema comprende la qualità dei candidati, la regressione dei rilasci, la deriva della qualità del vivo, la salute durante il periodo di esecuzione, gli effetti esterni, i risultati finali, la revisione soggettiva e l'autorità umana. L' esecuzione ha prodotto: Tutti e otto i casi hanno raggiunto il loro percorso di prova atteso. Cinque avevano prove sufficienti per la loro richiesta limitata. Tre erano sconosciute, e tutte e tre sarebbero sembrate verdi se la polizza avesse accettato un punteggio di passaggio generico. Questo non è uno standard universale. Sostituire il dispositivo con decisioni da un flusso di lavoro reale. Aggiungi i nomi esatti che il tuo tempo di corsa e le destinazioni possono produrre. Tenere il comportamento di fallimento: se un segnale richiesto è assente, restituire sconosciuto e elencare i campi mancanti. Non convertire l'assenza in un punteggio zero, perché lo zero suggerisce che si è verificata la misura. Scegli il punteggiatore solo dopo l'obiettivo delle prove Una volta che l'obiettivo è corretto, la selezione dei punteggiatori diventa più facile. Utilizzare il codice quando la proprietà è deterministica: forma JSON, nome dello strumento, intervallo di argomenti, somma di controllo, presenza di file, stato di test o stato di destinazione. Utilizzare un giudice LLM quando la proprietà è veramente qualitativa e si dispone di una rubrica chiara, un set di calibrazione e un percorso di revisione dei disaccordi. Le linee guida di OpenAI sottolineano che i modelli sono spesso più affidabili nella discriminazione tra le opzioni rispetto alla produzione di giudizi aperti, quindi il confronto o la classificazione in coppia possono essere più forti di un punteggio non vincolato. Utilizzare la revisione umana quando la decisione comporta il gusto senza una rubrica stabile, autorità giuridica o politica, ambiguità di alto impatto, segreti o azione irreversibile. Un giudice può riassumere le prove per il revisore; non può diventare la persona autorizzata. Documentazione di valutazione di MLflow descrive i set di dati, i punteggiatori, le funzioni di previsione, il feedback umano, la valutazione sistematica e il monitoraggio della produzione come capacità correlate. Questo è un utile menu di implementazione. La regola di routing appartiene ancora al proprietario dell'applicazione: lo strumento può calcolare un punteggio, ma solo il proprietario può definire quale decisione il punteggio può sostenere. Tenere quattro verdetti nel registro della liberazione e delle operazioni Una documentazione compatta di valutazione dovrebbe rispondere autonomamente a quattro domande: Il candidato ha soddisfatto i suoi criteri di qualità offline? Ha evitato una regressione proibita rispetto alla linea di base? Un campione di produzione fresca soddisfa i suoi criteri online? Il lavoro atteso è sano e il risultato promesso è verificato? Non valutare le risposte. Un rilascio può superare una valutazione offline mentre le prove in diretta non sono ancora disponibili. Un campione di produzione può sembrare sano se viene mancato un percorso programmato. Una traccia può sembrare completa mentre l'artefatto finale è assente. Conserva ogni verdetto, il suo tempo di prova e la sua portata. Ciò produce una regola operativa più calma: valutare il comportamento del modello e dell'applicazione con set di dati e campioni di esecuzione; valutare la salute del runtime con evidenza di accessibilità, programmazione, attesa e progresso; verificare i risultati esterni alla loro destinazione. Escala solo la corsia mancante o fallita. Sidewisp è attualmente in anteprima privata. È stato progettato come uno strato di salute per i tempi di esecuzione degli agenti esistenti, ma gli adattatori di monitoraggio della produzione e i sistemi di recupero non sono generalmente spediti. Se la distinzione tra una corsa bella e un risultato verificato è il problema che stai cercando di risolvere, la lista di attesa di anteprima privata è il passo successivo appropriato.