nOps prebudoval FinOps agenta Clara na AgentCore a sémantickej dátovej vrstve

Prečo pôvodná architektúra prestávala stačiť

Cloudová optimalizačná platforma nOps prebudovala svojho FinOps agenta Clara na architektúre, ktorá spája Amazon Bedrock AgentCore so sémantickou a analytickou vrstvou Databricks. Podľa spoločnej prípadovej štúdie AWS a nOps sa čas potrebný na uvedenie produkčných agentov skrátil o 75 percent: z odhadovaných desiatich až dvanástich mesiacov na štyri mesiace. Clara analyzuje cloudové výdavky a záväzky zákazníkov v AWS, Google Cloud a Microsoft Azure. nOps zároveň uvádza, že jeho zákazníci predstavujú viac než štyri miliardy dolárov cloudových výdavkov pod správou.

Prvá verzia Clary kombinovala Kubernetes, vyvolávanie modelov cez Amazon Bedrock, LangChain a LangGraph a nástroje postavené nad existujúcimi webovými API. Takéto riešenie umožnilo rýchlo vytvoriť prvú použiteľnú službu, no pri zložitejších analytických otázkach prinášalo dlhé kontexty, vyššiu latenciu a nekonzistentné odpovede. Obchodná logika bola rozptýlená medzi API a jednotlivé nástroje, ktoré pôvodne nevznikli na konverzačnú analýzu. Vývojári navyše museli udržiavať viacero vrstiev orchestrácie, monitorovania a infraštruktúry.

Nová verzia používa jedného agenta založeného na rámci Strands, nasadeného v kontajneri cez AgentCore Runtime. nOps odstránil smerovanie medzi viacerými agentmi aj samostatnú vrstvu LangChain a LangGraph. Agent má priamy prístup k nástrojom na vyhľadávanie dátových zdrojov, tvorbu a vykonávanie dotazov, správu analytického plátna a spúšťanie dlhších pracovných postupov. Zjednodušenie znižuje počet miest, na ktorých môže zlyhať volanie nástroja, no zároveň sústreďuje viac zodpovednosti do jedného agentického procesu a jeho oprávnení.

Dôležitejšia než výmena modelu bola dátová vrstva

Najpodstatnejšou zmenou nie je nový jazykový model, ale spôsob, akým agent získava finančné údaje. Clara už nemusí skladať odpoveď z generických produktových API. Vytvára SQL dotazy nad Databricks SQL Warehouse a používa Lakehouse Metric Views, ktoré umožňujú centrálne definovať obchodné metriky. Pravidlá pre kredity, zľavy, rezervované inštancie alebo Savings Plans tak nemusia byť zakaždým nanovo interpretované modelom. Rovnakú definíciu nákladu možno použiť v konverzácii, dashboarde aj ďalšom analytickom nástroji.

Dokumentácia Databricks opisuje metric views ako vrstvu, ktorá oddeľuje definície meraní od dimenzií používaných na filtrovanie, zoskupovanie a agregovanie. Pre finančného agenta je to praktická poistka proti situácii, keď dve odpovede používajú rovnaký pojem, ale rozdielny výpočet. Sémantická vrstva však sama nezaručuje správnosť. Ak je chybná definícia metriky, mapovanie účtov alebo vstupné fakturačné dáta, agent môže konzistentne produkovať nesprávny výsledok. Dôležité preto zostávajú verzovanie metrík, dátová línia, kontrola prístupov a porovnanie s účtovnými podkladmi.

Stav používateľského rozhrania, plátna, widgetov a relácií sa ukladá v serverless PostgreSQL službe Databricks Lakebase. AgentCore Memory má uchovávať sémantické fakty, používateľské preferencie a súhrny predchádzajúcich analýz. Relácia je previazaná s trvalým analytickým plátnom, nie iba s krátkym HTTP spojením, takže používateľ môže pokračovať aj po obnovení stránky. Dlhé výpočty prebiehajú asynchrónne a ich stav sledujú ďalšie služby AWS. To je podstatné pri analýzach, ktoré nemožno spoľahlivo dokončiť počas jedného konverzačného obratu.

Výsledky sú sľubné, ale nie nezávisle overené

