🤖 AI

Faithful Autoformalization of Natural Language Assertions

Le papier présente Monty, un cadre d'autoformalisation qui améliore la précision de la synthèse d'assertions exécutables à partir du langage naturel en filtrant les sorties générées par les LLM grâce à de nouveaux scores de conformité et de validité, atteignant un gain de précision moyenne allant jusqu'à 20 points par rapport aux méthodes de traduction naïves.

Auteurs originaux : Hongyi Liu, Madhusudan Parthasarathy, Adithya Murali

Publié 2026-07-16

📖 8 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Hongyi Liu, Madhusudan Parthasarathy, Adithya Murali

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 dilemme du traducteur : quand le code rencontre les mots humains

Imaginez que vous construisez une ville numérique massive. Pour que la circulation soit fluide et que les bâtiments tiennent debout, chaque coin de rue et chaque gratte-ciel doit avoir un livre de règles. Dans le monde du logiciel, ces livres de règles sont appelés « spécifications formelles ». Ce sont des instructions mathématiques précises qui disent exactement à un ordinateur ce qu'un morceau de code est censé faire et ce qu'il ne doit jamais faire. Considérez-les comme les lois immuables de la physique pour un monde numérique. Le problème, c'est que l'écriture de ces lois est incroyablement difficile. Cela exige un niveau de précision qui donne l'impression de parler une langue totalement différente, une langue que la plupart des programmeurs humains trouvent fastidieuse et sujette aux erreurs.

Entrez dans le problème de l'« autoformalisation ». Il s'agit de la quête consistant à prendre l'idée désordonnée d'un humain en langage naturel — comme « ne laisse pas la liste devenir trop grande » — et à la traduire automatiquement en ce code mathématique strict. Pendant des années, des scientifiques ont tenté d'utiliser l'Intelligence Artificielle (IA), plus précisément les Grands Modèles de Langage (LLM), pour agir comme des traducteurs. Ces modèles d'IA sont comme des polyglottes surdoués qui ont lu presque tout ce qui a été écrit. Ils sont excellents pour deviner le sens d'une phrase. Mais voici le piège : lorsque vous demandez à une IA de traduire une pensée humaine vague en un contrat juridique strict, elle hallucine souvent. Elle peut inventer des règles qui n'existent pas, omettre un détail minuscule qui brise tout le système, ou traduire avec assurance un « peut-être » en un « certainement ». La question centrale que cet article aborde est la suivante : comment faire confiance à un traducteur IA lorsque les enjeux sont élevés et que les instructions humaines sont floues ?

Rencontrez Monty : le détective qui vérifie les devoirs de l'IA

Cet article présente un nouveau cadre appelé Monty, un système conçu pour être un éditeur sceptique et méticuleux pour les règles de code générées par l'IA. Les auteurs, des chercheurs de l'Université du Wisconsin-Madison et de l'Université de l'Illinois, ont réalisé que demander simplement à une IA de traduire une phrase en code ne suffit pas. Si vous demandez à une IA de traduire « la liste doit être vide », elle pourrait deviner que cela signifie « la liste contient zéro élément » ou « la liste n'a aucun élément du tout ». Les deux semblent corrects, mais en code informatique, ils peuvent signifier des choses très différentes.

Monty ne se contente pas de faire confiance à la première réponse donnée par l'IA. Au lieu de cela, il agit comme un détective menant une série de tests. Voici comment l'histoire se déroule :

1. L'IA génère une foule de suspects
D'abord, Monty demande à un Grand Modèle de Langage de traduire une assertion en langage naturel (une phrase humaine) en code formel. L'IA ne donne pas seulement une réponse ; elle génère toute une foule de traductions « candidates ». Certaines peuvent être parfaites, d'autres légèrement décalées, et d'autres complètement erronées.

2. Le test de « Fuzz » : casser le code
Ensuite, Monty soumet ces traductions candidates à un test de stress appelé « fuzzing ». Imaginez un robot lançant des entrées aléatoires et sauvages au code pour voir s'il plante ou se comporte étrangement.

Si une traduction candidate fait planter l'ordinateur ou génère une erreur, Monty l'élimine immédiatement.
Si la traduction fonctionne mais ne correspond pas à la logique de la phrase humaine originale, elle reçoit un score faible.
Crucialement, Monty ne suppose pas que la phrase humaine est correcte. Parfois, un programmeur écrit une règle qui est en fait fausse (une règle « buggée »). Monty est assez intelligent pour réaliser qu'une traduction « valide » d'une règle « buggée » est toujours un bug. Il recherche à la fois la traduction la plus probable et correcte ainsi que la plus probable et incorrecte pour voir laquelle correspond au contexte.

