docs: record runtime evaluation decision

.agents/MEMORY.md

@@ -175,6 +175,73 @@ Privacy-Grenze für Lohndaten).
   steuerliche Höhe und findet `lb-rei-09`. Goldset 54 Fragen; Offline-Retrieval
   nun Hit-Rate 0,9792, Recall@8 **0,9479**, MRR 0,6653. Tests **75 grün**.
 
+- **llama.cpp-LLM-Eval (2026-09-16):** Lokaler/privater OpenAI-kompatibler
+  Server aus `.env` getestet (Zugangsdaten/URLs nicht dokumentiert oder
+  versioniert); nur das LLM wurde gewechselt, Retrieval und bge-m3-Index
+  blieben unverändert. llama.cpp benötigt
+  `chat_template_kwargs.enable_thinking=false`; Chatmodell meldet sich als
+  `qwen3.8`. 54-Fragen-Report: `data/eval-llamacpp-qwen38.json`
+  (lokal/gitignored). Zitier-Präzision **100 %**, Verweigerung korrekt 96,3 %,
+  erwartete Quelle 91,67 %, mean 54,9 s / p95 104,8 s, 2 Regenerierungen.
+  q-124–126 bestanden alle ohne Regenerierung. Fehlverweigerungen: q-029
+  (bekannte Survey-Flakiness, 357 s) und q-102. q-102 ist kein LLM-Defizit:
+  Mit Planner lieferte der KV-Scope viele ähnlich benannte KVs und nur einen
+  irrelevanten Abschnitt von kv-kvt-197; ohne Planner beantwortete dasselbe
+  llama.cpp-Modell die Frage in 14,8 s korrekt aus kv-kvt-056. Schluss:
+  llama.cpp ist grounding-stabil, aber langsamer als die Ollama-Basislinie;
+  q-102 erfordert später Planner-/Retrieval-Tuning, nicht Modell-Tuning.
+- **llama.cpp-Rerun nach Server-Tuning (2026-09-16):** Report
+  `data/eval-llamacpp-qwen38-rerun.json` (lokal/gitignored), gleicher Aufbau
+  wie zuvor: nur LLM über llama.cpp, Retrieval/bge-m3 unverändert. Ergebnis:
+  Zitier-Präzision **100 %**, Verweigerung korrekt **98,15 %**, erwartete
+  Quelle **95,83 %**, mean 53,5 s / p95 105,4 s, 6 Regenerierungen. Gegenüber
+  dem ersten Lauf: q-029 geheilt, erwartete Quelle +4,16 Prozentpunkte,
+  mean ca. 1,3 s schneller; q-102 bleibt als einzige Fehlverweigerung
+  reproduzierbar (Planner-/Kontextproblem). q-124–126 bestehen weiterhin;
+  q-125/q-126 benötigten diesmal je eine Regenerierung. Das Server-Tuning ist
+  damit qualitativ besser, erhöht aber die Regenerierungen (2 → 6); Latenz
+  bleibt deutlich über der Ollama-Basislinie.
+- **llama.cpp Full-Stack (Chat + Embeddings, 2026-09-16):** llama.cpp-
+  Embeddings sind trotz gleicher Dimension 1024 inkompatibel zu Ollama
+  `bge-m3` (Same-Text-Cosinus nur ca. -0,004 bis 0,017); deshalb separater,
+  lokaler Index `data/index-llamacpp.db`. Vollständig 16.480 Chunks; der
+  Embedding-Server lehnt einzelne Texte > ca. 9.000 Zeichen ab, daher wurden
+  nur für diesen Test längere Embedding-Inputs deterministisch auf 9.000
+  Zeichen gekürzt (KB und Produktionsindex unverändert). Indexbau ca. 17,4 min.
+  Retrieval ohne Neukalibrierung: Hit-Rate 0,9583, Recall@8 **0,9323**,
+  MRR 0,5977 (Gate >0,9 erfüllt). Vollreport
+  `data/eval-llamacpp-fullstack.json` (lokal/gitignored): Zitier-Präzision
+  **100 %**, Verweigerung korrekt 94,44 %, erwartete Quelle 87,5 %, mean
+  **44,6 s**, p95 130,8 s, 3 Regenerierungen. Full-Stack ist schneller als
+  llama.cpp-LLM + bge-m3 (53,5 s), aber fachlich schwächer: Fehlverweigerungen
+  q-029, q-102, q-111. q-102: korrektes Dokument kv-kvt-056, aber falscher
+  repräsentativer Abschnitt; q-111: Embedding-Retrieval verfehlt kv-kvt-001
+  komplett und liefert fremde Lehrlingstabellen. Decision-Support q-124–126
+  besteht weiter. Fazit: Full-Stack ist testfähig und erfüllt das Retrieval-
+  Recall-Gate, ersetzt bge-m3 aber noch nicht; zuerst eigene RRF-/Dense-
+  Kalibrierung und KV-Metadaten-/Representative-Section-Tuning nötig.
+- **llama.cpp Full-Stack Rerun (2026-09-16):** identischer separater Index und
+  unveränderte Parameter; Report `data/eval-llamacpp-fullstack-rerun.json`.
+  Zitier-Präzision **100 %**, Verweigerung korrekt **98,15 %**, erwartete
+  Quelle **91,67 %**, mean 49,5 s / p95 101,2 s, nur 1 Regenerierung. Gegenüber
+  erstem Full-Stack-Lauf: q-029 und q-111 geheilt, Fehlverweigerungen 3 → 1,
+  erwartete Quelle +4,17 Prozentpunkte, Regenerierungen 3 → 1; Latenz dagegen
+  44,6 → 49,5 s. Einziger reproduzierbarer Fehler bleibt q-102 (korrektes
+  Dokument, falscher Representative-Section-Kontext). q-124–126 alle ohne
+  Regenerierung bestanden. Full-Stack erreicht damit dieselbe Verweigerungs-
+  korrektheit wie der aktualisierte llama.cpp-LLM+bge-m3-Lauf, bleibt aber bei
+  erwarteter Quelle darunter (91,67 % vs. 95,83 %).
+
+- **D17 (Runtime-Entscheidung, 2026-09-16):** Nach den llama.cpp-LLM- und
+  Full-Stack-Vergleichen bleibt der Agent bei **Ollama** mit
+  `qwen3.8:27b` + `bge-m3`. Gründe: beste bzw. stabilere Gesamtbalance aus
+  erwarteter Quellentreue, Verweigerungskorrektheit und Latenz; llama.cpp-
+  Full-Stack zeigte embedding-spezifische KV-/Representative-Section-Fehler
+  und höhere Flakiness. Der letzte angeforderte Full-Stack-Rerun wurde nach
+  drei Fragen vom User abgebrochen und nicht gewertet. Lokale llama.cpp-
+  Indizes/Reports und `.env` bleiben unversioniert; keine Integration in die
+  Produktionskonfiguration.
+
 ## Open issues / blockers
 
 - **Push**: Remote localhost:3003 aus der Sandbox nicht erreichbar — User