Změna AI agenta: lepší skóre může skrývat rozbitou funkci
Přidání nové schopnosti může AI agentovi pokazit práci, kterou už zvládal. Zjisti, jak porovnat verze po jednotlivých případech a odhalit zhoršení skryté za vyšším skóre.
Tento článek vznikl v agentské redakci Agentivpraxi. Rešerši, návrh i formulaci připravují AI agenti jako běžnou součást redakční práce.
TL;DR
- Vyšší průměrné skóre po úpravě AI agenta může skrývat zhoršení konkrétní úlohy. Porovnávej i jednotlivé případy, které před změnou fungovaly.
- Vývoj řízený vyhodnocováním, označovaný jako eval-driven development, stanovuje měřítko úspěchu před úpravou agenta. Stejnými testy pak projde původní i nová verze.
- Před další změnou si napiš, co se má zlepšit a co musí dál fungovat. Část příkladů nech stranou pro kontrolu, zda zlepšení platí i mimo případy použité při ladění.
Přidáš internímu agentovi možnost zakládat požadavky na IT podporu. Hlášení nefunkčního připojení konečně předá správnému týmu. Jenže začne zakládat požadavky i lidem, kteří chtějí pouze najít návod k připojení. Novou schopnost získal, část dosavadní práce se zhoršila.
Právě takovou změnu může souhrnné skóre označit za úspěch. Pokud agenta vyvíjíš nebo přebíráš úpravy od dodavatele, potřebuješ vidět také to, které dříve úspěšné případy nově selhávají.
LangChain v článku z 9. listopadu 2026 popisuje přístup nazvaný eval-driven development, tedy vývoj řízený vyhodnocováním. Základem je předem určit požadované chování, změřit výchozí stav a každou úpravu porovnat na stejné sadě příkladů. Praktický přínos pro menší tým spočívá v jasnějším rozhodnutí, zda změnu přijmout.
Nejdřív určuj, co se nesmí zhoršit
Zadání „agent má lépe pomáhat zaměstnancům“ se špatně ověřuje. Potřebuješ popsat konkrétní situaci, očekávanou akci i hranici, za kterou agent jít nemá.
Zdroj to ukazuje na agentovi pro firemní dokumentaci. Dosud umí hledat v interních podkladech a na webu. Nově má zakládat požadavky na IT podporu. Rozdíl mezi dvěma podobnými zprávami je přitom zásadní:
- „Notebook se nepřipojí k VPN.“ Agent má založit požadavek na podporu.
- „Jak se připojím k VPN?“ Agent má vyhledat návod v dokumentaci.
Součástí zadání je také zachování dosavadního vyhledávání. Tím vznikne měřítko, podle kterého můžeš hodnotit novou funkci i její vliv na zbytek agentské práce.
Test připrav ještě před opravou nebo přidáním schopnosti. Když pravidla hodnocení píšeš až podle hotového výstupu, snadno je nevědomky přizpůsobíš tomu, co agent právě udělal.
Stejná sada ukáže přínos i novou chybu
Před úpravou nech původní verzi projít sadou příkladů a ulož její výsledky. U nové schopnosti může zatím selhávat, zatímco ostatní úlohy zvládá. Tento výchozí stav potřebuješ pro porovnání.
Po změně spusť stejné příklady znovu. Vedle celkového skóre sleduj, které případy se zlepšily a které se zhoršily. Návrat chyby do dříve funkčního chování se označuje jako regrese.
V popsaném příkladu začne agent správně zakládat požadavky na podporu, ale také chybně předá dotaz na návod. Záznam jeho běhu ukáže příčinu: popis nového nástroje je příliš široký a vztahuje se obecně na problémy s VPN a notebooky. Po zúžení popisu na situace vyžadující zásah IT projdou všechny příklady v ukázkové sadě.
To je výsledek demonstračního příkladu ve zdroji. Pro vlastní rozhodnutí si z něj vezmi hlavně požadavek na podklady: ke změně chtěj přehled nových selhání a záznam kroků, který pomůže vysvětlit jejich příčinu.
Kontroluj akci a stav, který po agentovi zůstane
Správně znějící odpověď nemusí znamenat správně provedenou práci. U agenta pro IT podporu lze kódem ověřit, zda zavolal očekávaný nástroj. U agenta upravujícího kód potřebuješ kontrolovat také výsledný stav prostředí. Každý testovací běh má začínat v čistém prostředí, aby ho neovlivnila předchozí úloha.
Způsob hodnocení proto vybírej podle toho, co chceš doložit. Jednoznačná pravidla může kontrolovat běžný kód. Pro posouzení významu odpovědi lze použít jazykový model, ale jeho hodnocení nejprve porovnej s hodnocením lidí. Zdroj doporučuje úzké otázky a jasné „splněno, nesplněno“ místo neurčité stupnice.
LangSmith v popsaném postupu ukládá vstupy, výstupy a hodnocení jednotlivých experimentů, umožňuje porovnávat verze a procházet volání modelu i nástrojů. Pro tým je důležité, aby odpovědná osoba měla tyto podklady při rozhodování o nasazení změny dostupné.
Stoprocentní výsledek může znamenat příliš úzký test
Když agenta opakovaně upravuješ podle stejných příkladů, může se přizpůsobit právě jim. Perfektní výsledek na malé známé sadě pak nemusí znamenat, že zvládne jinak formulované požadavky uživatelů.
Část příkladů proto nech stranou a nepoužívej ji při průběžném ladění. Pokud roste úspěšnost jen na známé sadě, zatímco na odložených příkladech stagnuje, je to signál možného přeučení na test.
Další příklady získávej z reálného provozu. Uživatelé formulují požadavky jinak, než očekáváš, a odhalují situace, které původní sada nepokrývala. Ověřená selhání pak přidávej do dalších testů. Rychlé kontroly lze spouštět při změnách kódu, pomalejší hodnocení modelem například před vydáním nebo v noci.
Před další úpravou chtěj porovnání konkrétních případů
Pro nejbližší změnu vyber jednu schopnost agenta. Předem popiš očekávané zlepšení, zakázané chování a dosavadní úlohy, které musí zůstat funkční. Od člověka, který změnu připravuje, si vyžádej výsledky původní i upravené verze na stejné sadě.
Rozhodnutí o nasazení pak opři také o nově vzniklé chyby a jejich dopad. U interní podpory může být klíčová právě nenápadná otázka: umí agent po přidání nové akce stále poznat, kdy má jen vyhledat odpověď?
Zdroj
Související z knihovny