🤖 AI

Function-Level Execution Feedback for Code Preference Optimization

L'article présente STEP-KTODER, un cadre d'optimisation des préférences de code qui définit les étapes comme des fonctions au niveau du module avec des étiquettes de correction binaires issues de tests unitaires, démontrant que ce processus de supervision basé sur l'exécution surpasse de manière significative les méthodes basées uniquement sur le résultat tout en évitant la corruption des étiquettes causée par les annotations de type LLM-as-a-judge.

Auteurs originaux : Idris Nechnech, Sehwan Kim, Jimin Seo, Yeongoon Kim, Minhae Oh, Sangwoo Hong, Jungwoo Lee

Publié 2026-08-26

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Idris Nechnech, Sehwan Kim, Jimin Seo, Yeongoon Kim, Minhae Oh, Sangwoo Hong, Jungwoo Lee

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

Dans le monde de l'intelligence artificielle, il existe un fossé grandissant entre les modèles qui peuvent simplement produire une réponse et ceux qui comprennent le cheminement pour y parvenir. Pendant des années, des chercheurs ont entraîné des programmes informatiques à résoudre des problèmes mathématiques en les récompensant non seulement pour le résultat final, mais aussi pour chaque étape logique qu'ils franchissent en cours de route. Cette approche, connue sous le nom de supervision de processus, a aidé les machines à devenir bien meilleures en raisonnement. Cependant, lorsqu'il s'agit d'écrire du code informatique, cette méthode est restée insaisissable. Contra irement à un problème mathématique, qui se décompose naturellement en une séquence de calculs, un logiciel est souvent un réseau complexe d'instructions où il est difficile de dire exactement quelle ligne est juste et laquelle est fausse. Si un programme ne parvient pas à s'exécuter, les méthodes d'entraînement traditionnelles considèrent souvent l'ensemble de la production comme un échec, même si quatre-vingt-dix pour cent du code est parfait. Ce retour d'information grossier laisse la machine deviner quelle partie spécifique de son travail doit être corrigée.

Une équipe de chercheurs de l'Université Nationale de Séoul et de l'Université de Konkuk a développé une nouvelle façon d'enseigner à ces modèles comment écrire un meilleur code en décomposant le problème en morceaux gérables et testables. Ils appellent leur méthode STEP-KTODER. Au lieu de juger un programme entier comme une unité unique, ils apprennent au modèle à considérer un programme comme une collection de fonctions indépendantes, ou de petits outils autonomes qui accomplissent une tâche spécifique. Les chercheurs prennent une solution correcte et la décomposent en ces fonctions distinctes. Ensuite, ils génèrent automatiquement un ensemble de vérifications simples, semblables à un inspecteur du contrôle qualité testant une seule pièce d'une machine, pour voir si chaque fonction fonctionne correctement par elle-même. Cela leur permet de donner au modèle un retour précis : « Cette fonction spécifique est correcte, mais celle-là est défectueuse », plutôt que de simplement dire « Tout a échoué ».

Les chercheurs ont testé cette approche sur plusieurs défis standards utilisés pour mesurer la capacité d'une intelligence artificielle à écrire du code. Ils ont constaté qu'en utilisant ces vérifications fines basées sur l'exécution, leurs modèles s'étaient nettement améliorés par rapport aux modèles entraînés avec les anciennes méthodes qui ne regardaient que le résultat final. En fait, sur les défis de codage les plus difficiles, leur nouvelle méthode a boosté la performance de près de vingt-sept pour cent par rapport aux meilleures techniques précédentes. L'étude a également révélé une intuition critique sur la façon dont nous évaluons le code : demander simplement à un modèle de langage puissant de deviner si un morceau de code est correct ne suffit pas. Lorsque les chercheurs ont essayé de remplacer leurs vérifications automatiques basées sur l'exécution par les jugements d'une autre IA, les résultats se sont dégradés. L'IA jugeante avait tendance à être trop critique, signalant incorrectement du code correct comme étant défectueux, ce qui a perturbé le processus d'entraînement. Cela a prouvé que la seule façon fiable d'enseigner à un modèle la valeur d'une étape correcte est de réellement exécuter le code et de voir s'il fonctionne.

Le cœur de cette découverte réside dans la manière dont les chercheurs ont géré la réalité désordonnée du codage, où un programme peut réussir tous ses tests finaux même si l'une de ses parties internes est défectueuse. Par le passé, de telles contradictions étaient souvent ignorées ou lissées. Cependant, l'équipe a découvert que ces conflits sont en fait précieux. En préservant les cas où le programme complet fonctionne mais où une fonction spécifique échoue, ils ont fourni au modèle une leçon nuancée : un programme peut être globalement réussi tout en contenant des erreurs qui doivent être corrigées. Cette approche permet au modèle d'apprendre à renforcer les parties de son code qui fonctionnent bien tout en ciblant spéciflement les parties qui ne fonctionnent pas, un peu comme un mécanicien qui sait exactement quel boulon serrer plutôt que de remplacer l'intégralité du moteur.

