AWS pridáva Strands Evals detektory na hľadanie príčin zlyhania AI agentov

AWS posúva hodnotenie AI agentov od jednoduchého merania úspešnosti k diagnostike toho, prečo sa agent pokazil. V novom technickom článku opisuje detektory v Strands Evals, ktoré berú stopu behu agenta, prechádzajú jednotlivé kroky a vracajú štruktúrovaný opis zlyhaní. Dôležité je, že nejde iba o ďalší leaderboard alebo skóre kvality odpovede. Cieľom je dostať sa k otázke, ktorá je v produkcii často najdrahšia: či problém vznikol v systémovom prompte, v popise nástroja, v spracovaní kontextu, alebo v samotnom výstupe modelu.

Strands Evals už predtým ponúkal prípady, experimenty a evaluátory, teda mechanizmy na meranie úspešnosti cieľov, výberu nástrojov alebo užitočnosti odpovedí. Nová vrstva detektorov nad tým pridáva analýzu na úrovni spanov v trace. Ak po zmene promptu alebo definície nástroja spadne úspešnosť agenta z 85 na 70 percent, samotné číslo ešte nehovorí, čo treba opraviť. Detektory majú prejsť jednotlivé udalosti v behu agenta, pomenovať kategóriu zlyhania, priradiť dôkazy a uviesť mieru istoty.

AWS v článku opisuje dvojfázový postup. Prvá fáza vyhľadáva zlyhania podľa taxonómie, ktorá zahŕňa halucinácie, nesprávne akcie, orchesračné chyby, nedodržanie inštrukcií, chyby exekúcie, problémy s kontextom, opakovanie, chyby výstupu modelu a konfiguračné nesúlady. Druhá fáza robí analýzu koreňovej príčiny. To je prakticky dôležité, pretože jeden skorý zlý parameter pri volaní nástroja môže spôsobiť niekoľko neskorších symptómov, ktoré by pri ručnej kontrole vyzerali ako samostatné chyby.

Príklad v zdroji pracuje s agentom pre výskum liekov postaveným na Strands Agents a Amazon Bedrock. Detektor nájde napríklad volanie nástroja bez povinného parametra knowledgeBaseId a súčasne zachytí situáciu, keď agent po priznaní chýbajúceho prístupu začne poskytovať všeobecné informácie. Analýza koreňovej príčiny potom rozlíši primárnu chybu od následkov a odporučí, či sa má meniť popis nástroja, systémový prompt alebo iná časť konfigurácie.

Pre tímy, ktoré nasadzujú agentov do zákazníckej podpory, výskumu alebo interných workflow, je rozdiel medzi evaluáciou a diagnostikou zásadný. Evaluácia povie, že agent v teste zlyhal. Diagnostika má povedať, či agent nepochopil cieľ, či si vybral nesprávny nástroj, či nástroj vrátil chybu, alebo či sa model rozbehol mimo dostupného kontextu. Bez takéhoto triedenia býva oprava agentov drahá, lebo inžinieri musia ručne čítať stopy s desiatkami až stovkami krokov.

Zaujímavá je aj škálovacia stratégia. Podľa AWS vie pipeline analyzovať malé relácie priamo, pri stredne veľkých stopách ponechať iba vetvy súvisiace so zlyhaním a pri veľkých stopách robiť rozdelenú analýzu s následným zlučovaním výsledkov. To ukazuje, že hodnotenie agentov sa začína podobať na klasické observability a incident-response nástroje: nestačí mať logy, treba vedieť vybrať relevantnú časť a priradiť jej prioritu.

Praktický dopad je najväčší v kontinuálnom testovaní. Ak sa detektory zapoja do eval pipeline, každá zmena promptu, nástroja alebo modelu môže okrem skóre vrátiť aj návrh opravy. Organizácie tak nemusia čakať, kým sa regresia prejaví v produkčnom incidente. Stále však platí, že LLM-diagnostika nie je neomylný audit. Výstupy s confidence score treba chápať ako zrýchlenie vyšetrovania, nie ako automatický rozsudok.

Pre ekosystém agentických aplikácií je tento smer dôležitejší než samotné meno frameworku. Väčšina firiem už rieši, ako agentov spoľahlivo testovať, verzovať a opravovať. Strands Evals ukazuje, že ďalšou konkurenčnou vrstvou nebude iba lepší model, ale aj lepšia prevádzková mechanika okolo neho: trace, span, typ chyby, príčina, odporúčaná oprava a možnosť zopakovať test po zmene. To je presne jazyk, ktorému rozumejú tímy zodpovedné za produkčné systémy. Zároveň to posúva debatu o agentoch od ukážok schopností k zodpovednosti za údržbu: každá automatizovaná akcia potrebuje nielen úspešný výsledok, ale aj vysvetliteľnú stopu, podľa ktorej sa dá bezpečne opraviť ďalšia verzia systému.