Benchmarks
Un benchmark est un ensemble de scénarios d'évaluation rejoués automatiquement contre un pipeline. C'est l'outil pour mesurer objectivement la qualité d'un agent et détecter les régressions avant qu'elles n'arrivent en prod.
Pourquoi
Un agent qui « semblait marcher » peut régresser silencieusement après :
- une modification de mission ;
- un changement de modèle LLM ;
- un nouveau tool ajouté.
Sans benchmark, vous le découvrez en prod. Avec un benchmark, vous le voyez au run suivant — avant vos utilisateurs.
Anatomie d'un scénario
Un scénario contient :
- Un stimulus — l'entrée que reçoit le pipeline (message ou séquence de tours, fixtures de données).
- Des checks — assertions explicites évaluées sur chaque tour : la sortie produite, la forme de la réponse, la chaîne d'appels de tools, le coût des actions.
Catalogue de checks
| Check | Vérifie |
|---|---|
pipeline_output_match | Une clé du flux de sortie correspond à la valeur attendue (chemin + assertion) |
response_shape | La forme de la réponse de l'agent (longueur, structure), mesurée sans juge |
llm_rubric | Le fond de la réponse, noté par un juge LLM sur une rubrique de critères vérifiables |
tool_chain_analysis | La séquence d'appels de tools suit la stratégie attendue |
tool_cost | Le budget d'actions : chaque appel a un coût, atteindre la cible rapporte un bonus |
static / tests / diff_quality | Checks orientés fichiers et code (sortie d'un pipeline de développement) |
Le catalogue est extensible côté plateforme : chaque check est un plugin enregistré côté serveur.
Créer un benchmark
- Applications → Évaluation → Scénarios.
- Créer les scénarios (stimulus, checks, fixtures de données) ; chaque scénario est dédié à un modèle (le pipeline cible). Les fixtures se gèrent dans l'onglet Fixtures.
Un scénario peut aussi être créé ou modifié par proposition depuis le serveur MCP (benchmark_create / benchmark_update), qui reste en attente jusqu'à son acceptation.
Un bon benchmark contient un mélange : cas nominal, cas limites, cas adverses (tentatives de manipulation, ambiguïté, données manquantes).
Lancer un benchmark
Depuis l'admin, lancez un run : il est mis en file durable puis exécuté par un worker dédié, hors du serveur web. Si ce worker s'arrête en plein run, le run est marqué en échec au redémarrage (il n'est pas repris automatiquement) : relancez-le. Un drawer donne le détail par scénario.
Le rapport indique :
- Taux de succès par check
- Évolution des scores entre les runs (onglets Historique et Évolution)
- Liste des scénarios échoués, avec le détail de chaque check
Bonnes pratiques
- Démarrer petit — 5 scénarios bien ciblés valent mieux que 50 scénarios approximatifs.
- Bencher avant chaque publication, et comparer au run précédent avant de pousser.
- Versionner les missions. Pas seulement les pipelines : les missions aussi évoluent.
- Garder les checks lisibles. Un check qui demande 20 lignes d'explication pour être compris est un check qu'il faut décomposer.