🤖 machine learning

Towards Functional Correctness of Large Code Models with Selective Generation

Cet article propose « FuzzEval », un paradigme qui exploite des tests unitaires générés dynamiquement pour permettre à un générateur de code sélectif de s'abstenir de produire des sorties incertaines, contrôlant ainsi théoriquement le taux de fausses découvertes et améliorant la correction fonctionnelle des grands modèles de code.

Auteurs originaux : Jaewoo Jeong, Taesoo Kim, Sangdon Park

Publié 2026-06-16

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jaewoo Jeong, Taesoo Kim, Sangdon Park

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 ayez un assistant robotique très talentueux mais légèrement trop sûr de lui, dont le travail est d'écrire du code informatique pour vous. Vous lui demandez : « Écris un programme qui trie une liste de noms », et il recrache joyeusement une solution. Mais voici le hic : parfois, ce robot hallucine. Il écrit du code qui semble fonctionner, mais quand vous l'exécutez réellement, il plante, donne une mauvaise réponse ou fait quelque chose de complètement inattendu.

Dans le monde du logiciel, c'est dangereux. Vous ne pouvez pas simplement faire confiance aveuglément au robot.

Ce document présente un nouveau système d'« inspecteur de sécurité » pour ces robots générateurs de code. Au lieu d'accepter simplement le code que le robot génère, ce système agit comme un gestionnaire de contrôle qualité strict qui dit : « Je ne laisserai passer que le bon code ; si je n'en suis pas sûr, j'admettrai que je ne sais pas. »

Voici comment fonctionne le système, décomposé en concepts simples :

1. Le Problème : La « Boîte Noire » du Code

Habituellement, pour vérifier si un morceau de code est bon, nous nous appuyons sur quelques tests pré-écrits (comme une liste de contrôle). Mais pour des problèmes complexes, une liste de contrôle peut manquer des bugs cachés. C'est comme vérifier si une voiture est sûre en ne regardant que les pneus et en ignorant le moteur. Le document soutient que parce que le code est si complexe et « non naturel » à lire pour les humains, il est difficile de dire si deux morceaux de code font exactement la même chose simplement en les regardant.

2. La Solution : La Machine de « Fuzzing »

Pour résoudre cela, les auteurs utilisent un outil appelé Fuzzing. Imaginez que vous avez une machine qui prend un morceau de code et lui lance des millions d'entrées aléatoires, bizarres et extrêmes, juste pour voir s'il casse.

L'Analogie : Pensez à un testeur de résistance pour un pont. Au lieu de faire traverser une seule voiture, la machine lance des sacs de sable, des camions lourds et même des éléphants sur le pont dans des motifs aléatoires pour voir s'il tient bon.
Le Résultat : Cette machine génère automatiquement des milliers de « tests unitaires » (petits scénarios pour vérifier le code) que le robot n'a jamais vus auparavant.

3. Le « Générateur Sélectif » : Le Robot Honnête

Le document propose une nouvelle façon d'utiliser le robot générateur de code. Ils ajoutent une étape de « garde-fou ».

Le Processus : Le robot essaie d'écrire le code. Ensuite, la « Machine de Fuzzing » teste immédiatement ce code contre des milliers de scénarios aléatoires.
La Décision :
- Si le code réussit les tests avec un haut niveau de confiance, le garde-fou dit : « Allez-y, c'est bon ! » et vous donne le code.
- Si le code échoue ou si les tests sont trop ambigus, le garde-fou dit : « Je ne sais pas », et refuse de vous donner le code.

C'est ce qu'on appelle la Génération Sélective. Le robot est autorisé à dire « Je ne sais pas » au lieu de deviner et de vous donner un mauvais code.

4. La Garantie : Le « Taux de Fausse Découverte »

La partie la plus excitante du document est la mathématique derrière le garde-fou. Les auteurs ne se contentent pas d'espérer que le système fonctionne ; ils le prouvent mathématiquement.

Ils fixent une règle : « Nous voulons nous assurer que moins de 30 % (ou quel que soit le nombre que vous choisissez) du code que nous vous donnons est réellement mauvais. »
Ils appellent cela le Taux de Fausse Découverte (FDR).
Le système est conçu de sorte que, même si le robot est médiocre, le garde-fou filtrera le mauvais contenu de manière si stricte que le lot final de code que vous recevez est garanti d'être majoritairement correct.

5. FuzzEval : Un Meilleur Bulletin de Notes

Enfin, les auteurs suggèrent d'utiliser cette même « Machine de Fuzzing » pour noter les modèles de code à l'avenir. Au lieu de simplement vérifier si un code passe quelques tests standards (comme un examen scolaire avec 5 questions), ils proposent d'utiliser la Machine de Fuzzing pour générer des centaines de tests aléatoires. Cela offre un bulletin de notes beaucoup plus précis et rigoureux sur la réelle capacité d'une IA à écrire du code. Ils appellent cette nouvelle méthode de notation FuzzEval.

