Prodotto · Evals e sandbox
Dove la qualità degli agenti viene misurata e sottoposta a gate
Evals è la superficie in cui la qualità dell’output degli agenti, le regressioni e il drift vengono valutati — e in cui un rilascio può essere sottoposto a gate prima di andare in produzione. Il framework, le scorecard e la console esistono e sono collegati, così come la parte che li rende rilevanti sul traffico reale: la sorgente di sessioni che alimenta il campionamento e la sorgente di cronologia ordinata che alimenta il replay delle sessioni nella sandbox. Entrambi gli adattatori sono sempre collegati in-process, senza configurazione dell’operatore. Il replay NON inventa input: se una sessione non ha una sequenza ricostruibile nella cronologia, il replay viene segnalato come degradato e nessun input viene fabbricato.
Cosa fa
Un framework per la qualità degli agenti
Monitoraggio della qualità dell'output, test di regressione e una sandbox isolata — il luogo in cui il comportamento degli agenti viene valutato prima e dopo una modifica.
Scorecard e monitoraggio della qualità dell'output
Valuta l'output degli agenti rispetto ai controlli che definisci e monitora la qualità nel tempo. Il framework, le scorecard e la console sono collegati; ciò che misurano diventa reale una volta connessa una sorgente di sessioni.
Test di regressione e A/B dei prompt
Riesegui una suite a fronte di una modifica per intercettare le regressioni prima che vadano in produzione e confronta le varianti di prompt A e B sugli stessi input — così una modifica viene giudicata sulle prove, non sull'intuito.
Rilevamento del drift
Rileva quando l'output degli agenti devia dalla baseline attesa nel tempo, così l'erosione della qualità emerge invece di essere scoperta in produzione.
Sandbox isolata
Un ambiente di test isolato per il confronto pre e post-deploy, con replay delle sessioni. Entrambi sono collegati: l’ambiente e la sorgente di cronologia ordinata da cui il replay ricostruisce una sessione.
Cosa è reale
Il framework, la console, il campionamento live e il replay ordinato sono tutti collegati
Questa superficie è la più ricca di giunzioni del prodotto, quindi siamo schietti al riguardo — l'onestà è la funzionalità, non una scusa:
- Attivo: il framework Evals, le scorecard, la console, le esecuzioni di regressione, l'A/B dei prompt e il rilevamento del drift sono realizzati e collegati, e la sandbox è un ambiente isolato per il confronto pre/post-deploy.
- Attivo, con un limite dichiarato: il campionamento di Evals legge sessioni reali tramite la sorgente di sessioni collegata, entro una finestra temporale configurabile che ne limita l’età, e il replay della sandbox ricostruisce dalla cronologia la sequenza ordinata delle azioni di una sessione. Il limite emerge quando non c’è nulla da leggere: una sessione priva di una sequenza ricostruibile nella cronologia produce un replay degradato di zero passaggi, mentre una sequenza oltre il limite ammesso per il replay viene rifiutata per intero anziché riprodotta in parte. In nessuno dei due casi vengono aggiunti input inventati.
- Postura: il motore adattivo di red-teaming è post-v1. Per la v1 documentiamo la postura con controlli compensativi anziché sovrastimare un motore che non è ancora qui.
Evals e sandbox — domande
Posso eseguire Evals sul traffico reale dei miei agenti oggi?
Sì. La sorgente di sessioni che alimenta il campionamento è sempre collegata in-process, senza configurazione dell’operatore, quindi le esecuzioni di monitoraggio campionano sessioni reali invece di dati precaricati — entro una finestra temporale configurabile che ne limita l’età, mantiene recenti i campioni e ne delimita l’insieme. Gli screenshot in questa pagina continuano a mostrare dati di esempio precaricati, perché sono schermate, non un tenant live.
Il replay delle sessioni nella sandbox funziona?
Sì, ed è deterministico: il replay ricostruisce dalla cronologia la sequenza ordinata delle azioni di tool e MCP della sessione e la riesegue sui mock forniti, quindi la stessa sessione e gli stessi mock producono sempre gli stessi output. Due limiti vengono dichiarati anziché nascosti: una sessione priva di una sequenza ricostruibile nella cronologia viene segnalata come degradata con zero passaggi, mentre una sequenza oltre il limite ammesso per il replay viene rifiutata per intero anziché riprodotta in parte.
Esiste un motore automatizzato di red-teaming?
Non nella v1. Il motore adattivo di red-teaming è post-v1. Per la v1 documentiamo la postura di sicurezza con controlli compensativi anziché lasciar intendere un motore adattivo che non è ancora realizzato.
Quindi cosa è effettivamente utilizzabile in questo momento?
Il framework Evals e la console — scorecard, esecuzioni di regressione, A/B dei prompt e rilevamento del drift —, più la sandbox isolata per il confronto pre/post-deploy, la sorgente di sessioni collegata che campiona sessioni reali e il replay ordinato ricostruito dalla cronologia delle sessioni. È qui che la qualità degli agenti e le regressioni vengono misurate e sottoposte a gate. Solo il motore adattivo di red-teaming resta post-v1, e questa pagina lo dichiara nel punto appropriato.
Scopri dove la qualità degli agenti viene sottoposta a gate
Distribuisci Olivares sulla tua infrastruttura ed esplora il framework Evals e la sandbox — scorecard, test di regressione, confronto pre e post-deploy, campionamento live delle sessioni e replay ordinato ricostruito dalla cronologia delle sessioni.