Observability & Telemetrie

Szenario

Eure LLM-Pipeline läuft in vier Stufen: Retrieval → Rerank → LLM → Postprocess. Ihr messt nur eine End-to-End-Latenz pro Request. Die p95 ist von 2 s auf 6 s gestiegen, die p50 blieb bei 1,8 s — also nur ein Teil der Requests ist langsam. Ihr müsst herausfinden, welche Stufe die Tail-Latenz verursacht.

Anforderungen

• Wie instrumentiert ihr, um die Ursache zu finden?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Jede Stufe als eigener Span unter einer gemeinsamen Trace-/Korrelations-ID, sodass ihr die Zeit pro Stufe seht und einen einzelnen langsamen Request durch alle vier Stufen verfolgen könnt.. Richtig. Nur korrelierte Spans attribuieren die Zeit auf eine Stufe und lassen sich pro Request verfolgen — so seht ihr, dass die langsamen Requests z. B. großes Retrieval haben, das dann auch das LLM bremst. Genau das braucht ein Tail-Problem.
2. Plausibler Fehlweg: Feinere End-to-End-Perzentile ergänzen (p50/p90/p95/p99), um das Tail-Verhalten genauer zu sehen — als zentrale Collector-Regel für alle Pfade versioniert und mit festem Aufbewahrungsziel ausgerollt. Feinere Aggregate der Gesamtzeit bestätigen nur, dass ein Tail existiert — sie attribuieren keine Sekunde auf eine Stufe. Du weißt danach präziser, dass es langsam ist, aber weiterhin nicht wo.
3. Plausibler Fehlweg: Pro Stufe eine eigene Latenz-Metrik (Histogramm je Stufe) erfassen, ohne Trace-Korrelation.. Stufen-Aggregate zeigen die Durchschnittslast je Stufe, aber du kannst einen einzelnen langsamen Request nicht durch die Stufen verfolgen und nicht sehen, dass Retrieval- und LLM-Langsamkeit im selben Request zusammenfallen. Ein p95-Tail aus einer Request-Teilmenge verschwindet im Stufen-Durchschnitt.
4. Plausibler Fehlweg: Einen Zeitstempel bei Request-Start und -Ende loggen und die Differenz bilden.. Das ist dieselbe eine Zahl in Log-Form — keine Aufschlüsselung nach Stufe. Und unkorrelierte Logs der vier Stufen lassen sich ohne gemeinsame ID nicht zu einem Request zusammenfügen.

Szenario

Ein Nutzer meldet eine schlechte Antwort von vor drei Tagen. Seither habt ihr zweimal einen neuen Prompt deployt, und euer Provider hat sein Modell hinter derselben API still aktualisiert. Zusätzlich läuft gerade ein A/B-Test, der pro Request eine von zwei Prompt-Varianten zuweist. Ihr wollt Requests künftig so festhalten, dass ein solcher Fall reproduzierbar ist.

Anforderungen

• Was stempelt ihr pro Request fest, damit Incidents reproduzierbar sind?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Die exakte Prompt-Version (Hash/Tag), die Modell-Identität inklusive Snapshot/Version und die aufgelöste Config (Temperatur, Retrieval-Parameter, zugewiesene A/B-Variante).. Richtig. Genau dieses Tripel — Prompt-Version, Modell-Snapshot, aufgelöste Config inkl. Experiment-Zuweisung — identifiziert eindeutig, was den Request bedient hat, unabhängig von späteren Deploys und stillen Provider-Wechseln.
2. Plausibler Fehlweg: Den Git-Commit-SHA der App zum Request-Zeitpunkt — damit ist der Stand ja eindeutig festgehalten.. Der Commit pinnt euren Code, nicht das provider-seitige Modell (das sich unabhängig ändert) und nicht die per-Request aufgelöste A/B-Variante. Notwendig, aber nicht hinreichend — die reproduktionsrelevanten Teile fehlen.
3. Plausibler Fehlweg: Nur den Zeitstempel — welcher Prompt und welches Modell live waren, rekonstruiert ihr im Incident aus dem Deploy-Log.. Rekonstruktion aus dem Zeitstempel bricht genau hier: Der stille Modell-Wechsel steht in keinem eurer Deploy-Logs, und die per-Request zugewiesene A/B-Variante lässt sich aus der Uhrzeit nicht ableiten. Aufzeichnen schlägt Rekonstruieren.
4. Plausibler Fehlweg: Die Sampling-Parameter (Temperatur, top_p) pro Request — die bestimmen ja das Ergebnis.. Config allein ohne Prompt- und Modell-Identität sagt nicht, was die Antwort erzeugt hat. Selbst bei identischen Parametern liefert ein anderer Modell-Snapshot andere Ausgaben — die Identität fehlt.

Szenario

Ein Chat-Request erscheint im Backend als drei voneinander unabhängige Traces. Latenz und Fehler lassen sich deshalb nicht bis zum Modellanbieter zurückverfolgen.

Anforderungen