nOps uvádza korektnosť odpovedí 81,7 percenta oproti približne 65 percentám v prvej verzii a skóre užitočnosti 79,4 percenta. Podiel zlyhaní nástrojov mal klesnúť zo 7,49 na 0,92 percenta. Manuálna analýza pre tímy zákazníckej podpory a riešení sa podľa firmy skrátila z približne dvoch hodín na tridsať minút. Na spoločnom runtime má fungovať štyri až šesť produkčných agentov. Tieto čísla naznačujú praktický prínos, nemožno ich však čítať ako všeobecný benchmark AgentCore alebo Databricks.

Prípadovú štúdiu napísali zástupcovia nOps a AWS a nie je doložená nezávislým auditom. Zverejnený text neposkytuje kompletnú testovaciu množinu, intervaly neistoty, počet hodnotených odpovedí ani podrobnú metodiku ľudského posudzovania. Percentuálne zlepšenia korektnosti a užitočnosti sa navyše vzťahujú na predchádzajúce obdobie, zatiaľ čo uvedené skóre prvej verzie predstavuje iný porovnávací bod. Chýba aj úplné ekonomické porovnanie: nižšia práca s infraštruktúrou môže byť vyvážená cenou riadeného runtime, pamäte, analytických dotazov a ďalších služieb.

Bezpečnosť si vyžaduje viac než vstupný guardrail. Architektúra podľa nOps kontroluje používateľský prompt, presadzuje oddelenie tenantov a sanitizuje odchádzajúce texty aj udalosti widgetov, aby sa nezobrazovali interné identifikátory. Pri agentovi pracujúcom s fakturačnými údajmi však treba samostatne overovať oprávnenie každého nástroja, rozsah SQL dotazov, auditné záznamy a správanie pri nejednoznačnom pokyne. Pamäť musí mať pravidlá uchovávania a mazania; preferencia používateľa nesmie byť omylom povýšená na účtovný fakt.

Čo z toho vyplýva pre slovenské a európske firmy

FinOps Foundation zdôrazňuje, že optimalizácia nie je iba hľadanie najnižšej ceny. Organizácie majú porovnávať úsporu s rizikom, výkonom, udržateľnosťou a hodnotou pracovného zaťaženia a do rozhodovania zapájať technické, finančné aj produktové tímy. Agent preto môže pripraviť vysvetlenie odchýlky, zoradiť príležitosti alebo navrhnúť ďalší krok, no schválenie záväzku či zmena produkčnej kapacity by mali zostať oddelenými, auditovateľnými operáciami. Najmä dlhodobé cloudové záväzky môžu pri chybnom odhade presunúť náklady namiesto ich odstránenia.

Pre slovenské firmy je podobná architektúra zaujímavá najmä v prostredí viacerých účtov, dcérskych spoločností a cloudov, kde sa náklady rozdeľujú podľa tímu, projektu alebo zákazníka. Sémantická vrstva môže zjednotiť definície nákladov, no lokálne nasadenie musí riešiť meny, daňové a účtovné obdobia, interné strediská aj rozdiel medzi fakturovanou a amortizovanou cenou záväzku. Európske organizácie musia navyše posúdiť umiestnenie dát, prenosy medzi službami, dobu uchovávania konverzácií a zmluvné postavenie jednotlivých dodávateľov.

Praktická lekcia z Clary je širšia než konkrétna kombinácia AWS a Databricks. Pri podnikových agentoch môže mať kvalitná dátová vrstva, jednoznačná definícia metrík, izolovaný stav a pozorovateľnosť väčší vplyv než samotná výmena modelu. Tímy by preto mali pred nasadením vytvoriť vlastnú sadu reálnych otázok, merať správnosť čísel aj citácií, sledovať zlyhania nástrojov a vyčísliť celkové náklady na jednu dokončenú analýzu. Otvorenou otázkou zostáva, či sa výsledky nOps zopakujú pri iných dátach, objeme používateľov a bezpečnostných požiadavkách. Kým nebudú dostupné nezávislé testy, ide o užitočný architektonický príklad, nie o dôkaz univerzálnej prevahy jedného cloudového stacku.