AWS ukazuje, ako hľadať pomalé miesta a rast pamäte v produkčných AI agentoch

Prechod AI agenta z prototypu do produkcie mení charakter problémov. Kým pri prvých testoch sa vývojári sústreďujú na to, či agent správne volá nástroje a dokončí úlohu, v ostrej prevádzke začnú rozhodovať latencia, spotreba tokenov a správanie počas dlhých relácií. AWS v novom technickom návode opisuje, ako tieto problémy sledovať cez Amazon Bedrock AgentCore Observability a Amazon CloudWatch. Dôležitý posun je v tom, že funkčný agent ešte nemusí byť použiteľný agent: môže odpovedať správne, no príliš pomaly, draho alebo nestabilne.

Základom postupu je distribuované trasovanie, teda rozdelenie jednej požiadavky na jednotlivé kroky a meranie času každého z nich. Namiesto jedného súhrnného čísla tak tím vidí, koľko trvalo načítanie pamäte, volanie externého nástroja, generovanie odpovede či nadväzujúca operácia. AWS odporúča najprv stanoviť výkonový rozpočet pre konkrétny prípad použitia a potom v CloudWatch vyhľadať požiadavky, ktoré ho prekročili. Hranica vhodná pre dávkové spracovanie totiž nemusí byť prijateľná pre zákaznícky čet, kde používateľ vníma aj menšie zdržanie.

Praktická hodnota takéhoto pohľadu spočíva v rozlíšení príčiny od symptómu. Celková odpoveď môže trvať niekoľko sekúnd, no problém nemusí byť v modeli. Úzke miesto môže vytvárať databázový dotaz, sieťové spojenie, studený štart služby alebo externé API. Pri sériovom spracovaní sa oneskorenia navyše sčítajú. Ak agent čaká na tri nezávislé nástroje jeden po druhom, používateľ zaplatí časom za všetky tri; pri paralelnom spustení sa výsledná latencia približuje najpomalšiemu z nich. AWS vo svojom príklade uvádza pokles zo 4,5 na približne dve sekundy.

AgentCore Observability preto nie je iba obrazovka s priemernou odozvou. CloudWatch Logs Insights umožňuje filtrovať pomalé vyvolania, zoradiť ich podľa latencie a následne otvoriť konkrétnu trasu. Vývojár môže porovnať medián s 95. percentilom, ktorý lepšie zachytí skúsenosť používateľov pri problematických požiadavkách. Nízka chybovosť pritom sama osebe nestačí: agent môže úspešne dokončiť väčšinu úloh, ale postupné zhoršovanie odozvy môže viesť k opúšťaniu relácií bez toho, aby klasický monitoring vyhlásil incident.

Samostatnou vrstvou je pamäť agenta. Dlhé relácie hromadia kontext, uložené fakty aj históriu volaní. Ak sa obsah nekonsoliduje, rastie počet tokenov, predlžuje sa vyhľadávanie a agent môže naraziť na limit kontextového okna alebo vyčerpať pridelené zdroje. AWS navrhuje sledovať relácie podľa trvania a veľkosti pamäte, kontrolovať pravidelnosť extrakcie dôležitých informácií a vyhľadávať zlyhania konsolidácie. To je dôležité najmä pri zákazníckej podpore, výskumných asistentoch a monitorovacích agentoch, ktorí majú pracovať nepretržite alebo celé hodiny.

Odporúčaná náprava nie je neobmedzené zväčšovanie pamäte. Návod radí rozdeliť obsah do menších tematických priestorov, napríklad na preferencie, nedávnu históriu a doménové znalosti. Staršie rozhovory sa majú zhrnúť namiesto uchovávania každého výroku a jednotlivé priestory majú dostať limity. Takýto návrh znižuje vyhľadávací priestor a zároveň núti tím rozhodnúť, ktoré informácie sú skutočne potrebné. Ak retrieval trvá neprimerane dlho, problém môže byť v organizácii pamäte, nie v kapacite modelu.

Výkon a náklady sa stretávajú aj pri generovaní textu. Model vytvára tokeny postupne, takže zbytočne dlhá odpoveď predlžuje čakanie a zvyšuje účet. AWS odporúča v promptoch požadovať stručnú odpoveď, pokiaľ používateľ výslovne nechce podrobnosti, a nastaviť upozornenia na nečakane vysokú spotrebu tokenov. Nejde však o univerzálny recept na skracovanie obsahu. Tím by mal oddeliť úlohy, kde je stručnosť súčasťou kvality, od prípadov, v ktorých je dlhšie vysvetlenie nevyhnutné pre správnosť alebo audit.

Prevádzkový monitoring má zmysel až vtedy, keď vedie k overiteľnej zmene. Po úprave indexov, zapnutí vyrovnávacej pamäte, nastavení časových limitov alebo paralelizácii nástrojov treba znova spustiť rovnaké dotazy a porovnať percentily latencie. Pri pamäti je potrebné sledovať, či po konsolidácii klesá počet tokenov a čas vyhľadávania bez straty podstatného kontextu. Takto sa z jednorazového ladenia stáva opakovateľný cyklus: nájsť problematickú trasu, vysloviť hypotézu, upraviť jednu vrstvu a zmerať výsledok.

Pre tímy, ktoré prevádzkujú agentov mimo ekosystému AWS, je dôležitý najmä všeobecný vzor. Potrebujú korelačný identifikátor pre požiadavku, trasovanie naprieč modelom a nástrojmi, percentily namiesto samotných priemerov a samostatné metriky pre tokeny, pamäť a externé závislosti. Agentické aplikácie kombinujú viac zdrojov neistoty než bežné API, preto nestačí merať iba dostupnosť koncového bodu. Bez viditeľnosti do jednotlivých krokov môže tím nesprávne viniť model za problém, ktorý vzniká v databáze alebo v návrhu pracovného toku.

Nový návod AWS je druhou časťou série o diagnostike AgentCore a sústreďuje sa na agentov, ktorí nezlyhávajú nahlas. To je pre produkciu podstatná kategória: pomalé odpovede, nekontrolovaný rast kontextu a postupné zdražovanie sa často prejavia skôr v správaní používateľov než v počte chýb. Organizácie by preto mali výkonový rozpočet, správu pamäte a kontrolu tokenov zaradiť medzi podmienky nasadenia, nie ich riešiť až po sťažnostiach. AgentCore Observability a CloudWatch predstavujú konkrétnu implementáciu tohto prístupu; princíp merateľnosti však platí pre každý produkčný agentický systém.