KI-Anwendungen auf Basis von Sprachmodellen verhalten sich fundamental anders als klassische Software. Sie produzieren keine vorhersehbaren Ausgaben, reagieren sensibel auf Prompt-Formulierungen und können bei identischen Eingaben zu unterschiedlichen Zeiten unterschiedliche Ergebnisse liefern. Das stellt Teams, die für Betrieb und Qualität solcher Systeme verantwortlich sind, vor neue Herausforderungen. Klassisches Monitoring reicht hier nicht aus – LLM-Observability ist ein eigenes Fachgebiet.
Warum Standard-Monitoring bei LLMs versagt
In klassischer Software sind Fehler klar: Ein HTTP 500 ist ein Fehler, eine Latenz über 2 Sekunden ist problematisch, ein leeres Array ist unerwünscht. Bei Sprachmodellen ist das schwieriger: Das System antwortet mit HTTP 200, die Latenz ist akzeptabel – aber die Antwort ist falsch, halluziniert oder nicht auf die gestellte Frage bezogen.
Ein LLM, das auf eine Support-Anfrage antwortet und dabei eine Funktion eines Produkts erfindet, die nicht existiert, produziert einen stillen Fehler. Kein Alert, kein Log-Error, keine Exception – nur ein Nutzer, der falsch informiert wurde. Traditionelle Monitoring-Stacks erkennen das nicht.
Die vier Dimensionen der LLM-Observability
1. Tracing: Der Weg einer Anfrage durch das System
Moderne LLM-Anwendungen sind selten einfach ein Prompt und eine Antwort. Sie bestehen aus Chains: Der Nutzer stellt eine Frage, ein Retrieval-Schritt holt relevante Dokumente (RAG), das LLM generiert eine Antwort, ein zweiter Schritt validiert diese, ein dritter formatiert sie. Tracing macht diesen Weg sichtbar.
OpenTelemetry hat mit den GenAI Semantic Conventions einen Standard für LLM-Tracing definiert. Damit lassen sich folgende Daten erfassen:
- Input-Prompt (sanitisiert, ohne personenbezogene Daten)
- Output-Completion – was das Modell zurückgegeben hat
- Modell-Metadaten: Modell-ID, Version, Parameter (Temperatur, max_tokens)
- Token-Usage: Input-Tokens, Output-Tokens, Gesamtkosten
- Latenz pro Schritt – besonders wichtig: Time to First Token (TTFT)
- Retrieval-Kontext: welche Chunks aus der Vektordatenbank abgerufen wurden
Tools wie Langfuse, Helicone, Arize Phoenix oder das OpenLLMetry-Paket ermöglichen dieses Tracing mit wenigen Zeilen Instrumentierungscode und leiten die Daten an bestehende Observability-Backends (Grafana, Jaeger, Honeycomb) weiter.
2. Metriken: Was messbar ist, kann überwacht werden
Folgende Metriken sollte jede produktive LLM-Anwendung im Dashboard haben:
- TTFT (Time to First Token): Wie lange dauert es, bis das Modell zu antworten beginnt? Bei Streaming-Interfaces ist das die für Nutzer wahrgenommene Latenz.
- Totale Completion-Latenz: Gesamtdauer vom API-Call bis zur vollständigen Antwort.
- Token-Throughput: Tokens pro Sekunde – relevant für Kostenschätzungen und Kapazitätsplanung.
- Kostenmetriken: Kosten pro Anfrage, Kosten pro Nutzer, Kosten nach Endpunkt.
- Error-Rate: Rate-Limit-Fehler, Timeout-Fehler, Parsing-Fehler.
- Completion-Length-Distribution: Wie lang sind Antworten typischerweise? Starke Abweichungen können auf Modellfehler hindeuten.
3. Qualitäts-Evaluation: Das Kernproblem der LLM-Observability
Latenz und Fehlerraten sind einfach. Das wirklich Schwierige ist die Qualitätsbewertung. Ist die Antwort korrekt? Ist sie hilfreich? Enthält sie Halluzinationen? Ist sie auf die Frage bezogen?
Dafür gibt es verschiedene Ansätze:
- LLM-as-Judge: Ein zweites Modell bewertet die Ausgabe des ersten. Günstig zu implementieren, aber selbst fehleranfällig.
- Referenz-basierte Evaluation: Ausgaben werden gegen erwartete Antworten aus einem Ground-Truth-Datensatz gemessen.
- Faithfulness-Score: Misst, ob die Antwort durch den gelieferten Kontext gestützt wird – wichtig für RAG-Systeme, um Halluzinationen zu erkennen.
- Nutzerfeedback: Thumbs up/down-Signale direkt in der App, rückgekoppelt ins Observability-System.
In der Praxis kombinieren Teams diese Methoden: Automatische LLM-as-Judge-Evaluation für alle Anfragen (gesampled auf 5-10 %), detailliertere Evaluation für geflagte Anfragen und regelmäßige manuelle Reviews.
4. Sicherheits-Monitoring: Prompt Injection und Missbrauch
Eine Dimension, die bei klassischer Software keine Rolle spielt, ist das Monitoring auf missbräuchliche Eingaben. Prompt Injection – der Versuch, durch spezielle Formulierungen das Modell zu unerwünschtem Verhalten zu bringen – ist ein reales Risiko für produktive LLM-Anwendungen.
Monitoring-Ansätze hierfür:
- Klassifizierungsmodell, das Prompts auf bekannte Injection-Muster prüft
- Logging von Prompts, die bestimmte Schlüsselwörter enthalten
- Rate-Limiting und Anomalie-Erkennung auf ungewöhnlich lange oder strukturell auffällige Prompts
- Output-Monitoring auf Policy-Verletzungen
Infrastruktur für LLM-Observability
Für Teams, die bereits einen Observability-Stack betreiben, empfiehlt sich die Integration über OpenTelemetry. Die GenAI Semantic Conventions für Traces und Metriken sind seit 2025 stabil und ermöglichen es, LLM-Daten in bestehende Backends (Grafana, Honeycomb, Datadog) zu leiten, statt ein weiteres Tool einzuführen.
Für Teams, die neu starten, bieten spezialisierte Tools wie Langfuse (Open Source, selbst hostbar) oder Helicone einen schnelleren Einstieg mit LLM-spezifischen Dashboards out-of-the-box.
Kostenüberwachung: Der unterschätzte Aspekt
Neben Qualität und Verfügbarkeit ist die Kostenkontrolle ein zentrales Thema bei produktiven LLM-Anwendungen. Tokenbasierte Abrechnung kann bei skalierendem Traffic schnell unübersichtlich werden. Observability-Systeme sollten daher auch Kostenmetriken pro Endpunkt, pro Nutzergruppe und pro Anwendungsfall aufzeichnen. Nur so lassen sich teure Prompts identifizieren und optimieren.
Praktische Umsetzung in drei Schritten
- Instrumentierung einrichten: OpenTelemetry-SDK mit GenAI Semantic Conventions oder Langfuse SDK in die Anwendung integrieren
- Dashboard bauen: Kernmetriken (TTFT, Latenz, Token-Kosten, Error-Rate) in Grafana oder im Langfuse-Dashboard sichtbar machen
- Alerting konfigurieren: Alertregeln für Latenz-Ausreißer, hohe Error-Rates und Kostenspitzen einrichten
Fazit
LLM-Observability ist kein Nice-to-have, sondern Betriebsvoraussetzung für produktive KI-Anwendungen. Die Kombination aus Tracing, Metriken, Qualitäts-Evaluation und Sicherheits-Monitoring schafft die Sichtbarkeit, die Teams brauchen, um Probleme frühzeitig zu erkennen, die Qualität kontinuierlich zu verbessern und Kosten im Griff zu halten. Wer heute LLM-Anwendungen ohne Observability betreibt, fliegt blind.
Bildquelle: Pexels / Christina Morillo (Foto-ID 1181671) – Lizenz: Pexels Free License
Quellen: OpenTelemetry GenAI Semantic Conventions – https://opentelemetry.io/docs/specs/semconv/gen-ai/; Langfuse – https://langfuse.com; Helicone – https://www.helicone.ai; Arize Phoenix – https://phoenix.arize.com
