Imaginez un monde où vous possédez un assistant robotique super intelligent capable d'écrire du code informatique pour vous. C'est comme avoir un apprenti de génie qui peut taper plus vite que n'importe qui et qui connaît un million d'astuces de programmation. Mais voici le piège : ce robot est un peu un « complaisant ». Si vous lui dites : « Répare ce bouton cassé », il réparera joyeusement le bouton. Mais si le bouton était cassé parce qu'une règle secrète que vous ne lui avez jamais dite existait (comme « ne jamais laisser le bouton devenir rouge les mardis »), le robot pourrait réparer le bouton tout en cassant accidentellement cette règle secrète. Si vous ne le prenez pas en flagrant délit, il pourrait commettre exactement la même erreur la fois suivante, car il ne se souvient que de la correction spécifique, et non de la raison derrière celle-ci. C'est le problème des « agents de codage » dans le monde réel : ils sont excellents pour colmater les brèches, mais terribles pour apprendre les lois profondes et non écrites de la manière dont un système doit se comporter, à moins qu'on ne leur enseigne explicitement.

Ce document, écrit par Muness Castle et Eric Rubeck, s'attaque précisément à ce problème. Il introduit une nouvelle façon de travailler appelée « Synthèse Agentique contre les Croquis Supplémentés par Contre-Exemples » (Agentic Synthesis against Counterexample-Supplemented Sketches). Voyez cela comme un camp d'entraînement rigoureux pour les codeurs IA. Au lieu de simplement laisser l'IA deviner et vérifier, cette méthode force un humain à agir comme un entraîneur strict. Lorsque l'IA commet une erreur qui enfreint une règle cachée, l'humain ne dit pas seulement « répare ça ». Il dit : « Voici l'erreur, voici la bonne réponse, et voici la règle que tu as enfreinte. » L'IA doit alors réécrire son propre « manuel d'instructions » (appelé croquis ou sketch) pour inclure cette nouvelle règle avant d'être autorisée à réessayer. Le papier teste cette idée avec une application de navigateur fictive appelée « CatSynth » et conclut que cette méthode aide l'IA à mieux apprendre les règles qu'en lui montrant simplement une liste d'erreurs passées, bien que les auteurs précisent avec prudence qu'il s'agit d'une expérience spécifique et non d'un remède miracle pour toutes les situations.

L'histoire du Croquis et du Livre de Règles

Imaginez que vous essayez de construire un robot qui choisit le chat parfait pour une famille. Vous donnez au robot un « Croquis » (Sketch). Dans cette histoire, un Croquis n'est pas un dessin ; c'est un manuel d'instructions incomplet et rudimentaire. Il dit des choses comme : « Le chat doit être duveteux » et « Le chat doit être amical ». Mais il manque la partie la plus importante : « Le chat ne peut pas être un Persan car la famille a une allergie aux chats. »

