M3 Bake-off abgeschlossen: qwen3.8:27b als Antwortmodell fixiert (D7)

Alle 5 Kandidaten auf dem Goldset (35 Fragen, Antwortmodus) gemessen.
Protokoll Zitier-Praezision > Verweigerungskorrektheit > Latenz:

  qwen3.8:27b   100% / 94,3% / 80,6%  32s  -> Sieger, fixiert
  gemma4:26b    100% / 91,4% / 67,7%  7,9s -> Latenz-Kandidat (4x schneller)
  gemma4:12B    94,3% / 91,4% / 77,4%  21s
  qwen3.6:27B   94,3% / 85,7% / 80,6%  43s
  mistral-small3.1:24b 100% / 71,4% / 58,1%  20s

mistral-Deutsch-Hypothese praktisch widerlegt (71,4% Verweigerungs-
korrektheit). q-008/q-031 verweigern beide Finalisten -> Prompt-/
Retrieval-Tuning, nicht modellspezifisch. Tabelle in planung.md 13,
README und MEMORY aktualisiert.

.agents/MEMORY.md

@@ -5,10 +5,10 @@ Rollender Übergabe-Log für agent-Threads. Workflow: `.agents/SKILL.md`
 
 ## Current focus
 
-M1 und M2 sind **fertig und gegen den echten Ollama validiert**.
-Offen: Modell-Bake-off (M3) mit den bereits installierten Kandidaten
-und Prompt-Tuning der Fehlverweigerungen. Odoo-Integration (M4) separat
-zu planen.
+M1, M2 und **M3 (Bake-off) sind abgeschlossen** — `qwen3.8:27b` ist als
+Antwortmodell fixiert (D7). Offen: Fehlverweigerungs-Tuning (q-008,
+q-031 — beide Finalisten betreffend) und Odoo-Integration (M4, separat
+zu planen).
 
 ## Completed (2026-09-14)
 
@@ -35,19 +35,19 @@ zu planen.
   einen eigenen, fast leeren Ollama auf localhost:11434 (dorthin ging der
   erste bge-m3-Pull — auf die GPU-Maschine neu gepullt). Ziel-Instanz ist
   ausschließlich `http://100.103.83.12:11435`.
-- **Bake-off M3, Zwischenstand** (Antwortmodus, 35 Fragen):
-  - `qwen3.8:27b` (Baseline): Zitier-Präzision **100 %**, Verweigerung
-    korrekt 94,3 %, erwartete Quelle 80,6 %, mean 32 s/p95 53 s,
-    4 Regenerierungen (`data/eval-qwen38.json`).
-  - `qwen3.6:27B`: Zitier-Präzision 94,3 % (2 dauerhafte Verstöße),
-    Verweigerung 85,7 %, mean 43 s/p95 89 s, 10 Regenerierungen —
-    klar schwächer (`data/eval-qwen36.json`).
-  - `gemma4:26b`: Lauf abgebrochen (GPU-Maschine crashte mitten im Lauf).
-  - `mistral-small3.1:24b`, `gemma4:12B`: ausstehend (Server-Neustart).
-  - Kandidaten sind installiert; Pro-Kandidat-Befehl:
-    `PV_ANSWER_MODEL=<tag> python3 -u -m agent.cli eval --answers --json-out data/eval-<name>.json`
-    (vor jedem Lauf vorheriges Modell entladen: `/api/generate` mit
-    `keep_alive: 0`; `python3 -u` gegen Buffering bei Absturz).
+- **Bake-off M3 — abgeschlossen (D7)**: alle 5 Kandidaten gemessen
+  (Tabelle in `planung.md` Abschnitt 13). **`qwen3.8:27b` gewinnt**
+  (100 % Zitier-Präzision, 94,3 % Verweigerung korrekt, 80,6 % erwartete
+  Quelle, 32 s mean). `gemma4:26b` = dokumentierter Latenz-Kandidat
+  (7,9 s mean, 100 % Zitier-Präzision, aber 67,7 % Quellentreue, 3
+  Fehlverweigerungen). mistral-small3.1: 71,4 % Verweigerungskorrektheit
+  — Deutsch-Hypothese praktisch widerlegt. qwen3.6:27B: 2 dauerhafte
+  Zitierverletzungen, 10 Regenerierungen. gemma4:12B: 2 Verletzungen.
+  Reports: `data/eval-*.json`. q-008/q-031 verweigern beide Finalisten —
+  Prompt-/Retrieval-Tuning (nicht modellspezifisch).
+- **Remote-GPU-Maschine**: nach `systemctl restart ollama` (User-Aktion)
+  liefen alle Läufe stabil; zwischen Kandidaten wurde per `keep_alive: 0`
+  entladen (Crash-Ursache war der Modell-Swap-Stress beim gemma4-Lauf).
 
 ## Open issues / blockers
 
@@ -62,13 +62,9 @@ zu planen.
   Hebel: weniger Kontextblöcke (aktuell 8+6), schnellere Kandidaten.
 - **Cloud-Modelle** (`*:cloud` auf der Ollama-Instanz) sind für Antworten
   tabu (Anforderung: lokal). Nicht versehentlich konfigurieren.
-- **Bake-off M3 — Remote-GPU-Maschine neu starten**: seit ~22:45 sterben
-  dort ALLE llama-server-Loads (auch bge-m3), der Ollama-Hauptprozess
-  antwortet noch (API-Requests 500 „llama-server process has terminated:
-  exit status 1"). Ursache vermutlich GPU-/Runner-Crash beim gemma4:26b-
-  Lauf. **Auf der GPU-Maschine ausführen:** `sudo systemctl restart ollama`
-  (ggf. vorher freien RAM prüfen; Ollama läuft dort auf Port 11435).
-  Danach laufen die restlichen Kandidaten ohne weiteres Zutun.
+- **Bake-off M3 — erledigt** (siehe Completed; Entscheidung D7 in
+  `planung.md`). Nach Tuning von Prompt/Retrieval: erneuter kurzer
+  Bestätigungslauf nur mit dem Sieger.
 - **M4 Odoo**: native LLM-Module des konkreten Odoo-19-Stands verifizieren
   (keine API-Annahmen); Option A (dünnes Custom-Modul + Service-API) ist
   Default.
@@ -87,6 +83,10 @@ zu planen.
 - **D5:** Vektoren-Tabelle ist Cache (Content-Hash × Modell), Rebuild
   löscht sie nicht; `--no-embed` setzt `embed_off` im Config-Copy.
 - **D6:** Leeres Retrieval → deterministische Verweigerung ohne LLM-Call.
+- **D7 (Bake-off 2026-09-14):** `qwen3.8:27b` ist das fixierte Antwortmodell
+  (100 % Zitier-Präzision, 94,3 % Verweigerung korrekt). `gemma4:26b` als
+  dokumentierter Latenz-Kandidat; ein Modellwechsel läuft nur erneut über
+  das dokumentierte Protokoll (Skill).
 - **Bake-off-Protokoll** (Skill): Modellwechsel nur über dokumentierten
   Goldset-Vergleich; Kriterium: Zitier-Präzision > Verweigerungs-
   korrektheit > Latenz.