Befund
Im per-Konzept-Fan-out des Extractors stehen zwei pro-Call-variable Blöcke vor dem Chunk-Text (Prompt-Template extractor.py:85-104, Befüllung :362-363, 393-405):
tag_whitelist mit source-abhängiger Prio-Sortierungexisting (bestehende Konzepte) nach Titel-Overlap sortiert
Damit endet der cachebare gemeinsame Prompt-Präfix (Anthropic Prompt-Caching) bereits vor dem statischen Instruktionsblock-Rest. Real gemessen am größten Run-Trace (2026-06-02, by-chapter, 129 Calls): Input-Seite gesamt ≈ 6,1 M Tokens, davon 2,54 M cache_creation vs. 3,57 M cache_read — 41 % der Input-Seite ist Cache-NEUanlage statt -Nutzung.
Impact
Größter verbliebener qualitätsneutraler Token-Hebel. Die frühere Analyse („kein großer Eval-Token-Hebel bei gleicher Qualität", 2026-06-21) bleibt für die Eval korrekt — dieser Hebel liegt in der Extraktions-Phase und war damals nicht im Blick. Betrifft Subscription- (Auto-Caching) und API-Backend (nach cache_control-Einbau, siehe separates litellm-Issue) gleichermaßen.
Fix-Richtung
Prompt-Layout umstellen: statische Blöcke (Instruktionen, source_meta, volle Whitelist unsortiert) nach vorn; alles Konzept-Spezifische (Prio-Tags, existing-Auswahl, Chunk) ans Ende. Optional ersten Call pro Stage „vorwärmen", bevor der Semaphore-Fan-out startet. Wirkung messen: cache_creation/cache_read-Verhältnis vorher/nachher am echten Lauf (Traces in .cache/runs/), plus Eval-Stichprobe zur Bestätigung Label-Neutralität (Lehre aus dem justification-A/B: Prompt-Umbauten nie ungemessen als „neutral" deklarieren).
Priorität
Hoch nach BA — messbarer Kosteneffekt bei jedem Lauf.
Quelle: Projekt-Review 2026-07-07 (Effizienz-Subagent; Messwerte aus realem Run-Trace).
Befund
Im per-Konzept-Fan-out des Extractors stehen zwei pro-Call-variable Blöcke vor dem Chunk-Text (Prompt-Template
extractor.py:85-104, Befüllung:362-363, 393-405):tag_whitelistmit source-abhängiger Prio-Sortierungexisting(bestehende Konzepte) nach Titel-Overlap sortiertDamit endet der cachebare gemeinsame Prompt-Präfix (Anthropic Prompt-Caching) bereits vor dem statischen Instruktionsblock-Rest. Real gemessen am größten Run-Trace (2026-06-02, by-chapter, 129 Calls): Input-Seite gesamt ≈ 6,1 M Tokens, davon 2,54 M cache_creation vs. 3,57 M cache_read — 41 % der Input-Seite ist Cache-NEUanlage statt -Nutzung.
Impact
Größter verbliebener qualitätsneutraler Token-Hebel. Die frühere Analyse („kein großer Eval-Token-Hebel bei gleicher Qualität", 2026-06-21) bleibt für die Eval korrekt — dieser Hebel liegt in der Extraktions-Phase und war damals nicht im Blick. Betrifft Subscription- (Auto-Caching) und API-Backend (nach cache_control-Einbau, siehe separates litellm-Issue) gleichermaßen.
Fix-Richtung
Prompt-Layout umstellen: statische Blöcke (Instruktionen, source_meta, volle Whitelist unsortiert) nach vorn; alles Konzept-Spezifische (Prio-Tags, existing-Auswahl, Chunk) ans Ende. Optional ersten Call pro Stage „vorwärmen", bevor der Semaphore-Fan-out startet. Wirkung messen: cache_creation/cache_read-Verhältnis vorher/nachher am echten Lauf (Traces in
.cache/runs/), plus Eval-Stichprobe zur Bestätigung Label-Neutralität (Lehre aus dem justification-A/B: Prompt-Umbauten nie ungemessen als „neutral" deklarieren).Priorität
Hoch nach BA — messbarer Kosteneffekt bei jedem Lauf.
Quelle: Projekt-Review 2026-07-07 (Effizienz-Subagent; Messwerte aus realem Run-Trace).