# 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).