Die Zukunft von LLM-verfassten Incident-Reports macht mir Angst
(surfingcomplexity.blog)- In Incident-Reports sind LLMs nützlich beim Sammeln und Ordnen von Material, aber wenn man ihnen auch den eigentlichen Berichtstext überlässt, wird der Verifizierungsprozess schwächer
- Der Prozess des eigenen Schreibens sorgt dafür, dass man die Konsistenz zwischen Belegen und Erklärungen überprüft, und das Schreiben selbst dient als Mechanismus, Verständnismängel offenzulegen – LLM-generierter Text überspringt diesen Denkschritt
- LLM-Berichte können plausibel wirken, aber tatsächlich nicht vorhandene Systemkopplungen erfinden oder Interaktionen, die für den Incident wichtig waren, übersehen
- Bei Coding oder AI-SRE kann man das Ergebnis über Tests und Recovery-Ergebnisse überprüfen, doch bei Incident-Reports gibt es keinen klaren Test zur Verifikation der richtigen Antwort, weshalb fehlerhafte Berichte gefährlicher sind
- Je lästiger das Schreiben des Berichts ist, desto größer wird die Versuchung, ihn von AI erzeugen zu lassen – das Format stimmt dann zwar, aber das tatsächliche Lernen über das System kann abnehmen
Der bevorstehende LLM-verfasste Incident-Report
- Ausgehend von einem satirisch gefärbten Beitrag von Reginald Braithwaite wird darauf hingewiesen, dass ein vollständig von LLMs geschriebener Incident-Report bevorsteht
Das Schreiben von Incident-Reports ist eine reine Zeitfresser-Aufgabe, und in der Organisation hat ohnehin niemand einen Grund, dieses Dokument zu lesen. Möchten Sie dieses Problem lösen?
Begleiten Sie uns auf unserer großartigen Reise zum Bau eines AI-Ops-Tools, das Incident-Reports für AI schreibt, damit diese sie lesen und selbstständig handeln kann. Außerdem fasst dieses Tool die Reports auch noch zusammen, sodass beschäftigte Menschen nicht jedes kleine Detail lesen müssen.- Der Beitrag war spöttisch gemeint, doch eine solche Zukunft wird sehr wahrscheinlich dennoch eintreten
- Für gute Incident-Reports fällt viel toil an, um die nötigen Daten zusammenzutragen, und es gibt kaum Widerspruch dazu, dass LLMs diese Last stark verringern können
- Allerdings besteht ein großer Unterschied zwischen dem Sammeln des Materials, das man zum Schreiben eines Reports braucht, und dem Schreiben des Reports selbst durch ein LLM
- Gerade die Versuchung (seduction) von LLMs nach dem Motto „Man bittet einfach darum, und es schreibt“ ist der beängstigende Punkt
Welche Rolle Schreiben für das Denken spielt
- Ein Ausspruch des Cartoonisten Dick Guindon: „Schreiben ist die Art der Natur, dir zu zeigen, wie schlampig dein Denken ist.“
- Selbst wenn man glaubt, ein Konzept verstanden zu haben, merkt man oft erst beim Versuch, es tatsächlich schriftlich zu erklären, wie vage das eigene Verständnis ist
- Das Schreiben in eigenen Worten zwingt einen dazu, sich dem tatsächlichen Grad des eigenen Verständnisses zu stellen
- Leslie Lamport sagte: „Wenn Sie denken, ohne zu schreiben, machen Sie sich nur vor, dass Sie denken.“
- Wenn ein LLM den Text eines Incident-Reports generiert, wird dieser Denkschritt (thinking step) umgangen
- Der menschliche Prüfer (human in the loop), der sich damit auseinandersetzt, ob die Erklärung wirklich mit den gesammelten Belegen übereinstimmt, verschwindet
Risiken von LLM-generierten Berichten
- Das Ergebnis bleibt oft nur eine plausibel wirkende Erklärung für Menschen, die mit den Details nicht vertraut sind
- Leser können nicken und denken: „Klingt plausibel.“
- Doch LLMs können nicht existierende Verbindungen zwischen Systemen (couplings) erfinden oder entscheidende Interaktionen des Incidents auslassen
- Weil niemand die Daten selbst synthetisiert hat, bemerkt diese Fehler womöglich niemand
- Wenn das Ziel darin besteht, den Schreibaufwand zu verringern, wird zwangsläufig auch der Aufwand für die Verifikation der LLM-Ergebnisse gering ausfallen
Vergleich mit Coding und AI-SRE
- LLM-generierte Incident-Reports gelten hier als gefährlicher als Coding oder AI-SRE-Arbeit
- Bei Coding-Arbeit gibt es, selbst wenn man den Code nicht direkt im Detail prüft, immer eine Testphase, in der überprüft wird, ob das gewünschte Verhalten erreicht wird
- Bei AI-SRE-Arbeit zeigt sich unmittelbar, ob die Ausgabe des LLM beim Lösen eines Incidents hilft oder nicht
- In beiden Fällen fungiert die „Natur“ als letzte Instanz für die Ausgabe des LLM
- Bei Incident-Reports werden die negativen Folgen schlechter Ergebnisse hingegen nicht sofort sichtbar
- Es entsteht ein Bericht, der oberflächlich das richtige Format hat, in Wirklichkeit aber falsch ist, und es gibt keinen klaren Test zur Überprüfung seiner Genauigkeit
Weniger Gelegenheiten zum Lernen
- Da das Schreiben von Berichten viel Zeit kostet, wird die Versuchung, AI-Tools zu verwenden, überwältigend sein
- Ein LLM spricht jedoch nicht direkt mit den Menschen, die am Incident beteiligt waren
- Solche Berichte werden zu bloßen Simulakren (simulacra) mit formaler Gestalt, ohne den Lesern echte Einsichten in das Wesen des Systems zu vermitteln
- In der Folge nimmt das Ausmaß des Lernens stark ab
- Es ist zudem wahrscheinlich, dass Menschen solche erzeugten Berichte anschließend erneut von AI zusammenfassen lassen
„Auf so eine Zukunft freue ich mich nicht.“
1 Kommentare
Lobste.rs-Kommentare
Vor ein paar Monaten gab es bei der Arbeit einen Sicherheitsvorfall, dessen Ursache eine von KI überprüfte Vibe-Coding-Funktion war, und leider scheint sich diese Vorgehensweise zunehmend als Standard zu etablieren.
Ich habe vor dem eigentlichen Meeting das Postmortem-Dokument gelesen, und es war in sich widersprüchlich. In einem Absatz stand, das Konfliktrisiko sei gering, in einem anderen, ein Konflikt sei garantiert.
Im Meeting fragte ich den Engineer, der das Postmortem leitete: „Was von beidem stimmt denn?“ Darauf antwortete er: „Ich weiß es nicht!“ Als ich nachfragte: „Was soll das heißen? Sie haben das doch geschrieben!“, sagte er: „Nein … mein Agent hat das geschrieben!“
KI zu benutzen, ohne die Ausgabe überhaupt zu verstehen, und das eigene Denken auszulagern, ist ein wirklich schwerwiegender Fehler, und wenn das so weitergeht, wäre das aus meiner Sicht sogar ein Kündigungsgrund.
Ich befürchte, das wird noch schlimmer werden. Zum einen betrachten Leute — egal ob SREs, Entwickler oder sonst wer — Vorfallsberichte nicht als Gelegenheit, zu verstehen, was tatsächlich Auswirkungen auf die Zuverlässigkeit des Systems hatte, sondern nur als ein weiteres Kästchen zum Abhaken.
Allein das reduziert meiner Meinung nach schon den Nutzen von Berichten oder Postmortems erheblich.
Dazu kommt ein Zweitrundeneffekt. Unternehmen werben damit, solche Berichte als Trainingsmaterial zu verwenden, zugeschnitten auf „bestimmte Architekturen“ und „einzigartige Konfigurationen“. Dadurch halluzinieren Modelle noch mehr und präsentieren diese Halluzinationen dann als Fakten. Schlimmer noch: Sie haben dann sogar einen Beleg dafür, dass diese „Fakten“ tatsächlich dokumentiert waren.
Außerdem sieht man die Tendenz, nach bestimmten Alerts einfach Prompting oder irgendwelche Skills laufen zu lassen, das Ergebnis unverändert einzufügen und dann zu sagen: „Das ist passiert.“ In ein paar Monaten werden einige dieser Leute Vorfälle wahrscheinlich nicht einmal mehr vernünftig diagnostizieren können, wenn ihr Agent ihnen nicht an die Hand nimmt.
Ich stimme dem ganzen Artikel zu, aber der Vergleich mit Code ist meiner Meinung nach nicht ganz passend.
Im Artikel heißt es, dass es bei Code-Arbeit einen Testschritt gibt, um zu prüfen, ob das gewünschte Verhalten erreicht wird, während bei Vorfallsberichten die Folgen eines schlechten Berichts nicht sofort sichtbar werden und dadurch Berichte entstehen, die oberflächlich formal korrekt wirken, in Wirklichkeit aber falsch sind.
Aber bei Code von mehr als trivialem Umfang gibt es auch Faktoren wie Design, Performance und Latenz, und die lassen sich immer schwerer mit einem simplen Bestanden-/Nicht-bestanden-Kriterium erfassen.
Auch die Folgen von schlecht geschriebenem Code sind für ein ungeschultes Auge oder aus einer rein ergebnisorientierten Perspektive nicht sofort sichtbar. Wenn man etwas in Rekordzeit ausliefert, jubeln alle und klatschen sich ab.
Dann kommt die nächste Person, versucht das Ganze zu verstehen oder Edge Cases zu debuggen, und wird langsamer. Die Person danach wird wieder langsamer. Weil die zweite Person statt einer konsistenten Lösung nur Workarounds drangehängt hat — und so setzt sich das fort.
Bei uns hat jemand bei der Arbeit einen Trigger gebaut, der für jede Slack-Benachrichtigung einen Thread erstellt und dort einen langen, von einem LLM geschriebenen Text mit Root-Cause-Analyse, nächsten Schritten und Ähnlichem postet.
Wenn man auf einen Alert reagieren muss, ist es überhaupt nicht hilfreich, so ein Geschwafel lesen zu müssen, aber es sieht auch nicht so aus, als würde das gestoppt werden — aus Gründen wie „Das ist die Zukunft“.
Ich sehe das ein bisschen als eine Büchse der Pandora. Die Büchse ist bereits geöffnet, wir können das nicht mehr kontrollieren, also müssen wir es lieber so steuern, dass es besser wird.
Wenn die entstehenden Dokumente voller KI-Müll sind, muss man in eine andere Richtung gegensteuern. Weg von überbreiter Geschwätzigkeit, langen Listen von Beispielen und Formulierungen wie „nicht x, sondern y“.
Der Gedanke „gib mir einfach nur den Prompt“ lässt sich auch auf LLMs ausdehnen. So nach dem Motto: „Wenn jemand beim Lesen dieser Ausgabe am liebsten fragen würde: ‚Gib mir einfach nur den Prompt‘, dann ist es ein Fehlschlag.“
Ich denke, wir befinden uns noch im Abschnitt des Uncanny Valley dieser Kurve. Die Prosa ist gut genug, um plausibel zu wirken, aber nicht gut genug, um sich wie von einem Menschen geschrieben anzufühlen. In etwa 2 Jahren (+/-2 Jahre) könnte sie in eine Richtung optimiert sein, die man tatsächlich lesen möchte, und Ergebnisse liefern, die schwer von menschlichen Texten zu unterscheiden sind.
Entscheidend ist, dass der Prozess des eigenen Schreibens eines Berichts beim Verfasser selbst Lernen erzeugt — und dass dieses Lernen nicht auf dieselbe Weise entsteht, wenn man den Bericht generieren lässt.
Es gibt die Aussage: „Braithwaites Artikel ist voller Satire, aber vollständig von LLMs geschriebene Vorfallsberichte werden definitiv kommen“ — aber es fühlt sich an, als würden wir schon seit geraumer Zeit genau in dieser Realität leben.
Vorfallsberichte gehören zu den Texten, bei denen am offensichtlichsten erkennbar ist, dass sie von LLMs erzeugt wurden. Das liegt daran, dass Sicherheitsforscher unter dem Druck stehen, früher als andere zu veröffentlichen.
Ich bin bereits in der Lage, offenkundig von KI geschriebene Systemdesign-Dokumente lesen zu müssen, und manchmal wollte ich sie einfach ablehnen.
Wenn mich jemand bittet, ein riesiges Dokument zu lesen, in das offensichtlich kaum Mühe geflossen ist, empfinde ich das buchstäblich als Beleidigung.