Résumé technique : Converti, non équivalent : Évaluation de la conversion de bases de code par équivalence observationnelle

Énoncé du problème

Les récents progrès des agents de codage leur ont permis d'agir comme des collaborateurs à l'échelle de la base de code, capables de naviguer dans des projets, d'éditer des fichiers et d'effectuer une maintenance logicielle à grande échelle. Cependant, une faiblesse critique est apparue : les agents font souvent trop confiance à leurs propres routines de validation locale. Dans le contexte de la conversion de bases de code (par exemple, la migration de PyTorch vers JAX), les agents déclarent souvent le succès sur la base de vérifications superficielles — telles qu'un point d'entrée callable, une perte finie ou une validité syntaxique — tout en violant les contrats sémantiques dont dépendent réellement les utilisateurs.

Les méthodes d'évaluation précédentes pour la conversion de bases de code sont largement axées sur les résultats, comparant la réussite finale des tâches ou les artefacts d'état final sous des évaluateurs cachés. Cette approche est instable pour la conversion préservant la sémantique, car les résultats observables peuvent être rares par rapport à l'espace d'implémentation. Deux bases de code avec des contrats internes radicalement différents peuvent produire des pertes directes presque identiques sur un seul lot tout en divergeant fortement dans les gradients, les états de l'optimiseur ou les dynamiques d'entraînement à court horizon. Par conséquent, les comparaisons basées uniquement sur les résultats risquent de récompenser un accord accidentel sur des sondages superficiels tout en échouant à détecter les échecs sémantiques.

Méthodologie : T2J-Bench

Pour combler cette lacune d'évaluation, les auteurs introduisent T2J-Bench, un benchmark qui reformule la conversion de bases de code comme un transfert sous un contrat d'équivalence fixe. Plutôt que de demander si une base de code convertie s'exécute simplement, T2J-Bench vérifie si la base de code convertie se comporte comme l'original sous un ensemble fixe de tests bornés dérivés de la source.

Cadre principal

Le benchmark fonctionne selon un processus de vérification ordonné en trois étapes. Une base de code candidate doit réussir chaque étape séquentiellement pour être considérée comme réussie :

