Votemap (votemap.eu) je analytická platforma věnovaná záznamům hlasování Evropského parlamentu. Na našem clusteru provozuje Mastodon, PeerTube a vlastní vícejazyčnou aplikaci. Je to dost velký systém na to, aby návrh agenta, který by ho hlídal, byl rozumné technické cvičení, ne teoretický myšlenkový experiment. Počáteční zadání vymezovalo pro navrhovaného agenta čtyři konkrétní úkoly: hlídat, že pody běží, spouštět redeploy, hlídat čerstvost dat a hlásit incidenty.
Rozepsání toho zadání na jednotlivé body agenta úplně rozpustilo. Každý úkol na seznamu měl nakonec levnější řešení, které už běželo, a co zbylo, byly tři alerty. Jsme firma, která prodává AI, a tohle je text o místě, kde jsme ji nepoužili. Stojí to za zapsání, protože rozhodnutí něco nestavět po sobě nezanechá žádný artefakt, a proto má sklon zůstat nezaznamenané.
Rozepsání zadání na body
První úkol bylo hlídat zdraví podů. Zadání předpokládalo, že agent bude muset nepřetržitě sledovat provozní stav kontejnerů. Byl to sice věrohodný požadavek, ale tuhle funkci už měří kube-state-metrics. Agent by nad tahle syrová data přidal vrstvu interpretace navíc, což byla zbytečná režie.
Druhý úkol se týkal čerstvosti dat. Požadavek byl, aby agent sledoval aktuálnost dat načítaných do platformy. Tahle podmínka se ale dá vyjádřit a hlídat standardním alertovacím pravidlem. Agent by musel alert interpretovat, což přidávalo složitost tam, kde stačila jednoduchá kontrola prahové hodnoty.
Třetí úkol se týkal spouštění redeploye. Zadání navrhovalo, že by agent měl zahájit nové nasazení, když se splní určité podmínky. Tuhle akci už řeší naplánovaná pipeline. Agent by dostal na starost rozhodovat, kdy má pipeline běžet - a to je rozhodovací vrstva navíc, která nebyla potřeba.
Poslední úkol bylo hlášení incidentů. Zadání stanovovalo, že agent má nahlásit incidenty, když nastanou. Tahle funkce už se řeší přes webhook mechanismus. Agent by odpovídal za formátování a odesílání hlášení - tedy za vrstvu abstrakce nad existujícím, spolehlivým komunikačním kanálem.
Když se těchhle čtyři úkoly rozepsaly na jednotlivé body, navrhovanému agentovi nezbylo nic. Zůstaly z něj tři samostatné, snadno zvladatelné alerty.
Proč pravidlo poráží agenta
Pravidlo je deterministický kus logiky, který se spustí, když se splní konkrétní podmínka. Není to systém, který interpretuje záměr, a nesnaží se vymyslet, co jste tím mysleli. Pravidla jsou navržená na jasné vstupy a předvídatelné výstupy.
Pravidla se implementují levněji než agenti, protože potřebují jen definovanou logiku, ne komplexní, univerzální uvažování. Nehalucinují, takže jejich výstup se dá vždy dohledat zpátky ke vstupním datům. Nedají se vymluvit promptem, takže jejich chování je předvídatelné bez ohledu na kontext konverzace. A jejich selhání jsou navíc viditelná - dávají jasné body selhání, které se snadno diagnostikují.
Tohle není argument proti použití agentů ve složitých systémech. Je to spíš argument o tom, kde leží hranice mezi nutnou automatizací a přeinženýrovanou složitostí.
Chyba byla o krok dřív
Počáteční rozsah pro agenta byl zkopírovaný ze zadání napsaného jinde. Znělo to věrohodně a obsahovalo veškerý potřebný technický žargon, aby to vypadalo kompletně. Tahle počáteční věrohodnost bývá nejzrádnější součást technického plánování.
Rozsah zděděný z cizího zadání je premisa, ne fakt. Technický oříšek nebyl vyřešit, jak agenta omezit, ale zjistit, jestli má agent vůbec existovat. Soustředit se na detaily implementace dřív, než se ověří samotná premisa, je běžná past.
Ověření premisy stálo jen jeden průchod seznamem požadavků, bod po bodu. Tenhle jednoduchý ověřovací krok se ukázal jako nejlevnější krok celého cvičení a úspěšně smazal celý projekt.
Kdy si agent skutečně vydělá na místo
Agent si vydělá na místo tam, kde je prací sbírání a sepisování, rozptýlené napříč systémy, které nesdílí technologický stack, a kde je užitečným výstupem shrnutí, které si člověk přečte a podle kterého jedná. Hlídání není tahle práce: metrika, co překročí práh, je a vždycky bude práce pro pravidlo. Rozdíl je mezi všimnutím si podmínky, což zvládne líp pravidlo, a poskládáním obrazu z věcí, které žijí na pěti různých místech, což pravidlo nezvládne vůbec.
Agent není potřeba, když se jediná podmínka dá vyjádřit jako jednoduchý práh. Monitoring hlídá stroje, agent sepíše, co nasbíral, a člověk rozhodne, co s tím dál. Víc k tomuhle rozlišení najdete v textu jak malý tým provozuje spoustu systémů.
Otázky a odpovědi
Potřebuju AI agenta na monitoring?
Ne nutně. Nejdřív by se člověk měl zeptat, jestli se monitorovací úkol dá definovat jako jednoduchý práh nebo naplánovaná kontrola. Pokud je požadavek prostě zkontrolovat, jestli X je větší než Y, správný nástroj je pravidlo.
Kdy je lepší alert než agent?
Alert je lepší, když je potřebná akce binární a okamžitá, například když služba klesne pod definovanou výkonnostní metriku. Agent je potřeba, když má být výsledkem shrnutí nesourodých událostí, které vyžaduje lidský úsudek při třídění.
Jak se rozhodnout, jestli agenta vůbec stavět?
Rozepište si zadání na jednotlivé body dřív, než cokoli navrhnete, a u každého se zeptejte, co ho už pokrývá. Pokud má každý řádek levnější řešení, které už běží, nezbývá žádný agent ke stavbě. Co ten průchod přežije, je skutečný rozsah - a obvykle je mnohem menší než původní zadání.
Než začnete stavět jakéhokoli agenta, nejdůležitější otázka zní: které části tohohle rozsahu se nedají napsat jako pravidlo?