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

1. Declaración del Problema

Los Modelos de Lenguaje Grandes (LLM) actuales han demostrado promesa en la comprensión de código, pero las evaluaciones existentes (por ejemplo, CoSQA, CodeQA) se centran predominantemente en fragmentos de código aislados, funciones o APIs. Estos enfoques no logran capturar la complejidad de la ingeniería de software del mundo real, donde los desarrolladores deben:

• Navegar por grandes bases de código interconectadas que abarcan múltiples archivos.
• Comprender la arquitectura del software y las razones de diseño.
• Rastrear dependencias de largo alcance y realizar razonamiento de múltiples saltos.
• Sintetizar conocimientos arquitectónicos para responder preguntas complejas de "Por qué" y "Cómo".

Existe una falta de evaluaciones de alta calidad, verificadas por humanos, que evalúen a los LLM en la respuesta a preguntas (QA) a nivel de repositorio, que requieran contexto profundo de múltiples archivos y comprensión estructural.

2. Metodología: Construcción de la Evaluación SWE-QA

Los autores proponen SWE-QA, una evaluación de preguntas y respuestas de código a nivel de repositorio construida mediante un pipeline de cuatro etapas (Figura 2) que involucra 15 repositorios de Python diversos (12 de SWE-Bench, 3 de SWE-Bench-Live).

A. Recolección de Semillas y Construcción de la Taxonomía

• Fuente de Datos: Se rastrearon 77,100 issues de GitHub de 12 repositorios populares.
• Filtrado: Se seleccionaron 41,955 issues con contenido sustancial (>1,000 caracteres) y se utilizó un LLM para extraer 127,415 preguntas explícitas relacionadas con el código.
• Taxonomía: Dos expertos humanos con más de 3 años de experiencia analizaron manualmente 1,000 preguntas muestreadas para crear una taxonomía de dos niveles:
  • Nivel 1 (Interrogativo): Qué, Por qué, Dónde, Cómo.
  • Nivel 2 (Intención): 12 categorías detalladas (por ejemplo, Rastreo de Dependencias, Racional de Diseño, Ubicación de Funcionalidad, Implementación de Algoritmos).
• Distribución: Las preguntas "Cómo" (35.2%) y "Dónde" (28.4%) son las más frecuentes, reflejando la necesidad de conocimiento procedimental y de ubicación.

B. Instanciación de Preguntas

• Extracción de Contexto: Se utilizó tree-sitter para analizar las estructuras de los repositorios en grafos tipificados (nodos: clases, métodos, archivos; aristas: llamadas, importaciones).
• Generación: Se seleccionaron elementos focales (por ejemplo, una clase específica) y se combinó su contexto estructural con plantillas base derivadas de la taxonomía.
• Proceso: Un LLM generó preguntas candidatas adaptadas a repositorios específicos, asegurando que requirieran razonamiento de múltiples saltos y no pudieran responderse mediante una recuperación simple.

C. Recolección y Validación de Respuestas

• Pipeline RAG: Las respuestas se generaron utilizando un enfoque de Generación Aumentada por Recuperación (RAG), recuperando fragmentos de código relevantes, documentación y metadatos.
• Humano en el Bucle:
  • Revisión de Expertos: Dos desarrolladores senior revisaron cada respuesta en cuanto a precisión factual, completitud y claridad utilizando herramientas como Cursor. Los desacuerdos fueron resueltos por un tercer experto.
  • Filtrado de Calidad: Los pares se descartaron si eran ambiguos, factualmente incorrectos o carecían de fundamentación suficiente en el código.
• Conjunto de Datos Final: 720 pares de preguntas y respuestas de alta calidad (48 por repositorio), que abarcan 13,300 archivos y más de 3.4 millones de líneas de código.

3. Contribuciones Clave

