Résumé technique : Abstention et Validation : Une politique à double LLM pour réduire le bruit dans la réparation de programmes agentique

Énoncé du problème

Les systèmes de réparation automatique de programmes (APR) agentiques ont démontré leur capacité à résoudre des bogues complexes au niveau du dépôt, atteignant des taux de pass@1 élevés sur des benchmarks comme SWE-Bench-Verified. Cependant, le déploiement de ces systèmes dans des contextes industriels présente un défi critique : le problème du « bruit ». Même avec des taux de résolution en progression, une proportion significative de correctifs générés est peu susceptible d'être acceptée par les développeurs humains. Présenter ces correctifs de faible qualité ou intraitables gaspille le temps précieux des développeurs, érode la confiance envers les outils automatisés et engendre des coûts de calcul inutiles. Le problème central abordé est la manière de filtrer les bogues qu'un système APR est peu susceptible de résoudre avant les tentatives de réparation, et de rejeter les correctifs qui sont peu susceptibles d'être corrects après la génération, optimisant ainsi le rapport signal/bruit pour les réviseurs humains.

Méthodologie

Les auteurs proposent un cadre de politique à double LLM composé de deux étapes complémentaires : l'Abstention de Bogue et la Validation de Correctif.

1. Politique d'Abstention de Bogue

Cette politique opère avant que l'agent de réparation ne tente une correction. Elle fonctionne comme un pré-filtre pour exclure les bogues jugés peu susceptibles d'être résolus par le système.

• Entrée : Uniquement le rapport de bogue (titre, description, métadonnées). La politique n'accède pas au code source ni à la trajectoire de l'agent afin de maintenir l'efficacité.
• Mécanisme : Un LLM prédit la probabilité d'une tentative de réparation réussie. Les auteurs formalisent cela comme l'estimation de la probabilité de succès empirique ($\hat{\pi}_b$) d'un bogue $b$.
• Représentations : Deux stratégies de prompting ont été évaluées :
  • Prompting d'instruction sans directives : Entrée de base du rapport de bogue.
  • Prompting d'instruction avec directives : Augmenté de critères dérivés de l'humain (ex: « Problème et action clairs », « Localisation précise du code ») pour guider l'évaluation de la difficulté par le LLM.
• Décision : Si la probabilité prédite $P_a(b)$ est inférieure à un seuil configurable $\tau$, le système s'« abstient » de tenter la réparation, économisant ainsi du calcul et évitant la génération de correctifs de faible qualité.

2. Politique de Validation de Correctif

Cette politique opère après que l'agent a généré une trajectoire de réparation. Elle évalue si un correctif spécifique est une correction correcte.

• Entrée : Le rapport de bogue, la trajectoire de l'agent (pensées et actions), le correctif généré (diff) et les résultats des tests.
• Mécanisme : Une approche multi-étapes :
  1. Vérifications déterministes : Construction et tests de régression pour éliminer les correctifs présentant des échecs évidents.
  2. Génération de spécification de correction : Un LLM génère une « spécification de correction » — un ensemble de critères pour une correction correcte basé uniquement sur le rapport de bogue et les fichiers sources originaux (sans connaissance de la solution de référence).
  3. Jugement par LLM : Un second appel de LLM évalue la tentative de l'agent par rapport à la spécification générée, au correctif et aux résultats des tests.
• Sortie : Un triplet comprenant un jugement binaire (corrigé/non corrigé), une explication en langage naturel et un score de confiance dérivé des probabilités de log des tokens.
• Décision : Les correctifs peuvent être filtrés sur la base du jugement binaire ou d'un seuil de percentile du score de confiance, permettant une sévérité ajustable.

3. Cadre combiné

Les deux politiques sont composées séquentiellement : l'Abstention de Bogue filtre l'ensemble initial de bogues, le système APR tente les réparations sur les bogues restants, et la Validation de Correctif filtre les correctifs résultants. Cela crée un entonnoir configurable pour la révision par les développeurs.

Évaluation et Résultats

Les politiques ont été évaluées sur trois jeux de données industriels provenant du code source de Google :

