KI-Observability ist die Schicht, die jeden Prompt, jeden Retrieval-Aufruf, jeden Tool-Call und jede Modell-Antwort in einem produktiven KI-System aufzeichnet, indiziert und replay-fähig macht. Sie ist der Unterschied zwischen «der Agent hat letzten Dienstag etwas Seltsames getan» und «hier ist der exakte Trace, hier ist der Input, hier ist der retrievte Kontext, hier ist, was das Modell produziert hat, und hier ist, warum wir es so geroutet haben.»

Was eine Observability-Schicht aufzeichnet.

  • Jeder Prompt mit Version, Modell und Parametern.
  • Jeder Retrieval-Aufruf mit Anfrage, den top-K zurückgegebenen Chunks und ihren Similarity-Scores.
  • Jeder Tool-Call mit dem gewählten Tool, den Argumenten, der Antwort und der Latenz.
  • Jeder Modell-Output mit den Eval-Scores, die er gegen die Rubrik erhalten hat, und ob das Regression-Gate ihn akzeptiert hat.
  • Kosten und Latenz pro Schritt, damit Operatoren sehen, welcher Agent teuer ist, ohne raten zu müssen.

Warum KI-Observability mehr ist als normales Logging.

Ein nicht-KI-System scheitert deterministisch: derselbe Input produziert dieselbe Ausgabe, und ein Stack-Trace zeigt auf die Code-Zeile. KI-Systeme scheitern nicht-deterministisch — derselbe Input kann unterschiedliche Outputs produzieren, der Failure-Mode liegt in den Daten oder im Prompt statt in einer Code-Zeile, und «es fixen» bedeutet das Eval-Set, die Rubrik oder den Retrieval-Index zu ändern. Nichts davon ist ohne die Replay-Schicht möglich.

«Wenn Sie den Failure nicht replayen können, können Sie ihn nicht fixen. Sie können nur hoffen, dass er nicht wieder passiert.»

Was Observability nicht ist.

Sie ist kein Dashboard. Sie ist kein «wir loggen nach Datadog» im Nachhinein. Sie ist nicht die eingebaute Usage-Grafik des LLM-Providers. KI-Observability ist die Engineering-Oberfläche, die einem realen Menschen erlaubt zu rekonstruieren, was bei einem spezifischen Request, in Produktion, vor sechs Wochen passiert ist — und zu entscheiden, ob das System eine neue Fixture, einen Rubrik-Wechsel, eine Prompt-Überarbeitung oder einen Modellwechsel braucht.

Häufige Fragen.

Was ist KI-Observability?
KI-Observability ist die Schicht, die jeden Prompt, jeden Retrieval-Aufruf, jeden Tool-Call und jede Modell-Antwort in einem produktiven KI-System aufzeichnet, indiziert und replay-fähig macht. Sie erlaubt es Operatoren, einen einzelnen fehlerhaften Output zu debuggen, eine Aufsichtsfrage zu beantworten oder Drift über Wochen zu messen.
Unterscheidet sich KI-Observability von normalem Logging?
Ja. Normales Logging zeichnet auf, dass etwas passiert ist. KI-Observability erlaubt es, exakt zu replayen, was das Modell gesehen und produziert hat. Derselbe Input kann in KI unterschiedliche Outputs liefern — «check die Logs» reicht nicht. Sie brauchen die volle Input-Verteilung, den retrievten Kontext, die Tool-Calls und die Modellparameter zusammen für jeden spezifischen Request.
Was baut Morvion in KI-Observability ein?
Trace-Storage für jeden Prompt + Retrieval + Tool-Call + Antwort, Prompt-Version-Pinning in Git, Eval-Scores auf jedem Release aufgezeichnet, Replay-Tooling, das jeden vergangenen Run rekonstruiert, und Kosten-/Latenz-Telemetrie pro Schritt. Unabhängig von der UI, damit jedes Dashboard oder jede Operator-Oberfläche aus denselben Daten lesen kann.
Kostet KI-Observability viel?
Weniger als sie nicht zu haben. Die Kosten sind Trace-Storage (klein im Vergleich zum LLM-API-Spend) plus das Engineering der Replay-Schicht (einmalig, Tage Arbeit). Die Kosten, sie nicht zu haben, sind unsichtbare Regressionen, blockiertes Debugging und Unfähigkeit, eine Compliance- oder Stakeholder-Frage ohne retroaktives Engineering zu beantworten.

Englische Fassung: KI-Observability on the EN edition.