Observability für LLM-Apps: Tracing, Kosten, Latenz und Qualitätsdrift

LLM-Anwendungen behalten die üblichen Ausfallmuster von Software bei und ergänzen sie um probabilistische Ausgaben, Modell- und Prompt-Drift, Toolverhalten, Retrieval-Qualität sowie nutzungsabhängige Kosten. Einige Fehler erzeugen Stack-Traces; andere werden nur in evaluierten Ausgaben, Nutzerberichten oder veränderten Verteilungen sichtbar.

Herkömmliche Observability (Datadog, New Relic, Sentry) zeigt Ihnen, dass der API-Aufruf nach 8,4 Sekunden erfolgreich abgeschlossen war und 12.847 Eingabetoken verbraucht hat. Sie verrät jedoch nicht, ob die Antwort gut war, ob das Modell halluziniert hat, ob das falsche Tool aufgerufen wurde oder ob sich die Qualität seit der Vorwoche verschlechtert hat.

LLM-Systeme im Produktivbetrieb benötigen zusätzlich zu den üblichen Traces, Metriken und Protokollen semantische Daten. Beginnen Sie mit den semantischen OpenTelemetry-Konventionen für generative KI und erweitern Sie diese nur dort, wo Ihr Produkt weitere Details benötigt. Dieser Artikel beschreibt eine beispielhafte Ereignisstruktur; AIExpert hat weder einen Trace aus dem Produktivbetrieb noch ein Dashboard veröffentlicht, das jedes der folgenden Felder belegt.

Was unterscheidet LLM-Observability?

Einige typische Eigenschaften von LLM-Systemen werden durch herkömmliche Observability nicht abgedeckt:

Nichtdeterminismus auf Ebene einzelner Aufrufe. Dieselbe Eingabe erzeugt bei verschiedenen Aufrufen unterschiedliche Ausgaben. Die Frage „Hat das richtig funktioniert?“ lässt sich nicht allein durch die Prüfung von Statuscodes beantworten.

Qualität als zentrale Metrik. Latenz und Kosten sind wichtig, doch Qualität ist am wichtigsten und zugleich am schwersten zu messen.

Mehrstufige Traces. Eine Benutzeranfrage kann mehrere Modell-, Retrieval- und Tool-Aufrufe auslösen. Jeder Vorgang gehört zu einem größeren Trace.

Nutzungsabhängige Kosten. Die Kosten variieren je nach Modell, Tokenanzahl, Caching, Tools und anbieterspezifischen Gebühren. Ordnen Sie die tatsächlich abgerechnete Nutzung einzelnen Aufrufen oder Batches zu, statt eine allgemeingültige Kostenspanne pro Aufruf anzunehmen.

Drift im Zeitverlauf. Modelle werden aktualisiert. Prompts entwickeln sich weiter. Eingabeverteilungen verschieben sich. Auch die Qualität verändert sich; diese Entwicklung muss sichtbar werden.

Sensible Payloads. Ein- und Ausgaben sind häufig die wertvollsten Diagnosedaten, zugleich aber auch die sensibelsten. Deshalb ist eine strenge Protokollierungsdisziplin erforderlich.

Lange asynchrone Abläufe. Agentenläufe, die Minuten dauern. Batch-Aufträge im Hintergrund. Streaming-Antworten. Herkömmliche Request/Response-Observability passt hier nicht.

Die Instrumentierung soll diese Ausfallmuster sichtbar machen. Welche davon in Ihrem System überwiegen, müssen Sie anhand des eigenen Datenverkehrs feststellen.

Der Observability-Stack

Ein praxistaugliches Konzept für LLM-Observability kann je nach Aufgabe und Risiko folgende Ebenen umfassen:

1. Instrumentierung auf Aufrufebene. Jeder LLM-Aufruf erzeugt freigegebene Betriebsmetadaten wie Latenz, abgerechnete Nutzung, Modell oder Revision und Status. Rohe Ein- oder Ausgaben werden nur erfasst, wenn dies gesondert begründet und kontrolliert wird.

2. Instrumentierung auf Trace-Ebene. Workflows mit mehreren Aufrufen werden zu Traces zusammengeführt. So lässt sich die vollständige Aufrufkette einer Nutzeranfrage nachvollziehen.

