LLM-Observability und Tracing für Finanz-Workloads

Ein Finanz-LLM-System ist genau dann diagnostizierbar, wenn sich jede Antwort, die es im letzten Quartal produziert hat, exakt rekonstruieren lässt: der aufgelöste Prompt, der abgerufene Kontext und seine Versionen, die rohe Ausgabe, die Token-Zahlen und der Modellstring. Observability ist die Disziplin, diesen Trace bei jedem Aufruf festzuhalten und anschließend in Produktion günstige Checks dagegen laufen zu lassen, sodass eine Regression als Alert auftaucht statt als Kundenbeschwerde.

Die meisten Teams instrumentieren zuerst die falsche Ebene. Sie bauen ein Dashboard mit Request-Volumen und durchschnittlicher Latenz, das Ihnen sagt, dass der Dienst läuft, aber nichts darüber, ob die Antworten korrekt sind. Bei einem Finanz-Workload ist der Fehler, der Ihnen wehtut, ein selbstsicherer Satz mit einer falschen Zahl darin, und dieser Fehler bleibt für Infrastruktur-Metriken unsichtbar. Er zeigt sich nur, wenn Sie erfasst haben, was das Modell gesehen und was es gesagt hat, und dann beides miteinander vergleichen.

Ein Trace ist ein Baum – und dieser Baum ist Ihre Arbeitseinheit

Eine einzelne Nutzerfrage kann sich in einen Retrieval-Schritt, drei Tool-Aufrufe, einen Re-Ranking-Durchlauf und zwei Modell-Completions auffächern. Wenn Sie diese als separate Zeilen loggen, können Sie die eine Frage nicht beantworten, auf die es bei einem Fehler ankommt: Was hat die gesamte Pipeline für genau diesen Input getan? Die Span, die Sie interessiert, ist also der Trace – ein Baum, der jeden Sub-Aufruf auf eine Wurzel zurückführt, mit einer stabilen ID, die Sie einem Analysten in die Hand geben oder in ein Ticket einfügen können.

Für jeden Knoten in diesem Baum erfassen wir:

• Den aufgelösten Prompt, nach Template-Rendering und Kontext-Injektion, nicht das Template. Das Template verrät Ihnen die Absicht; der aufgelöste Prompt verrät Ihnen, was tatsächlich an das Modell ging, inklusive der abgerufenen Zahlen, die falsch gewesen sein könnten.
• Den abgerufenen Kontext mit Dokument-IDs und Versions- oder As-of-Daten. Hier lebt die Point-in-Time-Korrektheit. Wenn Ihr Retriever eine restatete 10-Q gezogen hat, die zum Entscheidungszeitpunkt gar nicht existierte, sieht die Antwort vertretbar aus und leakt still Zukunftsinformationen.
• Die rohe Modellausgabe vor jedem Parsing. Parser verstecken Fehler. Wenn die JSON-Extraktion auf einen Default zurückfällt, wollen Sie die fehlerhafte Ausgabe sehen, die das ausgelöst hat.
• Die Token-Zahlen für Input und Output, das Modell und den Versionsstring, die Temperatur sowie die Latenz pro Knoten.

Zwei praktische Regeln. Erstens: Propagieren Sie die Trace-ID durch jeden Hop, auch durch Tool-Aufrufe, die Ihren Prozess verlassen, sonst verliert der Baum Äste. Zweitens: Sampeln Sie im Finanzbereich auf dem Write-Path nichts. Speicher ist billiger als ein nicht reproduzierbarer Abstimmungsbruch zum Quartalsende. Sampeln Sie später, wenn Sie entscheiden, was bewertet wird.

Token-Zahlen sind Ihr frühestes Drift-Signal

Teams behandeln Token-Zahlen als Rechnungsposten. Sie sind aber zugleich das sauberste Frühwarnsignal, das Sie für Verhaltens-Drift haben. Ein Retrieval-Bug, der plötzlich doppelt so viel Kontext in den Prompt stopft, zeigt sich als sprunghafter Anstieg der Input-Tokens – Tage bevor jemandem auffällt, dass die Antworten vager wurden. Ein Prompt-Injection-Versuch, der das Modell schwafeln lässt, zeigt sich als Output-Token-Spike auf einer schmalen Menge von Traces.