1. Evaluación SWE-QA: Una evaluación de preguntas y respuestas a nivel de repositorio con 720 pares verificados por humanos que abarcan 15 repositorios de Python. Combina de manera única el razonamiento de múltiples saltos, las dependencias entre archivos y la comprensión arquitectónica.
2. Pipeline de Generación Flexible: Un marco modular que permite la creación semi-automatizada de conjuntos de datos de preguntas y respuestas para cualquier nuevo repositorio de código abierto utilizando plantillas base y análisis estático de código.
3. Evaluación Exhaustiva: Una evaluación rigurosa de los LLM bajo diversas estrategias de aumento de contexto (Prompting Directo, RAG, Marcos de Agentes).

4. Resultados Experimentales

Los autores evaluaron seis LLM avanzados (incluyendo GPT-5.1, Gemini 2.5 Pro, GLM-4.6 y Qwen3-Coder) utilizando diferentes estrategias:

• Impacto del Aumento de Contexto:
  • Prompting Directo: Rindió pobremente (por ejemplo, Kimi K2 obtuvo ~51/100), destacando la necesidad de contexto de repositorio.
  • RAG (Ventana Deslizante/Fragmentación de Funciones): Mejoró significativamente el rendimiento (por ejemplo, +10–14 puntos).
  • Marcos de Agentes (OpenHands, SWE-agent): Lograron los mejores resultados al permitir razonamiento iterativo y uso de herramientas. OpenHands con GPT-5.1 obtuvo la puntuación más alta de 70.79/100.
• Rendimiento del Modelo:
  • GPT-5.1 y GLM-4.6 (con OpenHands) lideraron el grupo.
  • Los modelos más pequeños (por ejemplo, Qwen3-30B) tuvieron dificultades con los marcos de agentes, rindiendo de manera similar o peor que RAG, lo que sugiere limitaciones en la memoria a largo plazo y la planificación de herramientas.
  • Las herramientas comerciales (Cursor, Tongyi Lingma) rindieron de manera competitiva (69–70), validando soluciones completas aumentadas con herramientas.
• Análisis de la Taxonomía:
  • Los modelos destacaron en preguntas "Por qué" (Racional de Diseño) y "Cómo" relacionadas con el soporte de API, donde la información suele ser explícita en las cadenas de documentación.
  • Los modelos tuvieron dificultades con preguntas "Qué" (Exploración de Arquitectura) y "Dónde" (Ubicación de funcionalidad), que requieren reconstruir lógica dispersa a través de archivos.
• Generalización entre Repositorios:
  • El rendimiento varió según la complejidad del repositorio. "Flask" fue el más fácil (75.42), mientras que "Pylint" (62.01) y "Conan" (64.51) fueron los más desafiantes.
  • Los repositorios de SWE-Bench-Live (con menos filtrado de datos) fueron más difíciles que los de SWE-Bench.

5. Significado y Direcciones Futuras

• Evaluación Realista: SWE-QA va más allá de las pruebas a nivel de fragmento para evaluar la comprensión de "todo el repositorio" requerida para tareas de ingeniería de software del mundo real.
• Marcos de Agentes: Los resultados sugieren que, aunque RAG ayuda, los marcos basados en agentes son actualmente el enfoque más efectivo para navegar bases de código complejas y de múltiples archivos, a pesar de los costos de tokens más altos.
• Limitaciones: La evaluación es actualmente solo de Python y se basa en instantáneas estáticas. El trabajo futuro apunta a extenderse a otros lenguajes y repositorios dinámicos y en evolución.
• Desafíos Abiertos: El artículo destaca que los LLM aún tienen dificultades con el rastreo profundo de dependencias y el razonamiento de ubicación preciso, lo que indica la necesidad de una mejor integración de grafos de código y capacidades de razonamiento.

El artículo concluye que, aunque los LLM muestran promesa en la respuesta a preguntas a nivel de repositorio, particularmente cuando se aumentan con agentes, persisten desafíos significativos en el manejo de dependencias complejas de múltiples saltos y el razonamiento arquitectónico.