3. Metriken auf Anwendungsebene. Aggregationen pro Funktion, Nutzer und Mandant.

4. Qualitätsüberwachung. Stichprobenweise oder vollständige automatisierte Qualitätsbewertung.

5. Erfassung von Nutzerfeedback. Explizite Signale (Daumen hoch oder runter) und implizite Signale (erneut generieren, abbrechen).

6. Warnmeldungen. Echtzeitwarnungen bei Kostenspitzen, höherer Latenz, sinkender Qualität und steigenden Fehlerquoten.

7. Debugging-Werkzeuge. Wenn etwas fehlschlägt, können autorisierte Verantwortliche genau die minimal erforderlichen und freigegebenen Nachweise untersuchen. Rohe Ein- und Ausgaben sind weder garantiert noch grundsätzlich verfügbar.

Wir gehen jeden Punkt durch.

Instrumentierung auf Aufrufebene

Jeder LLM-Aufruf sollte einen freigegebenen Metadatensatz erzeugen. Die kommentierten Payload- und Identitätsfelder im folgenden Beispiel sind optionale sensible Felder, keine Standardwerte:

{
  "call_id": "uuid",
  "timestamp": "2026-08-04T14:23:45Z",
  "trace_id": "uuid",  // for grouping into traces
  "span_id": "uuid",   // for parent-child relations
  "feature": "summarize_document",
  "prompt_version": "v3.2",
  "model": "provider-model-revision",
  "provider": "anthropic",
  "input_messages": null,  // optional; approved sampled/redacted payload only
  "output_message": null,  // optional; approved sampled/redacted payload only
  "input_tokens": 1842,
  "output_tokens": 384,
  "total_tokens": 2226,
  "cost_usd": 0.0084,
  "latency_ms": 2340,
  "first_token_ms": 1240,  // streaming
  "status": "success",
  "error": null,
  "subject_ref": "pseudonymous_ref",  // optional, purpose-specific lookup
  "tenant_ref": "tenant_scoped_ref",
  "metadata": {
    "session_id": "...",
    "experiment_arm": "v3_test"
  }
}

Dies ist ein beispielhaftes Anwendungsereignis, kein verbindliches Schema. Erfassen Sie nur das Minimum, das für einen definierten betrieblichen Zweck benötigt wird. Rohe Prompts und Ausgaben sind optionale sensible Payloads, keine Standardtelemetrie.

Wichtige Implementierungsentscheidungen:

Wo protokollieren? Optionen:

• Ein dediziertes Observability-Tool (Helicone, LangSmith, Phoenix, Braintrust, Arize).
• Eine allgemeine Observability-Plattform mit LLM-Erweiterungen (Datadog LLM Observability, Sentry).
• Eigene Protokolle oder Datenbank.

Wählen Sie anhand Ihrer Anforderungen: OpenTelemetry-Export, Visualisierung von Traces und Toolaufrufen, Datenstandort, Self-Hosting, Schwärzung, Zugriffskontrolle, APIs für Aufbewahrung und Löschung, Pflege der Modellpreise, Evaluierungsunterstützung und Gesamtkosten. Ein dediziertes Tool, ein vorhandenes APM oder eine kleine Eigenentwicklung kann jeweils die richtige Wahl sein. Testen Sie Export und Löschung, bevor Sie sich festlegen.

Wie instrumentieren? Optionen:

• Ein Proxy zwischen Ihrer Anwendung und dem LLM-Anbieter (der Ansatz von Helicone).
• Ein Wrapper-SDK in Ihrem Anwendungscode.
• Eine Wrapper-Klasse, die manuell für jeden LLM-Aufruf aufgerufen wird.

Proxys zentralisieren die Instrumentierung, fügen jedoch einen zusätzlichen Netzwerkschritt und eine weitere Fehlerquelle hinzu. Ein SDK-Wrapper hält die Instrumentierung im Prozess, koppelt den Code aber an die Integration. Manuelle Wrapper können präzise sein, erfordern jedoch Tests der Abdeckung. Messen Sie Mehraufwand und Fehlerverhalten des gewählten Ansatzes.

