Was ist LLM Observability?

Was ist LLM Observability?

LLM Observability überträgt klassische Observability auf Anwendungen, die Large Language Models nutzen: Chat-Assistenten, Retrieval-Augmented-Generation-Systeme (RAG), Copilots und autonome KI-Agenten. Sie beantwortet Fragen, an denen herkömmliches APM scheitert: Welcher Prompt hat diese Antwort erzeugt, welche Dokumente wurden abgerufen, welche Tools hat der Agent in welcher Reihenfolge aufgerufen, wie viele Tokens hat jeder Schritt verbraucht, was hat der Request gekostet und war die Antwort korrekt, belegt und sicher?

Technisch nutzt LLM Observability dieselben Bausteine wie jede moderne Observability-Praxis, also Traces, Metriken und Logs, und ergänzt zwei Dinge: GenAI-spezifische Telemetrie wie Modellnamen, Token-Zahlen und Finish Reasons sowie Evaluierungen, die die Qualität nicht deterministischer Ausgaben bewerten.

Warum LLM-Anwendungen eine andere Observability brauchen

• Erfolg ist nicht binär. Ein Modellaufruf mit HTTP 200 kann trotzdem halluzinieren, Anweisungen ignorieren oder Daten preisgeben. Statuscodes und Latenz allein sagen nicht, ob das System funktioniert.
• Das Verhalten ist nicht deterministisch. Dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen, und ein Modell-Update beim Anbieter kann das Verhalten ändern, ohne dass Sie selbst etwas deployt haben.
• Die Kosten schwanken pro Request. Sie hängen von Prompt-Länge, abgerufenem Kontext, Antwortlänge und der Zahl der Agent-Iterationen ab. Eine einzige außer Kontrolle geratene Agent-Schleife kann mehr kosten als Tausende normale Requests.
• Agenten sind mehrstufige Systeme. Ein Agent plant, ruft ein Modell auf, nutzt Tools, fragt eine Vektordatenbank ab und ruft das Modell erneut auf. Ohne Trace bedeutet Debugging Raten, welcher Schritt schiefging.
• Externe Abhängigkeiten dominieren. Latenz, Rate Limits und Ausfälle des Modellanbieters treffen Nutzer direkt und müssen deshalb aus Ihrer Perspektive gemessen werden.
• Prompts enthalten sensible Daten. Nutzereingaben und abgerufene Dokumente können personenbezogene oder vertrauliche Informationen enthalten. Das verändert, wie Telemetrie erfasst und gespeichert werden muss.

Was Sie überwachen sollten: die fünf Dimensionen

Dimension	Wichtige Metriken	Warum relevant
Performance	End-to-End-Latenz, Time to First Token, Zeit pro Output-Token, Latenz je Agent-Schritt	Nutzer bewerten Streaming-Apps nach der Time to First Token, Agenten addieren Latenz pro Schritt
Kosten	Input- und Output-Tokens pro Request, Nutzer, Feature und Modell, Kosten pro erfolgreicher Aufgabe, Prompt-Cache-Trefferquote	Token-Ausgaben skalieren mit Nutzung und Prompt-Design und geraten leicht außer Kontrolle
Zuverlässigkeit	Fehlerrate, HTTP-429-Rate-Limits, Timeouts, Retries, Finish Reasons wie Länge oder Content-Filter	Anbieterlimits und abgeschnittene Antworten verursachen stille Fehler
Qualität	Evaluierungsscores (Relevanz, Belegbarkeit, Korrektheit), Nutzerfeedback, Erfolgsquote von Aufgaben	Der einzige Weg zu sehen, ob Antworten wirklich gut sind
Sicherheit	Guardrail-Auslösungen, PII-Funde, Prompt-Injection-Versuche, abgelehnte oder blockierte Ausgaben	Schützt Nutzer, Daten und Compliance

Ergänzen Sie für RAG-Systeme Retrieval-spezifische Signale: Retrieval-Latenz, Anzahl zurückgegebener Chunks, Similarity Scores und ob der abgerufene Kontext die Antwort tatsächlich stützt. Viele vermeintliche Halluzinationen erweisen sich als Retrieval-Fehler.

