Assertions binaires : le cadre de test qui rend les sorties IA mesurables

Demandez à un développeur d’évaluer si la sortie de son outil’IA est « bonne », et vous obtiendrez un haussement d’épaules, un peut-être, et une réponse qui change selon les jours. Demandez-lui si la sortie contient moins de 300 mots, et vous obtiendrez un oui ou un non catégorique.

Cette distinction entre jugement subjectif et mesure binaire est l’un des concepts les plus importants en assurance qualité IA aujourd’hui. C’est aussi le concept que la plupart des équipes développant des applications alimentées par l’IA ignorent complètement.

Les assertions binaires sont de simples tests vrai/faux appliqués aux sorties IA. Le texte contient-il un certain formatage ? La première ligne est-elle une phrase autonome ? La réponse inclut-elle au moins une statistique ? Le nombre de mots est-il inférieur à la limite ? Chaque question n’a qu’une seule réponse : oui ou non. Réussi ou échoué.

Cette simplicité est précisément l’objectif. Quand chaque critère de qualité est binaire, la qualité devient un nombre. Et quand la qualité est un nombre, elle peut être suivie, comparée et systématiquement améliorée.

Le concept n’est pas uniquement théorique. Des frameworks open-source comme Promptfoo et DeepEval ont construit des systèmes d’évaluation complets autour d’assertions déterministes, offrant aux équipes de développement des outils prêts pour la production. Parallèlement, les recherches du projet DSPy de Stanford démontrent que lorsque les assertions alimentent des boucles d’optimisation automatisées, les systèmes LLM peuvent améliorer leurs propres performances sans intervention humaine.

Le problème de l’évaluation subjective

La plupart des équipes évaluent les sorties IA comme elles évaluent la nourriture au restaurant : « ça semble correct » ou « ça ne semble pas tout à fait juste ». Cette approche présente trois défauts fondamentaux.

Résultats non déterministes

Montrez la même sortie IA au même évaluateur à deux jours différents et vous obtiendrez souvent des évaluations différentes. Montrez-la à deux évaluateurs différents et la divergence s’accentue. La recherche dans le domaine de l’évaluation des LLM a systématiquement montré que les évaluateurs humains présentent une variabilité inter-évaluateurs significative lors de la notation de la qualité de textes ouverts. Quand la mesure n’est pas cohérente, l’amélioration devient impossible car on ne peut pas déterminer si un changement a aidé ou si l’humeur de l’évaluateur a changé.

Processus non automatisable

L’évaluation subjective nécessite qu’un humain lise chaque sortie. Cela crée un goulot d’étranglement qui empêche l’itération rapide. Si l’amélioration d’un prompt nécessite 50 cycles de test, et que chaque cycle requiert une évaluation humaine, l’amélioration prend des semaines. Si l’évaluation est automatisée, ces 50 cycles peuvent s’exécuter pendant la nuit.

C’est précisément pourquoi la communauté du test LLM a adopté les types d’assertions déterministes. Promptfoo, l’un des outils d’évaluation open-source les plus adoptés, propose des types d’assertions comme contains, regex, equals et des fonctions JavaScript personnalisées qui produisent des résultats binaires pass/fail sans aucune intervention humaine. DeepEval adopte une approche similaire avec sa fonction assert_test(), inspirée de Pytest mais spécialisée pour les applications LLM.

Retour d’information non exploitable

« Cette sortie vaut 6 sur 10 » n’indique rien au système sur ce qu’il faut modifier. Quel aspect a mérité le 6 ? La structure ? La longueur ? Le ton ? Le formatage ? Sans retour spécifique et ciblé, le système ne peut que faire des modifications aléatoires en espérant que l’une d’elles améliore le score.

Les assertions binaires résolvent ce problème en décomposant la qualité en critères individuels et nommés. Quand l’assertion numéro 14 (« nombre de mots inférieur à 300 ») échoue tandis que les assertions 1 à 13 réussissent, le développeur comme toute boucle d’optimisation automatisée savent exactement quoi corriger.

À quoi ressemblent les assertions binaires en pratique

Les assertions binaires testent un critère spécifique et mesurable par assertion. Voici des exemples dans différents domaines que les équipes utilisent en production aujourd’hui.

Génération de contenu

Génération de code

E-mails et communication

Dans la configuration YAML de Promptfoo, ces assertions se traduisent directement en définitions de tests. Une assertion contains vérifie les chaînes requises. Une assertion regex valide les motifs. Une assertion javascript exécute une logique personnalisée qui retourne vrai ou faux. Chaque type d’assertion peut être inversé en préfixant not- (par exemple, not-contains ou not-regex), et les assertions peuvent être pondérées différemment selon leur importance.

Concevoir une suite de tests à assertions binaires

