🤖 machine learning

LogSieve: Task-Aware CI Log Reduction for Sustainable LLM-Based Analysis

LogSieve ist eine leichtgewichtige, aufgabenorientierte Log-Reduktionstechnik, die das Volumen und die Rechenkosten von CI-Logs für die LLM-basierte Analyse signifikant verringert, während sie gleichzeitig die semantische Treue bewahrt und somit ein nachhaltigeres sowie interpretierbares automatisiertes Debugging ermöglicht.

Ursprüngliche Autoren: Marcus Emmanuel Barnes, Taher A. Ghaleb, Safwat Hassan

Veröffentlicht 2026-01-29

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Marcus Emmanuel Barnes, Taher A. Ghaleb, Safwat Hassan

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, ein Rätsel zu lösen, aber anstatt einiger weniger Hinweise erhalten Sie einen Stapel von 10.000 Seiten Notizen. Die meisten dieser Seiten bestehen nur aus langweiligen Listen von gekauftem Material, Wetterberichten oder der Beschreibung, wie der Detektiv den Raum betritt. Nur eine Handvoll Seiten enthält tatsächlich die Hinweise, die das Verbrechen lösen.

Dies ist genau das Problem, mit dem Softwareentwickler bei CI-Logs konfrontiert sind (den digitalen „Tagebüchern“ ihres Software-Erstellungsprozesses). Wenn ein Software-Build fehlschlägt, sind die Logs oft massiv, verrauscht und voller repetitiver, unwichtiger Texte.

LogSieve ist ein neues Tool, das darauf ausgelegt ist, wie ein supereffizienter Editor für diese Logs zu fungieren, bevor eine intelligente KI (ein Large Language Model, oder LLM) versucht, sie zu lesen.

Hier ist die Erklärung des Papers, auf einfache Konzepte heruntergebrochen:

1. Das Problem: Zu viel Rauschen, zu hohe Kosten

Wenn eine Software nicht korrekt gebaut werden kann, sind die Logs wie ein unordentliches Zimmer. Sie enthalten:

Die Hinweise: Fehlermeldungen, Absturzberichte und spezifische Gründe, warum der Vorgang fehlgeschlagen ist.
Der Unfug: „Paket wird geladen“, „Tools werden heruntergeladen“, Zeitstempel und generische Fortschrittsbalken.

Derzeit füttern Entwickler, wenn sie die KI fragen: „Finde heraus, warum das fehlgeschlagen ist“, die KI mit dem gesamten, unordentlichen Zimmer. Dies ist teuer (es kostet Geld, die KI laufen zu lassen), langsam (es dauert Zeit, zu lesen) und verschwenderisch (es verbraucht viel Energie).

2. Die Lösung: LogSieve (Der intelligente Filter)

Die Forscher haben LogSieve entwickelt. Betrachten Sie LogSieve als ein Sieb (ein Küchenwerkzeug mit Löchern), durch das Sie die Logs schütteln.

Was es tut: Es betrachtet jede einzelne Zeile des Logs, bevor die KI sie liest.
Die Regel: Wenn eine Zeile nur „langweiliges Rauschen“ ist (wie „Bibliothek wird geladen“), fällt sie durch die Löcher und wird weggeworfen. Wenn eine Zeile ein „Hinweis“ ist (wie „Error: File not found“), bleibt sie im Korb.
Das Ziel: Es behält die „Ursache“ (die wahre Ursache des Fehlers), aber entfernt den Rest.

3. Die Ergebnisse: Kleiner, schneller, genauso klug

Das Team hat LogSieve an 20 verschiedenen Open-Source-Android-Projekten getestet. Hier ist das Ergebnis:

Den Stapel schrumpfen lassen: Im Durchschnitt reduzierte LogSieve die Größe der Logs um 42 % (Zeilen) und 40 % (Wörter/Token).
- Analogie: Es verwandelte einen 100-seitigen Roman in eine 60-seitige Version, aber die Handlung und das Ende blieben exakt dieselben.
Die KI versteht es immer noch: Sie ließen eine intelligente KI (GPT-4o) den Fehler unter Verwendung der vollständigen Logs und der reduzierten Logs erklären.
- Das Ergebnis: Die KI lieferte fast die identische Antwort für beide Fälle. Die „Bedeutung“ blieb erhalten. Die KI wurde nicht durch die fehlenden „langweiligen“ Zeilen verwirrt.
- Genauigkeit: Die Kategorisierung des Fehlers durch die KI war bei den reduzierten Logs zu 80 % korrekt, verglichen mit den vollständigen Logs.
Die Konkurrenz schlagen: Sie verglichen LogSieve mit zwei anderen Methoden:
1. LogZip: Ein Tool, das Dateien einfach nur komprimiert (wie das Zippen eines Ordners), aber alle langweiligen Zeilen beibehält. Ergebnis: Die KI wurde verwirrt, weil das Rauschen immer noch vorhanden war.
2. Zufälliges Entfernen: Einfach das Löschen zufälliger Zeilen. Ergebnis: Die KI hatte manchmal Glück, verpasste aber oft die entscheidenden Hinweise.
- LogSieve war der klare Gewinner, weil es wusste, was es basierend auf der Bedeutung behalten musste, nicht nur basierend auf der Struktur.

