Chatbot může odpovědět plynule a přesto selhat. U AI agentů, kteří sami volí nástroje a spouštějí vícekrokové postupy, je to ještě důležitější, protože chyba se může skrýt v kterémkoli kroku. AWS proto na svém blogu o strojovém učení tvrdí, že hodnocení samotné kvality odpovědí modelu tu nestačí. Navrhuje třívrstvý přístup, který kromě obecné kvality zkoumá i byznysovou správnost a schopnost systému vysvětlit svá rozhodnutí. Ukazuje ho na fiktivním příkladu z dodavatelského řetězce. Jde o vendorský příspěvek, takže popisuje doporučený postup, nikoli nezávislé měření. Následující text rozebírá, co jednotlivé vrstvy kontrolují, jak vypadá konkrétní hodnocení a kde jsou hranice celé ukázky.
Proč nestačí hodnotit jen odpověď
Podle AWS závisí správnost agentního systému na třech věcech: na výběru nástrojů, na provedení celého workflow a na dodržení obchodních omezení. Workflow je tu posloupnost kroků, kterými agent dojde od zadání k výsledku. Tradiční přístup, který posuzuje jen kvalitu textu, tedy zachytí jen část problému. Agent může text formulovat dobře, ale pokud sáhne po nevhodném nástroji, přeskočí důležitý krok nebo poruší pravidlo firmy, výsledek v praxi neobstojí. Autoři příspěvku z toho vyvozují, že se musí hodnotit i cesta k odpovědi, nejen odpověď samotná. U multiagentních systémů, kde práci mezi sebou dělí více agentů, má takový pohled zvlášť velkou váhu. Chyba jednoho z nich se totiž může přenést do dalších kroků a konečná odpověď pak může působit věrohodně, i když stojí na špatném základu.
Tři vrstvy hodnocení
Navržený postup postupuje po jasných krocích. Základem jsou vestavěné evaluátory, tedy hotové hodnoticí nástroje, které posuzují obecnou kvalitu. Na ně navazují vlastní evaluátory, jež ověřují byznysovou správnost, a nakonec přicházejí evaluátory vysvětlitelnosti. Ty mají podle AWS podpořit důvěru a auditovatelnost, tedy možnost zpětně dohledat, proč systém rozhodl tak, jak rozhodl. Každá vrstva odpovídá na jinou otázku. První se ptá, zda je odpověď obecně dobrá. Druhá zjišťuje, zda je správná pro konkrétní firmu a její pravidla. Třetí řeší, zda jí lze porozumět a věřit. Uspořádání od obecného ke specifickému je praktické: tým může začít hotovými nástroji a teprve pak investovat práci do testů šitých na míru své doméně.
Ukázka: rozhodování v dodavatelském řetězci
Metodu AWS předvádí na fiktivní společnosti AnyCompany Retail. Řešení využívá Strands Agents a skládá se z orchestračního agenta a čtyř specializovaných podagentů. Orchestrátor, jak naznačuje název, koordinuje práci ostatních. Podagenti se dělí podle zaměření na optimalizační, distribuční, routingový a analytický. Taková architektura dobře ilustruje, proč je hodnocení složitější než u jednoho modelu: každý agent má jiný úkol, jiné nástroje a jiný způsob, jak se může zmýlit. Jde o ukázkový scénář, ne o popis nasazení u skutečného zákazníka, takže z příspěvku nevyplývá, jak by se přístup choval v reálném provozu. Pro čtenáře je ale užitečný tím, že na konkrétní architektuře ukazuje, kde všude se může multiagentní systém zmýlit.
Vlastní evaluátory hlídají doménu
Obecné metriky nepoznají, zda je trasa pro dodávku vůbec proveditelná nebo zda dotaz do databáze vrací to, co má. Proto AWS přidává vlastní evaluátory zaměřené na chování specifické pro dodavatelské řetězce. Kontrolují splnění omezení, proveditelnost trasy a správnost SQL dotazů, tedy dotazů, kterými agent čte data z databáze. Dále ověřují ukotvení v datech o zásobách, tedy zda se doporučení opírá o skutečné údaje, a hodnotí kvalitu vysvětlení. Tato vrstva převádí požadavky firmy do podoby testů. Co dříve existovalo jako nepsané pravidlo, například že trasa musí být reálně proveditelná, se tak stává měřitelnou podmínkou. Kdo ji chce použít u sebe, musí si pravidla své domény nejdřív sám pojmenovat a rozhodnout, co přesně znamená správný výsledek.
Tři omezení najednou
Konkrétní příklad se týká optimalizačního agenta. Jeho hodnocení ověřuje tři podmínky současně. První je rozpočet: přírůstkové náklady na držení zásob se musí vejít do zbývajícího limitu, tedy do rozdílu mezi stropem a už utracenou částkou. Druhá je pokrytí poptávky. Doporučená úroveň zásob nesmí být nižší než prognóza poptávky, aby zboží nedošlo, a zároveň nesmí přesáhnout dvojnásobek poptávky, aby nevznikl přebytek. Pokud by například prognóza činila 100 kusů, vyhovovala by jen doporučení v rozmezí od 100 do 200 kusů. Jde o čistě ilustrační čísla, příspěvek je v tomto místě nepoužívá. Třetí podmínkou je kapacita skladu, do které se doporučené množství musí vejít. Doporučení tedy projde jen tehdy, když splní všechny tři požadavky najednou. Rozumný návrh, který vyhovuje dvěma podmínkám, ale třetí porušuje, tak neprojde.
Vysvětlitelnost odděleně od přesnosti
Nejzajímavější je rozhodnutí měřit vysvětlitelnost zvlášť. Doporučení může být správné, a přesto nevysvětlené, takže projde vlastními evaluátory, ale u vysvětlitelnosti neuspěje. Možný je i opačný případ: dobře vysvětlené, ale chybné rozhodnutí. Podle AWS z toho vývojáři dostanou použitelný signál. Pokud selhává vysvětlení, má agent zlepšit způsob, jakým své uvažování formuluje. Pokud selhává správnost, je třeba opravit samotnou rozhodovací logiku. Kdyby se obojí slilo do jednoho skóre, tým by nepoznal, kde problém hledat, a mohl by ladit špatnou část systému. Oddělené měření má i druhý význam. Správný, ale nevysvětlený výsledek je pro audit problematický, protože nikdo nedokáže doložit, na čem stojí. Naopak přesvědčivě podané, ale chybné vysvětlení může klamat. Právě proto jsou obě osy hodnocení vedeny nezávisle.
Hodnocení až po činu, ochrana během něj
Důležité je také časování. Evaluace posuzují kvalitu agenta až po provedení úlohy, nemohou tedy chybné rozhodnutí zastavit v okamžiku, kdy vzniká. Tuto úlohu mají plnit Amazon Bedrock Guardrails, které podle AWS vynucují bezpečnostní omezení přímo za běhu. Nabízejí konfigurovatelné pojistky, například filtrování obsahu, detekci zakázaných témat a ověřování ukotvení odpovědí. Autoři je představují jako doplněk hodnoticího rámce, nikoli jeho náhradu. Obě vrstvy tak pokrývají různé okamžiky: Guardrails hlídají průběh, evaluace posuzují výsledek zpětně. V praxi to znamená, že evaluace slouží hlavně k poznání, kde a proč agent selhává, a k dalšímu zlepšování. Okamžitou ochranu před nežádoucím chováním zajišťují jiné nástroje.
Co příspěvek neukazuje
Praktická část používá jen režim na vyžádání, v němž se hodnocení spouští ručně nad zvolenými případy. Online monitoring je v příspěvku sice popsán, ale v ukázce se netestuje. Příspěvek tedy neprokazuje, jak se přístup chová při průběžném sledování ostrého provozu. Dostupné podklady také neobsahují kvantitativní srovnání, například jak často evaluátory zachytí skutečné chyby. Nevíme proto, nakolik jsou jejich hodnocení spolehlivá. Čtenář dostává přehledný návrh struktury, jehož přínos si bude muset ověřit na vlastních datech a vlastních pravidlech. Kdo takový přístup zvažuje, měl by vyjít z hlavní myšlenky příspěvku: správnost agenta se skládá z více vrstev, které je rozumné hodnotit odděleně. Hotové nástroje poskytnou obecný základ, vlastní testy pohlídají pravidla firmy a samostatné měření vysvětlitelnosti ukáže, zda lze rozhodnutím věřit.
Zdroje
- Evaluating multi-agent systems for explainability and helpfulness with Amazon Bedrock AgentCore | Artificial Intelligence — AWS Machine Learning Blog
Článek vznikl s pomocí AI; podklady a odkazy jsou uvedeny výše.