Diversifying to Verify: When Task-Equivalent Programs Differ in Verifiability
Cet article présente Diversify2Verify, un pipeline basé sur les LLM qui démontre comment la génération d'implémentations de programmes diverses et équivalentes en termes de tâches améliore considérablement les taux de réussite de la vérification automatisée en identifiant des variantes plus propices à la preuve formelle.
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
Imaginez que vous essayez de construire un robot capable de résoudre une énigme mathématique. Vous disposez d'un assistant IA super intelligent (un grand modèle de langage) qui est excellent pour écrire du code. Habituellement, nous demandons à l'IA : « Écris un code qui résout cette énigme », et nous vérifions si le robot réussit quelques passages de tests. S'il réussit, nous disons : « Bon travail ! »
Mais dans le monde de la vérification formelle, réussir quelques tests ne suffit pas. C'est comme construire un pont et n'y faire passer qu'une voiture miniature. Pour être vraiment sûr, il faut une preuve mathématique que le pont supportera n'importe quelle voiture, à n'importe quel moment, sous n'importe quelle condition. C'est ce que l'article appelle la « vérification déductive ».
Le problème ? Obtenir de l'IA un code qui soit non seulement correct mais aussi facile à prouver est incroyablement difficile. Parfois, l'IA écrit une solution qui fonctionne parfaitement mais qui est si désordonnée ou étrangement structurée que le « vérificateur de preuve » (un outil appelé Why3) s'embrouille et ne parvient pas à la vérifier.
L'idée majeure : Ne cherchez pas seulement une seule voie
Les auteurs, Shirley Yu et Ruben Martins, ont posé une question simple : Et si nous ne demandions pas seulement une solution, mais plusieurs versions différentes de la même solution ?
Pensez-y comme si vous essayiez d'ouvrir un bocal récalcitrant.
- Version A : Vous essayez de tourner le couvercle avec la main droite.
- Version B : Vous essayez de tourner le couvercle avec la main gauche.
- Version C : Vous essayez de tapoter le couvercle avec une cuillère.
- Version D : Vous essayez de le passer sous l'eau chaude.
Peut-être que le « mouvement de torsion de la main droite » (le premier code écrit par l'IA) est trop glissant pour que le vérificateur de preuve puisse l'agripper. Mais le « mouvement de la main gauche » pourrait avoir une forme qui s'adapte parfaitement à la logique du vérificateur. L'article appelle cela Diversify2Verify. Au lieu d'espérer obtenir un code parfait, ils génèrent quatre « saveurs » différentes de la même tâche :
- Tableau + Impératif : Comme parcourir une file de personnes une par une, en vérifiant leurs noms.
- Tableau + Récursif : Comme un jeu du « téléphone arabe » où l'on transmet la tâche à une ligne d'assistants.
- Liste + Impératif : Comme feuilleter une pile de fiches cartonnées.
- Liste + Récursif : Comme une poupée russe où chaque poupée contient l'étape suivante.
L'expérience : 73 énigmes, 292 tentatives
L'équipe a construit un terrain de jeu spécial comprenant 73 énigmes de programmation différentes (impliquant principalement des nombres, des listes et des tableaux). Pour chaque énigme, ils ont demandé à l'IA de générer les quatre « saveurs » mentionnées. Cela leur a donné 292 tentatives de code différentes à tester.
Ils ne se sont pas contentés de laisser l'IA écrire du code ; ils ont mis en place un processus strict en trois étapes :
- Étape 1 (Le contrat) : D'abord, ils ont fait écrire à l'IA un « contrat » (un carnet de règles formelles) décrivant ce que le code doit faire, sans se soucier de comment il le fait. Ils ont vérifié ce carnet de règles à l'aide d'exemples pour s'assurer qu'il était cohérent. Une fois le carnet de règles accepté, il était gelé. Plus aucun changement possible dans les règles !
- Étape 2 (Le code) : Ensuite, ils ont demandé à l'IA d'écrire le code réel pour chacune des quatre saveurs, en veillant à ce qu'il passe quelques tests de base.
- Étape 3 (La preuve) : Enfin, ils ont tenté de prouver que chaque version du code respectait le carnet de règles gelé. Si la preuve échouait, ils donnaা un indice (une « réparation ») à l'IA pour corriger la preuve, mais uniquement la preuve, et non le code ou les règles.
Les résultats : La diversité l'emporte
Voici ce qui s'est passé lorsqu'ils ont analysé les chiffres :
- L'échec du « coup de fusil » (One-Shot) : Si l'on prenait simplement le premier code écrit par l'IA et que l'on tentait de le prouver, seuls 96 sur 292 (environ 32,9 %) fonctionnaient. C'est moins d'un tiers !
- Le pouvoir de la réparation : Lorsqu'ils ont laissé l'IA tenter de réparer les preuves deux fois, le nombre est passé à 154 sur 292 (environ 52,7 %).
- Le pouvoir de la diversité (Le véritable gagnant) : En examinant l'ensemble des 73 énigmes, ils ont constaté que pour 49 d'entre elles (un taux de réussite de 67,1 %), au moins une des quatre versions pouvait être prouvée correcte.
C'est la conclusion principale : Des implémentations équivalentes en termes de tâche peuvent différer substantiellement en termes de vérifiabilité. En d'autres termes, deux morceaux de code qui font exactement la même chose peuvent être aux antipodes en ce qui concerne la facilité de leur preuve.
Ce qu'ils ont écarté (Ce que ce n'est PAS)
L'article est très prudent sur ce qu'il ne prétend pas :
- Ce n'est pas une question de meilleur code : Ils n'ont pas trouvé que « les Tableaux sont meilleurs que les Listes » ou que « la Récursion est meilleure que les Boucles ». En fait, les résultats étaient mitigés. Le code récursif était généralement plus facile à prouver que le code impératif (basé sur des boucles), mais les tableaux et les listes ont eu des performances similaires globalement. La clé n'était pas de choisir le « meilleur » style, mais d'avoir des options.
- Ce n'est pas une question de changer les règles : Ils ont strictement interdit à l'IA de modifier le « contrat » (l'objectif) durant la phase de réparation. Si l'IA tentait de modifier l'objectif pour faciliter la preuve, cela était considéré comme un échec. Ils voulaient prouver l'objectif original, pas un objectif plus faible.
- Ce n'est pas un remède miracle pour tout : L'étude s'est concentrée uniquement sur des énigmes impliquant des entiers, des tableaux et des listes. Ils ne prétendent pas que cela fonctionne pour les nombres à virgule flottante, les graphismes 3D complexes ou les programmes communiquant sur Internet.
À quel point sont-ils sûrs ?
Les auteurs sont confiants dans leurs mesures, mais prudents quant à la vue d'ensemble.
- Mesuré : Ils ont des chiffres concrets. Ils ont utilisé les outils, compté les succès et constaté que la diversité augmentait le taux de réussite de 32,9 % à 52,7 % pour les artefacts individuels, et de 67,1 % pour les tâches.
- Suggéré : Ils suggèrent que la raison pour laquelle le code impératif (les boucles) est plus difficile à prouver est qu'il nécessite des « invariants de boucle » (des règles sur ce qui se passe à l'intérieur d'une boucle) qu'il est difficile pour une IA d'inventer automatiquement. Ils supposent que si l'on donne à l'IA de meilleurs outils pour deviner ces règles, l'écart pourrait se réduire.
- Non prouvé (encore) : Ils admettent qu'ils n'ont pas prouvé que le « Contrat de Tableau » et le « Contrat de Liste » sont mathématiquement identiques. Ils ont simplement supposé qu'ils signifiaient la même chose sur la base de la description de la tâche. Ils notent également que leur « juge » (une IA vérifiant si les règles correspondaient à l'énigme) n'est pas un expert humain parfait, donc quelques erreurs subtiles pourraient s'être glissées.
La conclusion à retenir
L'article suggère que lorsque nous demandons à une IA d'écrire des logiciels « vérifiés », nous ne devrions pas simplement demander une seule réponse et espérer que tout se passe bien. Au lieu de cela, nous devrions demander un menu d'options. En générant différentes manières de résoudre le même problème, nous augmentons nos chances de trouver la version que le vérificateur de preuve pourra réellement comprendre.
C'est comme essayer de trouver une clé qui s'adapte à une serrure. Si vous n'avez qu'une seule clé, vous pourriez être bloqué. Mais si vous avez tout un trousseau de clés, même si elles ouvrent toutes la même porte, l'une d'entre elles est presque garantie de s'adapter parfaitement à la serrure.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.