🤖 AI

Judging Is Not Enumerating: Silent Omissions in LLM-Authored Acceptable Sets

Cet article démontre que si les grands modèles de langage excellent pour juger si des candidats appartiennent à un ensemble correct, ils échouent considérablement à rédiger des ensembles complets acceptables en raison d'une tendance systématique aux omissions silencieuses plutôt qu'aux sur-inclusions, un déficit qui persiste à travers divers domaines et échelles de paramètres.

Auteurs originaux : Wenhui Chen, Jianlin Chen, Ziyao Lin, Peiji Long, Chi Man Vong

Publié 2026-08-04

📖 8 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Wenhui Chen, Jianlin Chen, Ziyao Lin, Peiji Long, Chi Man Vong

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le Grand Renversement des Rôles : Quand l'IA devient le Professeur

Imaginez une salle de classe où les élèves ne se contentent plus de répondre aux questions ; ils écrivent les manuels scolaires, corrigent les examens et décident de ce qui compte comme une réponse « correcte ». C'est ce qui se passe actuellement dans le monde de l'intelligence artificielle. Les grands modèles de langage (LLM) sont promus du statut d'« examinés » (ceux qui passent le test) à celui d'« examinateurs » (ceux qui créent le test). Ils écrivent les règles, les clés de correction et les listes de contrôle qui indiquent aux autres systèmes d'IA s'ils font du bon travail.

Pour comprendre pourquoi cela est délicat, pensez à deux compétences différentes. La première est le Jugement : regarder une réponse unique et dire : « Oui, c'est juste » ou « Non, c'est faux ». La seconde est l'Auteur : créer l'intégralité de la liste de toutes les réponses correctes possibles à partir de zéro. C'est la différence entre un arbitre qui siffle lorsqu'un joueur sort des limites du terrain, et un entraîneur qui essaie d'écrire un livre de règles listant toutes les manières possibles dont un joueur pourrait sortir des limites sans en oublier une seule. Nous nous en soucions car si l'IA qui rédige le test commet une erreur, elle ne se contente pas de rater une question ; elle change la définition de ce qui est « correct » pour tous les autres, risquant de punir les bonnes réponses et de récompenser les mauvaises.

La Grande Découverte de l'Article : Le Fantôme Silencieux dans la Machine

Cet article étudie un bug étrange et dangereux dans la façon dont l'IA gère ces nouveaux rôles. Les chercheurs ont découvert que, si les modèles d'IA sont en réalité très doués pour le Jugement (détecter si une réponse spécifique est juste ou fausse), ils sont étonnamment mauvais pour l'Auteur (rédiger la liste complète de toutes les bonnes réponses).

Pensez à un jeu de « Jacques a dit ». Si vous demandez à l'IA : « Est-ce que "pomme" est un fruit ? », elle dira presque toujours « Oui » correctement. Mais si vous lui demandez : « Liste tous les fruits qui existent », elle commencera à lister des pommes et des bananes, puis elle va simplement... s'arrêter. Elle oubliera les oranges, les kiwis et les mangues. Elle n'oublie pas parce qu'elle ne sait pas ce qu'ils sont ; elle oublie parce qu'elle est mauvaise dans la tâche spécifique de rédiger la liste complète.

Les auteurs appellent cela les « Ciseaux Jugement-Énumération ». Imaginez une paire de ciseaux où une lame est le « Jugement » (tranchante et forte) et l'autre est l'« Auteur » (émoussée et faible). À mesure que les modèles d'IA deviennent plus grands et plus intelligents (passant de petits modèles à des modèles massifs), la lame du « Jugement » s'aiguise, mais la lame de l'« Auteur » ne s'aiguise presque pas. Elles ne rattrapent jamais leur retard. L'écart entre leur capacité à juger et leur capacité à lister reste large, peu importe la puissance de calcul que vous leur donnez.

Le Fantôme Silencieux : Pourquoi nous ne remarquons pas les erreurs

La partie la plus terrifiante de cette découverte est la manière dont l'IA échoue. Lorsqu'elle rédige une liste de bonnes réponses, elle n'ajoute généralement pas de fausses réponses (comme appeler un « rocher » un fruit). Au lieu de cela, elle commet des Omissions Silencieuses. Elle se contente d'oublier les vraies réponses.