3. La vérification de la « Couverture de clauses » : la traduction inverse
C'est l'arme secrète de Monty. Pour vérifier si une traduction par l'IA est véritablement fidèle, Monty utilise une astuce ingénieuse appelée couverture de clauses (clausal coverage). Il prend le code formel de l'IA et demande à l'IA de le traduire à nouveau en anglais courant. Ensuite, il compare cette nouvelle phrase en anglais avec la phrase humaine originale.

L'IA a-t-elle oublié une partie de la phrase originale ?
A-t-elle ajouté quelque chose qui n'y était pas ?
A-t-elle changé le sens ?
L'IA agit comme un juge, donnant un score basé sur la manière dont les morceaux (les clauses) des deux phrases correspondent. Si la rétro-traduction manque un détail clé, le score chute, et ce candidat est filtré.

4. L'affrontement final : l'apprentissage actif
Parfois, l'IA génère deux candidats qui semblent tous deux parfaits et passent tous les tests, mais qui signifient légèrement des choses différentes. C'est là que l'ambiguïté du langage humain frappe de plein fouet. Dans ces cas rares, Monty ne devine pas. Il utilise l'apprentissage actif. Il trouve un scénario spécifique (une « évaluation distinctive ») où les deux candidats se comporteraient différemment. Il pose alors une question simple à un humain (ou à un oracle simulé) : « Dans ce cas précis, quelle règle vouliez-vous réellement dire ? ». L'humain choisit le vainqueur, et Monty verrouille la bonne traduction.

Ce que Monty a découvert

Les chercheurs ont testé Monty sur 541 tâches différentes impliquant le code Java, qui est un langage de programmation populaire. Ils ont utilisé des ensembles de données comprenant à la fois des règles parfaitement écrites et des règles intentionnellement cassées pour voir si Monty pouvait gérer le désordre de la vie réelle.

Les résultats sont prometteurs. Lorsqu'ils ont laissé l'IA traduire naturellement sans l'aide de Monty, la précision était correcte mais loin d'être parfaite. Par exemple, en utilisant un modèle spécifique appelé Qwen2.5-Coder, l'IA brute a réussi la traduction environ 75 % du temps sur un ensemble de données. Mais quand Monty est intervenu pour filtrer et vérifier les réponses, cette précision a bondi à 91,6 %. Sur un autre ensemble de données, elle est passée de 64 % à 85 %.

L'article suggère que Monty est particulièrement efficace pour corriger le problème de la « précision ». Cela signifie que lorsque Monty dit : « Voici la règle correcte », vous pouvez beaucoup plus lui faire confiance que lorsque vous demandez simplement à une IA et que vous acceptez sa première réponse. Il a réussi à faire cela sans rejeter trop de réponses correctes (en maintenant un « rappel » élevé).

Ce que Monty ne fait pas

Il est important de savoir ce que cet article ne prétend pas. Monty n'est pas une baguette magique qui résout tous les problèmes de programmation.

Il ne cherche pas à comprendre l'« intention » de haut niveau d'un projet logiciel entier (comme « construis-moi une application de réseau social »). Il se concentre strictement sur la traduction de règles spécifiques et localisées pour des morceaux de code individuels.
Il ne prétend pas avoir résolu le problème de l'ambiguïté pour toujours. Parfois, l'entrée humaine est si vague que même Monty a besoin qu'un humain intervienne pour clarifier.
Les auteurs argumentent explicitement contre l'idée selon laquelle nous devrions supposer que chaque règle écrite par un programmeur est correcte. De nombreux outils plus anciens supposaient que si une règle était écrite, elle devait être vraie. Monty rejette cela, montrant que parfois, l'objectif est de trouver la règle qui échoue, prouvant ainsi que le code est buggé.

L'essentiel

En fin de compte, Monty suggère que l'avenir de l'écriture de code ne consiste pas seulement à demander à une IA de faire le travail. Il s'agit de construire un système où l'IA génère des idées, mais où un processus rigoureux et intelligent les vérifie par rapport à la réalité. En combinant la créativité de l'IA avec le scepticisme des tests et la précision de la « rétro-traduction », Monty montre une voie pour rendre les logiciels plus sûrs et plus fiables, transformant les pensées désordonnées et ambiguës des développeurs humains en les lois propres et inviolables du monde numérique. L'article suggère que, bien que nous n'y soyons pas encore, cette approche de « vérification du travail » est une étape significative vers la transformation de l'IA en un partenaire de confiance dans le développement de logiciels.

