# 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 (`/sessions//`) | 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//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 ` 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 (`/sessions//`, 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