Voici pourquoi c'est si dangereux :

Sur-inclusion (Ajouter des choses fausses) : Si l'IA ajoute accidentellement un « rocher » à la liste des fruits, un réviseur humain peut facilement le repérer. « Hé, les rochers ne sont pas des fruits ! », dira-t-il. C'est une erreur visible.
Omission (Oublier des choses vraies) : Si l'IA oublie de lister le « kiwi », il n'y a pas d'erreur visible. La liste semble juste un peu plus courte. Pour trouver le kiwi manquant, le réviseur doit connaître la réponse lui-même et la chercher.

L'article montre que les modèles d'IA sont 6 à 7 fois meilleurs pour repérer ce qu'ils ont ajouté par erreur que pour réaliser ce qu'ils ont oublié. C'est comme un étudiant qui est excellent pour trouver des fautes de frappe dans sa rédaction, mais incapable de réaliser qu'il a oublié d'écrire la conclusion. Parce que les parties manquantes sont invisibles, les « clés de correction » de l'IA finissent par être incomplètes, et les systèmes d'IA qui se basent sur ces clés finissent par punir des réponses correctes simplement parce qu'elles ne figuraient pas sur la liste.

L'échappatoire de la « Règle Magique »

Les chercheurs ont testé un contournement astucieux. Ils n'ont pas demandé à l'IA de lister les fruits, mais d'écrire la règle de ce qui fait qu'un fruit est un fruit (par exemple, « S'il pousse sur un arbre et possède des graines »). En faisant cela, l'IA est devenue presque parfaite (atteignant 99 % de précision).

Cela prouve que l'IA n'est pas stupide. Elle connaît les règles. Le problème réside purement dans l'acte de les lister. C'est comme un chef qui peut décrire parfaitement la recette d'un gâteau, mais qui oublie systématiquement d'écrire les trois derniers ingrédients lorsqu'on lui demande de faire la liste de courses complète. L'article montre que si vous pouvez amener l'IA à écrire la règle plutôt que la liste, le problème disparaît. Mais dans de nombreux cas réels (comme la rédaction d'une suite de tests pour du code informatique), il n'existe pas de règle simple à écrire ; vous devez lister les cas de test spécifiques, et c'est là que l'IA trébuche.

Pourquoi « Vérifier son propre travail » ne fonctionne pas

Vous pourriez penser : « Bon, si l'IA est mauvaise pour lister, peut-être peut-elle simplement vérifier sa propre liste pour corriger les erreurs ? » L'article a aussi testé cela. Ils ont demandé à l'IA de générer une liste, puis de générer une seconde liste, et enfin de filtrer la première liste à l'aide de la seconde.

Le résultat ? Cela n'a pas fonctionné. L'IA n'a pas pu corriger ses propres omissions. C'est comme demander à une personne qui est mauvaise en calcul de compter ses propres doigts pour voir si elle en a oublié certains. La capacité de « jugement » de l'IA est forte lorsqu'elle examine une liste claire et préétablie, mais elle s'effondre lorsqu'elle essaie de juger sa propre liste désordonnée et auto-générée. L'article conclut que demander à une IA de vérifier sa propre clé de correction est un piège ; elle a besoin d'un « étalon-or » externe, vérifié par l'humain, pour détecter les éléments manquants.

Le Coût Réel : La « Taxe » sur l'IA

Enfin, l'article a mesuré ce qui se passe lorsque cette clé de correction défectueuse est utilisée pour entraîner d'autres IA. Ils ont mis en place un scénario où une IA apprend en obtenant des points pour les bonnes réponses.

Lorsque l'IA utilisait une clé parfaite, faite par l'homme, elle apprenait bien.
Lorsqu'elle utilisait une clé faite par un modèle, elle apprenait nettement moins bien.

