LLMs und KI-Systeme in Produktion überwachen: Observability für KI-Anwendungen

KI-Visualisierung mit leuchtendem Netzwerk als Symbol für Observability und Monitoring von KI-Systemen in Produktion

Sprachmodelle und KI-Systeme sind mittlerweile in vielen Produktionsumgebungen angekommen: als interne Assistenten, als Teil von Kundenprodukten, als automatisierte Entscheidungshelfer in Workflows. Was dabei oft übersehen wird: Diese Systeme brauchen Observability – genauso wie jeder andere kritische Dienst.

Wer ein LLM in Produktion betreibt, stellt schnell fest, dass klassische Monitoring-Ansätze nicht ausreichen. CPU-Auslastung, Speicherverbrauch und HTTP-Statuscodes sind sinnvoll zu messen – aber sie sagen wenig darüber aus, ob das Modell tatsächlich korrekte, nützliche und sichere Antworten liefert. Dafür braucht es eine erweiterte Observability-Strategie, die auf die spezifischen Eigenschaften von KI-Systemen zugeschnitten ist.

Warum KI-Systeme besonderer Überwachung bedürfen

Klassische Software verhält sich deterministisch: Dieselbe Eingabe erzeugt immer dieselbe Ausgabe. LLMs sind probabilistisch: Dieselbe Anfrage kann zu unterschiedlichen Antworten führen, und das Verhalten kann sich im Laufe der Zeit verändern – durch Modell-Updates, durch veränderte Nutzungsmuster, durch Prompt-Injection-Versuche oder durch Verteilungsverschiebungen in den Eingabedaten (sogenanntes Concept Drift).

Das macht herkömmliche Monitoring-Ansätze unvollständig. Es reicht nicht zu wissen, dass der API-Endpunkt antwortet. Die entscheidenden Fragen lauten: Antwortet das Modell sinnvoll? Halluziniert es häufiger als zuvor? Werden bestimmte Arten von Anfragen systematisch schlechter beantwortet? Wird das System für unerwünschte Zwecke missbraucht?

Die wichtigsten Metriken für LLM-Observability

Latenz und Throughput

Wie schnell generiert das Modell seine Antwort? Bei LLMs ist Latenz mehrdimensional: Es gibt die Zeit bis zum ersten Token (Time to First Token, TTFT) – also wie lange es dauert, bis die Ausgabe beginnt – und die gesamte Generierungszeit. Für interaktive Anwendungen ist TTFT oft die entscheidende Größe, weil Nutzer das Warten auf den Beginn einer Antwort als besonders belastend empfinden. Durchsatz (Throughput) in Tokens pro Sekunde ist relevant, wenn viele parallele Anfragen bedient werden müssen.

Token-Nutzung

Token-Verbrauch ist bei API-basierten Modellen direkt mit Kosten verbunden. Monitoring der Input- und Output-Token-Zahlen über Zeit zeigt nicht nur, wie sich die Kosten entwickeln, sondern kann auch auf Anomalien hinweisen: Plötzlich stark steigende Kontextlängen können auf missbrauchte Anfragen oder fehlerhafte Prompt-Konstruktionen hindeuten. Histogramme der Token-Verteilung über alle Anfragen helfen, Ausreißer zu erkennen.

Fehlerrate und Statuscodes

Neben HTTP-Fehlern (Rate Limiting, Timeouts, Serverprobleme) gibt es bei LLMs modellspezifische Fehler: Inhaltsfilter-Ablehnungen, Kontext-Überschreitungen, Sicherheitswarnungen. Diese sollten separat erfasst werden, weil sie auf inhaltliche Probleme hinweisen, die weit über reine Verfügbarkeit hinausgehen.

Antwortqualität (Output Quality)

Das ist die schwierigste Dimension, aber die wichtigste. Was bedeutet eine „gute" Antwort? Je nach Anwendungsfall kann Qualität unterschiedlich definiert sein: Korrektheit bei Faktenfragen, Formatkonformität bei strukturierten Ausgaben, Relevanz bei Such-Augmented-Anwendungen oder Ton und Stil bei Kundenkommunikation. Monitoring-Strategien für Ausgabequalität umfassen: Nutzer-Feedback-Signale (Daumen hoch/runter), automatisierte Evaluierungen durch ein zweites Modell (LLM-as-Judge), regelbasierte Plausibilitätsprüfungen und statistische Drift-Erkennung bei Ausgabe-Charakteristika.

Retrieval-Qualität bei RAG-Systemen

In Retrieval-Augmented-Generation-Architekturen (RAG) – bei denen ein LLM externe Dokumente oder Datenbanken abfragt, bevor es antwortet – ist die Qualität des Retrieval-Schritts entscheidend. Wird das richtige Dokument gefunden? Wie ähnlich ist es zur Anfrage? Wie viele Tokens werden für den Kontext verbraucht? Diese Metriken sollten separat neben den Sprachmodell-Metriken erfasst werden.

Tracing in KI-Pipelines

Moderne KI-Anwendungen sind selten monolithisch. Ein typischer RAG-Workflow besteht aus mehreren Schritten: Anfrage verarbeiten, Embedding berechnen, Vektor-Datenbank abfragen, Kontext zusammenstellen, LLM aufrufen, Antwort nachbearbeiten. Klassisches Distributed Tracing – mit einem Span pro Schritt – lässt sich auf diese Pipelines anwenden und macht sichtbar, wo Zeit verloren geht und wo Fehler entstehen.