Ein pragmatischer Ansatz ist ein SDK-Wrapper an der Stelle, an der Ihre Anwendung das LLM aufruft. So gibt es einen einzigen Instrumentierungspunkt, den alle Aufrufe durchlaufen.

Was protokollieren? Legen Sie Datenklassifizierung und Aufbewahrung fest, bevor Sie Payloads erfassen. Nach der DSGVO gelten die Grundsätze der Datenminimierung und Speicherbegrenzung aus Artikel 5 auch für Observability-Daten.

• Bevorzugen Sie Prompt-Versionen, Hashes, Token-Anzahlen, Richtlinienentscheidungen und abgeleitete Metriken gegenüber rohen Inhalten.
• Wenn die Erfassung von Payloads gerechtfertigt ist, erfassen Sie nur Stichproben, maskieren Sie sensible Angaben vor dem Export, verschlüsseln Sie die Daten, beschränken Sie den Zugriff und legen Sie eine kurze Aufbewahrungsdauer fest.
• Bewahren Sie nicht allein deshalb ein automatisch abrufbares Rohoriginal auf, weil eine geschwärzte Kopie protokolliert wurde. Damit würden Sie erneut einen sensiblen Datenspeicher schaffen, der einen eigenen rechtmäßigen Zweck und eigene Kontrollen benötigt.
• Protokollieren Sie keine Zugangsdaten, auch nicht in Fehlerpfaden.
• Protokollieren Sie beim Streaming sowohl die Latenz bis zum ersten Token als auch die Gesamtlatenz.

Instrumentierung auf Trace-Ebene

Eine einzelne Nutzeraktion umfasst häufig viele LLM-Aufrufe. Ohne Instrumentierung auf Trace-Ebene erhalten Sie tausend Aufrufprotokolle, können aber nicht erkennen, welche davon zu derselben Nutzeraktion gehören.

Implementierung:

Erzeugung von Trace-IDs. Erzeugen Sie zu Beginn einer Nutzeranfrage eine eindeutige Trace-ID und geben Sie sie an alle nachfolgenden Aufrufe weiter.

Über- und untergeordnete Spans. Innerhalb eines Traces besitzt jeder Aufruf eine Span-ID und optional eine übergeordnete Span-ID. Daraus entsteht ein Baum der Aufrufhierarchie.

Benennung der Vorgänge. Jeder Span erhält einen Namen („summarize_document“, „extract_entities“, „tool_call:search“). Der Trace zeigt die vollständige Vorgangskette.

Eine Trace-Ansicht in Ihrer UI:

Trace abc-123 (insgesamt 12.3s)
├─ classify_intent (450ms) [small-model-revision]
├─ retrieve_documents (1.2s) [embedding + search]
├─ generate_response (8.5s) [generation-model-revision]
│   ├─ tool_call: search_internal (320ms)
│   ├─ tool_call: lookup_customer (180ms)
│   └─ generate_final_text (7.5s)
└─ judge_response_quality (2.1s) [claude-haiku-4-5]

Nun sehen Sie, was Ihr System bei dieser Nutzeranfrage tatsächlich getan hat. Langsame, teure und fehlgeschlagene Aufrufe werden im Zusammenhang sichtbar.

Als Implementierungen kommen dedizierte LLM-Observability-Produkte und allgemeine APM-Systeme mit OpenTelemetry infrage. Prüfen Sie in einem repräsentativen Test die Weitergabe von Traces, die Darstellung von Toolaufrufen, Export, Schwärzung, Löschung, Zugriffskontrolle und Fehlerverhalten, statt sich auf eine Produktliste zu verlassen.

Metriken auf Anwendungsebene

Aggregieren Sie über einzelne Aufrufe hinaus folgende Metriken:

Pro Funktion.

• Aufrufvolumen.
• Durchschnittliche Latenz.
• Latenz bei p50, p95 und p99.
• Durchschnittliche Kosten pro Anfrage.
• Fehlerquote.
• Qualitätswert (falls gemessen).

Pro Benutzer/pro Mandant.

• Aufrufe pro Benutzer und Tag.
• Kosten pro Benutzer.
• Intensivnutzer und Missbrauchsmuster.

Pro Modell.

