From 9cefe4527303958dff70d0dddecf1068a851a137 Mon Sep 17 00:00:00 2001 From: Florian Egger Date: Wed, 16 Sep 2026 19:29:55 +0200 Subject: [PATCH] docs: record runtime evaluation decision --- .agents/MEMORY.md | 67 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/.agents/MEMORY.md b/.agents/MEMORY.md index 3798de3..4887301 100644 --- a/.agents/MEMORY.md +++ b/.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