Diff-XYZ : Un Benchmark pour Évaluer la Compréhension des Diff

Informations Fondamentales

• ID de l'article : 2510.12487
• Titre : Diff-XYZ: A Benchmark for Evaluating Diff Understanding
• Auteurs : Evgeniy Glukhov, Michele Conti, Egor Bogomolov, Yaroslav Golubev, Alexander Bezzubov (JetBrains Research)
• Classification : cs.SE (Génie Logiciel), cs.LG (Apprentissage Automatique)
• Conférence de Publication : 39e Conférence sur les Systèmes de Traitement de l'Information Neuronale (NeurIPS 2025) Atelier : Apprentissage Profond pour le Code à l'Ère Agentique
• Lien de l'article : https://arxiv.org/abs/2510.12487

Résumé

Cet article propose le benchmark Diff-XYZ pour évaluer la capacité des grands modèles de langage à comprendre les différences de code (diff). Le benchmark comprend trois tâches d'apprentissage supervisé : apply (ancien code + diff → nouveau code), anti-apply (nouveau code - diff → ancien code) et génération de diff (nouveau code - ancien code → diff). Les données du benchmark proviennent de véritables commits de CommitPackFT, contenant 1000 instances de triplets ⟨ancien code, nouveau code, diff⟩. La recherche révèle que différents formats de diff doivent être choisis en fonction du cas d'usage et de la taille du modèle, fournissant une base importante pour le développement futur des modèles d'édition de code.

Contexte et Motivation de la Recherche

Problèmes Fondamentaux

Les agents modernes d'édition de code nécessitent un traitement fiable des différences de code dans les éditions et refactorisations à grande échelle, mais les méthodes d'évaluation existantes présentent les problèmes suivants :

1. Manque de recherche systématique sur le choix des formats : Bien que plusieurs formats de représentation diff existent (diff unifié, recherche-remplacement, etc.), il manque une étude comparative systématique des formats
2. Complexité d'évaluation : Les benchmarks end-to-end existants (comme SWE-bench) mélangent plusieurs facteurs (récupération, utilisation d'outils, etc.), ce qui rend difficile l'isolation de l'impact du format diff
3. Diversité des modes de défaillance : Les correctifs peuvent échouer en raison d'erreurs syntaxiques, d'incompatibilités de contexte ou d'erreurs logiques, nécessitant une analyse plus granulaire

Importance de la Recherche

• Valeur pratique : Le traitement des diff de code est une capacité fondamentale pour l'édition automatisée de code, la correction de bugs, la correction des builds CI, etc.
• Signification théorique : Comprendre comment les LLM traitent les informations d'édition structurées est crucial pour améliorer les modèles de génération de code
• Valeur d'ingénierie : Fournir des conseils basés sur les données pour choisir le format diff approprié

Contributions Principales

1. Proposition du benchmark Diff-XYZ : Un cadre d'évaluation léger et reproductible comprenant trois tâches complémentaires
2. Comparaison systématique des formats : Première comparaison contrôlée et systématique de plusieurs formats de représentation diff
3. Établissement des lignes de base de performance : Lignes de base de performance détaillées pour les modèles propriétaires et open-source sur les tâches de compréhension diff
4. Conseils sur le choix des formats : Découverte des relations entre la taille du modèle, le type de tâche et le choix optimal du format
5. Ensemble de données ouvert : Publication d'un ensemble de données d'évaluation de haute qualité sur HuggingFace Hub

Détails de la Méthodologie

Définition des Tâches

Basées sur l'équation diff = nouveau code - ancien code, trois tâches sont définies :