4. Die Automatisierung: Der „Roboter-Editor“

Sie fragen sich vielleicht: „Wer entscheidet, welche Zeilen langweilig sind?“

Der menschliche Aspekt: Zuer Sie haben die Forscher tausende Zeilen manuell beschriftet, um dem Computer beizubringen, was „wichtig“ aussieht.
Die Automatisierung: Sie trainierten ein kleineres, schnelleres Computerprogramm (einen Machine-Learning-Klassifizierer), um dies automatisch zu erledigen.
Die Bewertung: Dieser „Roboter-Editor“ war zu 97 % genau darin, zu entscheiden, was beibehalten werden soll. Das bedeutet, dass LogSieve automatisch im Hintergrund laufen kann, ohne dass ein Mensch jede Zeile lesen muss.

5. Warum das wichtig ist: Energie und Geld sparen

Das Paper betont, dass die Verarbeitung weniger Wörter Energie spart.

Die Analogie: Stellen Sie sich vor, Sie fahren einen Lkw. Wenn Sie 40 % der Ladung (die nutzlosen Log-Zeilen) entfernen, verbraucht der Lkw weniger Benzin, um ans Ziel zu kommen.
Die Auswirkung: Indem Unternehmen der KI weniger Daten zuführen, sparen sie Geld bei den Rechenkosten und reduzieren ihren CO2-Fußabdruck (Energieverbrauch).

Zusammenfassung

LogSieve ist ein Werkzeug, das die unordentlichen, verrauschten Logs von Software-Builds bereinigt, bevor eine KI versucht, sie zu lesen. Es wirft den langweiligen Teil weg und behält die wichtigen Hinweise. Dies macht die KI schneller, günstiger und umweltfreundlicher, während sie gleichzeitig in der Lage bleibt, das Rätsel zu lösen, warum die Software fehlgeschlagen ist.

Was das Paper NICHT behauptet:

Es behauptet nicht, die Softwarefehler selbst zu beheben, sondern hilft lediglich dabei, den Grund für den Fehler zu finden.
Es behauptet nicht, dass es bereits mit jeder Art von Log in der Welt funktioniert (es wurde an Android-Projekten getestet).
Es behauptet nicht, menschliche Entwickler zu ersetzen, sondern möchte ihnen helfen, indem es die Arbeit der KI erleichtert.

Technisches Resümee: LogSieve

Problemstellung

Continuous Integration (CI)-Logs, insbesondere innerhalb von Mobil-Ökosystemen wie Android, zeichnen sich durch ein hohes Volumen, Verbösiät und unstrukturiertes Rauschen aus. Obwohl sie für die Diagnose von Build-Fehlern und Leistungsregressionen essenziell sind, macht ihre schiere Größe die manuelle Inspektion und automatisierte Analyse zunehmend kostspielig, zeitaufwendig und ökologisch nicht nachhaltig. Die Einführung von Large Language Models (LLMs) für CI-Aufgaben (z. B. Fehlererklärung, Ursachenanalyse) verschärft diese Probleme, da die Inferenzkosten und die Latenz direkt mit der Eingabe-Token-Länge skalieren.

Bestehende Techniken zur Log-Reduktion konzentrieren sich primär auf „strukturorientierte“ Ziele wie Kompression, Deduplizierung oder Template-Clustering (z. B. LogZip, Drain, Spell). Während diese Methoden die Speichereffizienz und Indizierung verbessern, behalten sie oft aufgabenirrelevante Inhalte (z. B. Zeitstempel, Downloads von Abhängigkeiten, Umgebungseinrichtung) bei, die das Token-Budget aufblähen, ohne die nachgeschaltete Argumentation zu unterstützen. Im Gegensatz dazu führen LLM-basierte Reduktionsmethoden oft hohe Inferenzkosten während des eigentlichen Reduktionsprozesses zur Folge. Es besteht eine kritische Lücke in der „aufgabenbewussten“ Reduktion, die Informationen basierend auf der semantischen Relevanz für spezifische diagnostische Aufgaben (wie die Ursachenanalyse/Root Cause Analysis) filtert, bevor die LLM-Inferenz stattfindet.

