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

1. O Problema

O artigo identifica duas limitações fundamentais nas abordagens atuais de geração automática de instruções de log (logging statements):

1. Abordagem Estática e de Passagem Única: Os métodos existentes tratam a geração de logs como um problema estático, baseado apenas na análise de código fonte (como árvores de sintaxe abstrata) em uma única passagem. Eles ignoram o comportamento real do programa durante a execução. Na prática, desenvolvedores humanos refinam iterativamente os logs com base no que observam nos logs de runtime (ex: ajustar precisão de tempo, mudar níveis de severidade ou adicionar variáveis faltantes).
2. Avaliação Baseada em Similaridade Textual: A avaliação tradicional compara os logs gerados com os escritos por desenvolvedores, assumindo que os logs originais são o "padrão ouro". No entanto, essa suposição é questionável porque:
   • Os logs escritos por humanos podem ser subótimos.
   • No contexto da era dos Grandes Modelos de Linguagem (LLMs), os logs são consumidos não apenas por humanos, mas também por agentes de IA para tarefas downstream (como localização de defeitos e reparo de código). A similaridade textual não garante que o log seja útil para essas tarefas.

2. Metodologia: O Framework ReLog

Os autores propõem o ReLog, um framework iterativo guiado por feedback de runtime para geração de instruções de log. Diferente dos métodos estáticos, o ReLog trata a geração de logs como um processo de refinamento consciente da execução.

O fluxo de trabalho do ReLog opera em um ciclo fechado com quatro estágios principais:

1. Geração Inicial de Logs:

   • O framework executa o código de entrada para capturar o resultado da execução (exceções, valores de retorno incorretos, etc.).
   • Utiliza o contexto do código e os sinais de execução observados para gerar instruções de log iniciais focadas em áreas potencialmente defeituosas.
   • O modelo de linguagem (LLM) gera uma lista discreta de logs para inserção, sem reescrever a lógica original.

2. Reparo de Compilação (Compilation Repair):

   • Após a inserção dos logs, o programa instrumentado pode falhar na compilação (devido a variáveis não resolvidas, imports faltantes, etc.).
   • Um módulo de reparo utiliza as mensagens de erro do compilador para corrigir apenas as instruções de log adicionadas, mantendo a lógica original intacta. Isso garante que o código seja executável para coletar feedback real.

3. Avaliação de Suficiência do Log (Log Sufficiency Evaluator):

   • O programa instrumentado é executado e os logs de runtime são coletados.
   • Um "Critic" baseado em LLM avalia se os logs fornecem informações suficientes para tarefas downstream (localização de defeitos).
   • A avaliação baseia-se em três dimensões:
     • Rastreabilidade: O log expõe claramente o caminho de execução?
     • Visibilidade de Estado: Variáveis e estados intermediários chave estão registrados?
     • Vínculo Causal: O log explica por que o comportamento ocorreu, não apenas que ocorreu?
   • Se os logs forem insuficientes, o critic gera feedback acionável.

4. Refinamento Iterativo de Logs:

   • Um módulo "Refiner" (também baseado em LLM) atualiza as instruções de log existentes com base no feedback do critic.
   • O processo pode adicionar, remover ou modificar logs específicos (ex: adicionar uma verificação de condição faltante ou logar o valor de uma constante).
   • O ciclo (Execução -> Avaliação -> Refinamento) se repete até que os logs sejam considerados suficientes ou um limite de iterações seja atingido.

3. Contribuições Principais

• Framework ReLog: Uma nova arquitetura que transforma a geração de logs em um processo guiado por execução e feedback de runtime, em vez de uma previsão estática.
• Nova Metodologia de Avaliação: Propõe avaliar a utilidade dos logs gerados através de tarefas downstream (localização de defeitos e reparo de programas) em vez de métricas de similaridade textual com logs humanos.
• Novos Benchmarks: Construção de dois conjuntos de dados derivados do Defects4J:
  • Depuração Direta: O agente de depuração tem acesso ao código fonte defeituoso e aos logs gerados.
  • Depuração Indireta: O agente tem acesso apenas aos logs de runtime e ao contexto de chamada (simulando ambientes de produção sem acesso ao código fonte).

4. Resultados Experimentais

Os experimentos foram conduzidos utilizando múltiplos LLMs (incluindo GPT-5-mini, DeepSeek-V3, Qwen3-Coder-30B, GLM-4.7) e comparados com baselines de ponta (SCLogger, UniLog, LANCE, FastLog, etc.).

• Desempenho na Depuração Direta:

  • O ReLog alcançou o maior F1-score de detecção de bugs (0,520), superando o melhor baseline (UniLog) em 16,33%.
  • Sucesso em reparar 97 defeitos (31,19% do total), superando significativamente outras abordagens.
  • Taxa de Falha de Compilação: O ReLog teve 0 falhas de compilação, enquanto baselines como LANCE2 e FastLog falharam em centenas de casos (171 e 142, respectivamente), demonstrando a eficácia do módulo de reparo.

• Desempenho na Depuração Indireta (Sem Código Fonte):

  • Mesmo sem acesso ao código fonte, o ReLog obteve o melhor F1-score de 0,408, superando o baseline GoStatic (0,350) em 16,57%.
  • Isso prova que os logs gerados pelo ReLog contêm informações diagnósticas suficientes para inferir a causa raiz apenas com base no comportamento de execução.

• Robustez e Ablação:

  • O framework funcionou consistentemente bem em diferentes LLMs, indicando que a melhoria vem da metodologia de refinamento iterativo e não apenas da capacidade de um modelo específico.
  • Estudos de ablação mostraram que remover o módulo de reparo de compilação ou o loop de refinamento degradou significativamente o desempenho, confirmando que ambos são essenciais.

5. Significado e Impacto

Este trabalho representa uma mudança de paradigma na geração automática de logs:

• Do Estático para o Dinâmico: Demonstra que a geração de logs deve ser um processo iterativo que considera o comportamento real do software, espelhando o fluxo de trabalho humano de depuração.
• Foco na Utilidade Prática: Ao priorizar a utilidade para tarefas downstream (especialmente aquelas auxiliadas por LLMs) em vez da similaridade textual, o ReLog produz logs que são verdadeiramente eficazes para diagnóstico de falhas.
• Viabilidade para Agentes de IA: O framework valida que logs ricos em contexto e causalidade, gerados via feedback de runtime, são cruciais para permitir que agentes de IA realizem depuração e reparo de software com sucesso, mesmo em cenários onde o código fonte não está disponível.

Em resumo, o ReLog estabelece que a qualidade de um log não deve ser medida por quão bem ele se parece com um log escrito por um humano, mas sim por quão bem ele permite que um sistema (humano ou IA) entenda e corrija defeitos no software.