• Autor: Peter Vnuk
AI agenti se z technologických ukázek rychle přesouvají do běžné firemní praxe. Jejich přínos spočívá hlavně v tom, že dokážou spojit několik kroků do jednoho pracovního postupu. Nejdřív dohledají potřebné informace a projdou relevantní dokumenty, potom podle zadání použijí dostupný nástroj nebo interní systém a nakonec připraví výstup, který člověk zkontroluje nebo schválí.
Ve srovnání s běžným chatbotem se agent dostává mnohem blíž k reálné práci lidí ve firmě. Zákaznické podpoře může pomoci najít správnou odpověď v dokumentaci, obchodníkovi připraví podklady pro jednání a u administrativních úloh dokáže omezit ruční přepínání mezi několika aplikacemi. Čím víc se takový nástroj přibližuje skutečnému workflow, tím víc záleží na tom, jak je navržený technicky i provozně.
První pilot může vzniknout poměrně rychle, pokud má firma dobře vybraný scénář, omezený okruh uživatelů a prostředí, ve kterém lze bezpečně testovat data (klidně fiktivní nebo syntetická) i typické dotazy. Při přechodu do každodenní praxe se z ukázky stává služba, na kterou se lidé začnou spoléhat. Agent musí reagovat předvídatelně i při větší zátěži, pracovat podle oprávnění jednotlivých uživatelů a zanechávat dostatek stop pro tým, který později potřebuje dohledat příčinu chybné nebo nečekané odpovědi.
Dozvíte se:
Pilotní fáze má ukázat, zda agent řeší konkrétní problém lépe než dosavadní postup. Ve firmách často začíná u interní znalostní báze, zákaznické podpory nebo přípravy obchodních podkladů, protože právě tam se opakuje hodně podobných dotazů a zároveň se dá dobře měřit úspora času. V této části projektu firma zjišťuje hlavně to, zda lidem nový nástroj opravdu pomáhá a zda jeho odpovědi obstojí při běžné práci.
Technické nároky se řeší průběžně, protože už pilot by měl pracovat s realistickými daty, dokumenty a zadáními. V této fázi se vyplatí držet užší záběr: nejprve ověřit hodnotu konkrétního scénáře a teprve z výsledků odvozovat, jaká infrastruktura bude potřeba pro širší nasazení. Dobře připravený pilot proto raději testuje menší, jasně vymezený proces než široké zadání typu „zavedeme AI asistenta pro všechny".
Produkční provoz přináší vyšší odpovědnost i vyšší očekávání uživatelů. Agent se postupně mění z testovacího nástroje v běžně dostupnou službu, která má zvládat více požadavků současně, pracovat s aktuálními daty a zachovat předvídatelné chování i ve špičce. Přibývá také tlak na správu oprávnění, protože agent může odpovídat jen z těch zdrojů, ke kterým má daný uživatel skutečně přístup.
Oblast | Pilotní fáze | Produkční provoz Cíl | Ověřit přínos a použitelnost | Zajistit stabilní službu pro běžnou práci Uživatelé | Malý tým, vybrané role | Více týmů nebo širší firemní nasazení Data | Omezený vzorek dokumentů | Aktuální interní data a řízený přístup Výkon | Rezerva pro testování | Odezva, souběžnost a možnost růstu Riziko | Chyba slouží k učení | Chyba má jasný postup řešení Provoz | Jednodušší dohled | Monitoring, logování, verzování, odpovědnost
S rostoucím počtem uživatelů se mění také způsob, jakým lidé systém vnímají. Experimentu odpustí pomalejší reakci i občasnou nepřesnost, u nástroje pro každodenní práci už očekávají stabilní službu, na kterou se mohou spolehnout. Právě v tomto bodě se ukazuje, zda byl agent navržený jako izolovaná ukázka, nebo jako součást firemního provozu.
i
Pilot má ukázat hodnotu konkrétního scénáře. Produkce musí zajistit, aby stejný scénář obstál při každodenním používání, větší zátěži a jasně dané odpovědnosti.
Při plánování AI agenta se často mluví hlavně o jazykovém modelu, protože právě ten je nejviditelnější částí celého řešení. Ve firemním nasazení však rozhoduje architektura kolem něj. Model interpretuje zadání a vytváří odpověď, aplikační vrstva řídí postup práce a konektory fungují jako bezpečné napojení na firemní zdroje. Přes ně se agent dostává k dokumentům, databázím nebo interním nástrojům, aniž by měl automaticky volný přístup ke všemu.
Ve výsledném řešení se jednotlivé vrstvy doplňují podle toho, jakou roli mají v celém procesu. Správa identit určuje, k jakým datům se konkrétní uživatel dostane, zatímco logování pomáhá zpětně dohledat průběh požadavku. Uživatelské rozhraní zase rozhoduje o tom, zda lidé nástroj přijmou do běžné práce, nebo ho začnou obcházet. U jednoduchého prototypu mohou být tyto části velmi lehké, ve firemním provozu už tvoří základ spolehlivosti a bezpečnosti.
Dobře je to vidět u RAG scénářů, tedy u práce s interní znalostní bází. Agent nejprve vyhledá relevantní části firemních dokumentů a teprve potom z nich připraví odpověď. V praxi může jít například o kombinaci interních směrnic, smluvních podkladů a technické dokumentace, kde by ruční hledání zabralo výrazně víc času.
To zvyšuje nároky na infrastrukturu, protože dokumenty se před použitím musí připravit pro vyhledávání. Systém je rozdělí na smysluplné části, převede jejich význam do podoby vhodné pro vyhledávání a uloží je tak, aby agent rychle našel pasáže relevantní pro konkrétní dotaz. GPU se podílí hlavně na rychlosti inference, zatímco databáze, úložiště, CPU a síťová vrstva ovlivňují, jak svižně proběhne celá cesta od dotazu k odpovědi.
i
Zdržení se často skrývá mimo grafickou kartu a může vznikat už při vyhledávání dokumentů nebo přístupu k souborům. U složitějších agentů se přidává latence externích API, dlouhý kontext a větší počet požadavků, které běží ve stejný okamžik.
S přechodem do produkce se nejdřív projeví souběžnost požadavků. V pilotu pracuje s agentem několik lidí z jednoho týmu, produkční nasazení už může ve stejný čas obsluhovat obchod, podporu, administrativu i management. Pro dimenzování infrastruktury je proto klíčové, kolik požadavků běží současně a jak dlouho jednotlivé úlohy trvají.
Složitější zadání zatěžuje systém úplně jinak než jednoduché shrnutí jednoho dokumentu. Agent může nejprve hledat informace v několika zdrojích, potom je porovnávat s interními pravidly, případně si vyžádat údaje z dalšího firemního systému a až nakonec připravit návrh odpovědi zákazníkovi. V takovém scénáři už je důležité sledovat celý průběh práce, protože chyba může vzniknout při vyhledávání, volání nástroje, interpretaci dat i při samotném sestavení odpovědi.
S rostoucím významem agenta ve firemních procesech se posouvá také hranice odpovědnosti. V pilotu se počítá s laděním a občasnou nepřesností, produkční nasazení už ale potřebuje jasně nastavené mantinely. V praxi jde hlavně o rozlišení mezi tím, kdy agent pouze připravuje podklad, a kdy už má jeho výstup dopad na zákazníka, objednávku nebo interní rozhodnutí. Právě v těchto situacích musí být předem jasné, zda může pokračovat samostatně, nebo má výsledek nejprve schválit člověk.
Kompletní nasazení proto vyžaduje i vlastní IT tým nebo integračního partnera. Ten musí znát firemní prostředí natolik, aby agent pracoval se správnými daty, respektoval oprávnění a zapadl do procesů, které už ve firmě existují. Infrastruktura poskytne technický základ, samotný agent se ale musí stát součástí konkrétního provozu, ne izolovaným nástrojem mimo něj.
U prvního testování bývá nejpraktičtější výkonná pracovní stanice nebo menší AI server. Tým může rychle zkoušet různé modely a pracovat s reálnými dokumenty, aniž by hned navrhoval cílovou infrastrukturu pro celou organizaci. V této fázi hraje velkou roli hlavně operační paměť, rychlé NVMe úložiště a GPU s dostatečnou VRAM pro zvolený model i pracovní kontext.
V produkčním provozu už musí infrastruktura počítat s rezervou, protože systém má zvládat špičky, větší počet současných dotazů a postupný růst. Vedle samotného výkonu proto začíná být podstatná také servisovatelnost, zálohování, dlouhodobá rozšiřitelnost a schopnost rozdělit zátěž, pokud jeden server přestane stačit.
| Scénář | Typické řešení | Na co se zaměřit |
|---|---|---|
| Vývoj a první testy | Výkonná pracovní stanice | VRAM, RAM, rychlé SSD, snadná správa prostředí |
| Interní pilot | Pracovní stanice nebo menší AI server | Reálná data, měření odezvy, testování kvality |
| Týmové nasazení | AI server s výkonovou rezervou | Souběžné dotazy, monitoring, přístupová práva |
| Produkční provoz | Serverová infrastruktura, více GPU nebo hybridní model | Škálování, dostupnost, zálohy, síť, provozní dohled |
| Citlivá data | Lokální nebo privátní infrastruktura | Kontrola nad daty, auditovatelnost, bezpečnostní politika |
Výběr konfigurace by měl vycházet z konkrétní zátěže. Interní asistent pro desítky zaměstnanců má jiné potřeby než agent, který pracuje s rozsáhlou dokumentací a dlouhým kontextem. Nejdřív se vyplatí otestovat reálné dotazy, změřit odezvu a až potom rozhodovat o cílové infrastruktuře.
i
Jakmile pilot ukáže pravidelné využití, vyplatí se vedle technického návrhu spočítat i ekonomiku provozu. U stabilní zátěže může firma porovnat cloud, vlastní infrastrukturu a hybridní model. Do výpočtu vstupují měsíční náklady, využití hardwaru, očekávaný růst i požadavky na práci s daty.
Místo pro TCO kalkulačku
U AI agentů se výkon obtížně posuzuje podle názvu grafické karty nebo jediného parametru v konfiguraci. Velký vliv má kapacita VRAM, protože do ní se musí vejít model, kontext a část běhové režie. Jakmile agent pracuje s delšími vstupy nebo větším počtem současných požadavků, paměťové nároky rostou velmi rychle.
Operační paměť a úložiště ovlivňují hlavně práci s daty. U RAG scénářů systém průběžně zpracovává dokumenty a ukládá jejich reprezentace pro pozdější vyhledávání. Rychlé úložiště pomáhá při práci s dokumentovou bází i dočasnými soubory, zatímco slabší část infrastruktury může zpomalit celý řetězec i ve chvíli, kdy samotný model běží na výkonné GPU.
Kvantizace modelu může snížit paměťové nároky a umožnit provoz na dostupnějším hardwaru. U jednodušších interních dotazů může jít o praktické řešení, u odborných, právních nebo finančních výstupů je potřeba sledovat i kvalitu. Rychlejší odpověď má omezenou hodnotu, pokud systém začne hůř pracovat s detaily nebo bude při opakovaném použití méně stabilní.
Jak velký model opravdu potřebujete, jak dlouhé budou vstupy, kolik lidí bude systém používat současně a jaká odezva je ještě pohodlná pro práci? Bez těchto odpovědí se hardware vybírá naslepo.
Produkční agent potřebuje dohled podobně jako jiná firemní aplikace, jen s větší potřebou sledovat jednotlivé kroky. Jeden uživatelský požadavek může spustit vyhledání dokumentů, volání interního systému, interpretaci výsledků i sestavení odpovědi. Pokud výsledek neodpovídá očekávání, firma musí umět dohledat, kde problém vznikl.
Na technické úrovni se sleduje hlavně odezva a propustnost, protože ty uživatelé vnímají nejrychleji. V provozu je ale stejně důležité vědět, jak je vytížená GPU, kolik paměti systém spotřebovává a zda se chyby objevují v modelu, konektorech nebo vyhledávání dokumentů. U složitějších agentů proto mají velkou hodnotu trace logy, tedy záznamy jednotlivých kroků.
Ekonomická stránka dohledu je stejně důležitá jako technická, protože bez průběžných metrik firma nevidí, co provoz agenta skutečně stojí. V cloudu se náklady mění podle využívání modelu a objemu zpracovaných požadavků, u vlastní infrastruktury zase rozhoduje, jak dobře je pořízený hardware vytížený a jakou rezervu má pro špičky. Teprve z těchto dat se dá určit, jestli systém potřebuje větší kapacitu, lepší optimalizaci, nebo jednodušší provozní model.
V produkčním nasazení pracuje firemní agent často s informacemi, které mají zůstat dostupné jen konkrétním rolím nebo týmům. Pokud například čerpá ze smluvních nebo cenových podkladů, musí se řídit stejnými pravidly jako zaměstnanec, který by s nimi pracoval ručně. Chyba v oprávněních pak není jen technický detail, ale přímé bezpečnostní riziko.
U znalostních asistentů je základní princip jednoduchý: agent nemá odpovídat na základě dokumentu, který by daný uživatel sám nemohl otevřít. Proto musí být správa identit a přístupových práv součástí návrhu od začátku, ne až dodatečnou úpravou po pilotu. V praxi rozhoduje i to, zda systém dokáže zpětně ukázat, z jakého zdroje odpověď vycházela a kdo k ní měl v danou chvíli oprávnění.
Ještě citlivější je situace u agentů, kteří mohou spouštět akce. Příprava odpovědi zákazníkovi nebo návrh změny v objednávce může proběhnout automaticky, samotné odeslání nebo zásah do firemního systému už ale často vyžaduje potvrzení člověkem. Produkční agent proto potřebuje jasně nastavenou hranici mezi doporučením, návrhem a skutečným provedením akce.
Pilot by měl začít u procesu, kde se opakuje podobná práce a výsledek se dá rozumně měřit. V praxi to často bývá zákaznická podpora, protože pracuje s podobnými dotazy a opírá se o existující dokumentaci. Podobně dobře může fungovat interní znalostní báze nebo příprava obchodních podkladů, pokud je jasné, jakou část práce má agent zrychlit a podle čeho se pozná úspěch.
Teprve po vyjasnění konkrétního scénáře přichází na řadu volba modelu, databáze a hardwaru. U pilotu je důležitější zjistit, jak se agent chová v reálném pracovním kontextu, než hned navrhovat infrastrukturu pro celou firmu. Právě proto se vyplatí začít menším, dobře ohraničeným použitím, které lze otestovat na skutečných dotazech a postupně rozšiřovat.
i
Mohlo by vás zajímat
Testovací sada má zahrnovat víc než ukázkové otázky připravené tak, aby agent vypadal dobře. V prvním kroku mohou stačit anonymizovaná nebo syntetická data, ale pilot má co nejdřív pracovat i s reprezentativními firemními podklady. Teprve na nich se ukáže, jak si systém poradí s neúplným zadáním, starší verzí dokumentu, nejednotnou terminologií nebo situací, kdy má raději přiznat nejistotu než vytvořit přesvědčivou, ale špatnou odpověď.
Už během pilotu se vyplatí měřit rychlost odpovědi spolu s její kvalitou a schopností dohledat správný zdroj. Stejně důležité je sledovat, jestli lidé nástroj skutečně používají, nebo ho po prvním vyzkoušení obcházejí. Pokud pilot obstojí, návrh produkčního provozu už musí řešit očekávanou zátěž, pravidla pro práci s daty, bezpečnost a způsob, jak se bude agent dál upravovat podle potřeb firmy.
AI agenti mohou firmám zrychlit práci s informacemi a opakovanou agendou, skutečný přínos se však ukáže až v běžném provozu. Důležité je, aby lidé nástroj opravdu používali, odpovědi obstály i při méně přesných dotazech a infrastruktura zvládla špičky bez citelného zhoršení odezvy. Pilotní fáze pomůže ověřit přínos konkrétního scénáře. Produkční provoz už vyžaduje robustnější infrastrukturu, řízení přístupů, monitoring, testování změn a jasnou odpovědnost za celý systém. Dobře navržený agent začíná konkrétním scénářem, pokračuje realistickým testem a až poté přechází k rozhodnutí o infrastruktuře.
Při výběru technického základu je nejdůležitější znát zátěž, data a očekávaný provoz. Jinou konfiguraci potřebuje vývojový tým, jinou interní pilot a jinou produkční nasazení pro více oddělení. Firma, která tyto rozdíly pojmenuje včas, se vyhne poddimenzovanému řešení i zbytečně drahému nákupu výkonu bez jasného využití.
Pilotní fáze má ukázat, zda agent řeší konkrétní problém lépe než dosavadní postup. Produkční provoz přináší vyšší odpovědnost i vyšší očekávání uživatelů – agent se mění z testovacího nástroje v běžně dostupnou službu, která musí zvládat více požadavků současně, pracovat s aktuálními daty a zachovat předvídatelné chování i ve špičce.
U AI agentů se výkon obtížně posuzuje podle názvu grafické karty nebo jediného parametru v konfiguraci. Zdržení se často skrývá mimo GPU a může vznikat už při vyhledávání dokumentů nebo přístupu k souborům. Databáze, úložiště, CPU a síťová vrstva ovlivňují, jak svižně proběhne celá cesta od dotazu k odpovědi.
Příprava odpovědi zákazníkovi nebo návrh změny v objednávce může proběhnout automaticky, samotné odeslání nebo zásah do firemního systému už ale často vyžaduje potvrzení člověkem. Produkční agent proto potřebuje jasně nastavenou hranici mezi doporučením, návrhem a skutečným provedením akce.
Jeden uživatelský požadavek může spustit vyhledání dokumentů, volání interního systému, interpretaci výsledků i sestavení odpovědi. Pokud výsledek neodpovídá očekávání, firma musí umět dohledat, kde problém vznikl. Bez průběžných metrik firma navíc nevidí, co provoz agenta skutečně stojí.
RAG (práce s interní znalostní bází) je scénář, kdy agent nejprve vyhledá relevantní části firemních dokumentů a teprve potom z nich připraví odpověď. Dokumenty se před použitím musí připravit pro vyhledávání – systém je rozdělí na smysluplné části, převede jejich význam do podoby vhodné pro vyhledávání a uloží je pro rychlé dohledání. To zvyšuje nároky na úložiště, databázi i síťovou vrstvu.
Peter Vnuk
Technologie jsou pro mě práce i zábava – nejvíc se věnuji smartphonům, notebookům, audiotechnice, umělé inteligenci a všemu hi-tech. Rád recenzuji novinky, sleduji futuristické trendy a odhaduji další vývoj technologií. Fascinuje mě sci-fi a vize budoucího světa, které často inspirují i reálný technologický pokrok. Profesionálně se věnuji také videohrám a hernímu průmyslu. Když zrovna nepracuji, rád si odpočinu u dobré hry, kvalitního piva nebo tvorbou technologických memes na Facebooku.
