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

Resumo Técnico: Evidência de Linguagem Única é Insuficiente para Registro Automatizado

Declaração do Problema
A geração automatizada de instruções de registro é uma tarefa crítica para a manutenção de software, diagnóstico de falhas e observabilidade em produção. Embora os desenvolvedores dependam de registros para compreender o comportamento em tempo de execução, a criação manual de instruções de registro de alta qualidade é intensiva em mão de obra e dependente de contexto, exigindo decisões sobre localização de inserção, seleção de API, níveis de severidade, conteúdo da mensagem e exposição de variáveis. Embora pesquisas recentes tenham explorado a geração automatizada usando Modelos de Linguagem de Grande Escala (LLMs), as evidências existentes sofrem de duas limitações primárias que restringem a generalizabilidade das descobertas:

1. Viés de Linguagem Única: Estudos anteriores (por exemplo, LANCE, LEONID, SCLogger) são predominantemente centrados em Java. O registro automatizado depende fortemente de fatores específicos da linguagem, como sintaxe, sistemas de tipos, idiomatismos de fluxo de controle e designs de frameworks de registro. Consequentemente, conclusões extraídas de um único ecossistema podem não se transferir para outros.
2. Limitação de Instantâneo de Repositório: A maioria dos benchmarks depende de instantâneos congelados de repositórios onde o modelo reconstrói uma instrução de registro existente a partir de contexto estático. Isso falha em capturar a natureza dinâmica da evolução do código, onde os desenvolvedores introduzem instruções de registro simultaneamente enquanto modificam funcionalidades ou abordam falhas.

Metodologia: MultiLogBench
Para abordar essas lacunas, os autores constroem o MultiLogBench, um benchmark multilíngue e estudo empírico abrangendo seis ecossistemas de linguagens de programação: Java, Python, Go, C++, JavaScript e C#. O benchmark integra três ramos de dados complementares:

1. Dados de Instantâneo de Repositório: O principal benchmark controlado contendo 63.965 instâncias de código de produção mineradas de revisões congeladas. Isso serve como linha de base para comparação entre linguagens.
2. Dados de Histórico de Revisão: Um ramo complementar contendo 744 instâncias extraídas de commits autênticos onde os desenvolvedores introduziram instruções de registro. Este ramo testa se as descobertas se mantêm em configurações realistas de manutenção onde decisões de registro são intercaladas com a evolução do código.
3. Dados de Histórico de Revisão Transformados: Um ramo de robustez onde o código circundante das instâncias do histórico de revisão é reescrito usando transformações de superfície que preservam semântica (por exemplo, inserção de parênteses, neutralização de condições, normalização de blocos). Isso testa se o desempenho do modelo depende da memorização exata de superfície de dados de pré-treinamento em vez de raciocínio genuíno.

O estudo avalia sete LLMs contemporâneos (incluindo modelos fechados de ponta e modelos de código especializados) sob um protocolo unificado. A avaliação decompõe a tarefa em componentes específicos:

• Localização do local de registro: Medida por Precisão de Posição (PA).
• Correspondência de âncora de framework: Medida por Precisão de Framework (FA), avaliando se a API/receptor correto é utilizado.
• Previsão de severidade: Medida por Precisão de Nível (LA) e Distância Ordinal Média (AOD).
• Geração de mensagem: Medida por BLEU-4 e ROUGE-L.
• Recuperação de variáveis: Medida por Taxa de Correspondência Precisa (PMR) e F1 baseado em conjuntos.
• Qualidade geral: Uma Pontuação Composta em Cascata (CCS) que bloqueia métricas de qualidade de conteúdo na seleção correta de posição e framework.

Principais Resultados
O estudo empírico produz quatro descobertas primárias através das perguntas de pesquisa (RQ1–RQ4):

