🤖 AI

How Do LLMs Read Bug Reports? An Empirical Study of Attention in LLMs for Automated Program Repair

Este artículo presenta el primer estudio empírico que demuestra que la reparación automática de programas basada en LLM exitosa depende de una atención difusa a través de diversos componentes de diagnóstico en los informes de errores, mientras que los fallos son causados por una atención sobrelocalizada en los metadatos, destacando la asignación incorrecta de la atención como un factor clave en la inconsistencia de la reparación.

Autores originales: Ramtin Ehsani, Irene Manotas, Saurabh Pujar, Luca Buratti, Preetha Chatterjee

Publicado 2026-07-29

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Ramtin Ehsani, Irene Manotas, Saurabh Pujar, Luca Buratti, Preetha Chatterjee

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

El dilema del detective: Por qué la IA a veces pierde las pistas

Imagina que eres un detective intentando resolver un misterio. Tienes un cuaderno lleno de pistas: el relato de un testigo, una foto borrosa, una lista de sospechosos y un mapa de la escena del crimen. Para resolver el caso, necesitas leer cada página, conectar los puntos y determinar qué pista es realmente importante. Ahora, imagina que contratas a un robot detective superinteligente para que haga el mismo trabajo. Le entregas el cuaderno y, al instante, escribe una solución. Pero aquí está lo extraño: a veces el robot resuelve el misterio perfectamente y otras veces falla por completo, ¡incluso cuando le das exactamente el mismo cuaderno!

Este es el mundo de los Modelos de Lenguaje de Gran Tamaño (LLM) y la Reparación Automática de Programas. Los LLM son como esos robots superinteligentes; son sistemas de IA entrenados con cantidades mascasivas de texto y código. Pueden escribir historias, responder preguntas e incluso corregir errores (bugs) en programas informáticos. La "Reparación Automática de Programas" es solo un término elegante para pedirle a la IA que observe una pieza de software averiada y una descripción del problema, y luego escriba el código para arreglarlo. Pero los desarrolladores han notado algo frustrante: estos detectives de IA son inconsistentes. Pueden arreglar un error fácilmente, pero fallar en uno casi idéntico situado justo al lado. Los científicos quieren saber: ¿Por qué? ¿Está la IA simplemente adivinando, o está mirando las pistas equivocadas? Este artículo se sumerge en el "cerebro" de la IA para ver exactamente a qué presta atención cuando intenta reparar un programa averiado.

El gran descubrimiento del artículo: Dónde mira la IA importa

En este estudio, los investigadores decidieron jugar a un juego de "encuentra las diferencias" con la atención de la IA. Tomaron 319 errores del mundo real de proyectos de software populares (escritos en Python y Java) y pidieron a tres modelos de IA diferentes que los arreglaran. Algunos modelos eran los grandes, costosos y de acceso cerrado (como el propietario claude-4-sonnet), y otros eran modelos de código abierto (como gpt-oss-20b y qwen-3-32b).

Para descubrir en qué estaba pensando la IA, los investigadores utilizaron un truco ingenioso llamado análisis de perturbación. Imagina que tienes una receta para un pastel y quieres saber qué ingrediente es el más importante. Podrías intentar hornear el pastel sin la harina, luego sin el azúcar, y ver cuál de los dos arruina más el pastel. Los investigadores hicieron lo mismo con los informes de errores. Tomaron un informe de error —que suele tener secciones como "Qué salió mal", "Cómo hacer que falle de nuevo", "Qué versión del software se utilizó" y "Cómo se ve el código"— y eliminaron secretamente una sección a la vez. Luego, le pidieron a la IA que intentara arreglar el error nuevamente. Si la solución de la IA cambiaba mucho tras eliminar una sección, eso significaba que la IA estaba prestando mucha atención a esa parte. Si la solución se mantenía igual, la IA no le daba importancia a esa parte.

Los patrones de atención "Difusa" vs. "Localizada"

Los investigadores descubrieron dos formas muy diferentes en las que la IA observaba las pistas, y estos patrones les dijeron todo sobre si la reparación funcionaría.

1. El detective "Difuso" (El ganador):
Cuando la IA tenía éxito, actuaba como un detective meticuloso. Distribuía su atención en muchas partes diferentes del informe de error. Observaba la descripción del error (la historia de lo que salió mal), el stacktrace (el registro técnico de error que señala la línea exacta de código) y los casos de prueba (ejemplos de cómo debería comportarse el código). Los investigadores llaman a esto atención difusa. Era como si la IA estuviera leyendo todo el cuaderno, conectando la historia del testigo con el mapa y la foto.

El resultado: Cuando la IA hacía esto, tenía muchas más probabilidades de arreglar el error. De hecho, el estudio encontró que la "atención difusa" estaba fuertemente vinculada al éxito.

