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

Probleemstelling

Bestaande methoden voor het automatisch genereren van log statements (logboekaanwijzingen) hebben twee fundamentele beperkingen die hun bruikbaarheid in het tijdperk van Large Language Models (LLMs) ondermijnen:

1. Statische, eenmalige generatie: Huidige benaderingen genereren log statements puur op basis van statische codeanalyse (zoals Abstract Syntax Trees) in één enkele pass. Ze negeren echter het gedrag van het programma tijdens de uitvoering. In de praktijk worden log statements echter vaak iteratief verfijnd door ontwikkelaars op basis van wat ze zien in de runtime-logs (bijvoorbeeld het aanpassen van precisie of ernstniveaus).
2. Verouderde evaluatiemethoden: Bestaande methoden evalueren de kwaliteit van gegenereerde logs door ze te vergelijken met door mensen geschreven logs (textuele gelijkenis). Deze aanname is problematisch omdat menselijke logs niet altijd optimaal zijn en omdat de primaire consument van logs in moderne workflows vaak een LLM is voor downstream taken (zoals defectlokalisatie en reparatie), niet alleen een mens. Een log die tekstueel lijkt op een menselijke log, is niet per se nuttig voor een LLM om een fout te diagnosticeren.

Methodologie: ReLog

De auteurs introduceren ReLog, een iteratief framework dat log statement-generatie herformuleert als een proces dat wordt geleid door runtime-feedback. In plaats van een statische voorspelling, behandelt ReLog het als een gesloten lus van generatie, uitvoering, evaluatie en verfijning.

Het framework bestaat uit vier fasen:

1. Initiële Generatie: ReLog voert eerst de invoercode uit om de uitvoeringsuitkomst te vangen (bijv. uitzonderingen, foutieve retourwaarden). Deze runtime-signalen worden gebruikt, samen met de codecontext, om gerichte initiële log statements te genereren die zich richten op potentiële foutbronnen.
2. Compilatieherstel (Compilation Repair): Nadat de log statements zijn ingevoegd, kan de code niet meer compileren (door ontbrekende imports, variabele typefouten, etc.). ReLog gebruikt een "Repair Agent" die compilerfouten analyseert en de gegenereerde log statements aanpast om de code weer compileerbaar en uitvoerbaar te maken, zonder de originele logica te wijzigen.
3. Evaluatie van Log-voldoende (Log Sufficiency Evaluation): Een LLM-based "Critic" module evalueert of de gegenereerde runtime-logs voldoende informatie bevatten voor downstream taken. De evaluatie gebeurt op basis van drie dimensies:
   • Traceerbaarheid: Is het uitvoeringspad duidelijk?
   • Zichtbaarheid van status: Zijn belangrijke variabelen en tussenliggende staten vastgelegd?
   • Causale koppeling: Bieden de logs bewijs voor waarom een fout optrad, niet alleen dat het optrad?
4. Iteratieve Verfijning: Als de critic oordeelt dat de logs ontoereikend zijn, wordt een "Refiner" module ingeschakeld. Deze past de log statements aan op basis van de feedback (bijv. toevoegen van ontbrekende variabelen, aanpassen van de locatie) en het proces herhaalt zich tot de logs voldoende zijn of een maximum aantal iteraties is bereikt.

Evaluatie en Resultaten

Om de praktische bruikbaarheid te testen, hebben de auteurs twee nieuwe datasets gebouwd op basis van Defects4J, gericht op downstream debugging taken:

• Direct Debugging: De broncode is beschikbaar voor de debug-agent.
• Indirect Debugging: De broncode is niet beschikbaar; de agent moet uitsluitend vertrouwen op de gegenereerde runtime-logs en de aanroepcontext.

Belangrijkste resultaten:

• Superieure Prestaties: ReLog presteert consequent beter dan alle bestaande baselines (zoals SCLogger, UniLog, LANCE, GoStatic) in zowel directe als indirecte debugging.
  • In directe debugging bereikt ReLog een F1-score van 0,520 voor defectlokalisatie (een stijging van 16,33% ten opzichte van de beste baseline) en repareert het 97 van de 311 defecten succesvol.
  • In indirecte debugging (zonder broncode) behaalt ReLog een F1-score van 0,408, wat 16,57% beter is dan de beste baseline.
• Robuustheid: Het framework werkt consistent goed over verschillende LLMs heen (GPT-5-mini, DeepSeek-V3, Qwen3, GLM-4), wat aangeeft dat het voordeel voortkomt uit het framework zelf en niet alleen uit de capaciteiten van één specifiek model.
• Ablatie-studies: Het verwijderen van de compilatieherstel-module of de iteratieve verfijning leidt tot een aanzienlijke daling in prestaties, wat bevestigt dat beide componenten essentieel zijn.
• Compilatie-stabiliteit: In tegenstelling tot andere methoden die vaak oncompileerbare code genereren, heeft ReLog een zeer lage mislukingsratio voor compilatie dankzij de ingebouwde herstelmodule.

Belangrijkste Bijdragen

1. ReLog Framework: Een nieuw, runtime-feedback-gedreven framework voor iteratieve generatie van log statements dat de kloof overbrugt tussen statische code en dynamisch uitvoeringsgedrag.
2. Nieuwe Evaluatiemethodologie: Een verschuiving van evaluatie op basis van tekstuele gelijkenis naar evaluatie op basis van downstream nut (effectiviteit bij defectlokalisatie en reparatie door LLMs).
3. Datasets: De constructie van twee nieuwe benchmarks voor directe en indirecte debugging, die het mogelijk maken om log-generatie te testen onder verschillende niveaus van toegang tot broncode.

Betekenis en Impact

Dit werk markeert een paradigmaverschuiving in het veld van geautomatiseerd logging. Het stelt dat log statements niet meer alleen voor mensen moeten worden geschreven, maar specifiek moeten worden geoptimaliseerd voor verbruik door AI-systemen (LLMs) in downstream taken. Door runtime-feedback te integreren, produceert ReLog logs die diagnostisch waardevoller zijn, zelfs wanneer de broncode niet beschikbaar is. Dit is een cruciale stap voor de toekomst van geautomatiseerd softwareonderhoud en foutopsporing in complexe systemen.