Resumen Técnico: SHERLOC – Localización de Diagnóstico Estructurado para Agentes de Reparación de Código

1. Planteamiento del Problema

La reparación de código a nivel de repositorio depende cada vez más de agentes de Modelos de Lenguaje de Gran Escala (LLM) que intercalan el razonamiento con llamadas a herramientas estructuradas para resolver problemas de GitHub. Sin embargo, un análisis sistemático de los agentes existentes revela una ineficiencia crítica: los agentes dedican casi la mitad de su presupuesto de interacción (un promedio de 18.5 turnos y más de 320k tokens por instancia) únicamente a la localización de fallos antes de intentar un parche de código.

Los métodos de localización actuales sufren dos limitaciones primarias:

1. Salida Incompleta: La mayoría de los enfoques recuperan archivos o funciones defectuosos, pero no proporcionan el contexto diagnóstico (causa raíz, dirección de la solución) necesario para que los agentes de reparación posteriores actúen de manera efectiva.
2. Desajuste de Evaluación: Los marcos de localización dedicados a menudo se evalúan como sistemas de recuperación de archivos en lugar de herramientas de diagnóstico accionables, produciendo localizaciones sin el razonamiento requerido para la reparación.

Esto crea un cuello de botella de rendimiento donde se consumen recursos computacionales significativos en la búsqueda en lugar de la construcción, y las localizaciones resultantes suelen carecer de la especificidad necesaria para guiar la reparación.

2. Metodología: SHERLOC

Los autores presentan SHERLOC (Exploración y Razonamiento Basado en Hipótesis Estructuradas para la Localización), un marco libre de entrenamiento diseñado para emparejar un LLM de razonamiento con un conjunto compacto de herramientas de repositorio y mecanismos de autorrecuperación.

Arquitectura Central

SHERLOC opera como un único LLM de razonamiento que interactúa con un ejecutor de herramientas determinista a través de un bucle iterativo acotado (máximo 20 turnos). No requiere ajuste fino (fine-tuning), aprendizaje por refuerzo ni orquestación multi-agente.

• Conjunto de Herramientas: El marco utiliza cuatro herramientas amigables para LLM:
  • View File (Ver Archivo): Inspecciona el contenido de los archivos con coincidencia difusa de rutas y rangos de líneas opcionales.
  • Codebase Search (Búsqueda en la Base de Código): Realiza búsquedas literales en todo el repositorio con contexto.
  • Repository Tree (Árbol del Repositorio): Muestra la jerarquía de archivos filtrada para recuperar el contexto global.
  • Connected Tree (Árbol Conectado): Resume las relaciones de importación (directas e inversas) para navegar por las dependencias.
• Interacción Iterativa: El modelo alterna entre el razonamiento y la selección de herramientas. Acumula observaciones (fragmentos, rutas, resúmenes de dependencias) en su historial de contexto para formar un estado de hipótesis.
• Mecanismos de Autorrecuperación: Para estabilizar el uso extendido de herramientas, SHERLOC emplea estrategias de recuperación ligeras:
  • Truncamiento de contexto (preservando el prompt inicial y los turnos recientes).
  • Detección de bucles (advertencia contra llamadas repetitivas improductivas).
  • Recuperación implícita de llamadas a herramientas (procesamiento de solicitudes malformadas pero inequívocas).
  • Síntesis de turno final (forzando una conclusión cuando se agota el presupuesto de pasos).

Salida de Diagnóstico Estructurada

A diferencia de los métodos anteriores que solo devuelven rutas de archivos, SHERLOC emite un hallazgo de diagnóstico estructurado para cada ubicación predicha. Este hallazgo incluye cinco campos:

1. Explicación de la Ubicación: Por qué se sospecha del archivo.
2. Causa Raíz: El mecanismo subyacente del error.
3. Idea de Solución: Guía accionable para la corrección (sin código).
4. Dependencias: Impacto en otros módulos.
5. Impacto en Pruebas: Modificaciones de prueba sugeridas.

Métricas de Evaluación

El artículo propone métricas de nivel de fragmento (chunk-level) agnósticas a la estructura (recuperación de cobertura, precisión y estrechez promedio) sobre los rangos de número de línea, reconociendo que los parches no siempre se alinean con unidades sintácticas como funciones o clases.

3. Resultados Clave

