Single-Language Evidence Is Insufficient for Automated Logging: A Multilingual Benchmark and Empirical Study with LLMs

Resumen Técnico: La Evidencia de Un Solo Idioma es Insuficiente para el Registro Automatizado

Enunciado del Problema
La generación automatizada de sentencias de registro es una tarea crítica para el mantenimiento de software, el diagnóstico de fallos y la observabilidad en producción. Aunque los desarrolladores dependen de los registros para comprender el comportamiento en tiempo de ejecución, la elaboración manual de sentencias de registro de alta calidad es laboriosa y dependiente del contexto, requiriendo decisiones sobre la ubicación de inserción, la selección de API, los niveles de severidad, el contenido del mensaje y la exposición de variables. Aunque investigaciones recientes han explorado la generación automatizada utilizando Modelos de Lenguaje Grande (LLM), la evidencia existente adolece de dos limitaciones principales que restringen la generalizabilidad de los hallazgos:

1. Sesgo de Un Solo Idioma: Estudios previos (por ejemplo, LANCE, LEONID, SCLogger) son predominantemente centrados en Java. El registro automatizado depende en gran medida de factores específicos del idioma, como la sintaxis, los sistemas de tipos, los idiomatismos de flujo de control y los diseños de los marcos de registro. En consecuencia, las conclusiones extraídas de un único ecosistema pueden no transferirse a otros.
2. Limitación de Instantánea de Repositorio: La mayoría de las pruebas de referencia se basan en instantáneas congeladas de repositorios donde el modelo reconstruye una sentencia de registro existente a partir de un contexto estático. Esto no logra capturar la naturaleza dinámica de la evolución del código, donde los desarrolladores introducen sentencias de registro mientras modifican simultáneamente la funcionalidad o abordan fallos.

Metodología: MultiLogBench
Para abordar estas brechas, los autores construyen MultiLogBench, una prueba de referencia multilingüe y un estudio empírico que abarca seis ecosistemas de lenguajes de programación: Java, Python, Go, C++, JavaScript y C#. La prueba de referencia integra tres ramas de datos complementarias:

1. Datos de Instantánea de Repositorio: La prueba de referencia controlada principal que contiene 63,965 instancias de código de producción extraídas de revisiones congeladas. Esto sirve como línea base para la comparación entre idiomas.
2. Datos de Historial de Revisiones: Una rama complementaria que contiene 744 instancias extraídas de confirmaciones auténticas donde los desarrolladores introdujeron sentencias de registro. Esta rama prueba si los hallazgos se mantienen en entornos de mantenimiento realistas donde las decisiones de registro se entrelazan con la evolución del código.
3. Datos de Historial de Revisiones Transformados: Una rama de robustez donde el código circundante de las instancias del historial de revisiones se reescribe utilizando transformaciones superficiales que preservan la semántica (por ejemplo, inserción de paréntesis, neutralización de condiciones, normalización de bloques). Esto prueba si el rendimiento del modelo depende de la memorización exacta de la superficie de los datos de preentrenamiento en lugar de un razonamiento genuino.

El estudio evalúa siete LLM contemporáneos (incluyendo modelos propietarios de vanguardia y modelos especializados en código) bajo un protocolo unificado. La evaluación descompone la tarea en componentes específicos:

• Localización del sitio de registro: Medida por la Precisión de Posición (PA).
• Coincidencia de anclaje de marco: Medida por la Precisión del Marco (FA), evaluando si se utiliza la API/receptor correcto.
• Predicción de severidad: Medida por la Precisión de Nivel (LA) y la Distancia Ordinal Promedio (AOD).
• Generación de mensajes: Medida por BLEU-4 y ROUGE-L.
• Recuperación de variables: Medida por la Tasa de Coincidencia Precisa (PMR) y F1 basado en conjuntos.
• Calidad general: Una Puntuación Compuesta en Cascada (CCS) que filtra las métricas de calidad del contenido sobre la selección correcta de posición y marco.

Resultados Clave
El estudio empírico arroja cuatro hallazgos principales a través de las preguntas de investigación (RQ1–RQ4):

