La méthode
Un bench mesure ce qu’un LLM décide dans un système réel, pas ce qu’il sait. Chaque bench part d’un cas d’usage en production et rejoue son code tel quel, sans effet de bord : rien n’est envoyé aux services externes.
Les situations
Chaque situation fige toutes les données dont le modèle a besoin. Elles viennent de deux sources :
- des cas réels tirés d’une base de production, avec leurs vraies données ;
- des cas fictifs construits pour isoler une difficulté précise, un seul piège à la fois.
Pour chaque situation, la décision attendue est écrite avant le lancement, du point de vue du métier. Les écarts sont jugés par rapport à elle.
Deux modes par modèle
- Avec moteur : des règles déterministes font une proposition, le LLM l’ajuste ou la refuse.
- LLM seul : le modèle décide sans proposition préalable.
Les garde-fous de production (planchers, écart maximal, validation par l’utilisateur) s’appliquent dans les deux modes. La décision publiée est celle qui sortirait réellement.
Ce qu’on publie
- Bonnes décisions : nombre de situations où aucun run du modèle ne prend une mauvaise décision.
- Alertes : runs au bon résultat mais au conseil incomplet (drapeau manquant, appel en échec, réponse hors format).
- Conseils absents : appels sans réponse exploitable ; le système retombe alors sur ses règles.
- Durée : médiane et maximum par appel, mesurés de bout en bout.
- Chaque run : le conseil brut, la décision finale et le message affiché à l’utilisateur.
Un même cas d’usage est rejoué quand un modèle sort, quand le prompt change ou quand le code évolue. Les données brutes de chaque bench restent publiées : un nouveau bench se lit à côté des anciens.