• RQ1: Variação entre Linguagens: O desempenho varia substancialmente entre as linguagens. Java alcança a maior qualidade geral (CCS), seguido por Go e C#, enquanto C++ e JavaScript mostram pontuações mais baixas. Crucialmente, a correspondência de âncora de framework (FA) é o componente mais sensível à linguagem, exibindo a maior dispersão entre linguagens. Por exemplo, C++ mostra uma fraqueza significativa na correspondência de framework em comparação com outras linguagens.
• RQ2: Dificuldade Estrutural: A dificuldade de geração está distribuída de forma desigual dentro das funções. Contextos de laço e chamável aninhado são os ambientes estruturais mais desafiadores, exigindo que os modelos localizem instruções de registro dentro de atualizações iterativas ou escopos internos concorrentes. Em contraste, contextos de ramificação e tratamento de exceções são comparativamente mais fáceis.
• RQ3: Estabilidade em Configurações de Manutenção: Ao transitar de dados de instantâneo de repositório para dados de histórico de revisão, o desempenho absoluto declina em todas as linguagens e métricas. Embora diferenças entre linguagens de granularidade grossa persistam, as classificações dos modelos tornam-se significativamente menos estáveis. Os modelos de topo (Gemini-3.1-Pro e Claude-Sonnet-4.6) permanecem relativamente estáveis, mas modelos de nível médio e inferior reordenam-se frequentemente entre linguagens na configuração de histórico de revisão, tornando as tabelas de classificação de linguagem única insuficientes para seleção de modelos de granularidade fina.
• RQ4: Robustez a Transformações: Sob transformações de código que preservam semântica, os modelos não exibem um colapso amplo de desempenho na mesma direção. A mudança média na CCS é negligenciável (−0.005), sugerindo que os padrões de desempenho observados não são impulsionados principalmente pela memorização exata de forma de superfície das instâncias do benchmark.

Análise Qualitativa de Falhas
A análise qualitativa revela dois padrões de falha dominantes:

1. Confusão de Framework: Os modelos frequentemente identificam corretamente a intenção de registrar, mas falham em alinhar-se com famílias de APIs específicas do projeto ou convenções de receptor (por exemplo, usar LOG genérico em vez de VLOG específico do projeto em C++, ou receptores de instância em vez de estáticos em C#).
2. Ambiguidade Estrutural: Em contextos de laço e chamável aninhado, os modelos lutam para localizar a instrução de registro no subescopo correto, frequentemente anexando mensagens a operações mais amplas ou manipuladores vizinhos em vez do contexto iterativo ou de callback específico.

Significado e Contribuições
O artigo argumenta que evidência de linguagem única é insuficiente para tirar conclusões robustas sobre a geração automatizada de instruções de registro. As principais contribuições são:

1. MultiLogBench: Um benchmark multilíngue integrando dados de instantâneo de repositório, histórico de revisão e dados transformados para avaliar a geração de registro em seis ecossistemas.
2. Protocolo de Avaliação Unificado: Um framework que decompõe a qualidade da geração em componentes de localização, correspondência de framework, severidade, mensagem e variáveis, permitindo o isolamento de fontes específicas de falha.
3. Evidência Empírica de Instabilidade: Evidência sistemática mostrando que conclusões derivadas de um ecossistema de linguagem (por exemplo, Java) não se transferem confiavelmente para outros. Especificamente, a correspondência de âncora de framework é um grande gargalo, e as classificações dos modelos são instáveis fora do nível de ponta quando avaliadas entre linguagens ou em configurações realistas de manutenção.
4. Validação de Robustez: Demonstração de que, embora o desempenho degrade em cenários realistas de manutenção, os padrões multilíngues centrais persistem e não são meramente artefatos de vazamento de dados ou memorização de superfície.

Os autores concluem que trabalhos futuros e desenvolvimento de ferramentas devem priorizar avaliação multilíngue e validação orientada à manutenção. Eles enfatizam que decisões de implantação devem ser conscientes da linguagem em vez de depender de tabelas de classificação globais centradas no modelo, e que o progresso no registro automatizado requer abordar a realização específica do ecossistema (correspondência de framework) e localização estrutural (tratamento de laços e escopos aninhados) em vez de apenas melhorar a geração de texto de mensagem.