Bancs d'évaluation

Ce que c'est

Les Bancs d'évaluation, c'est la pratique de construire un jeu de tests à partir de votre trafic de production réel et d'y faire passer chaque changement candidat avant qu'il n'atteigne les utilisateurs. Si un développeur veut changer de modèle, modifier un prompt, ajuster le retrieval ou modifier un workflow, le changement doit d'abord passer une batterie de mesures : la qualité est-elle restée élevée ou meilleure, la latence est-elle restée dans le budget, le coût est-il resté dans le budget, les classificateurs de sécurité passent-ils, un bogue précédemment corrigé est-il revenu. Seuls les changements qui franchissent toutes ces portes peuvent être livrés. C'est ce qui sépare un système IA qui s'améliore prévisiblement d'un système qui se détériore en silence chaque mardi.

Ce qui est inclus

Un jeu d'évaluations construit à partir des traces de production — exécutions réussies comme étalons, échecs comme régressions — augmenté de cas limites synthétiques. Un harnais exécute des variantes candidates en parallèle contre le jeu, score chacune sur plusieurs axes (qualité de tâche via rubrique ou LLM-comme-juge calibré contre des évaluateurs humains, latence p95, coût en tokens et en dollars, empreinte mémoire, fiabilité des outils, scores de classification de sécurité), et rapporte les écarts par rapport à la version de production.

• Jeux d'évaluations bâtis sur traces de production et cas étiquetés
• Tests de différences de prompts, modèles (hébergés, locaux ou auto-hébergés), retrieval et workflows
• LLM-comme-juge calibré contre des évaluateurs humains
• Portes de promotion sur qualité, latence, coût et sécurité

Comment nous construisons

Nous instrumentons le workflow pour que chaque trace de production porte les entrées, le contexte récupéré, les appels d'outils, les sorties intermédiaires du modèle et le résultat final. Les traces sont dédoublonnées et triées : les succès clairs deviennent étalons ; les échecs clairs deviennent régressions ; les cas ambigus reçoivent des étiquettes humaines. Le harnais utilise le jeu comme un traité — les changements proposent, le harnais mesure, un humain approuve ou rejette selon l'écart. Inspect AI, OpenAI Evals et Promptfoo sont des substrats fréquents que nous étendons.

Pourquoi pas juste de l'A/B en production

Le test A/B en production est inévitable pour mesurer l'impact côté utilisateur, mais il est trop lent et trop risqué comme principale porte de livraison pour les changements d'agent. Un mauvais changement de prompt peut dégrader mille workflows avant que les métriques ne le révèlent. L'évaluation avant promotion attrape les régressions qu'un test A/B aurait détectées seulement après dommage, et réserve l'expérimentation en production aux changements qui paraissent bons dans le harnais.

Points de départ fréquents

Mettre debout un premier jeu d'évaluations à partir des 60 derniers jours de traces de production et exécuter une référence ; introduire des portes de promotion pour que les changements de prompt et de modèle ne puissent plus être livrés sans écart vert ; ou construire des alertes de dérive qui comparent la qualité production à la référence d'évaluation chaque semaine.