• Autor: Peter Vnuk
AI agenti sa z technologických ukážok rýchlo presúvajú do bežnej firemnej praxe. Ich prínos spočíva najmä v tom, že dokážu prepojiť viacero krokov do jedného uceleného pracovného postupu. Najskôr dohľadajú potrebné informácie a prejdú relevantné dokumenty, následne podľa zadania využijú dostupný nástroj alebo interný systém a napokon pripravia výstup, ktorý človek už len skontroluje alebo schváli.
V porovnaní s bežným chatbotom sa agent dostáva oveľa bližšie k reálnej práci ľudí vo firme. Zákazníckej podpore pomôže nájsť správnu odpoveď v dokumentácii, obchodníkom pripraví podklady na rokovania a pri administratívnych úlohách dokáže obmedziť ručné prepínanie medzi viacerými aplikáciami. Čím viac sa takýto nástroj približuje skutočnému workflow, tým viac záleží na jeho technickom aj prevádzkovom návrhu.
Úvodná testovacia fáza môže vzniknúť pomerne rýchlo, pokiaľ má firma dobre vybraný scenár, obmedzený okruh používateľov a prostredie, v ktorom je možné bezpečne skúšať dáta (aj fiktívne či syntetické) a typické otázky. Pri prechode do každodennej praxe sa z ukážky stáva služba, na ktorú sa ľudia začnú spoliehať. Agent musí reagovať predvídateľne aj pri vyššej záťaži, pracovať podľa oprávnení jednotlivých používateľov a zanechávať dostatok stôp pre tím, ktorý neskôr potrebuje dohľadať príčinu chybnej alebo nečakanej odpovede.
Dozviete sa:
Úvodná testovacia fáza má ukázať, či agent rieši konkrétny problém lepšie ako doterajší postup. Vo firmách často začína pri internej znalostnej báze, zákazníckej podpore alebo príprave obchodných podkladov, pretože práve tam sa opakuje veľa podobných otázok a zároveň sa dá dobre merať úspora času. V tejto časti projektu firma zisťuje najmä to, či ľuďom nový nástroj skutočne pomáha a či jeho odpovede obstoja pri bežnej práci.
Technické nároky sa riešia priebežne, pretože už testovacia fáza by mala pracovať s realistickými dátami, dokumentmi a zadaniami. Oplatí sa držať užší záber: najprv overiť hodnotu konkrétneho scenára a až z výsledkov odvodiť, aká infraštruktúra bude potrebná pre širšie nasadenie. Dobre pripravený test preto radšej overuje menší, jasne vymedzený proces než široké zadanie typu „zavedieme AI asistenta pre všetkých“.
Produkčná prevádzka prináša vyššiu zodpovednosť aj vyššie očakávania používateľov. Agent sa postupne mení z experimentálneho nástroja na bežne dostupnú službu, ktorá má zvládať viac požiadaviek súbežne, pracovať s aktuálnymi dátami a zachovať predvídateľné správanie aj v špičke. Pribúda tiež tlak na správu oprávnení, pretože agent môže odpovedať len z tých zdrojov, ku ktorým má daný používateľ skutočný prístup.
Oblasť | Testovacia fáza | Produkčná prevádzka
Cieľ | Overiť prínos a použiteľnosť | Zaistiť stabilnú službu pre bežnú prácu
Používatelia | Malý tím, vybrané roly | Viac tímov alebo širšie firemné nasadenie
Dáta | Obmedzená vzorka dokumentov | Aktuálne interné dáta a riadený prístup
Výkon | Rezerva na testovanie | Odozva, súbežnosť a možnosť rastu
Riziko | Chyba slúži na učenie | Chyba má jasný postup riešenia
Prevádzka | Jednoduchší dohľad | Monitoring, logovanie, verzovanie, zodpovednosť
S rastúcim počtom používateľov sa mení aj spôsob, akým ľudia systém vnímajú. Experimentu odpustia pomalšiu reakciu aj občasnú nepresnosť, pri nástroji pre každodennú prácu už očakávajú stabilnú službu, na ktorú sa môžu spoľahnúť. Práve v tomto bode sa ukazuje, či bol agent navrhnutý ako izolovaná ukážka alebo ako súčasť firemnej prevádzky.
i
Úvodná fáza má ukázať hodnotu konkrétneho scenára. Produkcia musí zabezpečiť, aby rovnaký scenár obstál pri každodennom používaní, vyššej záťaži a jasne definovanej zodpovednosti.
Pri plánovaní AI agenta sa často hovorí najmä o jazykovom modeli, pretože práve ten je najviditeľnejšou časťou riešenia. Vo firemnom nasadení však rozhoduje architektúra okolo neho. Model interpretuje zadanie a vytvára odpoveď, aplikačná vrstva riadi postup práce a konektory fungujú ako bezpečné napojenie na firemné zdroje. Cez ne sa agent dostáva k dokumentom, databázam alebo interným nástrojom bez toho, aby mal automaticky voľný prístup ku všetkému.
Vo výslednom riešení sa jednotlivé vrstvy dopĺňajú podľa toho, akú rolu majú v celom procese. Správa identít určuje, k akým dátam sa konkrétny používateľ dostane, zatiaľ čo logovanie pomáha spätne dohľadať priebeh požiadavky. Používateľské rozhranie zase rozhoduje o tom, či ľudia nástroj prijmú do bežnej práce alebo ho začnú obchádzať. Pri jednoduchom prototype môžu byť tieto časti veľmi jednoduché, vo firemnej prevádzke však tvoria základ spoľahlivosti a bezpečnosti.
Dobre je to vidieť pri RAG scenároch, teda pri práci s internou znalostnou bázou. Agent najprv vyhľadá relevantné časti firemných dokumentov a až potom z nich pripraví odpoveď. V praxi môže ísť napríklad o kombináciu interných smerníc, zmluvných podkladov a technickej dokumentácie, kde by ručné hľadanie zabralo výrazne viac času.
To zvyšuje nároky na infraštruktúru, pretože dokumenty sa pred použitím musia pripraviť na vyhľadávanie. Systém ich rozdelí na zmysluplné časti, prevedie ich význam do podoby vhodnej pre vyhľadávanie a uloží ich tak, aby agent rýchlo našiel pasáže relevantné pre konkrétnu otázku. GPU sa podieľa najmä na rýchlosti inferencie, zatiaľ čo databáza, úložisko, CPU a sieťová vrstva ovplyvňujú, ako svižne prebehne celá cesta od otázky k odpovedi.
i
Latencia často vzniká mimo grafickej karty — už pri vyhľadávaní dokumentov alebo prístupe k súborom. Pri zložitejších agentoch sa pridáva latencia externých API, dlhý kontext a väčší počet požiadaviek, ktoré bežia v rovnakom okamihu.
S prechodom do produkcie sa najskôr prejaví súbežnosť požiadaviek. V testovacej fáze pracuje s agentom niekoľko ľudí z jedného tímu, produkčné nasadenie už môže v rovnakom čase obsluhovať obchod, podporu, administratívu aj manažment. Pre dimenzovanie infraštruktúry je preto kľúčové, koľko požiadaviek beží súčasne a ako dlho jednotlivé úlohy trvajú.
Zložitejšie zadanie zaťažuje systém úplne inak ako jednoduché zhrnutie jedného dokumentu. Agent môže najprv hľadať informácie v niekoľkých zdrojoch, potom ich porovnávať s internými pravidlami, prípadne si vyžiadať údaje z ďalšieho firemného systému a až nakoniec pripraviť návrh odpovede zákazníkovi. V takomto scenári je dôležité sledovať celý priebeh práce, pretože chyba môže vzniknúť pri vyhľadávaní, volaní nástroja, interpretácii dát aj pri samotnom zostavení odpovede.
S rastúcim významom agenta vo firemných procesoch sa posúva aj hranica zodpovednosti. V testovacej fáze sa počíta s ladením a občasnou nepresnosťou, produkčné nasadenie však už potrebuje jasne nastavené mantinely. V praxi ide najmä o rozlíšenie medzi tým, kedy agent iba pripravuje podklad, a kedy už má jeho výstup dopad na zákazníka, objednávku alebo interné rozhodnutie. Práve v týchto situáciách musí byť vopred jasné, či môže pokračovať samostatne, alebo má výsledok najprv schváliť človek.
Pné nasadenie preto vyžaduje aj vlastný IT tím alebo integračného partnera. Ten musí poznať firemné prostredie natoľko, aby agent pracoval so správnymi dátami, rešpektoval oprávnenia a zapadol do procesov, ktoré už vo firme existujú. Infraštruktúra poskytne technický základ, samotný agent sa však musí stať súčasťou konkrétnej prevádzky, nie izolovaným nástrojom mimo nej.
Pri úvodnom testovaní býva najpraktickejšia výkonná pracovná stanica alebo menší AI server. Tím môže rýchlo skúšať rôzne modely a pracovať s reálnymi dokumentmi bez toho, aby už v tejto chvíli navrhoval cieľovú infraštruktúru pre celú organizáciu. V tejto fáze zohráva veľkú úlohu najmä operačná pamäť, rýchle NVMe úložisko a GPU s dostatočnou VRAM pre zvolený model aj pracovný kontext.
V produkčnej prevádzke už musí infraštruktúra počítať s rezervou, pretože systém má zvládať špičky, väčší počet súčasných požiadaviek a postupný rast. Popri samotnom výkone preto začína byť dôležitá aj servisovateľnosť, zálohovanie, dlhodobá rozšíriteľnosť a schopnosť rozložiť záťaž v prípade, že jeden server prestane stačiť.
| Scenár | Typické riešenie | Na čo sa zamerať |
|---|---|---|
| Vývoj a úvodné testy | Výkonná pracovná stanica | VRAM, RAM, rýchle SSD, jednoduchá správa prostredia |
| Interná testovacia fáza | Pracovné stanice alebo menší AI server | Reálne dáta, meranie odozvy, overovanie kvality |
| Tímové nasadenie | AI server s výkonovou rezervou | Súbežné požiadavky, monitoring, prístupové práva |
| Produkčná prevádzka | Serverová infraštruktúra, viac GPU alebo hybridný model | Škálovanie, dostupnosť, zálohy, sieť, prevádzkový dohľad |
| Citlivé dáta | Lokálna alebo privátna infraštruktúra | Kontrola nad dátami, auditovateľnosť, bezpečnostná politika |
Výber konfigurácie by mal vychádzať z konkrétnej záťaže. Interný asistent pre desiatky zamestnancov má iné potreby ako agent, ktorý pracuje s rozsiahlymi dokumentmi a dlhým kontextom. Najskôr sa oplatí otestovať reálne otázky, zmerať odozvu a až potom rozhodovať o cieľovej infraštruktúre.
i
Keď úvodná fáza ukáže pravidelné využitie, vyplatí sa popri technickom návrhu spočítať aj ekonomiku prevádzky. Pri stabilnej záťaži môže firma porovnať cloud, vlastnú infraštruktúru a hybridný model. Do výpočtu vstupujú mesačné náklady, využitie hardvéru, očakávaný rast aj požiadavky na prácu s dátami.
Výkon AI agentov sa nedá posudzovať podľa názvu grafickej karty alebo jediného parametra v konfigurácii. Veľký vplyv má kapacita VRAM, pretože do nej sa musí vojsť model, kontext aj časť prevádzkovej réžie. Keď agent pracuje s dlhšími vstupmi alebo väčším počtom súčasných požiadaviek, pamäťové nároky rastú veľmi rýchlo.
Operačná pamäť a úložisko ovplyvňujú najmä prácu s dátami. Pri RAG scenároch systém priebežne spracováva dokumenty a ukladá ich reprezentácie pre neskoršie vyhľadávanie. Rýchle úložisko pomáha pri práci s dokumentovou bázou aj dočasnými súbormi, zatiaľ čo slabšia časť infraštruktúry môže spomaliť celý reťazec aj vo chvíli, keď samotný model beží na výkonnej GPU.
Kvantizácia modelu môže znížiť pamäťové nároky a umožniť prevádzku na dostupnejšom hardvéri. Pri jednoduchších interných otázkach môže ísť o praktické riešenie, pri odborných, právnych alebo finančných výstupoch je však potrebné sledovať aj kvalitu. Rýchlejšia odozva má obmedzenú hodnotu, ak systém začne horšie pracovať s detailmi alebo bude pri opakovanom použití menej stabilný.
Aký veľký model naozaj potrebujete, aké dlhé budú vstupy, koľko ľudí bude systém používať súčasne a aká odozva je ešte pohodlná pre prácu. Bez týchto odpovedí sa hardvér vyberá naslepo.
Produkčný agent potrebuje dohľad podobne ako iná firemná aplikácia, len s väčšou potrebou sledovať jednotlivé kroky. Jedna používateľská požiadavka môže spustiť vyhľadanie dokumentov, volanie interného systému, interpretáciu výsledkov aj zostavenie odpovede. Ak výsledok nezodpovedá očakávaniam, firma musí vedieť dohľadať, kde problém vznikol.
Na technickej úrovni sa sleduje najmä odozva a priepustnosť, pretože ich používatelia vnímajú najrýchlejšie. V prevádzke je však rovnako dôležité vedieť, ako je vyťažená GPU, koľko pamäte systém spotrebováva a či sa chyby objavujú v modeli, konektoroch alebo pri vyhľadávaní dokumentov. Pri zložitejších agentoch preto majú veľkú hodnotu trace logy, teda záznamy jednotlivých krokov.
Ekonomická stránka dohľadu je rovnako dôležitá ako technická, pretože bez priebežných metrík firma nevidí, čo prevádzka agenta skutočne stojí. V cloude sa náklady menia podľa využívania modelu a objemu spracovaných požiadaviek, pri vlastnej infraštruktúre zase rozhoduje, ako dobre je hardvér vyťažený a akú rezervu má pre špičky. Až z týchto dát sa dá určiť, či systém potrebuje väčšiu kapacitu, lepšiu optimalizáciu alebo jednoduchší prevádzkový model.
V produkčnom nasadení pracuje firemný agent často s informáciami, ktoré majú zostať dostupné iba konkrétnym rolám alebo tímom. Ak napríklad čerpá zo zmluvných alebo cenových podkladov, musí sa riadiť rovnakými pravidlami ako zamestnanec, ktorý by s nimi pracoval ručne. Chyba v oprávneniach potom nie je len technický detail, ale priame bezpečnostné riziko.
V prípade znalostných asistentov je základný princíp jednoduchý: agent nemá odpovedať na základe dokumentu, ktorý by daný používateľ sám nemohol otvoriť. Preto musí byť správa identít a prístupových práv súčasťou návrhu od začiatku, nie až dodatočnou úpravou po úvodnej fáze. V praxi rozhoduje aj to, či systém dokáže spätne ukázať, z akého zdroja odpoveď vychádzala a kto k nej mal v danom momente oprávnenie.
Ešte citlivejšia je situácia pri agentoch, ktorí môžu spúšťať akcie. Príprava odpovede zákazníkovi alebo návrh zmeny v objednávke môže prebehnúť automaticky, samotné odoslanie alebo zásah do firemného systému však často vyžaduje potvrdenie človekom. Produkčný agent preto potrebuje jasne nastavenú hranicu medzi odporúčaním, návrhom a skutočným vykonaním akcie.
Úvodná testovacia fáza by mala začať pri procese, kde sa opakuje podobná práca a výsledok sa dá rozumne merať. V praxi to často býva zákaznícka podpora, pretože pracuje s podobnými otázkami a opiera sa o existujúcu dokumentáciu. Rovnako dobre môže fungovať interná znalostná báza alebo príprava obchodných podkladov, pokiaľ je jasné, akú časť práce má agent zrýchliť a podľa čoho sa pozná úspech.
Až po vyjasnení konkrétneho scenára prichádza na rad voľba modelu, databázy a hardvéru. V úvodnej fáze je dôležitejšie zistiť, ako sa agent správa v reálnom pracovnom kontexte, než hneď navrhovať infraštruktúru pre celú firmu. Preto sa oplatí začať menším, dobre ohraničeným použitím, ktoré je možné otestovať na skutočných otázkach a postupne rozširovať.
i
Mohlo by vás zaujímať
Testovacia súprava má obsahovať viac než ukážkové otázky pripravené tak, aby agent vyzeral dobre. V prvom kroku môžu stačiť anonymizované alebo syntetické dáta, no úvodná fáza má čo najskôr pracovať aj s reprezentatívnymi firemnými podkladmi. Až na nich sa ukáže, ako si systém poradí s neúplným zadaním, staršou verziou dokumentu, nejednotnou terminológiou alebo situáciou, keď má radšej priznať neistotu než vytvoriť presvedčivú, ale nesprávnu odpoveď.
Už počas úvodnej fázy sa oplatí merať rýchlosť odpovede spolu s jej kvalitou a schopnosťou dohľadať správny zdroj. Rovnako dôležité je sledovať, či ľudia nástroj skutočne používajú, alebo ho po prvom vyskúšaní obchádzajú. Ak úvodná fáza obstojí, návrh produkčnej prevádzky už musí riešiť očakávanú záťaž, pravidlá pre prácu s dátami, bezpečnosť a spôsob, akým sa bude agent ďalej upravovať podľa potrieb firmy.
AI agenti môžu firmám výrazne zrýchliť prácu s informáciami a opakovanou agendou, skutočný prínos sa však ukáže až v bežnej prevádzke. Dôležité je, aby ľudia nástroj naozaj používali, odpovede obstáli aj pri menej presných otázkach a infraštruktúra zvládla špičky bez citeľného zhoršenia odozvy. Úvodná fáza pomáha overiť hodnotu konkrétneho scenára. Produkčná prevádzka už vyžaduje robustnejšiu infraštruktúru, riadenie prístupov, monitoring, testovanie zmien a jasnú zodpovednosť za celý systém. Dobre navrhnutý agent začína konkrétnym scenárom, pokračuje realistickým testom a až potom prechádza k rozhodnutiu o infraštruktúre.
Pri výbere technického základu je najdôležitejšie poznať záťaž, dáta a očakávanú prevádzku. Inú konfiguráciu potrebuje vývojový tím, inú interná testovacia fáza a inú produkčné nasadenie pre viac oddelení. Firma, ktorá tieto rozdiely pomenuje včas, sa vyhne poddimenzovanému riešeniu aj zbytočne drahému nákupu výkonu bez jasného využitia.
Úvodná fáza má ukázať, či agent rieši konkrétny problém lepšie ako doterajší postup. Produkčná prevádzka prináša vyššiu zodpovednosť aj vyššie očakávania používateľov – agent sa mení z experimentálneho nástroja na bežne dostupnú službu, ktorá musí zvládať viac požiadaviek súčasne, pracovať s aktuálnymi dátami a zachovať predvídateľné správanie aj v špičke.
Pri AI agentoch sa výkon nedá posudzovať podľa názvu grafickej karty alebo jediného parametra v konfigurácii. Oneskorenie často vzniká mimo GPU – už pri vyhľadávaní dokumentov alebo prístupe k súborom. Databáza, úložisko, CPU a sieťová vrstva ovplyvňujú, ako svižne prebehne celá cesta od otázky k odpovedi.
Príprava odpovede zákazníkovi alebo návrh zmeny v objednávke môže prebehnúť automaticky, samotné odoslanie alebo zásah do firemného systému však často vyžaduje potvrdenie človekom. Produkčný agent preto potrebuje jasne nastavenú hranicu medzi odporúčaním, návrhom a skutočným vykonaním akcie.
Jedna používateľská požiadavka môže spustiť vyhľadanie dokumentov, volanie interného systému, interpretáciu výsledkov aj zostavenie odpovede. Ak výsledok nezodpovedá očakávaniam, firma musí vedieť dohľadať, kde problém vznikol. Bez metrík firma nevidí skutočné náklady na prevádzku agenta.
RAG (práca s internou znalostnou bázou) je scenár, pri ktorom agent najprv vyhľadá relevantné časti firemných dokumentov a až potom z nich pripraví odpoveď. Dokumenty sa pred použitím musia pripraviť na vyhľadávanie – systém ich rozdelí na zmysluplné časti, prevedie ich význam do podoby vhodnej na vyhľadávanie a uloží ich tak, aby boli rýchlo dostupné. To zvyšuje nároky na úložisko, databázu aj sieťovú vrstvu.
Peter Vnuk
Technológie sú pre mňa prácou aj zábavou – najviac sa venujem smartfónom, notebookom, audiotechnike, umelej inteligencii a všetkému hi-tech. Rád recenzujem novinky, sledujem futuristické trendy a odhadujem ďalší vývoj technológií. Fascinuje ma sci-fi a vízie budúceho sveta, ktoré často inšpirujú reálny technologický pokrok. Profesionálne sa venujem aj videohrám a hernému priemyslu. Keď práve nepracujem, rád si odpočiniem pri dobrej hre, kvalitnom pive alebo tvorbe technologických memes na Facebooku.
