Inhalt
In So baust du ein Multi-Agenten-System hieß es: „Instrumentiere jede Übergabe, bevor du Agenten hinzufügst." Die Technologie, die diese „Instrumentierung" in der Produktion trägt, ist AI observability. Sie macht sichtbar, was deine LLMs und Agenten in der Produktion tatsächlich tun — welche Tools sie aufrufen, was sie abrufen, wo sie scheitern und wie viel es kostet.
Anders als gewöhnliches App-Monitoring hat KI eine fiese Eigenschaft: Eine Anfrage kann „200 OK in 50ms" zurückgeben und trotzdem selbstbewusst lügen (halluzinieren). Mit anderen Worten: Sie kann schnell und verfügbar sein, während die Qualität kaputt ist. Dieser Artikel führt Einsteiger durch die 3 Säulen der Observability, den Unterschied zur Evaluation (evals), die Kennzahlen, die sich lohnen, und die wichtigsten Tools.
Den „Ausführungsbaum" einer Anfrage visualisieren
— Ein trace zeichnet Eingaben, Tool-Aufrufe, Retrieval und Ausgaben als spans auf
* Eigenschaften und Konzepte der Tools in diesem Artikel sind aus öffentlichen Materialien und offiziellen Dokumentationen zitiert (Stand Juni 2026). Tool-Bewertungen variieren je nach Anwendungsfall und Version — bitte als Richtwert verstehen.
1. Was ist KI-Observability?
AI observability bedeutet, das Verhalten von LLMs und KI-Agenten in der Produktion von außen beobachtbar zu machen. Für jede Anfrage hältst du fest: „welches Modell mit welchem Prompt aufgerufen wurde, welche Tools und Suchen genutzt wurden, was zurückkam und wie lange und wie viel es kostete" — damit du, wenn etwas kaputtgeht, bis zur Ursache zurückverfolgen kannst.
Der entscheidende Unterschied zum gewöhnlichen App-Monitoring: Traditionelles Monitoring prüft „läuft es, ist es schnell?" Aber KI kann normal und schnell antworten, während der Inhalt falsch ist. Die meisten KI-Ausfälle sind keine Infrastruktur-Ausfälle, sondern „Qualitäts-Ausfälle" — Halluzinationen, schwaches Retrieval, unsichere Antworten, unvollständige Aufgaben, schlechte Tool-Nutzung und Regressionen nach einer Prompt-Änderung.
Deshalb braucht KI eine eigene Beobachtung. Besonders in Multi-Agenten-Systemen treten Fehler innerhalb mehrstufiger Kausalketten auf, nicht auf Ebene des einzelnen Aufrufs. „Welcher Schritt schiefging und warum" wird erst sichtbar, sobald du den vollständigen Session-Trace erfasst.
2. Die 3 Säulen: traces, metrics, logs
Observability wird traditionell anhand von drei Säulen beschrieben. Dasselbe gilt für KI, und der Industriestandard OpenTelemetry (GenAI-Konventionen) erlaubt es dir, alle drei mit einem herstellerneutralen gemeinsamen Schema zu handhaben.
Traces
Erfassen den Ausführungspfad einer Anfrage als Baum aus spans. Du siehst, wie LLM-Aufrufe, Tools, Retrieval und Argumentationsketten abliefen. Der Star der KI-Beobachtung.
Metrics
Aggregieren Latenz, Kosten, Token-Anzahl, Fehlerrate und Durchsatz als Zahlen. Trends pro Modell/Agent verfolgen.
Logs
Detaillierte Aufzeichnungen einzelner Ereignisse — vollständige Prompts, Fehlerdetails — die Belege für tiefe Untersuchung.
Die GenAI-Konventionen von OpenTelemetry zeichnen Prompts, Modellantworten, Token-Verbrauch, Tool-/Agenten-Aufrufe und Provider-Metadaten in einem Standardformat auf. Das bedeutet, du bist nicht an einen Hersteller gebunden und kannst KI-Traces in bestehende Monitoring-Backends wie Datadog oder Grafana einspeisen.
3. Unterschied zur Evaluation (evals)
Was Einsteiger am häufigsten verwechseln, ist der Unterschied zwischen „Observability" und „Evaluation (evals)". Es sind verschiedene Dinge, und sie zählen nur als Paar.
🔭 Observability
Zeigt „was passiert ist": traces, Kosten, Latenz, Fehler. Leicht zu messen, aber für sich allein kann sie nicht sagen, „ist die Antwort korrekt?"
✅ Evaluation (evals)
Misst „ist die Antwort gut?": Genauigkeit, groundedness, Sicherheit. Explizite evals sind erforderlich — das ist der Wächter der Qualität.
Der Kern: „Kosten und Latenz sind leicht zu messen, aber die Antwortqualität lässt sich ohne explizite Bewertung nicht erkennen." Deshalb zeigen die führenden Tools von 2026 nicht nur traces — sie bewerten Ausgaben, alarmieren bei Qualitätsverschlechterung und speisen Erkenntnisse zurück in die Entwicklung. Beobachtung und Bewertung sind zwei Räder desselben Wagens.
4. Was beobachten: zentrale Kennzahlen
Die Indikatoren, die du auf einem Dashboard verfolgst, teilen sich grob in „betrieblich" und „qualitativ".
⚙️ Betrieblich (leicht zu messen)
- Kosten: Token-Abrechnung pro Anfrage
- Latenz: Antwortzeit (variiert stark je nach Eingabe)
- Token-Verbrauch: aufgeblähte Prompts früh erkennen
- Fehlerrate / Durchsatz: pro Modell/Agent
🎯 Qualität (braucht Bewertung)
- Halluzination: selbstbewusste, aber falsche Behauptungen
- Groundedness: am wichtigsten für RAG — wird es durch abgerufene Quellen gestützt?
- Sicherheit: PII-Leck, schädliche Ausgabe
- Aufgabenerfüllung / korrekte Tool-Nutzung
Unter den Qualitätskennzahlen ist bei RAG (retrieval-augmented generation) „groundedness (faithfulness)" der kritischste Indikator: Wird die Antwort tatsächlich von den abgerufenen Dokumenten gestützt, oder hat das Modell sie erfunden? Zur Halluzinationserkennung werden häufig LLM-as-a-judge (eine KI bewerten lassen), semantische Ähnlichkeit und groundedness-Scores verwendet.
5. Wichtige Tools im Vergleich
Hier die repräsentativen AI-observability-Tools von 2026. Viele bewegen sich darauf zu, Tracing und Bewertung an einem Ort zu vereinen.
| Tool | Merkmale | Am besten für |
|---|---|---|
| LangSmith | Passt hervorragend zu LangChain/LangGraph. Detailliertes Tracing + eval + Monitoring. Geringer Overhead. | Produktion auf LangChain-Basis |
| Langfuse | Open Source. Selbst hostbar, sodass du Daten nicht an ein externes SaaS senden musst. | Self-Hosting / strenge Datenanforderungen |
| Arize Phoenix | Stark beim RAG-Debugging. Gut darin, die Retrieval-Qualität zu visualisieren. | RAG-Untersuchung/Verbesserung |
| MLflow | Zentralisiert den gesamten GenAI-Lebenszyklus. | End-to-End von Entwicklung bis Betrieb |
| AgentOps | Spezialisiert auf das Monitoring autonomer Agenten. Mehrstufiges Session-Tracking. | Agenten-Betrieb |
| OpenTelemetry | Der Standard. Herstellerneutral; verbindet sich mit Datadog/Grafana usw. | Integration in bestehendes Monitoring |
Quelle: diverse Tool-Vergleiche und offizielle Informationen (Juni 2026). Merkmale sind Tendenzen; Bewertungen variieren je nach Anwendungsfall und Version.
Im Zweifel ist es sicher, auf OpenTelemetry-konforme Weise mit dem Erfassen von traces zu beginnen. Du vermeidest Vendor-Lock-in und kannst später ein Tool neu wählen. Wenn du LangChain nutzt, ist LangSmith ein einfacher Einstieg; wenn du Daten im Haus halten willst, Langfuse.
6. Wie man startet und warum es für Agenten zählt
Mach es dir nicht zu kompliziert — fang klein an. Wichtig ist, die Beobachtung einzurichten, bevor du in die Produktion gehst.
Traces erfassen
Zeichne LLM-Aufrufe, Tools und Retrieval als spans auf. OpenTelemetry-konform erleichtert einen späteren Wechsel.
Betriebliche Kennzahlen visualisieren
Erstelle ein Dashboard für Kosten, Latenz und Tokens. Richte Alarme bei Anomalien ein.
Evaluation (evals) anbinden
Bewerte Produktions-traces auf Qualität und erkenne Verschlechterungen. Kombiniere evals mit Guardrails.
Besonders in Multi-Agenten-Systemen ist Beobachtung kein „nice to have" — sie ist unverzichtbar. Da sich Fehler in mehrstufigen Ketten verbergen, weißt du ohne einen vollständigen Session-Trace nie, „wo und warum es kaputtging". Richte die Beobachtung ein, bevor du Agenten hinzufügst — das ist die Regel. Sie hilft auch bei der Früherkennung von Sicherheitsvorfällen.
Zusammenfassung
AI observability ist das betriebliche Fundament, das „Produktions-KI sichtbar macht". Fassen wir zusammen.
Die wichtigsten Erkenntnisse
- 🔭 Macht das Innere der Produktions-KI sichtbar. Drei Säulen: traces, metrics, logs.
- ⚠️ 200 OK kann trotzdem lügen. Die meisten KI-Ausfälle sind Qualitäts-Ausfälle, keine Infrastruktur-Ausfälle.
- 🔁 Beobachten + bewerten zugleich. Traces für das „was", evals für „ist es gut".
- 🛠️ Tools: LangSmith/Langfuse/Phoenix/MLflow/AgentOps. Der Standard ist OpenTelemetry.
- 🤖 Unverzichtbar für Agenten. Mehrstufige Fehler sind nur in einem vollständigen Session-Trace sichtbar.
„Schnell und verfügbar" reicht nicht, um KI zu vertrauen. Produktionsreif ist sie erst, wenn du ins Innere sehen und die Qualität messen kannst. Beginne damit, traces auf OpenTelemetry-konforme Weise zu erfassen, und binde dann evals an. Zum Bau von Agenten siehe hier; zum Sicherheitsdesign die Guardrails.
FAQ
F. Wie unterscheiden sich Observability und Evaluation (evals)?
A. Observability zeigt, „was passiert ist" (traces, Kosten, Latenz); Evaluation misst, „ist die Antwort gut". Da eine Antwort schnell und verfügbar sein kann und trotzdem falsch ist, besteht der grundlegende Ansatz darin, beide als Paar zu verwenden.
F. Kann ich nicht einfach ein normales App-Monitoring-Tool verwenden?
A. Es kann Verfügbarkeit und Geschwindigkeit messen, aber nicht KI-spezifische Qualität wie Halluzination oder groundedness. KI braucht eine eigene Beobachtung (oder die OpenTelemetry-GenAI-Konventionen), die Prompts, Tokens und Tool-Aufrufe aufzeichnet.
F. Wo fange ich an?
A. Es ist sicher, auf OpenTelemetry-konforme Weise mit dem Erfassen von traces zu beginnen. Du vermeidest Vendor-Lock-in und kannst später Tools wie LangSmith oder Langfuse neu wählen. Visualisiere dann Kosten und Latenz und binde schließlich die Evaluation an.
F. Warum ist es für Agenten besonders wichtig?
A. Agenten-Fehler treten nicht in einem einzelnen Aufruf auf, sondern innerhalb mehrstufiger Kausalketten. Ohne einen vollständigen Session-Trace kannst du nicht festnageln, „welcher Schritt schiefging und warum", was Debugging unmöglich macht.
