Zepto riadi podporu cez evaluačné brány, AI agenti vybavia vyše 80 % tiketov

Indická platforma rýchleho obchodu Zepto prevádzkuje viacagentový systém zákazníckej podpory, ktorý podľa prípadovej štúdie Databricks spracúva viac než 100-tisíc tiketov denne. Podstatou nového prístupu nie je jeden výkonnejší model ani ďalší chatbot, ale proces, v ktorom sa hodnotenie stáva povinnou súčasťou vývoja aj prevádzky. Zepto uvádza, že agenti s ľudským dohľadom plne vybavia viac než 80 % tiketov, náklady na podporu klesli o 65 % a investícia sa vrátila za menej než mesiac. Ide o čísla zverejnené dodávateľom a zákazníkom, nie o nezávislý audit, no opísaná architektúra ponúka konkrétny obraz toho, ako sa agentické systémy presúvajú z pilotov do veľkej prevádzky.

Hodnotenie sa presúva pred nasadenie

Pri bežnom chatbotovi možno sledovať, či odpoveď pôsobí správne. Agent však najprv klasifikuje požiadavku, vyhľadáva informácie, rozhoduje o ďalšom kroku, volá nástroje a niekedy vykonáva transakciu. Dobrá záverečná veta preto môže zakryť chybný výber politiky, nesprávne získaný údaj alebo rizikové volanie nástroja. Pri viac než 100-tisíc prípadoch denne by aj jednopercentná chybovosť vytvárala približne tisíc problematických interakcií. Zepto preto nehodnotí iba finálnu odpoveď, ale aj priebeh jednotlivých krokov zachytený v trasách.

Databricks opisuje dve prepojené slučky. Vo vývojovej slučke vznikajú nové verzie promptov, pracovných postupov a modelových konfigurácií. Tie sa testujú na referenčných, takzvaných zlatých dátových súboroch a podľa viacerých metrík. Do produkčnej slučky sa verzia dostane až po prechode kvalitatívnou bránou. Živá prevádzka následne vytvára ďalšie trasy a odhaľuje prípady, ktoré pôvodný testovací súbor nepokrýval. Zlyhania sa vracajú do vývoja ako nové regresné testy, takže hodnotiaca množina sa vyvíja spolu so službou.

Tento model pripomína kontinuálnu integráciu v softvérovom vývoji, no s menej jednoznačnými výsledkami. Pri klasickom teste funkcia buď vráti očakávanú hodnotu, alebo nie. Odpoveď agenta môže byť fakticky správna, ale nevhodne formulovaná, príliš drahá, pomalá či v rozpore s internou politikou. Zepto preto kombinuje deterministické kontroly, vlastné hodnotiace pravidlá, ľudské anotácie a LLM-as-a-judge. Posudzovací model umožňuje automatizovať kritériá, ktoré sa nedajú jednoducho zapísať ako presná zhoda, jeho verdikt však tiež potrebuje kalibráciu voči úsudku odborníkov.

Trasy ukazujú, kde agent zlyhal

MLflow Tracing zachytáva vstupy, výstupy a metadáta medzikrokov vrátane latencie a spotreby tokenov. V praxi tak možno odlíšiť chybu klasifikácie od zlyhania vyhľadávania alebo nesprávneho použitia nástroja. To je zásadný rozdiel oproti monitorovaniu iba poslednej odpovede. Ak agent napríklad odmietne oprávnenú refundáciu, tím potrebuje vedieť, či nesprávne rozpoznal typ objednávky, načítal neaktuálnu politiku, alebo správne dáta vyhodnotil zlým pravidlom.

Produkčné trasy zároveň slúžia ako zdroj nových testovacích prípadov. Vývojári môžu vybrať zriedkavé, hraničné alebo finančne citlivé situácie, doplniť očakávaný výsledok a zaradiť ich do ďalšej evaluácie. Takýto postup je dôležitý pri sezónnych špičkách, nových kategóriách tovaru a viacjazyčnej podpore. Statický benchmark zostavený pri prvom nasadení by rýchlo zostarol, pretože reálne požiadavky zákazníkov menia slovník, distribúciu aj obchodné riziká.