L’approche 5×5

Une suite de tests pratique utilise 5 prompts de test représentatifs avec 5 assertions chacun, créant un système de notation sur 25 points. Cela fournit suffisamment de granularité pour détecter les changements significatifs tout en restant gérable pour les équipes qui adoptent la pratique pour la première fois.

Étape 1 : Définir les prompts de test

Sélectionnez 5 prompts représentatifs qui couvrent l’éventail des entrées que votre application IA traite. Pour un outil de rédaction marketing :

1. « Écris un post LinkedIn sur pourquoi les automatisations simples battent les complexes »
2. « Écris un post LinkedIn annonçant une nouvelle fonctionnalité produit »
3. « Écris un post LinkedIn sur une leçon tirée d’un projet échoué »
4. « Écris un post LinkedIn partageant des statistiques sectorielles »
5. « Écris un post LinkedIn sur une success story client »

Chaque prompt teste différents aspects de l’application : différents sujets, différents types de contenu, différents défis structurels. Cette diversité compte car un LLM pourrait réussir toutes les assertions sur un type de prompt et échouer systématiquement sur un autre.

Étape 2 : Définir les assertions par prompt

Pour chaque prompt, définissez 5 assertions binaires qui capturent les dimensions de qualité qui vous importent. Certaines assertions s’appliquent universellement à tous les prompts (nombre de mots, règles de formatage). D’autres sont spécifiques au prompt (une success story client devrait référencer une métrique de résultat spécifique).

Étape 3 : Exécuter et noter

Exécutez chaque prompt, appliquez chaque assertion et produisez un score : 23/25, 24/25, 25/25. Le dénominateur reste constant ; le numérateur reflète la qualité. C’est le fondement de ce que la communauté TDD-pour-LLM appelle « l’ingénierie de prompt pilotée par les tests », où les spécifications de sortie attendues sont définies avant l’écriture du prompt.

Principes de conception des assertions

Mesurable sans interprétation. « Contient au moins une statistique » est mesurable. « Utilise des données convaincantes » ne l’est pas. Si deux évaluateurs pouvaient être en désaccord sur le résultat, l’assertion est trop subjective. La documentation de Promptfoo catégorise explicitement cela comme la catégorie d’assertions « déterministes », distincte des évaluations notées par modèle.

Liée aux résultats de qualité. Chaque assertion devrait correspondre à un indicateur de qualité réel qui compte pour le résultat final. « Nombre de mots inférieur à 300 » compte parce que les données LinkedIn montrent systématiquement que les posts de 150 à 300 mots tendent à générer des taux d’engagement plus élevés. N’ajoutez pas d’assertions juste pour gonfler le total.

Indépendante. Chaque assertion teste une seule chose. Si l’assertion 3 dépend de l’assertion 2, une seule cause racine d’échec ressemble à deux échecs, faussant le score.

Stable entre les exécutions. La même sortie devrait toujours produire les mêmes résultats d’assertion. Les assertions impliquant la correspondance de chaînes, le comptage ou la détection de motifs sont naturellement stables. Les assertions nécessitant une interprétation ne le sont pas.

Les assertions binaires dans les boucles d’amélioration autonome

Les assertions binaires deviennent les plus puissantes lorsqu’elles sont combinées avec des boucles d’amélioration autonome : des systèmes qui modifient leurs propres instructions, testent la sortie et conservent ou annulent les changements en fonction du score.

Comment fonctionne la boucle

1. Référence : Exécuter tous les tests, noter la sortie actuelle (par exemple, 21/25)
2. Modifier : Effectuer un changement dans le prompt ou les instructions système
3. Retester : Exécuter à nouveau tous les tests, noter la sortie modifiée
4. Décider : Si le score s’améliore (22/25), conserver le changement. S’il baisse (20/25), annuler.
5. Répéter : Effectuer un changement différent et boucler

Ce schéma n’est pas théorique. Le cookbook d’OpenAI le documente comme l’architecture « Self-Evolving Agents », où les agents capturent les problèmes de performance, apprennent du retour d’information et propagent les améliorations dans les flux de travail de production. Le système AlphaEvolve de Google DeepMind, dévoilé en mai 2025, utilise une approche évolutive similaire où un LLM génère des modifications candidates d’algorithmes et la sélection est pilotée par des fonctions d’évaluation automatisées. Les chercheurs derrière le framework SICA ont rapporté des améliorations de performance de 17 à 53 pour cent sur des tâches de codage grâce à des agents qui éditent leurs propres prompts et heuristiques en utilisant ce schéma de boucle.

