SWE-bench: ¿Pueden los modelos de lenguaje resolver problemas reales de GitHub?

El artículo de CodeAct presentó un argumento convincente a favor de Python como el formato de acción adecuado para los agentes de LLM. Pero elegir el formato de acción correcto es solo la mitad del problema: también hay que demostrar que los agentes pueden manejar la complejidad de las tareas del mundo real, no solo benchmarks curados. SWE-bench (arXiv:2310.06770), publicado por Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press y Karthik Narasimhan de Princeton y presentado en el ICLR 2024, es el artículo que obligó al campo a enfrentar esa brecha directamente.

El artículo

"SWE-bench: ¿Pueden los modelos de lenguaje resolver problemas reales de GitHub?" construye un benchmark de 2,294 instancias de tareas extraídas de solicitudes de extracción (pull requests) reales fusionadas en 12 repositorios populares de Python: astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy y xarray. Cada instancia presenta al modelo una instantánea de la base de código y una descripción de un problema de GitHub; el modelo debe producir un parche que haga que un conjunto designado de pruebas que fallaban anteriormente pasen, sin romper las pruebas existentes. El benchmark se construyó extrayendo unas 90,000 PR, filtrando aquellas que resolvían un problema vinculado y añadían nuevas pruebas, y luego verificando las transiciones de aprobado/fallido basadas en la ejecución. Esta construcción disciplinada evita el problema típico de los benchmarks con verdades fundamentales ambiguas o fácilmente manipulables.

Ideas clave

• Claude 2, el modelo con mejor rendimiento al momento de la publicación, resuelve solo el 1.96% de los problemas utilizando la recuperación dispersa BM25, que es el entorno de implementación realista donde el modelo debe encontrar los archivos relevantes por sí mismo.
• Con recuperación de oráculo (donde se le entregan al modelo exactamente los archivos que necesita), Claude 2 mejora al 4.80%, lo que confirma que el cuello de botella es en parte la recuperación, pero principalmente la edición: incluso con un contexto perfecto, las tasas de éxito se mantienen por debajo del 5%.
• GPT-4 resuelve el 0.00% de los problemas con recuperación BM25 (evaluado en un subconjunto del 25% por razones de presupuesto) y el 1.74% con oráculo. La caída de oráculo a BM25 para Claude 2 es grave; para GPT-4 es total.
• Los parches generados son sistemáticamente demasiado cortos: los parches exitosos de Claude 2 promedian 19.6 líneas, frente a las 74.5 líneas de los parches humanos de referencia. Los modelos encuentran correcciones locales simples; los humanos escriben soluciones integrales que abarcan varios archivos.
• Más contexto perjudica activamente. BM25 con 50k tokens recupera más archivos del oráculo que con 13k tokens, pero las tasas de resolución a menudo disminuyen. El efecto "perdido en el medio" (modelos que ignoran evidencia relevante enterrada en contextos largos) es un modo de fallo real y documentado aquí.
• SWE-Llama 13b, ajustado con contextos recuperados por oráculo, alcanza un 4.00% con oráculo pero solo un 0.70% con BM25. Entrenar con un contexto perfecto crea agentes frágiles que colapsan cuando la recuperación es realista.

Qué se mantiene y qué no

La construcción del benchmark es rigurosa. La evaluación basada en la ejecución (pruebas que realmente se corren, pasan o fallan) es la verdad fundamental correcta para las tareas de edición de código. Es objetiva, automatizable y difícil de manipular. La decisión de exigir transiciones de fallo a aprobado (no solo la aplicación exitosa del parche) es particularmente importante: evita parches trivialmente correctos como operaciones nulas o eliminaciones.

Los resultados se han mantenido notablemente bien. SWE-bench se publicó en octubre de 2023 y se convirtió rápidamente en la evaluación de facto para agentes de codificación. La línea base inicial del 1.96% es genuinamente informativa, no seleccionada a dedo. SWE-agent, publicado en 2024 por un grupo relacionado, elevó la cifra al 12.47% mediante el rediseño de la interfaz agente-computadora, una mejora de 6 veces que confirma por sí misma cuánto terreno dejó libre la línea base original.

Dos cosas que el artículo no maneja bien: Primero, el benchmark es solo para Python. Es una necesidad práctica, pero crea un riesgo real de sobreajuste a las convenciones de Python. Segundo, el artículo propone solo líneas base de generación aumentada por recuperación (RAG) y delega explícitamente a trabajos futuros los enfoques basados en agentes. Esa delegación era apropiada en 2023, pero significa que el artículo en sí no proporciona señales sobre qué arquitecturas de agentes ayudan.

El entorno de "oráculo" es también un límite superior más débil de lo que parece. Proporcionar el contexto de archivo perfecto no resuelve la localización del código dentro de esos archivos, y no ayuda con el razonamiento multi-archivo sobre las interacciones entre módulos. Que Claude 2 tenga un 4.8% en el oráculo significa que incluso con los archivos correctos en contexto, el modelo falla el 95% de las veces. El problema no es principalmente la recuperación.

Por qué esto es importante para la IA en finanzas

Beancount es un proyecto de Python alojado en GitHub. Un agente de escritura para Beancount es, en esencia, un agente que necesita superar tareas al estilo de SWE-bench: dado un archivo de libro contable y una instrucción ("añadir esta transacción", "corregir esta discrepancia de saldo"), producir una edición que pase el bean-check sin romper las aserciones existentes.

El fallo de recuperación es directamente análogo al problema de localización en el libro contable. Cuando un usuario dice "corrige la sobreestimación en suministros de oficina del tercer trimestre", el agente debe encontrar primero los asientos relevantes en un archivo que podría contener miles de líneas; la misma tarea de localización de archivos donde BM25 falla en el 40–50% de las instancias de SWE-bench. La degradación por estar "perdido en el medio" se aplica por igual a los archivos .beancount largos, donde los asientos con fechas anteriores tienen la misma probabilidad de ser ignorados.

La asimetría en la longitud del parche es una advertencia práctica. Los modelos parchean de forma demasiado estrecha. En contabilidad, esto se traduce en corregir un asiento mientras se olvida el asiento de contrapartida, o actualizar la línea de gasto dejando obsoleto el saldo acumulado. Un agente de Beancount en producción necesita una capa de validación (bean-check, aserciones de saldo o un paso de conciliación explícito) que obligue al agente a ver la consecuencia completa de su edición, no solo su plausibilidad local.

La brecha entre oráculo y BM25 también es un recordatorio de que la calidad de la recuperación no es separable de la calidad del agente. Un agente que no puede identificar de manera fiable qué cuentas o archivos son relevantes para la pregunta de un usuario fallará en el paso de navegación del libro contable antes de intentar siquiera una edición.

Qué leer a continuación

• SWE-agent (arXiv:2405.15793, NeurIPS 2024): el seguimiento directo; pasa del 1.96% al 12.47% rediseñando la interfaz agente-computadora. Los principios de diseño para la navegación de archivos y la búsqueda de código son directamente aplicables a las herramientas para agentes de Beancount.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489): elimina la complejidad del agente y muestra que una tubería simple de localización + reparación sin andamiaje puede ser competitiva; un contrapunto útil a los enfoques con interfaces pesadas.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560): aborda el problema del contexto largo de frente con una gestión de memoria por niveles; directamente relevante para agentes que deben razonar sobre libros contables de Beancount de varios años.