1. Bogues rapportés par l'humain (174 bogues) : Corrections de vérité terrain connues et tests de reproduction en échec.
2. Bogues NPE rapportés par machine (198 bogues) : Exceptions de pointeur nul (Null Pointer Exceptions) issues d'un déploiement réel avec traces de pile (stack traces).
3. Bogues rapportés par sanitizers (50 bogues) : Erreurs de mémoire et de concurrence (data races) avec tests de reproduction connus.

Principaux résultats :

• Bogues rapportés par l'humain :
  • Baseline : Le système non filtré a obtenu un taux de fail-to-pass@1 de 11,29 %.
  • Abstention de Bogue : En utilisant les directives ($r_2$), le taux de fail-to-pass@1 filtré est passé à 21,05 %.
  • Validation de Correctif : En utilisant une validation stricte basée sur le percentile (90e percentile), le taux de fail-to-pass@1 filtré est passé à 29 % (un gain de 15 points de pourcentage par rapport à la baseline).
  • Politique combinée : L'approche à double politique a atteint un fail-to-pass@1 filtré de 53 % (un gain de 39 points de pourcentage) avec la configuration la plus stricte (combined-p90), augmentant efficacement le taux de réussite à 1 sur 2 pour les correctifs présentés aux développeurs.
• Bogues rapportés par machine :
  • La validation de correctif a considérablement amélioré les taux d'accept@1 filtrés pour les bogues NPE (de 0,38 à 0,62) et les bogues de sanitizers (jusqu'à 15 points de pourcentage par rapport à la baseline).
• Compromis : L'étude souligne un arbitrage entre le volume de bogues tentés et la précision des correctifs présentés. Un filtrage plus strict (ex: 90e percentile) réduit drastiquement le nombre de bogues présentés aux développeurs (ex: de 174 à 12) mais garantit un taux de réussite bien plus élevé pour ceux qui restent.

Principales contributions

1. Politique d'Abstention de Bogue : Un nouveau mécanisme de pré-filtrage de la réparation utilisant des LLM pour prédire la faisabilité de la réparation basée uniquement sur les rapports de bogues, évitant ainsi des tentatives de réparation futiles.
2. Politique de Validation de Correctif : Un cadre d'évaluation post-réparation multi-étapes qui utilise des « spécifications de correction » générées sans connaissance de la vérité terrain pour filtrer les correctifs candidats.
3. Évaluation industrielle étendue : Une étude complète à travers trois catégories distinctes de bogues (rapportés par l'humain, NPE et sanitizers) démontrant la nature complémentaire des deux politiques.
4. Innovation de métrique : Introduction du « filtered success@k », une métrique qui évalue les taux de réussite uniquement sur le sous-ensemble de bogues et de correctifs autorisés par les politiques, fournissant une mesure plus réaliste de l'expérience développeur.

Signification et Revendications

L'article affirme que cette approche à deux politiques offre une voie pratique vers le déploiement fiable et à l'échelle industrielle des systèmes d'APR agentiques. En réduisant considérablement le bruit des tentatives de réparation improductives, le cadre répond au goulot d'étranglement critique de la confiance et du temps des développeurs.

Les auteurs soulignent que, bien que le taux global de résolution de bogues puisse diminuer en raison d'un filtrage agressif (car certains bogues réparables sont rejetés), la qualité des correctifs présentés aux développeurs s'améliore de façon spectaculaire. En termes pratiques, cela transforme l'expérience du développeur, passant de la révision d'un correctif ayant environ 10 % de chances de succès à la révision d'un correctif ayant environ 50 % de chances de succès (sous des paramètres stricts) ou environ 33 % (sous des paramètres permissifs). Ce changement est jugé essentiel pour l'adoption des outils d'IA dans le génie logiciel, car il aligne la production des systèmes automatisés avec la capacité limitée des réviseurs humains. Le travail ne prétend pas résoudre la difficulté fondamentale de réparer tous les bogues, mais cherche plutôt à optimiser l'interaction entre les systèmes agentiques et les développeurs humains en garantissant que seuls les candidats les plus prometteurs atteignent l'étape humaine.