Valutazione offline vs monitoraggio online per agenti di intelligenza artificiale

Definizione della valutazione offline

Composizione della traiettoria

Una traiettoria è una lista ordinata di passaggi che l'agente è previsto seguire quando riceve un input specifico. Ogni passaggio contiene:

- l'utteranza dell'utente o l'evento di sistema che attiva l'agente

- il pensiero o il ragionamento che l'agente dovrebbe produrre (se si registra la catena di pensieri)

- la chiamata dello strumento o la richiesta API che l'agente dovrebbe effettuare

- la risposta attesa dello strumento o il feedback dell'ambiente

- l'output finale dell'agente che dovrebbe essere mostrato all'utente o al sistema a valle

Quando si raccolgono traiettorie, si inizia di solito con un piccolo set di storie utente rappresentative, poi le si espandono aggiungendo casi limite che si sono visti nei log o che si possono immaginare dai documenti di requisiti., Rubrica di valutazione

La valutazione offline confronta la traiettoria effettiva dell'agente con la traiettoria dorata utilizzando una rubrica che può contenere diverse dimensioni indipendenti:

- Corrispondenza esatta - l'agente produce la stessa sequenza di chiamate di strumenti e risposte?

- Somiglianza semantica - le utteranze o gli output sono equivalenti dal punto di vista del significato anche se la formulazione differisce?

- Fedeltà - il ragionamento dell'agente rimane fondato sugli output dello strumento forniti?, - Successo del compito - l'output finale soddisfa i criteri di successo definiti per la storia?

Ogni dimensione riceve un punteggio tra0 e1. Il punteggio offline complessivo è spesso una media ponderata, ma si può anche trattare ogni dimensione come un cancello separato.

Esecuzione della valutazione offline in CI

Poiché l'insieme di traiettorie è statico e la rubrica è deterministica, è possibile eseguire la valutazione come un passaggio nella pipeline di integrazione continua. Il passaggio tipicamente:

- controlla il codice dell'agente e i fixture di traiettoria

- installa le dipendenze richieste

- esegue l'agente contro ogni traiettoria, catturando la traccia effettiva

- applica la rubrica e scrive un report JSON

- fa fallire la build se qualsiasi punteggio scende al di sotto di una soglia predefinita

Definizione del monitoraggio online

Ciò che si osserva in produzione

Il monitoraggio online non confronta con uno script pre-scritto. Invece, trasmette segnali live dall'agente in esecuzione e cerca deviazioni dalle baseline stabilite. I segnali tipici includono:

- distribuzione della lunghezza dell'utterance dell'utente o del conteggio dei token - frequenza di ogni chiamata di strumento - tassi di errore restituiti dalle API esterne - latenza di ogni passaggio nel ciclo dell'agente - tasso di comportamenti di fallback o retry - deriva semantica nel output finale (misurata con la distanza di embedding rispetto a un set di riferimento recente)

Poiché il traffico di produzione è illimitato, si raccolgono questi segnali su finestre temporali (ad esempio, finestre scorrevoli di cinque minuti) e li si confronta con quantili storici.

Punti di strumentazione

Per ottenere i dati necessari, è necessario strumentare l'agente in alcuni punti chiave:

- al punto di ingresso – catturare la richiesta raw dell'utente e un timestamp - prima di ogni chiamata di strumento – loggare la chiamata intesa e gli argomenti - dopo ogni risposta di strumento – loggare il flag di successo, il codice di errore e la dimensione del payload - dopo che l'agente produce il suo output finale – loggare il testo di output e eventuali punteggi di sicurezza - ad intervalli regolari – emettere un heartbeat che include l'utilizzo della memoria e il carico della CPU

Questi log vengono inviati a un backend di osservabilità (Prometheus, Loki o un timeseries personalizzato) dove è possibile creare dashboard e avvisi.

Esempio di regola di avviso

Una regola utile è quella di avvisare quando la proporzione di chiamate a una particolare API esterna che restituisce un errore 5xx supera il 99° percentile degli ultimi due settimane per tre finestre consecutive. Ciò cattura un degrado improvviso di una dipendenza che il set offline non ha coperto perché il modo di guasto appare solo sotto carico del mondo reale.

