Eine schlechte Antwort muss sich rekonstruieren lassen

Eine Nutzerin beschwert sich über eine falsche Antwort. Der Chat ist weg. Der Prompt ist unversioniert. Die Chunks kennt niemand. Ohne Observability lässt sich die Antwort nicht rekonstruieren.

Was rekonstruiert werden muss

Nicht das ganze Modell. Der eine Lauf:

welcher Prompt, welche Version

welche Chunks oder Tools

welches Modell, welche Token, welche Kosten

was die Nutzerin gesehen hat

Ohne das ist eine Reklamation nicht bearbeitbar. In einem regulierten Haus ist das ein Betriebsrisiko, kein Logging-Nice-to-have.

Was ich nicht meine

Ein Dashboard mit Token-Summen. Das ist FinOps. Nützlich. Es beantwortet nicht: warum hat Satz drei diese Normstelle erfunden?

Langfuse und ähnliche Tools helfen. Der Name im Title ist nicht das Ziel. Das Ziel ist der Pfad von der Frage zur Aussage. Siehe Quellenbindung.

Typischer Fund

Ein Team loggt HTTP-Status und Latenz. Der Inhalt der Antwort fehlt. Zwei Wochen später lässt sich ein Vorfall nicht nachvollziehen. Kosten pro Anfrage kennt ebenfalls niemand, weil die Token nicht am Request hängen.

MCP-Tool-Calls ohne Metadaten gehören in dieselbe Schublade. Der MCP-Artikel beschreibt das Logging. Hier zählt, ob ein Reviewer den Lauf ohne Chatverlauf nachbauen kann.

Was der Check daraus macht

Im LLM-Readiness-Check ist das Tag 3 neben Evaluation. Fehlt der Pfad, steht „nicht produktionsreif“ im Bericht, auch wenn die Demo glänzt.

Verwandt: Evaluation. Leistung: KI-Engineering. Praxis: Gesundheits-Chatbot.