Ce travail suggère une voie pratique pour rendre l'intelligence artificielle plus fiable dans des tâches complexes. En s'éloignant du jugement du produit fini de manière isolée pour se concentrer sur la correction des composants individuels qui le constituent, les chercheurs peuvent guider ces systèmes pour qu'ils apprennent plus efficacement. L'étude démontre que pour la génération de code, la supervision la plus efficace provient de l'exécution et du test du code lui-même, plutôt que d'un deuxième avis. Ce passage d'un retour d'information basé sur le résultat à un retour d'information basé sur le processus, ancré dans l'exécution réelle, offre une manière plus claire et plus directe pour les machines d'apprendre l'art de la programmation.

Résumé Technique : STEP-KTODER

Énoncé du Problème

Bien que la supervision de processus — fournissant un retour sur les étapes intermédiaires de raisonnement — ait considérablement amélioré le raisonnement mathématique des grands modèles de langage (LLM), son application à la génération de code reste peu explorée. Dans les domaines mathématiques, les étapes sont naturellement définies comme des chaînes de pensée. En revanche, dans la génération de code, il n'existe pas de notion standard d'une « étape ». Les cibles de supervision varient largement (lignes de code, traces de raisonnement ou états de programme), créant une ambiguïté sur ce qu'il faut étiqueter et optimiser.

Les méthodes actuelles d'optimisation de préférences, telles que la Direct Preference Optimization (DPO) et la Kahneman–Tversky Optimization (KTO), opèrent généralement au niveau du résultat, traitant l'ensemble d'un programme comme une unité unique de feedback. Ce signal grossier ne parvient pas à distinguer les composants corrects des incorrects au sein d'un programme partiellement réussi. Par exemple, un programme qui est majoritairement correct mais qui échoue sur un cas limite étroit sera entièrement étiqueté comme « indésirable », occultant ainsi quelles fonctions spécifiques ont contribué au succès ou à l'échec. Ce manque de granularité limite la capacité à renforcer le code localement correct tout en pénalisant des composants défaillants spécifiques.

Méthodologie : STEP-KTODER

Les auteurs proposent STEP-KTODER, un cadre d'optimisation des préférences de code qui définit les « étapes » comme des fonctions de niveau module dans des programmes multi-fonctions décomposés. La méthode combine la supervision de processus au niveau de la fonction avec le feedback au niveau du résultat via un pipeline d'étiquetage basé sur l'exécution.

1. Pipeline de Construction de Données

Le cadre repose sur un processus de construction automatique de données composé de quatre étapes :

Décomposition de Référence : Un modèle de code performant, ajusté par instruction, réécrit les solutions de référence en programmes décomposés et multi-fonctions tout en préservant l'interface et le comportement originaux. Seules les réécritures passant la suite de tests originale sont conservées.
Génération de Tests Unitaires par Fonction : Pour chaque fonction décomposée, le modèle génère des tests unitaires ciblés couvrant l'interface de la fonction et ses cas limites. Ces tests sont validés par exécution contre l'implémentation de référence ; seuls les tests qui réussissent et contiennent des assertions non triviales sont conservés.
Génération de Candidats On-Policy : Le modèle cible génère des complétions candidates en remplissant des squelettes de fonctions (où les corps de fonctions sont remplacés par pass) dérivés des références décomposées.
Étiquetage :
- Étiquette de Résultat ( $o$ ) : Déterminée par la réussite ou l'échec du programme candidat complet face à la suite de tests fournie pour le jeu de données.
- Étiquettes d'Étape ( $z$ ) : Déterminées par l'exécution de chaque fonction candidate contre ses tests unitaires générés. Une étiquette de $1$ indique une correction locale, $0$ indique un échec, et $\emptyset$ indique qu'aucun test valide n'était disponible.

2. Fonction d'Objectif

STEP-KTODER étend la KTO en introduisant un objectif conjoint qui combine la supervision au niveau du résultat et au niveau de l'étape.

KTO au Niveau du Résultat : Utilise la perte KTO standard ( $L_{out}$ ) basée sur la désirabilité binaire du programme complet.
KTO au Niveau de l'Étape : Définit une perte par étape ( $L_{step}$ ) sur les tokens des fonctions individuelles. Pour chaque fonction $s_i$ , un log-ratio local est calculé, et une fonction de valeur est appliquée en fonction de l'étiquette d'étape $z_i$ .
Objectif Conjoint : La perte finale est $L_{STEP-KTODER} = L_{out} + \lambda_{step} L_{step}$ .

