Resumen Técnico: Dialogue-SWEBench

Planteamiento del Problema

Los benchmarks actuales para agentes de codificación, como SWE-Bench, evalúan los sistemas en un entorno totalmente autónomo donde los agentes reciben una especificación de problema completa y correcta desde el inicio. Este enfoque no logra capturar la naturaleza interactiva de la ingeniería de software en el mundo real, donde los usuarios participan frecuatamente en diálogos para corregir, rechazar o aclarar las salidas del agente. Los estudios indican que los usuarios corrigen las salidas de los agentes el 44% de las veces, sin embargo, los agentes rara vez buscan aclaraciones (1-2%). Además, los benchmarks existentes suelen presuponer que hay una especificación perfecta disponible, mientras que los problemas del mundo real son frecuentemente subespecificados o vagos. En consecuencia, existe una brecha significativa entre las métricas de evaluación actuales y las capacidades reales requeridas para agentes de codificación interactivos y basados en el diálogo.

Metodología

Benchmark Dialogue-SWEBench

Los autores presentan Dialogue-SWEBench, un benchmark diseñado para evaluar la capacidad de los agentes de codificación para resolver problemas de ingeniería de software (SWE) del mundo real estrictamente a través del diálogo con un usuario. El benchmark se construye reformulando tareas de SWE-Bench Verified:

• Transformación de Entrada: En lugar de proporcionar el texto completo del problema como una especificación estática, la tarea comienza con una consulta inicial fija ($u_1$) que refleja la intención del usuario pero omite detalles críticos necesarios para la resolución.
• Bucle Interactivo: Los agentes operan en un entorno donde pueden realizar acciones estándar de codificación (editar archivos, ejecutar pruebas) y una nueva acción message_user. Esta acción permite al agente consultar al usuario, recibiendo una respuesta simulada como una observación.
• Terminación: El bucle termina cuando el agente emite una acción finish, enviando un parche de git. El éxito se determina por si el parche pasa todas las pruebas de ejecución asociadas.

Simulador de Usuario

Para garantizar una evaluación fiel y reproducible, los autores diseñaron un simulador de usuario basado en personas utilizando un modelo LLaMa 3.3 70B cuantizado.

• Fundamentación de Conocimiento: El simulador está condicionado al texto original completo del problema de GitHub ($I_{text}$), pero tiene restringido el acceso al repositorio de código o la ejecución de código por sí mismo. Debe actuar como un usuario que conoce el problema pero no puede implementar la solución.
• Mecanismo de Autorrevisión: Para evitar alucinaciones y mantener las restricciones del entorno (por ejemplo, que el usuario no puede ejecutar código), el simulador emplea un paso de autorrevisión. Se genera una respuesta de usuario candidata, validada por el mismo LLM para detectar violaciones (como afirmar que se ejecuta código o romper el personaje), y se revisa si es necesario antes de ser devuelta al agente.
• Personas: Para aumentar la diversidad del diálogo, a cada problema se le asigna una persona de usuario específica (por ejemplo, "cauteloso", "perfeccionista", "pragmático") que influye en el tono y el comportamiento de las respuestas simuladas.

Agente Guiado por Esquemas

Los autores proponen un nuevo agente de codificación guiado por esquemas para mejorar el rendimiento del diálogo. Este agente utiliza prompts para mantener una representación interna estructurada (un "esquema") del estado del diálogo.

• Flujo de Trabajo: El agente primero determina el tipo de problema (por ejemplo, error o característica) y redacta un esquema con claves para detalles críticos (por ejemplo, "comportamiento esperado", "pasos de reproducción").
• Gestión de Estado: Los valores se marcan como UNKNOWN (desconocido) hasta que se discuten. Se instruye al agente para que llene estos vacíos mediante el diálogo antes de proceder a la exploración de código y la generación de parches. Esta estructura está diseñada para guiar al agente en la realización de preguntas dirigidas y de búsqueda de información en lugar de hacer suposiciones.