Sur une tâche de langage spécifique, l'IA utilisant la clé faite par le modèle a obtenu un score 18,5 points inférieur à celui de celle utilisant la clé parfaite. Même sur une tâche mathématique où les règles étaient simples, elle a perdu 1,9 point. Cette « taxe » se produit parce que la clé faite par le modèle est trop stricte : elle rejette de bonnes réponses que l'IA a générées mais qu'elle a oubliées d'inclure dans sa propre liste. L'IA est confuse, pensant que ses bonnes réponses sont fausses, et cesse d'être créative.

Ce qu'il faut retenir

L'article ne dit pas que l'IA est inutile. Il dit que lorsque nous demandons à l'IA d'être l'« examinateur » et de rédiger les règles de correction, nous devons être très prudents.

Ne demandez pas la liste, demandez la règle. Si l'IA peut écrire une règle (comme un script Python) pour vérifier les réponses, utilisez cela. C'est presque parfait.
Ne faites pas confiance aveuglément à la liste. Si l'IA doit écrire une liste de bonnes réponses, elle en oubliera presque certainement certaines.
Utilisez un « Gardien ». Avant de faire confiance à la clé de correction d'une IA, vérifiez si elle accepte une réponse connue comme étant correcte. Si elle rejette une réponse connue comme correcte, jetez la clé.
Corrigez, ne jetez pas. Si la clé rejette une réponse correcte, vous pouvez souvent simplement corriger l'erreur spécifique (comme le résultat attendu d'un test) plutôt que de tout jeter.

Le fond de l'histoire : l'IA est excellente pour repérer les erreurs, mais très mauvaise pour s'assurer qu'elle n'a rien oublié. Tant que nous n'aurons pas résolu ce problème d'« omission silencieuse », nous ne pourrons pas pleinement faire confiance à l'IA pour corriger ses propres devoirs.

Résumé Technique : Juger n'est pas Énumérer

Énoncé du Problème

Les modèles de langage (LLM) sont de plus en plus déployés non seulement comme des candidats répondant à des questions, mais comme des examinateurs qui rédigent les spécifications, les suites de tests, les clés de correction et les fonctions de récompense qui définissent la justesse pour les systèmes en aval. Cet article étudie une asymétrie critique dans ce renversement de rôle : alors que les modèles démontrent une forte capacité à juger si un candidat spécifique appartient à un ensemble acceptable, ils sont nettement moins performants lorsqu'il s'agit d'rédiger l'ensemble lui-même.

Le problème central est le « écart d'auteur » (authoring gap) : l'incapacité d'un modèle à matérialiser l'extension d'une spécification de correction (la liste de toutes les réponses valides ou la suite de tests qui les accepte) avec la même fidélité qu'il possède pour juger des candidats individuels. Cet écart est particulièrement dangereux car les artefacts produits (clés, rubriques, suites) deviennent la définition opérationnelle de la justesse pour d'autres systèmes, y compris l'Apprentissage par Renforcement avec Récompenses Vérifiables (RLVR). L'article postule que le mode de défaillance dominant est l'omission silencieuse — l'incapacité d'inclure des membres valides — ce qui est intrinsèquement difficile à auditer car une absence ne peut être contestée par un réviseur local de la même manière qu'une sur-inclusion.

Méthodologie