X. Tâche Apply (Tâche d'Application)

• Entrée : Ancien code + diff
• Sortie : Nouveau code
• Objectif : Tester la conformité au format et la fidélité au niveau des caractères

Y. Tâche Anti-Apply (Tâche d'Application Inverse)

• Entrée : Nouveau code + diff
• Sortie : Ancien code
• Objectif : Sonder la réversibilité et l'absence de perte du format

Z. Tâche de Génération de Diff (Tâche de Génération de Différence)

• Entrée : Ancien code + nouveau code
• Sortie : diff
• Objectif : Tester la capacité de synthèse fiable des diff

Construction de l'Ensemble de Données

Source des données : Véritables commits open-source du dataset CommitPackFT

Stratégie de filtrage :

• Conservation uniquement des commits modifiant un seul fichier
• Exclusion des fichiers binaires, code généré, répertoires de dépendances
• Limite du nombre de lignes du fichier : 40-1000 lignes
• Exclusion des modifications contenant uniquement des espaces blancs

Échantillonnage stratifié :

• Distribution linguistique : Python, JavaScript, Java, Kotlin, Rust avec 200 échantillons chacun
• Complexité d'édition : Stratification par nombre de blocs de modification et taille de modification
  • Éditions petites : ≤7 lignes modifiées (40%)
  • Éditions moyennes : 8-24 lignes modifiées (40%)
  • Éditions grandes : >24 lignes modifiées (20%)
• Types de modifications : 81,5% contiennent des ajouts/suppressions, 16,3% ajouts uniquement, 2,2% suppressions uniquement

Métriques d'Évaluation

Tâches Apply et Anti-Apply :

• Correspondance Exacte Épurée (EM) : Taux de correspondance exacte après suppression des lignes vides
• Intersection sur Union Épurée (IoU) : Intersection sur union au niveau des lignes

Tâche de Génération de Diff :

• Taux d'Analyse : Proportion de diff analysables
• Taux d'Application : Proportion de diff applicables avec succès
• EM/IoU après application : Taux de correspondance exacte et IoU après application du diff
• F1+ / F1- : Scores F1 pour les lignes ajoutées et supprimées

Points d'Innovation Technique

1. Complémentarité de la conception des tâches : Les trois tâches évaluent complètement la capacité de compréhension diff sous différents angles
2. Expériences à variables contrôlées : Mesure précise de l'impact du format en fixant les variations de contexte
3. Approche basée sur des données réelles : Basée sur des commits réels plutôt que des données synthétiques, assurant la validité écologique
4. Évaluation multidimensionnelle : Combinaison de la correction syntaxique, du taux de succès d'application et de la correction sémantique

Configuration Expérimentale

Formats Comparés

1. udiff : Format diff unifié standard
2. udiff-h : Diff unifié avec en-têtes de bloc assouplis
3. udiff-l : Diff unifié utilisant des étiquettes explicites (ADD/DEL/CON)
4. search-replace : Format recherche-remplacement

Modèles Testés

Modèles propriétaires :

• GPT-4o, GPT-4o-mini
• GPT-4.1, GPT-4.1-mini, GPT-4.1-nano
• Claude 4 Sonnet
• Gemini 2.5 Flash

Modèles open-source :

• Série Qwen2.5-Coder (0.5B-32B)

Stratégies d'Invite

• sans format : Invite d'assistant générique
• avec format : Invite système incluant la description du format

Résultats Expérimentaux

Résultats Principaux

Performance des modèles propriétaires :

• Claude 4 Sonnet affiche les meilleures performances sur la tâche Apply (EM : 0.95-0.96)
• GPT-4.1 montre des performances solides sur toutes les tâches, mais est sensible aux invites
• Les modèles propriétaires plus petits (comme GPT-4.1-nano) montrent une dégradation significative sur les tâches complexes

Lois d'échelle des modèles open-source :

• La performance s'améliore clairement avec la taille du modèle
• Qwen2.5-Coder-32B approche le niveau de GPT-4o sur Apply/Anti-Apply
• Mais montre un écart significatif sur la génération de Diff

Découvertes de la Comparaison des Formats

Découvertes clés :

1. Dépendance aux tâches :
   • Apply/Anti-Apply : Le format udiff affiche les meilleures performances
   • Génération de Diff : search-replace est supérieur pour les grands modèles
2. Effets de la taille du modèle :
   • Grands modèles : search-replace excelle dans les tâches de génération
   • Petits modèles : udiff-l (étiquettes explicites) fonctionne mieux
3. Analyse des caractéristiques des formats :
   • Avantages de search-replace : Évite les contraintes globales, les éditions locales sont indépendantes
   • Inconvénients d'udiff-h : La suppression des supports de numéros de ligne crée une confusion structurelle
   • Avantages d'udiff-l : Les étiquettes explicites réduisent les conflits de marquage

Résultats des Expériences d'Ablation

Impact des invites :

• La tâche de génération de Diff est hautement sensible à la description du format
• GPT-4.1 sans description de format tend à produire le format V4A
• La tâche Apply est relativement robuste aux variations d'invites

Différences linguistiques :

• Performance relativement cohérente sur les cinq langages de programmation
• Légèrement supérieure sur Python et JavaScript par rapport aux autres langages

Travaux Connexes

Benchmarks de Génération de Code

• HumanEval/MBPP : Génération de code au niveau des fonctions
• BigCodeBench : Tâches d'appels de bibliothèques complexes
• Limitations : Principalement axé sur la génération à partir de zéro, n'implique pas les représentations d'édition

Benchmarks d'Édition et de Résolution de Problèmes

• SWE-bench : Résolution de véritables problèmes GitHub
• CodeEditorBench : Édition suivant les instructions
• Limitations : Évaluation end-to-end, difficile d'isoler l'impact du format

Positionnement de cet Article

• Complémentarité : Axé sur l'étude isolée des représentations d'édition
• Légèreté : Pas besoin de configuration de dépôt ou d'environnement d'exécution
• Contrôlabilité : Contexte de tâche fixe, variation des formats de représentation

Conclusions et Discussion

Conclusions Principales

1. Le choix du format est crucial : Les différents formats montrent des variations de performance significatives selon les tâches et la taille du modèle
2. Spécificité des tâches : Les tâches de génération et d'application nécessitent des formats optimaux différents
3. Dépendance à la taille : Les stratégies optimales diffèrent entre les petits et grands modèles
4. Écart avec la réalité : Les modèles open-source ont encore une marge d'amélioration significative sur la génération de diff

Limitations

1. Simplification des tâches : Les tâches du benchmark sont des approximations simplifiées des applications en aval
2. Portée d'évaluation : Considère uniquement le décodage glouton, n'implique pas le raisonnement ou l'utilisation d'outils
3. Couverture des formats : N'inclut pas les formats de niveau AST ou les correctifs structurés
4. Connexion en aval : Manque de lien quantitatif entre la performance du benchmark et l'efficacité réelle de l'application

Directions Futures

1. Extension des formats : Explorer les représentations d'édition au niveau des arbres et AST
2. Connexion en aval : Établir le lien entre la performance du benchmark et l'efficacité réelle de l'application
3. Capacités de raisonnement : Évaluer les scénarios de raisonnement multi-étapes et d'utilisation d'outils
4. Récupération d'erreurs : Étudier la gestion des diff partiels ou endommagés

Évaluation Approfondie

Points Forts

1. Définition claire du problème : Identification précise de la compréhension diff, une capacité fondamentale mais négligée
2. Conception expérimentale rigoureuse : La méthode de comparaison des formats à variables contrôlées est scientifiquement fiable
3. Qualité élevée des données : Basée sur des commits réels, l'échantillonnage stratifié assure la représentativité
4. Découvertes précieuses : Les conseils sur le choix des formats ont une valeur pratique directe
5. Forte reproductibilité : Configuration expérimentale détaillée et ensemble de données ouvert

Insuffisances

1. Profondeur théorique limitée : L'analyse théorique des mécanismes de différence de format manque de profondeur
2. Dimensions d'évaluation uniques : Principalement axé sur la correction, manque de considérations d'efficacité et de lisibilité
3. Couverture incomplète des modèles : Les modèles open-source sont principalement concentrés sur la série Qwen
4. Limitations des scénarios d'application : N'envisage pas l'édition interactive et les scénarios de mise à jour incrémentale

Impact

1. Valeur académique : Comble un vide important dans l'évaluation de l'édition de code, susceptible de catalyser des recherches ultérieures
2. Valeur d'ingénierie : Fournit un soutien basé sur les données pour le choix du format diff par l'industrie
3. Contribution communautaire : Le benchmark ouvert et l'ensemble de données bénéficieront à toute la communauté de recherche
4. Potentiel de normalisation : Pourrait devenir un benchmark standard pour l'évaluation des capacités d'édition de code

Scénarios Applicables

1. Développement de modèles : Évaluation et amélioration des capacités des modèles d'édition de code
2. Conception de formats : Vérification de l'efficacité des nouveaux formats diff
3. Choix d'outils : Sélection de la stratégie de format pour les outils d'édition de code
4. Base de recherche : Test des capacités fondamentales pour les tâches d'édition de code complexes

Références

L'article cite 31 références connexes, incluant principalement :

• Benchmarks de génération de code : HumanEval, MBPP, BigCodeBench, etc.
• Évaluation d'édition : SWE-bench, CodeEditorBench, etc.
• Rapports techniques de modèles : GPT-4o, Claude, Qwen2.5-Coder, etc.
• Outils et formats : Aider, GNU diffutils, etc.

Évaluation Globale : Ceci est un article de recherche de haute qualité et systématique qui identifie et résout précisément un problème important dans le domaine de l'édition de code. Bien que manquant de profondeur théorique, sa valeur pratique et ses contributions méthodologiques sont significatives, jouant un rôle important dans l'avancement du développement de la technologie d'édition de code.