LLM-Apps und KI-Agenten tracen

Distributed Tracing ist das Rückgrat der LLM Observability. Jeder Agent-Aufruf wird zu einem Trace, jeder Schritt zu einem Span mit Zeitmessung, Attributen und Status. Ein typischer Agent-Trace sieht so aus:

invoke_agent support-assistant                 4.8 s
├── chat gpt-4o                (plan)          1.1 s   in 1,840 / out 120 tokens
├── execute_tool search_orders                 0.3 s
│   └── HTTP GET /orders?customer=…            0.2 s
├── embeddings text-embedding-3-small          0.1 s
├── vector search (top_k=5)                    0.2 s
└── chat gpt-4o                (answer)        3.0 s   in 3,950 / out 410 tokens

Ein solcher Trace beantwortet sofort, warum eine Antwort langsam war (die finale Generierung), was sie gekostet hat (Summe der Tokens beider Modellaufrufe) und welchen Kontext das Modell gesehen hat. Da die LLM-Spans im selben Trace liegen wie die HTTP-, Datenbank- und Queue-Spans Ihrer Services, können Sie eine Nutzerbeschwerde vom Frontend über den Agenten bis ins Bestellsystem verfolgen, ohne das Werkzeug zu wechseln.

Achten Sie besonders auf Agent-Schleifen: Ein Trace mit Dutzenden wiederholten Tool-Aufrufen ist ein klassisches Zeichen für einen Agenten, der sein Ziel nicht erreicht, und häufig die Ursache plötzlicher Kostenspitzen. Alarmieren Sie deshalb auf Schrittzahl und Tokens pro Trace, nicht nur auf Fehler.

OpenTelemetry GenAI Semantic Conventions

OpenTelemetry definiert Semantic Conventions für generative KI, damit Instrumentierungen verschiedener Bibliotheken und Anbieter konsistente Telemetrie erzeugen. Sie haben noch den Status „in Entwicklung“ und ändern sich zwischen Releases, sind aber bereits breit umgesetzt. Die wichtigsten Elemente:

• Span-Namen und Operationen: Spans werden nach Operation und Modell benannt, etwa chat gpt-4o, mit Werten für gen_ai.operation.name wie chat, embeddings, execute_tool, create_agent und invoke_agent.
• Request- und Response-Attribute: gen_ai.provider.name (Nachfolger des früheren gen_ai.system), gen_ai.request.model, gen_ai.response.model, gen_ai.request.temperature, gen_ai.request.max_tokens und gen_ai.response.finish_reasons.
• Usage-Attribute: gen_ai.usage.input_tokens und gen_ai.usage.output_tokens.
• Metriken: gen_ai.client.token.usage und gen_ai.client.operation.duration auf Client-Seite sowie Server-Metriken wie Time to First Token für Model-Serving-Infrastruktur.
• Erfassung von Inhalten: Prompts, Antworten und Tool-Argumente werden standardmäßig nicht aufgezeichnet. Die Erfassung ist wegen Größe und Sensibilität ein bewusstes Opt-in.

Wer auf diesen Konventionen aufbaut, hält seine Instrumentierung portabel: Sie können Modellanbieter, Frameworks oder Observability-Backends wechseln, ohne Dashboards und Alerts neu zu bauen.

Kosten und Qualität messen

Token-Kosten

Die Kosten pro Aufruf berechnen sich als Input-Tokens × Input-Preis + Output-Tokens × Output-Preis. Bei einem beispielhaften Preis von 3 $ pro Million Input-Tokens und 15 $ pro Million Output-Tokens kostet ein Request mit 2.000 Input- und 500 Output-Tokens 0,006 + 0,0075 = 0,0135 $. Bei einer Million Requests im Monat sind das 13.500 $, und ein Agent mit vier solchen Aufrufen pro Aufgabe vervierfacht den Betrag. Ordnen Sie Tokens Features, Mandanten und Prompt-Versionen zu, damit sichtbar wird, welche Änderung die Rechnung bewegt hat.

Qualitätsevaluierungen

