Tricky$^2$: Towards a Benchmark for Evaluating Human and LLM Error Interactions

Résumé technique : Tricky2 – Vers un benchmark pour l'évaluation des interactions entre erreurs humaines et LLM

Énoncé du problème

Alors que les modèles de langage de grande taille (LLM) sont de plus en plus intégrés dans les flux de travail de développement logiciel (par exemple, GitHub Copilot), les benchmarks existants pour les tests et le débogage de logiciels évaluent les erreurs générées par l'humain et par l'IA de manière isolée. Les ensembles de données actuels, tels que TrickyBugs (défauts humains) ou buggy-HumanEval (défauts de LLM), ne parviennent pas à capturer la réalité du développement moderne où le code écrit par l'humain et le code généré par l'IA coexistent au sein des mêmes fichiers et fonctions.

Le document identifie une lacune critique : les benchmarks existants ne peuvent pas évaluer les interactions d'erreurs. Dans les contextes hybrides, les corrections humaines peuvent masquer des fautes de LLM, et les réparations par LLM peuvent réintroduire des défauts humains ; de plus, les métriques d'évaluation standard peuvent échouer lorsque plusieurs sources d'erreurs se cumulent ou s'obscurcissent mutuellement. Par conséquent, la communauté du génie logiciel manque de la capacité d'évaluer rigoureusement les outils de réparation dans des contextes mixtes réalistes, ou d'étudier la fiabilité du débogage dans la collaboration hybride humain-IA.

Méthodologie

Pour répondre à cela, les auteurs introduisent Tricky2, un jeu de données hybride qui étend le corpus existant TrickyBugs. Le pipeline de construction comprend les étapes suivantes :

1. Jeu de données de base : Le fondement est TrickyBugs, contenant 3 043 programmes buggés écrits par des humains et 1 361 programmes corrigés en C++, Python et Java, dérivés de soumissions de programmation compétitive.
2. Injection de bugs contrôlée : Les auteurs emploient deux LLM, GPT-5 et OpenAI-oss-20b, pour injecter des erreurs supplémentaires dans les programmes existants.
   • Cadre de prompting : Un prompt structuré, guidé par une taxonomie, instruit les modèles d'injecter exactement un nouveau bug issu d'une taxonomie prédéfinie (Entrée/Sortie, Variable/Donnée, Logique/Condition, Boucle/Itération, Fonction/Procédure) tout en préservant strictement tous les défauts humains originaux et la structure du programme.
   • Contraintes : Les modèles ont pour instruction d'éviter les changements de commentaires ou de formatage et de produire le fichier modifié avec le niveau de la taxonomie et les positions de caractères du code injecté.
3. Répartition du jeu de données : Le processus génère trois répartitions distinctes :
   • Humain uniquement : Les programmes buggés originaux.
   • LLM uniquement : Programmes corrigés avec des erreurs injectées par LLM (sans bugs humains).
   • Humain + LLM : Programmes buggés contenant à la fois les défauts humains originaux et les nouveaux erreurs injectées par LLM.
4. Validation : Un pipeline automatisé valide la syntaxe et la compilation à l'aide d'outils spécifiques au langage (g++, py_compile, javac). Le corpus final contient 11 851 programmes buggés, toutes les répartitions partageant des cas de test et des références de correction identiques.

Principales contributions

• Benchmark Tricky2 : Le premier benchmark contrôlé modélisant explicitement la cooccurrence d'erreurs humaines et de LLM au sein de contextes de programmes partagés.
• Injection guidée par la taxonomie : Un pipeline reproductible utilisant une taxonomie d'erreurs spécifique pour générer des bugs d'origine machine qui interagissent avec les défauts humains sans altérer la structure du code original.
• Trois tâches d'évaluation : Le papier définit trois tâches complémentaires pour mesurer la fiabilité dans les contextes hybrides :
  1. Classification de l'origine : Distinguer entre les défauts humains, de LLM et mixtes.
  2. Identification de l'erreur : Localiser les segments de bugs et identifier le niveau de la taxonomie.
  3. Réparation de programme : Évaluer le succès de correctifs minimaux par rapport aux tests fournis.
• Évaluations de référence : Évaluations de preuve de concept à petite échelle sur un sous-ensemble stratifié de 135 problèmes difficiles (45 par répartition) en C++, Java et Python.

Résultats

Les évaluations de référence, bien que limitées en portée, révèlent des modèles distincts concernant les erreurs d'origine mixte :

• Difficulté de réparation : Les répartitions "Humain uniquement" et "LLM uniquement" ont toutes deux démontré des taux de réussite de réparation plus élevés par rapport à la répartition Humain + LLM.
• Effets d'interaction : Les résultats suggèrent que les défauts d'origine mixte introduisent des effets d'interaction qui compliquent le raisonnement et la réparation. Notamment, dans la répartition C++ de l'ensemble Humain + LLM, le modèle n'a pas réussi à produire un seul programme corrigé, malgré la correction réussie de sous-ensemts substantiels des cas à origine unique.
• Classification et localisation : Le papier rapporte des matrices de confusion et des cartes thermiques pour la classification de l'origine et l'identification de la taxonomie, bien que les pourcentages de précision spécifiques ne soient pas l'objet principal du résumé ; l'accent est mis sur la divergence des résultats de réparation.

Signification et affirmations

Le papier positionne Tricky2 comme une étape préliminaire mais nécessaire vers l'évaluation de la fiabilité logicielle dans les environnements de développement hybrides humain-IA. Les auteurs affirment que :

• Les effets d'interaction sont réels : Les défauts d'origine mixte ne sont pas simplement la somme de leurs parties ; ils créent des effets de cumul ou de masquage que les benchmarks actuels à source unique ne peuvent détecter.
• Les outils actuels peinent : Les LLM existants semblent éprouver des difficultés significatives face à la complexité du débogage de code où les erreurs humaines et de l'IA interagissent, soulignant une lacune dans les capacités de réparation actuelles.
• Fondation pour des travaux futurs : Tricky2 sert de fondation pour étudier la robustesse, la collaboration consciente des erreurs et la conception de flux de travail de codage humain-IA plus sûrs. Les auteurs envisagent des extensions futures impliquant des protocoles de débogage agentiques, des études longitudinales de la fiabilité des modèles, et l'expansion à d'autres langages et familles de modèles.

Le papier reconnaît explicitement des limites, notamment la dépendance à des versions spécifiques de LLM (qui peuvent évoluer avec le temps), la contrainte du domaine sous-jacent de TrickyBugs (programmation compétitive versus systèmes industriels), et l'absence de couverture pour les erreurs sémantiques complexes comme la concurrence ou la gestion de la mémoire. Cependant, il affirme que le jeu de données fournit une base de référence contrôlée pour l'étude des interactions d'erreurs qui étaient auparavant impossibles à mesurer.