Agenti AI se zřídkakdy zhroutí. Selhávají nenápadně a výzkum ukazuje proč

Agenti založení na velkých jazykových modelech nyní odpovídají na požadavky zákaznické podpory, dotazují se do databází a plánují cesty. Když se něco pokazí, obvykle vrátí sebejistou odpověď a stavový kód úspěchu. Rostoucí počet výzkumů vysvětluje, proč se tato selhání těžko odhalují a jak se je technické týmy učí měřit.

Selhání, které vypadá jako úspěch

Tradiční software obvykle selhává viditelně. Funkce vyvolá výjimku, server vrátí chybový kód a na monitorovacím panelu se rozsvítí červená. Agent AI se chová jinak. Funguje ve smyčce: jazykový model si přečte zadání, rozhodne se zavolat nástroj, například vyhledávací rozhraní API nebo databázi, přečte si výsledek a rozhodne, co udělá dál. Každý krok se může pokazit, přestože všechny síťové požadavky v řetězci proběhnou úspěšně.

Uvažujme běžný případ. Nástroj pro předpověď počasí selže a v jinak normální odpovědi vrátí text „služba není dostupná“. Model si tento text přečte, zdvořile se omluví, nebo v horším případě vytvoří věrohodnou předpověď na základě dat, na kterých byl natrénován. Uživatel dostane plynulou odpověď. Protokoly serveru ukazují úspěšný požadavek s běžnou latencí. Běžný monitorovací systém nijak nezaznamená, že se něco pokazilo.

Poskytovatelé modelů popisují stejnou mezeru ve své dokumentaci. Průvodce Googlem k rozhraní Gemini API uvádí, že model „funkci sám nevykonává“. Pouze navrhne název funkce a její argumenty; samotné volání provede aplikace vývojáře. Aplikace je proto jedinou částí systému, která vidí skutečný výsledek. Průvodce Anthropic pro vývoj agentů upozorňuje na související skutečnost: agenti potřebují v každém kroku „skutečné informace“ z prostředí, například výsledky volání nástrojů, aby mohli posoudit svůj postup. Když nástroj oznámí selhání obyčejným textem, jsou tyto informace nesprávné a agent nemá jak to poznat.

Nejde o nový typ problému, ale pouze o vyostřenou podobu problému starého. V roce 2015 popsali inženýři Googlu pod vedením D. Sculleyho „skrytý technický dluh“ v systémech strojového učení. Tvrdili, že většina rizik produkčního systému strojového učení nespočívá v kódu modelu, ale mimo něj, v závislostech na datech, konfiguraci a propojovacím kódu. Agenti k tomuto seznamu přidávají další vrstvu. Zadání a popisy nástrojů jsou konfigurací, která může změnit chování systému, aniž se změní jeho kód.

Malé úpravy, velké dopady

Jak velký vliv může mít drobná změna zadání? Ve studii představené na konferenci ICLR 2024 Melanie Sclar z University of Washington a její kolegové změnili pouze formátování zadání s několika ukázkami: oddělovače, mezery a velká písmena. Význam zůstal stejný. Výsledky na stejném úkolu se přesto u modelu LLaMA-2-13B lišily až o 76 bodů přesnosti. Tato citlivost nezmizela ani u větších modelů, s větším počtem příkladů nebo při dolaďování podle instrukcí.

Autoři doporučují uvádět rozmezí výsledků pro věrohodné varianty formátování zadání, nikoli jediné číslo. Pro technické týmy je praktické poučení jednodušší: úprava zadání je změnou kódu. Musí mít historii verzí a před zpřístupněním uživatelům se musí otestovat.

Totéž platí pro popisy nástrojů, které model čte jako součást zadání. Průvodce od společnosti Anthropic doporučuje věnovat definicím nástrojů „stejně velkou pozornost při tvorbě zadání“ jako hlavnímu zadání. Popisuje programovacího agenta, který opakovaně chyboval při práci s relativními cestami k souborům. Když byl nástroj upraven tak, aby vyžadoval absolutní cesty, model jej začal používat bez chyb. Model se nezměnil. Změnil se pouze popis, který četl.

