SWE-QA-Pro: A Representative Benchmark and Scalable Training Recipe for Repository-Level Code Understanding

Ce papier présente SWE-QA-Pro, une nouvelle benchmark et une recette d'entraînement évolutive combinant un pipeline de données synthétiques et un apprentissage par renforcement, conçues pour évaluer et améliorer la compréhension de code au niveau du dépôt par des modèles agentic, permettant ainsi à un petit modèle open-source de surpasser GPT-4o sur cette tâche.

L'essentiel

🕵️‍♂️ SWE-QA-Pro : Le Grand Jeu de l'Enquêteur de Code

Imaginez que le développement logiciel est comme une immense bibliothèque remplie de millions de livres (les projets de code). Les intelligences artificielles (les IA) sont censées être des bibliothécaires géniaux capables de trouver n'importe quelle information dans ces livres.

Mais il y a un gros problème : jusqu'à présent, on testait ces bibliothécaires avec des questions trop faciles ou trop connues. C'est comme demander à un bibliothécaire : "Qui a écrit Harry Potter ?". Même un enfant qui a lu le livre par cœur peut répondre sans jamais ouvrir le rayon des livres. L'IA triche en utilisant sa "mémoire" (ce qu'elle a appris avant) au lieu de vraiment chercher dans les livres.

SWE-QA-Pro est une nouvelle méthode pour tester et entraîner ces IA de manière honnête et efficace.

1. Le Nouveau Terrain de Jeu (Le Benchmark)

Les chercheurs ont créé un nouveau test, SWE-QA-Pro, qui ressemble à une immense chasse au trésor dans des bibliothèques obscures et complexes.

• Le problème des anciens tests : Ils utilisaient des projets très célèbres (comme les géants du web). Les IA connaissaient déjà ces projets par cœur.
• La solution SWE-QA-Pro : Ils ont choisi des projets de code "de la longue traîne" (des projets moins connus, très spécifiques, comme des outils de niche pour des ingénieurs). C'est comme demander à un bibliothécaire de trouver un livre rare dans un sous-sol poussiéreux qu'il n'a jamais visité.
• Le piège : Pour s'assurer que l'IA ne triche pas, ils ont éliminé toutes les questions qu'une IA pourrait répondre juste en "devinant" ou en se souvenant de son entraînement. Si l'IA ne peut pas répondre sans ouvrir les fichiers du projet, alors c'est une bonne question !

L'analogie : C'est la différence entre demander "Quel est le nom de la capitale de la France ?" (réponse mémorisée) et "Montrez-moi la page exacte du plan de la ville où se trouve la boulangerie de mon voisin" (nécessite une exploration réelle).

2. Le Mécanisme de Difficulté (Le Filtre Anti-Triche)

Comment savoir si une question est vraiment difficile ?
Les chercheurs ont utilisé un système de "juge de paix". Ils ont demandé à trois super-IA (les plus intelligentes du moment) de répondre aux questions sans avoir accès aux fichiers du projet, juste avec leur cerveau.

• Si les super-IA réussissent sans effort, la question est trop facile : on la jette.
• Si elles échouent, c'est que la question nécessite vraiment de fouiller dans le code. On la garde.

C'est comme un examen de conduite où l'on retire les questions sur le code de la route (que tout le monde connaît) pour ne garder que les situations de conduite réelle dans la boue et la pluie.

