← Derniers articles
💻 computer science

Bug Report Specification Refinement with Trajectory Guidance for Automated Program Repair

TrajSpec est un cadre guidé par la trajectoire qui affine les rapports de bogues en synthétisant les preuves issues des trajectoires du dépôt pré-correction en une spécification hiérarchique, améliorant de manière significative les taux de réussite de la réparation automatique de programmes à travers de multiples agents et benchmarks.

Auteurs originaux : S M Farah Al Fahim (Peter), Md Nakhla Rafi (Peter), Md Ahasanuzzaman (Peter), Zeyang Ma (Peter), Dong Jae Kim (Peter), Shaowei Wang (Peter), Tse-Hsun (Peter), Chen

Publié 2026-07-10
📖 1 min de lecture☕ Lecture pause café

Auteurs originaux : S M Farah Al Fahim (Peter), Md Nakhla Rafi (Peter), Md Ahasanuzzaman (Peter), Zeyang Ma (Peter), Dong Jae Kim (Peter), Shaowei Wang (Peter), Tse-Hsun (Peter), Chen

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

Résumé technique : TrajSpec – Affinement de la spécification des rapports de bogues guidé par la trajectoire

Énoncé du problème

Les agents de réparation automatique de programmes (APR) au niveau du dépôt dépendent des rapports de bogues comme principale spécification de tâche. Cependant, les rapports de bogues standards décrivent souvent uniquement les symptômes de défaillance observés, omettant des informations critiques pour la réparation, telles que le mécanisme de défaillance sous-jacent, les exigences comportementales spécifiques et l'étendue complète de l'implémentation. Par conséquent, les agents d'APR peuvent inspecter du code non pertinent, inférer des exigences incorrectes ou générer des correctifs qui traitent le symptôme rapporté sans restaurer le comportement prévu du dépôt. Bien que des travaux antérieurs se soient concentrés sur l'amélioration des stratégies de recherche, de la localisation ou de l'ingénierie de prompts des agents, ces approches supposent souvent que le rapport d'entrée constitue une spécification suffisante. Il existe un manque dans les méthodes qui affinent explicitement le rapport en recueillant les détails de spécification manquants à partir du dépôt avant que le processus de réparation en aval ne commence.

Méthodologie : TrajSpec

Les auteurs proposent TrajSpec, une approche guidée par la trajectoire pour l'affinement de la spécification supportée par le dépôt. Le système opère sur un rapport de bogue original (bb) et un instantané du dépôt pré-correctif (RcR_c) via le pipeline suivant :

  1. Collecte de trajectoire non vérifiée :
    TrajSpec exécute un agent de collecte de trajectoire en utilisant uniquement bb et RcR_c. Cet agent explore le dépôt, inspecte le code et raisonne sur le problème. Crucialement, cette exécution est non vérifiée : TrajSpec ne valide aucun correctif candidat produit durant cette phase. Tout correctif candidat est rejeté, et seule la trajectoire d'exécution (τ\tau) — une séquence de tuples pensée-action-observation — est conservée. Cette trajectoire sert de source de preuves supportées par le dépôt, même si le correctif final de l'agent était incorrect.

  2. Abstraction hiérarchique des preuves :
    Les trajectoires brutes sont souvent bruitées et longues. TrajSpec extrait des conclusions candidates de bb et τ\tau en se concentrant sur trois dimensions :

    • Mécanisme de défaillance : Le comportement du code source expliquant le symptôme.
    • Exigence comportementale : Le comportement qui devrait être maintenu.
    • Étendue de l'implémentation : Les emplacements de code impliqués.

    Ces conclusions sont organisées en une représentation hiérarchique (MM) avec trois niveaux de détail pour chaque dimension :

    • Niveau élevé : Une conclusion de spécification candidate.
    • Niveau intermédiaire : Raisonnement diagnostique et relations (ex: chemins de code, dépendances).
    • Niveau bas : Observations concrètes du dépôt (ex: fichiers, fonctions, variables spécifiques).
  3. Génération de brouillon et revue basée sur le dépôt :
    En utilisant bb et MM, un LLM génère un rapport affiné de brouillon (b^\hat{b}) suivant un schéma fixe (Titre, Description, CauseRacine, ÉtapesPourReproduire, ComportementAttendu, ComportementObservé).

    Une étape de revue basée sur le dépôt valide ensuite b^\hat{b} par rapport à RcR_c. Un agent réviseur évalue si les affirmations du brouillon sont supportées par les preuves de MM et le code source réel. Il supprime les affirmations non supportées, révise les énoncés incertains, ajoute les détails manquants supportés par le dépôt et s'assure que l'étendue de l'implémentation est appropriément délimitée. Le résultat est le rapport affiné final (b^f\hat{b}_f), qui sert de spécification de tâche pour l'agent de réparation en aval.