Résumé

En résumé, ce document nous enseigne comment construire un filet de sécurité pour les générateurs de code par IA. En utilisant une machine de « test de résistance » (Fuzzing) pour créer automatiquement des millions de tests, nous pouvons créer un système qui :

Filtre le mauvais code avant qu'il ne vous parvienne.
Avoue son ignorance (« Je ne sais pas ») lorsqu'il est incertain, plutôt que d'halluciner une mauvaise réponse.
Garantit mathématiquement que le code que vous recevez est sûr à utiliser.

Cela transforme une approche de « deviner et espérer » en une approche de « tester et vérifier », rendant le code généré par l'IA beaucoup plus fiable pour une utilisation dans le monde réel.

Résumé Technique : Vers la correction fonctionnelle des modèles de code par génération sélective

Énoncé du problème

Les grands modèles de langage (LLM) ont démontré des performances significatives dans les tâches de génération de code ; cependant, leur applicabilité dans les systèmes critiques pour la sécurité est entravée par l'« hallucination de code », où le code généré ne parvient pas à satisfaire les spécifications fonctionnelles souhaitées. Un goulot d'étranglement critique pour atténuer ce problème est la difficulté d'identifier la correction fonctionnelle du code généré. Contrairement au langage naturel, où l'implication sémantique peut être annotée par des humains, le code possède une structure complexe et non naturelle qui rend la vérification manuelle de l'équivalence fonctionnelle difficile. Les benchmarks existants reposent souvent sur des tests unitaires limités, curatés manuellement, qui peuvent ne pas couvrir suffisamment de chemins d'exécution pour garantir la correction. De plus, les méthodes actuelles de contrôle de l'hallucination se concentrent souvent sur l'amélioration des performances du modèle via le fine-tuning ou le classement, manquant de mécanismes directs et théoriquement fondés pour contrôler le taux de sorties erronées lors de l'inférence.

Méthodologie

Les auteurs proposent un cadre de Génération de Code Sélective qui contrôle théoriquement le taux d'hallucination en utilisant une métrique de Taux de Faux Découvertes avec Implication de Code (FDR-CE). La méthodologie se compose de trois composantes clés :

1. $\alpha$ -Implication de Code et Fuzzing

Pour répondre à la difficulté de définir la correction fonctionnelle, l'article redéfinit l'implication pour le code en utilisant la nature exécutable des programmes.

$\alpha$ -Implication de Code : Au lieu d'exiger une équivalence exacte, les auteurs définissent un extrait de code $\hat{y}$ comme étant $\alpha$ -impliqué par un générateur de tests unitaires $F(x)$ si la probabilité que $\hat{y}$ réussisse les tests est d'au moins $1-\alpha$ . Cela permet une mesure probabiliste de la correction fonctionnelle.
FuzzEval : Pour générer automatiquement et rigoureusement les tests unitaires nécessaires, les auteurs emploient le fuzzing, une technique d'analyse de code dynamique. En échantillonnant et en mutant aléatoirement des graines d'entrée (seeds), le fuzzing explore une large gamme de chemins d'exécution pour générer des paires entrée-sortie. Ce processus, nommé FuzzEval, sert deux objectifs :
- Apprentissage : Générer un grand ensemble de tests unitaires pour estimer l'ensemble d'implication pour le générateur sélectif.
- Évaluation : Fournir un benchmark d'évaluation plus rigoureux que les tests statiques curatés manuellement.

2. Cadre de Génération Sélective

Le système introduit un générateur sélectif $\hat{S}(x)$ qui agit comme un post-processeur pour un générateur de code de base $G(x)$ .

Mécanisme d'Abstention : Pour un prompt $x$ donné, le système calcule un score $f(x, G(x))$ (par exemple, la log-probabilité normalisée par la longueur). Si le score dépasse un seuil calibré $\tau$ , le code est renvoyé ; sinon, le système s'abstient (renvoie « Je ne sais pas »).
Contrôle du Risque : L'objectif est de s'assurer que la probabilité que le code sélectionné soit fonctionnellement incorrect (c'est-à-dire non $\alpha$ -impliqué) reste inférieure à un niveau souhaité $\epsilon_S$ . Cela est formalisé par le contrôle du FDR-CE :
$R_\alpha(\hat{S}) := P\{ \hat{S}(x) \notin E_\alpha(x) \mid \hat{S}(x) \neq \text{IDK} \}$
où $E_\alpha(x)$ est l'ensemble des extraits de code qui satisfont la condition d' $\alpha$ -implication.

3. Garanties Théoriques et Algorithme (ASCG)

Les auteurs proposent l'algorithme d'apprentissage ASCG (Algorithme pour la Génération de Code Sélective).

Estimation : Puisque le véritable ensemble d'implication $E_\alpha$ est inconnu, l'algorithme utilise une borne de queue binomiale inférieure $\hat{L}$ dérivée des tests unitaires générés pour estimer l'ensemble d'implication $\hat{E}_{\alpha, \epsilon_E}$ .
Calibration : En utilisant un ensemble de calibration, l'algorithme recherche le seuil $\tau$ optimal qui minimise le seuil (maximisant l'efficacité de la sélection) tout en garantissant que la borne supérieure du FDR-CE ne dépasse pas la cible $\epsilon_S$ .
Garantie : Le Théorème 4.3 fournit une garantie théorique que le générateur sélectif appris satisfait la contrainte de FDR-CE souhaitée avec une probabilité élevée ( $1-\delta_S$ ), même sans étiquettes d'implication annotées par l'humain.

