Résumé Technique : Code-QA-Bench

Énoncé du Problème

Les benchmarks actuels pour les agents de codage IA, tels que HumanEval, MBPP et SWE-Bench, se concentrent principalement sur la génération de code ou la résolution de problèmes. Bien qu'efficaces pour mesurer la génération de correctifs, ils échouent à évaluer adéquatement la compréhension du code—la capacité à comprendre des bases de code existantes, à retracer les flux de contrôle, à localiser des fonctionnalités et à expliquer le comportement. Un écart critique existe dans la distinction entre le raisonnement authentique sur le code et le rappel de documentation ou la mémorisation pré-entraînement. Les benchmarks existants de type QA au niveau du dépôt évaluent souvent les agents sur des dépôts dont la documentation complète est intacte, rendant difficile la détermination de savoir si un agent lit le code ou se contente de rappeler des informations issues de ses données d'entraînement ou de la documentation fournie.

Méthodologie

Code-QA-Bench introduit un cadre entièrement automatisé conçu pour synthétiser des benchmarks de QA au niveau du dépôt qui isolent la compréhension du code de la documentation et de la mémorisation. Le cadre fonctionne selon quatre principes fondamentaux :

1. Conception Expérimentale à Trois Conditions

Pour quantifier les contributions spécifiques de l'accès au code, de la documentation et de la mémorisation, chaque tâche est évaluée dans trois conditions distinctes :

• Sans livre (Closed-book) : L'agent reçoit uniquement la question sans accès au dépôt. Cela mesure les connaissances préalables et la mémorisation.
• Code uniquement (Code-only) : L'agent a accès au dépôt avec tout le contenu en langage naturel supprimé (docstrings, commentaires, README et fichiers de documentation). Cela mesure le raisonnement purement structurel sur le code.
• Documenté (Documented) : L'agent a accès au dépôt complet incluant toute la documentation. Cela mesure le raisonnement sur le code augmenté par la documentation.

Des métriques clés sont dérivées des écarts entre ces conditions :

• Code uniquement - Sans livre : La contribution authentique de la lecture du code au-delà de la mémorisation.
• Documenté - Code uniquement : L'utilité de la documentation pour la compréhension du code.

