Session-Prompt für nächste Session
Aufgabe: Kritisch auf Phase-2+3 schauen, alle Ergebnisse pruefen, entscheiden wie wir realistisch auf 80–90 % R@10_any kommen — ohne Florian-Eval-Set- Korrektur (das ist Marvin-extern und unklar wann).
Kontext in einem Satz
Phase 2 + 3 des Search-Pipeline-Rebuilds für Florian Icking sind durch. Wir stehen bei R@10_any 54.9 % auf 51-Case-Eval-Set, Plan-Ziel war 80 %. Marvin will jetzt auf 80–90 % kommen, ohne auf Florian zu warten.
Was du als Erstes lesen sollst (Pflicht-Pfade)
- Phase-2/3 Decision-Doc mit kompletter Bake-Off-Tabelle + Empfehlung + Phase-4-Optionen:
~/source/a-icking/docs/decisions/2026-05-17-search-pipeline-phase-2.md - Plan-Doku mit Original-Plan + Notausgang-Logik:
~/source/a-icking/docs/plans/2026-05-15-004-feat-search-quality-phase2-plan.md - Vault Run-Log mit Schichten-Tabelle:
intern/runs/2026-05-17-icking-phase-2/report.md - Manual-Review aller 51 Cases mit meinem Verdict pro Miss-Case:
intern/runs/2026-05-17-icking-phase-2/manual-review.md(216 KB, alle Queries + expected[] + Top-10 actual mit kurztext) - Pipeline-Diagramm zur ECS-Architektur:
inbox/2026-05-17-icking-phase2-pipeline-diagram.html
Aktuelle Zahlen (verifizierte Bake-Off-Ergebnisse)
| Schicht | Stack | R@10 any | R@10 wgr | p50 |
|---|---|---|---|---|
| 0 baseline | hybrid (langtext only) | 43.1 % | 45.1 % | 0.7 s |
| 1 multi-field | + kurztext-Fusion | 52.9 % | 54.9 % | 0.8 s |
| 2 + rerank | + Cohere Rerank 3.5 | 47.1 % | 52.9 % | 22 s* |
| 3 + rewrite | + Haiku 4.5 Query-Expansion | 51.0 % | 58.8 % | 4.4 s |
| 3a+3c final | + Diskriminator + GAEB-Synonyme | 54.9 % | 56.9 % | ~0.9 s |
* mit Quota-Throttle-Sleep; echte Latenz wäre 1.3s
Sieger-Pipeline-Code: Image inference-service-prod:phase3c in ECR
(av-production), Task-Def Revision 4. Branch
feat/search-quality-phase2 in ~/source/a-icking/, gepusht zu
marvin-khl/a-icking.
Was wir versucht haben (mit Lift gegen Schicht 0)
| Hebel | Lift R@10_any | Verdikt |
|---|---|---|
| Multi-Field (langtext + kurztext) | +9.8pp | ✓ Hauptgewinn, behalten |
| Cohere Rerank | +3.9pp | ✗ schadet auf R@10_any, off |
| Query-Rewrite via Haiku | +7.8pp | ⚠ R@10 neutral, R@1 schlechter |
| Brand+Material-Diskriminator | 0pp | ⚠ neutral bei W=0.05, leicht negativ bei W=0.10 |
| GAEB-Synonym in FTS only | 0pp | ⚠ R@1 +2pp, R@10 flat |
| GAEB-Synonym in FTS + Embedding | +2pp | ✓ kleiner Lift, behalten |
Kritische Fragen für die naechste Session
1. Stimmen unsere Bewertungen ueberhaupt?
Ich (Claude in dieser Session) habe alle 24 Miss-Cases bewertet als:
- 8 “Subtyp-Bias OK” (System ist plausibel)
- 9 “Eval-Set falsch / System ist besser”
- 7 “Echte Misses”
Pruefe stichprobenartig: sind diese Verdicts wirklich richtig? Wo bin ich
moeglicherweise zu wohlwollend mit dem System gewesen? Lies manual-review.md
und pick 5 Cases aus der Eval-Set falsch-Kategorie — sind die wirklich
falsche Eval-Set-Eintraege oder hat das System wirklich danebengelegen?
Konkret skeptisch sein bei: Cases 31, 32, 35, 37, 40, 45, 46, 47 — habe ich da System-Verteidigung mit fachlicher Plausibilitaet verwechselt?
2. Welche Phase-Optionen sind realistisch ohne Florian?
Im Decision-Doc stehen vier Phase-4-Optionen. Bewerte jede mit:
- Erwarteter Lift in Prozentpunkten R@10_any
- Aufwand in Stunden / Tagen
- Risiko (das es nicht funktioniert)
- Cost (Bedrock + Compute)
| Option | Lift-Hypothese | Aufwand | Risiko |
|---|---|---|---|
| BGE-M3 fine-tuned auf Florians Korpus | +10-30pp | 1-2 Wochen | hoch (Setup + Training-Daten + neue Spalte + Reembed) |
| LLM-Reranker (Haiku) mit angereichertem Doc-Text (wgr+tgk+einheit+kurztext) | +5-15pp | 2-3 Tage | mittel |
| Hybrid-Weight-Tuning (Grid-Search) | +0-5pp | 1 Tag | gering |
| Wgr/Tgk-Filter im Request | nicht messbar gegen Eval | mittel | UX-Aenderung |
3. Gibt es Hebel die wir uebersehen haben?
Wir haben uns sehr auf Score-Fusion + Synonyme konzentriert. Was ist mit:
- Top-K erhoehen (jetzt 10) — wenn Cases bei Rank 11-15 sind, ist das mit 20er-Top-K eingefangen. Aber UX-Frage.
- Query-Augmentation via doc-similarity — fuer jede Query die naechsten 3 Catalog-Eintraege im Embedding-Space finden und deren kurztext als Query-Erweiterung nutzen
- Catalog-Side-Cleanup — sind manche Catalog-Eintraege so generisch, dass sie viele Queries falsch absorbieren? (Vermutung: 90004-Reinigung absorbiert zu viel)
- Boost wgr/tgk-Hits — wenn Query keine eindeutige wgr hat, aber expected schon, koennte ein wgr-Boost helfen wenn die Mehrheit der Top-Hits auf derselben wgr sitzen
- Florians LV-Projekt-Kontext — Eval-Set ist aus Projekt P2021000012 (Dachsanierung). Vielleicht hat das Projekt eine implizite wgr-Range die wir als Filter nutzen koennen?
Brainstorm — sind das gute Ideen? Welche zwei wuerdest du als naechstes probieren?
4. Sollte Pipeline live geschaltet werden?
Aktuelle Pipeline laeuft NUR im :phase3c-Image, NICHT im Production-Service
(der ist noch auf Rev 1 = altes Image). Die Live-Pipeline unter
inference.agenticventures.de ist die ALTE Cohere-v3-langtext-only-Variante
ohne Multi-Field, ohne Synonyme.
Frage: Sollen wir die Phase-3-Pipeline jetzt in Production schalten
(update-service --task-definition inference-service-prod:4), damit Florian
sie nutzen kann und wir Echtzeit-Feedback bekommen — oder erst weitere
technische Phasen abwarten?
Risiko bei Cutover: live wechseln in Produktion. Migration 003 (kurztext- Embedding-Spalten) ist applied, aber suchwort_v4 ist nur 86 % gefuellt — was heisst Multi-Field-Score fuer 14 % der Records hat NULL fuer suchwort (graceful degradation? muss validiert werden).
5. Sind die ECR-Tags + Task-Def-Revisionen aufzuraeumen?
Wir haben ECR mit :phase2, :phase3a, :phase3c und Task-Def Rev 2, 3, 4.
Das ist viel Test-Krimskrams. Welcher Tag sollte canonical werden (:latest?)
und sollten wir die Test-Revisionen aus dem Registry loeschen?
Was du NICHT tun sollst
- Florian-Termin nicht von dir aus organisieren — das macht Marvin selbst
- Pipeline nicht live schalten ohne explizites Marvin-OK
- Keine groesseren Bedrock-Bake-Off-Runs ohne Marvin-OK (Quota kann teuer werden, gestern ~3 EUR aufgebraucht)
Deliverables fuer Marvin nach dieser Session
- Eine ehrliche Entscheidungs-Matrix “Phase 4 Optionen × Effort × Lift” — keine wischwaschi-Empfehlung
- Eine Top-3-Empfehlung “machen wir als naechstes” mit Reihenfolge
- Skepsis-Pass ueber meine Manual-Review-Verdicts mit konkreten Stellen wo ich danebenlag
Wichtige Files + ihre Pfade
~/source/a-icking/ # Code-Repo
├── docs/
│ ├── plans/2026-05-15-004-feat-search-quality-phase2-plan.md
│ └── decisions/2026-05-17-search-pipeline-phase-2.md # ← komplette Bilanz
├── inference-service/
│ ├── app/
│ │ ├── search/discriminators.py # Phase 3a Diskriminator
│ │ ├── search/score_fusion.py # fuse_hybrid + multi-field
│ │ ├── search/hybrid.py # Hybrid-Search
│ │ ├── query_preprocessor.py # Phase 3c GAEB-Synonyme
│ │ ├── embedding/_bedrock_base.py # embed_query mit Synonym-Expansion
│ │ └── evaluation.py # Fair-eval Metriken
│ ├── scripts/
│ │ ├── bake_off.py # Bake-Off-CLI
│ │ ├── reembed_catalog.py # Multi-Field Reembed
│ │ └── inspect_misses.py # Per-Case Markdown
│ ├── db/migrations/003_multi_field_embedding_columns.sql
│ └── tests/unit/ # 220 unit tests, alle gruen
~/source/agentic-ventures/ # Vault
├── intern/projekte/icking-ai-rebuild/_index.md # Projekt-Status
└── intern/runs/2026-05-17-icking-phase-2/
├── report.md # Run-Log
├── manual-review.md # 51 Cases mit Verdicts
└── next-session-prompt.md # diese Datei
AWS Production-Stand
- Account: av-production (425924867359)
- Region: eu-central-1
- ECS Cluster: inference-service-prod, Service ist noch auf Rev 1 (alt!)
- Latest Image:
425924867359.dkr.ecr.eu-central-1.amazonaws.com/inference-service-prod:phase3c(sha 5b870a2e) - Task-Def Rev 4 referenziert das
:phase3cImage — wuerde fuer Cutover genutzt - RDS:
inference-service-prod.cfwqykik8qyi.eu-central-1.rds.amazonaws.com - Eval-Set in S3:
s3://av-production-terraform-state/inference-service/bootstrap/eval_set.jsonl - Live-Service:
https://inference.agenticventures.de(Cloudflare-Tunnel) — laeuft auf Rev 1 - Cost-Stand: ca. 7-8 EUR Bedrock fuer alle Bake-Offs (heute + gestern)
Methodische Selbstkritik (Marvin’s Bitte)
Folgende Sachen waren in dieser Session moeglicherweise nicht optimal:
- Synonym-Liste aus dem Bauch heraus — keine systematische Quelle, nur eyeballed. Vielleicht hat Florian eine echte GAEB-Synonym-Tabelle?
- Diskriminator-Material-Familien — hand-curated, vermutlich Edge-Cases-anfaellig
- Manual-Review-Verdicts — Claude hat als Inhalts-Bewerter gespielt ohne Bauwesen-Fachkenntnis. Stichprobe gegen Florian-Wissen ist Pflicht.
- Phase-3-Bake-Offs sind nicht unabhaengig — gleiche 51 Cases, gleiche Embedding-Pipeline, gleiche Datenbasis. Overfitting-Risiko gegen das eine Eval-Set.
- Latenz wurde nicht serioes gemessen — alle Zahlen durch Quota-Sleeps verzerrt. Echte Production-p50 ist Schätzung.
Sei misstrauisch bei 1, 3, 4. Pruefe ob das gerechtfertigt ist.
Wenn du dich gut vorbereitet hast, sag Marvin:
“Ich habe Phase 2+3 reviewed. Hier meine 3 Top-Empfehlungen für 80-90 %, mit konkreten Bedenken zu unseren bisherigen Verdicts in Cases X, Y, Z.”
Keine wischiwaschi-Antworten. Erwarteter Output: ~1000 Wörter.