• Volumen nach Modell.
• Kostenanteil nach Modell.
• Fehlerquote nach Modell.
• Qualität (wo gemessen) nach Modell.

Pro Funktion × pro Modell.

• Welche Funktionen verwenden welche Modelle?
• Wo könnten Anfragen an günstigere Modelle geleitet werden?

Diese Dashboards unterstützen betriebliche Entscheidungen: Welche Funktionen sind teuer, welche langsam und welche müssen optimiert werden?

Qualitätsüberwachung

Die schwierigste Ebene ist die automatisierte Qualitätsbewertung.

Für Evaluationen verwenden Sie einen festgelegten Datensatz. Beim laufenden Qualitätsmonitoring bewerten Sie den Datenverkehr aus dem Produktivbetrieb.

Ansätze:

LLM als Bewerter einer Stichprobe. Definieren Sie die Stichprobe anhand von Datenverkehr, Risikosegmenten, Datenschutzauflagen, Erkennungsziel und Budget. Wenden Sie einen kalibrierten Bewerter auf geeignete Beispiele an, behalten Sie die menschliche Entscheidung bei strittigen oder folgenreichen Fällen bei und verfolgen Sie die Ergebnisse nach Prompt- und Modellversion. Bewertungsmodelle weisen Verzerrungen aufgrund von Position, Ausführlichkeit und Eigenpräferenz auf; ihre Ergebnisse sind zu validierende Messwerte, keine unumstößliche Wahrheit.

Implizite Signale. Erfassen Sie erneute Generierungen, Abbrüche, Fehlerquoten, Zeit bis zum Abschluss und die Häufigkeit von Folgenachrichten. Diese Signale sind schwach, aber kostengünstig. Nutzen Sie sie als Frühindikatoren.

Explizites Benutzerfeedback. Daumen hoch/runter, „Hat das geholfen?“-Schaltflächen, explizite Meldungen. Höchste Signalstärke, aber niedrigstes Volumen.

Mustererkennung. Bestimmte problematische Muster („Ich kann dabei nicht helfen“, „Ich bin nur eine KI“, wiederholte Ablehnungen) werden automatisch markiert. So lassen sich einige Regressionen sofort erkennen.

Ein Implementierungsprotokoll sollte Stichprobenregel, ausgeschlossene Daten, Bewertungsraster, Bewerterversion, menschlichen Kalibrierungsdatensatz, Unsicherheit, Aggregationsfenster, Warnschwelle und Kostenobergrenze festhalten. Leiten Sie Änderungsschwellen aus wiederholten Basisläufen und der Schwere übersehener Regressionen ab. Ein übernommener Prozentsatz hat für eine andere Aufgabe weder statistische noch geschäftliche Aussagekraft.

Kosten-Observability

Wiederholungen, Schleifen, unerwartet lange Ein- oder Ausgaben, Routing-Änderungen und Preisänderungen des Anbieters können die Kosten schnell erhöhen. Erkennen Sie jeden Mechanismus direkt, statt einen Multiplikator anzunehmen.

Ebenen der Kosten-Observability:

Kosten pro Aufruf. Die Kosten jedes Aufrufs werden bei der Protokollierung berechnet. Aggregationen stehen sofort zur Verfügung.

Budgetwarnungen. Tägliche, wöchentliche oder monatliche Budgets pro Funktion und Mandant, mit Warn- und Durchsetzungsschwellen, die aus Prognoseabweichungen und geschäftlicher Kritikalität abgeleitet werden.

Anomalieerkennung. Vergleichen Sie Kosten und Nutzung mit der passenden Basislinie für denselben Datenverkehrsmix. Begrenzen Sie außerdem ausufernde einzelne Läufe, Token, Tools, Wiederholungen, Dauer und Ausgaben jeweils separat.

Kostenzuordnung. Kosten pro Funktion, Mandant und Nutzer. Identifizieren Sie die größten Kostentreiber.

Prognose. Basierend auf dem aktuellen Verlauf: Wie hoch wird die Rechnung am Monatsende sein?

Eine nützliche Dashboard-Ansicht zeigt in einem einzigen Panel die heutigen Kosten, die übrigen Kosten dieser Woche und die Werte der Vorwoche, jeweils nach Funktion aufgeschlüsselt.

