Wo ein LLM in einem Monitoring-System wirklich hingehört

Die Aufgabe

Im Netz laufen ständig geplante Arbeiten, und gleichzeitig treten Störungen auf. Gefährlich ist die Überschneidung: Ein Trupp legt einen Ring genau dort für die Wartung still, wo der Verkehr nach einer Störung bereits auf der Reserve liegt. Das beschriebene System sucht solche Überschneidungen nach Stadt und Zeitfenster und warnt, bevor die Arbeiten beginnen.

Ereignisse kommen aus vier Quellen: Monitoring, BPMS, Firmenpostfach und manuelle Eingabe. Drei davon sind strukturiert. Die vierte nicht.

Die Regel: LLM dort, wo es kein Schema gibt

„Alles durch das Modell schicken" ist teuer - im Budget wie im Debugging. Hier arbeitet das Modell an genau einer Stelle: beim Auswerten der Schreiben externer Betreiber.

Der Grund: Diese Schreiben haben kein Schema. Ein Betreiber schreibt „planmäßige Wartung am 12.07. von 01:00 bis 05:00 Uhr, Stadt N", ein anderer hängt eine Tabelle an, ein dritter formuliert so, dass sich das Datum erst aus zwei Absätzen ergibt. Reguläre Ausdrücke scheitern daran wöchentlich, ein Modell nicht.

Alles Übrige ist gewöhnlicher deterministischer Code:

• Abfragen der Monitoring-API und Lesen der BPMS-Queue;
• Deduplizierung der Ereignisse;
• Vergleich von Zeitintervallen und Suche nach Überschneidungen;
• automatisches Schließen nicht mehr relevanter Konflikte;
• Metriken, UI, CSV/Excel-Import.

Der Vergleich zweier Intervalle ist keine Aufgabe für ein neuronales Netz. Er lautet start_a < end_b and start_b < end_a und muss montags dieselbe Antwort liefern wie freitags.

Was das bringt

Vorhersagbarkeit. Wird ein Konflikt falsch erkannt, hat die Frage „wo steckt der Fehler" eine Antwort. Entschiede das Modell, wäre die Antwort ein Achselzucken.

Kosten. Das Modell wird auf das Volumen eingehender Mails angewendet, nicht auf das Volumen der Monitoring-Ereignisse — Größenordnungen Unterschied.

Testbarkeit. Die Konflikterkennung ist durch Unit- und Integrationstests gegen eine im Container gestartete Datenbank abgedeckt. LLM-Auswertung lässt sich so nicht testen — dort prüft man nur Antwortformat und Robustheit gegen Müll am Eingang.

Die Architektur in drei Diensten

mail-agent  → IMAP → Rauschfilter → LLM → strukturiertes Ereignis ─┐
                                                                   ↓
Monitoring / BPMS / manuelle Eingabe ───────────────→ detector (Dedup, Suche nach
                                                                 Überschneidungen,
                                                                 Auto-Close)
                                                                   ↓
                                                        PostgreSQL → UI

Jeder Dienst liefert Prometheus-Metriken, Logs landen in Loki, das Datenbankschema wird über Migrationen versioniert. Langweilige Infrastruktur ist die Voraussetzung dafür, dass jemand den interessanten Teil überhaupt nutzt.

Was ich anders machen würde

Der Rauschfilter vor dem Modell hätte von Anfang an dasein sollen und nicht erst nach der ersten Token-Rechnung: Der überwiegende Teil der Firmenpost hat mit geplanten Arbeiten nichts zu tun und lässt sich mit einfachen Regeln aussortieren.