Seven simple steps for log analysis in AI systems

Dieses Papier schlägt einen standardisierten, siebenstufigen Leitfaden für die Analyse von Logs in KI-Systemen vor, der auf bewährten Praktiken basiert, durch konkrete Code-Beispiele in der Inspect Scout-Bibliothek veranschaulicht wird und Forschern eine Grundlage für rigorose und reproduzierbare Analysen bietet.

Das Wesentliche

Stell dir vor, KI-Systeme sind wie neugierige, aber manchmal chaotische Praktikanten, die in einem riesigen Büro arbeiten. Wenn sie Aufgaben erledigen (z. B. einen Code schreiben oder eine Frage beantworten), hinterlassen sie eine Spur: Notizen, abgebrochene Versuche, Fehlermeldungen und Gespräche mit dem Chef. Diese Spur nennen wir „Logs" (Protokolle).

Das Problem: Ein Praktikant kann tausende Seiten Notizen hinterlassen. Wenn du diese einfach nur durchblätterst, wirst du wahnsinnig. Du siehst die Details, aber du verstehst das große Ganze nicht.

Diese neue Anleitung von einer Gruppe von KI-Sicherheits-Experten ist wie ein Rezeptbuch für Detektive. Es erklärt, wie man aus diesem chaotischen Haufen an Notizen klare Erkenntnisse gewinnt. Hier ist die einfache Erklärung der sieben Schritte, verpackt in alltägliche Bilder:

1. Der Kompass: Was wollen wir eigentlich finden?

Bevor du überhaupt anfängst zu suchen, musst du wissen, wonach du suchst.

• Die Analogie: Stell dir vor, du bist in einem Wald. Willst du nach einem bestimmten Pilz suchen? Oder willst du herausfinden, warum der Wald so laut ist?
• In der KI: Willst du wissen, ob die KI lügt? Ob sie sich weigert, gefährliche Dinge zu tun? Oder ob sie einfach nur faul ist? Ohne diese klare Frage verlierst du dich in den Daten.

2. Das Archiv: Die Notizen ordnen

Die Notizen des Praktikanten liegen oft in verschiedenen Ordnern, manche sind unvollständig, andere sind verschmiert.

• Die Analogie: Bevor du die Akten studierst, sortierst du sie in einen ordentlichen Schrank. Du wirfst leere Blätter weg und klebst wichtige Daten (wie Datum oder Uhrzeit) auf die Rückseite.
• In der KI: Man bereitet die Log-Daten auf, entfernt Unvollständiges und macht sie suchbar. Nur so kann man später schnell finden, was man braucht.

3. Der erste Blick: Schnuppern und Staunen

Jetzt schaut man sich die Notizen an, ohne sofort zu messen.

• Die Analogie: Du gehst durch den Wald, riechst die Luft und hörst Geräusche. Du siehst: „Oh, hier hat jemand einen Ast abgebrochen" oder „Da ist ein seltsames Tier".
• In der KI: Man liest einige zufällige Gespräche der KI durch. Vielleicht fällt auf: „Aha, die KI sagt oft 'Das ist zu gefährlich' und bricht dann ab." Oder: „Sie scheint sich zu verwechseln." Das hilft, Hypothesen zu bilden.

4. Die Lupe: Die Frage schärfen

Jetzt wird aus dem vagen Gefühl eine konkrete Frage.

• Die Analogie: Statt zu sagen „Da ist etwas Seltsames im Wald", sagst du: „Ich suche nach Spuren von Füchsen, die nachts um 3 Uhr durch den Garten gelaufen sind."
• In der KI: Aus „Die KI verhält sich komisch" wird: „Wie oft weigert sich die KI, wenn sie nach Hack-Anleitungen gefragt wird?" Man definiert genau, wonach man sucht (z. B. bestimmte Wörter oder Verhaltensmuster).

5. Der Roboter-Detektiv: Den Scanner bauen

Jetzt baust du ein Werkzeug, das automatisch nach diesen Spuren sucht.

• Die Analogie: Anstatt selbst jeden Baum zu untersuchen, stellst du eine Kamera auf, die automatisch auf Füchse scharf stellt. Oder du gibst deinem Praktikanten eine Liste mit Regeln: „Wenn du das Wort 'Fuchs' hörst, mach ein Foto."
• In der KI: Man programmiert einen „Scanner" (oft eine andere, klügere KI). Dieser Scanner liest die Notizen und markiert alles, was nach einer Weigerung oder einem Fehler aussieht. Man muss dem Scanner aber genau sagen, was er tun soll (z. B. „Ignoriere höfliche 'Vielleicht'-Antworten, zähle nur das klare 'Nein'").