MLflow vo svojej dokumentácii definuje evaluáciu cez tri základné prvky: dátový súbor so vstupmi a očakávaniami, hodnotiace funkcie a predikčnú funkciu, ktorá spúšťa hodnotenú aplikáciu. Platforma podporuje aj spätnú väzbu používateľov a odborníkov pripojenú priamo k trasám. To umožňuje uchovať nielen skóre, ale aj pôvod verdiktu, čas a revízie. Pre audit je takýto kontext cennejší než jediné agregované percento úspešnosti.

Praktický dopad pre tímy

Najdôležitejšou lekciou nie je konkrétna voľba Databricks alebo MLflow, ale oddelenie experimentovania od oprávnenia konať v produkcii. Nový model, prompt či nástroj by nemal automaticky získať prístup k refundáciám alebo zmenám objednávky len preto, že v ukážke pôsobil presvedčivo. Kvalitatívna brána musí obsahovať minimálne úspešnosť kritických scenárov, regresie oproti schválenej verzii, limity latencie a ceny a samostatné pravidlá pre prípady, ktoré sa majú odovzdať človeku.

Pre slovenské e-shopy, banky či telekomunikačných operátorov je relevantná aj práca s menším objemom dát. Zlatý súbor nemusí mať desaťtisíce položiek, ak cielene zachytáva reklamácie, odstúpenie od zmluvy, zmenu osobných údajov, podozrenie na podvod a jazykové varianty typické pre miestnych zákazníkov. Dôležitejšia než veľkosť je verzovanie, dohľadateľný pôvod prípadov a zastúpenie situácií s vysokým dopadom. Slovenčina navyše vyžaduje vlastné testy; výsledky na anglických alebo hindských dátach nemožno bez overenia preniesť na lokálne formulácie a legislatívne pojmy.

Meranie nákladov musí zahŕňať viac než cenu modelových tokenov. Do celkového účtu patria databázové dotazy, hodnotiace modely, uchovávanie trás, ľudské kontroly, opravy chybných rozhodnutí aj náklady na eskaláciu. Lacnejší model môže vyzerať výhodne v jednom volaní, ale prehrávať, ak potrebuje viac krokov alebo častejšie posiela prípad operátorovi. Evaluačný rámec má preto sledovať kvalitu, cenu aj čas spoločne a porovnávať celé pracovné postupy, nie izolované modely.

Čísla potrebujú opatrnú interpretáciu

Databricks uvádza okrem poklesu nákladov aj 20-percentné zlepšenie spokojnosti zákazníkov, osempercentné zlepšenie presnosti, trojnásobne rýchlejší vývoj a štvornásobne kratší čas vyriešenia prípadu. Verejný materiál však neposkytuje nezávisle overené surové dáta, úplné definície všetkých metrík ani presný experimentálny dizajn. Nie je preto jasné, aký bol porovnávací interval, ako sa menila skladba tiketov a aký podiel výsledku pochádza z automatizácie, organizačných zmien alebo samotnej platformy.

Otvorenou otázkou zostáva aj spoľahlivosť automatických rozhodcov. LLM-as-a-judge môže škálovať kontrolu prirodzeného jazyka, no môže zvýhodňovať určitý štýl, prehliadať doménové chyby alebo meniť správanie po aktualizácii modelu. Kritické scenáre preto potrebujú deterministické pravidlá a pravidelné porovnanie s ľudskými anotáciami. Trasy navyše môžu obsahovať osobné či transakčné údaje, takže ich zber musí sprevádzať minimalizácia dát, obmedzená retencia, riadenie prístupu a redakcia citlivých polí.

Prípad Zepto tak nie je dôkazom, že agenti sú pripravení bez dozoru prevziať zákaznícku podporu. Ukazuje skôr podmienky, za ktorých sa dá ich riziko systematicky riadiť: pozorovateľný priebeh, živé regresné dáta, merateľná brána pred nasadením a jasná cesta k človeku. Konkurenčnou výhodou nemusí byť agent s najvyšším skóre v univerzálnom benchmarku, ale organizácia, ktorá dokáže každú zmenu rýchlo otestovať na vlastných prípadoch a zastaviť ju skôr, než sa chyba rozšíri medzi zákazníkov.