Le framework DSPy de Stanford formalise cela davantage. Les optimiseurs DSPy ajustent automatiquement les prompts et les poids pour maximiser les métriques spécifiées par le développeur. L’exigence clé ? Ces métriques doivent être des fonctions calculables, ce qui est exactement ce que fournissent les assertions binaires.

Pourquoi les assertions binaires permettent les boucles autonomes

• La notation automatisable signifie qu’aucun humain n’est nécessaire dans la boucle
• Un signal d’amélioration clair rend 22/25 supérieur à 21/25 sans ambiguïté
• L’attribution grâce à un changement par itération signifie que vous savez ce qui a causé l’amélioration
• La convergence car le système tend vers des scores plus élevés à chaque changement conservé

Trajectoires d’amélioration typiques

Les boucles autonomes suivent des trajectoires prévisibles :

• Itérations 1 à 5 : Amélioration rapide à mesure que les problèmes structurels évidents sont corrigés (par exemple, 18/25 grimpant à 23/25)
• Itérations 5 à 15 : Amélioration modérée à mesure que des problèmes plus subtils sont traités (23/25 atteignant 24/25)
• Itérations 15 et au-delà : Rendements décroissants à mesure que le système approche de son plafond

Un système qui commence à 18/25 pourrait atteindre 24 ou 25 sur 25 en 20 à 30 itérations, représentant environ 2 à 3 heures d’exécution autonome selon la latence du modèle. La même amélioration obtenue manuellement par évaluation humaine et ajustement de prompt prendrait typiquement des semaines.

La limite : ce que les assertions binaires ne peuvent pas mesurer

Les assertions binaires sont puissantes mais limitées. Elles excellent dans la mesure des dimensions de qualité structurelles, dénombrables et basées sur les motifs. Elles sont insuffisantes dans plusieurs domaines.

Ton et voix

« Est-ce que ça sonne comme notre marque ? » est fondamentalement subjectif. Vous pouvez l’approximer en vérifiant les mots interdits, les phrases requises et les motifs de longueur de phrases, mais le ressenti global d’une voix de marque résiste à la réduction binaire.

Qualité créative

« Cette accroche est-elle engageante ? » dépend du lecteur, du contexte et du paysage concurrentiel. Aucune assertion binaire ne capture si un contenu va réellement résonner auprès de son audience.

Pertinence contextuelle

« Cette réponse est-elle appropriée à la situation de ce client ? » nécessite de comprendre un contexte que les vérifications binaires ne peuvent pas capturer. Une réponse pourrait réussir tous les tests structurels et être quand même inadaptée à la situation spécifique.

La solution hybride

L’industrie a convergé vers une approche hybride. Utilisez les assertions binaires pour la qualité structurelle (les 60 à 70 pour cent de la qualité qui sont mesurables) et combinez-les avec une évaluation LLM-as-judge pour les dimensions qualitatives.

Promptfoo implémente cela directement. En plus de ses assertions déterministes, il offre les types d’assertions llm-rubric et g-eval notées par modèle qui utilisent un LLM secondaire pour évaluer le ton, la pertinence et la cohérence. La même suite de tests peut combiner des vérifications binaires (« la sortie contient moins de 300 mots ») avec des vérifications notées par modèle (« la sortie maintient un ton professionnel mais conversationnel ») et produire un score composite unique.

DeepEval adopte une approche hybride similaire avec plus de 50 métriques d’évaluation couvrant à la fois des vérifications déterministes et des critères évalués par LLM comme la pertinence des réponses, la détection d’hallucinations et le scoring de toxicité.

Cela signifie que vous ne gaspillez pas l’attention humaine sur des problèmes que les machines peuvent détecter (erreurs de formatage, dépassement du nombre de mots, sections manquantes) et vous ne prétendez pas que les machines peuvent évaluer ce qu’elles ne peuvent actuellement pas (créativité, nuance culturelle, jugement contextuel).

L’écosystème d’outils du monde réel

Les équipes qui implémentent les assertions binaires aujourd’hui disposent de plusieurs options prêtes pour la production.

Promptfoo

L’option open-source la plus populaire pour l’évaluation de prompts. Promptfoo utilise des fichiers de configuration YAML pour définir des suites de tests avec des assertions. Il supporte à la fois les assertions déterministes (contains, regex, equals, fonctions JavaScript) et les assertions notées par modèle (llm-rubric, G-Eval, search-rubric). Les tests s’intègrent directement dans les pipelines CI/CD, et les poids des assertions peuvent être personnalisés pour refléter les différences de priorité entre les critères.

DeepEval

Un framework open-source inspiré de Pytest, spécialement conçu pour les tests unitaires d’applications LLM. DeepEval fournit plus de 50 métriques intégrées et supporte l’intégration CI/CD via les lanceurs de tests standards. Sa fonction assert_test() rend le test par assertions binaires familier pour tout développeur ayant écrit des tests unitaires.