Au début, le robot (l'agent de codage) regarde le Croquis et dit : « D'accord, les Persans sont duveteux et amicaux ! Je vais choisir un Persan ! » Il écrit le code pour faire cela. Mais ensuite, un expert humain (l'Expert en la Matière) regarde le résultat et dit : « Oh là là, stop ! C'est une catastrophe. La famille a une allergie. Tu as choisi le mauvais chat. »

Dans l'ancienne méthode, l'humain pourrait simplement dire : « D'accord, corrige cela, choisis un autre chat. » Le robot choisirait alors un autre chat, peut-être un Siamois. Mais le robot n'apprendrait pas réellement la règle sur les allergies. Il se souviendrait juste de « Ne pas choisir de Persans pour cette famille spécifique. » La prochaine fois, si la famille changeait d'avis sur l'allergie sans que le robot ne le sache, ou si une nouvelle famille avec une allergie arrivait, le robot pourrait commettre la même erreur.

Ce document propose une boucle différente, plus stricte. Lorsque l'expert humain dit : « Mauvais chat ! », il ne se contente pas de corriger le résultat. Il agit comme un juge dans un tribunal. Il dit :

1. L'Erreur : « Tu as choisi un Persan. »
2. La Correction : « Le bon chat est un Sibérien. »
3. La Règle : « La règle que tu as enfreinte est : "Les règles strictes (comme les allergies) doivent toujours l'emporter sur les préférences souples (comme le duvetité)". »

Ensuite, un « Opérateur » humain (le patron) doit explicitement donner son aval. Il dit : « Oui, c'est une vraie règle maintenant. » Une fois signé, le robot doit réécrire son Croquis pour y inclure cette nouvelle règle. Le robot ne peut pas simplement colmater le code ; il doit mettre à jour le manuel.

Le contrôle en deux étapes : Le Rejou (Replay) et la Comparaison (Compare)

Pour s'assurer que le robot a réellement appris la leçon, le document utilise un test ingénieux en deux étapes, semblable à un agent de sécurité vérifiant un visiteur à une porte.

1. Le Rejou (Le test « As-tu réparé le désastre ? ») : Cela vérifie si la nouvelle réponse du robot résout le problème immédiat. Le robot a-t-il choisi un chat qui est duveteux et amical ? Si oui, le « Rejou » réussit.
2. La Comparaison (Le test « As-tu suivi les règles ? ») : C'est la partie délicate. Elle vérifie si le robot a choisi le bon chat en fonction de la nouvelle règle. A-t-il choisi le Sibérien au lieu du Persan ? S'est-il souvenu de l'allergie ? Si le robot a choisi un Persan duveteux qui résout le problème du « duvet » mais enfreint la règle de l'« allergie », la « Comparaison » échoue.

Le document appelle cela la « Porte » (Gate). Si le robot réussit les deux, il passe à la suite. S'il échoue à la Comparaison, cela signifie que le robot a réglé le problème de surface mais a ignoré la règle profonde. Le robot doit alors retourner corriger son Croquis à nouveau.

L'expérience CatSynth

Les auteurs ont testé cela avec un projet fictif appelé CatSynth. Ils ont créé un scénario où un robot devait choisir un chat basé sur une liste de préférences (gros, duveteux, affectueux) et une règle stricte (pas de chats déclenchant des allergies).

Ils ont lancé une simulation où le robot tentait de résoudre 14 cas « gelés » (des scénarios figés avant l'expérience).

• Le Résultat : Dans 8 des 14 cas, la première proposition du robot était erronée car il avait manqué une règle. Ces 8 cas sont devenus des « contre-exemples ».
• Le Processus : Pour chacune de ces 8 erreurs, un humain a approuvé la correction, le robot a mis à jour son Croquis, et le robot a essayé à nouveau.
• Le Test : Après que le robot a fini d'apprendre, les auteurs l'ont testé sur 21 nouveaux cas cachés (des cas qu'il n'avait jamais vus auparavant).

Voici ce qu'ils ont découvert :

• Lorsqu'ils ont reconstruit le code du robot de zéro en utilisant uniquement le Croquis final évolué (celui qui avait été mis à jour avec toutes les règles), le robot a réussi 19 cas sur 21 de ces nouveaux cas.
• Lorsqu'ils ont tenté de reconstruire le robot en lui montrant le Croquis original plus une longue liste de tous les exemples passés (la méthode « replay-all »), le robot n'a réussi que 15 cas sur 21.

Cela suggère que faire apprendre au robot les règles et les écrire dans son Croquis était plus efficace que de simplement lui montrer un historique d'erreurs. Le robot qui a appris les règles a mieux généralisé à de nouvelles situations.

Ce que cela signifie (et ce que cela ne signifie pas)

Le document est très prudent pour ne pas survendre les résultats. Les auteurs ne prétendent pas que c'est la « méthode parfaite » pour résoudre tous les problèmes de codage de l'IA pour toujours. Ils admettent qu'il s'agissait d'une simulation avec un modèle spécifique (GPT-5.4-mini) et un ordre spécifique de problèmes. Ils ignoreent si cela fonctionnerait exactement de la même manière avec un autre robot ou un autre ensemble de règles.

Cependant, l'expérience démontre quelque chose d'important : Il est préférable d'enseigner à une IA le « Pourquoi » (la règle) plutôt que simplement le « Quoi » (l'exemple).

Si vous montrez simplement à une IA une liste de « Ne fais pas X », elle pourrait mémoriser la liste mais manquer le schéma directeur. Mais si vous la forcez à mettre à jour son propre manuel d'instructions (le Croquis) chaque fois qu'elle enfreint une règle, et que vous la testez en jetant son ancien code et en le reconstruisant à partir de ce manuel, vous obtenez une IA plus intelligente et plus fiable.

Les auteurs soulignent également que cette méthode demande beaucoup d'efforts humains. Il faut un expert humain pour repérer l'erreur, un opérateur humain pour approuver la nouvelle règle, et un humain pour organiser la liste des tests. Ce n'est pas un système de type « configurer et oublier ». C'est un partenariat où l'humain est le professeur et l'IA est l'élève qui doit prendre des notes et réécrire son propre manuel.

À retenir

En fin de compte, ce document est un guide sur la façon d'empêcher l'IA d'être un correcteur « plausible mais erroné ». Il soutient que lorsqu'une IA commet une erreur, nous ne devrions pas simplement colmater le code. Nous devrions traiter l'erreur comme une leçon qui modifie la compréhension fondamentale du monde par l'IA. En utilisant un « Croquis » pour détenir les règles, une « Porte » pour vérifier le travail, et un humain pour approuver les leçons, nous pouvons construire une IA qui ne se contente pas de deviner la bonne réponse, mais qui comprend réellement pourquoi elle est la bonne.

Les auteurs concluent que, bien que cette méthode n'ait pas résolu tous les problèmes de leur simulation (le robot a quand même échoué sur 2 cas sur 21), elle a prouvé que le « Croquis évolué » transmettait mieux la connaissance qu'un simple historique d'exemples. C'est un pas vers un codage par IA qui ressemble davantage à un apprentissage discipliné qu'à une chance sur deux.