Resumen Técnico: Socratic-SWE

Planteamiento del Problema

Los agentes de ingeniería de software (SWE) impulsados por modelos de lenguaje de gran tamaño (LLM) han emergido como un punto de referencia crítico para la inteligencia en el mundo real, requiriendo una interacción de largo horizonte con repositorios de código para la localización, reparación y verificación de errores. Sin embargo, el entrenamiento de estos agentes se ve obstaculizado por la escasez de tareas de SWE de alta calidad. Los métodos de generación de datos sintéticos existentes suelen depender de la mutación estática, la inyección de errores o procedimientos de reescritura fijos. Estos enfoques generan distribuciones de tareas que son independientes del propio progreso de entrenamiento del agente y de sus debilidades específicas, lo que conduce a un desalineamiento entre el currículo y las brechas de capacidad reales del modelo. Además, si bien el entrenamiento mediante aprendizaje por refuerzo (RL) produce "trazas de resolución" valiosas (registros del comportamiento del agente, uso de herramientas y fallos), los métodos actuales descartan estas trazas tras extraer recompensas escalares, fallando en su capacidad para utilizar estas trazas para evolucionar el currículo de entrenamiento.

Metodología: Socratic-SWE

Los autores proponen Socratic-SWE, un marco de trabajo de ciclo cerrado y autoevolutivo que transforma las trazas de resolución históricas en señales de entrenamiento estructuradas. El sistema opera a través de un bucle de coevolución que involucra una política compartida $\pi_\theta$ que alterna entre dos roles: un Generador y un Solucionador (Solver).

1. Registro de Habilidades del Agente (Destilación de Trazas)

En lugar de descartar las trazas, Socratic-SWE las destila en un Registro de Habilidades del Agente ($S$). Este proceso implica tres etapas:

• Recolección de Trazas: El Solucionador interactúa con repositorios semilla, generando un corpus de trazas ($T$), que incluye trayectorias tanto exitosas como fallidas.
• Extracción de Habilidades: Un modelo de destilación ($M_{distill}$) analiza estas trazas para identificar patrones de comportamiento recurrentes. Para las trazas exitosas, extrae estrategias generalizables; para las fallidas, resume los modos de fallo y los principios correctivos.
• Construcción del Registro: Las habilidades candidatas se deduplican y filtran para formar un registro estructurado. Cada habilidad es un documento estructurado que contiene un nombre, descripción, condiciones de aplicabilidad y una lista ordenada de operaciones.

2. Generación de Tareas Guiada por Habilidades

El rol del Generador utiliza el Registro de Habilidades del Agente para construir tareas de reparación dirigidas en repositorios de código reales.

• Propuestas Adaptativas: El Generador muestrea una habilidad $s \in S$ y un repositorio $r$ para proponer una tarea $\tau$ y una señal de verificación $v$. Este proceso está condicionado por la evidencia ($E_t$) recopilada de la ejecución previa del Solucionador, asegurando que las tareas apunten a las brechas de capacidad actuales.
• Validación por Etapas: Las tareas candidatas se someten a un flujo de validación basado en la ejecución de cuatro etapas en un entorno de sandbox:
  1. Formato: Validez sintáctica.
  2. Fundamentación (Grounding): Verificación de que los artefactos de la tarea existen en el repositorio.
  3. Ejecución: Estabilidad y reproducibilidad de la suite de verificación.
  4. Semántica: Confirmación de que la tarea distingue entre estados de fallo y de reparación.
• Recompensa Consciente del Gradiente: Para asegurar que las tareas no sean solo válidas sino también útiles, el Generador es recompensado basándose en la alineación del gradiente del solucionador. El sistema calcula una dirección de gradiente objetivo ($G_v$) a partir de un conjunto de tareas de validación de confianza reservado. La recompensa para una tarea candidata es la similitud de coseno entre el gradiente del solucionador inducido por la tarea ($g_\tau$) y $G_v$. Esto prioriza las tareas que impulsan al solucionador en una dirección consistente con las mejoras de confianza.

3. Solucionador de Reparación de Repositorio

El rol del Solucionador entrena sobre el currículo aceptado de tareas. Interactúa con el sandbox del repositorio para generar parches. La función de recompensa ($r_S$) es de múltiples componentes, recompensando:

• El paso de la suite completa (todas las pruebas pasan).
• Tasas de reparación parcial.
• Evitación de regresiones (preservación de las pruebas originalmente aprobadas).
  El Solucionador se optimiza utilizando GDPO (Optimización de Política Directa Agrupada) para manejar eficazmente los componentes heterogéneos de la recompensa.

