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

1. Declaração do Problema

Os Modelos de Linguagem de Grande Escala (LLMs) atuais demonstraram promessa na compreensão de código, mas os benchmarks existentes (por exemplo, CoSQA, CodeQA) focam predominantemente em trechos de código isolados, funções ou APIs. Essas configurações falham em capturar a complexidade da engenharia de software do mundo real, onde os desenvolvedores devem:

• Navegar em grandes bases de código interconectadas que abrangem múltiplos arquivos.
• Compreender a arquitetura de software e as racionalidades de design.
• Rastrear dependências de longo alcance e realizar raciocínio multi-hop.
• Sintetizar conhecimento arquitetural para responder a perguntas complexas do tipo "Por que" e "Como".

Há uma falta de benchmarks de alta qualidade, verificados por humanos, que avaliem LLMs em perguntas e respostas (QA) de nível de repositório, exigindo contexto profundo de múltiplos arquivos e compreensão estrutural.

2. Metodologia: Construção do Benchmark SWE-QA

Os autores propõem o SWE-QA, um benchmark de QA de código em nível de repositório construído através de um pipeline de quatro etapas (Figura 2) envolvendo 15 repositórios Python diversos (12 do SWE-Bench, 3 do SWE-Bench-Live).

A. Coleta de Sementes e Construção de Taxonomia

• Fonte de Dados: 77.100 issues do GitHub foram rastreadas em 12 repositórios populares.
• Filtragem: 41.955 issues com conteúdo substancial (>1.000 caracteres) foram selecionadas e um LLM foi utilizado para extrair 127.415 perguntas explícitas relacionadas a código.
• Taxonomia: Dois especialistas humanos com mais de 3 anos de experiência analisaram manualmente 1.000 perguntas amostradas para criar uma taxonomia de dois níveis:
  • Nível 1 (Interrogativo): O que, Por que, Onde, Como.
  • Nível 2 (Intenção): 12 categorias granulares (por exemplo, Rastreamento de Dependências, Racionalidade de Design, Localização de Funcionalidade, Implementação de Algoritmo).
• Distribuição: Perguntas "Como" (35,2%) e "Onde" (28,4%) são as mais frequentes, refletindo a necessidade de conhecimento procedural e de localização.

B. Instanciação de Perguntas

• Extração de Contexto: O tree-sitter foi utilizado para analisar a estrutura dos repositórios em grafos tipados (nós: classes, métodos, arquivos; arestas: chamadas, imports).
• Geração: Elementos focais (por exemplo, uma classe específica) foram selecionados e seu contexto estrutural foi combinado com modelos de semente derivados da taxonomia.
• Processo: Um LLM gerou perguntas candidatas adaptadas a repositórios específicos, garantindo que exigissem raciocínio multi-hop e não pudessem ser respondidas por simples recuperação.

C. Coleta e Validação de Respostas

• Pipeline RAG: As respostas foram geradas usando uma abordagem de Geração Aumentada por Recuperação (RAG), recuperando trechos de código relevantes, documentação e metadados.
• Humano no Loop:
  • Revisão por Especialistas: Dois desenvolvedores seniores revisaram cada resposta quanto à precisão factual, completude e clareza, utilizando ferramentas como o Cursor. Desacordos foram resolvidos por um terceiro especialista.
  • Filtragem de Qualidade: Pares foram descartados se fossem ambíguos, factualmente incorretos ou carecessem de fundamentação suficiente no código.
• Conjunto de Dados Final: 720 pares QA de alta qualidade (48 por repositório), cobrindo 13.300 arquivos e mais de 3,4 milhões de linhas de código.

3. Principais Contribuições

1. Benchmark SWE-QA: Um benchmark de QA em nível de repositório com 720 pares QA verificados por humanos, abrangendo 15 repositórios Python. Combina de forma única raciocínio multi-hop, dependências entre arquivos e compreensão arquitetural.
2. Pipeline de Geração Flexível: Um framework modular que permite a criação semi-automatizada de conjuntos de dados QA para qualquer novo repositório de código aberto, utilizando modelos de semente e análise estática de código.
3. Avaliação Abrangente: Uma avaliação rigorosa de LLMs sob várias estratégias de aumento de contexto (Prompting Direto, RAG, Frameworks de Agentes).

4. Resultados Experimentais

Os autores avaliaram seis LLMs avançados (incluindo GPT-5.1, Gemini 2.5 Pro, GLM-4.6 e Qwen3-Coder) usando diferentes estratégias:

• Impacto do Aumento de Contexto:
  • Prompting Direto: Desempenhou mal (por exemplo, Kimi K2 pontuou ~51/100), destacando a necessidade de contexto de repositório.
  • RAG (Janela Deslizante/Fragmentação de Função): Melhorou significativamente o desempenho (por exemplo, +10–14 pontos).
  • Frameworks de Agentes (OpenHands, SWE-agent): Alcançaram os melhores resultados, permitindo raciocínio iterativo e uso de ferramentas. OpenHands com GPT-5.1 alcançou a pontuação mais alta de 70,79/100.
• Desempenho do Modelo:
  • GPT-5.1 e GLM-4.6 (com OpenHands) lideraram o grupo.
  • Modelos menores (por exemplo, Qwen3-30B) lutaram com frameworks de agentes, performando de forma similar ou pior que o RAG, sugerindo limitações em memória de longo prazo e planejamento de ferramentas.
  • Ferramentas comerciais (Cursor, Tongyi Lingma) performaram de forma competitiva (69–70), validando soluções aumentadas por ferramentas de ponta a ponta.
• Análise de Taxonomia:
  • Os modelos se destacaram em perguntas "Por que" (Racionalidade de Design) e "Como" relacionadas ao suporte de API, onde a informação é frequentemente explícita em docstrings.
  • Os modelos tiveram dificuldade com perguntas "O que" (Exploração de Arquitetura) e "Onde" (Localização de Funcionalidade), que exigem reconstruir lógica dispersa entre arquivos.
• Generalização entre Repositórios:
  • O desempenho variou conforme a complexidade do repositório. "Flask" foi o mais fácil (75,42), enquanto "Pylint" (62,01) e "Conan" (64,51) foram os mais desafiadores.
  • Repositórios do SWE-Bench-Live (com menos vazamento de dados) foram mais difíceis do que os do SWE-Bench.

5. Significado e Direções Futuras

• Avaliação Realista: O SWE-QA vai além do teste em nível de trecho para avaliar a compreensão de "repositório inteiro" necessária para tarefas de engenharia de software do mundo real.
• Frameworks de Agentes: Os resultados sugerem que, embora o RAG ajude, frameworks baseados em Agentes são atualmente a abordagem mais eficaz para navegar em bases de código complexas e multi-arquivo, apesar dos custos mais altos de tokens.
• Limitações: O benchmark é atualmente apenas em Python e baseado em instantâneos estáticos. Trabalhos futuros visam estender para outras linguagens e repositórios dinâmicos e em evolução.
• Desafios Abertos: O artigo destaca que os LLMs ainda lutam com rastreamento profundo de dependências e raciocínio de localização preciso, indicando a necessidade de melhor integração de grafos de código e capacidades de raciocínio.

O artigo conclui que, embora os LLMs mostrem promessa em QA de nível de repositório, particularmente quando aumentados com agentes, desafios significativos permanecem no manuseio de dependências complexas, multi-hop e raciocínio arquitetural.