2. Suppression de la Documentation (Contrôle au Niveau de l'Environnement)

Pour forcer un raisonnement structurel sur le code, le cadre crée une version "code uniquement" de chaque dépôt en supprimant programmatiquement :

• Docstrings : Identifiées via AST et supprimées (avec insertion de pass pour maintenir la syntaxe).
• Commentaires : Les commentaires sur ligne entière et inline sont supprimés ou tronqués.
• Fichiers de Documentation : Les répertoires comme docs/, doc/ et les fichiers comme README*, *.md et *.rst sont supprimés.
  Crucialement, le code exécutable, les imports, les annotations de type et les littéraux de chaîne sont préservés, garantissant que les signaux sémantiques provenant des identifiants subsistent.

3. Génération de Tâches Basée sur la Réponse

Contrairement aux approches précédentes qui génèrent d'abord les questions, Code-QA-Bench emploie un pipeline basé sur la réponse :

1. Sélection de Chunks : Des chunks de documentation sont extraits et notés en fonction de la qualité du contenu, des références au code et des signaux structurels.
2. Génération de la Réponse Or (Gold Answer) : Un agent équipé d'outils explore le code source (en utilisant read_file, list_directory, search_code) pour produire une "réponse or" vérifiée. L'agent est tenu de retracer au moins un niveau plus profondément que la documentation et d'inclure des faits absents du texte.
3. Vérification : Un "audit code uniquement" s'assure que la réponse or ne contient aucune affirmation qui ne pourrait être récupérée que depuis la documentation. Si une affirmation dépend de la documentation, elle est supprimée ou réécrite.
4. Dérivation de la Question : Une question en langage naturel est dérivée de la réponse or vérifiée, garantissant que la tâche est ancrée dans la structure réelle du code.

4. Double Ensemble de Tâches

Le benchmark génère deux ensembles de tâches distincts :

• Tâches Dérivables du Code (528 tâches) : Les réponses or sont vérifiées comme étant récupérables à partir de la structure du code uniquement. Ces tâches valident la conception (en s'attendant à Code uniquement ≈ Documenté).
• Tâches Dépendantes de la Documentation (100 tâches) : Les réponses or sont générées à partir de la documentation uniquement, exigeant intentionnellement la documentation pour une réponse complète. Ces tâches quantifient l'utilité de la documentation (en s'attendant à Documenté > Code uniquement).

5. Évaluation

Les tâches sont notées par un juge LLM (GPT-5.4) sur une échelle de 0 à 5 selon trois axes :

• Précision : Exactitude des affirmations factuelles.
• Exhaustivité : Couverture des points clés dans la grille d'évaluation.
• Spécificité : Référence à des fichiers, fonctions ou motifs de code spécifiques.
  Le score final est la moyenne normalisée de ces trois axes.

Résultats Clés

Des expériences ont été menées sur quatre modèles de pointe (Claude Opus 4.6, DeepSeek-V4-Pro, Kimi-K2.6, Gemini-3.1-Pro) à travers 10 dépôts Python issus de SWE-Bench.

1. L'Accès au Code est le Facteur Dominant

L'accès à la base de code procure un gain de performance substantiel par rapport à la mémorisation. Le gain moyen de Code uniquement par rapport à Sans livre est de +0,23, ce qui est trois fois plus important que le gain fourni par la documentation. Cela confirme que la lecture du code contribue significativement plus à la compréhension que les seules connaissances préalables.

2. La Documentation Apporte une Utilité Modeste et Mesurable

Pour les tâches dépendantes de la documentation, l'accès à la documentation produit une amélioration constante et statistiquement significative (Documenté - Code uniquement = +0,071, p < 0,003). Cela suggère que, bien que la structure du code permette aux agents d'inférer une grande partie de la réponse, la documentation fournit des détails critiques (rationnel de conception, cas limites) qui améliorent l'exhaustivité et la précision.

3. Validation de la Conception Expérimentale

Sur les tâches dérivables du code, l'écart de performance entre les conditions Code uniquement et Documenté est négligeable (∆ ≈ +0,007) et statistiquement insignifiant pour la plupart des modèles. Cela valide la méthodologie : le cadre isole avec succès les tâches où la documentation est inutile, prouvant que les bénéfices observés sur les tâches dépendantes de la documentation sont une utilité authentique et non des artefacts de la configuration d'évaluation.

4. Insights Spécifiques aux Modèles

• Mémorisation : Les modèles obtiennent des scores de 0,56 à 0,68 dans la condition sans livre, indiquant une mémorisation pré-entraînement significative des bibliothèques bien connues.
• Raisonnement vs Rappel : DeepSeek-V4-Pro a montré l'écart le plus important entre code uniquement et sans livre (+0,450), suggérant une forte dépendance à l'exploration active du code plutôt qu'au rappel paramétrique.
• Analyse par Catégorie : Contrairement à l'hypothèse selon laquelle les questions "Pourquoi" montreraient le plus grand écart de documentation, les questions "Où" (localisation de fonctionnalités) ont montré le delta le plus significatif sur les tâches dérivables du code, suggérant que la documentation agit comme un index de navigation.

Signification et Revendications

L'article revendique que Code-QA-Bench fournit un changement méthodologique nécessaire dans l'évaluation des agents de codage IA en :

1. Séparant la Compréhension de la Mémorisation : Il offre une manière quantitative de mesurer dans quelle mesure un agent dépend de la lecture du code par rapport au rappel de données d'entraînement ou de documentation.
2. Contrôle au Niveau de l'Environnement : En supprimant la documentation au niveau du dépôt plutôt qu'en filtrant les questions, il force les agents à s'engager avec la structure du code, abordant le problème de "contamination" dans les benchmarks existants.
3. Automatisé et Reproductible : Le pipeline est entièrement automatisé, agnostique du dépôt et applicable à tout dépôt Python bien documenté, permettant des mises à jour continues du benchmark à mesure que les modèles s'améliorent.
4. Valeur Diagnostique : La conception à trois conditions fournit des signaux diagnostiques (par exemple, saturation de la spécificité, niveaux de mémorisation) que les benchmarks de génération seule manquent, offrant une vue plus nuancée des capacités d'un agent.

Les auteurs concluent que, bien que les modèles de pointe soient de forts lecteurs de structure de code, le bénéfice modeste mais constant de la documentation souligne l'importance continue de bases de code bien documentées pour les agents IA. Le cadre est open-source et sert à la fois d'outil d'évaluation et de source de données d'entraînement vérifiées.