Jeden úspěch mnoho nedokazuje

Další výzkumná linie se zaměřuje na konzistentnost. Benchmark τ-bench, který zveřejnil Shunyu Yao s kolegy ze společnosti Sierra a který byl představen na konferenci ICLR 2025, simuluje rozhovory se zákaznickou podporou, v nichž agent musí používat nástroje a dodržovat obchodní pravidla. Autoři zavedli metriku zvanou pass^k: pravděpodobnost, že agent správně vyřeší stejný úkol ve všech k pokusech.

Výsledky byly střízlivým varováním. Agent GPT-4o vyřešil při jediném pokusu přibližně 61 % maloobchodních úkolů. Když měl tentýž úkol úspěšně vyřešit osmkrát za sebou, míra úspěšnosti klesla přibližně na 25 %. Ukázka, která funguje jednou, toho o chování systému při tisícím spuštění mnoho neříká.

Kde se systémy s více agenty rozpadají

Mnoho týmů nyní propojuje několik agentů: jeden plánuje, druhý úkol provádí a třetí kontroluje výsledek. Studie z roku 2025 od UC Berkeley nazvaná „Proč systémy LLM s více agenty selhávají?“ analyzovala více než 1 600 anotovaných záznamů průběhu vykonávání napříč sedmi oblíbenými frameworky pro více agentů. Autoři pod vedením Merta Cemriho vytvořili taxonomii nazvanou MAST, která zahrnuje 14 režimů selhání ve třech skupinách: problémy s návrhem systému, nesoulad mezi agenty a ověřování úkolů.

Jejich hlavním zjištěním je, že řada selhání pramení z návrhu systému, nejen z omezení základního modelu. Agenti ignorují přidělené role, ztrácejí přehled o konverzaci nebo prohlásí úkol za dokončený, aniž by zkontrolovali výsledek. Po těchto selháních nezůstává žádná chybová zpráva. Odhalit je lze pouze tehdy, když někdo může zjistit, co každý agent skutečně udělal. Článek Unite.AI o paradoxu systémů s více agenty upozorňuje na podobný problém z hlediska architektury: přidání agentů může počáteční chybu zesílit, místo aby ji vyrušilo.

Jak zviditelnit to, co není vidět

Inženýrské řešení vychází z distribuovaných systémů, v nichž se požadavky už dlouho sledují napříč mnoha službami pomocí techniky zvané trasování. U agentů se každý požadavek uživatele stává stopou a každé volání modelu nebo nástroje úsekem této stopy. Úsek zaznamenává vstup, výstup, počet použitých tokenů i dobu, kterou zpracování trvalo. Organizace OpenTelemetry, která v oboru stanovuje standardy, připravuje společné konvence pro úseky generativní umělé inteligence. Ještě v roce 2026 jsou tyto konvence označeny jako rozpracované, takže názvy atributů se mohou stále měnit.

Několik open source projektů, například Langfuse, Arize Phoenix a AcruxCore, už tento přístup uplatňuje. Jejich zdrojový kód je veřejně dostupný, takže týmy mohou zkoumat, jak se ukládají stopy, a provozovat software na vlastních serverech. Zaznamenávají volání modelů i nástrojů jako úseky jedné stopy a umožňují týmům přiřadit jim hodnocení kvality. Na výběru nástroje záleží méně než na jedné věci: úsek nástroje musí zaznamenat, co nástroj skutečně vrátil, nejen to, zda síťový požadavek uspěl. Bez toho zůstane výše popsané selhání nástroje pro předpověď počasí skryté.