Contributions Clés

Génération Sélective pour le Code : Le papier étend le concept de prédiction sélective (précédemment appliqué au langage naturel) à la génération de code, introduisant un mécanisme pour contrôler le taux d'hallucination via l'abstention.
Paradigme FuzzEval : Il propose d'utiliser des outils de fuzzing pour générer automatiquement des tests unitaires pour l'apprentissage de la fonction de sélection et l'évaluation de la correction du code, surmontant les limites des petits ensembles de tests manuels.
Contrôle Théorique du FDR-CE : Le travail fournit un algorithme d'apprentissage avec une garantie de type PAC, assurant que le taux de code généré de manière erronée (parmi les réponses non faisant l'objet d'une abstention) est borné par un paramètre défini par l'utilisateur.
Définition de l' $\alpha$ -Implication de Code : Il formalise une définition probabiliste de la correction du code adaptée à l'analyse automatisée, comblant le fossé entre l'implication sémantique en NLP et l'équivalence fonctionnelle en code.

Résultats Expérimentaux

Les auteurs ont évalué leur méthode sur diverses configurations, incluant :

Modèles : Quatre générateurs de code (GPT-4o, Gemini 1.5 Pro, GPT-4.1, CodeLlama 13B, DeepSeek-R1).
Jeux de données : Quatre benchmarks (APPS, Mercury, HumanEval, MBPP) convertis en versions « Fuzz » (APPS-f, etc.) à l'aide de tests unitaires générés automatiquement.
Langages : Python, C++, Java, JavaScript et Perl.

Principales conclusions :

Contrôlabilité : La méthode proposée (SCG) parvient à borner le FDR-CE au niveau souhaité ( $\epsilon_S$ ) à travers divers modèles et jeux de données, alors que les méthodes de référence (par exemple, SCG-EM, SCG-manual) échouent soit à borner le risque, soit présentent une efficacité triviale (abstention trop fréquente).
Efficacité : SCG atteint une efficacité de sélection raisonnable (le ratio de réponses non faisant l'objet d'une abstention) tout en maintenant la garantie de sécurité. Par exemple, sur GPT-4o avec $\epsilon_S=0.3$ , SCG a maintenu un FDR-CE sous la cible tout en conservant environ 33-50 % des réponses générées, selon le jeu de données.
Bénéfice du Fuzzing : Les expériences ont démontré que l'utilisation de tests unitaires générés par fuzzing (SCG) surpasse significativement les méthodes utilisant des tests manuels limités (SCG-small) ou aucun test (SCG-EM) en termes de contrôle du risque et d'efficacité.
Extension aux travaux antérieurs : La méthode agit comme un post-processeur qui peut être appliqué sur des modèles avancés existants (par exemple, DeepSeek-R1 avec fine-tuning GRPO), fournissant une couche supplémentaire de garanties de sécurité statistique.

Signification et Revendications

L'article affirme que sa contribution principale réside dans l'algorithme d'apprentissage de génération sélective qui contrôle directement le taux d'hallucination des modèles de code. En exploitant la nature exécutable du code via le fuzzing, les auteurs soutiennent qu'il est possible de dépasser les améliorations de performance heuristiques pour atteindre une sécurité théoriquement contrôlée.

La signification du travail est présentée comme fournissant une « garantie de contrôlabilité » sur le taux de faux découvertes, rendant les générateurs de code plus dignes de confiance pour les systèmes exigeant des normes de sécurité plus élevées. Les auteurs notent modestement que, bien que la méthode contrôle le taux d'hallucination, l'efficacité globale de la sélection dépend toujours de la qualité sous-jacente du générateur de code, et que l'hypothèse i.i.d. pour la garantie théorique peut limiter l'applicabilité dans des environnements de changement de distribution. Le travail ne prétend pas éliminer entièrement l'hallucination, mais propose plutôt un mécanisme pour la gérer et la borner avec une rigueur statistique.