nanobot: 2026-09-20 14:15:06

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

@@ -0,0 +1,116 @@
+# 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).

results/2026-09-20_hodnoceni-beziciho-modelu-nanobot.md

@@ -0,0 +1,251 @@
+# Jak hodnotit běžící LLM model v nanobotu
+
+Deep research, 2026-09-20. Otázka: jak navrhnout hodnocení modelu, který **už běží** jako
+agent v nanobotu — ne offline benchmark kandidáta před nasazením.
+
+## Shrnutí
+
+Běžící model se hodnotí z **protokolů, které po sobě zanechal**, ne z re-runu — a musí se
+měřit dvěma známkami, ne jednou: úspěch výsledku (outcome) a kvalita trajektorie, protože
+ty dvě se rozcházejí [1]. Hlavní metodologický problém v nanobotu ale není statistika ani
+judge — je to, že **nanobot sám je harness**, a ten se mění každý den (skilly, MEMORY.md,
+SOUL.md, tool schémata). Změna skóre mezi dvěma okny je proto ve skutečnosti nejčastěji
+změna scaffoldu, ne modelu — harness umí posunout výsledek o 7–34 procentních bodů při
+identických vahách [2][3]. Praktický závěr: neporovnávat skóre v čase, ale **párovat na
+stejných úlohách**, drift hlídat zvlášť jako signál, a hodnotit **pass^k**, ne pass@1 —
+model se 90 % pass@1 má při osmi opakováních ~43 % [4].
+
+## Zjištění
+
+### 1. Co „běžící model" mění
+
+Tři strukturální rozdíly proti offline evalu:
+
+- **Nemůžeš opakovat vstup.** Produkční snímek (co uživatel poslal) se nedá znovu
+  vyvolat. Zbývá replay ze záznamu — a ten je věrný jen do chvíle, kdy se změní nástroje
+  nebo stav okolí [5].
+- **Váhy nejsou zmrazené.** Vendor mění checkpoint pod stejným ID; pinning ID zamrazí
+  jen část chování, serving stack, batching a decoding se mění bez čísla verze [6][7].
+  Detekce: canary prompt s hashí, output-shape metriky [8][9].
+- **Hodnotíš i sebe.** Model, který dělá evaluaci, je tentýž model, který je hodnocený —
+  a LLM judge favorizuje vlastní styl výstupu (self-preference bias, mechanismus =
+  perplexity familiarita, ne vědomé rozpoznání) [10]. To se týká přímo mě: každý eval,
+  který spustím v turnu na `deepseek`, je self-eval.
+
+### 2. Jaké důkazní zdroje už v nanobotu jsou
+
+Tohle je konkrétní inventura téhle instance (ne obecná rada):
+
+| Zdroj | Co v něm je | Použitelné pro |
+|---|---|---|
+| session JSONL (`<config-dir>/sessions/<workspace-id>/`) | plná historie tahů včetně `tool_calls`, `reasoning_content` [11] | trajectory eval, failure clustering |
+| `memory/history.jsonl` | denormalizované distilly tahů | levná klasifikace témat |
+| `db/ollama_usage.sqlite` (`samples`) | **přesné per-model request counts** + % kvóty | cost/usage scorecard |
+| `.nanobot/tool-results/<session>/call_*.txt` | raw tool výstupy (cap 16 000 znaků) | forenzika selhání tool callu |
+| `tasks/done/`, `tasks/archive/` | frontmatter s `model:` a `duration_seconds` | **attribuce výsledku na model** |
+| `results/` | reporty včetně deep-research výstupů | outcome grading |
+| `reflect/findings.jsonl` | už existující store klasifikovaných vzorců chyb | failure clustering, hotový |
+| `log/reflect_cron.log` | běhy nočního scriptu | provozní telemetrie |
+| webui `token-usage.json` | tokeny + requesty po source (user/api/cron/dream/system) | rozpad spotřeby kvóty |
+
+**Co v nanobotu chybí:** žádná OpenTelemetry/GenAI instrumentace — grep na `gen_ai`,
+`otlp`, `opentelemetry` v `nanobot/` nic nenajde. Standard pro agentní traces přitom
+existuje: spany `invoke_agent` → `chat` → `execute_tool`, atributy `gen_ai.request.model`,
+`gen_ai.usage.input_tokens`/`output_tokens`, metrika `gen_ai.client.operation.duration`
+[12][13]. Je to stále **pre-stable, bez 1.0** [12] — ale tvar je dobrý a je to jediná
+cesta, jak dostat trajectory eval bez ad-hoc parsování JSONL. Nanobot má naštěstí
+`AgentHook` s `after_iteration` a `usage` [14] — což je přesně to místo, kam OTel span
+patří, aniž by se musel sáhnout do core loopu.
+
+### 3. Co měřit: dvě známky, ne jedna
+
+Outcome-only hodnocení **řadí modely ve špatném pořadí** [1]. Konkrétně:
+
+- Správná odpověď po rozbitém plánu, který trefil výsledek náhodou (lucky pass).
+- Špatná odpověď ze správného plánu, kterému poslední tool vrátil 503 (unlucky fail).
+- Policy/konvenční porušení, které výsledek nezmění — τ-bench zavedl policy adherence
+  jako first-class metriku právě proto: agent, který vrátí peníze bez ověření identity,
+  má outcome pass a policy fail [15].
+
+Trajektorie se skóruje po vrstvách: kvalita plánu, volba nástroje (včetně **správného
+nerozhodnutí volat**), správnost argumentů, recovery po chybě, finální odpověď [1].
+U nás je „správné nerozhodnutí volat" přesně to, co testuje scénář S6 v
+`projects/ai/artifacts/ollama-toolcall-test.py` — a co vyřadilo `deepseek-v3` [16].
+
+**Klíčová metrika je pass^k, ne pass@1.** τ-bench ji zavedl jako reliability measure:
+podíl úloh, kde uspěje **všech** k opakování. Neklesá ke středu, ale dolů, protože
+přesně odhaluje nekonzistenci [15][4]. Čísla: GPT-4o v retailu pod 50 % na pass^1, ale
+pod 25 % na pass^8 [15]; model s 90% pass@1 padá na ~43 % při pass^8 a ~19 % při pass^16
+(při nezávislých pokusech) [4]. Model, který získá pass@1 a ztratí pass^4, je pro provoz
+regrese, i když se leaderboard pohnul nahoru [4].
+
+### 4. Statistika: velikost vzorku a co je ještě šum
+
+Tohle je nejvíc podceňovaná část. Konkrétní čísla z runnable receptu [17]:
+
+- **Wilson interval**, ne Wald. Wald na 7/10 hlásí [0,42; 0,98], Wilson [0,40; 0,89] —
+  Wald slibuje jistotu, kterou data neunesou [17][18].
+- **Clusterované SE.** Když se skóre měří na víc otázkách z jednoho tématu/ session,
+  naive SE podstřeluje; v příkladu vyšlo clusterované 1,45× naive. Čím větší cluster,
+  tím větší nafouknutí — v některých případech přes 3× [17]. U nás jsou clustery
+  přirozeně **session a reminder/note kategorie**.
+- **Párový test (McNemar).** Vzorek 200 párových úloh detekoval +9,5 pb rozdíl na
+  p=0,032; nezávislý design by na totéž potřeboval **388 úloh na rameno** [17].
+  Párování je tedy 2× úspora vzorku — a to je přesně argument pro replay stejných úloh
+  na obou modelech místo porovnávání dvou náhodných řezů provozem.
+- **„27 z 30" je statisticky téměř ticho** [19]. Eval sety o 50–200 příkladech, které
+  hlásí signifikanci, ji většinou nemají [20].
+
+Praktický důsledek pro nás: náš reálný objem je **desítky** relevantních tahů za den, ne
+tisíce. To stačí na detekci hrubých rozdílů (S6 fail, CJK drift, 2× latence), ale **ne**
+na rozlišení 2–3 pb rozdílu ve kvalitě. Cokoli jemnějšího je u nás měření šumu.
+
+### 5. Jak to nasadit bez re-runu
+
+Tři režimy a co který umí [21]:
+
+| Režim | Co dostaneš | Co nedostaneš |
+|---|---|---|
+| **Replay ze záznamu** | chování na reálné distribuci vstupů, nulové riziko | žádný signál o uživatelském výsledku |
+| **Shadow** | totéž, ale živě, paralelně s produkcí | pořád žádný user-outcome signál — nikdo jeho odpověď nevidí |
+| **Canary / A/B** | skutečný outcome uživatele | riziko na řezu provozu |
+
+Pro nanobot je **canary triviálně dostupný a to je jeho největší výhoda**: `detach
+--model <preset>` pustí úlohu izolovaně na jiném presetu, cron joby mají vlastní preset,
+`/model` přepíná za běhu. Assignace varianty se ale musí dělat **hashem stabilního ID
+(session/chat), ne per-request náhodou** — jinak se model v rámci jedné konverzace
+přepne uprostřed a test se kontaminuje crossoverem [21]. A promote/rollback se gatuje
+na **deltě proti připnutému baseline s tolerancí**, ne na absolutním čísle; je to otázka
+signifikance, ne verdiktu [21].
+
+Pozor na slepou uličku: standardní canary controller (error rate, p99) na LLM regresi
+**nikdy nezabliká**, protože ta nemá error code — horší model vrátí HTTP 200, v limitu, s
+plynulou a sebevědomou chybnou odpovědí. Signál se musí **vyrobit** (LLM judge na 1–10 %
+provozu) a teprve ten skóre je rollback trigger [21].
+
+### 6. Drift: dvě různé věci se stejným jménem
+
+Rozlišovat **input drift / output drift / judge-score drift** [8]:
+
+- *Input drift* = uživatelé začali posílat něco, na co systém nebyl testovaný. Bývá první
+  signál reálného failure clusteru [8].
+- *Output drift* = odpovědi změnily tvar. **Odpojený od input driftu je to nejhlasitější
+  signál „model se nám změnil pod rukama"** — typicky tiché přetrénování u providera [8].
+  U nás konkrétně měřitelné: podíl odpovědí s CJK znaky, refusal rate, tool-call rate,
+  platnost struktury, medián délky odpovědi, poměr thinking:response tokenů.
+- *Judge-score drift* = nejblíž kvalitnímu canary, ale je downstream od stability
+  judge — judge se musí pinovat zvlášť [8].
+
+**Referenční okno je verzovaný artefakt**, ne „včera" nebo „minulý týden": je to okno, proti
+kterému byl aktuální model validovaný, content-hashed a svázané s releasem [8]. Bez toho
+se párové srovnání rozpadá.
+
+### 7. Pasti specifické pro tenhle případ
+
+Tohle je jádro odpovědi — čtyři věci, které se u nás pokazí, i kdyby metodika byla jinak
+správná:
+
+1. **Harness churn je u nás dominantní, ne okrajový.** `git log` v workspace má záznam
+   skoro každý den (naposledy `974b37a` 2026-09-20 12:21) a mění se přitom skilly,
+   MEMORY.md, SOUL.md, AGENTS.md — tedy systémový prompt, instrukce i tool popisy.
+   Harness sensitivity je 7–34 pb při identických vahách [2][3]; prompt a tool popisy
+   samy o sobě 5–15 pb [3]. **Porovnávat skóre napříč týdny je proto neplatné.** Párování
+   musí být na úrovni úlohy, ne období.
+2. **Self-eval.** Vyhodnocovací smyčka běží na stejném modelu, který hodnotí. Mitigace
+   jsou známé a levné [10]: cross-model judging (jiná rodina než contestant), double-swap
+   s filtrem konzistence (swap consistency je u judge modelů jen 70,5–77,3 %, tj. hrubě
+   každý čtvrtý verdikt se překlopí jen podle pořadí [10]), length-controlled scoring
+   (všechny testované LLM mají silný length bias, +17 pb nad lidskými hodnotiteli [10]).
+   Prakticky: hodnotit `deepseek` judge modelem z jiné rodiny (`glm`), a každou dvojici
+   proběhnout dvakrát s prohozeným pořadím.
+3. **Kvóta je součástí měření.** Ollama Cloud má max 3 paralelní dotazy a usage tiers
+   (Medium u `deepseek-v4.1-flash` vs High u `glm`); 4. souběžný dotaz čeká ve frontě a
+   to čekání spadne do wall-clocku [16][22]. Naměřená latence z paralelního běhu je proto
+   nadhodnocená a musí se měřit izolovaně.
+4. **Sandbox brání čtení záznamů.** Session JSONL jsou mimo workspace
+   (`<config-dir>/sessions/<workspace-id>/`, migrace ve v0.3.5 [11]) a `restrict_to_workspace`
+   mi blokuje exec na `~/.nanobot/...` — ověřeno dnes, guard to odmítl. Scripty spouštěné
+   cronem (jako `reflect_auto.py`) přístup mají. **Eval harness tedy musí být script pod
+   cronem nebo `detach`, ne pár tool callů v mém turnu.**
+
+## Rozpory a nejistoty
+
+- **Harness sensitivity: čísla se rozcházejí.** „7–34 pb" [2] vs „10–20 pb" [3] vs
+  „10–20 pb, scaffold gap přes 28 pb" [23]. Rozsah je konzistentní, přesná hodnota
+  závisí na benchmarku a definici scaffoldu. Pro nás je podstatné, že efekt je **větší
+  než typická mezera mezi modely**, ne konkrétní číslo.
+- **τ-bench je zmrazený.** Oficiální board je zamrzlý na modelech z konce 2024
+  (Claude 3.5 Sonnet 69,2 % retail / 46,0 % airline); každé číslo z let 2025–26 na
+  „τ-bench" je vendor self-report nebo successor τ2/τ3 [15]. Konkrétní čísla tedy
+  nepoužívat jako srovnávací bod — použitelná je **metodika** (pass^k, policy adherence,
+  user simulator), ne hodnoty.
+- **OTel GenAI konvence jsou pre-stable**, bez 1.0, GenAI repo nemá tagovaný release,
+  každý agent span má status Development [12]. Doporučení „instrumentovat proti
+  `gen_ai.*`" je tedy investice do pohyblivého cíle. Alternativa OpenInference existuje
+  paralelně a trace z jedné konvence nepoplní atributy druhé [12].
+- **Nemám ověřené, že session JSONL na téhle instanci skutečně obsahují `usage` per tah.**
+  Session manager ukládá `tool_calls`, `reasoning_content`, `thinking_blocks` [24];
+  token usage jde do separátního `token-usage.json` v webui dir [25]. Per-tah token
+  rozpad na thinking vs response, který bych chtěl pro verbositu, může být potřeba
+  dopočítat nebo vzít z response objektu providera — to jsem neověřil.
+- **Sierra má komerční zájem na τ-bench** [15] — metodika je dobrá, ale je to benchmark
+  postavený tak, aby vyhovoval jejich typu agenta. Nekopírovat slepě.
+- **„LLM judge ≈ lidský hodnotitel" je slabší tvrzení, než se cituje.** Kappa se často
+  reportuje bez konfidenčního intervalu [26]; agregátní korelace mohou maskovat rozptyl
+  [27]. Judge je pro nás nástroj na hrubé filtrování, ne ground truth.
+
+## Konkrétní návrh pro nanobot
+
+Kdybych to stavěl, minimální funkční varianta:
+
+1. **Scorecard per tah, ne per model.** Skript (cron) přečte nové session JSONL a pro
+   každý tah zapíše do `db/eval.sqlite`: preset, tool cally, tokeny in/out,
+   thinking:response poměr, wall-clock izolovaně, stop_reason, počet iterací.
+   Bez tohohle je jakákoli další úvaha dohad.
+2. **Připnutá párová sada ~50 úloh**, ne jednorázové testy: remind CRUD, note lookup,
+   wiki search, krátký multi-step edit, deep-research. Každá úloha má deterministický
+   check na stavu disku plus rubrici pro trajektorii. Spouští se **na obou presetech
+   z téhož commitu workspace** — jinak se měří scaffold.
+3. **pass^k = 4** jako primární metrika, Wilson interval a McNemar na párových výsledcích.
+   Clusterovat na session, ne na tah.
+4. **Deterministické checky první**, agent-as-judge až na to, co deterministicky ověřit
+   nelze. Judge z jiné modelové rodiny, double-swap, length-controlled.
+5. **Drift watchdog** jako samostatný hlídač: input drift (délka promptu, jazyk, téma) a
+   output drift (CJK podíl, refusal rate, tool-call rate, poměr thinking:response) proti
+   připnutému referenčnímu oknu, s prahy nastavenými na toleranci false positives [8].
+6. **Vlastní harness fingerpint.** Hash (systémový prompt + seznam skillů + tool schéma)
+   při každém běhu. Když se změní, scorecard se označí jako nepárovatelný s předchozím.
+   Tohle je u nás ta jediná věc, bez které je zbytek měření neplatný.
+
+Krok 1 a 6 jsou přitom levné a dají se udělat hned; kroky 2–4 vyžadují tu párovou sadu,
+což je ta skutečná práce.
+
+## Zdroje
+
+[1] Trajectory-level evaluation (outcome vs trajectory, 2×2 matice) — https://www.aievals.co/learn/agentic-evals/trajectory-vs-outcome
+[2] Agent Harness Benchmark Score: The Point-Swing Data (7–34 pb) — https://alatirok.com/agent-harness-benchmark-score/
+[3] AI Agent Benchmarks: Why Harness Sensitivity Matters — https://halmob.com/blog/ai-agent-benchmarks-harness-sensitivity-guide
+[4] Pass^k: the metric that catches inconsistent agents — https://www.aievals.co/learn/agentic-evals/pass-k-and-consistency
+[5] A/B Testing and Shadow Deployments for Agents (eval/regression boundary) — https://www.skillveris.com/learn/agent-evaluation-observability/a-b-testing-and-shadow-deployments-for-agents
+[6] Your Model ID Is Not a Lockfile: Silent Updates and Reproducibility — https://www.zustis.com/blog/model-id-not-a-lockfile.html
+[7] How to Handle AI Model Version Changes in Production (2026) — https://www.aimadetools.com/blog/ai-model-version-changes-production/
+[8] Drift detection for production AI (input/output/judge-score, referenční okno) — https://www.aievals.co/learn/production/drift-detection
+[9] How to Catch a Silent Model Upgrade: Version Pinning, Canary Prompts — https://dreaming.press/posts/how-to-catch-a-silent-model-upgrade-hosted-endpoint-drift.html
+[10] LLM Judge Biases: Position, Verbosity, Self-Preference (swap consistency 70,5–77,3 %, length bias +17 pb, perplexity mechanismus) — https://ai-tldr.dev/learn/evaluation-safety/llm-as-judge/llm-judge-biases/
+[11] nanobot-internals.md (sessions storage, v0.3.5 migrace) — `workspace/knowledge/nanobot-internals.md`
+[12] OpenTelemetry GenAI Semantic Conventions: Tracing AI Agents in Production (invoke_agent/chat/execute_tool, pre-stable bez 1.0, OpenInference paralelně) — https://veraexmachina.com/tech/opentelemetry-genai-agent-observability-production/
+[13] Inside the LLM Call: GenAI Observability with OpenTelemetry — https://opentelemetry.io/blog/2026/genai-observability/
+[14] nanobot `nanobot/agent/hook.py` (AgentHook, `after_iteration`, `usage`) — `tmp/nanobot`
+[15] Tau-Bench 2026: Customer-Service Agent Eval, Methodology, Tiers (policy adherence, pass^k, zamrzlý board, vendor interest) — https://benchmarkingagents.com/tau-bench/
+[16] projects/ai/memory.md (tool-call testy, S6 over-eager calling u deepseek-v3) a develop/knowledge.md (max 3 paralelní dotazy, usage tiers) — `workspace/`
+[17] Error Bars for LLM Evals: Wilson, clustered SE, párový McNemar, power (200 párových vs 388 na rameno) — https://www.aievals.co/cookbook/adding-error-bars
+[18] LLM Eval Sample Size Confidence Intervals (Wilson math, „27 z 30 je téměř ticho") — https://qaskills.sh/blog/llm-eval-sample-size-confidence-intervals
+[19] How Many Eval Examples Do You Need? Sample Size for LLM Tests — https://ai-tldr.dev/learn/evaluation-safety/evaluation-basics/llm-eval-sample-size/
+[20] Your LLM Eval Is Lying to You: The Statistical Power Problem — https://tianpan.co/blog/2026/04/15/statistical-power-llm-evals
+[21] How to Roll Out a New LLM in Production: Shadow vs Canary vs A/B (200 bez error code, hash stabilního ID, delta vs baseline) — https://dreaming.press/posts/how-to-roll-out-a-new-llm-shadow-vs-canary-vs-ab.html
+[22] ollama.com/library/deepseek-v4.1-flash/tags (Medium Usage, 1M ctx, vision+tools+thinking) — https://ollama.com/library/deepseek-v4.1-flash/tags
+[23] LLM Benchmark Methodology 2026: Reading Leaderboards (contamination, harness multiplier, governance types) — https://www.digitalapplied.com/blog/llm-benchmark-methodology-2026-contamination-leaderboard-guide
+[24] nanobot `nanobot/session/manager.py` (ukládané klíče zpráv) — `tmp/nanobot`
+[25] nanobot `nanobot/webui/token_usage.py` (workspace-scoped token telemetrie) — `tmp/nanobot`
+[26] Your LLM-as-judge eval set is too small. Here is the math (kappa bez CI) — https://medium.com/@maya.andersson/your-llm-judge-eval-set-is-too-small-here-is-the-math-da21cdde24f1
+[27] Beyond correlation: The impact of human uncertainty in measuring LLM-as-Judge — https://openreview.net/forum?id=E8gYIrbP00