6. Der Prüfer: Funktioniert der Detektiv?

Bevor du dem Roboter vertraust, musst du testen, ob er gut arbeitet.

• Die Analogie: Du zeigst dem Kamera-Roboter 100 Fotos. Auf 50 davon sind Füchse, auf 50 keine. Der Roboter muss sie erkennen. Wenn er 10 Füchse übersieht, ist er nicht gut genug.
• In der KI: Menschen schauen sich die Ergebnisse des Scanners an. Hat der Scanner richtig erkannt, wann die KI lügt? Wenn nicht, muss man die Regeln für den Scanner verbessern (z. B. „Achte auch auf Sätze wie 'Ich kann das nicht tun' statt nur auf 'Nein'").

7. Die Entdeckung: Was lernen wir daraus?

Jetzt hast du verlässliche Daten. Was tun wir damit?

• Die Analogie: Du hast herausgefunden, dass Füchse immer nachts kommen. Jetzt kannst du das Tor schließen oder einen Zaun bauen.
• In der KI: Man nutzt die Daten, um die KI sicherer zu machen. Vielleicht muss man die KI neu trainieren, damit sie nicht so leicht aufgibt. Oder man erkennt, dass ein bestimmtes Tool in der Umgebung nicht funktioniert und repariert es.

Warum ist das wichtig?

Früher haben Forscher oft nur „gefühlt", wie eine KI arbeitet. Heute, wo KIs immer mächtiger werden, reicht das Gefühl nicht mehr. Man braucht harte Beweise.

Diese Anleitung ist wie eine Bauanleitung für eine Brücke. Ohne sie bauen wir Brücken, die einstürzen könnten. Mit ihr können wir sicherstellen, dass unsere KI-Systeme nicht nur clever sind, sondern auch verlässlich, sicher und ehrlich.

Kurz gesagt: Die KI hinterlässt Spuren. Diese Anleitung zeigt uns, wie wir diese Spuren nicht nur sammeln, sondern sie so lesen, dass wir die KI wirklich verstehen und verbessern können.

Technische Zusammenfassung

Problemstellung

KI-Systeme (sowohl autonome Agenten als auch Chatbots) generieren bei der Interaktion mit Werkzeugen und Nutzern enorme Mengen an unstrukturierten Log-Daten. Diese Logs enthalten wertvolle Informationen über Modellfähigkeiten, Verhaltensneigungen und die Wirksamkeit von Evaluierungen. Bisher fehlte jedoch ein standardisierter Ansatz zur systematischen Analyse dieser Daten. Die manuelle Auswertung ist bei großen Datensätzen unpraktikabel, und bestehende automatisierte Methoden (wie LLM-basierte Scanner) sind oft nicht konsistent oder wissenschaftlich rigoros genug. Es besteht ein dringender Bedarf an einem Framework, das die Transformation unstrukturierter Logs in strukturierte Daten ermöglicht, um reproduzierbare und valide Analysen durchzuführen.

Methodik: Der Sieben-Schritte-Pipeline

Das Paper schlägt einen strukturierten Pipeline-Ansatz vor, der auf aktuellen Best Practices basiert und durch die Open-Source-Bibliothek Inspect Scout (Teil des Inspect AI-Ökosystems) implementiert wird. Der Prozess gliedert sich in sieben Schritte:

1. Zweckdefinition (Define Purpose):

   • Festlegung der Forschungsfrage (primär: z. B. „Kann der Agent eine Aufgabe lösen?" oder sekundär: „Ist die Evaluierung valide?").
   • Verständnis des Kontexts (Aufgaben-Setup, Modellkonfiguration, Agenten-Scaffolding, Umgebung).

2. Vorbereitung der Log-Datenbank (Prepare Database):

   • Organisation der Logs in eine strukturierte Datenbank.
   • Filterung (z. B. unvollständige Runs entfernen), Anreicherung (Hinzufügen von Metadaten) und Standardisierung der Formate.
   • Sicherstellung der Konsistenz über verschiedene Modelle und Evaluierungsläufe hinweg.

3. Exploration der Logs (Explore Logs):

   • Manuelle Exploration: Stichprobenartige Prüfung von Transkripten (zufällig oder strategisch basierend auf Scores, Fehlern oder Länge), um Muster, Fehlermodi und Grenzen des Modells zu verstehen.
   • Automatisierte Exploration: Nutzung von Programmierung (String-Matching, Regex) oder LLMs (z. B. RAG, direkte Abfragen), um erste Muster in großen Datenmengen zu identifizieren.

4. Verfeinerung der Forschungsfrage (Refine Research Question):

   • Umwandlung der abstrakten Frage in konkrete, messbare Signale.
   • Unterscheidung zwischen umweltbedingten Faktoren (z. B. fehlende Tools) und systembedingten Faktoren (z. B. Verweigerungshaltung).
   • Definition spezifischer Signale (z. B. „direkte Verweigerung", „indirekte Verweigerung", „Tool-Fehler").

5. Entwicklung von Scannern (Develop Scanner):

   • Erstellung automatisierter Detektionsmechanismen (Scanner), meist LLM-basiert („LLM-as-a-Judge").
   • Design-Entscheidungen: Festlegung des Analyse-Levels (Chunking vs. gesamtes Transkript), Wahl des Score-Typs (binär, multi-class, quantitativ, ordinal) und Erstellung detaillierter Rubriken (Definitionen, Beispiele, „Other"-Kategorien).
   • Best Practices: Verwendung von Kontext, Anforderung von Erklärungen und Zitaten, Nutzung strukturierter Ausgabeformate (JSON).

6. Validierung des Scanners (Validate Scanner):

   • Systematische Überprüfung der Scanner-Genauigkeit gegen einen Ground Truth (manuell gelabelte Validierungsdaten).
   • Verwendung von stratifiziertem Sampling, um alle Klassen und Unsicherheitsniveaus abzudecken.
   • Berechnung geeigneter Metriken (Präzision, Recall, F1-Score, Kalibrierung) und Analyse von Diskrepanzen zwischen Scannern und menschlichen Annotatoren.

7. Nutzung der Ergebnisse (Use Results):

   • Flagging: Sofortiges Markieren kritischer Verhaltensweisen in Produktion (z. B. Sicherheitsrisiken).
   • Forschung: Transformation der Logs in strukturierte Datensätze für statistische Analysen (z. B. Korrelation von Verweigerungsraten mit Aufgaben-schwierigkeit).
   • Vermeidung von Fallstricken wie „Cherry-Picking" und Anwendung rigoroser statistischer Methoden (z. B. hierarchische Bayes-GLMs).

Schlüsselergebnisse und Fallbeispiel

Das Paper illustriert den Ansatz anhand eines Fallbeispiels aus der Cybersicherheit (Cybench-Evaluierung):

• Herausforderung: Die Modelle zeigten unerwartet niedrige Leistungen bei CTF-Aufgaben (Capture the Flag).
• Analyse: Durch manuelle Exploration wurde festgestellt, dass viele Modelle die Aufgabe verweigerten oder abbrachen, oft ohne explizite Verweigerungswörter.
• Lösung: Ein einfacher Keyword-Scanner reichte nicht aus. Es wurde ein LLM-basierter Multi-Class-Scanner entwickelt, der zwischen „Keine Verweigerung", „Teilweise Verweigerung", „Indirekte Verweigerung" und „Kritische Verweigerung" unterscheidet.
• Validierung: Der Scanner wurde mit einem menschlich gelabelten Validierungsset (25 % der Daten) getestet und erreichte eine F1-Score von 0,998 für binäre Verweigerungserkennung.
• Erkenntnis: Durch die Verfeinerung der Rubrik (Einbeziehung von Aufgabenabbruch als indirekte Verweigerung) konnte die Genauigkeit weiter gesteigert werden.

Bedeutung und Beiträge

• Standardisierung: Das Paper bietet das erste umfassende, standardisierte Framework für die Log-Analyse in der KI-Forschung, das Reproduzierbarkeit und Vergleichbarkeit fördert.
• Praktische Anwendbarkeit: Durch die Integration mit Inspect Scout wird ein sofort nutzbares Werkzeug für Forscher bereitgestellt, das den gesamten Workflow von der Datenaufbereitung bis zur Validierung abdeckt.
• Methodische Strenge: Es hebt die Notwendigkeit hervor, automatisierte Analysen durch menschliche Validierung und statistische Rigorosität zu untermauern, um Fehlinterpretationen zu vermeiden.
• Offene Fragen: Das Paper identifiziert kritische offene Forschungsfragen (z. B. optimale Stichprobengrößen, Einfluss der Transkriptlänge auf die Scanner-Genauigkeit, Vergleich von Paarvergleichen vs. absoluten Ratings), die als Roadmap für zukünftige Arbeiten dienen.

Zusammenfassend stellt dieses Paper einen essenziellen Leitfaden dar, um die wachsende Komplexität von KI-Systemen durch systematische Log-Analyse besser zu verstehen, zu evaluieren und sicherer zu gestalten.