Logging Like Humans for LLMs: Rethinking Logging via Execution and Runtime Feedback

Resumen Técnico: ReLog

1. El Problema

La generación automática de sentencias de registro (logging) es crucial para la depuración y el mantenimiento de software. Sin embargo, los enfoques existentes presentan dos limitaciones fundamentales en la era de los Modelos de Lenguaje Grande (LLM):

1. Enfoque Estático y de Un Solo Paso: Las técnicas actuales generan sentencias de registro basándose únicamente en el análisis estático del código (como árboles de sintaxis abstracta) en una sola pasada. Ignoran el comportamiento real del programa durante la ejecución. En la práctica, los desarrolladores suelen refinar iterativamente los registros basándose en lo que observan en los logs de tiempo de ejecución (por ejemplo, ajustar la precisión de los datos o el nivel de severidad).
2. Evaluación Basada en Similitud Textual: La evaluación tradicional compara las sentencias generadas con las escritas por desarrolladores humanos, asumiendo que estas últimas son el "estándar de oro". Esta premisa es cuestionable porque:
   • Los registros originales pueden ser subóptimos.
   • La similitud textual no garantiza que los logs sean útiles para tareas posteriores.
   • Nuevo Consumidor: En la era de los LLM, los logs no solo los leen humanos, sino que se consumen para tareas automatizadas como la localización de defectos y la reparación de código. Por tanto, la utilidad debe medirse por la capacidad de los logs para ayudar a estos agentes, no por su parecido con el código humano.

2. Metodología: El Marco ReLog

Los autores proponen ReLog, un marco de trabajo impulsado por retroalimentación en tiempo de ejecución para la generación iterativa de sentencias de registro. A diferencia de los métodos estáticos, ReLog trata la generación de registros como un proceso de refinamiento consciente de la ejecución.

El flujo de trabajo consta de cuatro etapas en un bucle cerrado:

1. Generación Inicial:
   • ReLog ejecuta el código de entrada para capturar el resultado de la ejecución (éxito, excepción, valor de retorno incorrecto).
   • Utiliza tanto el contexto del código como las señales de ejecución observadas para generar sentencias de registro iniciales dirigidas a las partes del código relevantes para el fallo.
2. Reparación de Compilación:
   • Tras insertar los registros, el programa instrumentado puede fallar al compilar (errores de sintaxis, variables no resueltas, etc.).
   • ReLog incluye un módulo de reparación que utiliza los mensajes de error del compilador para corregir exclusivamente las sentencias de registro añadidas, sin alterar la lógica original del programa, asegurando que el código sea ejecutable.
3. Evaluación de Suficiencia del Log:
   • Un módulo basado en LLM actúa como "crítico" para evaluar si los logs generados proporcionan información suficiente para tareas de depuración.
   • La evaluación se basa en tres dimensiones estructuradas:
     • Rastreabilidad: ¿Exponen claramente la ruta de ejecución?
     • Visibilidad del Estado: ¿Se registran variables clave y estados intermedios?
     • Vinculación Causal: ¿Proveen evidencia de por qué ocurrió el comportamiento, no solo que ocurrió?
4. Refinamiento Iterativo:
   • Si el crítico determina que la información es insuficiente, genera retroalimentación accionable (ej. "falta registrar la variable X" o "ajustar la posición").
   • Un módulo refinador actualiza la lista de sentencias de registro basándose en esta retroalimentación.
   • El ciclo (Ejecución -> Reparación -> Evaluación -> Refinamiento) se repite hasta que los logs son suficientes o se alcanza un límite de iteraciones.

3. Contribuciones Clave

• Nuevo Paradigma de Generación: Se propone un enfoque iterativo guiado por la ejecución, alejándose de la predicción estática de un solo paso.
• Metodología de Evaluación Innovadora: Se abandona la métrica de similitud textual con el código humano. En su lugar, se evalúa la utilidad de los logs mediante su desempeño en tareas de depuración downstream (localización de defectos y reparación de programas).
• Nuevos Conjuntos de Datos (Benchmarks): Se construyeron dos nuevos conjuntos de datos derivados de Defects4J para evaluar diferentes niveles de disponibilidad de código:
  • Depuración Directa: El agente tiene acceso al código fuente defectuoso y a los logs generados.
  • Depuración Indirecta: El agente solo tiene acceso a los logs generados y al contexto de llamadas, simulando entornos de producción donde el código fuente no está disponible.
• Recurso Abierto: El paquete de replicación del estudio está disponible públicamente.

4. Resultados Experimentales

Los experimentos se realizaron utilizando múltiples LLMs (incluyendo GPT-5-mini, DeepSeek-V3, Qwen3-Coder, GLM-4) sobre los conjuntos de datos de Defects4J.

• Rendimiento Superior en Depuración:
  • Depuración Directa: ReLog alcanzó un F1 Score de 0.520 para la localización de defectos, superando a la mejor línea base (UniLog) en un 16.33%. Además, logró reparar exitosamente 97 defectos (31.19% del total), superando significativamente a otros métodos.
  • Depuración Indirecta: En escenarios sin código fuente, ReLog obtuvo un F1 Score de 0.408, superando a la línea base más cercana en un 16.57%. Esto demuestra que los logs generados contienen suficiente información para diagnosticar fallos sin ver el código.
• Robustez y Estabilidad:
  • ReLog tuvo una tasa de fallo de compilación casi nula (0 en depuración directa, 2 en indirecta) gracias a su módulo de reparación, mientras que otros enfoques (como LANCE2 o FastLog) fallaron en compilación en más de 100 casos.
  • El rendimiento se mantuvo consistente a través de diferentes modelos LLM, indicando que la mejora proviene del marco de trabajo y no de un modelo específico.
• Estudios de Ablación:
  • Eliminar la reparación de compilación aumentó drásticamente los fallos de ejecución y redujo la recuperación (recall).
  • Eliminar el refinamiento iterativo redujo el F1 Score de 0.520 a 0.388, confirmando que la retroalimentación en tiempo de ejecución es esencial para capturar la información diagnóstica necesaria.

5. Significado e Impacto

Este trabajo representa un cambio de paradigma en la ingeniería de software asistida por IA:

1. De la Similitud a la Utilidad: Demuestra que generar logs que "se parezcan" a los humanos no es el objetivo final; el objetivo es generar logs que sean útiles para la depuración automatizada.
2. Cierre de la Brecha entre Estático y Dinámico: Al integrar la ejecución real en el proceso de generación, ReLog captura información de estado y control que el análisis estático no puede inferir.
3. Preparación para la Era de los LLM: Al optimizar los logs para que sean consumibles por agentes de IA (para localizar y reparar errores), el trabajo sienta las bases para sistemas de mantenimiento de software más autónomos y eficientes.
4. Validación Práctica: El estudio de caso (Figura 4 del artículo) ilustra cómo ReLog, mediante corrección de compilación y refinamiento iterativo, logra exponer la causa raíz de un defecto que los métodos estáticos no pudieron identificar correctamente.

En conclusión, ReLog establece que la generación de registros debe ser un proceso dinámico y guiado por la ejecución, priorizando la utilidad diagnóstica para tareas posteriores sobre la mera imitación del estilo de codificación humana.