Průzkumy v oboru naznačují, že trasování je dnes běžné, testování však za ním zaostává. Zpráva společnosti LangChain o stavu vývoje agentů se koncem roku 2025 zaměřila na 1 340 odborníků z praxe. Kvalitu označilo za nejčastější překážku nasazení agentů do produkčního prostředí 32 % respondentů. Nějakou formu sledovatelnosti agentů uvedlo 89 % organizací a 62 % z nich podrobně trasovalo jednotlivé kroky a volání nástrojů. Pouze 52,4 % provádělo offline vyhodnocování na testovacích sadách a 37,3 % vyhodnocovalo provoz v reálném čase. Většina týmů vidí, co jejich agenti udělali. Méně z nich ověřuje, zda to bylo správně.

Hodnocení odpovědí ve velkém měřítku

Stopy ukazují, co se stalo. Neříkají ale, zda byla odpověď dobrá. Ruční čtení každé konverzace nelze škálovat, a tak týmy stále častěji používají jako hodnotitele druhý model; tento přístup se označuje jako LLM-as-a-judge. Studie z konference NeurIPS 2023, kterou napsal Lianmin Zheng s kolegy, zjistila, že výkonné modely, například GPT-4, se shodly s lidskými preferencemi ve více než 80 % případů, tedy přibližně stejně často, jako se shodují lidé mezi sebou.

Tatáž studie popsala slabiny této metody. Hodnoticí modely upřednostňují odpověď uvedenou jako první, dávají přednost delším odpovědím a mohou nadržovat textu, který samy vytvořily. Skóre od těchto modelů jsou proto pouze odhady. Hodí se pro vyhodnocování velkého množství odpovědí, je však třeba je ověřovat na menší sadě příkladů označených lidmi, přičemž pořadí odpovědí musí být náhodné.

Od praxe k pravidlům

Toto měření se stává také požadavkem na správu a řízení. Americký Národní institut pro standardy a technologie zveřejnil v lednu 2023 svůj rámec pro řízení rizik umělé inteligence. Jedna ze čtyř hlavních funkcí rámce, „Měření“, žádá organizace, aby rizika umělé inteligence průběžně kvantifikovaly, sledovaly a dokumentovaly. U agentů jsou důkazy, které tato funkce vyžaduje, právě stopy a výsledky vyhodnocování.

Co mohou týmy udělat už nyní

To odpovídá argumentu, který zazněl na této platformě: skutečnou zkouškou agentní umělé inteligence je spolehlivost. Výše uvedený výzkum tento argument doplňuje o podrobnosti týkající se měření: spolehlivost není vlastnost, kterou lze zjistit jednou provždy, ale rozsah, který je třeba průběžně měřit.

Výzkum ukazuje na několik jednoduchých návyků a hlavní poskytovatelé modelů doporučují mnohé z nich také. Praktická příručka OpenAI pro vytváření agentů týmům radí, aby si „nastavily evaluační testy a stanovily výchozí úroveň výkonu“ ještě před optimalizací a aby předaly řízení člověku, pokud agent překročí stanovený počet neúspěšných pokusů nebo narazí na vysoce rizikovou akci. Anthropic doporučuje „rozsáhlé testování v izolovaných prostředích“, než agenti začnou jednat samostatně.

V praxi to znamená několik konkrétních kroků. Uchovávejte prompty a popisy nástrojů pod správou verzí stejně jako kód. Každou změnu promptu otestujte na pevně dané datové sadě a počítejte s rozmezím výsledků, nikoli s jedinou hodnotou. Každý testovací případ spusťte několikrát, protože jediné spuštění neodhalí nekonzistentnost. Výstupy nástrojů zaznamenávejte do stop, aby se selhání nástroje nemohlo skrýt za stavovým kódem úspěchu. Automatická skóre hodnoticích modelů považujte za odhady a ověřujte je na lidech.

Žádný z těchto návyků nevyžaduje průlom ve schopnostech modelů. Vyžadují, abychom s agentem umělé inteligence zacházeli tak, jaký skutečně je: jako s pravděpodobnostním systémem, jehož výkon je třeba měřit, protože agent jen zřídka sám upozorní na svá selhání.