Legen Sie Budgetgrenzen anhand des gemessenen Datenverkehrs und der geschäftlichen Kritikalität fest. Bevorzugen Sie gestufte Kontrollen: warnen, drosseln, einen unkritischen Pfad auf ein günstigeres Modell umstellen und erst dann per Circuit Breaker abschalten. Eine allgemeine Regel wie „bei 10× abschalten“ reagiert möglicherweise viel zu spät oder legt einen wesentlichen Workflow lahm.

Latenz-Observability

LLM-Latenz ist vielschichtiger als bei typischen APIs:

Gesamtlatenz. Von der Anfrage bis zur finalen Antwort.

Time-to-First-Token (TTFT). Wann sieht der Nutzer beim Streaming das erste Zeichen? Dieser Wert prägt die wahrgenommene Latenz einer Chat-Oberfläche stark.

Time-to-Last-Token (TTLT). Wie lange dauert es, bis die Antwort vollständig ist?

Tokens pro Sekunde. Ausgaberate. Einige Modelle streamen langsamer als andere.

Latenz von Toolaufrufen. Bei Agentenabläufen: Zeit in Toolaufrufen im Vergleich zu LLM-Aufrufen.

Verfolgen Sie alle diese Werte. Unterschiedliche Optimierungsstrategien zielen auf unterschiedliche Metriken ab.

Bei nutzerseitigen Chats ist TTFT eine wichtige Interaktionsmetrik. Gesamtdauer, Ausgaberate, Unterbrechungen, Aufgabenerfolg und Barrierefreiheit sind jedoch ebenfalls relevant. Leiten Sie Ziele aus dem beobachteten Nutzerverhalten ab, statt anzunehmen, dass eine einzelne Latenzmetrik für jede Oberfläche entscheidend ist.

Bei Batch-Verarbeitung ist die Gesamtlatenz relevant, der Durchsatz aber wichtiger.

Bei Agenten dominiert häufig die Latenz der Toolaufrufe. Die Optimierung des LLM hilft nicht, wenn die Tools langsam sind.

Fehler-Observability

LLM-spezifische Fehler:

API-Fehler. Ratenbegrenzungen, Authentifizierungs- und Serverfehler. Wie bei jeder anderen API.

Validierungsfehler. Eine strukturierte Ausgabe entspricht nicht dem Schema. Erfassen Sie die Häufigkeit pro Funktion.

Inhaltsfilterfehler. Der Anbieter hat die Anfrage blockiert. Erfassen Sie diese Fehler, um Probleme mit Prompts zu erkennen.

Toolfehler. Bestimmte Tools schlagen fehl. Erfassen Sie die Fehler pro Tool.

Qualitätsfehler. Das bewertende LLM stuft die Ausgabe als schlecht ein. Beobachten Sie die Entwicklung im Zeitverlauf.

Halluzinationssignale. Hinweise auf wahrscheinliche Halluzinationen, etwa wenn das Modell etwas behauptet, das nicht in der Quelle steht. Eine automatische Erkennung ist schwierig, lässt sich aber näherungsweise umsetzen.

Kostenfehler. Aufrufe, die deutlich mehr kosten als erwartet. Das weist häufig auf einen Fehler hin.

Jede Fehlerklasse erhält eine eigene Dashboard-Ansicht und kann Warnmeldungen auslösen.

Debugging-Werkzeuge

Wenn etwas fehlschlägt, müssen Sie es finden und verstehen. Die Debugging-Oberfläche umfasst:

Trace-Suche. Finden Sie ein Ereignis anhand der Trace-ID, einer freigegebenen pseudonymen Betroffenenreferenz oder des Zeitstempels, ohne weitere Mandantendaten offenzulegen.

Aufrufinspektor. Zeigt standardmäßig nur Metadaten. Freigegebene, minimierte Anfrage- und Antwortfelder werden ausschließlich unter Rollenprüfungen, Zugriffsprotokollierung, Zweckbindung und Aufbewahrungsregeln sichtbar. Viele Deployments sollten die vollständige Payload niemals speichern.

Trace-Zeitachse. Stellt bei komplexen Abläufen die Kette der Aufrufe visuell dar.

