nanobot-runtime/plans/deepseek-v4.1-flash-eval.md

Evaluace deepseek-v4.1-flash jako agentního modelu pro nanobot

Context

Uživatel už běží na presetu deepseek (= deepseek-v4.1-flash:cloud) a chce vědět, jak dobře ten model reálně funguje — bez velké research smyčky, ideálně „pustit deep-research a podívat se, jak to dopadne".

Tenhle plán dává odpovědi měřitelný rámec, aby výsledek nebyl dojem. Cíl není vybrat model (to je hotové, knowledge/models.md), ale rozhodnout, jestli má deepseek zůstat v rotaci jako daily driver / dream model, nebo se vrátit na glm.

Pozn.: „jak dobře funguje" nejde změřit v turnu, ve kterém sám běžím — vlastní turn spotřebovává kvótu a hodnotí sám sebe. Proto všechny mechanické testy jdou přes skripty (direct API), reálná práce přes detach --model deepseek.

Co už je ověřené (nemusí se testovat)

Fakt	Zdroj
deepseek-v4.1-flash:cloud = Medium Usage tier, 1M ctx, vision+tools+thinking	ollama.com/library/deepseek-v4.1-flash/tags (fetch 2026-09-20)
Reálný context_length 1048576, capabilities completion/thinking/tools/vision	/api/show na nvidia.hell i ollama.com
Vendor: Terminal-Bench 2.1 90,6 · DeepSWE 74,2 · AutomationBench 54,8 · HLE 36,8	ollama library (DeepSeek V4.1 tech report)
Preset v configu: ctx 976 000, maxTokens 16384, temp 0.1, reasoningEffort high	my check model_presets.deepseek

Fáze 0 — baseline (nutná, jinak čísla nic neznamenají)

Bez referenčního bodu je „90,6 na Terminal-Benchu" jen cizí tabulka. Každý test se pustí dvakrát: na deepseek a na glm (glm-5.3, současný default v knowledge/models.md). Rozdíl je výsledek; absolutní čísla jsou kontext.

Fáze 1 — mechanika (deterministické, scripted)

Skripty se pouští přes uv, ne přes agenta — žádná kvóta z mého vlastního turnu.

1. Tool calling, 10 scénářů. Reuse projects/ai/artifacts/ollama-toolcall-test.py. Dnes má whitelist MODELS (lokální modely) a BASE = http://nvidia.hell:11434 — doplnit deepseek-v4.1-flash:cloud a glm-5.3:cloud do seznamu (malý edit artifactu; samostatný krok k odsouhlasení). Sledované položky: celkové skóre, S6 no-tool restraint (u deepseek-v3 selhal over-eager calling → u V4.1 klíčová otázka), S7 multi-call, S9 diakritika v argumentu, S10 výběr netriviálního nástroje z 5.
2. Latence a verbosita. scripts/benchmark_ollama.py --models deepseek-v4.1-flash,glm-5.3 --runs 3. Vstup: TTFT-thinking, TTFT-response, tok/s zvlášť pro thinking a response fázi. Tohle je hlavní ekonomická zbraň — u reasoning modelů rozhoduje poměr thinking:response tokenů, ne celková rychlost.
3. Jazykový drift (čeština). 10 českých promptů, automatická detekce CJK znaků v odpovědi (regex). Kimi měl známý random-Chinese bug, deepseek je čínský model taky — u nás je to blocker, ne kosmetika. Projít i diakritiku ve výstupu.
4. Chování v agent loopu. 1 scripted multi-step úloha (~10 tool callů, čtení souboru → edit → re-read → kontrola) s ověřením výsledku na disku. Metriky: počet iterací, wall-clock, počet chyb tool callů, recovery po chybě.

Fáze 2 — reálná práce (to, co navrhoval uživatel)

Každý bod jako skills/detach/scripts/create-task.py --model deepseek, tj. izolovaná session, ať to nemíchá můj vlastní turn. Hodnotí se artefakt, ne dojem: citace, počet iterací, wall-clock, delta kvóty.

1. deep-research na jednom ne-triviálním tématu (např. aktuální stav Ollama Cloud usage tiers) — výstup do results/, hodnotí uživatel.
2. remind: add → list → edit → remove (SQLite, deterministický formát, český text) — tady je vidět, jestli model drží naše konvence.
3. note nebo wiki: uložení + zpětné vyhledání (retrieval, ne jen zápis).

Fáze 3 — ekonomika

1. Delta kvóty z db/ollama_usage.sqlite (per-model request counts před/po Fázi 2). Tabulka samples má přesné request counts, procenta jsou hrubá.
2. Verdikt k tier: Medium Usage vs High u glm — kolik requestů a kolik % týdenního okna sežere stejná práce.

Verification (kritéria úspěchu)

Hodnotí se odděleně, ne jedním číslem:

Signál	Pass	Fail
Tool calling skóre	≥ 9/10 a S6 PASS	S6 fail (over-eager) nebo < 8/10
Latence	TTFT-response v řádu stovek ms, wall-clock srovnatelný s glm	> 2× pomalejší než glm
Verbosita	thinking:response token ratio ≤ 2:1	reasoning spálí většinu budgetu
Čeština	0 CJK znaků v 10/10 promptů, diakritika OK	jakýkoli CJK výskyt
Agent loop	úloha dokončena, výsledek na disku ověřen, ≤ 2 chybné tool cally	nedokončeno / výsledek nepřesný
Kvalita (deep-research)	použitelný report s citacemi, uživatel ho uzná	halucinace, chybějící citace

Výstup: results/2026-09-20_deepseek-v4.1-flash-agent-eval.md s tabulkami deepseek vs glm a jednoznačným verdiktem (nechat / nechat jen na Dream / vyhodit).

Steps

1. Odsouhlasit rozsah (viz rozhodovací bod níže).
2. Fáze 0: připravit baseline běh glm.
3. Fáze 1: doplnit dva modely do ollama-toolcall-test.py, spustit bod 1–4 ×2.
4. Fáze 2: 3 detached tasky na deepseek (+ stejné na glm, pokud bude čas).
5. Fáze 3: sebrat usage deltu z db/ollama_usage.sqlite.
6. Napsat report do results/, případně promítnout závěr do knowledge/models.md (a doplnit tam chybějící řádek presetu deepseek).

Rozhodovací bod (potřebuju od uživatele)

• A — light varianta (to, co navrhoval uživatel): jen Fáze 2, bod 1 (jeden deep-research na deepseek) + Fáze 3 delta kvóty. ~15 min, jeden datový bod, kvalitu hodnotíš okem.
• B — plná varianta: Fáze 0–3 včetně A/B proti glm. ~1–1,5 h, ale dá čísla, o která se dá opřít, a odhalí S6/latentní problémy, které oko nevidí.

Doporučuju B, ale s tím, že Fáze 1 (mechanika) jde první — je levná a když tam deepseek propadne na S6 nebo na češtině, Fázi 2 a 3 už nemá smysl dělat.

Co záměrně nedělám

• Neměním agents.defaults.modelPreset ani nic v configu (jen čtení).
• Nespouštím Dream na deepseek — Dream jede na aktivním presetu a jeho případná změna je samostatné rozhodnutí, ne součást evaluace.
• Neporučuju deepseek-v4-pro (jiný model, 15 tok/s + 57 s TTFT cold start).