OpenTelemetry-Instrumentierung ist hier ein sinnvoller Standard. Viele LLM-Frameworks wie LangChain, LlamaIndex oder Haystack bieten inzwischen native OpenTelemetry-Integrationen oder Callbacks, mit denen Traces automatisch erzeugt werden. Das Ergebnis: ein vollständiger Überblick über den Weg einer Anfrage durch die gesamte KI-Pipeline.

Halluzinierungsmonitoring: Realistisch bleiben

Halluzinierungen – das Generieren faktisch falscher, aber plausibel klingender Inhalte – sind ein strukturelles Merkmal von Sprachmodellen. Sie lassen sich reduzieren, aber nicht vollständig eliminieren. Für produktive KI-Systeme bedeutet das: Monitoring auf Halluzinierungsanzeichen ist wichtig, sollte aber realistisch kalibriert sein.

Automatisierte Halluzinierungserkennung kann auf verschiedene Weisen erfolgen: Faktenprüfung gegen externe Datenquellen (bei eingeschränkten Domänen machbar), Konsistenzprüfung (fragt man dasselbe auf zwei verschiedene Weisen, kommen widersprüchliche Antworten?), Confidence-Schätzungen oder Retrieval-Abgleich bei RAG-Systemen. Keiner dieser Ansätze ist perfekt, aber eine Kombination gibt ein nützliches Signal über die Qualitäts-Baseline des Systems.

Sicherheits-Observability: Prompt Injection und Missbrauch

LLMs sind ein Angriffsziel. Prompt-Injection-Versuche – bei denen Nutzer durch manipulierte Eingaben versuchen, das Modell zu unerwünschtem Verhalten zu bringen – sind real und kommen in Produktionssystemen vor. Monitoring sollte diese Versuche sichtbar machen:

Inhaltsfilter-Logs: Wie viele Anfragen werden abgelehnt, und welche Muster zeigen sie?
Anomalie-Erkennung bei Eingaben: Ungewöhnlich lange Kontexte, ungewöhnliche Zeichenmuster oder häufige Wiederholungen können auf Injection-Versuche hinweisen.
Rate Limiting pro Nutzer: Monitoring der Anfragehäufigkeit pro Account oder Session, um automatisierte Missbrauchs-Versuche zu erkennen.

Observability-Werkzeuge für LLM-Systeme

Der Markt für LLM-Observability-Werkzeuge hat sich seit 2024 erheblich entwickelt. Spezialisierte Plattformen wie Langfuse, LangSmith (von LangChain), Phoenix von Arize AI oder Helicone bieten LLM-spezifische Dashboards, Trace-Visualisierungen und Evaluierungs-Frameworks. Bestehende Observability-Plattformen wie Datadog, New Relic und Grafana haben KI-spezifische Dashboards und Integrationen hinzugefügt.

Für Teams, die bereits eine Observability-Infrastruktur betreiben, ist die Integration via OpenTelemetry oft der sinnvollste Weg: LLM-Spans werden neben regulären Service-Spans sichtbar, und Korrelationen zwischen KI-Systemverhalten und der umgebenden Infrastruktur werden direkt im vertrauten Dashboard erkennbar.

Uptime-Monitoring für KI-Dienste

Auch bei KI-Diensten gilt: Verfügbarkeit ist die Grundlage. Wer externe Modell-APIs (wie OpenAI, Anthropic oder Google) nutzt, ist von der Verfügbarkeit dieser Dienste abhängig. Heartbeat-Checks gegen API-Endpunkte, verbunden mit Statusseiten der Anbieter, geben Frühwarnung bei Ausfällen. Für interne Modelldienste – etwa selbst gehostete Open-Source-Modelle – sind HTTP-Checks gegen den Inference-Endpunkt das Mindestmaß.

Wichtig ist auch das Monitoring von Abhängigkeiten: Vektordatenbanken, Embedding-Services, externe Wissensquellen. Ein RAG-System kann nicht korrekt antworten, wenn die Vektordatenbank nicht erreichbar ist – auch wenn der LLM-Endpunkt selbst reagiert. Das vollständige System muss in den Monitoring-Scope.

Fazit

KI-Systeme in Produktion zu betreiben, ohne sie zu überwachen, ist wie ein Flugzeug ohne Instrumente zu fliegen. Klassische Infrastruktur-Metriken sind notwendig, aber nicht hinreichend. LLM-spezifische Observability – Token-Nutzung, Ausgabequalität, Tracing über KI-Pipelines, Sicherheitssignale – ist der Schlüssel zu einem belastbaren KI-Betrieb.

Der gute Einstieg: Mit Latenz, Token-Nutzung und Fehlerrate beginnen. Tracing über OpenTelemetry aufbauen. Dann schrittweise Ausgabequalitäts-Signale ergänzen – Nutzerfeedback zuerst, automatisierte Evaluierungen danach. Uptime-Checks auf alle kritischen Abhängigkeiten ausweiten. So entsteht schrittweise eine vollständige Sicht auf KI-Systeme, die weit über „der Endpunkt antwortet" hinausgeht.

Bildquelle: Pexels / Tara Winstead