Résumé Technique : Autoformalisation Fidèle des Assertions en Langage Naturel

Énoncé du Problème

Le document traite du défi d'une autoformalisation fiable : la synthèse d'assertions formelles exécutables (par exemple, en Java Modeling Language, JML) à partir de spécifications en langage naturel (LN). Bien que les grands modèles de langage (LLM) offrent une voie pour combler le fossé entre l'intention informelle du développeur et les spécifications formelles, les approches actuelles souffrent de deux problèmes critiques :

Le manque de fidélité (Unfaithfulness) : Les LLM génèrent souvent des formalisations qui ne reflètent pas précisément le contenu sémantique de l'assertion originale en LN.
L'ambiguïté : Le langage naturel est intrinsèquement ambigu. Les travaux existants supposent souvent implicitement qu'une assertion en LN décrit une propriété valide du code. Cependant, dans des contextions comme la recherche de bogues ou le test de code généré par IA, l'assertion peut être destinée à être invalide (c'est-à-dire pour révéler un échec). Supposer la validité peut conduire à filtrer la formalisation correcte si le code est buggé, ou à accepter une formalisation qui ne vérifie pas l'intention de l'utilisateur.

L'objectif est de produire une formalisation qui soit fidèle à la spécification en LN, que l'assertion résultante soit valide ou invalide par rapport à l'implémentation du code.

Méthodologie : Le Cadre Monty

Les auteurs proposent Monty, un cadre qui combine la génération par LLM avec le test de programmes et l'apprentissage actif pour résoudre l'ambiguïté et garantir la fidélité. Le pipeline se compose de quatre étapes :

1. Génération de Candidats

Étant donné un module de code (classe), les signatures de méthodes, la documentation et une spécification en LN, un LLM est incité à générer plusieurs spécifications candidates ( $\psi_1, \dots, \psi_n$ ) dans un langage logique exécutable (JML).

2. Filtrage et Notation

Les candidats sont évalués à l'aide de deux signaux complémentaires :

