Applied AI
Mesterséges intelligencia a vállalati működésben, projektmenedzsment-fegyelemmel: felméréstől az éles üzemen át az átadásig.
Kérjen felméréstMit jelent az „applied AI” a gyakorlatban
Az alkalmazott mesterséges intelligencia („applied AI”) nem kutatási terület és nem modellfejlesztés. Arról szól, hogy egy meglévő nyelvi modellt beillesztünk egy konkrét munkafolyamatba úgy, hogy a folyamat mérhetően gyorsabb, olcsóbb vagy pontosabb legyen. A modellt nem mi tanítjuk: kész modellel dolgozunk, és azt építjük köré, amitől a modell használhatóvá válik.
A munka java része ezért nem a modellnél van. Ott van, ahol egy IT-projektben mindig is lenni szokott: az adatok minőségénél, a jogosultságoknál, az integrációnál, a tesztelésnél és az üzemeltetésnél. Egy belső dokumentumkereső esetében a modell kiválasztása néhány nap munka, a jogosultsági szabályok tisztázása viszont hetekbe telhet. Az arány ritkán fordul meg.
Ez a szemlélet magyarázza, miért ugyanazok a szabályok érvényesek rá, mint egy SAP-bevezetésre vagy egy adatmigrációra. Kell hozzá hatókör, mérföldkövek, elfogadási kritérium, tesztterv, felelős gazda az üzleti oldalon és átadási terv. Ha ezek hiányoznak, a technológia újdonsága semmit nem ment meg.
Amiről nem szól
- Saját alapmodell tanítása a nulláról
- Mindent átfogó „AI-stratégia” konkrét folyamat nélkül
- Chatbot a honlapra, mert a versenytársnak is van
- Olyan bemutató, ami válogatott példákon működik, éles adaton nem
Amiről szól
- Egy fájdalmas, ismétlődő folyamat kiválasztása és megmérése
- A legkisebb működő megoldás, ami ezt a folyamatot javítja
- Számokkal alátámasztott döntés arról, megy-e élesbe
- Üzemeltethető rendszer, amit az Önök csapata is ért
Miért akad el a legtöbb AI-pilot
A kísérleti szakasz („pilot”) ritkán technológiai okból hal el. Sokkal gyakoribb, hogy a bemutató jól sikerül, aztán senki nem tudja megmondani, mi legyen a következő lépés. Öt visszatérő mintát látok, és mindegyikre van bevált projektmenedzsment-válasz.
1. Nincs mihez mérni
Ha a pilot indulásakor nem tudjuk, hogy egy ajánlatkérés feldolgozása ma hány percbe és hány emberi kézbe kerül, akkor a végén sem lesz mihez hasonlítani. A lelkesedés nem mérőszám.
A PM-válasz: a jelenlegi állapot felmérése az első héten megtörténik, és az elfogadási kritériumot még a fejlesztés előtt aláírjuk.
2. A bemutató adata nem az éles adat
A válogatott mintadokumentumokon minden szépen működik. Az éles állományban ott vannak a szkennelt szerződések, a rossz minőségű táblázatok, a három különböző elnevezési konvenció és a hiányzó mezők.
A PM-válasz: a pilot már az első naptól valódi, anonimizált éles adaton fut, nem tisztított mintán.
3. Nincs kiértékelési módszer
A nyelvi modell néha téved, és magabiztosan teszi. Ha nincs rögzített kérdés-válasz készlet, amin minden változtatás után újramérünk, akkor minden finomítás hitkérdés marad. Ez a kiértékelő készlet („eval set”) a projekt legfontosabb és leggyakrabban kihagyott eleme.
A PM-válasz: 50 és 200 közötti valós kérdésből álló készletet állítunk össze az üzleti gazdával, és minden verzióváltásnál lefuttatjuk.
4. A biztonsági és jogi kérdéseket a végére hagyják
Az adatvédelmi tisztviselő vagy az információbiztonsági vezető jellemzően akkor kerül képbe, amikor a rendszer már majdnem kész. Ilyenkor derül ki, hogy egy adatkör nem hagyhatja el az országot, vagy hogy a jogosultságokat dokumentumszinten kell érvényesíteni.
A PM-válasz: az érintettek a felmérés résztvevői, nem a jóváhagyás akadályai. Az adatáramlás térképe a pilot előtt elkészül.
5. Senki nem veszi át
A sikeres pilot után a rendszer a tanácsadó gépén marad. Nincs üzemeltetési leírás, nincs gazdája a költségkeretnek, és fél év múlva már senki nem meri hozzányúlni.
A PM-válasz: az átadás nem záró esemény, hanem az első naptól tervezett szakasz, dokumentációval és közös üzemeltetési időszakkal.
Hogyan dolgozom: négy szakasz
Minden szakasz külön dönthető és külön árazott. Bármelyik végén ki lehet szállni, és a kimenet akkor is az Önöké marad. Ez a felépítés azért fontos, mert így nem kell egyben megvenni egy olyan projektet, amiről még nem tudni, megéri-e.
Felmérés
2–3 hét
Végigjárjuk a szóba jöhető folyamatokat, és megnézzük, hol van valódi ismétlődő teher. Rögzítjük a mai időráfordítást és hibaarányt, feltérképezzük az adatforrásokat, és tisztázzuk az adatvédelmi kereteket. A kimenet egy rangsorolt lista arról, mit érdemes elsőként megcsinálni, és mit nem érdemes egyáltalán.
Pilot
6–8 hét
Egyetlen folyamatra épül a legkisebb működő megoldás, valódi adaton, valódi felhasználókkal. Elkészül a kiértékelő készlet, és mérjük a válaszminőséget, a futásidőt és a költséget. A kimenet egy futó rendszer és egy döntési anyag: számokkal alátámasztva megy-e élesbe.
Éles üzem
8–12 hét
A pilotból üzemeltethető rendszer lesz: integráció a meglévő rendszerekhez, jogosultságok, naplózás, mentés, monitoring és riasztások. Megírjuk az üzemeltetési leírást, és felkészítjük a felhasználókat. Itt derül ki, hogy a folyamat körüli munkautasításokat is hozzá kell igazítani.
Átadás
4–6 hét
Az Önök csapata átveszi az üzemeltetést, én pedig egy ideig még mögötte állok. Közös hibakezelés, a kiértékelő készlet karbantartásának betanítása, a költségkeret gazdájának kijelölése. A cél az, hogy a rendszer akkor is működjön, amikor én már nem vagyok a projektben.
Képességterületek
Négy területen dolgozom rendszeresen. Mindegyiknél az a kérdés, hogy a folyamat elviseli-e a gépi tévedést, és hogy hol kell emberi jóváhagyási pontot beépíteni.
Dokumentumfeldolgozás és belső keresés
A vállalati tudás jellemzően szétszórva él: szerződésekben, szabályzatokban, régi levelezésben, projektdokumentációban. A visszakeresésen alapuló válaszadás (angolul „retrieval-augmented generation”, röviden RAG) azt jelenti, hogy a modell először megkeresi a saját dokumentumaink között a releváns részleteket, és csak azokból fogalmaz választ. Ez két dolgot ad: a válasz forrásra hivatkozik, és a modell nem a saját emlékezetéből találgat.
A tipikus felhasználás egy belső kérdés-válasz felület az ügyfélszolgálatnak, a műszaki csapatnak vagy a jogi területnek. A nehézségek nem a modellnél kezdődnek: a dokumentumok darabolása, a jogosultságok dokumentumszintű érvényesítése és a forrásmegjelölés helyessége viszi el az időt.
Automatizált riportálás és döntéstámogatás
Sok szervezetben hetente több munkanapnyi kézi munka megy el arra, hogy valaki több rendszerből adatot gyűjtsön, összefésülje és értelmezze. Ez a rész jól gépesíthető: az adatgyűjtés és a számolás hagyományos kóddal, a szöveges összefoglaló pedig nyelvi modellel. A számokat nem a modell állítja elő, csak megfogalmazza, ami mögöttük van.
Ez a felállás azért biztonságos, mert a modell nem számol, tehát nincs miben tévednie a számadatok szintjén. A riport kiküldése ütemezetten megy oda, ahol a csapat amúgy is dolgozik, legyen az levelezés, belső csevegőrendszer vagy irányítópult.
Monitoring és üzemeltetés
Az AI-rendszer nem attól él, hogy elkészült. A modellek verziói cserélődnek, az árazás változik, az adatállomány bővül, és a válaszminőség ettől észrevétlenül romolhat. Ezért kell mérni: futásidőt, hibaarányt, költséget, és rendszeres időközönként újrafuttatni a kiértékelő készletet.
Ugyanez vonatkozik a költségekre. Egy rosszul megírt lekérdezés vagy egy elszabadult ismétlés komoly számlát tud okozni, ha nincs rá riasztás. Ez klasszikus üzemeltetési feladat, csak a mérőszámok újak.
Saját szerver vagy felhő
A saját szerveres futtatás („on-premise”) mellett az adatérzékenység szól: az adat nem hagyja el a szervezetet, és a költség kiszámítható. A nyílt súlyú modellek, vagyis azok, amelyek paraméterei szabadon letölthetők, és így saját gépen is futtathatók, ma már elérik azt a szintet, ami sok belső feladathoz elég. Cserébe hardvert, üzemeltetést és frissítési fegyelmet kér.
A felhős modellek jellemzően pontosabbak, nulla üzemeltetéssel indulnak, viszont használatarányos költséggel és külső adatfeldolgozói viszonnyal járnak. A kettő nem zárja ki egymást: gyakori, hogy az érzékeny adatkörök saját szerveren maradnak, a többi pedig felhőbe kerül. A döntés a felmérés része, nem előfeltevés.
A bizonyíték: saját, futó rendszerek
Az AI-tanácsadás piacán nehéz megkülönböztetni azt, aki már üzemeltetett ilyen rendszert, attól, aki csak beszél róla. Nálam ez ellenőrizhető: több éve saját szerveren futtatok AI-alapú rendszereket, ütemezetten, éles adatokon, valódi üzemeltetési következményekkel.
Fontos pontosítás: az alább felsorolt rendszerek a saját infrastruktúrámon futnak, és nem ügyfélreferenciák. Azt bizonyítják, hogy a technológiát nem bemutatókból ismerem, hanem onnan, ahol hétfő reggel meg kell javítani, ha elromlott.
Ütemezett elemzőrendszer piaci adatokra
Munkanapokon futó rendszer 15 elemű figyelőlistával, több adatforrásból. Egy nyelvi modell fordítja üzleti nyelvre a technikai jelzéseket, a riasztások pedig a csevegőrendszerbe érkeznek. Ez tanított meg arra, mennyire nem mindegy, hogy egy külső adatforrás hibáját a rendszer elnyeli vagy jelzi.
Heti piaci felderítő ügynök
Európai hatókörű felderítés öt országban, saját irányítópulttal és több mint 170 nyilvántartott céggel. Heti ütemezéssel fut, és minden körben a korábbi adatbázisra épít. Jó példa arra, hogyan kell egy ismétlődő ügynökfuttatást úgy megírni, hogy ne írja felül azt, amit a felhasználó kézzel rögzített.
Napi levélösszefoglaló
Reggeli automatikus összefoglaló a beérkező levelekről, szűrési szabályokkal és emberi jóváhagyási ponttal. Kicsi rendszer, de pontosan azt mutatja meg, hogyan kell egy osztályozási feladatnál visszajelzési hurkot építeni ahelyett, hogy vakon bíznánk a gépben.
Kódbázis-átvizsgáló ügynökcsapat
Heti futású, négy különböző szerepkörből (fejlesztés, tesztelés, biztonság, architektúra) véleményező rendszer, eddig 15 kódbázis átnézésével. A tanulság az, hogy több, szűkebb szerepkörű ügynök megbízhatóbb eredményt ad, mint egyetlen mindent tudó.
On-premise dokumentumkereső termék
Saját szerveren futó, visszakeresésen alapuló kérdés-válasz rendszer, amely a Cognexa néven önálló termékké érett. Ez adta a legtöbb tapasztalatot a dokumentumdarabolás, a forrásmegjelölés és a válaszminőség méréséről.
Applied AI kézikönyv
Belső használatra írt, 37 ezer szavas szakmai kézikönyv 13 fejezetben, tapasztalt IT-projektmenedzsereknek. Egy teljes fejezet a modellfuttató réteg cseréjéről szól: saját mérésen alapuló döntés arról, hogy a váltás megérte-e. A hűségmutató, vagyis az, hogy a válasz mennyire marad a forrásdokumentum tartalmánál, ebben a mérésben közel húsz százalékkal javult (0,656-ról 0,783-ra).
A technikai részletek, a döntési naplók és a mérési eredmények a simonprojects.eu testvéroldalon olvashatók. Az ott bemutatott rendszerek adják a szakmai fedezetet ahhoz, amit itt szolgáltatásként kínálok.
Kinek való ez, és kinek nem
Az őszinte szűrés mindkettőnknek olcsóbb, mint egy félbehagyott projekt. Ezért érdemes az elején tisztázni, hogy a helyzetük illik-e ehhez a munkamódszerhez.
Valószínűleg jó illeszkedés
- Van egy konkrét, ismétlődő folyamat, ami ma emberi időt eszik
- A folyamatnak van gazdája, aki el tudja dönteni, hogy egy válasz jó-e
- Az adatok léteznek, még ha rendezetlenül is
- Elfogadják, hogy a mérés a projekt része, nem opció
- Középvállalati vagy növekvő szervezet, ahol a döntés két megbeszélésbe fér bele
Valószínűleg nem
- A cél a bejelentés, nem a működő rendszer
- Nincs kijelölt üzleti gazda, csak felső vezetői szándék
- Az elvárás a hibátlan, ellenőrzés nélküli gépi döntés
- A várt megtérülés jövő negyedévre esedékes
- Alapmodell-fejlesztés vagy kutatási feladat a kérés
Ha a „Valószínűleg nem” listából ismerős valami, attól még érdemes beszélnünk. A felmérés éppen arra való, hogy ezt kimondjuk, mielőtt bárki fejlesztésre költene.
Miért éppen egy IT-projektmenedzser
Húsz évnél hosszabb iparági és tizenöt évnél hosszabb IT-projektmenedzsment-tapasztalat áll mögöttem, jórészt energetikai és közműves környezetben. SAP IS-U bevezetések, felhőmigrációk, cégleválasztások, adatmigrációk és HR-rendszerek bevezetése olyan szervezeteknél, mint az MVM Ügyfélszolgálati Zrt., az E.ON Tiszántúli Áramhálózati Zrt., az OPUS TITÁSZ Zrt., a MOL Nyrt. vagy az Allianz Hungária Zrt.
Ezekben a programokban a technológia sosem a nehéz rész volt. A nehéz rész a hatókörkezelés, az érintettek összehangolása, az adatminőség és az átadás. Az AI-projektek pontosan ugyanezeken buknak el, csak most gyorsabban és látványosabban. Az érték, amit hozok, ennek a két világnak a metszete: húsz év megvalósítási fegyelem, és mellette olyan AI-rendszerek, amelyek nem bemutatóként, hanem üzemben léteznek.
Bővebben a szakmai háttérről a Rólam oldalon, a klasszikus projektmenedzsment- és automatizálási szolgáltatásokról pedig a Szolgáltatások oldalon olvashat.
Gyakori kérdések
Amit a felmérés előtt a legtöbben megkérdeznek
A felmérés 2–3 hét, a pilot ezután 6–8 hét. A pilot végén nem prezentáció van, hanem egy futó rendszer és egy mérési jegyzőkönyv, amiből eldönthető, megy-e élesbe. Ha a felmérés azt hozza ki, hogy a folyamat AI nélkül is javítható, ezt megmondom, és ott le is állunk.
Nem. A nyílt súlyú modellek ma már saját szerveren is elfutnak, és sok belső feladatnál elég jók. A felhős modellek jellemzően pontosabbak és nulla üzemeltetést igényelnek. A választás adatérzékenységi és költségkérdés, a felmérésben döntjük el, nem előre.
Az üzemeltetéshez nem kell AI-szakértő, egy rendszergazdai szintű csapat elég. Ami viszont kell: egy üzleti oldali gazdája a folyamatnak, aki el tudja dönteni, hogy egy adott válasz jó-e vagy sem. Ő az, aki a kiértékelő készletet validálja, és nélküle nincs mérhető minőség.
A modellhasználat a legtöbb belső folyamatnál a kisebb tétel. A költség java a felmérésben, az adat-előkészítésben és az integrációban van, vagyis emberi munkában. Ezért adok szakaszonként külön árajánlatot: a felmérés után Önök már tudják, mibe kerül a pilot, a pilot után pedig azt, mibe kerül az éles üzem.
Az, hogy néha téved, nem hiba, hanem a technológia tulajdonsága. A kérdés az, hogy a folyamat elviseli-e. Ezért minden éles rendszernél forrásmegjelölés, mérhető hibaarány és emberi jóváhagyási pont épül be ott, ahol a tévedés drága. Amelyik folyamat ezt nem bírja el, azt nem is automatizáljuk.
Elsősorban projektvezetést vállalok és architektúra-döntéseket hozok, a megvalósításba pedig az Önök csapata vagy egy behozott fejlesztő kapcsolódik be. Az én szerepem, hogy a döntések megalapozottak legyenek, a szállítás követhető maradjon, és a végén az Önök csapatához kerüljön a rendszer.
Van egy folyamat, amit gépesítene?
Kezdjük egy rövid beszélgetéssel arról, hol megy el ma a legtöbb idő. Ha kiderül, hogy AI nélkül is megoldható, azt is megmondom.
KapcsolatfelvételVagy írjon közvetlenül: info[ at]prioconsulting.hu