• Szerző: Peter Vnuk
Az AI-ügynökök a technológiai demókból rohamtempóban költöznek át a mindennapi vállalati gyakorlatba. Legnagyobb előnyük abban rejlik, hogy több lépést egyetlen munkafolyamattá tudnak összefűzni. Először felkutatják a szükséges információkat és átnézik a releváns dokumentumokat, aztán a feladat alapján igénybe veszik a rendelkezésre álló eszközt vagy belső rendszert, végül pedig elkészítik a kimenetet, amelyet egy ember ellenőriz vagy jóváhagy.
Egy hagyományos chatbothoz képest az ügynök sokkal közelebb kerül az emberek tényleges munkájához a cégen belül. Az ügyfélszolgálatnak segíthet megtalálni a helyes választ a dokumentációban, az értékesítőnek összeállítja a tárgyaláshoz szükséges anyagokat, az adminisztratív feladatoknál pedig csökkentheti a kézi váltogatást több alkalmazás között. Minél jobban közelít egy ilyen eszköz a valós munkafolyamathoz, annál fontosabb, hogy technikailag és üzemeltetési szempontból is jól legyen megtervezve.
Az első projekt viszonylag gyorsan elkészülhet, ha a cég jól választotta ki a felhasználási forgatókönyvet, ha szűk a felhasználói kör, és rendelkezésre áll egy olyan környezet, amelyben biztonságosan tesztelhetők az adatok (akár fiktív vagy szintetikus adatokkal) és a jellemző kérdések. Amikor viszont a mindennapi gyakorlatba lép át, a demóból szolgáltatás lesz, amelyre az emberek elkezdnek támaszkodni. Az ügynöknek nagyobb terhelés mellett is kiszámíthatóan kell reagálnia, az egyes felhasználók jogosultságai szerint kell dolgoznia, és elegendő nyomot kell hagynia ahhoz, hogy a csapat később vissza tudja keresni egy hibás vagy váratlan válasz okát.
Megtudod:
A tesztfázis célja kideríteni, hogy az ügynök jobban old-e meg egy konkrét problémát, mint az eddigi módszer. A cégeknél gyakran a belső tudásbázissal, az ügyfélszolgálattal vagy az üzleti anyagok előkészítésével indul, mert éppen ezeken a területeken ismétlődik rengeteg hasonló kérdés, és egyúttal jól mérhető az időmegtakarítás. A projekt ezen szakaszában a cég elsősorban azt vizsgálja, hogy az új eszköz tényleg segít-e az embereknek, és hogy a válaszai megállják-e a helyüket a mindennapi munkában.
A technikai követelményeket menet közben kell kezelni, mert már a demónak is valós adatokkal, dokumentumokkal és feladatokkal kell dolgoznia. Ebben a fázisban érdemes szűkebb fókuszt tartani: először egy konkrét forgatókönyv értékét igazolni, és csak az eredmények alapján levezetni, milyen infrastruktúrára lesz szükség a szélesebb körű bevezetéshez. Egy jól előkészített demó ezért inkább egy kisebb, egyértelműen körülhatárolt folyamatot tesztel, nem pedig egy olyan széles feladatot, mint a „vezessünk be AI-asszisztenst mindenkinek".
Az éles üzem nagyobb felelősséggel és magasabb felhasználói elvárásokkal jár. Az ügynök fokozatosan teszteszközből mindennap elérhető szolgáltatássá alakul, amelynek egyszerre több kérést kell kezelnie, aktuális adatokkal kell dolgoznia, és csúcsidőben is kiszámítható viselkedést kell mutatnia. Egyre nagyobb nyomás nehezedik a jogosultságkezelésre is, hiszen az ügynök csak azokból a forrásokból válaszolhat, amelyekhez az adott felhasználó ténylegesen hozzáfér.
A felhasználók számának növekedésével az is megváltozik, hogyan tekintenek az emberek a rendszerre. Egy kísérletnek elnézik a lassabb reakciót és az alkalmi pontatlanságot, de egy mindennapi munkaeszköztől már stabil, megbízható szolgáltatást várnak. Pontosan itt derül ki, hogy az ügynököt elszigetelt bemutatónak tervezték, vagy a vállalati működés szerves részének.
i
A demó célja egy konkrét forgatókönyv értékének igazolása. Az éles üzemnek azt kell biztosítania, hogy ugyanez a forgatókönyv a mindennapi használat, a nagyobb terhelés és az egyértelműen meghatározott felelősségi körök mellett is megállja a helyét.
Az AI-ügynök tervezésekor általában elsősorban a nyelvi modellről esik szó, hiszen ez a teljes megoldás leglátványosabb része. Vállalati környezetben azonban a köré épülő architektúra a döntő. A modell értelmezi a feladatot és létrehozza a választ, az alkalmazási réteg irányítja a munkafolyamatot, a konnektorok pedig biztonságos csatlakozást biztosítanak a vállalati erőforrásokhoz. Ezeken keresztül fér hozzá az ügynök a dokumentumokhoz, az adatbázisokhoz vagy a belső eszközökhöz anélkül, hogy automatikusan szabad hozzáférése lenne mindenhez.
A végső megoldásban az egyes rétegek aszerint egészítik ki egymást, hogy milyen szerepet töltenek be a teljes folyamatban. Az identitáskezelés határozza meg, hogy egy adott felhasználó milyen adatokhoz férhet hozzá, míg a naplózás segít utólag visszakövetni egy kérés menetét. A felhasználói felület pedig arról dönt, hogy az emberek beépítik-e az eszközt a mindennapi munkájukba, vagy inkább megkerülik. Egy egyszerű prototípusnál ezek a részek lehetnek nagyon könnyűsúlyúak, vállalati üzemben viszont már a megbízhatóság és a biztonság alapját képezik.
Jól megfigyelhető ez a RAG-forgatókönyveknél, vagyis a belső tudásbázissal végzett munkánál. Az ügynök először megkeresi a vállalati dokumentumok releváns részeit, és csak ezután állítja össze belőlük a választ. A gyakorlatban ez lehet például belső szabályzatok, szerződéses anyagok és műszaki dokumentáció kombinációja, ahol a kézi keresés jóval több időt venne igénybe.
Ez megnöveli az infrastruktúrával szembeni követelményeket, mivel a dokumentumokat használat előtt elő kell készíteni a kereséshez. A rendszer értelmes részekre bontja őket, a jelentésüket keresésre alkalmas formába alakítja, és úgy tárolja el őket, hogy az ügynök gyorsan megtalálja az adott kérdés szempontjából releváns szövegrészeket. A GPU főként az inferencia sebességéhez járul hozzá, míg az adatbázis, a tárhely, a CPU és a hálózati réteg azt befolyásolja, milyen gyorsan zajlik le a teljes út a kérdéstől a válaszig.
i
A késlekedés gyakran nem a grafikus kártyánál jelentkezik, hanem már a dokumentumok keresésekor vagy a fájlokhoz való hozzáférésnél is felmerülhet. Összetettebb ügynököknél ehhez hozzáadódik a külső API-k latenciája, a hosszú kontextus és az egyidejűleg futó kérések nagyobb száma.
Az éles üzembe álláskor először a kérések egyidejűsége mutatkozik meg. A demó során néhány ember dolgozik az ügynökkel egyetlen csapatból, éles környezetben viszont már egyszerre szolgálhatja ki az értékesítést, az ügyfélszolgálatot, az adminisztrációt és a menedzsmentet is. Az infrastruktúra méretezéséhez ezért kulcsfontosságú, hogy hány kérés fut egyidejűleg, és az egyes feladatok mennyi ideig tartanak.
Az összetettebb feladatok egészen másként terhelik a rendszert, mint egyetlen dokumentum egyszerű összefoglalása. Az ügynök először több forrásban kereshet információt, aztán összevetheti azokat a belső szabályokkal, esetleg adatokat kérhet egy másik vállalati rendszerből, és csak a végén készíti el a válaszjavaslatot az ügyfélnek. Ilyen forgatókönyvben már fontos a teljes munkafolyamat nyomon követése, mert hiba keletkezhet a keresésnél, az eszközhívásnál, az adatok értelmezésénél, de akár magánál a válasz összeállításánál is.
Az ügynök vállalati folyamatokban betöltött növekvő jelentőségével a felelősség határa is eltolódik. A tesztfázisban számítani lehet finomhangolásra és alkalmi pontatlanságokra, az éles üzembe helyezés viszont már egyértelműen kijelölt korlátokat igényel. A gyakorlatban leginkább arról van szó, hogy különbséget kell tenni aközött, amikor az ügynök csupán előkészíti az anyagot, és amikor a kimenete már hatással van az ügyfélre, a megrendelésre vagy egy belső döntésre. Pontosan ezekben a helyzetekben kell előre tisztázni, hogy folytathatja-e önállóan, vagy az eredményt előbb egy embernek jóvá kell hagynia.
A teljes körű bevezetéshez ezért saját IT-csapatra vagy integrációs partnerre is szükség van. Ennek a partnernek annyira ismernie kell a vállalati környezetet, hogy az ügynök a megfelelő adatokkal dolgozzon, tiszteletben tartsa a jogosultságokat, és illeszkedjen a cégnél már meglévő folyamatokba. Az infrastruktúra biztosítja a technikai alapot, de magának az ügynöknek a konkrét üzemmenet részévé kell válnia, nem pedig azon kívül álló, elszigetelt eszköznek.
Az első tesztelésnél általában egy erős munkaállomás vagy egy kisebb AI-szerver a legpraktikusabb megoldás. A csapat gyorsan kipróbálhat különböző modelleket, és valós dokumentumokkal dolgozhat anélkül, hogy azonnal meg kellene terveznie a célinfrastruktúrát az egész szervezet számára. Ebben a fázisban elsősorban az operatív memória, a gyors NVMe tárhely és a választott modellhez és munkafolyamathoz elegendő VRAM-mal rendelkező GPU játszik nagy szerepet.
Éles üzemben az infrastruktúrának már tartalékkal kell számolnia, mivel a rendszernek kezelnie kell a csúcsterheléseket, a nagyobb számú egyidejű lekérdezést és a fokozatos növekedést. A puszta teljesítmény mellett ezért a szervizelhetőség, a biztonsági mentés, a hosszú távú bővíthetőség és a terheléselosztás képessége is fontossá válik arra az esetre, ha egyetlen szerver már nem lenne elegendő.
| Forgatókönyv | Jellemző megoldás | Mire figyelj |
|---|---|---|
| Fejlesztés és első tesztek | Erős munkaállomás | VRAM, RAM, gyors SSD, egyszerű környezetkezelés |
| Belső demó | Munkaállomás vagy kisebb AI-szerver | Valós adatok, válaszidő mérése, minőségtesztelés |
| Csapatszintű bevezetés | AI-szerver teljesítménytartalékkal | Egyidejű lekérdezések, monitorozás, hozzáférési jogok |
| Éles üzem | Szerverinfrastruktúra, több GPU vagy hibrid modell | Skálázás, rendelkezésre állás, mentések, hálózat, üzemeltetési felügyelet |
| Érzékeny adatok | Helyi vagy privát infrastruktúra | Adatok feletti kontroll, auditálhatóság, biztonsági szabályzat |
A konfiguráció kiválasztásánál a konkrét terhelésből érdemes kiindulni. Egy néhány tucat munkatársat kiszolgáló belső asszisztensnek más az igénye, mint egy olyan ügynöknek, amely kiterjedt dokumentációval és hosszú kontextussal dolgozik. Először érdemes valós lekérdezésekkel tesztelni, megmérni a válaszidőt, és csak utána dönteni a célinfrastruktúráról.
i
Amint a demó rendszeres használatot mutat, a technikai tervezés mellett érdemes az üzemeltetés gazdaságosságát is kiszámolni. Stabil terhelés esetén a cég összehasonlíthatja a felhőt, a saját infrastruktúrát és a hibrid modellt. A számításba beletartoznak a havi költségek, a hardverkihasználtság, a várható növekedés és az adatkezelési követelmények.
Hely a TCO-kalkulátornak
Az AI-ügynököknél a teljesítményt nehéz pusztán a videokártya márkája vagy egyetlen konfigurációs paraméter alapján megítélni. Komoly szerepe van a VRAM kapacitásának, mivel abba kell beleférnie a modellnek, a kontextusnak és a futásidejű többletterhelés egy részének. Amint az ügynök hosszabb bemenetekkel vagy nagyobb számú egyidejű kéréssel dolgozik, a memóriaigény rendkívül gyorsan nő.
Az operatív memória és a háttértár elsősorban az adatkezelést befolyásolja. RAG-forgatókönyvek esetén a rendszer folyamatosan dolgozza fel a dokumentumokat, és tárolja azok reprezentációit a későbbi kereséshez. A gyors háttértár segít a dokumentumbázis és az ideiglenes fájlok kezelésében, miközben az infrastruktúra gyengébb láncszeme az egész folyamatot lelassíthatja – még akkor is, ha maga a modell erős GPU-n fut.
A modell kvantálása csökkentheti a memóriaigényt, és lehetővé teheti a működést elérhetőbb hardveren. Egyszerűbb belső lekérdezéseknél ez praktikus megoldás lehet, szakmai, jogi vagy pénzügyi kimeneteknél viszont a minőséget is figyelned kell. A gyorsabb válasznak korlátozott az értéke, ha a rendszer rosszabbul kezeli a részleteket, vagy ismételt használat során kevésbé lesz stabil.
Mekkora modellre van valóban szükséged, milyen hosszúak lesznek a bemenetek, hányan fogják egyszerre használni a rendszert, és mekkora válaszidő kényelmes még a munkához? Ezek nélkül a válaszok nélkül vakon választasz hardvert.
Az éles üzemben futó ügynöknek ugyanúgy szüksége van felügyeletre, mint bármely más vállalati alkalmazásnak – csak itt még fontosabb az egyes lépések nyomon követése. Egyetlen felhasználói kérés dokumentumkeresést, belső rendszerhívást, eredményértelmezést és válaszösszeállítást is elindíthat. Ha az eredmény nem felel meg a várakozásoknak, a cégnek vissza kell tudnia követni, hol keletkezett a probléma.
Technikai szinten elsősorban a válaszidőt és az áteresztőképességet figyelik, mert ezeket érzékelik leggyorsabban a felhasználók. Éles üzemben azonban ugyanilyen fontos tudni, mennyire terhelt a GPU, mennyi memóriát fogyaszt a rendszer, és hogy a hibák a modellben, a csatlakozókban vagy a dokumentumkeresésben jelentkeznek-e. Összetettebb ügynököknél ezért rendkívül értékesek a trace logok, vagyis az egyes lépések részletes naplói.
A felügyelet gazdasági oldala ugyanolyan fontos, mint a technikai, mert folyamatos metrikák nélkül a cég nem látja, mennyibe kerül valójában az ügynök üzemeltetése. A felhőben a költségek a modellhasználat és a feldolgozott kérések mennyisége szerint változnak, saját infrastruktúra esetén pedig az a döntő, mennyire van kihasználva a beszerzett hardver, és mekkora tartalék áll rendelkezésre a csúcsidőszakokra. Csak ezekből az adatokból állapítható meg, hogy a rendszernek nagyobb kapacitásra, jobb optimalizálásra vagy egyszerűbb üzemeltetési modellre van-e szüksége.
Éles környezetben a vállalati ügynök gyakran olyan információkkal dolgozik, amelyeknek csak meghatározott szerepkörök vagy csapatok számára szabad elérhetőnek lenniük. Ha például szerződéses vagy árazási anyagokból merít, ugyanazokat a szabályokat kell betartania, mint egy munkatársnak, aki manuálisan dolgozna velük. A jogosultságok hibája ilyenkor nem csupán technikai apróság, hanem közvetlen biztonsági kockázat.
A tudásalapú asszisztenseknél az alapelv egyszerű: az ügynök nem adhat választ olyan dokumentum alapján, amelyet az adott felhasználó maga nem nyithatna meg. Ezért az identitás- és hozzáférés-kezelésnek már a tervezés részévé kell válnia a kezdetektől, nem pedig utólagos módosításként a demó után. A gyakorlatban az is meghatározó, hogy a rendszer képes-e visszamenőleg megmutatni, milyen forrásból származott a válasz, és kinek volt az adott pillanatban jogosultsága hozzáférni.
Még érzékenyebb a helyzet az olyan ügynöknél, amelyek műveleteket is indíthatnak. Az ügyfélnek szánt válasz előkészítése vagy egy rendelés módosítási javaslata megtörténhet automatikusan, de maga a kiküldés vagy a vállalati rendszerbe való beavatkozás gyakran már emberi jóváhagyást igényel. Egy éles üzemben futó ügynöknek ezért egyértelműen meghatározott határvonalra van szüksége az ajánlás, a javaslat és a tényleges műveletvégrehajtás között.
A demót érdemes olyan folyamatnál indítani, ahol hasonló munka ismétlődik, és az eredmény észszerűen mérhető. A gyakorlatban ez gyakran az ügyfélszolgálat, mivel hasonló kérdésekkel dolgozik, és meglévő dokumentációra támaszkodik. Hasonlóan jól működhet egy belső tudásbázis vagy üzleti anyagok előkészítése, ha egyértelmű, hogy a munka melyik részét kell az ügynöknek felgyorsítania, és mi alapján mérhető a siker.
A konkrét forgatókönyv tisztázása után kerül csak sor a modell, az adatbázis és a hardver kiválasztására. A demónál fontosabb megtudni, hogyan viselkedik az ügynök valós munkahelyi környezetben, mint azonnal az egész cég számára megtervezni az infrastruktúrát. Éppen ezért éri meg egy kisebb, jól körülhatárolt felhasználási esettel kezdeni, amelyet valós kérdéseken lehet tesztelni, majd fokozatosan bővíteni.
A tesztkészletnek többet kell tartalmaznia, mint olyan bemutatókérdéseket, amelyeket úgy állítottak össze, hogy az ügynök jól mutasson. Első lépésben elegendőek lehetnek anonimizált vagy szintetikus adatok, de a demónak minél hamarabb valós, reprezentatív vállalati anyagokkal is dolgoznia kell. Csak ezeken derül ki, hogyan boldogul a rendszer hiányos feladatmeghatározással, egy dokumentum régebbi verziójával, következetlen terminológiával, vagy olyan helyzettel, amikor inkább be kellene vallania a bizonytalanságot, ahelyett hogy meggyőző, de hibás választ adna.
Már a demó során érdemes mérni a válaszidőt a minőséggel és a helyes forrás-visszakeresés képességével együtt. Ugyanilyen fontos figyelni, hogy az emberek tényleg használják-e az eszközt, vagy az első kipróbálás után megkerülik. Ha a demó megállja a helyét, az éles üzem tervezésénél már a várható terhelést, az adatkezelési szabályokat, a biztonságot és az ügynök jövőbeli, a cég igényeihez igazodó finomhangolásának módját is meg kell oldani.
Az AI-ügynökök felgyorsíthatják a cégek információkezelését és az ismétlődő feladatok elvégzését, valódi hasznuk azonban csak a mindennapi üzemben mutatkozik meg. Fontos, hogy az emberek tényleg használják az eszközt, a válaszok kevésbé pontos kérdések esetén is megállják a helyüket, az infrastruktúra pedig csúcsidőben is érezhető válaszidőromlás nélkül bírja a terhelést. A tesztfázis segít igazolni egy adott forgatókönyv hasznosságát. Az éles üzem viszont már robusztusabb infrastruktúrát, hozzáférés-kezelést, monitoringot, változáskezelési tesztelést és egyértelmű felelősségi köröket igényel az egész rendszerre vonatkozóan. Egy jól megtervezett ügynök konkrét forgatókönyvvel indul, realisztikus teszttel folytatódik, és csak ezután kerül sor az infrastruktúráról szóló döntésre.
A technikai alap kiválasztásánál a legfontosabb, hogy ismerd a terhelést, az adatokat és a várható üzemeltetési igényeket. Más konfigurációra van szüksége egy fejlesztőcsapatnak, másra egy belső demónak, és megint másra egy több részleget kiszolgáló éles rendszernek. Az a cég, amelyik időben felismeri ezeket a különbségeket, elkerüli mind az alulméretezett megoldást, mind a feleslegesen drága, kihasználatlan kapacitásvásárlást.
A tesztfázis célja annak kiderítése, hogy az ügynök jobban megold-e egy adott problémát, mint az eddigi módszer. Az éles üzem nagyobb felelősséggel és magasabb felhasználói elvárásokkal jár – az ügynök teszteszközből mindennap elérhető szolgáltatássá válik, amelynek egyszerre több kérést kell kezelnie, aktuális adatokkal kell dolgoznia, és csúcsidőben is kiszámítható viselkedést kell mutatnia.
Az AI-ügynököknél a teljesítmény nehezen ítélhető meg pusztán a videokártya márkája vagy egyetlen konfigurációs paraméter alapján. A lassulás gyakran nem a GPU-ban keresendő – már a dokumentumok keresésekor vagy a fájlok elérésekor is keletkezhet. Az adatbázis, a tárhely, a CPU és a hálózati réteg mind befolyásolja, hogy a kérdéstől a válaszig tartó teljes útvonal mennyire lesz gyors.
Egy ügyfélnek szánt válasz előkészítése vagy egy rendelés módosítási javaslata történhet automatikusan, de a tényleges kiküldés vagy a vállalati rendszerbe való beavatkozás már gyakran emberi jóváhagyást igényel. Ezért az éles üzemben futó ügynöknek egyértelműen meghatározott határvonalra van szüksége az ajánlás, a javaslat és a tényleges művelet végrehajtása között.
Egyetlen felhasználói kérés dokumentumkeresést, belső rendszerhívást, eredményértelmezést és válaszösszeállítást is elindíthat. Ha az eredmény nem felel meg az elvárásoknak, a cégnek vissza kell tudnia követni, hol keletkezett a probléma. Folyamatos metrikák nélkül ráadásul nem látod, mennyibe is kerül valójában az ügynök üzemeltetése.
A RAG (belső tudásbázissal való munka) egy olyan forgatókönyv, amelyben az ügynök először kikeresi a vállalati dokumentumok releváns részeit, és csak ezután állítja össze belőlük a választ. A dokumentumokat használat előtt elő kell készíteni a kereséshez – a rendszer értelmes részekre bontja őket, jelentésüket keresésre alkalmas formába alakítja, és eltárolja őket a gyors visszakeresés érdekében. Ez megnöveli a tárhely, az adatbázis és a hálózati réteg iránti igényeket.

Peter Vnuk
A technológia egyszerre munka és szórakozás számomra - leginkább az okostelefonok, laptopok, audio, mesterséges intelligencia és minden más hi-tech dolog érdekel. Szeretem áttekinteni a híreket, követni a futurisztikus trendeket és megjósolni a technológia következő fejleményeit. Lenyűgöznek a sci-fik és a jövő világáról szóló víziók, amelyek gyakran valódi technológiai fejlesztéseket inspirálnak. Szakmailag is foglalkozom videojátékokkal és a játékiparral. Amikor nem dolgozom, szeretek kikapcsolódni egy jó játékkal, egy jó sörrel, vagy tech-mémek készítésével a Facebookon.