Kontrollierte Wiederholbarkeit. Lässt sich eine freigegebene, minimierte Eingabe in einer isolierten Umgebung erneut ausführen, während Tools deaktiviert sind oder in einer Sandbox laufen? Wiederholen Sie Aufrufe aus dem Produktivbetrieb niemals mit echten Nebenwirkungen. Die Nützlichkeit einer Wiederholung rechtfertigt nicht automatisch die Speicherung von Payloads.

Differenzansicht. Vergleichen Sie zwei Aufrufe mit verschiedenen Versionen desselben Prompts oder verschiedenen Modellen direkt nebeneinander.

Suche nach freigegebenen Inhalten oder abgeleiteten Feldern. Suchen Sie nach festgelegten Mustern, ohne das Telemetriesystem in ein uneingeschränktes Korpus von Kunden-Prompts zu verwandeln. Autorisierung, Minimierung, Indizierung, Aufbewahrung und Zugriffsprotokollierung gelten für die Suche ebenso wie für die Speicherung.

Die Produkte unterscheiden sich erheblich bei diesen Fähigkeiten. Prüfen Sie sie in einem repräsentativen Test und berücksichtigen Sie Integration, Speicherung, Datenschutzprüfung, Migration und Betriebsaufwand im Vergleich. Der Listenpreis allein beweist nicht, dass der Kauf günstiger ist.

Datenschutz und personenbezogene Daten

LLM-Observability-Protokolle sind sensibel. Eingaben können personenbezogene Daten enthalten, Ausgaben können sie wiedergeben. Die Erfassung roher Payloads wird mitunter für das Debugging vorgeschlagen, ist aber weder automatisch erforderlich noch rechtmäßig. Definieren Sie den Zweck und prüfen Sie zuerst synthetische Reproduktionen, abgeleitete Felder oder kurzlebige kontrollierte Stichproben.

Praktiken:

Pseudonymisierung/Tokenisierung. Ersetzen Sie direkte Identifikatoren durch zweckspezifische Token und schützen Sie die Zuordnung zur erneuten Identifizierung separat. Bleibt eine erneute Identifizierung möglich, handelt es sich weiterhin um personenbezogene Daten und nicht um anonyme „Non-PII“.

Schwärzung bei der Protokollierung. Erkennen und schwärzen Sie personenbezogene Daten, bevor sie im Observability-Speicher landen. Ersetzen Sie bekannte Muster wie E-Mail-Adressen, Telefonnummern oder US-Sozialversicherungsnummern durch Platzhalter.

Mandantenisolierung. Isolieren Sie Observability-Daten in Mehrmandantensystemen nach Mandanten. Die Daten eines Mandanten dürfen für andere nicht sichtbar sein.

Zugriffskontrollen. Legen Sie fest, wer rohe Ein- und Ausgaben sehen darf, und protokollieren Sie jeden Zugriff.

Aufbewahrungsrichtlinien. Löschen Sie Protokolle nach der festgelegten Frist oder verschieben Sie sie in einen Langzeitspeicher. Für die Aufbewahrung personenbezogener Daten gelten in vielen Rechtsordnungen gesetzliche Grenzen.

Ablauf für Löschung und Einschränkung. Sorgen Sie dafür, dass Telemetriedatensätze über die für diesen Zweck zugelassenen Identifikatoren auffindbar sind. Setzen Sie den von der Rechtsberatung festgelegten Ablauf in Primärspeichern, Indizes, Exporten und Backups um. Machen Sie aus dem umgangssprachlichen „Recht auf Vergessenwerden“ kein pauschales Versprechen; eine Löschung nach DSGVO unterliegt Bedingungen und Ausnahmen.

Das System benötigt Kontrollen, die Art und Zweck der personenbezogenen Daten angemessen sind. Die genaue Kombination variiert. Mandantenisolierung, autorisierter Zugriff, Minimierung, Aufbewahrung, Verfahren für Löschung und Einschränkung sowie Auditierbarkeit müssen jedoch vor der Aktivierung von Payload-Telemetrie feststehen. Die Europäische Kommission fasst die Bedingungen und Ausnahmen für Löschungsanfragen zusammen.

Warnmeldungen

Schwellenwerte und Signale, die eine Warnmeldung rechtfertigen:

Kosten.