• Welches Ereignis bricht die Kausalitätskette?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Den aktiven W3C-Trace-Kontext in erlaubte Message-Metadaten injizieren und beim Konsumenten extrahieren. Producer und Consumer bleiben dadurch kausal verbunden. Für Messaging braucht es eine bewusste Kontextübertragung, nicht nur lokale Spans.
2. Plausibler Fehlweg: Im Worker denselben festen Trace-Identifier für alle Queue-Nachrichten dieses Tages verwenden — als zentrale Collector-Regel für alle Pfade versioniert und mit festem Aufbewahrungsziel ausgerollt. Ein geteilter Tageswert vermischt unabhängige Requests. Trace-IDs müssen eine konkrete verteilte Operation korrelieren.
3. Plausibler Fehlweg: Nur die Provider-Dauer als Histogramm exportieren und die drei Traces unverändert lassen. Das Histogramm zeigt eine Verteilung, stellt aber die verlorene Kausalität eines einzelnen Requests nicht wieder her.

Szenario

Euer Chat-Assistent hat keine Qualitäts-Labels. Ihr habt 👍/👎-Buttons eingebaut, aber weniger als 2 % der Nutzer klicken je darauf — und wer klickt, ist meist besonders verärgert oder begeistert. Product will trotzdem verlässlich wissen, ob die Antworten taugen.

Anforderungen

• Wie gewinnt ihr ein brauchbares Qualitätssignal aus dem Betrieb?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Zusätzlich implizite Signale erfassen (Regenerate, Copy, umformulierte Folgefrage, schneller Abbruch) und jedes Signal — explizit wie implizit — an die Trace-/Request-ID der auslösenden Antwort knüpfen.. Richtig. Implizite Signale decken die schweigende Mehrheit ab, und die Verknüpfung an den Trace macht sie pro Prompt-/Modell-Version auswertbar. So wird aus spärlichem Feedback ein belastbares, attribuierbares Signal.
2. Plausibler Fehlweg: Beim expliziten 👍/👎 bleiben und die Klickrate durch UI-Nudges hochtreiben.. Freiwilliges Feedback ist strukturell spärlich und verzerrt (nur die Ränder klicken). Selbst verdoppelte 2 % repräsentieren nicht den Median — und das Mehrheitsverhalten, das die impliziten Signale zeigen, bleibt ungenutzt.
3. Plausibler Fehlweg: Feedback als eigenständige Metrik führen: ein täglicher Zähler der 👎, ohne Bezug zum einzelnen Request.. Ein aggregierter 👎-Zähler zeigt, dass etwas schlecht ist, aber nicht welche Prompt-Version, welches Modell oder welcher Request-Typ. Ohne Trace-Verknüpfung kannst du nicht triagieren oder attribuieren.
4. Plausibler Fehlweg: Nutzer-Feedback durch einen automatischen LLM-Judge ersetzen, der jede Antwort bewertet.. Ein Judge misst modell-geurteilte Qualität, nicht die tatsächliche Nutzer-Zufriedenheit — und der Bau von Eval-Judges ist ein anderes Thema (llmops/evaluation). Hier geht es darum, echte Nutzer-Signale als Telemetrie an Traces zu binden.

Szenario

Euer LLM-Support-Assistent macht ~50.000 Requests/Tag. Heute wird pro Request nur der finale Antworttext geloggt. Gestern kam ein Beschwerdefall — die Antwort war fachlich falsch — und ihr konntet ihn nicht nachstellen: Ihr wisst nicht, was der Nutzer fragte, welcher Prompt aktiv war und welche Dokumente das Retrieval lieferte. Ihr definiert jetzt den Telemetrie-Umfang neu.

Anforderungen

• Was erfasst ihr pro Request?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Ein strukturierter Datensatz je Request: Input, Output, Token-Zahlen, Latenz, Kosten, Modell- und Prompt-Version sowie Retrieval-Kontext als Referenzen (Doc-IDs + Scores). PII-Redaction läuft in der dafür zuständigen Schicht, Retention ist definiert.. Richtig. Das ist der reproduzierbare Minimalumfang: Input + Versionen + Retrieval-Kontext erlauben, den Fall nachzuspielen; Referenzen statt Volltext und eine Retention halten das Volumen im Griff; PII wird gesondert behandelt statt hier ignoriert.
2. Plausibler Fehlweg: Input und Output vollständig im Klartext, unbegrenzt aufbewahrt — lieber zu viel als zu wenig, damit nie wieder etwas fehlt — als zentrale Collector-Regel für alle Pfade versioniert und mit festem Aufbewahrungsziel ausgerollt sowie ohne Unterscheidung nach Diagnosewert oder Datenklasse dauerhaft beibehalten. Vollständigkeit ohne Grenzen ist der andere Fehler: bei 50.000 Requests/Tag explodieren Speicher und Kosten, und unbegrenzt gehortete Klartext-Inputs sind eine PII- und Compliance-Haftung. Umfang braucht Retention und Referenzierung, nicht Horten.
3. Plausibler Fehlweg: Nur aggregierte Metriken — Token-Zahlen, Latenz und Kosten pro Zeitfenster. Das genügt für Dashboards und ist am günstigsten.. Damit baust du Kosten- und Latenz-Dashboards, aber kein einzelner Beschwerdefall wird reproduzierbar: Aggregate zeigen nie, was das Modell sah oder sagte. Genau diese Lücke hat euch gestern blockiert.
4. Plausibler Fehlweg: Output plus eine Request-ID — Input, Versionen und Retrieval-Kontext lasst ihr weg, um Volumen zu sparen.. Eine Request-ID korreliert nur, sie rekonstruiert nichts. Ohne Input, Prompt-/Modell-Version und Retrieval-Kontext bleibt der Fall unreproduzierbar — das ist fast der Status quo, der gerade versagt hat.