2. El detective con "Visión de Túnel" (El perdedor):
Cuando la IA fallaba, actuaba como un detective con visión de túnel. Se obsesionaba con un detalle diminuto e insignificante e ignoraba todo lo demás. A menudo, se fijaba en la información de la versión (como "Software Versión 1.2.3" o "Sistema Operativo: Linux"). Esto es como un detective que ignora el arma del crimen y al testigo, y en su lugar pasa todo su tiempo observando la talla de zapato del sospechoso.

El resultado: Cuando la IA se centraba demasiado en estos detalles de metadatos aburridos, generalmente fallaba al arreglar el error. El estudio mostró que la "atención localizada" (centrarse en una sola cosa) era una señal clara de que la reparación fallaría.

¿Coinciden la IA y los humanos en lo que es importante?

Los investigadores también querían saber si la IA estaba mirando las mismas pistas que miran los desarrolladores humanos. Para averiguarlo, pidieron a cuatro desarrolladores experimentados que leyeran 100 de los mismos informes de error y marcaran las partes que consideraban más importantes.

Los resultados fueron una mezcla de buenas y malas noticias:

Las buenas noticias: Cuando la IA tenía éxito, normalmente estaba mirando las mismas secciones que los humanos consideraban importantes. La IA y los humanos coincidían en las pistas principales (como la descripción del error) aproximadamente el 54% de las veces.
Las malas noticias: Cuando la IA fallaba, a menudo ignoraba las pistas principales de los humanos y se centraba en cosas erróneas (como los números de versión). El estudio encontró que cuanto más coincidía la atención de la IA con la atención humana, mayor era la probabilidad de una reparación exitosa.

Lo que el artículo descarta

Es importante señalar lo que este estudio no encontró. Los investigadores comprobaron si la dificultad del error era la razón principal del fallo. Analizaron errores "Fáciles", "Medios" y "Difíciles". Descubrieron que, si bien los errores más difíciles eran efectivamente más complicados de arreglar, la dificultad del error por sí sola no explicaba por qué la IA fallaba. Incluso en errores fáciles, la IA podía fallar si tenía "visión de túnel" e ignoraba las pistas correctas. Esto sugiere que el problema no es solo que los errores sean demasiado difíciles; el problema es que la IA a veces está mirando en el lugar equivocado.

La conclusión

Este artículo sugiere que el secreto para hacer que la IA sea mejor arreglando código no es solo darle más datos o hacerla más inteligente. Se trata de enseñarle cómo leer. El estudio demuestra que las reparaciones exitosas ocurren cuando la IA distribuye su atención por toda la historia —los síntomas, los registros de error y el comportamiento esperado— en lugar de quedarse estancada en detalles aburridos como las versiones de software.

Al comprender que la IA puede sufrir de "visión de túnel", los desarrolladores pueden ahora diseñar mejores instrucciones (prompts) para obligar a la IA a mirar las pistas correctas. Es como enseñar a un detective a dejar de mirar los zapatos del sospechoso y empezar a mirar el arma del crimen. Los investigadores incluso han creado un nuevo conjunto de datos de informes de errores anotados por humanos para ayudar a entrenar futuros modelos de IA para que presten atención a las cosas correctas, con la esperanza de hacerlos más fiables en la reparación del software que hace funcionar nuestro mundo.

Resumen Técnico: ¿Cómo leen los LLM los informes de errores? Un estudio empírico de la atención en los LLM para la reparación automática de programas

Planteamiento del problema
Los sistemas de Reparación Automática de Programas (APR) basados en Modelos de Lenguaje de Gran Escala (LLM) han demostrado mejoras significativas sobre las técnicas tradicionales, sin embargo, su rendimiento es inconsistente. Los modelos suelen tener éxito en un error pero fallar en uno casi idéntico, incluso cuando se les proporciona la misma información contextual. Esta imprevisibilidad surge de una falta de interpretabilidad respecto a cómo los LLM procesan los informes de errores (bug reports). Específicamente, no está claro cómo los modelos priorizan la información diversa dentro de los informes de errores (por ejemplo, descripciones de errores, trazas de la pila/stacktraces, metadatos de versión) y si los patrones de asignación de atención se correlacionan con el éxito de la reparación. Estudios previos han analizado la atención en la generación de código a partir de descripciones de tareas cortas, pero extender esto a informes de errores del mundo real, que son heterogéneos y contienen tanto código como lenguaje natural, sigue siendo un desafío abierto.

Metodología
Los autores realizaron un estudio empírico analizando 319 errores del mundo real de los conjuntos de datos SWE-bench Verified (Python) y Multi-SWE-bench (Java). El estudio utilizó tres LLM: el propietario claude-4-sonnet y los de código abierto gpt-oss-20b y qwen-3-32b. Para investigar los mecanismos de atención sin requerir acceso a los estados internos del modelo (lo cual suele ser imposible con modelos propietarios), los autores emplearon un análisis basado en perturbaciones.

La metodología abordó tres Preguntas de Investigación (RQ):