Contributions clés

  • Formulation : L'article formule l'amélioration des rapports de bogues pour l'APR au niveau du dépôt comme un "affinement de spécification supporté par le dépôt", visant à rendre explicites le mécanisme de défaillance, l'exigence comportementale et l'étendue de l'implémentation.
  • Framework TrajSpec : Introduction d'une méthode qui extrait et organise hiérarchiquement les preuves de spécification à partir d'une exécution de collecte de trajectoire non vérifiée, révise ces preuves par rapport au code source, et génère un rapport affiné sans supposer que les correctifs candidats de la trajectoire sont corrects.
  • Évaluation complète : Évaluation sur les 300 instances de SWE-Bench Lite en utilisant Mini-SWE-Agent V2, démontrant des améliorations significatives de performance.
  • Généralisation : Démonstration que les bénéfices de TrajSpec se généralisent à différents agents de réparation en aval (Agentless et AutoCodeRover).
  • Analyse des composants : Études d'ablation confirmant que la représentation hiérarchique des preuves et la revue basée sur le dépôt sont toutes deux critiques pour les gains de performance.

Résultats d'évaluation

Les auteurs ont évalué TrajSpec sur 300 instances de SWE-Bench Lite :

  • Agent de réparation primaire (Mini-SWE-Agent V2) :

    • Avec GPT-5-mini, le Pass@1 est passé de 41,00 % (rapports originaux) à 59,67 %.
    • Avec MiniMax M2.5, le Pass@1 est passé de 54,67 % à 64,33 %.
    • TrajSpec a surpassé une ligne de base "Agentic-Base" (qui utilise les données de trajectoire mais manque d'abstraction hiérarchique et de revue de dépôt) dans les deux configurations.
    • Les améliorations étaient largement distribuées sur 12 dépôts différents, TrajSpec élargissant la couverture de réparation tout en préservant presque toutes les instances précédemment réparées par les rapports originaux.
  • Généralisation inter-agents (Échantillon stratifié de 100 instances) :

    • Agentless : Le Pass@1 est passé de 41,00 % à 71,00 %.
    • AutoCodeRover : Le Pass@1 est passé de 47,00 % à 72,00 %.
  • Études d'ablation :

    • Supprimer la revue basée sur le dépôt a réduit le Pass@1 de 59,67 % à 48,00 %.
    • Supprimer la représentation hiérarchique des preuves a réduit le Pass-@1 à 47,67 %.
    • Cela confirme que la structuration des preuves et la vérification des affirmations par rapport au dépôt sont essentielles.
  • Analyse des coûts :

    • Bien que TrajSpec incurre un coût supplémentaire pour la génération du rapport (environ 0,083 $ par instance avec GPT-5-mini), il réduit l'utilisation des tokens d'entrée de la réparation en aval d'environ 24 % et diminue le coût monétaire de l'exécution de la réparation elle-même. Le coût total de bout en bout reste modeste par rapport aux gains significatifs de succès.

Signification et Revendications

L'article affirme que TrajSpec offre une direction prometteuse pour améliorer la réparation au niveau du dépôt en abordant le "problème de spécification" inhérent aux rapports de bogues sous-spécifiés. Les auteurs soulignent que :

  1. Les trajectoires sont réutilisables au-delà de la génération de correctifs : Même les trajectoires non vérifiées contiennent des preuves précieuses concernant les mécanismes de défaillance et la portée du code qui peuvent être abstraites et structurées pour améliorer la spécification de la tâche.
  2. La vérification est critique : L'utilisation simple des données de trajectoire est insuffisante ; une structure hiérarchique et une étape de revue basée sur le dépôt sont nécessaires pour filtrer le bruit et garantir que les affirmations sont ancrées dans le code pré-correctif.
  3. La spécification de la tâche compte : Améliorer la spécification d'entrée (le rapport de bogue) est aussi important que d'améliorer l'agent de réparation lui-même. TrajSpec démontre que fournir aux agents un contexte actionnable et supporté par le dépôt améliore systématiquement la performance de réparation à travers différents modèles et architectures d'agents.

Les auteurs maintiennent une position modeste, notant que leur évaluation est limitée aux dépôts Python dans SWE-Bench Lite et que l'efficacité pour d'autres langages ou benchmarks reste un travail futur. Ils reconnaissent également que bien que les rapports affinés améliorent les métriques de réparation automatisée, l'étude se concentre sur l'utilité pour l'APR plutôt que sur la qualité des rapports perçue par l'humain.

Noyé(e) sous les articles dans votre domaine ?

Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.

Essayer Digest →