SWE-QA: Can Language Models Answer Repository-level Code Questions?

1. Probleemstelling

Huidige Large Language Models (LLM's) tonen veelbelovende resultaten in codebegrip, maar bestaande benchmarks (zoals CoSQA, CodeQA) richten zich voornamelijk op geïsoleerde codefragmenten, functies of API's. Deze opstellingen falen in het vastleggen van de complexiteit van software-engineering in de echte wereld, waar ontwikkelaars moeten:

• Navigeren door grote, onderling verbonden codebases die over meerdere bestanden verspreid zijn.
• Software-architectuur en ontwerprationalen begrijpen.
• Lange-afstandsafhankelijkheden traceren en multi-hop redenering uitvoeren.
• Architecturale kennis synthetiseren om complexe "Waarom"- en "Hoe"-vragen te beantwoorden.

Er ontbreekt een hoogwaardige, door mensen geverifieerde benchmark die LLM's evalueert op repository-level vraag-antwoord (QA) waarbij diepe, multi-file context en structureel begrip vereist zijn.

2. Methodologie: Bouw van de SWE-QA Benchmark

De auteurs stellen SWE-QA voor, een repository-level code QA-benchmark die is opgebouwd via een viertrapsproces (Figuur 2) met 15 diverse Python-repositories (12 uit SWE-Bench, 3 uit SWE-Bench-Live).

A. Verzameling van Zaden en Constructie van Taxonomie

• Data Bron: 77.100 GitHub-issues van 12 populaire repositories gekraald.
• Filtering: 41.955 issues met substantiële inhoud (>1.000 tekens) geselecteerd en een LLM gebruikt om 127.415 expliciete code-gerelateerde vragen te extraheren.
• Taxonomie: Twee menselijke experts met meer dan 3 jaar ervaring analyseerden handmatig 1.000 gestichte vragen om een twee-niveau taxonomie te creëren:
  • Niveau 1 (Interrogatief): Wat, Waarom, Waar, Hoe.
  • Niveau 2 (Intentie): 12 fijnmazige categorieën (bijv. Dependency Tracing, Design Rationale, Feature Location, Algorithm Implementation).
• Verdeling: "Hoe"-vragen (35,2%) en "Waar"-vragen (28,4%) komen het meest voor, wat de behoefte aan procedurele en locatiewaarde kennis weerspiegelt.

B. Instantiatie van Vragen

• Context Extractie: tree-sitter gebruikt om repository-structuren te parsen naar getypeerde grafen (knooppunten: klassen, methoden, bestanden; randen: calls, imports).
• Generatie: Focus-elementen geselecteerd (bijv. een specifieke klasse) en hun structurele context gecombineerd met zaadtemplates afgeleid van de taxonomie.
• Proces: Een LLM genereerde kandidaatvragen die op maat waren gemaakt voor specifieke repositories, waarbij werd gegarandeerd dat ze multi-hop redenering vereisten en niet door eenvoudige retrieval konden worden beantwoord.

C. Verzameling en Validatie van Antwoorden

• RAG-pijplijn: Antwoorden werden gegenereerd met een Retrieval-Augmented Generation (RAG)-aanpak, waarbij relevante codefragmenten, documentatie en metadata werden opgehaald.
• Mens in de Lus:
  • Expert Herziening: Twee senior ontwikkelaars beoordeelden elk antwoord op feitelijke juistheid, volledigheid en duidelijkheid met tools zoals Cursor. Meningsverschillen werden opgelost door een derde expert.
  • Kwaliteitsfiltering: Paren werden verworpen als ze dubbelzinnig, feitelijk onjuist waren of onvoldoende onderbouwd waren in de code.
• Definitieve Dataset: 720 hoogwaardige QA-paren (48 per repository), die 13.300 bestanden en meer dan 3,4 miljoen regels code bestrijken.

3. Belangrijkste Bijdragen

1. SWE-QA Benchmark: Een repository-level QA-benchmark met 720 door mensen geverifieerde QA-paren die 15 Python-repositories bestrijken. Het combineert uniek multi-hop redenering, kruisbestuivende afhankelijkheden en architecturaal begrip.
2. Flexibele Generatiepijplijn: Een modulair kader dat semi-automatische creatie van QA-datasets voor elke nieuwe open-source repository mogelijk maakt met behulp van zaadtemplates en statische code-analyse.
3. Uitgebreide Evaluatie: Een rigoureuze beoordeling van LLM's onder verschillende contextverrijkingstrategieën (Direct Prompting, RAG, Agent Frameworks).

4. Experimentele Resultaten

De auteurs evalueerden zes geavanceerde LLM's (waaronder GPT-5.1, Gemini 2.5 Pro, GLM-4.6 en Qwen3-Coder) met verschillende strategieën:

• Impact van Contextverrijking:
  • Direct Prompting: Presteerde slecht (bijv. Kimi K2 scoorde ~51/100), wat de noodzaak van repository-context benadrukt.
  • RAG (Sliding Window/Function Chunking): Verbeterde de prestaties aanzienlijk (bijv. +10–14 punten).
  • Agent Frameworks (OpenHands, SWE-agent): Bereikten de beste resultaten door iteratieve redenering en toolgebruik mogelijk te maken. OpenHands met GPT-5.1 behaalde de hoogste score van 70,79/100.
• Modelprestaties:
  • GPT-5.1 en GLM-4.6 (met OpenHands) leidden het veld.
  • Kleinere modellen (bijv. Qwen3-30B) hadden moeite met agent frameworks, presteerden vergelijkbaar met of slechter dan RAG, wat wijst op beperkingen in langetermijngeheugen en toolplanning.
  • Commerciële tools (Cursor, Tongyi Lingma) presteerden concurrerend (69–70), wat end-to-end tool-verrijkte oplossingen valideert.
• Taxonomie-analyse:
  • Modellen excelleerden bij "Waarom"-vragen (Design Rationale) en "Hoe"-vragen met betrekking tot API-ondersteuning, waar informatie vaak expliciet staat in docstrings.
  • Modellen hadden moeite met "Wat"-vragen (Architectuuroverzicht) en "Waar"-vragen (Feature location), die vereisen dat verspreide logica over bestanden wordt gereconstrueerd.
• Generalisatie over Repositories:
  • De prestaties varieerden per complexiteit van de repository. "Flask" was het makkelijkst (75,42), terwijl "Pylint" (62,01) en "Conan" (64,51) het meest uitdagend waren.
  • Repositories uit SWE-Bench-Live (minder datalek) waren moeilijker dan die uit SWE-Bench.

5. Betekenis en Toekomstige Richtingen

• Realistische Evaluatie: SWE-QA gaat verder dan snippet-level testen om het begrip van de "hele repository" te evalueren dat vereist is voor software-engineeringtaken in de echte wereld.
• Agent Frameworks: De resultaten suggereren dat, hoewel RAG helpt, agent-gebaseerde frameworks momenteel de meest effectieve aanpak zijn voor het navigeren door complexe, multi-file codebases, ondanks hogere tokenkosten.
• Beperkingen: De benchmark is momenteel uitsluitend Python-gebaseerd en gebaseerd op statische snapshots. Toekomstig werk richt zich op uitbreiding naar andere talen en dynamische, evoluerende repositories.
• Open Uitdagingen: Het paper benadrukt dat LLM's nog steeds worstelen met diepe dependency-tracing en precieze locatieredenering, wat wijst op de behoefte aan betere code-grafintegratie en redeneervermogens.

Het paper concludeert dat LLM's veelbelovend zijn in repository-level QA, vooral wanneer verrijkt met agents, maar dat aanzienlijke uitdagingen blijven bestaan bij het hanteren van complexe, multi-hop afhankelijkheden en architecturale redenering.