25. června 2026
Evaluace jako vstup, ne dashboard: Jak stavět sebeopravné LLM systémy
V tom, jak většina týmů evaluuje LLM aplikace, je zapečený tichý předpoklad: že eval je něco, na co se díváte. Postavíte testovací sadu, spustíte ji, dostanete skóre, dáte ho na dashboard a cítíte se ujištěni nebo vystrašeni. Dashboard vám řekne, že se něco zhoršilo. Člověk pořád musí přečíst, přijít na to proč, a jít to ručně opravit. Eval měří; člověk opravuje.
Nejzajímavější posun, který se teď v inženýrství agentů děje, je ten předpoklad úplně zlomit — přestat brát eval jako report, který čtete, a začít ho brát jako vstup, který systém přepisuje. Výstup evaluace nejde na graf, aby ho člověk interpretoval. Jde rovnou zpátky do smyčky jako signál, který pohání automatickou optimalizaci.
„Evaluace se stává vstupem, ne dashboardem." Trace z běhu tečou k rozhodčímu (verdikty → návrhy oprav → lidská brána, která vrací aktualizované nastavení agentovi) a paralelně k „dreamer" agentům, kteří píší do paměti, ze které agent čerpá. Jediná lidská brána je jediný krok ve smyčce, který není model. (Překresleno podle přednášky o evaluaci LLM agentů.)
Od tabule skóre k řídicímu signálu
Statická testovací sada je poctivá, ale pasivní. Umí vám říct, že úspěšnost spadla z 84 % na 79 %; neumí říct, který prompt upravit, a rozhodně ho neupraví. Takže hodnota dashboardu je stropovaná člověkem, který je k němu připojený — někdo si toho musí všimnout, diagnostikovat to a jednat, a ten někdo je úzké hrdlo.
Udělat z evalu vstup ten strop odstraní. Místo čísla, které člověk čte, se z evaluace stane strukturovaná zpětná vazba, kterou systém konzumuje: tenhle běh selhal, tady, z tohoto důvodu, a tady je změna, která by ho opravila. Eval přestává být koncem měření a stává se začátkem optimalizace.
Smyčka: trace, rozhodčí, fix, brána
Mechanismus začíná tím, co se vlastně hodnotí. Nehodnotíte jen finální odpověď agenta — zachytíte celý jeho exekuční trace, celý DAG kroků, kterými se k odpovědi dostal: každé vyhledání, každé volání nástroje, každé mezirozhodnutí. Tenhle trace, ne výstup, je jednotkou evaluace, protože právě tam selhání doopravdy žije.
Trace teče k nezávislým rozhodčím modelům, které produkují verdikty: nejen „tenhle běh byl špatný", ale „chyba je na tomhle uzlu". Pak jde návrhář oprav o krok dál, než kdy mohl jakýkoli dashboard — navrhne konkrétní změnu. Lokalizovanou úpravu promptu, vyladěnou instrukci na problémovém uzlu, zásah mířený přesně tam, kde verdikt našel vinu. Eval se posunul od „něco je špatně" k „tady je záplata".
A pak ten jeden záměrný kousek tření: lidská brána. Člověk navržený fix zreviduje a schválí, nebo odmítne. Schválený se stane aktualizovaným nastavením a vrátí se zpět do agenta. Smyčka se uzavře — běž, traceuj, suď, navrhni, schval, aktualizuj, běž znovu — a systém se zlepšuje, aniž by někdo ručně psal opravu.
Proč si nemůže známkovat vlastní úkol
Lákavá zkratka je nezávislé rozhodčí přeskočit a nechat agenta reflektovat vlastní běh. Zní to elegantně a nefunguje to. Agent revidující vlastní trace sdílí přesně ta slepá místa, která chybu vyprodukovala. Jeho chybné uvažování vypadá zevnitř správně — to je přesně logická halucinace — takže sebereflexe propluje rovnou kolem těch chyb, které potřebujete, aby zachytila.
Proto musí trace jít externím modelům s čerstvým kontextem. Vykonavatel a kritik musí být oddělené mysli, protože úkolem kritika je přesně vidět to, co vykonavatel nemohl. Je to tentýž důvod, proč dotazovací bot potřebuje vyhrazeného rozhodčího místo důvěry vlastní první odpovědi — vytažený až na úroveň celého exekučního trace a posunutý za pouhé souzení k navrhování opravy.
„Je to AI až na dno" — kromě jedné brány
Podívejte se na tu smyčku zblízka a vyvstane něco nápadného: skoro nic z ní není lidské. Agent je model. Rozhodčí je model. Kritéria rozhodčího jsou psaná modelem. Návrhy oprav jsou psané modelem. Jediná lidská schvalovací brána je jediná věc v celé smyčce, která není model.
Ta jedna brána není formalita — je to nosný bezpečnostní mechanismus. Plně AI optimalizační smyčka bez člověka uvnitř může driftovat, přefitovat se na vrtochy vlastního rozhodčího nebo se otrávit: věrohodný-ale-špatný „fix" se aplikuje, změní chování a další kolo modelem psané evaluace teď známkuje proti zkažené základní lince. Lidská brána je jistič proti tomuhle násobícímu se selhání a je to místo, kde žije odpovědnost — člověk podepíše každou změnu, která se dostane do produkce.
Všimněte si, co to dělá s rolí člověka. Už nepíše testovací případy ani nezírá na dashboardy. Reviduje navržené opravy a drží bránu. Úzké hrdlo se přesouvá od psaní ke schvalování — daleko mocnější místo pro lidský úsudek, a takové, kde jediný člověk může dohlížet na optimalizační smyčku, jejíž ruční provoz by stál celý tým.
Větev dreamerů: offline analýza do paměti
Smyčka rozhodčí-a-fix je jen horní polovina. Paralelně, v pomalejším offline tempu, běží druhá větev: „dreamer" agenti, kteří se prohrabávají zpětně proběhlými interakcemi. Nesedí v živé cestě požadavku; pracují na pozadí, destilují, co se opravdu stalo, syntetizují nové testovací scénáře ze skutečného provozu a zapisují svá zjištění do paměti. Hlavní agent pak do té paměti sahá pro kontext u dalších požadavků.
Tohle je offline polovina systému — část, která běží, když nikdo nečeká, a mění včerejší skutečné konverzace na zítřejší testovací případy a zítřejší kontext. Je to totéž oddělení, ke kterému se pořád vracíme: modul s předstihem na pozadí, který připravuje znalosti, živí online agenta, který je konzumuje. Tady ten modul na pozadí nejen předpočítává schéma — vysnívá evaly a pěstuje paměť agenta z prožité zkušenosti.
Shadow deployment: ostrá data, žádné následky
Zbývá jeden problém: abyste agenta evaluovali proti realitě, potřebujete ho mít běžícího na skutečných produkčních datech — ale nemůžete nechat napůl hotového agenta na těch datech doopravdy jednat. Odpovědí je shadow deployment. Agent běží v produkci, na živých datech, striktně jen pro čtení. Když se rozhodne provést akci — zapsat, odeslat, něco změnit — middleware volání zachytí a předstírá úspěch, vrátí 200 OK pro operaci, kterou nikdy doopravdy neprovedl. Agent pokračuje, jako by jednal; ve skutečnosti se nic nestalo.
Co pak inženýři studují, není výstup — je to rozhodovací trajektorie agenta. Dostanete plnou realističnost produkčního provozu bez jakéhokoli rizika a hodnotíte, jak agent uvažuje ve skutečných situacích, dávno předtím, než mu svěříte, aby se čehokoli dotkl. Je to princip read-only bezpečnosti proměněný ve vývojovou metodiku: nech ho přemýšlet proti skutečnému světu, jen ho zatím nenech jednat.
Co se změní, když je eval vstup
Složte to dohromady a obraz se obrátí. Eval už není to, co kontrolujete na konci; je to motor, který systém zlepšuje. Rozhodčí čtou trace a vynášejí verdikty. Návrháři oprav píší záplaty. Dreameři dolují minulost do paměti. Shadow deploymenty dodávají tlak skutečného světa bez škody skutečného světa. A jediný člověk stojí u té jedné brány, která jinak plně automatizovanou smyčku drží poctivou.
„Sebeopravný" je férový název pro výsledek, dokud si pamatujete, odkud to opravování doopravdy přichází. Není to agent, který se kouzlem sám debuguje — viděli jsme, proč to selhává. Je to smyčka nezávislých modelů navrhujících změny, paměť, která se kumuluje, a člověk, který schvaluje. Dashboard nikdy nic opravit neměl; uměl jen říct, že je něco rozbité. Skok je udělat z evaluace vstup, který opravuje — a držet u toho jednu lidskou ruku na bráně.
Pořád berete evaly jako dashboard, který kontrolujete dodatečně? Posun k evalu-jako-vstupu — trace, nezávislí rozhodčí, navržené opravy a lidská brána — je způsob, jak se agentní systémy začnou zlepšovat samy. Pojďme zmapovat, jak by ta smyčka vypadala pro váš stack.