Crucialement, le cadre emploie des étiquettes préservant les conflits. Il conserve les exemples d'entraînement où l'étiquette de résultat ( $o$ ) et les étiquettes d'étape ( $z$ ) divergent (par exemple, un programme qui passe la suite de tests globale mais contient une fonction localement défaillante). Ces conflits fournissent des signaux d'entraînement uniques que les méthodes basées uniquement sur le résultat ne peuvent capturer, permettant au modèle d'apprendre que des composants spécifiques peuvent être corrects même si l'ensemble échoue, ou vice versa.

3. Fiabilité des Étiquettes

L'article souligne que les étiquettes basées sur l'exécution sont essentielles. Les auteurs ont testé le remplacement des étiquettes d'étape basées sur l'exécution par des annotations « LLM-as-a-judge » (utilisant GPT-5.4 mini). Bien que le LLM ait montré un accord global modéré (73,2 %), il présentait un biais systématique : il sur-prédisait les échecs, identifiant correctement 94,1 % des fonctions défaillantes mais seulement 52,2 % des fonctions réussissant. Ce biais a corrompu les étiquettes positives d'étape nécessaires à l'entraînement, entraînant une dégradation des performances, particulièrement sur les benchmarks difficiles.

Principales Contributions

Cadre STEP-KTODER : Une instanciation spécifique au code de la KTO par étapes qui définit les étapes comme des fonctions testables indépendamment, comblant le fossé entre la supervision de processus et la génération de code.
Pipeline de Données Automatique : Un pipeline qui décompose les solutions, génère des tests unitaires par fonction et dérive des étiquettes d'étape basées sur l'exécution, permettant une supervision fine sans annotation manuelle.
Validation Empirique : Des expériences démontrant que les étiquettes basées sur l'exécution sont supérieures aux jugements par LLM pour la supervision d'étapes et que la préservation des conflits locaux/globaux est critique pour la performance.

Résultats Expérimentaux

La méthode a été évaluée sur HumanEval(+), MBPP(+), BigCodeBench et LiveCodeBench en utilisant des modèles ajustés par instruction (Qwen2.5-Coder et DeepSeek-Coder).

Gains de Performance : STEP-KTODER a systématiquement surpassé la KTO et la DPO basées uniquement sur le résultat, avec les améliorations les plus significatives observées sur les benchmarks les plus difficiles.
- Sur Qwen2.5-Coder-1.5B, il a amélioré la KTO de +11,5 % sur BigCodeBench Hard et de +7,7 % sur LiveCodeBench.
- Sur Qwen2.5-Coder-3B, les gains furent de +11,3 % sur BigCodeBench Hard et +9,5 % sur LiveCodeBench.
- Sur DeepSeek-Coder-6.7B, il a obtenu un gain de +4,9 % par rapport à la KTO sur BigCodeBench Hard.
Comparaison avec Target-DPO : Bien que Target-DPO cible également les échecs localisés, STEP-KTODER a obtenu des résultats supérieurs sur les benchmarks les plus difficiles (par exemple, une amélioration de +18,5 % par rapport à Target-DPO sur BigCodeBench Hard pour le modèle 3B) en utilisant nettement moins d'échantillons d'entraînement (environ 11 400 contre 59 000 paires).
Études d'Ablation :
- Préservation des Conflits : Le masquage des conflits (suppression des exemples où $o \neq z$ ) a réduit la performance aux niveaux de la KTO, confirmant que ces décalages fournissent des signaux d'entraînement essentiels.
- Source des Étiquettes : Le remplacement des étiquettes basées sur l'exécution par des annotations de type « LLM-as-a-judge » a provoqué des chutes de performance substantielles (par exemple, -25,8 % sur BigCodeBench Hard), validant la nécessité du feedback basé sur l'exécution.

Signification et Revendications

L'article affirme que STEP-KTODER offre une voie pratique vers la supervision de processus pour la génération de code en exploitant la modularité naturelle des programmes. En définissant les étapes comme des fonctions et en les supervisant via l'exécution, la méthode fournit un feedback localisé qui renforce les composants corrects et pénalise les fautes spécifiques, une capacité absente de la supervision uniquement basée sur le résultat.

Les auteurs soulignent que l'efficacité de la méthode repose fortement sur deux facteurs :

Fiabilité basée sur l'exécution : Les tests unitaires automatisés fournissent la vérité terrain nécessaire pour les étiquettes d'étape, tandis que les juges LLM introduisent des biais systématiques qui dégradent l'apprentissage.
Préservation des conflits : La capacité d'apprendre des exemples où la correction locale et le succès global divergent est un différenciateur clé par rapport à l'optimisation de préférence standard.

Ce travail suggère que le feedback d'exécution par fonction est un mécanisme viable et efficace pour aligner les modèles de code, particulièrement pour des tâches complexes où le feedback à grain grossier est insuffisant. Les auteurs notent des limitations concernant l'exigence que les solutions soient décomposables en fonctions testables et le coût d'ingénierie de la génération de candidats on-policy pour de nouveaux modèles.