Qualität muss explizit gemessen werden. Gängige Ansätze sind Offline-Evaluierungen gegen kuratierte Testdatensätze vor jeder Prompt- oder Modelländerung, Online-Evaluierungen auf einer Stichprobe des Produktions-Traffics per Heuristik oder LLM-as-a-Judge sowie Nutzerfeedback wie Bewertungen oder Folgeverhalten. Speichern Sie Evaluierungsscores als Attribute oder Events am zugehörigen Trace. So führt ein niedriger Score direkt zu Prompt, Kontext und Tool-Aufrufen, die ihn verursacht haben.

Sicherheit und Guardrails

Guardrails prüfen Ein- und Ausgaben gegen Richtlinien: Sie erkennen personenbezogene Daten, Prompt-Injection- und Jailbreak-Versuche, toxische Inhalte oder Antworten außerhalb des erlaubten Themenbereichs. Jede Guardrail-Entscheidung sollte als Event am Trace festgehalten werden, einschließlich der ausgelösten Regel und der Frage, ob der Request blockiert, umgeschrieben oder durchgelassen wurde. Die Rate der Guardrail-Auslösungen im Zeitverlauf zeigt sowohl Angriffe als auch zu strenge Regeln, die legitime Nutzer ausbremsen. Bei Agenten, die Aktionen ausführen können, etwa E-Mails versenden oder Datensätze ändern, sollten Sie zusätzlich protokollieren, welche Tools mit welchen Berechtigungen aufgerufen wurden. So lässt sich jede Aktion im Nachhinein lückenlos prüfen, was gerade in regulierten Branchen und mit Blick auf Vorgaben wie DSGVO, DORA oder NIS2 wichtig ist.

Für RAG-Anwendungen gilt dasselbe Prinzip für die Datenquellen: Protokollieren Sie, aus welchen Dokumenten und Berechtigungsbereichen der Kontext stammt. Nur so erkennen Sie, ob ein Agent Informationen verwendet hat, die der jeweilige Nutzer gar nicht sehen dürfte.

Best Practices und Fallstricke

• Auf Framework-Ebene instrumentieren mit OpenTelemetry-kompatiblen Bibliotheken und eigene Spans für Retrieval und Geschäftslogik ergänzen.
• Prompts versionieren und die Version an jedem Span mitschreiben, damit sich Qualitäts- und Kostenänderungen einer Prompt-Änderung zuordnen lassen.
• Personenbezogene Daten vor der Speicherung maskieren. Prompts sind Logs mit erhöhtem Risiko. Schwärzen Sie beim Ingest und beschränken Sie den Zugriff auf Rohinhalte.
• Alle fehlerhaften und teuren Traces behalten per Tail-based Sampling und unauffällige erfolgreiche Traces nur stichprobenartig speichern.
• Budgets setzen und auf Ausgaben alarmieren, pro Feature und Mandant sowie auf Tokens pro Trace.
• SLOs für KI-Features definieren, auf Latenz, Fehlerrate und Evaluierungsscores, nicht nur auf Verfügbarkeit.
• Das Modell nicht als Blackbox außerhalb der Traces behandeln. Latenz und Fehler des Anbieters gehören auf dieselbe Zeitachse wie Ihre eigenen Services.

Wie Obseria bei LLM Observability unterstützt

Obseria AI Observability erfasst LLM-Aufrufe, Agenten und RAG-Pipelines Ende zu Ende als Traces auf Basis von OpenTelemetry, gemeinsam mit der übrigen Telemetrie Ihrer Anwendungen. Tokens, Kosten, Latenz und Qualität werden pro Modell, Prompt-Version, Feature und Mandant ausgewertet, Guardrail-Ereignisse werden protokolliert. Obseria Pipeline maskiert personenbezogene Daten in Prompts und Antworten bereits beim Ingest, Tail-based Sampling behält die relevanten Traces, und die Daten können in der EU-Region oder im eigenen Cloud-Account bleiben. Verschlechtert sich ein KI-Feature, untersucht Obseria Intelligence das wie jeden anderen Incident und folgt dem Trace vom Nutzer über den Agenten bis zum Modellanbieter oder dem fehlerhaften Tool.