252 lines
18 KiB
Markdown
252 lines
18 KiB
Markdown
# 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
|