Score de Validité (au niveau de l'exécution) : Un générateur de tests (Randoop) crée des entrées de test pour vérifier les candidats.
- Vérification Syntaxique : S'assure que le code compile.
- Vérification de Sécurité de Fuzzing (Fuzz-Safety) : S'assure que l'assertion ne lève pas d'exceptions d'exécution.
- Vérification Sémantique de Fuzzing (Fuzz-Semantic) : Détermine si l'assertion est test-valide ou test-invalide pour la méthode donnée.
- Note : Le cadre ne rejette pas les candidats simplement parce qu'ils sont test-invalides ; il les préserve pour gérer les cas où l'utilisateur souhaite trouver des bogues.
Score de Conformité (au niveau sémantique) : Une nouvelle métrique appelée Couverture Clause par Clause (Clausal Coverage) est utilisée.
- Le candidat formel est retraduit en langage naturel par un LLM.
- Un second LLM (agissant comme juge) compare la structure clause par clause de cette description en langage naturel générée avec l'assertion originale en LN.
- Il vérifie la Correction (Soundness) (la description couvre-t-elle toutes les clauses de l'original ?) et la Complétude (Completeness) (contient-elle des informations supplémentaires ou conflictuelles ?).
- Un score dans l'intervalle $[-1, 1]$ est attribué, où $+1$ indique une conformité parfaite. Les candidats en dessous d'un seuil (par exemple, 0,6) sont rejetés.

3. Matrice de Décision

Le système sélectionne les formalisations "les plus probablement fidèles" en séparant les candidats en deux catégories basées sur la vérification de validité :

Le candidat ayant le score de conformité le plus élevé parmi ceux qui sont test-valides.
Le candidat ayant le score de conformité le plus élevé parmi ceux qui sont test-invalides.
Cette approche reconnaît que la "bonne" formalisation dépend de l'intention de l'utilisateur (documentation vs recherche de bogues) et évite le biais de présumer la validité.

4. Désambiguïsation par Apprentissage Actif

Si un candidat valide et un candidat invalide subsistent (et que les deux ont des scores de conformité élevés), le système identifie une évaluation distinguante (un état d'entrée spécifique) où les deux candidats diffèrent.

Le système interroge l'utilisateur (ou un oracle lors de l'évaluation) pour déterminer quel candidat satisfait la spécification voulue pour cette évaluation spécifique.
Le système sélectionne ensuite la formalisation correspondante.

Principales Contributions

Cadre d'Autoformalisation Fidèle : Un pipeline qui génère à la fois des formalisations probablement valides et probablement invalides, traitant la limitation des travaux antérieurs qui supposent que les assertions doivent être valides.
Vérification de Conformité par Couverture Clause par Clause : Une technique novatrice utilisant le "LLM-as-a-Judge" pour évaluer le chevauchement sémantique entre le LN et les assertions formelles via un aller-retour de traduction et une analyse de couverture au niveau des clauses. L'article affirme que cela surpasse les bases de comparaison de l'inférence de langage naturel (NLI) standard.
Désambiguïsation par Apprentissage Actif : Un mécanisme pour résoudre les ambiguïtés inhérentes au LN en générant des cas de test spécifiques qui distinguent les candidatures fidèles concurrentes.
Nouvelles Suites de Benchmarks : Les auteurs ont constitué des ensembles de données contenant 541 tâches de génération d'assertions à travers 22 classes de type collections Java. Ceux-ci incluent :
- C2S-Augmenté : Spécifications en LN générées synthétiquement à partir d'assertions formelles.
- Jeux de données avec Bogues : Scénarios avec du code buggé ou des assertions intentionnellement incorrectes ou trompeuses.
- Spécifications en LN Manuelles : Spécifications écrites par des humains pour tester la généralisabilité.

Résultats Expérimentaux

Les auteurs ont évalué Monty sur 541 tâches en utilisant divers modèles de base (incluant GPT-oss, Qwen2.5-Coder et des modèles plus larges).

Amélioration de la Précision : Monty améliore considérablement la précision de l'autoformalisation par rapport à l'utilisation naïve de "One-shot" LLM.
- Sur le jeu de données C2S-Augmenté, Qwen2.5-Coder (32B) a fait passer la précision de 75 % à 91,6 %.
- Sur le jeu de données de LN Manuelle, la précision est passée de 64,1 % à 85,2 %.
Maintien du Rappel : Le processus de filtrage maintient un rappel élevé (par exemple, 97,6 % pour GPT-oss sur C2S-Aug), indiquant que les candidats corrects sont rarement rejetés.
Robustesse à l'Ambiguïté : Le cadre gère avec succès les jeux de données "Buggy" où l'assertion est censée être invalide, un scénario où les LLM naïfs échouent souvent ou hallucinent des assertions valides.
Études d'Ablation :
- La méthode de Couverture Clause par Clause a surpassé les bases de comparaison (incluant la NLI et les simples vérifications de l'aller-retour) dans les mesures AUC.
- Les informations contextuelles (signatures de code, documentation) se sont révélées cruciales pour la qualité du classement.
- L'apprentissage actif a été invoqué dans une petite fraction des cas (où les candidats valides et invalides passaient tous deux la conformité), mais s'est avéré efficace (100 % de précision dans les cas éligibles pour GPT-oss).

Signification et Revendications

L'article affirme que Monty offre une voie plus fiable vers l'autoformalisation en traitant explicitement l'ambiguïté du langage naturel et l'incertitude de la validité des assertions.

Fiabilité : En filtrant pour la conformité et en séparant les candidats valides/invalides, l'outil produit des formalisations qui sont plus susceptibles d'être des traductions fidèles de l'intention du développeur.
Praticité : L'approche ne nécessite pas de réglage fin (fine-tuning) des modèles ; elle repose sur le prompting, le test et une matrice de décision, ce qui la rend applicable aux LLM existants.
Limites : Les auteurs notent que l'approche repose sur des assertions en LN localisées (au niveau du module) et ne tente pas de formaliser l'intention de haut niveau d'une application ou d'extraire des spécifications de documentations non structurées sans une cible de méthode spécifique. La composante d'apprentissage actif nécessite une interaction utilisateur, bien que le système minimise cela en ne sollicitant l'utilisateur que lorsque c'est nécessaire.

Ce travail se positionne comme une étape vers le développement piloté par la spécification avec l'IA, où les spécifications lisibles par l'humain sont rédigées puis rigoureusement vérifiées par rapport au code à l'aide de l'autoformalisation et des tests.