Testování AI agentů: začni jednou chybou a sleduj i provedené kroky

TL;DR

• Při testování AI agenta kontroluj odpověď, provedené kroky i skutečný výsledek v nástroji. Každá z těchto částí může odhalit jinou chybu.
• Pro začátek vyber jedno konkrétní chování a malou sadu případů ze skutečné práce. Na stejných případech pak porovnávej změny zadání, modelu nebo nástrojů.
• Vezmi poslední selhání svého agenta a napiš, podle čeho poznáš správné provedení. Získáš první případ pro opakovaný test.

Agent ti oznámí, že přesunul schůzku na čtvrtek. Odpověď je srozumitelná a obsahuje správný čas. V kalendáři ale zůstala i původní událost. Pokud hodnotíš jen závěrečnou zprávu, takovou chybu přehlédneš.

Tento ilustrační příklad ukazuje hlavní otázku při testování AI agentů: co přesně musíš ověřit, abys mohl výsledek použít? Pro malý tým má smysl začít jednou činností, u které dokáže určit správný výsledek i nepřijatelný postup.

LangChain v přehledu z 15. října 2026 doporučuje vycházet ze záznamů skutečných úloh, kombinovat testy před nasazením s hodnocením běžného provozu a nalezené chyby vracet do testovací sady. Přehled popisuje také možnosti platformy LangSmith; základní princip lze využít i při výběru toho, co má tvůj tým vůbec měřit.

Odpověď, postup a stav po dokončení jsou tři různé kontroly

Záznam průběhu úlohy, označovaný jako trace, obsahuje vstupy, výstupy a jednotlivá volání modelu a nástrojů. Umožní ti zjistit, co agent udělal mezi přijetím zadání a závěrečnou odpovědí.

U agenta pracujícího s kalendářem můžeš rozlišit tři kontroly:

• Odpověď: oznámil správné datum a čas?
• Postup: vybral správnou událost a vyžádal si schválení, pokud ho daná změna vyžaduje?
• Výsledný stav: je událost skutečně přesunutá a nezůstala po ní nechtěná kopie?

Jde o návrh kontrol pro tento příklad, nikoli o výsledek provedeného testu. Rozdělení je užitečné tím, že odděluje různé příčiny selhání. Správně napsaná zpráva sama nedokládá správnou změnu v kalendáři.

U delší konverzace navíc kontroluj celé zadání včetně oprav. Pokud nejprve požádáš o středu a následně termín změníš na čtvrtek, výsledná událost musí odpovídat poslednímu požadavku. Samostatné hodnocení každé odpovědi tuto návaznost nemusí zachytit.

Malá testovací sada potřebuje jasnou otázku

Zdroj pro začátek doporučuje deset až dvacet příkladů jednoho chování ze záznamů práce agenta. Je to výchozí rozsah pro první testování, nikoli hranice, po jejímž dosažení máš spolehlivost prokázanou.

Vyber například otázku: „Promítne agent změnu termínu do správné události?“ K případům si ulož vstup a očekávaný výsledek. Současnou verzi na nich vyhodnoť a výsledky zachovej pro další porovnání. Pokud agenta teprve připravuješ, můžeš vycházet ze zkušebních úloh vlastního týmu.

Po změně zadání, modelu nebo nástroje spusť stejné případy znovu. Zjistíš tak, zda úprava opravila známou chybu a současně nezhoršila něco, co už fungovalo. Pro srovnání zachovej také stejná hodnoticí pravidla.

Co ověří kód a co má posoudit člověk

Pevně dané podmínky se hodí kontrolovat kódem. U kalendáře to může být datum, identifikátor události nebo počet vzniklých záznamů. Pro takovou otázku nepotřebuješ další model, který výsledek slovně posoudí.

Hodnoticí model se hodí tam, kde potřebuješ posoudit význam textu. Může například hodnotit, zda odpověď srozumitelně vysvětluje, co se změnilo. I jeho úsudek ale potřebuje kontrolu: nech člověka ohodnotit vzorek stejných případů a prohlédni si neshody.

Pomáhají úzké otázky a popsaná kritéria. „Uvádí odpověď nový termín?“ dává hodnotiteli jasnější úkol než „Je odpověď dobrá?“ Stejně tak může být hodnocení splněno či nesplněno lépe opakovatelné než známka od jedné do deseti bez vysvětlení jednotlivých stupňů. O tom, jaké chyby ještě přijmeš a které brání nasazení, rozhoduje tvůj tým.

Chyby z provozu rozšiřují testy před další změnou

Testy před nasazením, často označované jako offline evaluace, pracují s připravenou sadou případů. Hodnocení v provozu neboli online evaluace sleduje skutečné úlohy uživatelů. Oba přístupy odpovídají na jinou otázku: zda změna obstála ve známých situacích a co jí uniká při běžném používání.

Hodnoticí model nemusí posuzovat každou úlohu. Náklady lze omezit výběrem vzorku nebo zaměřením na případy s negativní zpětnou vazbou. Takový výběr ale nepředstavuje kontrolu veškerého provozu.

Když najdeš nové selhání, přidej ho mezi opakované testy. Pro první pokus stačí vybrat jednu nedávnou chybu a určit, kde se projeví: v odpovědi, v postupu, nebo ve výsledném stavu. Právě tam má začít tvoje kontrola při příští změně agenta.

Zdroj

Divya Santhanam, LangChain: The Most Common Questions About Agent Evals, Answered, 15. října 2026