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, l'éditeur vous prévient avant que vous publiiez.
Anatomie d'un scénario
Un scénario contient :
- Un stimulus — l'entrée que reçoit le pipeline (message, payload, appel téléphonique simulé).
- Une séquence attendue — les tours de conversation, tools appelés, sorties produites.
- Des checks — assertions explicites : « l'agent doit appeler
crm.search_customer», « la réponse doit contenir le mot "remboursement" », « le pipeline doit se terminer en moins de 3 tours ».
Catalogue de checks
| Check | Vérifie |
|---|---|
tool_called | Un tool précis a été appelé (éventuellement avec args spécifiques) |
tool_not_called | Un tool n'a pas été appelé (anti-faux-positif) |
output_contains | La sortie agent contient un texte / pattern |
output_matches_json | La sortie JSON valide un schéma donné |
turn_count_max | Le pipeline a fini en ≤ N tours |
cost_max | Le coût total est ≤ N crédits |
latency_max | La durée est ≤ N secondes |
branch_taken | Une condition a routé sur la bonne branche |
Les checks sont extensibles : sur le plan Enterprise, vous pouvez en ajouter des custom via un opérateur.
Créer un benchmark
- Concepteur → Benchmarks → Nouveau benchmark.
- Choisir le pipeline cible.
- Ajouter des scénarios. Vous pouvez :
- Forger manuellement un scénario (le plus précis).
- Capturer depuis l'historique — convertir une vraie exécution en scénario (avec anonymisation).
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 :
- Run unique — résultats immédiats, drawer avec détail par scénario.
- Run programmé — chaque nuit, à chaque publication d'une nouvelle version, etc.
Le rapport indique :
- Taux de succès par check
- Régression vs la version précédente
- Liste des scénarios échoués, avec le diff par rapport à l'attendu
Bonnes pratiques
- Démarrer petit — 5 scénarios bien ciblés valent mieux que 50 scénarios approximatifs.
- Bencher avant chaque publication. L'éditeur peut bloquer la publication si le benchmark régresse.
- 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.