Představme si asistenta, který má připravit podklady k objednávce. V prvním e-mailu je původní termín, v dalším změna dodavatele a o kus dál pokyn, že se nová cena vztahuje jen na část dodávky. AI může správně citovat všechny tři zprávy a přesto sestavit špatnou objednávku. Najít větu totiž není totéž jako udržet přehled o tom, co po všech změnách skutečně platí.
Právě tento rozdíl zkoumá nový benchmark StateBench od Ai2. Pro firmy je na něm nejzajímavější nepříjemně prostá otázka: když asistent dostane delší historii práce, získá lepší přehled, nebo jen větší hromadu podkladů, v níž se může přesvědčivě splést? Podle nás bychom měli přestat zaměňovat kapacitu vstupu za spolehlivost výsledku.
Najít poslední větu je ta lehčí práce
Za StateBench stojí Jackson Petty, William Merrill a Ashish Sabharwal. Jejich technická zpráva na arXivu byla vložena 2. listopadu 2026; Ai2 projekt veřejně představil o den později. Jde o cílený výzkumný test sledování stavu, nikoli o audit kancelářských asistentů nebo měření jejich firemní návratnosti.
Autoři rozlišují čtyři obtížnosti. Nejprve se hodnota nemění, potom ji přepisuje nové přiřazení. Třetí úroveň vyžaduje průběžně aktualizovat vlastní hodnotu a čtvrtá přidává závislosti mezi proměnnými. Rozdíl je podobný jako mezi nalezením původního údaje, dohledáním poslední opravy a sledováním řetězce přesunů, v němž další krok závisí na výsledku předchozího.
V oznámení Ai2 jsou popsány testy Gemini 3.8 Flash, Claude Opus 5.5 a GPT-6 Sol i Luna. Na jednodušších úlohách si vedly dobře, na složitějších s délkou vstupu ztrácely přesnost. U nejdelších zadání nejtěžší úrovně Ai2 uvádí nejvýše 13 procent. To není úspěšnost AI v běžné kanceláři, ale výsledek konkrétního syntetického testu.
Právě proto bychom z čísla nedělali titulek o neschopné umělé inteligenci. Důležitější je konstrukce zkoušky: donutí model rozlišit údaj, který stačí vyhledat, od stavu, který je potřeba postupně odvodit. U pracovního asistenta potřebujeme vědět obojí. Jediná souhrnná známka za dlouhé dokumenty nám tento rozdíl může schovat.
Archiv ještě není aktuální evidence
Vraťme se k objednávce. Když si ověřujeme, zda dodavatel někdy slíbil určitý termín, hledáme historický doklad. Když rozhodujeme, co objednat dnes, potřebujeme vyhodnotit pozdější změny, jejich rozsah a návaznosti. Stejný nalezený e-mail může být v prvním případě správnou odpovědí a ve druhém jen zastaralým podkladem.
To je také hranice, na kterou jsme narazili v rozboru archivování historie pomocí Mnemonic Proxy. Dohledat původní záznam má cenu, ale agentická paměť se nedá hodnotit jen podle toho, zda něco nezmizelo. Potřebujeme ještě poznat, zda nalezená informace platí, čím byla nahrazena a ke kterému okamžiku se vztahuje.
Náš praktický závěr je vést vedle historie také přehled aktuálního stavu s odkazy na rozhodující podklady. U objednávky by obsahoval platného dodavatele, schválené položky a poslední potvrzené podmínky. Neměl by vznikat jako volná vzpomínka asistenta, kterou už nikdo neporovná se zdroji. Musí být možné otevřít doklad a zjistit, proč v evidenci stojí právě tato hodnota.
Ani takový přehled ovšem není automatická pravda. Pokud ho stejný model chybně aktualizuje a potom se na něj poslušně odvolává, pouze jsme omyl přestěhovali z dlouhého chatu do pěkné tabulky. U významné změny proto doporučujeme kontrolovat nejen novou hodnotu, ale také její podklad a to, které předchozí rozhodnutí nahrazuje.
Menší modely ukázaly směr, ne hotovou náhradu
Samostatná část studie porovnává přímo trénované architektury. Autoři učili modely s 275 miliony parametrů na posloupnostech nejvýše 256 přiřazení a zkoušeli je i na výrazně delších. Rekurentní Gated DeltaNet a hybridní modely zobecňovaly na prvních třech úrovních podstatně lépe než testované varianty transformerů. Na nejtěžší úrovni ale ani jejich zobecňování nebylo neomezené.
Z toho neplyne, že malý specialista nahradí univerzálního asistenta. Model vycvičený na přesně vymezeném druhu operací dostal jinou přípravu než obecně předtrénovaný systém. Studie je argumentem pro cílený trénink a výzkum architektur, ne nákupním žebříčkem hotových produktů. Samotný název architektury není zárukou, že konkrétní nasazení zvládne naši práci.
Rámec navíc pracuje s pevným počtem proměnných; autoři tuto hranici výslovně uvádějí. Skutečná porada může přidat nového dodavatele nebo úplně nový požadavek. Test tedy pomáhá izolovat problém, ale neobsahuje celý provozní svět. Převádět jeho procenta přímo na počet chybných objednávek by bylo stejně nepřesné jako podle jedné disciplíny rozhodnout, kdo umí nejlépe řídit firmu.
Firemní zkouška má obsahovat i změnu zadání
Pokud bychom dnes zaváděli asistenta pro práci s dokumenty, chtěli bychom vedle shrnutí otestovat opravy a navazující změny. Nechat ho najít dodací podmínku v jednom dokumentu je slabá zkouška pro systém, který pak dostane celou obchodní historii. Zadání by mělo obsahovat původní rozhodnutí, jeho změnu a další krok závislý na změněném stavu.
V zákaznické podpoře bychom zkusili, zda asistent rozliší původní souhlas s vrácením zboží od pozdějšího omezení na jednu položku. V projektovém řízení, zda po přesunu úkolu změní i odpovědnou osobu v doporučeném dalším postupu. U programovacího asistenta, zda před opravou respektuje aktuální verzi souboru místo první varianty, kterou během práce viděl. To jsou naše návrhy provozních zkoušek, nikoli výsledky experimentů Ai2.
Hodnotili bychom zvlášť nalezení podkladu, správnost odvozeného stavu a rozhodnutí, zda už lze provést akci. Správná citace nezachrání chybnou objednávku. Stejně tak správně odvozená hodnota sama neznamená oprávnění odeslat zákazníkovi závaznou nabídku. V praxi nás zajímá celý tento řetězec, ne pouze přesvědčivost poslední odpovědi.
Podobný požadavek jsme rozebírali u sdílené pracovní plochy pro AI agenty: tým potřebuje rozlišovat stav úkolu a skutečně zkontrolovaný výsledek. StateBench k tomu přidává výzkumnou otázku, zda model vůbec správně udržel stav, ze kterého při další práci vychází. Evidence a schopnost s ní zacházet jsou dvě oddělené vrstvy.
Ai2 zveřejnil kód benchmarku i testovací data, takže se debata nemusí zastavit u grafu v oznámení. Pro běžného uživatele ale není hlavní úkol spouštět výzkumné experimenty. Je jím položit dodavateli asistenta přesnější otázku: ukázali jste, že systém informaci našel, nebo také že po všech opravách správně určil, co ještě platí?
Delší kontext je užitečná kapacita. Nedává však důvod vzdát se kontroly aktuálního stavu. Dokud tyto dvě věci budeme prodávat a nakupovat jako jednu schopnost, budeme mít asistenty, kteří umějí velmi dobře doložit, odkud vzali špatnou odpověď.