DSPy

Le framework de Stanford adopte une approche différente : plutôt que de tester la sortie après génération, les assertions DSPy contraignent la génération elle-même. Les DSPy Assertions définissent des règles que le LLM doit suivre, et les optimiseurs DSPy ajustent automatiquement les prompts et les poids pour satisfaire ces contraintes tout en maximisant les métriques spécifiées.

Braintrust et LangSmith

Des plateformes entreprise qui combinent évaluation et observabilité. Braintrust offre des flux d’évaluation automatisés avec un support solide TypeScript/JavaScript. LangSmith, construit par l’équipe LangChain, fournit une intégration profonde avec les applications basées sur LangChain. Les deux supportent des fonctions de scoring personnalisées capables d’implémenter la logique d’assertions binaires à grande échelle.

Implémenter les assertions binaires : guide étape par étape

Pour les équipes qui commencent aujourd’hui

1. Listez vos exigences de sortie. Qu’est-ce qui doit toujours être vrai concernant la sortie de votre outil’IA ? Notez-les sous forme de règles en langage naturel.
2. Convertissez en binaire. Réécrivez chaque exigence sous forme de question oui/non. « La sortie devrait être concise » devient « Le nombre de mots est-il inférieur à 300 ? »
3. Testez manuellement d’abord. Exécutez vos assertions à la main sur 5 à 10 sorties pour vérifier qu’elles capturent de vraies différences de qualité et ne produisent pas de faux positifs.
4. Choisissez un framework. Promptfoo pour la configuration YAML, DeepEval pour les tests style Pytest, ou des scripts personnalisés si vos besoins sont simples.
5. Automatisez. Écrivez vos assertions sous forme de code et intégrez-les dans votre flux de développement.
6. Notez et suivez. Produisez un nombre unique (nombre de réussites divisé par le total des assertions) et enregistrez les scores au fil du temps pour détecter les régressions.

Erreurs courantes à éviter

Trop d’assertions. Vingt-cinq est un bon point de départ. Cent crée du bruit et rend les améliorations individuelles invisibles dans le score.

Trop vague. « La sortie est bien structurée » n’est pas binaire. « La sortie contient au moins 3 sous-titres » l’est.

Tester les mauvaises choses. Les assertions devraient refléter ce qui compte réellement pour la qualité, pas ce qui est facile à mesurer. Une réponse parfaitement formatée mais factuellement fausse échoue quand même en production.

Pas de diversité dans les prompts de test. Exécuter le même prompt cinq fois ne teste pas l’éventail de l’application. Utilisez cinq prompts différents qui représentent vos cas d’utilisation réels pour détecter les faiblesses systématiques.

Ignorer le fossé qualitatif. Les assertions binaires gèrent la qualité structurelle. Vous avez toujours besoin d’une revue humaine ou d’une évaluation LLM-as-judge pour le ton, la créativité et la pertinence contextuelle. Les équipes qui se fient exclusivement aux assertions binaires développent des angles morts dans ces domaines.

Conclusion

Les assertions binaires transforment la qualité IA d’une opinion en un nombre. Ce nombre peut être suivi, comparé, automatisé et systématiquement amélioré. Les assertions elles-mêmes sont simples (vrai ou faux, réussi ou échoué) mais la discipline de les définir force les équipes à articuler ce que « qualité » signifie réellement pour leur cas d’utilisation spécifique.

L’écosystème a mûri rapidement. Promptfoo, DeepEval et DSPy fournissent des implémentations prêtes pour la production. Le schéma de boucle d’amélioration autonome, validé par les recherches d’OpenAI, Google DeepMind et Stanford, transforme ces assertions en moteur d’optimisation continue. Et l’approche hybride, combinant assertions déterministes et évaluation LLM-as-judge, répond à la limite que tout ce qui mérite d’être mesuré n’est pas binaire.

Les équipes qui adoptent les frameworks d’assertions binaires obtiennent deux avantages : elles peuvent exécuter des boucles d’amélioration autonomes qui optimisent la qualité structurelle pendant la nuit, et elles libèrent leurs évaluateurs humains pour se concentrer sur les dimensions qualitatives (ton, créativité, contexte culturel) où le jugement humain est irremplaçable. Les deux dimensions s’améliorent. Aucune n’est gaspillée.

Sources et lectures complémentaires

• Promptfoo Deterministic Metrics Documentation
• DeepEval: The LLM Evaluation Framework
• Self-Evolving Agents: Autonomous Agent Retraining
• DSPy Optimization Overview
• LLM Testing: Top Methods and Strategies
• Testing LLM Applications: A Practical Guide
• Promptfoo Assertions and Metrics
• The Complete Guide for TDD with LLMs