EVALUATOR_ENDPOINT sul server.
Nota: Tu definisci le dimensioni del punteggio. Il tuo valutatore può restituire qualsiasi chiave numerica desideri; Observability memorizza, tende alla tendenza e visualizza tutto quello che invii.
In sintesi
- Scrivi uno scorer. Crea un piccolo servizio HTTP che legge una trascrizione della sessione e restituisce i punteggi. Observability fornisce un riferimento funzionante che puoi copiare. Vedi Scrivere un valutatore con l’SDK.
- Punta Observability su di esso. Imposta
EVALUATOR_ENDPOINT(e unEVALUATOR_TOKENcondiviso) sul processo server. - Guarda i punteggi arrivare. Ogni sessione completata viene valutata automaticamente; i risultati appaiono nella pagina dei dettagli della sessione, nella griglia delle sessioni e nei dashboard salvati.

Come funziona
Quando l’SDK di Observability emette un eventoagent_end per una sessione, il server pianifica una valutazione. Quindi invia un POST della trascrizione completa degli eventi al tuo servizio di valutazione, che può:
-
Restituire il risultato inline con
{"status":"done", "scores":{...}, "reasoning":{...}, "summary":"..."}. Il risultato viene aggiunto alla timeline di valutazione della sessione.reasoningesummarysono facoltativi. -
Rimandare con
{"status":"pending", "job_id":"abc-123"}. Observability poi chiamaGET {EVALUATOR_ENDPOINT}/evaluate/abc-123finché il tuo valutatore non restituisce{"status":"done", ...}o{"status":"error", "error":"..."}. La cadenza di polling è per job: una rispostapendingpuò includerenext_poll_secsper sovrascrivere; altrimenti Observability usa il valoredefault_poll_interval_secsdaGET /config; altrimenti il server ricade suEVALUATOR_POLLING_INTERVAL_SECS(default 10s). Tutti i valori sono limitati a [1s, 1h].
agent_end (ad esempio, un processo agent che si è bloccato) possono essere rilevate: il GET /config del valutatore può restituire {"inactivity_timeout_secs": 1800}, e Observability valuterà qualsiasi sessione rimasta inattiva per quel tempo. Imposta il campo a null oppure omettilo per disabilitare questo fallback.
La pipeline è completamente non operativa quando EVALUATOR_ENDPOINT non è impostato.
Una sessione può accumulare più valutazioni terminali nel tempo: ogni evento agent_end (e ogni rivalutazione manuale dal dashboard) aggiunge una riga di valutazione nuova. Questo è il modo supportato per valutare una conversazione ripresa: un utente termina un agent, ritorna più tardi, invia altri eventi, termina di nuovo l’agent, e viene eseguita una seconda valutazione sulla trascrizione completa aggiornata. Il dashboard rende la valutazione più recente come titolo principale e le valutazioni precedenti come timeline collapsible. Mentre una valutazione è in esecuzione per una sessione, gli ulteriori eventi agent_end per quella sessione vengono ignorati; il prossimo dopo il completamento della valutazione in esecuzione metterà in coda una nuova valutazione come al solito.
Il fallback di inattività si riattiva anche nelle sessioni riprese: se arrivano nuovi eventi dopo una precedente valutazione terminale e la sessione poi rimane inattiva oltre inactivity_timeout_secs, una nuova valutazione viene messa in coda.
I guasti transitori (5xx, 429, timeout, errori di rete) vengono ritentati con backoff esponenziale fino a EVALUATOR_MAX_ATTEMPTS; le risposte 4xx sono terminali. Observability è sicuro da eseguire con più istanze di server scalate orizzontalmente; il lavoro è partizionato in modo che la stessa sessione non venga mai inviata due volte contemporaneamente.
Contratto HTTP
Ogni rotta autenticata usa autenticazione bearer token. Lo stesso valore deve essere configurato su entrambi i lati:- Server Observability: variabile di ambiente
EVALUATOR_TOKEN - Servizio di valutazione: configurato allo stesso modo (l’SDK
agenteye-evaluatorleggeEVALUATOR_TOKENper convenzione)
EVALUATOR_TOKEN non è impostato, il server non invia l’header Authorization; il valutatore può quindi accettare richieste anonime, il che va bene per una rete interna ma è sconsigliato su internet pubblico.
Rotte che il valutatore deve servire
Body EvalRequest inviato dal server
Forme di risposta
Sincrona (done):reasoning (una mappa di giustificazione per punteggio) e summary (una narrazione complessiva di un paragrafo) sono entrambi facoltativi. Le chiavi in reasoning dovrebbero specchiare le chiavi in scores; il dashboard rende ogni voce in linea sotto la sua barra dei punteggi. I valutatori più vecchi che restituiscono solo scores continuano a funzionare senza modifiche; reasoning e summary semplicemente leggono come null e le corrispondenti funzioni UI sono omesse.
Asincrona (rimanda):
next_poll_secs è facoltativo; se omesso il server ricade su default_poll_interval_secs del valutatore da /config, poi su la propria variabile di ambiente EVALUATOR_POLLING_INTERVAL_SECS.
Errore terminale lato valutatore:
error terminale per la sessione.
Scrivere un valutatore con l’SDK
Non devi implementare il contratto HTTP a mano. Il pacchetto Pythonagenteye-evaluator ti fornisce un wrapper FastAPI tipizzato che gestisce l’autenticazione, il routing e le forme di richiesta/risposta per te.
Failproof AI Observability fornisce anche un valutatore di riferimento funzionante che valuta helpfulness, tool_efficiency e factuality dalla forma della trascrizione. Copialo come punto di partenza e sostituisci la tua logica: un giudice LLM, un motore di regole, qualsiasi cosa si adatti al tuo standard di qualità.
Valutatore minimo praticabile:
app gira sotto qualsiasi server ASGI, così uvicorn module:app lo avvia.
Per i valutatori che devono rimandare lavoro costoso, restituisci JobPending e registra un gestore @app.job_lookup; il server Observability polling GET /evaluate/{job_id} finché non restituisci uno stato terminale o il cap EVALUATOR_MAX_POLL_DURATION_SECS (default 1 h) trascorre.
Il riferimento API completo, il modello asincrono e lo schema degli eventi sono documentati nel README dell’SDK agenteye-evaluator.
Eseguire il tuo valutatore
Il valutatore è il tuo servizio — Failproof AI Observability non fornisce un valutatore predefinito, quindi lo crei e lo esegui dove esegui i tuoi servizi. Viene eseguito sotto qualsiasi server ASGI (ad esempiouvicorn my_evaluator:app); servi le rotte /health, /config e /evaluate dal contratto HTTP, poi punta il server su di esso (vedi Configurare il server).
Una volta che il valutatore è raggiungibile, GET /health restituisce {"status":"ok"}. Dopo che un agent viene eseguito end-to-end, GET /evaluations sul server restituisce una riga con status: "done" e i punteggi prodotti dal tuo valutatore.
Configurare il server
Imposta sul processo server:
Per attivare lo scoring automatico, imposta sia
EVALUATOR_ENDPOINT che EVALUATOR_TOKEN sul server, quindi riavvialo per applicare le modifiche. Con EVALUATOR_ENDPOINT non impostato la pipeline rimane non operativa.
I pulsanti di regolazione sopra sono facoltativi; imposta le variabili di ambiente corrispondenti sul server solo se hai bisogno di sovrascrivere i default.
Riferimento API
Filtrare per intervallo di punteggi: score_filters
GET /evaluations accetta un parametro score_filters facoltativo che restringe i risultati per valori numerici dentro l’oggetto scores. Il parametro è un elenco separato da virgole di voci key:min..max; entrambi i limiti possono essere omessi. Più voci si combinano con AND logico. Le righe dove la chiave denominata è assente o non numerica sono escluse. Una richiesta può portare al massimo 20 voci di filtro; superare questo restituisce HTTP 400.
Esempi:
/evaluations ha questi campi:
Permessi
L’admin bootstrap (
ADMIN_KEY, ADMIN_EMAIL) riceve automaticamente questi.
Visualizzare i risultati
/sessions/<id>: timeline degli eventi + una barra laterale destra che mostra i punteggi della sessione e qualsiasi errore dal tentativo di invio. Se la tua chiave haevaluations:trigger, appare un pulsante re-evaluate accanto al pulsante di esportazione, utile per sessioni che non hanno mai emessoagent_end, o per aggiornare i punteggi dopo aver distribuito un nuovo valutatore. Il dashboard effettua il poll per il nuovo risultato e aggiorna la barra laterale destra quando arriva./sessions: griglia di sessione filtrabile; la colonna dei punteggi mostra lo stato di valutazione e i punteggi di ogni sessione a colpo d’occhio./dashboards: viste di salute eval salvate (vedi Dashboard sotto).

