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

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