di AgentGrade (LX AI)
Rubriche di valutazione degli agenti che funzionano su più stack
Una rubrica di valutazione che funziona su più stack è una che produce punteggi confrontabili quando si scambiano il modello, il framework o il prompt. Se una rubrica funziona solo sullo stack per cui è stata scritta, misura lo stack invece dell'agente e smette di essere utile la prima volta che si cambia qualcosa.
Definizione di una rubrica pronta per il viaggio
Inizio scrivendo la rubrica prima di esaminare qualsiasi output del modello. La rubrica deve contenere tre assi indipendenti: successo del compito, correttezza dello strumento e fedeltà. Ogni asse ottiene la sua own guida di valutazione che non menziona il nome del modello, la versione del framework o il testo esatto del prompt. Conservo le guide in un file di testo semplice che vive accanto alla suite di test in modo che chiunque possa controllarle.
Proprietà principali
- Criteri pre-registrati – le condizioni di successo sono scritte prima della prima esecuzione. - Isolamento degli assi – i punteggi per un asse non si sovrappongono mai ad un altro.
Perché il successo di un task deve essere basato sul risultato
Il successo di un task risponde alla semplice domanda: l'agente ha completato ciò che gli è stato chiesto? Io giudico questo contro una checklist che guarda allo stato finale del mondo, non al testo della risposta. Ad esempio, se il task è "aggiornare l'indirizzo email dell'utente a alice@example.com", controllo il record del database dopo l'esecuzione. Non mi importa se l'agente ha detto "Ho aggiornato la tua email" o "La tua email è ora alice@example.com".
Checklist concreta
- Pre-condizione verificata (ad esempio, l'utente esiste). - Post-condizione verificata (ad esempio, il campo email è uguale a alice@example.com). - Nessun effetto collaterale extra (ad esempio, nessun altro campo modificato). - Opzionale: latenza sotto una soglia (ad esempio, 2 secondi).
Registrazione di un punteggio di successo del task binario (pass/fail) per ogni traiettoria. Se l'agente non supera la post-condizione, il punteggio di successo del task è zero, indipendentemente da quanto il testo sembri fluente.
La correttezza dello strumento come asse separato
La correttezza dello strumento esamina le chiamate che l'agente effettua a API, funzioni o database esterni. Tratto ogni chiamata come un mini-esperimento: l'agente ha selezionato lo strumento giusto, ha passato gli argomenti giusti e ha effettuato la chiamata il numero giusto di volte? Seguo le linee guida dei fogli di lavoro OWASP sull'uso sicuro degli strumenti, ad esempio il foglio di lavoro per la prevenzione dell'iniezione di prompt e il foglio di lavoro per la prevenzione dell'iniezione SQL per evitare iniezioni accidentali.
Rubrica di valutazione
- Lo strumento giusto selezionato - 1 punto. - Tutti gli argomenti corrispondono allo schema - 1 punto per argomento. - Nessuna chiamata extra - 1 punto se il numero di chiamate è uguale al valore atteso. - Nessun effetto collaterale proibito (ad esempio, scrittura su un log che dovrebbe rimanere solo in lettura) - 1 punto.
Il punteggio dell'asse è la somma dei punti divisa per il massimo possibile.
Fedeltà: tracciare ogni affermazione
La fedeltà chiede se ogni dichiarazione nella risposta dell'agente possa essere ricondotta ai risultati degli strumenti o al contesto fornito al modello. Tratto l'output come un insieme di affermazioni e verifico ogni una contro le prove. Se un'affermazione non può essere supportata, la segno come allucinazione. Questo asse è più importante quando l'agente riassume documenti, cita fonti o risponde a domande che richiedono dati esterni.
Verifica passo dopo passo
- Divido l'output in frasi atomiche. - Per ogni frase, elenco i fatti che afferma. - Abbinio ogni fatto a una riga nel risultato dello strumento o a un estratto dal contesto fornito. - Se un fatto non ha un abbinamento, lo conto come un insuccesso. - Punteggio di fedeltà = (numero di fatti supportati) / (numero totale di fatti).
Registro i conteggi grezzi in modo da poter vedere se un calo di fedeltà deriva da poche grandi allucinazioni o da molti piccoli errori.
Cosa questo non è
Voglio essere chiaro sui limiti di una rubrica pronta per il viaggio. Non garantisce che l'agente sia sicuro, economico o veloce. Non promette il 100% di accuratezza per ogni possibile input. Non sostituisce una revisione di sicurezza dedicata, un'analisi dei costi o un benchmark di latenza. La rubrica misura solo i tre assi che ho definito sopra. Se è necessario sapere se l'agente perde chiavi private, è necessario eseguire un controllo separato di gestione dei segreti, ad esempio utilizzando la Secrets Management Cheat Sheet. Se è necessario sapere se l'agente rimane entro un budget, è necessario tenere traccia dell'utilizzo dei token o dei costi delle chiamate API al di fuori di questa rubrica.
Creare traiettorie confrontabili
Una traiettoria è il log completo di ciò che è accaduto durante una singola esecuzione: il prompt iniziale, ogni chiamata di strumento con i suoi argomenti e risultati e l'output finale del modello. Memorizzo ogni traiettoria come un oggetto JSON con uno schema fisso in modo da poter confrontare automaticamente le esecuzioni. Di seguito è riportato un esempio dello schema che utilizzo.
Campo | Tipo | Descrizione prompt | stringa | Il prompt esatto dell'utente o del sistema inviato al modello. chiamate | array | Elenco ordinato delle esecuzioni degli strumenti. chiamate[].strumento | stringa | Nome dello strumento o dell'API. chiamate[].argomenti | oggetto | Argomenti passati allo strumento. chiamate[].risultato | qualsiasi | Output grezzo dello strumento. output | stringa | Testo finale restituito dal modello. metadati | oggetto | Tag opzionali come nome del modello, versione del framework, timestamp.
Poiché lo schema non cambia mai, posso calcolare i punteggi degli assi per ogni traiettoria utilizzando gli stessi script. Conservo un set principale di traiettorie che copre i compiti principali che spedisco e i modi di guasto comuni che ho visto. Quando cambio il modello, eseguo nuovamente le stesse traiettorie e confronto i nuovi punteggi con il valore di riferimento. Inoltre, strumenti come possono essere utilizzati per migliorare l'esperienza dell'utente e garantire che gli agenti, come quelli descritti in funzionino correttamente e siano conformi alle linee guida di AgentGrade.
Eseguire valutazioni su ogni modifica
Integro il passaggio di valutazione nella mia pipeline di integrazione continua. La pipeline esegue le seguenti operazioni su ogni commit che può influenzare il comportamento:
- Effettua il checkout dell'ultimo codice. - Installa le dipendenze dell'agente. - Esegue l'agente sul set di traiettorie fisse. - Analizza i log e calcola i punteggi di successo del task, correttezza dello strumento e fedeltà. - Pubblica i risultati su un dashboard e segnala eventuali assi che scendono di più del 5% rispetto alla precedente build verde.
Questa pratica individua le regressioni precocemente. Ad esempio, quando ho sostituito la libreria di retrieval sottostante, l'asse della correttezza dello strumento è sceso da 0,96 a 0,82 perché la nuova libreria restituiva i risultati in un ordine diverso, causando all'agente di effettuare chiamate extra. Il calo è apparso nel report di CI prima che un utente notasse un problema.
Mantengo anche un set di venti traiettorie valutate manualmente. Ogni mese le valuto con una persona e confronto la media con i punteggi automatici. Se il giudice automatico si discosta, ricambio la rubrica o ritratto il modello del giudice.
Checklist dell'operatore per le valutazioni dell'agente che attraversano gli stack
Conservo una checklist scritta accanto a ogni rilascio che tocca questo argomento. La lista è noiosa di proposito: nomina il proprietario, nomina l'artefatto di prova e nomina il rollback. Se un passaggio non può produrre un file, un ticket o una riga di log, non è un passaggio - è un desiderio.
Prima di modificare la produzione
- Congela il ramo o la revisione della configurazione che verrà misurata. - Registra il modo di fallimento attuale con un input concreto e un output concreto. - Conferma quale identità esegue il lavoro e se tale identità può accedere a dati che non dovrebbe. - Apri le principali referenze che citerai: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.
Mentre esegui il controllo
- Preferisci un percorso riproducibile rispetto a dieci screenshot aneddotici. - Scrivi il risultato sicuro atteso prima di attivare lo strumento o la query. - Acquisisci il comando esatto, il prompt, lo schema o l'espressione regolare sotto test - non una parafrasi. - Se il sistema può agire (inviare, scrivere, eliminare, trasferire), richiedi un confine di conferma nello stesso passaggio.
Dopo che hai finito
- Archivia il rischio residuo con un proprietario e una data, anche quando la scansione è pulita. - Non convertire un controllo verde in un linguaggio di vendita che afferma la completezza. - Esegui nuovamente la stessa checklist quando il modello, lo schema dello strumento o le regole di convalida cambiano.
Segnale | Cosa registrare | Fermare la spedizione? Scrittura o invio inaspettato | Nome dello strumento, argomenti, identità | Sì fino a quando non è bloccato Conferma mancante sull'azione distruttiva | Percorso di chiamata e bypass | Sì Testo non attendibile trattato come istruzione | Superficie di origine e azione risultante | Sì per l'ambito dell'agente Scanner pulito, giudizio aperto | Elementi differiti + proprietario | Solo se il percorso principale è sicuro
agenteval aiuta con il primo passaggio misurabile. Le scelte architettoniche, il consenso legale e le affermazioni rivolte al cliente richiedono ancora un proprietario umano. Tratta ogni riga della checklist come supporto decisionale, non come certificato.
Come spiego i limiti agli acquirenti
Quando un potenziale acquirente chiede se il prodotto "copre tutto", rispondo con il limite: i controlli automatizzati rilevano modelli noti; le nuove catene e il giudizio di politica richiedono ancora una revisione. Quella onestà mantiene basso il carico di supporto e mantiene il blog allineato con ciò che il prodotto effettivamente fa.
Se hai bisogno di un secondo parere, abbina questo testo con i riferimenti qui sotto e con la tua propia riproduzione di staging. Non saltare il passaggio di riproduzione solo perché un modello ha scritto un riassunto fiducioso.
Riferimenti
- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files
Domande frequenti
Quanti casi di test sono necessari?
Quanti sono sufficienti per coprire i compiti che si consegnano effettivamente e i modi in cui falliscono. Un pugno di traiettorie ben scelte batte un grande insieme di facili.
Possiamo valutare i risultati con un altro modello?
Si può, ma registrare che il giudice è un modello e mantenere un campione fisso valutato da esseri umani, in modo da poter dire se il giudice stesso si è spostato.
Cosa è la fedeltà, concretamente?
Se ogni affermazione nel risultato è supportata dai risultati dello strumento o dal contesto che l'agente ha ricevuto, piuttosto che prodotta dalle priorità del modello.
Dovremmo valutare solo la risposta finale?
No. Valutare anche la traiettoria - le chiamate degli strumenti sono dove si verificano la maggior parte dei fallimenti dell'agente.
Con quale frequenza le valutazioni dovrebbero essere eseguite?
Ogni volta che si verifica un cambiamento che può influenzare il comportamento: prompt, modello, elenco degli strumenti o configurazione di recupero.
Un punteggio buono significa che l'agente è sicuro?
No. Significa che ha eseguito bene i compiti che sono stati testati. La sicurezza, il costo e la gestione dei fallimenti sono valutazioni separate.
Riferimenti
- NIST — Framework di gestione del rischio AI - Stanford CRFM — HELM (Valutazione olistica dei modelli linguistici)
Prova il prodotto: AgentGrade
2026-09-20 · solo fonti primarie · nessuna metrica di traffico fabbricata · supporto alle decisioni solo
Articoli correlati
- Valutazione offline vs monitoraggio online per agenti di intelligenza artificiale - Esplora la matrice completa dei temi di AI micro-SaaS →
Quanti casi di test sono necessari?
Quanti sono sufficienti per coprire i compiti che si effettivamente consegnano e i modi in cui falliscono. Un pugno di traiettorie ben scelte batte un grande set di facili.
Possiamo giudicare gli output con un altro modello?
Si può, ma registrare che il giudice è un modello e mantenere un campione fisso valutato da esseri umani, in modo da poter dire se il giudice stesso si è spostato.
Cosa è la fedeltà, concretamente?
Se ogni affermazione nell'output è supportata dai risultati degli strumenti o dal contesto che l'agente ha ricevuto, piuttosto che prodotta dai propri priori del modello.
Dovremmo valutare solo la risposta finale?
No. Valutare anche la traiettoria - le chiamate degli strumenti sono dove si originano la maggior parte dei fallimenti degli agenti.
Quanto spesso dovrebbero essere eseguite le valutazioni?
Ogni volta che si apporta un cambiamento che può influire sul comportamento: prompt, modello, elenco degli strumenti o configurazione di recupero.
Un punteggio buono significa che l'agente è sicuro?
No. Significa che ha funzionato bene sui compiti che sono stati testati. La sicurezza, il costo e la gestione dei fallimenti sono valutazioni separate.
Supporto alle decisioni. Non una certificazione - AgentGrade.