Messlauf-Diagnose-Ausbau (Bündel, priorisiert)

[TillQuandel]

Kontext

Sammel-Issue aus der 3-Runden-Messlauf-Diagnose (A/B-Effizienzreihe 2026-07-13, Profile legacy vs. balanced, Runs M1–M5). Bündelt die noch offenen Diagnose-Ausbau-Punkte, die nicht bereits als eigenständiges Issue existieren (Token-Totals, Dauer-KPI, Cache-Pricing, Baseline-Overwrite siehe separate Issues). Priorisiert nach Aufwand/Nutzen.

Checkliste (priorisiert)

• (a) cur_tokens-Kachel um Cache-Anteile erweitern [S]. KPI-Kachel „Pipeline-Tokens" zeigt nur in+out ohne Cache (~10 % des billable, siehe Token-Totals-Issue). Run-Level-Kachel „Billable Tokens" (in+out+cache_r+cache_c) ergänzen — triviale Summe aus token_runs, cache_c bereits vorhanden.
• (b) Run-Label mit Notes-Zahl + Profil [S, braucht Nachvollziehbarkeit: Laufzeit-Profil (legacy/fast/balanced/quality) wird nicht persistiert — weder pipeline_runs noch Trace #235]. _run_options-Label „TT.MM. HH:MM · PDF · Version" hat weder Notes-Zahl (n_vault/n_gen liegt in DB) noch Profil. Ohne Profil sind legacy/balanced-Paare nicht als Paar erkennbar — in der A/B-Reihe wurde das Profil per Hand aus Uhrzeit+Logs rekonstruiert, weil pipeline_runs keine Profil-Spalte hat (runtime_config.profile existiert zur Laufzeit, orchestrator.py:2798, wird bei insert_run, :2765, aber nicht mitgeschrieben).
• (c) A/B-Compare-Panel ?run_a=&run_b= [M]. Aktuell nur 1 Run isolierbar (global-run-Dropdown); Vergleich zweier Läufe erfordert manuelle Zwei-Fetch-Gegenüberstellung von data.json?run=. Daten sind per-run vorhanden (agent_stats rechnet bereits über allowed_run_ids) — braucht Server-Param-Erweiterung + Delta-Tabelle (billable Tokens, cache_pct, Dauer, n_notes, hall, cov, accept, Kosten).
• (d) Bookkeeping-Event-Reader in build_data [M]. build_data/_read_agent_stats/_read_token_runs filtern strikt auf llm_call-Records und überspringen alle Bookkeeping-Events (stage_outcome, note_outcome, plan_stats, score_result, anchor_stats). Ein gemeinsamer Reader speist gebündelt:
  • Drop-/Routing-Funnel: stage_outcome-Events liegen seit heute in echten Traces (M5 20260713-093124: {"type":"stage_outcome","stage":"dedup","outcome":"dropped","drop_reason":"sibling_neardup"}) — Stage-Outcome-Events + Drop-Gründe als Voraussetzung für Gate-Funnel #197 Schritt 3 ist damit entsperrt. Achtung n_dropped-Semantik-Lücke: DB n_dropped=0 für M5 trotz echtem Trace-Drop; nur n_extracted−n_generated (5−4=1) verrät ihn. Ein Funnel kann nicht aus der DB gebaut werden, nur aus Trace-Events. Zusatzfalle: bei Alt-Runs bedeutet n_extracted=0 „nicht getrackt", nicht „0 extrahiert" — Funnel nur für Runs mit befülltem n_extracted rendern.
  • Stage-8-Anteil: Eval-Judge-Overhead als Anteil an der Agent-Zeit fehlt als Zahl (M1: eval 390,2 s von Σ≈1506 s ≈ 26 %).
  • Refine-Sicht: aus score_result-Sequenz je Note-Titel ableitbar (M1: 10 Critic-Calls für 4 Notes, M5: 16 für 4 Notes = 2,5–4× → Refine-Loops), aktuell nur im stdout-Log sichtbar.
• (e) Experiment-Tags + CSV/MD-Export [S]. pipeline_runs hat keine Tag/Label/Experiment-Spalte (21 Spalten geprüft). --tag/--experiment-CLI-Param → DB-Spalte + Run-Label („13.07. 08:25 · balanced · exp=ab-effizienz"). Zusätzlich Export-Endpoint /export.csv der gefilterten Run-Tabelle (Felder liegen bereits in data.json) — behebt die Hand-data.json-Fetches aus der A/B-Reihe.
• (f) build_data-Timing + ehrliches generated_at [S]. generated_at zeigt faktisch immer „jetzt" (Live-Server rebuildet pro Request, kein Memoizing) — kein echtes Staleness-Signal. build_data-Dauer nirgends instrumentiert (gemessen per Single-Fetch: 1,21 s/Request, wächst mit quality_history.jsonl-Größe, siehe Stage-8/Eval-Effizienz: PDF 3x pro Note, 24-MB-JSONL-Linearscan, Embeddings ohne Memoization, Cache-Rotation #151-Kommentar). Vorschlag: build_data mit perf_counter umschließen, „gebaut in X ms" anzeigen; „N Läufe, jüngster HH:MM (vor Xm)" aus latest.mtime als echte Frische-Zeile.
• (g) Pro-Note-/Pro-Wort-Normalisierung [S]. Alle Effizienz-KPIs sind absolut; A/B-PDFs unterscheiden sich in n_words (M3 = 1 Note aus 4100 Wörtern vs. 5-Note-Läufe ⇒ Äpfel/Birnen-Vergleich). n_words/n_generated liegen in DB vor — Tokens/Wort & Tokens/Note trivial ableitbar.
• (h) n=1-Statistik-Kennzeichnung [M]. Ein Lauf je (Profil, PDF) bei LLM-Nichtdeterminismus, kein Run-Level-Varianz/CI — ein legacy-vs-balanced-Delta kann Rauschen sein (nur die gepoolte Hall-CI existiert aktuell). Braucht mehrere Läufe/Zelle + Delta-CI, um daraus belastbare Aussagen abzuleiten.

Referenzierte Issues

#235 (Profil-Persistenz, Voraussetzung für (b)/(c)/(h)), #232 (retrieval-miss, separat), #197 Schritt 3 (Funnel, durch (d) entsperrt), #220 (stage_outcome-Instrumentierung, bereits vorhanden), #211/#212 (Lauf-Filter, Basis).

---

Quelle: Dashboard-Untersuchung 2026-07-13, 3 Runden Opus-Review (UX + Messlauf-Diagnose), Funde adversarial verifiziert.