Rendimiento de Localización

SHERLOC logra el estado del arte (SOTA) en localización a nivel de archivo a través de diversas escalas de modelos sin entrenamiento específico de la tarea:

• SWE-Bench Lite: 84.33% de precisión@1 (usando Qwen3-235B).
• SWE-Bench Verified: 81.27% de recuperación@1 (usando Qwen3-235B).
• Eficiencia de Escala: A una escala de ~30B de parámetros comparables, SHERLOC (Qwen3-30B) alcanza un 75.07% de recuperación@1, superando significativamente a los baselines ajustados (ej. ToolTrain-32B) y a los métodos sin ajuste fino (por +7.0 a +18.3 pp).
• Transferencia entre Familias: El método se transfiere eficazmente entre familias de modelos (ej. DeepSeek-V3 alcanza 79.53% de recuperación@1).

Transferencia de la Localización a la Reparación de Código

La inyección de las localizaciones y los hallazgos de diagnóstico de SHERLOC en los agentes de reparación existentes (OpenHands y SWE-Agent) produce mejoras significativas:

• Tasa de Resolución: Un aumento promedio de +5.95 puntos porcentuales en la tasa de resolución en cinco backbones de reparación.
• Eficiencia: Una reducción del 36.7% en los tokens de localización y una reducción del 23.1% en el total de tokens.
• Mediación de Calidad: El beneficio de transferencia depende de la calidad. Los modelos más pequeños se benefician de "Todos los hallazgos de SHERLOC", mientras que los modelos más grandes y capaces se benefician más de los Hallazgos filtrados por calidad (aquellos calificados con ≥4.0 por un juez LLM). Los hallazgos no filtrados pueden degradar el rendimiento en agentes fuertes debido a la transferencia negativa de diagnósticos de baja confianza.

Estudios de Ablación y Validez

• Importancia de los Componentes: Eliminar la herramienta View File o el prompt de turno final causa las mayores caídas de rendimiento, confirmando que la inspección de código y la presión de síntesis son críticas.
• Conocimiento Implícito vs. Razonamiento: Los controles que enmascaran las rutas de archivos en el texto del problema muestran que, si bien los LLM poseen familiaridad implícita con repositorios populares (ej. scikit-learn, requests), la exploración activa asistida por herramientas explica una parte significativa de la brecha de rendimiento (aprox. 22 pp de mejora sobre los baselines de solo texto).
• Necesidad de Razonamiento: Los modelos en modo "Thinking" (pensamiento) superan significativamente a los modelos en modo "Instruct", que a menudo fallan al mantener el protocolo de múltiples turnos.

4. Significación y Reivindicaciones

El artículo argumenta que la salida de diagnóstico estructurada, y no simplemente la recuperación de la ubicación, es la unidad operativa de una localización útil. Una ruta de archivo correcta con un diagnóstico erróneo puede confundir a los agentes posteriores, mientras que un hallazgo estructurado con análisis de causa raíz y guía de solución permite una reparación efectiva.

Las reivindicaciones clave incluyen:

1. SOTA Libre de Entrenamiento: Un único LLM de razonamiento con herramientas compactas y autorrecuperación puede igualar o exceder los sistemas de localización especializados y ajustados.
2. Contexto Accionable: La inclusión de campos de diagnóstico estructurados (causa raíz, idea de solución) es esencial para transferir el éxito de la localización a las tareas de reparación posteriores.
3. Eficiencia: SHERLOC reduce drásticamente el costo de tokens de la fase de localización, liberando presupuesto para la reparación real del código.
4. Filtrado de Calidad: Un filtro de calidad es necesario para evitar la transferencia negativa; los hallazgos de alta calidad impulsan el éxito, mientras que los de baja calidad pueden ser perjudiciales.

Los autores concluyen que la localización debe evaluarse mediante la accionabilidad diagnóstica en lugar de solo la precisión de la recuperación de archivos. Señalan que, aunque sus resultados son sólidos, están parcialmente confundidos por la familiaridad del preentrenamiento de los LLM con repositorios públicos, y que el trabajo futuro requiere distribuciones de repositorios no vistos para una evaluación limpia. El marco es de diseño agnóstico al lenguaje, aunque sus herramientas actuales dependen de analizadores específicos de lenguaje para los árboles de importación.