LLM-Observability und Logging: KI-Anwendungen im Betrieb beobachten

LLM-Observability bedeutet, eine KI-Anwendung im laufenden Betrieb nachvollziehbar zu machen: Welche Anfragen kamen herein, welcher Prompt ging an das Modell, was kam zurück, wie lange hat es gedauert und was hat es gekostet? Ohne diese Daten bleiben Fehler, Kostensprünge und schlechte Antworten unsichtbar.

Was Sie protokollieren sollten

• Anfrage und Antwort: der vollständige Prompt inklusive Systemprompt und eingefügter Dokumente sowie die Antwort.
• Modell und Parameter: Modell-ID, Temperatur, Ausgabelimit, Prompt-Version.
• Token-Nutzung: Eingabe-, Ausgabe- und Cache-Tokens, bei Reasoning-Modellen auch die Denk-Tokens.
• Zeiten: Zeit bis zum ersten Token und Gesamtdauer.
• Fehler: Statuscodes, Wiederholungen, abgebrochene Antworten.
• Bewertungen: Daumen hoch oder runter, Korrekturen, Eskalationen an Menschen.

Tracing für Agenten und RAG

Bei einfachen Chat-Anwendungen reicht oft ein Eintrag pro Anfrage. Agenten und RAG-Systeme bestehen dagegen aus vielen Schritten: Suche, Reranking, mehrere Modellaufrufe, Werkzeugaufrufe. Tracing fasst alle Schritte einer Nutzeranfrage zu einer Spur zusammen. So sehen Sie etwa, dass eine falsche Antwort nicht am Modell lag, sondern an einem schlechten Suchtreffer. Für Tracing gibt es eigene Plattformen, offene Standards wie OpenTelemetry und Funktionen in vielen Agenten-Frameworks.

Vergeben Sie jeder Nutzeranfrage eine eindeutige Kennung, die durch alle Schritte weitergereicht wird. Speichern Sie außerdem, welche Prompt-Version und welche Dokumente im Einsatz waren. Nur so lässt sich eine Beschwerde wie „Gestern kam eine falsche Auskunft“ später genau nachvollziehen. Ein einfacher Anfang ist eine eigene Tabelle in der vorhandenen Datenbank; spezialisierte Werkzeuge lohnen sich, sobald Agenten mit vielen Schritten im Spiel sind.

Kennzahlen im Blick

• Kosten pro Tag und pro Anfrage: Ausreißer zeigen Schleifen, zu lange Kontexte oder Missbrauch. Mit dem KI-Kosten-Rechner lässt sich gegenrechnen, ob die Werte zur Planung passen.
• Latenz: Mittelwert und langsamste Anfragen getrennt betrachten.
• Fehlerquote: Rate-Limits und Zeitüberschreitungen.
• Qualität: Anteil negativer Bewertungen, Anteil „weiß ich nicht“, Eskalationsquote.
• Cache-Trefferquote: Bei Prompt Caching zeigt sie, ob die Ersparnis tatsächlich eintritt.

Für Grenzwerte und Warnungen bei Kosten lohnt sich auch der Ratgeber KI-Kosten überwachen.

Datenschutz beim Logging

Protokolle von KI-Anwendungen enthalten oft personenbezogene Daten: Namen in Fragen, Kundendaten in Dokumenten, Gesprächsinhalte. Für Logs gelten daher dieselben Regeln wie für die Anwendung selbst. Keine Rechtsberatung, aber typische Maßnahmen sind:

• nur protokollieren, was für Betrieb und Verbesserung nötig ist
• Aufbewahrungsfristen festlegen und alte Einträge automatisch löschen
• Zugriff auf Logs auf wenige Personen beschränken
• personenbezogene Daten vor dem Speichern maskieren, wo möglich; das Werkzeug Anonymisieren zeigt das Prinzip
• externe Observability-Dienste wie jeden anderen Auftragsverarbeiter prüfen

Aus Logs lernen

Der größte Nutzen entsteht, wenn Protokolle regelmäßig ausgewertet werden. Schlecht bewertete Antworten wandern in den Testdatensatz, häufige Fragen ohne gute Antwort zeigen Lücken in der Wissensbasis, und teure Anfragemuster zeigen Sparpotenzial. Wie Sie aus solchen Fällen automatische Tests machen, beschreibt LLM-Anwendungen testen. Zusätzlich können Sie mit Guardrails problematische Ein- und Ausgaben schon im Betrieb abfangen und protokollieren.