3. L'Entraînement de l'Agent (La Méthode d'Apprentissage)

Une fois le test créé, il fallait apprendre aux IA à réussir. Les chercheurs ont proposé une recette en deux étapes, un peu comme l'apprentissage d'un nouvel instrument de musique :

• Étape 1 : La Supervision (SFT) - "Apprendre les notes"
  On montre à l'IA (un modèle open-source comme Qwen3-8B) des exemples de la bonne façon de chercher. On lui dit : "Regarde ici, puis va là-bas, et lis ce fichier". C'est comme un professeur qui montre à l'élève comment tenir son violon.
• Étape 2 : L'Apprentissage par Récompense (RLAIF) - "Le concert"
  C'est ici que la magie opère. L'IA essaie de répondre seule. À la fin, un "juge" (une autre IA très stricte) note sa réponse.
  • Si l'IA a trouvé le bon fichier et la bonne ligne de code : Points ! 🌟
  • Si elle a inventé des choses ou n'a pas cherché assez : Zéro point. ❌
  • L'IA apprend de ses erreurs et s'améliore pour obtenir plus de points. C'est comme un joueur de vidéo qui répète un niveau jusqu'à obtenir le "S" (le meilleur score).

4. Les Résultats : Le Petit Géant qui Bat les Titans

Le résultat le plus surprenant ?
Un petit modèle open-source (Qwen3-8B), entraîné avec cette méthode, a réussi à battre des géants propriétaires (comme GPT-4o de chez OpenAI) sur ce test spécifique.

L'analogie finale :
Imaginez un petit chien de berger (le modèle open-source) qui, grâce à un entraînement spécifique à la recherche de moutons perdus dans la montagne, devient plus efficace qu'un lion (GPT-4o) qui, bien que puissant, n'a jamais appris à chercher dans ce type de terrain.

En Résumé

SWE-QA-Pro nous dit deux choses importantes :

1. Arrêtons de tricher : Il faut tester les IA avec des problèmes réels où elles doivent vraiment "lire" et "comprendre" le code, pas juste se souvenir de leur entraînement.
2. L'entraînement compte plus que la taille : Avec la bonne méthode d'entraînement (SFT + RL), un petit modèle intelligent et bien entraîné peut surpasser des modèles géants et coûteux dans des tâches complexes de navigation dans le code.

C'est une victoire pour l'open-source et une preuve que l'intelligence artificielle peut devenir un véritable assistant de développement, capable de se débrouiller seul dans des projets complexes.

Résumé technique

1. Problématique et Contexte

L'article identifie deux lacunes majeures dans l'évaluation actuelle de la compréhension du code par les modèles de langage (LLM) au niveau d'un dépôt entier (repository-level) :

• Manque de diversité et biais de mémorisation : Les benchmarks existants se concentrent sur quelques dépôts populaires. Les LLMs peuvent souvent "tricher" en répondant correctement grâce à des connaissances pré-entraînées (mémorisation) plutôt qu'en explorant réellement le code. De plus, ils négligent les sujets "long tail" (rares) comme la configuration, l'infrastructure ou le "glue code".
• Indétermination du besoin d'outils : De nombreuses questions des benchmarks actuels peuvent être résolues sans interaction avec le codebase (réponse directe). Cela empêche de distinguer les modèles capables de navigation active de ceux qui se contentent de rappeler des faits génériques.

L'objectif est donc de créer un environnement d'évaluation rigoureux qui force les modèles à explorer le code et de proposer une méthode d'entraînement efficace pour les modèles open-source afin qu'ils maîtrisent ces tâches complexes.

2. Méthodologie

L'approche proposée repose sur deux piliers principaux : la construction du benchmark SWE-QA-Pro et une recette d'entraînement en deux étapes.

A. Construction du Benchmark SWE-QA-Pro

Le benchmark est construit via un pipeline en quatre étapes (illustré dans la Figure 1a du papier) :

1. Collecte et Taxonomie : Analyse de plus de 1,6 million d'issues GitHub provenant de dépôts "long tail". Utilisation de clustering hiérarchique (K-Means) sur les embeddings des textes pour créer une taxonomie de 48 sous-catégories de tâches (ex: configuration, pipeline CI, gestion de dépendances).
2. Synthèse des Données : Utilisation d'agents (Claude Code) pour générer des paires question-réponse basées sur les issues réelles, en s'assurant que les problèmes sont exécutables dans des environnements "sandbox".
3. Calibration de la Difficulté (Filtrage) : C'est l'étape critique. Pour chaque question générée, on compare une réponse directe (sans outils, basée uniquement sur la connaissance du modèle) avec une réponse utilisant des outils d'exploration. Si le modèle direct obtient un score élevé, la question est rejetée. Cela garantit que le benchmark ne contient que des questions nécessitant une exploration active du code.
4. Validation : Les réponses sont vérifiées par des humains et des agents pour garantir la justesse factuelle et l'ancrage dans le dépôt (citations de fichiers et lignes de code).

Le résultat final est un ensemble de 260 questions provenant de 26 dépôts, équilibrées sur les types de tâches et difficiles à résoudre sans outils.

B. Recette d'Entraînement (Training Recipe)

Pour améliorer les petits modèles open-source sur ces tâches, les auteurs proposent un pipeline d'entraînement en deux étapes :

1. Supervised Fine-Tuning (SFT) : Entraînement sur 1 000 trajectoires de conversation multi-tours générées par un modèle fort (Claude Sonnet 4.5). Cela apprend au modèle la syntaxe des outils (recherche, visualisation de fichiers, commandes en lecture seule) et les patterns d'utilisation.
2. Reinforcement Learning from AI Feedback (RLAIF) : Utilisation d'un algorithme de renforcement (GRPO) sur 464 questions supplémentaires. Un modèle "Juge" (LLM-as-a-Judge) évalue les réponses générées selon cinq dimensions : exactitude, complétude, pertinence, clarté et qualité du raisonnement. Le modèle est récompensé pour produire des réponses ancrées dans le code (citations précises) et pénalisé pour les réponses floues ou incorrectes.

L'agent utilisé pour l'inférence suit un boucle ReAct (Reason + Act) sans index pré-construit (RAG), explorant directement le dépôt via des actions structurées (Search, View, Command).

3. Résultats Clés

Les expériences ont été menées sur 11 LLMs (propriétaires et open-source) en mode "réponse directe" et "agent".

• Écart de performance : Il existe un écart significatif entre les modèles répondant directement et ceux utilisant l'agent. Par exemple, pour Claude Sonnet 4.5, l'utilisation de l'agent améliore le score global de 3,34 à 7,34, confirmant que les tâches nécessitent une exploration réelle.
• Performance du modèle entraîné : Un modèle Qwen3-8B entraîné avec la recette SFT $\rightarrow$ RLAIF dépasse GPT-4o sur le benchmark SWE-QA-Pro avec une marge de 2,3 points (5,96 contre 5,59).
• Convergence vers l'état de l'art : Le modèle Qwen3-8B entraîné réduit considérablement l'écart avec les modèles propriétaires de pointe (GPT-4.1, Claude Sonnet 4.5, DeepSeek-V3.2), démontrant que l'entraînement spécifique sur les comportements d'agent est plus efficace que la simple augmentation de la taille du modèle.
• Analyse par type de tâche : Les modèles performants excellent dans les tâches de localisation (trouver un fichier), mais peinent davantage sur les questions causales ou explicatives nécessitant une intégration de preuves sur plusieurs fichiers.

4. Contributions Principales

1. SWE-QA-Pro (Benchmark) : Un nouveau standard pour l'évaluation de la compréhension de dépôts, caractérisé par sa diversité (dépôts long tail), son exécutabilité et son filtrage rigoureux contre les réponses basées sur la mémorisation.
2. Workflow Agent et Recette d'Entraînement : Une méthode scalable pour entraîner des modèles open-source à l'exploration active de code. La combinaison SFT + RLAIF permet à un modèle de 8B de surpasser des modèles beaucoup plus grands et propriétaires.
3. Preuve de concept : La démonstration que l'entraînement sur des comportements d'agent (navigation, raisonnement ancré) est crucial pour les tâches d'ingénierie logicielle réelles, et que les petits modèles peuvent atteindre des performances compétitives avec la bonne stratégie d'entraînement.

5. Signification et Impact

Ce travail marque un tournant dans la recherche sur les agents logiciels :

• Il déplace le focus des benchmarks basés sur la connaissance (qui favorisent les gros modèles) vers des benchmarks basés sur l'action et l'exploration.
• Il prouve que les modèles open-source, lorsqu'ils sont correctement entraînés à utiliser des outils et à raisonner sur le code, peuvent rivaliser avec les géants propriétaires.
• Il fournit une "recette" reproductible (SFT + RLAIF) et un pipeline de données synthétiques qui peuvent être adaptés à d'autres langages ou domaines, ouvrant la voie à des assistants de développement plus autonomes et accessibles.

En résumé, SWE-QA-Pro établit que la véritable compréhension du code ne réside pas dans la mémorisation, mais dans la capacité à naviguer, vérifier et raisonner de manière itérative au sein d'une base de code complexe.