Dashboard
La pagina Dashboard (/dashboards) ti consente di salvare una combinazione di filtri di valutazione come una vista denominata e riutilizzabile e osservare come quella sezione di valutazioni sta andando a colpo d’occhio. I dashboard sono condivisi in tutta la tua intera organizzazione; chiunque abbia dashboards:read vede lo stesso set.
Ogni dashboard fissa:
- Filtri: gli stessi controlli della pagina delle sessioni: ambiente, stato, agent, una finestra di tempo mobile e filtri di intervallo di punteggi (
key:min..max). - Una configurazione di visualizzazione: quali chiavi di punteggio presentare, le soglie di salute rosso/ambra/verde, quali pannelli mostrare e se collassare alla valutazione più recente per sessione.
GET /evaluations/aggregate), così i numeri sono esatti piuttosto che campionati.

dashboards:read che evaluations:read; creare e modificare richiede dashboards:write; eliminare richiede dashboards:delete. L’admin bootstrap riceve tutti questi automaticamente.
Risoluzione dei problemi
Le sessioni esistono ma non vengono create valutazioni. Conferma cheEVALUATOR_ENDPOINT è impostato sul processo server, che il server e il valutatore condividono lo stesso valore EVALUATOR_TOKEN, e che l’endpoint /health del valutatore è raggiungibile dal server. Con EVALUATOR_ENDPOINT non impostato la pipeline è non operativa.
Le valutazioni in corso si accumulano. Interroga GET /evaluation-jobs per vedere la coda in corso. Ispeziona attempt_count, next_attempt_at e last_error su ogni riga. Cause comuni: servizio di valutazione non raggiungibile o che restituisce 5xx (ritentato con backoff), EVALUATOR_TOKEN errato (401 è terminale), o un valutatore asincrono che restituisce pending indefinitamente (vedi sotto).
Le sessioni completate ma nessuna valutazione terminale. Interroga GET /evaluation-jobs?status=polling; il risultato potrebbe ancora essere in corso. Se un job è bloccato in pending, il server ha problemi a raggiungere il valutatore; controlla che il valutatore sia in esecuzione e che EVALUATOR_TOKEN corrisponda.
HTTP 401 from evaluator: invalid bearer token. Il EVALUATOR_TOKEN sul server non corrisponde al valore con cui è configurato il servizio di valutazione. Devono essere identici.
Il valutatore asincrono restituisce pending per sempre. Il server effettua il polling di GET /evaluate/{job_id} finché il valutatore non restituisce done o error, o finché il cap EVALUATOR_MAX_POLL_DURATION_SECS (default 1 h) non trascorre. Dopo il cap la valutazione viene registrata come timeout e rimossa dalla coda in corso. Alza EVALUATOR_MAX_POLL_DURATION_SECS se il tuo valutatore ha legittimamente bisogno di più tempo del default.
Prossimi passi
- Skill agent valutatore: fai progettare a un agent di codifica le tue dimensioni in base a sessioni reali e costruisci questo servizio per te.
- Python SDK: emetti gli eventi
agent_endche attivano lo scoring. - Chiavi API: i permessi
evaluations:readeevaluations:trigger. - Audit: l’altra funzione di qualità automatizzata di Observability, per la revisione basata su policy.

