Un benchmark public peut aider à comparer des modèles. Il ne permet pas, à lui seul, de décider si un système d’intelligence peut recevoir une autorité dans une mission donnée.
L’entreprise déploie une réalisation concrète : un modèle précis, un prompt ou une représentation, des données, un mécanisme de retrieval, des outils, des règles, un runtime et une configuration. C’est cette identité complète qui produit le comportement observé.
Commencer par un contrat de mission
Une évaluation utile commence avant le premier test. Elle déclare :
- l’objectif opérationnel ;
- les entrées et sorties attendues ;
- les comportements interdits ;
- les cas d’échec acceptables ;
- les contraintes de latence, mémoire et coût ;
- l’environnement de déploiement ;
- les seuils de décision ;
- les preuves nécessaires avant déploiement.
Sans contrat explicite, une amélioration de score peut masquer une régression importante. Un modèle peut gagner en moyenne tout en devenant moins fiable sur les cas qui comptent réellement.
Séparer recherche et preuve
Le même jeu de données ne peut pas servir indéfiniment à orienter la recherche puis à démontrer que la solution obtenue généralise. Plus une équipe observe un résultat et adapte le système en conséquence, plus ce résultat devient une information de recherche.
Une campagne rigoureuse distingue plusieurs rôles :
Search
Les données de recherche servent à produire des hypothèses, comparer des candidats et choisir les expériences suivantes.
Search confirmation
Une confirmation indépendante limite les décisions prises sur un signal accidentel ou trop étroit.
Robustesse
Les tests de robustesse examinent des variations ou perturbations pertinentes pour la mission : formulations, formats, bruit, valeurs limites ou interactions inattendues.
OOD
Les cas out-of-distribution vérifient le comportement lorsque l’entrée s’écarte de la distribution de recherche. OOD n’est pas une propriété universelle : sa définition dépend du système et de son environnement.
Fresh Final
Une évaluation fraîche intervient après le gel du gagnant. Elle ne sert plus à choisir ou réparer le candidat. Elle contribue au verdict final dans le périmètre déclaré.
Mesurer davantage que la qualité moyenne
Une mission industrielle peut nécessiter plusieurs dimensions simultanées :
- exactitude ou Macro-F1 ;
- taux de sortie conforme au schéma ;
- faux positifs et faux négatifs critiques ;
- comportement de refus ;
- latence de bout en bout ;
- mémoire et coût d’inférence ;
- disponibilité des dépendances ;
- traçabilité des décisions ;
- régressions collatérales ;
- autorité effective du système.
Ces dimensions ne se compensent pas toujours. Si la confidentialité est un hard gate, une meilleure précision obtenue en envoyant les données à une API interdite ne constitue pas une amélioration admissible.
Attacher le verdict à une identité exacte
Changer la quantification, le modèle, le prompt, le corpus, le verifier ou le runtime peut changer le système mesuré. Une qualification sérieuse doit donc identifier exactement la réalisation évaluée.
Cette discipline évite une erreur fréquente : appliquer à une nouvelle version le verdict obtenu par une ancienne version au seul motif qu’elles portent le même nom commercial.
Accepter les verdicts négatifs
Une campagne peut conclure :
- RETAIN : conserver la réalisation actuelle ;
- REPAIR : une intervention bornée paraît justifiée ;
- REPLACE : le substrat ou l’architecture doit changer ;
- CONTINUE SEARCH : les preuves restent insuffisantes ;
- STOP : les contraintes ne sont pas satisfaisables dans le budget ;
- INCONCLUSIVE : l’intégrité ou l’adéquation du protocole ne permet pas de conclure.
Un refus justifié peut être plus précieux qu’un déploiement fragile. Il protège l’organisation d’une certitude que les preuves ne soutiennent pas.
La surface publique AMF v0.18 illustre cette logique sur une campagne bornée. Pour transformer un besoin opérationnel en critères mesurables, commencez par décrire la mission.