Les auteurs emploient un cadre de mesure rigoureux, sans recours à un juge, utilisant une vérité de terrain construite pour éviter la circularité (c'est-à-dire utiliser un modèle pour noter les spécifications de son propre modèle). L'étude utilise quatre constructions distinctes pour trianguler le phénomène à travers différents domaines et niveaux de complétude :

Constructions Algorithmiques (Vérité Complète) :
- Chaîne de caractères : Les modèles reçoivent une liste finie de 15 mots et un prédicat mécaniquement décidable (ex: « contient une double lettre »). La tâche consiste à lister tous les mots satisfaisant le prédicat.
- Arithmétique : Similaire à la tâche de chaîne, mais avec des prédicats numériques (ex: « divisible par 3 ») sur des listes d'entiers.
- Signification : Ces constructions éliminent le biais de l'incomplétude lexicale ; la vérité de terrain est calculable et exacte.
Construction Exécutable (Vérité Exécutable) :
- Basée sur HumanEval+ et MBPP+. Les modèles génèrent des suites de tests à partir de docstrings. La justesse est déterminée par l'exécution de la suite contre un pool de solutions vérifiées par un oracle (1 560 correctes, 904 incorrectes).
- Signification : Cela mesure la capacité d'auteur « intentionnelle » où l'ensemble est non borné et défini par l'exécution de code.
Construction Lexicale (Vérité Lexicale) :
- Basée sur les synsets de WordNet. Les modèles listent des mots correspondant à un sens spécifique.
- Signification : Utilisée pour la triangulation, bien que reconnue comme incomplète (le lexique peut omettre des synonymes valides). L'article traite la précision ici comme une limite inférieure et s'appuie sur les tendances de rappel.

Conception Expérimentale :

Interfaces Comparées :
- Jugement (Exécution) : Le modèle reçoit un candidat et on lui demande « Est-ce que $x \in S^*$ ? » (Classification ponctuelle).
- Rédaction (Authoring) : Le modèle doit émettre l'ensemble complet $\hat{S}$ (Énumération extensionnelle) ou un prédicat/suite (Rédaction intentionnelle).
Contrôles : L'étude contrôle l'échelle (de 3B à 24x paramètres), les familles de modèles (Qwen2.5, Qwen3, Llama, Mistral, Phi, Gemma), les variations de prompts et les stratégies de décodage (greedy vs. raisonnement activé).
Tests de Mitigation : L'article teste le « échantillonnage puis vérification » (auto-réparation), le filtrage par « sonde connue-correcte » et la « réparation de trace » (réécriture des valeurs attendues basée sur l'exécution de référence).
Impact Aval : Les auteurs mesurent la « taxe RLVR » en entraînant des politiques avec des clés rédigées par le modèle par rapport à des clés oracle pour quantifier la perte de précision.

Contributions Clés et Résultats

1. Les Ciseaux Jugement–Rédaction

La conclusion principale est un écart persistant et statistiquement significatif entre la performance de jugement et celle de rédaction à travers toutes les échelles et familles de modèles.

Vérité Complète : Sur les tâches algorithmiques, les scores F1 de jugement varient de 0,60 à 0,77, tandis que les scores F1 de rédaction varient de 0,26 à 0,48. L'écart ( $\Delta$ ) reste positif (+0,25 à +0,34) et ne se réduit pas à mesure que l'échelle du modèle augmente.
Code Exécutable : L'écart est plus sévère ici. Les modèles qui jugent la justesse du code avec un F1 de 0,74–0,90 rédigent des suites de tests qui n'acceptent que 19–42 % des solutions correctes de l'oracle (les suites de Llama étant encore moins performantes, à 8–10 %).
Indépendance de l'Échelle : L'écart persiste sur une plage de 24x les paramètres et différentes générations de modèles (incluant des modèles de pointe comme GPT-5.1 et Opus), bien qu'il se réduise légèrement sur des constructions plus simples pour les modèles les plus puissants.

2. Mécanisme : L'Omission Silencieuse

L'article identifie l'omission comme le mode d'erreur dominant, qui est « pauvre en témoins ».

Asymétrie d'Audit : La revue locale (soustractive) est très efficace pour détecter les sur-inclusions (faux positifs) mais échoue à détecter les omissions (faux négatifs). Dans des expériences contrôlées, les modèles détectent les sur-inclusions implantées 6 à 7 fois plus souvent que les omissions implantées.
Conséquence de la Revue : Parce que les pipelines de revue suppriment préférentiellement les sur-inclusions tout en échouant à récupérer les omissions, le processus de raffinement itératif déplace les artefacts vers la sous-acceptation (haute précision, faible rappel) plutôt que vers la réparation.

3. Nature du Déficit : Énumération vs Spécification

L'article distingue l'incapacité à spécifier une règle de l'incapacité à énumérer son extension.

Émission de Prédicat : Lorsqu'on demande d'écrire la règle (ex: un prédicat Python def accepts(w)) plutôt que la liste des réponses, les modèles atteignent un F1 quasi parfait (~0,99).
Conclusion : Le déficit n'est pas un manque de connaissance ou une incapacité à spécifier la logique. C'est un échec de matérialisation en un coup (one-shot) : l'incapacité d'énumérer exhaustivement l'ensemble induit par une spécification sans anticipation (lookahead), particulièrement lorsqu'aucune règle compacte n'est fournie pour la reformuler.