• RQ1: Variación entre Idiomas: El rendimiento varía sustancialmente entre idiomas. Java logra la mayor calidad general (CCS), seguido por Go y C#, mientras que C++ y JavaScript muestran puntuaciones más bajas. Crucialmente, la coincidencia de anclaje de marco (FA) es el componente más sensible al idioma, mostrando la mayor dispersión entre idiomas. Por ejemplo, C++ muestra una debilidad significativa en la coincidencia de marcos en comparación con otros idiomas.
• RQ2: Dificultad Estructural: La dificultad de la generación está distribuida de manera desigual dentro de las funciones. Los contextos de bucle y llamada anidada son los entornos estructurales más desafiantes, requiriendo que los modelos localicen sentencias de registro dentro de actualizaciones iterativas o ámbitos internos competitivos. En contraste, los contextos de ramificación y manejo de excepciones son comparativamente más fáciles.
• RQ3: Estabilidad en Entornos de Mantenimiento: Al transitar de datos de instantánea de repositorio a datos de historial de revisiones, el rendimiento absoluto disminuye en todos los idiomas y métricas. Aunque persisten las diferencias interlingüísticas de granularidad gruesa, las clasificaciones de los modelos se vuelven significativamente menos estables. Los modelos de primer nivel (Gemini-3.1-Pro y Claude-Sonnet-4.6) permanecen relativamente estables, pero los modelos de nivel medio y bajo se reordenan frecuentemente entre idiomas en el entorno de historial de revisiones, lo que hace que las tablas de clasificación de un solo idioma sean insuficientes para la selección de modelos de granularidad fina.
• RQ4: Robustez ante Transformaciones: Bajo transformaciones de código que preservan la semántica, los modelos no exhiben un colapso generalizado de rendimiento en la misma dirección. El cambio medio en la CCS es insignificante (−0.005), lo que sugiere que los patrones de rendimiento observados no son impulsados principalmente por la memorización exacta de la forma superficial de las instancias de la prueba de referencia.

Análisis Cualitativo de Fallos
El análisis cualitativo revela dos patrones de fallo dominantes:

1. Confusión de Marcos: Los modelos a menudo identifican correctamente la intención de registrar, pero fallan al alinearse con familias de API específicas del proyecto o convenciones de receptor (por ejemplo, usar LOG genérico en lugar de VLOG específico del proyecto en C++, o receptores de instancia en lugar de estáticos en C#).
2. Ambigüedad Estructural: En contextos de bucle y llamada anidada, los modelos luchan por localizar la sentencia de registro en el subámbito correcto, a menudo adjuntando mensajes a operaciones más amplias o manejadores vecinos en lugar del contexto iterativo o de devolución de llamada específico.

Significado y Contribuciones
El artículo argumenta que la evidencia de un solo idioma es insuficiente para extraer conclusiones robustas sobre la generación automatizada de sentencias de registro. Las contribuciones clave son:

1. MultiLogBench: Una prueba de referencia multilingüe que integra datos de instantánea de repositorio, historial de revisiones y datos transformados para evaluar la generación de registros en seis ecosistemas.
2. Protocolo de Evaluación Unificado: Un marco que descompone la calidad de la generación en componentes de localización, coincidencia de marcos, severidad, mensaje y variables, permitiendo el aislamiento de fuentes específicas de fallo.
3. Evidencia Empírica de Inestabilidad: Evidencia sistemática que muestra que las conclusiones derivadas de un ecosistema de idioma (por ejemplo, Java) no se transfieren confiablemente a otros. Específicamente, la coincidencia de anclaje de marco es un cuello de botella importante, y las clasificaciones de modelos son inestables fuera del nivel de vanguardia cuando se evalúan entre idiomas o en entornos de mantenimiento realistas.
4. Validación de Robustez: Demostración de que, aunque el rendimiento se degrada en escenarios de mantenimiento realistas, los patrones multilingües centrales persisten y no son meros artefactos de filtrado de datos o memorización superficial.

Los autores concluyen que el trabajo futuro y el desarrollo de herramientas deben priorizar la evaluación multilingüe y la validación orientada al mantenimiento. Enfatizan que las decisiones de implementación deben ser conscientes del idioma en lugar de depender de tablas de clasificación globales centradas en el modelo, y que el progreso en el registro automatizado requiere abordar la realización específica del ecosistema (coincidencia de marcos) y la localización estructural (manejo de bucles y ámbitos anidados) en lugar de simplemente mejorar la generación de texto del mensaje.