Bake-off M3: qwen3.8 vs qwen3.6 gemessen; Topologie korrigiert (Remote-GPU-Maschine)

Zwischenstand Bake-off (Antwortmodus, 35 Goldset-Fragen):
qwen3.8:27b 100% Zitier-Praezision / 94,3% Verweigerung korrekt / 32s;
qwen3.6:27B 94,3% / 85,7% / 43s (10 Regenerierungen) - klar schwächer.

Topologie korrigiert: 100.103.83.12:11435 ist die Remote-GPU-Maschine
(Tailscale, R9700), NICHT dieselbe wie die Dev-Maschine (deren localhost:
11434 ist ein eigener, fast leerer Ollama; URL-Nicht-auf-11434-Korrigieren
in Skill/README/Config präzisiert). bge-m3 auf der GPU-Maschine gepullt.

gemma4:26b-Lauf brach ab: auf der GPU-Maschine sterben seit dem Crash
alle llama-server-Loads (API 500 'exit status 1'), auch bge-m3. Neustart
dort noetig: sudo systemctl restart ollama. Danach mistral-small3.1:24b
und gemma4:12B ausstehen.
This commit is contained in:
2026-09-14 22:42:54 +02:00
parent b6a6f5b788
commit 0281d8fa24
4 changed files with 37 additions and 14 deletions
+25 -5
View File
@@ -30,6 +30,24 @@ zu planen.
- Der ATZ-Konfliktfall (28,5 vs. 27,5 %) wird korrekt mit ⚠ und beiden
IDs beantwortet; harte Verweigerung (UStVA, Retrieval nicht leer)
funktioniert.
- **Topologie geklärt**: `100.103.83.12` ist die **Remote-GPU-Maschine**
(Entwicklungsumgebung, R9700, Tailscale); die Dev-Maschine selbst hat
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).
## Open issues / blockers
@@ -44,11 +62,13 @@ 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**: Kandidaten sind bereits installiert — `qwen3.8:27B`,
`qwen3.6:27B`, `gemma4:26b`, `mistral-small3.1:24b`, `gemma4:12B`
(Latenz-Untergrenze). Achtung: Plan nennt mistral-small3.**2**:24b —
installiert ist 3.1; 3.2 ggf. noch pullen oder 3.1 als Proxy.
Pro Kandidat: `PV_ANSWER_MODEL=<tag> python -m agent.cli eval --answers`.
- **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.
- **M4 Odoo**: native LLM-Module des konkreten Odoo-19-Stands verifizieren
(keine API-Annahmen); Option A (dünnes Custom-Modul + Service-API) ist
Default.
+7 -5
View File
@@ -39,11 +39,13 @@ touches Odoo code, also apply `.agents/odoo19-development/SKILL.md`.
## System context (fixed facts)
- **Ollama server:** `http://100.103.83.12:11435`the target instance
(custom port, holds the model zoo: qwen3.8:27b, bge-m3, bake-off
candidates). The same host also runs a near-empty instance on port
11434 — do **not** "correct" the port to 11434. Verify with
`curl http://100.103.83.12:11435/api/tags`.
- **Ollama server:** `http://100.103.83.12:11435`a **remote GPU
machine** in the Tailscale network (development environment, Radeon
AI Pro R9700) holding the model zoo: qwen3.8:27b, bge-m3, bake-off
candidates. Do **not** "correct" the URL to localhost or port 11434 —
a local Ollama on the dev machine's 11434 is a different, near-empty
instance. Verify with `curl http://100.103.83.12:11435/api/tags`.
Shell access for restarts/logs exists only on that machine.
- **GPU:** AMD Radeon AI Pro R9700, 32 GB — keep the total resident
budget (answer model + embeddings + KV cache) under ~28 GB.
- **Models (provisional until bake-off, see protocol below):**
+1 -1
View File
@@ -49,7 +49,7 @@ python -m agent.cli serve # http://127.0.0.1:8080 (/ask, /health, /r
| Variable | Default | Bedeutung |
|---|---|---|
| `OLLAMA_URL` | `http://100.103.83.12:11435` | Ollama-Server (Ziel-Instanz; der Host betreibt zusätzlich eine fast leere Instanz auf 11434 — nicht "korrigieren") |
| `OLLAMA_URL` | `http://100.103.83.12:11435` | Ollama-Ziel-Instanz — Remote-GPU-Maschine im Tailscale-Netz (nicht localhost:11434 — das ist ein anderer, lokaler Ollama) |
| `PV_ANSWER_MODEL` | `qwen3.8:27b` | Antwortmodell (provisorisch bis Bake-off M3) |
| `PV_EMBED_MODEL` | `bge-m3` | Embedding-Modell |
| `PV_DB_PATH` | `data/index.db` | SQLite-Index |
+4 -3
View File
@@ -37,9 +37,10 @@ class Config:
kb_dir: str = "wissensbasis"
db_path: str = "data/index.db"
# Ollama — Ziel-Instanz ist Port 11435 (Custom-Port, mit Modell-Zoo).
# Auf demselben Host läuft auch eine Instanz auf 11434 (fast leer) —
# NICHT auf 11434 "korrigieren", s. Skill.
# Ollama — Ziel-Instanz ist die Remote-GPU-Maschine im Tailscale-Netz
# (Entwicklungsumgebung, Radeon AI Pro R9700). Nicht auf localhost bzw.
# Port 11434 "korrigieren" — 11434 ist ggf. ein lokaler Ollama auf der
# Dev-Maschine, nicht die Ziel-Instanz.
ollama_url: str = "http://100.103.83.12:11435"
embed_model: str = "bge-m3"
answer_model: str = "qwen3.8:27b" # provisorisch bis Bake-off (M3)