Contribuciones Clave

1. Paradigma de Autoevolución Impulsado por Trazas: El artículo demuestra que las trazas de resolución, que normalmente se descartan tras la computación de la recompensa, pueden servir como un sustrato reutilizable para agentes autoevolutivos. Socratic-SWE convierte el comportamiento histórico en habilidades estructuradas que guían un bucle cerrado de traza-habilidad-tarea.
2. Optimización de Currículo Consciente del Gradiente: Los autores introducen un mecanismo de currículo que combina la generación condicionada por habilidades con la validación basada en la ejecución y una recompensa de alineación de gradiente del solucionador. Esto asegura que las tareas generadas sean tanto verificables como alineadas con las direcciones de mejora de confianza.
3. Desempeño Empírico Superior: El marco logra resultados de vanguardia entre los baselines de autoevolución bajo un presupuesto de cómputo idéntico, demostrando una fuerte capacidad de autoevolución y transferencia.

Resultados Experimentales

El marco fue evaluado en cuatro benchmarks: SWE-bench Verified, SWE-bench Lite, SWE-bench Pro y Terminal-Bench 2.0. Los experimentos utilizaron un presupuesto de cómputo fijo de 36,000 instancias de entrenamiento (12k por iteración durante 3 iteraciones) y se compararon contra cinco baselines de autoevolución (SPIRAL, R-Zero, Absolute-Zero, Socratic-Zero, SSR) y un agente base.

• Desempeño: Tras tres iteraciones, Socratic-SWE alcanzó un 50.40% en SWE-bench Verified, una mejora de +7.80 puntos sobre el agente base y +3.40 sobre el baseline más fuerte (SSR). También alcanzó un 36.67% en Lite, 22.85% en Pro y 14.61% en Terminal-Bench 2.0.
• Escalabilidad: A diferencia de los baselines que se estancan o retroceden después de 2 iteraciones, Socratic-SWE mostró ganancias consistentes a través de la tercera iteración. La escalabilidad extendida a 5 iteraciones mostró que alcanza un techo más alto (52.00%) en comparación con SSR (48.00%).
• Estudios de Ablación: Eliminar el Registro de Habilidades causó la mayor caída de rendimiento (-4.20 puntos), confirmando que el diseño de currículo guiado por habilidades es el principal motor. Reemplazar la destilación de trazas con habilidades manuales o utilizar GRPO estándar en lugar de GDPO también resultó en una degradación significativa.

Significado y Reivindicaciones

El artículo afirma que Socratic-SWE proporciona un sustrato escalable para agentes de SWE autoevolutivos al aprovechar sus propias trazas de resolución para adaptar continuamente su currículo de entrenamiento. Los autores argumentan que este enfoque supera las limitaciones de la síntesis de datos estática y agnóstica al modelo mediante la creación de un bucle dinámico y consciente del modelo donde:

• Las trazas se transforman en habilidades.
• Las habilidades guían la generación de tareas dirigidas.
• Las tareas generadas producen nuevas trazas para una mayor evolución.

Los resultados sugieren que las trazas de resolución contienen suficiente señal para impulsar una mejora continua sin anotación externa, retrasando efectivamente la saturación de las curvas de aprendizaje observadas en otros métodos de auto-juego. El marco es particularmente efectivo porque utiliza los modos de fallo ricos y diagnosticables inherentes a las trazas de SWE, combinados con una verificación determinista basada en la ejecución.

Limitaciones

Los autores reconocen varias limitaciones:

• Entorno de Mundo Cerrado: La evaluación depende de un conjunto fijo de repositorios semilla. A medida que el Registro de Habilidades se vuelve más completo, el sistema enfrenta rendimientos decrecientes debido a la redundancia de las señales de entrenamiento.
• Dependencia de la Validación: El método depende de un conjunto de validación reservado para definir la recompensa de alineación de gradiente del generador, lo que puede limitar la robustez si la distribución de validación no representa el entorno de despliegue objetivo.
• Requisitos de Ejecución: El enfoque asume una verificación ejecutable e interacción en sandbox, lo que significa que las ganancias pueden no transferirse directamente a entornos que carecen de pruebas fiables o ejecución determinista.
• Alcance: La evaluación se limita actualmente a benchmarks específicos de SWE y agentes de terminal; aún debe establecerse una transferencia más amplia a otros lenguajes o flujos de trabajo.