Produit · Évaluations et sandbox
Là où la qualité de l’agent est mesurée et filtrée
Les évaluations sont la surface où la qualité de sortie, les régressions et la dérive de l’agent sont notées — et où une release peut être filtrée avant d’être livrée. Le framework, les scorecards et la console existent et sont câblés, tout comme ce qui leur donne du poids sur du trafic réel : la source de sessions qui alimente l’échantillonnage et la source d’historique ordonné qui alimente la relecture des sessions dans le sandbox. Les deux adaptateurs sont toujours câblés dans le processus, sans configuration de l’opérateur. La relecture n’invente PAS d’entrées : si une session n’a pas de chronologie reconstructible, sa relecture est signalée comme dégradée et aucune entrée n’est fabriquée.
Ce qu’il fait
Un framework pour la qualité de l’agent
Surveillance de la qualité de sortie, tests de régression et un sandbox isolé — l’endroit où le comportement de l’agent est noté avant et après un changement.
Scorecards et surveillance de la qualité de sortie
Notez la sortie de l’agent par rapport aux contrôles que vous définissez et suivez la qualité dans le temps. Le framework, les scorecards et la console sont câblés ; ce qu’ils mesurent devient réel dès qu’une source de sessions est connectée.
Tests de régression et A/B de prompts
Relancez une suite contre un changement pour détecter les régressions avant la livraison, et comparez les variantes de prompt A par rapport à B sur les mêmes entrées — pour qu’un changement soit jugé sur des preuves, et non sur l’intuition.
Détection de dérive
Détectez quand la sortie de l’agent s’écarte de sa baseline attendue au fil du temps, afin que l’érosion de la qualité soit mise en évidence plutôt que découverte en production.
Sandbox isolé
Un environnement de test isolé pour la comparaison pre- et post-deploy, avec relecture des sessions. Les deux sont câblés : l’environnement et la source d’historique ordonné à partir de laquelle la relecture reconstruit une session.
Ce qui est réel
Le framework, la console, l’échantillonnage live et la relecture ordonnée sont tous câblés
Cette surface est la plus riche en coutures du produit, alors nous sommes francs à son sujet — l’honnêteté est la fonctionnalité, pas une excuse :
- Live : le framework d’évaluations, les scorecards, la console, les exécutions de régression, l’A/B de prompts et la détection de dérive sont construits et câblés, et le sandbox est un environnement isolé pour la comparaison pre/post-deploy.
- Live, avec une limite déclarée : l’échantillonnage des évaluations lit, par l’intermédiaire de la source de sessions câblée, des sessions réelles dont l’ancienneté ne dépasse pas une limite configurable, et la relecture du sandbox reconstruit depuis leur historique la séquence ordonnée des actions d’une session. La limite apparaît lorsqu’il n’y a rien à lire : une session sans chronologie reconstructible produit une relecture dégradée de zéro étape, et une chronologie dépassant la limite admise pour la relecture est refusée intégralement plutôt que relue en partie. Aucune entrée inventée n’est ajoutée dans l’un ou l’autre cas.
- Posture : le moteur adaptatif de red-teaming est post-v1. Pour la v1, nous documentons la posture avec des contrôles compensatoires plutôt que de survendre un moteur qui n’est pas encore là.
Évaluations et sandbox — questions
Puis-je exécuter des évaluations contre le trafic réel de mon agent aujourd’hui ?
Oui. La source de sessions qui alimente l’échantillonnage est toujours câblée dans le processus, sans configuration de l’opérateur ; les exécutions de surveillance échantillonnent donc des sessions réelles plutôt que des données préremplies — avec une ancienneté maximale configurable, ce qui garantit des échantillons récents et un périmètre borné. Les captures d’écran de cette page montrent toujours des données d’exemple préremplies, car ce sont des captures, pas un tenant live.
La relecture des sessions fonctionne-t-elle dans le sandbox ?
Oui, et elle est déterministe : la relecture reconstruit depuis l’historique la séquence ordonnée des actions d’outils et MCP de la session, puis la réexécute contre les mocks que vous fournissez ; la même session et les mêmes mocks produisent donc toujours les mêmes sorties. Deux limites sont déclarées plutôt que cachées : une session sans chronologie reconstructible est signalée comme dégradée avec zéro étape, et une chronologie dépassant la limite admise pour la relecture est refusée intégralement plutôt que relue en partie.
Existe-t-il un moteur automatisé de red-teaming ?
Pas en v1. Le moteur adaptatif de red-teaming est post-v1. Pour la v1, nous documentons la posture de sécurité avec des contrôles compensatoires plutôt que de laisser entendre un moteur adaptatif qui n’est pas encore construit.
Alors, qu’est-ce qui est réellement utilisable dès maintenant ?
Le framework et la console d’évaluations — scorecards, exécutions de régression, A/B de prompts et détection de dérive —, ainsi que le sandbox isolé pour la comparaison pre/post-deploy, la source de sessions câblée qui échantillonne des sessions réelles et la relecture ordonnée reconstruite depuis l’historique des sessions. C’est ici que la qualité de l’agent et les régressions sont mesurées et filtrées. Seul le moteur adaptatif de red-teaming reste post-v1, et cette page le précise à l’endroit approprié.
Voyez où la qualité de l’agent est filtrée
Déployez Olivares sur votre propre infrastructure et explorez le framework d’évaluations et le sandbox — scorecards, tests de régression, comparaison pre- et post-deploy, échantillonnage en direct de sessions et relecture ordonnée reconstruite depuis l’historique des sessions.