grok-bot
ea82f772ad
Tippfehler-Cluster (02–05, 09, 12, 23, 27–28) und Terminologie (Outcomes 16↔18, Budget 16↔23, prompt_version, Coding-Agent, fester Workflow). Handoff: Git-Remote, P0/P1A/P1B erledigt, nächster Slice Faktencheck.
11 KiB
Qualität in Produktion
Offline-Gates sind grün (Kapitel 17). Zwei Wochen Live-Traffic später: mehr Tickets „Antwort hilfreich: nein“, Repair-Rate steigt, niemand hat alarmiert — HTTP war 200, p95 ok, Demo-Set immer noch grün. Die Qualität ist still gekippt.
Produktion ist eine andere Verteilung als euer Golden Set. Wer nur offline misst, steuert blind.
Kern in einem Satz: Online braucht ihr Quality Signals, kontrollierte Ausrollung (Shadow/Canary) und Drift-Bewusstsein — Silent Degradation ist der Default-Failure-Mode, nicht der Edge Case (T3, T9).
Dieses Kapitel ergänzt Offline-Eval um Betrieb der Qualität. Tiefe Tracing-Stacks → Kapitel 22; Kosten/SLO-Design → Kapitel 23; Incidents → Kapitel 25.
Bridge: Klassisches SE → AI Engineering
| Klassisches SE | Qualität online bei LLMs … |
|---|---|
| Error rate / Apdex / SLO | plus Task Success, refuse-rate, repair-rate, feedback |
| Canary / progressive delivery | Canary auf Qualität und Cost, nicht nur Crash-free |
| Shadow traffic | Shadow: neuer Prompt/Model ohne User-Impact vergleichen |
| Drift detection (Data/ML) | Input-, Retrieval-, Feedback- und Model-Provider-Drift |
| Synthetic monitoring | Golden-Canaries periodisch gegen Prod-Stack |
| Feature flags | Flags pro Capability, Prompt-Version, Model-Pin |
| Postmortems | inkl. „welches Signal fehlte?“ und Gate-Lücken |
Die Brücke: Reliability allein reicht nicht. Ein stabiler Endpoint kann zuverlässig Unsinn liefern.
Silent Degradation
Silent Degradation: das System bleibt verfügbar, die semantische Qualität sinkt — ohne roten Error-Spike.
Typische Auslöser
| Auslöser | Beispiel |
|---|---|
| Model-/Provider-Update | stilles Behavior-Change hinter derselben API-Alias |
| Prompt/Policy-Änderung | Format ok, Grounding schlechter |
| Index/Corpus-Drift | veraltete oder neue Docs, Chunk-Regression |
| Traffic-Mix-Shift | neue Sprache, neuer Channel, Abuse |
| Tool/API-Downstream | leere Felder → Modell füllt mit Halluzination |
| Budget/Timeout enger | mehr Abbrüche als success_degraded ohne Alarm |
Warum klassische SRE-Metriken versagen
5xx und Latenz fangen Provider-Ausfälle. Sie fangen nicht: höfliche, falsche Antworten; fehlende Citations; Tool-Wahl-Verschlechterung; „immer sicherer Refuse“ nach Policy-Tuning.
Implikation: Quality Proxies und Outcome-Taxonomy (Kapitel 16) gehören in dieselben Dashboards wie Errors.
Online Metrics und Signale
Must-have Proxies (start small)
| Signal | Was es grob misst | Vorsicht |
|---|---|---|
| Explicit feedback | Thumbs, Ratings, „report“ | Bias, geringe Rate |
| Task success (instrumentiert) | Downstream-Event: Ticket gelöst, Form accepted | Definition pflegen |
| Outcome rates | success / success_degraded / refuse / needs_human / error_validation_exhausted … |
Taxonomy stabil halten (Kap. 16) |
| Repair / fallback rate | Contract- und Model-Stress | kann auch strengere Validatoren bedeuten |
| Citation / grounding fail | RAG-Qualität | nur wenn gemessen |
| Human-review reject rate | HITL-Queue | Gold-Signal bei Gelb/Rot |
| Judge sample (online) | Rubrik auf Sample | Kalibrierung, Cost, Privacy |
Weak signals (nützlich, nicht allein)
- regenrieren / umformulieren lassen
- Session-Abbruch nach AI-Antwort
- Copy-paste der Antwort in andere Systeme (proxy für Nutzen — vorsichtig)
- Support-Kontakte mit Tag
ai-quality
Was „gut“ ist, steht in der Spec
Online-Metriken ohne Zielkorridor aus der Feature-Spec erzeugen Dashboard-Theater. Definiert: erlaubte refuse-rate, max repair-rate, min task-success — feature-spezifisch, nicht branchenweit erfunden.
Shadow, Canary, Rollback
Shadow
Neuer Prompt/Model/Index verarbeitet Kopien des Traffics (oder Sample); User sieht nur Control.
| Pro | Contra |
|---|---|
| Vergleich auf realer Verteilung | doppelte Cost; PII/Compliance klären |
| kein User-Impact | Side Effects dürfen nicht doppelt feuern |
| gut vor riskanten Switches | Tool-Writes: shadow read-only oder dry-run |
Shadow braucht denselben redaction- und retention-Rahmen wie Prod-Logs (Kapitel 20).
Canary
Kleiner Live-Anteil auf Treatment (z. B. 1–5–25–100 %).
Stop-the-line Kriterien (Beispiele — Schwellen feature-spezifisch):
- Task-success oder Human-reject verschlechtert sich über Δ
- Safety-Violation > 0 in kritischer Klasse
- Cost/Latency außerhalb Envelope
- repair_rate / fallback_rate explodiert
Rollback
Rollback ist First-Class: Prompt-Version, Model-Pin, Index-Version, Policy-Flag einzeln oder als Bundle zurück. Wenn Rollback 2 Stunden dauert, ist euer Versionierungskonzept kaputt (T9).
Offline green → Shadow compare → Canary with quality gates → Promote / Rollback
Drift: was sich verschiebt
| Drift-Art | Symptom | Hebel |
|---|---|---|
| Input / Traffic | neue Sprachen, längere Tickets, neue Intents | Slices, Routing, Prompt-Scope |
| Retrieval / Data | schlechtere Treffer, veraltete Policies | Index-Pipeline, freshness, eval slice |
| Model / Provider | Format, Tool-Wahl, Stil ändert sich | pin, canary, contract tests |
| Feedback | User erwarten plötzlich mehr | Spec und UX ehrlich halten |
| Policy | strengere Guardrails → mehr Refuse | Produktentscheid, nicht nur „Qualität runter“ |
Detection (pragmatisch)
- Golden Canaries: fester Mini-Set periodisch gegen Prod (synthetic).
- Slice-Dashboards: Qualität und Outcomes nach Channel/Locale/Intent.
- Distribution checks: Input-Länge, language, retrieval hit-rate, tool error mix.
- Baseline windows: vergleiche diese Woche vs. last green canary, nicht nur vs. „gefühlt“.
Kein Anspruch auf Research-Grade Drift-Detektoren — sichtbare Deltas und Owner, die reagieren.
Feedback-Loops schließen
Prod traffic → signals → triage → Golden Set / Prompt / Policy / Model
↓
Alert / Review queue
| Loop | Rhythmus |
|---|---|
| Alert auf Quality-Drop | near-real-time / hourly je nach Volume |
| Sample-Review (Mensch) | täglich/wöchentlich je Risiko |
| Golden-Set-Erweiterung aus Prod | sprintlich, mit Label-Review |
| Model/Prompt-Experiment | Canary-Prozess, nicht Hotfix im Prod-Prompt |
Wichtig: Feedback ist biased (Unzufriedene klicken eher). Kombiniert explizite Signale mit instrumentiertem Task Success und synthetischen Canaries.
Patterns und Trade-offs
Pattern: Outcome taxonomy everywhere
Jeder Request endet in einem bekannten Outcome — UX, Metrics, Alerting teilen dasselbe Vokabular (Kapitel 16).
Trade-off: Disziplin im Code; Silent Müll wird sichtbar.
Pattern: Quality burn rate
„Wie schnell verbrauchen wir Vertrauen?“ — z. B. negative feedback pro 1000 sessions, human rejects pro Tag. Frühwarnung vor dem Ticketsturm.
Trade-off: Metrik muss zur UX passen; sonst Gaming.
Pattern: Paired control in canary
Nicht nur Treatment-Metrics: immer Delta zu Control im selben Zeitfenster (A/B oder time-sliced).
Trade-off: Traffic-Splitting-Komplexität; belastbarere Entscheidungen.
Pattern: Read-only shadow for tools
Shadow darf Tools lesen/simulieren, Writes nur im Control-Pfad.
Trade-off: Shadow unvollständig bei Write-lastigen Flows; dafür sicher.
Decision Frame: Alert jetzt oder abwarten?
| Signal | Tendenz |
|---|---|
| Safety / leakage / tool abuse | sofort incident |
| Task success −Δ über Schwelle | canary halt / rollback |
| repair_rate ↑ nach Model-Change | untersuchen, oft rollback |
| einzelner viraler Bad Case | sample + repro; nicht immer global rollback |
| nur Thumbs bei n<30 | warten oder mehr Sample, nicht blinde Panik |
Trade-off: viele Online-Judges vs. wenige harte Proxies
| Viele Judges | Wenige Proxies |
|---|---|
| teuer, privacy-sensibel | günstig, stabil |
| semantisch reich | grob, aber actionable |
| Drift des Judges | weniger Magie |
Start: Outcomes + task events + gezieltes Human-Sample. Judge online erst mit Kalibrierung und Budget.
Anti-Patterns
| Anti-Pattern | Symptom | Besser |
|---|---|---|
| Offline-only confidence | Prod unmonitored | Online proxies + canaries |
| HTTP-green = quality-green | 200 mit Unsinn | Outcome + task metrics |
| Big-bang model swap | Alias auf neu, beten | Shadow → Canary → pin |
| Canary only on errors | Qualität kippt unbemerkt | Quality stop rules |
| Dashboard without owner | niemand reagiert | named On-Call + Runbook |
| Feedback as only truth | Bias, low n | multi-signal |
| Hotfix prompt in prod | keine Version, kein Gate | Version + Mini-eval |
| Ignore degraded outcomes | alles „success“ | Taxonomy ehrlich |
| Shadow with side effects | Doppelbuchungen | dry-run / read-only |
| Alert fatigue | alle Schwellen rot | wenige, spez-gekoppelte Alerts |
Production Notes
Cost. Shadow verdoppelt Model-Kosten auf dem Sample; Online-Judge und langes Logging fressen Budget. Sample-Raten und Retention bewusst setzen (T7). Quality-Incidents sind auch Cost-Incidents (Support, Rollback, Trust).
Latency. Canary und Metrics-Pipelines dürfen p95 der User-Path nicht spoilieren: async feedback, async judge. Synthetic canaries getrennt schedulen.
Observability. Quality Signals in denselben Traces: outcome, versions, retrieval hit, tool errors, feedback id (observability-minimum.md). Ohne Versionsfelder sind Drift-Postmortems Spekulation (Kapitel 22).
Security. User-Feedback und gespeicherte Outputs können Angriffe und PII enthalten. Redaction, Zugriff, keine automatische Übernahme von User-Text in Prompts ohne Review (Kapitel 19, Kapitel 20).
Lifecycle. Jede Promotion endet mit beobachteter Online-Stabilität, nicht mit grünem Offline-Run allein (T9). Owner für Quality-Dashboard und Canary-Gates (T10). Runbook: was bei Quality-Drop zuerst passiert (templates/incident-runbook-ai.md).
Key Takeaways
- Silent Degradation ist der Normalfall ohne Quality Signals.
- Online: Outcomes, Task Success, Feedback, Repair/Fallback — neben Errors und Latency.
- Shadow → Canary → Promote/Rollback gilt für Model, Prompt, Index, Policy.
- Drift kommt von Traffic, Daten, Modell und Policy — Slices und Canaries machen ihn sichtbar.
- Feedback-Loops füttern Golden Sets; Offline und Online sind ein System (T3).
- Wenige spez-gekoppelte Alerts schlagen Dashboard-Friedhöfe.
Praktische nächste Schritte
- Definiert 3–5 Online-Proxies für eure Top-Capability inkl. Alarm-Schwellen aus der Spec.
- Stellt Outcome-Taxonomy in Prod-Logs sicher und dashboarded Raten.
- Richtet einen Golden-Canary (synthetic) gegen den Prod-Stack ein.
- Schreibt Canary-Stop-Regeln vor dem nächsten Model-Wechsel.
- Plant den Feedback→Golden-Set-Prozess (wer labelt, wie oft).
- Security-Fläche der laufenden Systeme: Security und Safety.