Inoltre, strumenti come possono aiutare a migliorare la sicurezza e l'efficienza del monitoraggio online. L'AgentEval e il possono essere utilizzati per valutare le prestazioni dell'agente e identificare aree di miglioramento.

Errori comuni quando si fa affidamento a un solo livello

- Pubblicazione con solo punteggi offline - potresti superare il gate ma comunque rilasciare un agente che fallisce su frasi rare degli utenti o su un comportamento degli strumenti che si verifica solo con alta concorrenza.

- Pubblicazione con solo cruscotti - potresti notare un problema giorni dopo che la modifica incriminata è stata unita, rendendo più difficile il rollback e aumentando l'impatto sugli utenti.

- Confronto dei numeri di produzione in un periodo in cui il modello, il prompt o l'elenco degli strumenti è anche cambiato - il drift osservato potrebbe essere dovuto all'aggiornamento intenzionale piuttosto che a una regressione, portando a falsi allarmi. Il il possono aiutare a monitorare tali cambiamenti.

- Utilizzo dello stesso limite per segnali offline e online - i punteggi offline sono di solito stretti (si prevedono corrispondenze quasi perfette) mentre le metriche online sono rumorose; l'applicazione di un unico taglio può causare falsi positivi o rilevamenti mancati.

- Transcuratezza nel versionare l'insieme di traiettorie - se si aggiorna l'insieme di traiettorie d'oro senza registrare il cambiamento, i punteggi offline storici diventano incomparabili. La documentazione in può aiutare a mantenere traccia di tali modifiche.

Creazione di una porta di regressione in CI

Di seguito è riportato un esempio concreto di come potresti strutturare la porta per un agente di supporto clienti che utilizza un modello linguistico, uno strumento di recupero e un'API di creazione dei biglietti.

Passaggio | Strumento o script | Output | Frequenza Checkout del codice e dei fixture | git clone + git checkout | area di lavoro pulita | una volta per ogni esecuzione del pipeline Installazione delle dipendenze | pip install -r requirements.txt | ambiente isolato | una volta per ogni esecuzione del pipeline Esecuzione dell'agente su ogni traiettoria | python run_agent.py --trajectories data/trajectories.jsonl | file JSONL con tracce effettive | una volta per ogni esecuzione del pipeline Applicazione della rubrica | python score_traces.py --rubric config/rubric.yaml | punteggi per dimensione e complessivo | una volta per ogni esecuzione del pipeline Controllo dei limiti | python gate_check.py --min-overall 0.92 --min-faithfulness 0.88 | stato di passaggio/fallimento | una volta per ogni esecuzione del pipeline Pubblicazione del report | curl -X POST -d @report.json https://metrics.example.com/ingest | record in timeseries | una volta per ogni esecuzione del pipeline

Ogni passaggio è deliberatamente mantenuto idempotente in modo che la ri-esecuzione del pipeline produca lo stesso risultato. Se un passaggio fallisce, il pipeline si ferma e la richiesta di merge viene bloccata.

Configurazione degli avvisi di produzione che contano

Il monitoraggio online efficace si concentra sui segnali che cambiano rapidamente quando qualcosa va storto, piuttosto che sui metriche che si spostano solo lentamente.

Tasso di errore dello strumento

Misurare il rapporto tra chiamate di strumenti non riuscite e chiamate di strumenti totali per ogni servizio esterno. Un improvviso picco spesso indica un guasto a valle o un cambio nel contratto di servizio che l'agente non ha adattato.

Conteggio del ritento del loop

Alcuni agenti ritentano una chiamata di strumento quando ricevono una risposta ambigua. Tenere traccia del numero medio di ritenti per richiesta utente. Un aumento può significare che il modello sta producendo output più incerti o che lo strumento sta restituendo errori vaghi.

Deriva dell'incorporamento dell'output

Calcolare un incorporamento di frase per ogni output finale dell'agente e confrontare la sua distanza con l'incorporamento mediano dell'ultima settimana stabile. Se la distanza del 95° percentile supera un limite prestabilito, attivare un'indagine.

Monitor di segnali di sicurezza

Se si esegue un rilevatore di iniezione di prompt o un filtro di profanità sull'output dell'agente, registrare la frazione di richieste che vengono segnalate. Utilizzare la OWASP LLM Prompt Injection Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) per decidere quali modelli da monitorare. Un aumento delle richieste segnalate può indicare che il modello sta diventando più suscettibile a tentativi di jailbreak.