• Ausgaben oder Prognose überschreiten den gemessenen Budgetrahmen der Funktion.
• Die Kosten pro Anfrage überschreiten eine aufgabenspezifische Obergrenze.
• Die Änderungsrate verlässt den Basisbereich für denselben Datenverkehrsmix.

Latenz.

• Die Latenz am Verteilungsende überschreitet das gemessene Serviceziel des Produkts.
• Die Zeit bis zum ersten Token oder bis zum Abschluss überschreitet das interaktionsspezifische Ziel.
• Tool-Timeouts oder Warteschlangenzeiten verlassen den Basisbereich.

Fehlerquote.

• Die Fehlerquote überschreitet das Fehlerbudget der Aufgabe.
• Ein bestimmter Fehlertyp weicht von seiner Basislinie ab, darunter Validierungsfehler und Ratenbegrenzungen.

Qualität.

• Eine kalibrierte Metrik verändert sich stärker als ihre Varianz über wiederholte Läufe, oder in einem Sicherheitssegment tritt ein unzulässiges Ergebnis auf.
• Der Anteil negativen Nutzerfeedbacks liegt über der Basislinie.
• Die Rate erneuter Generierungen liegt über der Basislinie.

Muster.

• Spezifische schlechte Phrasen treten häufiger auf.
• Plötzliche Änderung der Eingabeverteilung.

Jede Warnmeldung sollte Funktion, Zeitfenster, beobachteten und erwarteten Wert, betroffenes Segment, Trace-Links und Runbook nennen. Diagnostizieren Sie im Meldungstext keine unkontrollierte Schleife, solange diese Diagnose nicht durch Telemetrie zu Schleifen oder Wiederholungen gestützt wird.

Mehrmandantenbetrieb

Für B2B-SaaS-Apps:

Metriken pro Mandant. Jeder Kunde kann seine eigene Nutzung, Kosten und Qualität sehen.

Warnmeldungen pro Mandant. Abgestimmt auf die jeweiligen Schwellenwerte.

Debugging pro Mandant. Der Support kann unter angemessenen Zugriffskontrollen die Traces eines Kunden einsehen.

Konfiguration pro Mandant. Manche Kunden verwenden andere Modelle, Prompts oder Richtlinien. Die Observability-Ebene muss dies abbilden.

In Mehrmandantensystemen können Mandantenzuordnung und -isolierung für Support und Abrechnung erforderlich sein. Der Zugriff auf rohe Traces ist dadurch jedoch nicht automatisch gerechtfertigt. Geben Sie dem Support nur die mindestens erforderlichen Daten und Berechtigungen, protokollieren Sie den Zugriff und schaffen Sie einen Eskalationsweg für sensible Payloads.

Tool-Ökosystem (2026)

Ein Überblick über LLM-Observability-Tools zum Zeitpunkt der Veröffentlichung:

Dedizierte LLM-Observability:

• Helicone, LangSmith, Phoenix (Arize), Braintrust, PromptLayer und Weights & Biases Weave sind Kandidaten, die Sie anhand der oben genannten Anforderungen prüfen sollten.

Allgemeines APM mit LLM-Erweiterungen:

• Datadog LLM Observability und New Relic AI Monitoring sind Kandidaten, wenn die Organisation diese Plattformen bereits nutzt.
• OpenTelemetry + APM Ihrer Wahl. OTel bietet semantische Konventionen für generative KI; Sie instrumentieren einmal und können die Daten in verschiedenen Tools betrachten.

Eigenentwicklung:

• Eine kleine Datenbank kann für ein begrenztes System ausreichen, wenn sie die erforderlichen Kontrollen für Isolation, Zugriff, Aufbewahrung, Löschung und Indizierung umsetzt.
• Fügen Sie eine einfache UI zum Suchen und Anzeigen hinzu.
• Binden Sie die Lösung an Ihre vorhandene Protokollierungsinfrastruktur an.

Dokumentieren Sie die Entscheidung, verworfene Alternativen, die Prüfung des Datenflusses, den Exit- und Exporttest sowie das Datum der Neubewertung. Kein einheitlicher Migrationspfad passt zu jedem Team.

Ein praktisches Setup