Methodik

Das Paper stellt LogSieve vor, eine leichtgewichtige, Pre-Inferenz-Log-Reduktionstechnik, die darauf ausgelegt ist, CI-Logs zu filtern und dabei die semantische Treue für die nachgeschaltete LLM-Argumentation zu bewahren. Die Methodik wird durch ein vierteiliges Studiendesign mit 20 Open-Source-Android-Projekten unter Verwendung von GitHub Actions evaluiert.

1. Datenerhebung und Ground Truth

Die Autoren sammelten 9.166 GitHub-Actions-Workflow-Läufe aus 452 Android-Repositories, wobei der Fokus auf 1.806 fehlgeschlagenen Läufen lag. Eine geschichtete Zufallsstichprobe von 20 fehlgeschlagenen Workflows (einer pro Repository) wurde für eine detaillierte Analyse ausgewählt, was insgesamt 14.646 Logzeilen umfasst.

Manuelle Annotation: Zwei Co-Autoren beschrifteten jede Zeile unabhängig als RCA-relevant (1) oder RCA-irrelevant (0) basierend auf Richtlinien, die diagnostische Inhalte (Error Traces, Exceptions) gegenüber Boilerplate priorisieren. Die Inter-Rater-Reliabilität war hoch (Cohen's $\kappa = 0,80$ ).
Ground Truth: Unstimmigkeiten wurden durch Konsens gelöst, wodurch ein validierter Datensatz für Training und Evaluierung entstand.

2. LogSieve-Mechanismus

LogSieve agiert als Vorverarbeitungsschritt vor der LLM-Inferenz:

Embedding-Generierung: Logzeilen werden mittels drei Embedding-Familien in Feature-Vektoren umgewandelt: TF-IDF (lexikalisch), BERT (kontextuell) und LLaMA3 (instruktionsoptimiert).
Klassifizierung: Eine Suite von überwachten Machine-Learning-Klassifikatoren (einschließlich Logistischer Regression, SVM, Random Forest, XGBoost und LightGBM) wird trainiert, um die Relevanz jeder Zeile vorherzusagen.
Filterung: Als irrelevant klassifizierte Zeilen werden entfernt, wodurch die dem LLM übergebene Input-Token-Anzahl reduziert wird.

3. Evaluationsrahmen

Die Studie evaluiert LogSieve gegenüber zwei Baselines: LogZip (strukturbasierte Kompression) und Zufälliges Zeilenentfernen (Random-line removal).

LLM-Aufgaben: GPT-4o wurde verwendet, um zwei Aufgaben sowohl auf vollständigen als auch auf reduzierten Logs durchzuführen:
1. Fehlererklärung (Failure Explanation): Erstellung einer Zusammenfassung darüber, warum der Workflow fehlgeschlagen ist.
2. Fehlerkategorisierung (Failure Categorization): Zuweisung einer Kategorie zum Fehler.
Metriken:
- Reduktion: Prozentsatz der entfernten Zeilen und Token.
- Semantische Treue (Semantic Fidelity): Kosinus-Ähnlichkeit, BERTScore, ROUGE, BLEU und GPTScore im Vergleich der LLM-Antworten von reduzierten vs. vollständigen Logs.
- Kategorische Genauigkeit: Exact-Match-Genauigkeit für die Fehlerkategorisierung.

Zentrale Beiträge

LogSieve-Technik: Eine neuartige, RCA-bewusste Log-Reduktionstechnik, die informationsarme Zeilen filtert und gleichzeitig essenzielle Inhalte für die Fehlerdiagnose beibehält und somit die Lücke zwischen struktureller Kompression und LLM-Argumentation schließt.
Empirische Evaluierung: Eine umfassende Evaluierung an 20 Android-Projekten, die zeigt, dass LogSieve eine signifikante Größenreduktion bei minimalem semantischem Verlust erreicht.
Automatisierungsfähigkeit: Der Beleg, dass Embedding-basierte Klassifikatoren die Relevanzdetektion mit nahezu menschlicher Genauigkeit automatisieren können, was eine skalierbare Integration in CI-Workflows ermöglicht, ohne teure LLM-Inferenz während der Filterphase zu nutzen.
Nachhaltigkeitsauswirkung: Ein Nachweis, dass die Token-Reduktion vor der Inferenz die Rechenkosten und den proportionalen Energieverbrauch für die LLM-basierte CI-Analyse direkt senkt.

Ergebnisse

RQ1: Log-Größenreduktion

LogSieve erreichte eine durchschnittliche Reduktion der Logzeilen um 42 % und eine Reduktion der Token um 40 % über die 20 Repositories hinweg. Die Reduktion variierte je nach Projekt (zwischen 11 % und 85 % Zeilenreduktion), was darauf hindeutet, dass CI-Logs beträchtliche nicht-essentielle Inhalte enthalten.

RQ2: Semantische Treue

Trotz der 40%igen Token-Reduktion bewahrten die reduzierten Logs eine hohe semantische Treue für die LLM-Argumentation:

Erklärungsaufgabe: Die Kosinus-Ähnlichkeit betrug im Durchschnitt 0,93 und der GPTScore lag im Durchschnitt bei 0,93, beim Vergleich der Antworten von reduzierten vs. vollständigen Logs.
Kategorisierungsaufgabe: 80 % der Antworten aus den reduzierten Logs stimmten exakt mit der Klassifizierung der vollständigen Logs überein.
Diese Ergebnisse zeigen, dass die entfernten Zeilen weitgehend Rauschen waren, das die Fähigkeit des LLM zur Diagnose von Fehlern nicht behinderte.

RQ3: Automatisierungsleistung

Machine-Learning-Klassifikatoren konnten die Relevanz-Labeling-Aufgabe erfolgreich automatisieren:

Genauigkeit: Modelle erreichten bis zu 97 % Genauigkeit (z. B. Logistische Regression mit TF-IDF oder BERT-Embeddings, SVM mit LLaMA3-Embeddings).
Effizienz: Klassische ML-Modelle (lineare und baumbasierte Modelle) schnitten vergleichbar mit komplexeren neuronalen Modellen ab, was darauf hindeutet, dass leichtgewichtige Klassifikatoren für diese Aufgabe ausreichend sind, um den Overhead durch das Ausführen von LLMs für die Filterung zu vermeiden.

RQ4: Vergleich mit Baselines

LogSieve übertraf beide Baselines signifikant in Bezug auf die Bewahrung der semantischen und kategorischen Treue:

vs. LogZip: LogSieve erreichte eine Kosinus-Ähnlichkeit von 0,93 (vs. 0,70 für LogZip) und eine 80%ige Exact-Match-Genauigkeit (vs. 20 % für LogZip). LogZips strukturorientierter Ansatz behielt irrelevante Zeilen bei und verworf kontextuell wichtige Informationen.
vs. Zufälliges Entfernen: Während das zufällige Entfernen eine ordentliche Oberflächenähnlichkeit erreichte (Kosinus 0,90), resultierte dies in einer geringeren kategorischen Treue (70 % Exact-Match) im Vergleich zu den 80 % von LogSieve. Dies bestätigt, dass semantische Relevanz, nicht nur die reine Volumenreduktion, entscheidend für die LLM-Argumentation ist.

Bedeutung und Ansprüche

Das Paper behauptet, dass LogSieve einen praktischen Weg zu einer grüneren und interpretierbareren CI-Automatisierung bietet. Durch den Wechsel von einer „strukturorientierten“ zu einer „semantikorientierten“ Reduktion adressiert LogSieve die wachsenden ökologischen und ökonomischen Kosten der LLM-Inferenz in der Softwaretechnik.

Nachhaltigkeit: Die 40%ige Reduktion der Input-Token übersetzt sich direkt in eine proportionale Senkung des Energieverbrauchs und der Kohlenstoffemissionen, da die Inferenzkosten linear mit der Token-Anzahl skalieren.
Interpretierbarkeit: Im Gegensatz zu Kompressionsmethoden, die den Kontext verschleiern, bewahrt LogSieve die spezifischen diagnostischen Informationen, die für die Ursachenanalyse erforderlich sind.
Skalierbarkeit: Die Fähigkeit, die Relevanzdetektion mit nahezu menschlicher Genauigkeit mithilfe leichtgewichtiger Klassifikatoren zu automatisieren, ermöglicht es, LogSieve in CI-Pipelines zu integrieren, ohne signifikante Latenz oder Rechenaufwand zu verursachen.

Die Autoren kommen zu dem Schluss, dass LogSieve die Lücke zwischen Log-Management und LLM-Argumentation effektiv schließt und somit eine skalierbare Diagnose ermöglicht, ohne die Qualität der automatisierten Analyse zu beeinträchtigen. Die Studie räumt Einschränkungen hinsichtlich der Generalisierbarkeit auf andere CI-Plattformen, Sprachen und Log-Typen ein und merkt an, dass zukünftige Arbeiten adaptive Reduktionsstrategien und breitere LLM-Evaluierungen untersuchen werden.