Három réteg
Az automatizáció, az AI és az ügynök nem ugyanaz
A három szó sokszor egymás szinonimájaként megy, pedig más munkát végeznek. Az automatizáció akkor jó, amikor a lépések sorrendje előre ismert. Adatot kér le, státuszt ír át, levelet küld, fájlt mozgat. Ehhez nem kell intelligencia, sőt jobban is jár az ember, ha nincs benne, mert a kiszámítható rendszer hibája is kiszámítható.
Az AI ott kerül a képbe, ahol a bemenet bizonytalan. Szabad szöveg, beszkennelt dokumentum, ugyanaz a kérés ötféle megfogalmazásban. A nyelvi modell ezt a bizonytalanságot oldja fel, és utána már rendezett adat megy tovább a folyamatban.
Az ügynök pedig akkor indokolt, ha nemcsak a bemenet bizonytalan, hanem a következő lépés is. Amikor a helyzet dönti el, hogy most adatot kell kérni, kérdezni kell vagy továbbküldeni az ügyet, és ezt előre nem lehet leírni. Ez a legdrágább réteg, ezért a legkisebb felületen érdemes használni.
A beérkező ajánlatkéréseknél végül ez a három réteg szépen szétvált. Nálunk a levelet az AI értelmezte, az ismert szabályokat sima automatizáció vitte, és mindössze két esetág maradt, ahol a rendszernek tényleg mérlegelnie kellett. Nekik ez a verzió fele annyiba került, mint az eredeti ötlet, és azóta is fut.
A három réteg költsége is nagyon eltér. Egy sima munkafolyamat megépítése napokban mérhető, és utána évekig megy magától. Értelmező lépés mellé viszont már kell tesztkészlet, mert a modell válasza változhat. A szabadon mozgó ügynök pedig folyamatos felügyeletet kíván, hiszen minden új helyzetben saját döntést hoz. Ezért éri meg a felső réteget a lehető legkisebb felületre szorítani, és mindent lejjebb vinni, amit csak lehet.
Négy kérdés
A döntést négy kérdés hozza meg
Az első kérdés az, hogy leírható-e előre az útvonal. Ha a folyamat minden elágazását fel tudjuk rajzolni egy papírra, akkor hagyományos munkafolyamat kell, és kész.
A második az, hogy van-e a folyamatban értelmezendő információ. Ha valahol szabad szöveget, képet vagy vegyes formátumú dokumentumot kell megérteni, oda kerül az AI, de csak oda.
A harmadik az, hogy a következő lépést a helyzet alapján kell-e megválasztani. Igen esetén jöhet az ügynök, viszont szűk hatáskörrel, konkrét eszközökkel és leírt határokkal.
A negyedik kérdés írja felül az összes előzőt. Mi történik akkor, ha a rendszer téved. Ebből jön ki, mennyi kontroll kell köré, és sokszor ez dönti el, hogy egyáltalán érdemes-e belevágni.
Ezt a négy kérdést egy délelőtt alatt végig lehet venni egy folyamatra, és utána sokkal olcsóbb beszélgetés jön az eszközökről. A legtöbb cégnél fordítva megy, előbb választanak platformot, és utána keresik hozzá a feladatot.
Nálam ez a négy kérdés egy A4-es lapon elfér, és a felmérésen mindig előkerül. A kollégák rendszerint az első kettőnél elbizonytalanodnak, mert kiderül, hogy a folyamat felét senki nem tudja pontról pontra leírni. Ez önmagában hasznos eredmény, hiszen amit senki nem tud leírni, azt gép sem fogja megcsinálni helyettünk.
Bizonytalanság
A bizonytalanság helye adja meg a választ
Nálam ebből egy egyszerű ökölszabály alakult ki. Ha az adat bizonytalan, kell az AI. Amikor az útvonal is bizonytalan, ott kellhet az ügynök. Ha viszont egyik sem bizonytalan, akkor elég az automatizáció, és jobban is jársz vele.
Egy veszprémi kereskedő cégnél ezen a ponton derült ki, hogy a szállítói számlák feldolgozása két külön feladat. A szabványos számla útja az első levéltől a könyvelési tételig teljesen leírható, tehát ott nincs szükség semmilyen modellre. Értelmezést csak a kivételek kívánnak, tehát a jóváírás, a részbeszállítás, a hiányzó rendelésszám meg a furcsa formátum.
Ezért vált ketté a megoldás. Szabványos esetben a folyamat emberi érintés nélkül fut végig, a kivételek pedig egy értelmező lépésen keresztül kerülnek emberi asztalra, előkészített javaslattal. Így a havi számlák nyolcvan százaléka az első ágon fut, és a maradék húsz százalékra megy el a figyelem.
Érdemes külön megnézni azt is, hogy a bizonytalanság állandó marad-e. Egy új partnerkörnél eleinte minden levél máshogy néz ki, fél év múlva viszont már látszanak a minták. Ilyenkor a rendszer nyugodtan egyszerűsíthető, és ami eleinte modellt kívánt, abból később sima szabály lesz. Ezt a felülvizsgálatot évente egyszer érdemes elvégezni.
Hibaköltség
A tévedés ára szabja meg a kontrollt
Ha egy marketing anyag rossz kategóriába kerül, azt valaki átteszi, és nem történt semmi. Ha egy pénzügyi tétel kerül rossz helyre, abból könyvvizsgálói kérdés lesz. Ugyanaz a technológia, két teljesen más kontrollszint.
Alacsony hibaköltségnél bátran lehet engedni a gépet, mintavételes ellenőrzéssel. Magas hibaköltségnél viszont kell a validáció, a korlát, a napló és az emberi jóváhagyás a végén. Ez utóbbi nem a bizalmatlanságról szól, hanem arról, hogy a hiba ára határozza meg, mennyit szabad kockáztatni.
A gyakorlatban ez azt jelenti, hogy ugyanabban a cégben kétféle rendszer él egymás mellett. Az egyik gyors és olcsó, a másik lassabb és drágább, de ellenőrizhető. Aki mindent a második mintájára épít, az feleslegesen fizet, aki mindent az elsőre, az előbb utóbb fizet egy nagyot.
A hibaköltséget nem elég megbecsülni, meg is kell beszélni azzal, aki viseli. Egy pénzügyes kolléga pontosan meg tudja mondani, melyik tévedésből lesz kellemetlen levelezés, és melyikből bírság. Az ő válaszából lesz a kontrollterv, nem a fejlesztő vagy a tanácsadó feltételezéséből.
Tervezés
Az AI a tervezésnél végzi a legfontosabb munkáját
Ennek a munkának a java része nem is a kész rendszerben zajlik, hanem a felmérésen. Amikor leülünk a kollégákkal, és végigvesszük, mi alapján döntenek, akkor derül ki, hogy a szabályok nagy része sehol nincs leírva, csak a fejekben él.
A nyelvi modell itt kiváló segéd. Az interjúk jegyzetéből kibontja az ismétlődő mintákat, feltesz olyan kérdéseket, amiket mi már nem veszünk észre, és szembesíti egymással az ellentmondó válaszokat. Egy HR folyamatnál például ezzel jött elő, hogy három különböző értékhatár él egymás mellett, attól függően, melyik vezető hagyja jóvá.
A tanulság viszont az, hogy ezek a szabályok a kész rendszerben már determinisztikusan futnak. Nincs sok értelme minden egyes esetnél megkérdezni egy modellt arról, hogy szerinte mit jelent ugyanaz a válaszkombináció. Ha egyszer kiderült, akkor az onnantól szabály.
Ebből következik egy gyakorlati sorrend. Először a szabályok feltárása megy, modell segítségével, emberi jóváhagyással. Utána jön a rögzítés, tehát ami kiderült, az dokumentumba kerül. És csak ezután épül bármilyen rendszer. Aki ezt a sorrendet felcseréli, az a saját tisztázatlan működését automatizálja, és gyorsabban fog rossz eredményt kapni.
Költség
A valódi költség nem az API díj
A legtöbb kalkulációban a modellhasználat ára szerepel, és ez a kisebbik tétel. A pénz a tesztelésen, a figyelésen, a kivételkezelésen és a karbantartáson megy el. Egy rendszer, ami havonta kétszer megáll, és minden alkalommal fél napot visz el valakitől, drágább, mint amennyit a modell valaha felszámol.
Ezért is nyer rendszerint az egyszerűbb felépítés. Kevesebb mozgó alkatrész, kevesebb hibalehetőség, könnyebb hibakeresés. Amikor egy négy lépéses munkafolyamat elakad, fél óra alatt kiderül, hol. Egy szabadon mozgó ügynöknél viszont előbb azt kell kitalálni, mit is akart csinálni.
A kérdés tehát nem az, hogy mennyi AI fér bele, hanem az, hogy mennyi AI szükséges. Majdnem mindig az a legegyszerűbb rendszer nyer, ami megbízhatóan elvégzi a feladatot.
A karbantartás kérdését már a tervezéskor fel kell tenni. Ki veszi észre, ha a rendszer elkezd rosszul működni, és miből veszi észre. Ha erre nincs válasz, akkor a megoldás az első komolyabb változásnál csendben elhal, és fél év múlva derül ki, hogy már senki nem használja.
A karbantartásnak gazdája is kell, nem csak terve. Ha a rendszert senki nem vallja magáénak, akkor az első változás után árván marad. A legjobb, ha abból a csapatból kerül ki a gazda, amelyik a folyamatot napi szinten viszi, mert ő veszi észre elsőként, ha a kimenet furcsa lett. Külsős fejlesztő ezt soha nem fogja helyette megtenni.
Gyakorlat
Mit jelent ez egy induló projektben
Amikor egy cég ma AI bevezetést tervez, a legjobb első lépés nem az eszközválasztás. Végig kell venni három vagy négy valódi folyamatot a fenti négy kérdéssel, és megnézni, melyik rétegre van szükség bennük.
A legtöbb esetben az jön ki, hogy a munka nyolcvan százalékát sima automatizáció viszi, tizenöt százalékát egy értelmező lépés, és öt százalék marad az, ahol tényleg ügynök kell. Ez a megoszlás ránézésre csalódás, a működő rendszerek viszont pont így néznek ki.
Az ügynökök érdekesek, a konferenciákon is azokról beszélnek, a cégnél viszont az számít, hogy hétfő reggel működik-e a folyamat. Aki ebből indul ki, annak a rendszere fél év múlva is élni fog.
A mérés ugyanilyen fontos. Minden folyamatnál érdemes rögzíteni, hol tartott indulás előtt, tehát hány óra ment rá hetente, és hány hiba keletkezett. Enélkül fél év múlva senki nem tudja megmondani, hogy a rendszer megérte-e, és a vita a benyomásokról fog szólni, nem a számokról.
Van ennek a szemléletnek egy kellemetlen következménye is. Aki ügynököt ígér a vezetőségnek, az látványosabbat mond, mint aki négy munkafolyamatot meg egy értelmező lépést. A második viszont jövő héten is működni fog, az első pedig jó eséllyel bemutatóig jut, és ott marad. Ezt a különbséget érdemes az első beszélgetésen tisztázni, mert utólag már presztízskérdés lesz belőle.