1. Spécification (Admissibilité de l'interface) : Vérifie que la base de code convertie expose la même interface d'entraînement que la source. Cela inclut la vérification des arbres de paramètres, des schémas de lots, des points d'entrée publics et de la capacité à construire un runtime sans erreurs.
2. Numérique (Sorties directes et tenseurs) : Compare des artefacts spécifiques calculés lors de tests bornés. Cela inclut les sorties directes, les pertes, les gradients et les tenseurs spécifiques à l'objectif (par exemple, les log-probabilités de politique pour DPO, les sorties de valeur pour PPO). Les comparaisons utilisent des tolérances strictes pour l'erreur absolue/relative, la similarité cosinus et la divergence KL.
3. Comportemental (Dynamiques à court horizon) : Sonde si l'accord numérique local suffit à préserver les dynamiques d'entraînement à court terme sous des graines fixes. Cela implique de rejouer quelques étapes d'entraînement pour s'assurer que les mises à jour de l'optimiseur, les calculs de récompense et les interactions avec le modèle de référence produisent des trajectoires cohérentes avec la source.

Configuration expérimentale

• Tâche : Conversion de bases de code d'entraînement PyTorch complètes pour SFT (Supervised Fine-Tuning), DPO (Direct Preference Optimization) et PPO (Proximal Policy Optimization) vers JAX.
• Jeu de données : 45 points de données couvrant 15 familles de modèles (par exemple, variantes LLaMA, Mistral, Qwen) avec des contraintes de taille (<7 milliards de paramètres) et des configurations bornées.
• Protocole d'évaluation :
  • Lignes de base contrôlées : Modèles de pointe (par exemple, Claude Opus 4.7, Gemini 3.1 Pro, Qwen3 Coder) évalués à l'aide d'un squelette multi-agents implémenté en interne et agnostique du noyau.
  • Agents natifs : Systèmes complets d'agents de codage (par exemple, Claude Code, Codex) évalués dans leurs interfaces natives.
  • Contraintes : Un « prompt de contrainte minimale » ($p^\star$) est utilisé pour fixer l'interface d'entraînement sans divulguer les détails internes de l'évaluateur. Le vérificateur reste externe et fixe.

Résultats clés

L'évaluation de 355 tentatives de conversion aveugles produit quatre constatations centrales :

1. La conversion de bases de code est loin d'être résolue : Malgré des taux de réussite élevés à l'étape initiale de spécification (jusqu'à 91,1 %), le taux de réussite global de bout en bout pour les systèmes les plus performants n'est que de 26,7 à 28,9 % à @1. Le principal goulot d'étranglement est la préservation de l'équivalence numérique et des dynamiques d'entraînement, et non simplement la production de code exécutable.
2. Le budget de calcul est un remède faible : L'augmentation du budget d'inférence (nombre de jetons) produit des rendements décroissants. Une dispersion de 4,7 fois du coût en jetons par tentative se traduit par une dispersion de seulement 2,2 fois du taux de réussite global. Les systèmes qui dépensent plus de jetons s'engagent souvent dans des enquêtes répétées ou une auto-vérification verbeuse sans améliorer la qualité finale de la conversion.
3. Surconfiance systématique : Chaque système évalué surestime considérablement son propre succès. L'écart entre les taux de réussite auto-déclarés (souvent >90 %) et les taux de réussite mesurés par l'évaluateur (0–29 %) varie de 66,6 à 97,8 points de pourcentage. Les agents tendent à vérifier que les artefacts existent et sont bien formés (par exemple, « la perte est un scalaire fini ») mais échouent à vérifier que ces artefacts correspondent aux sémantiques de la source.
4. Les modes d'échec sont désalignés par rapport au contrat : Les échecs les plus difficiles proviennent d'une auto-validation désalignée par rapport au contrat plutôt que d'une force de noyau limitée. Les motifs d'échec courants incluent :
   • Erreurs de couture : Confusion de types à la frontière JAX/PyTorch (par exemple, passer un numpy.ndarray à une couche d'embedding PyTorch).
   • Substitution sémantique : Retourner la perte de la méthode DPO dans l'emplacement forward_loss, satisfaisant les tests de fumée locaux mais violant le contrat spécifique requis par l'évaluateur.
   • Divergence des gradients/états : Correspondance des passages directs mais échec à préserver les normes de gradient ou les mises à jour d'état de l'optimiseur.

Importance et revendications

L'article affirme que T2J-Bench opère un changement nécessaire d'une évaluation axée sur les résultats vers une évaluation axée sur le contrat. En décomposant la vérification en étapes de spécification, numérique et comportementale, le benchmark contourne l'indécidabilité de l'équivalence absolue de la base de code tout en restant discriminatif entre différents modèles et systèmes d'agents.

Les auteurs soutiennent que dans le régime actuel de conversion de bases de code :

• Le simple passage à l'échelle du noyau est insuffisant : L'écart entre les meilleurs et les pires modèles est faible par rapport à l'écart entre l'auto-validation et la vérification externe.
• L'auto-validation est le principal goulot d'étranglement : Les agents échouent non pas parce qu'ils ne peuvent pas calculer les bonnes valeurs, mais parce que leurs boucles de validation internes traitent les « artefacts bien formés » comme équivalents aux « artefacts sémantiquement corrects ».
• Les améliorations futures nécessitent un alignement externe : Réduire l'écart nécessite que les agents internalisent une boucle de comparaison avec la source plutôt que de compter sur des tests de fumée auto-cohérents. Le benchmark sert de squelette diagnostique pour identifier ces désalignements.

L'article conclut que, bien que T2J-Bench soit instancié sur la conversion de PyTorch vers JAX, son cadre de contrats d'équivalence fixes et de vérification par étapes offre une approche généralisable pour évaluer les transformations de bases de code préservant la sémantique.