RQ1 (Atención a nivel de sección): Los autores trataron los informes de errores como conjuntos de seis secciones distintas (Descripción del error, Reproducción, Comportamiento esperado, Comportamiento actual, Información de versión e Información adicional). Utilizaron Kernel SHAP (SHapley Additive exPlanations) para medir la contribución marginal de cada sección mediante el enmascaramiento de las mismas y observando los cambios en la similitud del parche generado con respecto a la verdad de referencia (medida mediante CodeBLEU).
RQ2 (Atención a nivel de grano fino): Dentro de cada sección, los componentes se desglosaron aún más en lenguaje natural (por ejemplo, descripciones, información de versión) y código (por ejemplo, trazas de la pila, fragmentos de pruebas, definiciones de clases). Utilizando embeddings de UniXcoder, los autores midieron la diferencia semántica entre la salida base y las salidas generadas tras el enmascaramiento de componentes individuales. Esto permitió la clasificación de los patrones de atención en tres estructuras: Difusa (atención distribuida en múltiples componentes), Localizada (foco en un solo componente) y Sin atención.
RQ3 (Alineación Humano-Modelo): Para comparar la atención del modelo con la intuición del desarrollador, los autores crearon un nuevo conjunto de datos de 100 informes de errores anotados manualmente. Cuatro desarrolladores experimentados calificaron la importancia de las secciones e identificaron frases clave. La alineación se midió utilizando métricas Hit@k y correlaciones de rango de Spearman entre las calificaciones de los desarrolladores y las puntuaciones de atención del modelo.

Resultados Clave

Diferencias a nivel de sección: Las reparaciones exitosas asignaron consistentemente una mayor atención a la sección de Descripción del error, mientras que las reparaciones fallidas exhibieron significativamente mayor atención a la Información de versión (metadatos del entorno). Este patrón se mantuvo en los tres modelos y en ambos lenguajes de programación.
Estructuras de atención:
- Atención Difusa: Fuertemente asociada con reparaciones exitosas (Odds Ratio [OR] = 2.07). Los modelos que distribuyeron la atención entre múltiples componentes de diagnóstico (por ejemplo, trazas de la pila, datos de prueba y descripciones) tuvieron más probabilidades de tener éxito.
- Atención Localizada: Fuertemente asociada con fallos de reparación (OR = 0.40). El exceso de enfoque en un solo componente, particularmente en metadatos no diagnósticos, a menudo condujo a parches incorrectos.
- Importancia de los componentes: La atención a Código: Traza de la pila (Stacktrace) y Lenguaje Natural: Descripción mostró asociaciones positivas significativas con el éxito. Por el contrario, la atención a Lenguaje Natural: Información de versión se asoció negativamente con el éxito.
Alineación Humano-Modelo: Existe una correlación estadísticamente significativa entre el éxito de la reparación y la alineación de la atención del modelo con las secciones y frases identificadas por los desarrolladores como importantes. Las reparaciones exitosas mostraron correlaciones de Spearman más altas ( $\rho=0.60$ ) y puntuaciones Hit@1 en comparación con los fallos. La desalineación, donde los modelos se enfocaban en números de versión mientras los desarrolladores se enfocaban en descripciones de fallos, fue una causa común de fracaso.

Significancia y Contribuciones
El artículo afirma proporcionar el primer estudio empírico de los patrones de atención en la APR basada en LLM. Sus principales contribuciones son:

Evidencia empírica de la mala asignación de atención: El estudio establece que la mala asignación de la atención —específicamente la sobre-localización en metadatos y la infrautilización de componentes diagnósticos— es un factor clave en los fallos de la APR.
Caracterización de los patrones de atención: Caracteriza la distinción entre las estrategias de atención "difusa" (exitosa) y "localizada" (a menudo fallida) a través de los niveles de sección y de componente.
Métrica de alineación Humano-Modelo: Demuestra que el éxito de la reparación está vinculado a qué tan bien la atención del modelo se alinea con el razonamiento del desarrollador, ofreciendo una nueva métrica para evaluar la fiabilidad de la APR.
Nuevo conjunto de datos: Los autores lanzan el primer conjunto de datos de atención de desarrolladores anotado para APR, que comprende 100 informes de errores con calificaciones de importancia por sección y anotaciones de frases clave.

Conclusión
Los autores concluyen que, si bien la dificultad del error influye en las tasas de reparación, no explica completamente la varianza del rendimiento. En su lugar, la distribución de la atención es un determinante crítico. Las reparaciones exitosas dependen de la integración de señales de múltiples fuentes diagnósticas, mientras que los fallos suelen resultar de que los modelos se obsesionan con metadatos menos informativos. Estos hallazgos sugieren que los futuros sistemas de APR deberían priorizar mecanismos que fomenten la atención difusa y alineen la priorización de información del modelo con la intuición del desarrollador, potencialmente a través de una mejor ingeniería de prompts, selección de contexto o ajuste fino utilizando el conjunto de datos de atención proporcionado.