Métricas de Evaluación

• Tasa de Resolución: La métrica principal es el porcentaje de diálogos que resultan en un parche que pasa todas las pruebas de ejecución.
• Calidad del Diálogo: Los autores introducen evaluaciones automáticas para la Naturalidad (facilidad de comprensión) y la Coherencia (progresión lógica hacia la solución) utilizando un LLM-as-a-Judge (Gemma 4 31B-IT), validado contra anotaciones humanas.

Contribuciones Clave

1. Dialogue-SWEBench: Un conjunto de datos de benchmark que transforma 500 problemas de SWE del mundo real en tareas interactivas impulsadas por el diálogo, donde los agentes deben resolver problemas sin una especificación inicial completa.
2. Simulador de Usuario: Un novedoso simulador de código abierto, basado en personas y con un mecanismo de autorrevisión, para producir respuestas de usuario realistas y conformes a las restricciones para la evaluación en línea.
3. Agente Guiado por Esquemas: Una nueva arquitectura de agente que utiliza esquemas de diálogo para rastrear explícitamente la información faltante, lo que resulta en un mejor rendimiento sobre las líneas base fuertes.
4. Evaluación Automática de Diálogo: Un marco de trabajo de LLM-as-a-Judge para evaluar la naturalidad y la coherencia de los diálogos de los agentes de codificación.

Resultados

Los autores evaluaron modelos de vanguardia tanto cerrados (GPT-5, GPT-5-mini) como de pesos abiertos (Qwen 3 Coder, Devstral 2 Small) utilizando tres configuraciones de agentes: OpenHands (estándar), OH Interactive (línea base para resolución de ambigüedad) y su propuesto Agente Guiado por Esquemas.

• Rendimiento: El agente guiado por esquemas logró la tasa de resolución promedio más alta (46.9%) en todos los modelos, superando a OpenHands (32.9%) y a OH Interactive (44.1%). Logró esto con el costo promedio más bajo.
• Capacidad de Diálogo vs. Codificación: Los resultados indican que los modelos de codificación más fuertes no necesariamente se traducen en mejores agentes de diálogo. Por ejemplo, GPT-5-mini a menudo igualó o superó a la versión más grande, GPT-5, en tasas de resolución, incurriendo en una fracción del costo y produciendo diálogos más naturales.
• Búsqueda de Información: Existe una fuerte correlación entre el número de movimientos de diálogo de búsqueda de información y las tasas de resolución. El agente guiado por esquemas utilizó consistentemente más movimientos de búsqueda de información que las líneas base, lo cual fue crítico para el éxito.
• Estudios de Ablación: Eliminar el simulador de usuario (forzando la resolución de un solo turno) redujo drásticamente el rendimiento (por ejemplo, GPT-5-mini cayó de 68.0% a 40.0%), confirmando que el diálogo de múltiples turnos es esencial para resolver estas tareas.
• Análisis de Calidad: Aunque GPT-5 logró una alta resolución en tareas difíciles, sufrió de puntuaciones de naturalidad más bajas debido a la verbosidad y la repetición. El enfoque guiado por esquemas generalmente mejoró la coherencia.

Significancia

El artículo argumenta que la capacidad de diálogo es una dimensión distinta y actualmente subestudiada del rendimiento de los agentes de codificación. Los hallazgos sugieren que simplemente escalar los modelos de codificación o proporcionar mejores especificaciones es insuficiente para el despliegue en el mundo real. En su lugar, la capacidad de participar en un diálogo de múltiples turnos y de búsqueda de información es un factor crítico para resolver problemas de ingeniería de software del mundo real. Los autores postulan que la investigación futura debe abordar la intersección de las capacidades de codificación y de diálogo para construir agentes que puedan colaborar eficazmente con usuarios humanos, en lugar de operar como sistemas totalmente autónomos y dependientes de una especificación.