Ordnen Sie die Schritte nach Abhängigkeiten und Risiken statt nach einem allgemeinen Zeitplan:

Phase 1: Wählen Sie anhand der Anforderungen einen Kandidaten aus und testen Sie ihn mit synthetischen, nicht sensiblen Traces. Prüfen Sie Export, Zugriff, Schwärzung, Aufbewahrung, Löschung, Fehlerverhalten und Ausstiegswege, nicht nur die Datenerfassung.

Phase 2: Fügen Sie Dashboards für die festgelegten Serviceziele hinzu, darunter Kosten pro Funktion, Latenzverteilungen, Fehlerklassen, Modell- und Prompt-Versionen sowie die Rate fehlender Telemetrie.

Phase 3: Richten Sie aus der jeweiligen Aufgabe abgeleitete Warnmeldungen für Kosten, Schleifen, Latenz und Fehlerklassen ein.

Phase 4: Verbinden Sie Spans über Abläufe mit mehreren Aufrufen hinweg und prüfen Sie die Weitergabe von Traces durch Tools und Warteschlangen.

Phase 5: Implementieren Sie freigegebene Qualitätsstichproben und kalibrieren Sie automatisierte Bewertungen anhand menschlicher Urteile.

Phase 6: Erfassen Sie Nutzerfeedback erst, wenn Interpretation, Datenschutzbehandlung und Reaktionsablauf festgelegt sind.

Phase 7: Ergänzen Sie mandantenspezifische Ansichten und Debugging-Funktionen mit Autorisierung und Zugriffsaudits.

Das Abnahmeprotokoll jeder Phase sollte Tests, Datenklassifizierungen, Verantwortliche, Fehlerverhalten und Rollback enthalten. Überspringen Sie eine Funktion nur mit ausdrücklicher Begründung und einer kompensierenden Kontrolle.

Was ohne es schiefgeht

Ein kurzer Katalog von Vorfallmustern, die bei Teams ohne angemessene LLM-Observability wiederkehren:

• Eine Funktion wiederholt Aufrufe in einer engen Schleife und verursacht unerwartete Gebühren, bevor die nächste Abrechnungsprüfung stattfindet.
• Ein Modellupdate verändert das Verhalten, doch die Anfragen enthalten keine Modellversion, sodass die Ursache erst spät zugeordnet werden kann.
• Eine neue Prompt-Version verschlechtert einen wichtigen Ablauf, aber Deployment- und Antwort-Traces lassen sich nicht nach Version vergleichen.
• Ein Agent gerät in eine Schleife, doch fehlende Schrittbudgets und Instrumentierung auf Trace-Ebene verdecken den wiederholten Zustand.
• Ein Authentifizierungsfehler eines Tools löst Wiederholungen aus, aber Telemetrie zu Fehlerklassen und Wiederholungen ist nicht miteinander verknüpft.
• Ein Prompt-Injection-Pfad führt zu einer unzulässigen Offenlegung, aber fehlende Datenherkunfts- und Richtlinienentscheidungs-Telemetrie verhindert eine Bewertung der Auswirkungen.

Diese Ausfallszenarien sollten getestet werden. Observability liefert Nachweise für Erkennung und Untersuchung; den zugrunde liegenden Fehler verhindert sie nur, wenn technische Kontrollen auf die Signale reagieren.

Instrumentieren Sie vor dem Vorfall

LLM-Observability erweitert das allgemeine APM, statt es zu ersetzen. Wählen Sie die Aufruf-, Trace-, Qualitäts-, Kosten-, Latenz-, Fehler- und Debugging-Signale aus, die durch Aufgabe und Bedrohungsmodell gerechtfertigt sind, und verknüpfen Sie sie mit getesteten Reaktionskontrollen.

Ein Anspruch auf Produktionsreife sollte stattdessen die Erkennungszeit je Szenario, Vollständigkeit der Traces, Präzision und Trefferquote der Warnmeldungen, soweit messbar, das Verhalten von Budgetkontrollen, Datenschutztests sowie Nachweise für Wiederherstellung oder Rollback zeigen. Instrumentieren Sie das System vor dem Start, proben Sie die Runbooks und veröffentlichen Sie nur Ergebnisse, die Sie tatsächlich gemessen haben.