Wir rechnen Tokens deshalb pro Trace, pro Prompt-Template und pro Mandant ab und alerten auf Verteilungsverschiebungen statt auf Summen:

• Input-Tokens pro Template. Ein Sprung bedeutet, dass sich Ihr Kontext-Assembly verändert hat, meist weil ein Retriever mehr oder längere Dokumente zurückgab, als für den Prompt vorgesehen war.
• Output-Tokens pro Template. Ein Sprung bei einer Aufgabe, die ein festes Schema produzieren sollte, bedeutet, dass das Modell das Format nicht mehr respektiert – oft das erste Symptom eines Modell-Versionswechsels auf Anbieterseite.
• Kosten, dem Mandanten und dem Workflow zugeordnet, sodass sich Straight-Through-Processing-Raten gegen die Ausgaben lesen lassen. Ein Workflow, der drei Retries pro Erfolg braucht, sagt Ihnen etwas, das die Durchschnittslatenz-Kurve nicht verrät.

Der Punkt ist: Token-Telemetrie, auf Trace-Ebene erfasst, dient zugleich als Verhaltens-Monitor. Sie zahlen ohnehin dafür, Tokens für die Rechnung zu zählen. Leiten Sie dieselben Zahlen in Ihr Alerting.

Evaluation muss auch in Produktion laufen

Offline-Eval-Sets fangen ab, woran Sie beim Testen gedacht haben. Produktion fängt den Rest. Diese Lücke wiegt im Finanzbereich schwerer als im allgemeinen Chat, denn Ihre Inputs sind naturgemäß adversarial: Filings werden restatet, Entity-Namen kollidieren über Tochtergesellschaften hinweg, und eine Gegenpartei, die letzten Monat eine juristische Einheit war, sind nach einem Carve-out zwei. Ein im März eingefrorenes Offline-Set enthält die Edge-Cases vom Juni nicht.

Wir betreiben zwei Ebenen von Checks kontinuierlich. Referenzfreie Checks laufen auf jeder Anfrage und brauchen keine Labels:

• Schema- und Typvalidierung auf strukturierter Ausgabe, sodass eine fehlerhafte Zahl niemals ins Straight-Through-Processing gelangt.
• Numerisches Grounding: Jede Zahl in der Antwort muss auf einen Wert im abgerufenen Kontext zurückführbar sein, sonst wird die Antwort geflaggt. Das ist der Check mit dem höchsten Wert für den Finanzbereich, weil er den Fehler „selbstsicher, aber falsche Zahl“ direkt abfängt.
• Citation-Coverage und Refusal-Rate, als Zeitreihen getrackt. Eine steigende Refusal-Rate nach einem Deploy bedeutet meist, dass eine Prompt-Änderung das Modell übervorsichtig gemacht hat.

Die zweite Ebene ist bewertete Evaluation auf einer gesampelten Teilmenge, mit einem Rubric und entweder menschlichem Review oder einem Model-as-Judge, dessen eigene Ausgaben Sie ebenfalls loggen und auditieren. Sie bewerten nicht jeden Trace; Sie bewerten eine stratifizierte Stichprobe plus jeden Trace, der einen referenzfreien Check nicht bestanden hat, denn genau dort sind die Labels ihr Geld wert. Speisen Sie bestätigte Fehler zurück ins Offline-Set, damit das nächste Release gegen sie getestet wird. Diese Schleife – nicht das Dashboard – ist es, die das System zwischen den Quartalsenden ehrlich hält.

Noch eine Sache, die man leicht überspringt und teuer überspringt. Verknüpfen Sie den Trace-Store vom ersten Tag an mit Ihren Audit- und Lineage-Anforderungen. Wenn ein Regulator oder ein interner Prüfer fragt, warum ein System an einem bestimmten Datum eine bestimmte Zahl produziert hat, lautet die Antwort: eine Trace-ID und ihr vollständiger Baum, aufbewahrt unter denselben Kontrollen wie die zugrunde liegenden Daten. Wenn Sie Observability als reine Debugging-Bequemlichkeit bauen und die Aufbewahrung später anflanschen, werden Sie feststellen, dass die nützlichen Traces genau in der Woche abgelaufen sind, bevor Sie sie brauchten.