4. Mitigation et Réparation

L'Auto-Vérification Échoue : Le « échantillonnage puis vérification » (générer plusieurs candidats et les filtrer avec le propre juge du modèle) ne comble pas l'écart. L'union des échantillons ne parvient pas à couvrir la vérité de terrain (limite de récupération), et le propre juge du modèle s'effondre sur ses propres candidats proches de la limite.
Porte d'Entrée Externe : Écarter toute suite rédigée qui rejette une sonde connue-correcte (ex: une solution de référence) réduit les taux de faux rejets de 58–92 % à $\le$ 5 %. Cependant, cela rejette la majorité des suites (rendement de 5–39 %).
Réparation de Trace : Réécrire les valeurs attendues dans une suite échouée pour correspondre à la sortie d'une exécution de référence permet de récupérer 3,3x à 10,6x plus de suites utilisables. Cela démontre que l'échec réside dans le calcul des sorties attendues (intentionnel), et non dans la sélection des entrées (extensionnel).

5. Coût Aval : La Taxe RLVR

Lorsque des clés rédigées par des modèles sont utilisées comme signaux de récompense en RLVR :

Tâche Lexicale : L'entraînement sur une clé rédigée coûte 18,5 points de précision (relative à WordNet) par rapport à une clé oracle.
Tâche de Vérité Complète : Même avec un ensemble mécaniquement exact, le coût est de 1,9 point.
Mécanisme : La clé rédigée agit comme un « canal à deux voies », affamant les comportements corrects (omission) et récompensant les incorrects (pollution). La politique apprend à optimiser pour la clé défectueuse, entraînant un déficit de précision permanent qui ne disparaît pas avec l'augmentation de l'échelle du modèle.

Signification et Revendications

L'article prétend établir une limitation fondamentale dans le paradigide actuel consistant à utiliser les LLM comme vérificateurs et concepteurs de récompenses.

L'Asymétrie au Niveau Métaphorique : S'il est bien connu que la vérification est plus facile que la génération pour les solutions, cet article montre que générer la norme de vérification elle-même est plus difficile que de vérifier des candidats par rapport à une norme. L'« avantage de vérification » ne se transfère pas à la construction du vérificateur.
Erreur Directionnelle : L'échec n'est pas un bruit aléatoire ; c'est un biais systématique vers l'omission. Cela rend les spécifications rédigées « directionnellement fausses » d'une manière qu'une revue locale ne peut certifier ou corriger.
Implication Pratique : L'article soutient qu'il ne faut jamais faire confiance à une spécification rédigée en un coup comme étant une vérité de terrain. Au lieu de cela, les systèmes devraient :
1. Éliciter la règle (prédicat) plutôt que le registre (liste) lorsque cela est possible.
2. Filtrer tous les vérificateurs rédigés contre des sondes connues-correctes.
3. Utiliser l'exécution externe pour réparer les valeurs attendues plutôt que de rejeter l'intégralité de l'artefact.
Modestie : Les auteurs précisent explicitement que l'écart est spécifique à la rédaction en un coup (one-shot), de type greedy, sans raisonnement au moment de l'exécution (test-time reasoning). Ils reconnaissent que le raisonnement au moment de l'exécution (scratchpads) peut combler l'écart sur les tâches algorithmiques où une règle existe, mais cela ne répare pas de manière fiable la rédaction de suites de tests où la règle doit être inférée à partir de prose. Ils ne prétendent pas que les LLM ne peuvent pas être entraînés pour rédiger de meilleurs vérificateurs, mais que le régime zero-shot/one-shot actuellement déployé à grande échelle est insuffisant.

En résumé, l'article démontre que le rôle d'« examinateur » est actuellement hors de portée pour les LLM dans sa forme la plus exigeante (énumération exhaustive), créant un goulot d'étranglement silencieux et non auditable qui dégrade les systèmes en aval, particulièrement dans les pipelines RLVR.