Chiudere il ciclo: trasformare i risultati del monitoraggio in test offline

Il vero potere di avere entrambi gli strati appare quando si utilizzano le osservazioni di produzione per migliorare la suite di test.

Catturare un nuovo errore

Quando un allarme si attiva, il primo passo è estrarre la sequenza esatta di richiesta-risposta che ha causato il problema. La maggior parte dei sistemi di osservabilità consente di scaricare un ID di traccia che include:

- l'utteranza originale dell'utente - ogni chiamata di strumento e i suoi argomenti - ogni risposta dello strumento - l'output finale dell'agente

Salvare questa traccia come nuovo file di traiettoria.

Etichettare il comportamento atteso

Lavorare con il proprietario del prodotto o il responsabile della sicurezza per decidere quale sia il comportamento corretto. Se il fallimento è stato causato da un bug nello strumento, potresti decidere di simulare la risposta dello strumento per simulare la versione corretta. Se il fallimento è stato causato dalla ragione del modello, potresti scrivere una catena di pensieri che porta alla risposta corretta.

Aggiungere all'insieme offline

Collocare la nuova traiettoria nella directory dei tracciati controllati dalla versione. Aggiornare la documentazione per notare la fonte (ad esempio, "aggiunto da incidente di produzione INC-2024-09-12-07").

Regolare la rubrica se necessario

A volte una nuova traiettoria rivela una dimensione che era stata precedentemente ignorata. Ad esempio, potresti scoprire che l'agente a volte produce una risposta corretta ma include una frase di scusa non necessaria che infastidisce gli utenti. Puoi aggiungere una dimensione di "concisione" alla rubrica e darle un peso.

Eseguire nuovamente il gate

Eseguire nuovamente la pipeline CI. Se la nuova traiettoria causa un calo del punteggio complessivo al di sotto della soglia, sai che il codice attuale avrebbe fallito il gate - che è esattamente ciò che volevi catturare prima del rilascio.

Cosa questo non è

Questo dibattito non promette che la valutazione offline catturerà ogni possibile errore prima della release. Non afferma che il monitoraggio online non perderà mai un errore o che i due strati insieme forniscono una garanzia del 100% di correttezza. Non afferma che l'utilizzo di questi metodi renderà il vostro agente impeccabile o che potete saltare le revisioni di sicurezza, gli esercizi di red team o la verifica formale. Non suggerisce che i segnali descritti siano sufficienti per la conformità normativa in domini ad alto rischio. Non afferma che il flusso di lavoro eliminerà la necessità di supervisione umana o che potete affidarvi esclusivamente ai punteggi automatizzati per le decisioni di release. Non garantisce che una particolare soglia funzionerà per ogni team o ogni architettura di modello. Non afferma che la tabella sopra è l'unico modo per impostare un gate CI o che le regole di allarme elencate sono universalmente ottimali. Non afferma che le cheat sheet di OWASP preverranno tutti i tentativi di iniezione di prompt o che sostituiscono una revisione di sicurezza dedicata.

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

Abbiamo bisogno di entrambi?

Sì, se l'agente tocca qualcosa che un utente o un sistema considera importante. Rilevano classi di errore diverse.

I test offline possono sostituire il monitoraggio?

No. Il tuo set di test non può contenere input che non hai ancora pensato.

Il monitoraggio può sostituire i test offline?

No. Il monitoraggio ti dice che qualcosa è cambiato dopo il fatto; un gate ti dice prima del rilascio.

Su cosa dovremmo allertare in produzione?

Tasso di cambiamento nei segnali di errore, tassi di errore degli strumenti e modelli di loop o retry insoliti — non solo il volume.

Come manteniamo i punteggi confrontabili nel tempo?

Fissare il rubric e le traiettorie, e registrare i cambiamenti al modello, prompt e strumenti insieme ai punteggi.

È una certificazione di sicurezza?

No. Entrambi sono segnali di ingegneria. La revisione della sicurezza è un esercizio separato.

Riferimenti

- NIST — Framework di gestione dei rischi dell'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

- Le rubriche di valutazione dell'agente che attraversano gli stack - Esplora la matrice completa dei temi AI micro-SaaS →