A válasz lényege egyszerű: a robusztus AI-automatizálási rendszerek újrahasznosítható mintázatokra szorulnak, amelyek kezelik az állapotot, a hibákat és a változásokat. Ez jelenti a valódi kapcsolatot az objektumorientált szoftverfejlesztés klasszikus tervezési mintáihoz. Az elv ma is helytálló, mert az AI-rendszereknek ugyanazokkal a nehéz feladatokkal kell megküzdeniük, csak ennél sokkal több összetevővel.
Újra és újra visszatérünk ehhez, mert számos AI-projekt ugyanazok az alapvető okokból bukik el. Nincsenek tisztán felépítve egy hiba után. Véletlenül ismételgetik a munkát. Elrejtik a történteket. És akkor is összevisszasá válnak, ha egy feladat tízzel bővül.
Egy stabil rendszerhez általában egyszerre tíz ilyen mintázatra van szükség, vagy ahhoz nagyon közeli mennyiségre. Mindegyik máshogy oldja meg a feladat egy-egy részét. Együttesen teszik könnyebben kezelhetővé a tesztelést és a magyarázhatóságot, valamint kevésbé sérülékennyé teszik a rendszert, ha valamelyik alkatrész meghibásodik.
Az első minta az orkestrátor. Egyetlen szolgáltatásnak vagy munkafolyamat-motornak kellene irányítania a lépéseket. Dönteni arról, mi jön legközelebb, és mi történik hiba esetén. Enélkül a középpont nélkül az automatizálás szétszórt hívások gombócává válik.
A második minta a tiszta határok a modell, a szabályok és az eszközök között. A modell ne vegye birtokába az összes döntést. Az üzleti szabályokat ahol csak lehet, tartsuk kívül a prompton. Az eszközöknek egyértelmű, egyetlen dolgot kell ellátniuk, például adatolvasást, adatírást vagy egy jóváhagyás kiküldését.
A harmadik minta az ideupotens műveletek. Ha ugyanaz a művelet kétszer is lefut, az eredménynek mindenképpen biztonságban kell maradnia. Ez különösen fontos, ha időtúllépés vagy összeomlás után újrapróbálkozik a rendszer. Idempotencia hiányában előfordulhat, hogy a rendszer két e-mailt küld, két rekordot hoz létre, vagy kétszer számláz.
A negyedik minta a pillanatfelvételek készítése (checkpointing). A rendszernek el kell mentenie az aktuális állását a főbb lépések után. Ha a munka megszakad, ismerős pontról tudja folytatni. Ez sokkal jobb, mint nulláról kezdeni, és abban bízkodni, hogy az modell majd emlékszik.
Az ötödik minta a kompenzáció. Vannak olyan műveletek, amelyeket szigorú értelemben nem lehet visszavonni, de kompenzálni lehet őket. Ha egy lépés hibás állapotot hoz létre, egy későbbi lépésnek minél inkább semlegesítenie kell az üzleti hatást. Ez gyakran előfordul a hosszabb munkafolyamatokban, amelyek több szolgáltatáson átívelnek.
A hatodik minta a emberi ellenőrzés a folyamat szélén. A rendszernek bizonytalan, kockázatos vagy költséges eseteket kell emberhez továbbítania. Ez nem gyengeség jele. Ez egy vezérlési pont. Az emberi áttekintés gyakran a legelegánsabb megoldás arra, amikor az AI-kimenet bizalma alacsony, vagy szabályozási kockázatról van szó.
A hetedik minta a típusos bemenetek és kimenetek. Pusztán promptok használata túl laza a komoly automatizáláshoz. A rendszernek előre meghatározott mezőkre, formátumokra és ellenőrzött eredményekre van szüksége. Ez csökkenti a kilengéseket, és segíti a kódokat elkapni a hibás kimenetet, mielőtt tovább terjedne.
A nyolcadik minta az eseményvezérelt tervezés. Az AI-rendszereknek gyakran eseményekre kell reagálniuk, nem pedig csupán előre rögzített ütemezés szerint. Egy új ügy, egy módosított rekord vagy egy meghiúsult feladat is elindíthatja a következő lépést. Így a rendszer könnyebben skálázható és könnyebben átlátható.
A kilencedik minta a megfigyelhetőség. Minden fontos lépésnek nyomot kell hagynia. A naplófájlok, a mutatók és a futtatási azonosítók segítenek a csapatoknak látni, mit végzett el a rendszer. AI-automatizálás esetén ez nem luxuscikk. Ez az egyetlen módja annak, hogy utólag megmagyarázzuk a rendszer viselkedését.
A tizedik minta a moduláris promptok és szabályzatok. A prompt szövegét, az eszközkövetelményeket és a jóváhagyási szabályokat nem szabad egyetlen hosszú tömbben tartani. Szét kell őket bontani, hogy bármelyik rész módosítható legyen anélkül, hogy a többit tönkretenné. Így a rendszer nem válik rideggé minden egyes üzleti változáskor.
Egy pontnál szeretnék most megállni. Nem minden AI-feladathoz szükséges mind a tíz minta teljes körű alkalmazása. Egy kisebb, belső munkafolyamathoz talán csak néhányra van szükség. Amint azonban a feladat pénzügyi tranzakciókat, ügyfeleket, jóváhagyási folyamatokat vagy adatbejegyzéseket érint, a mintázatkészlet egyre fontosabbá válik.
Éppen itt mutatkozik meg újra a régi tervezési-minta-elv ereje. Klasszikus objektumorientált értelemben a tervezési minta egy visszatérő problémára adott újrahasznosítható megoldás. AI-automatizálásban ezek a visszatérő problémák ma már az orkesztráció, az újrapróbálkozások, a biztonság és a nyomkövethetőség. A név kevésbé változik, mint maga az igény rá.
Van azonban egy határ is, amit érdemes őszintén kimondani. Egyetlen minta sem képes önmagában erőt adni egy gyenge folyamatnak. Ha az üzleti szabályok homályosak, vagy az adatminőség gyenge, a rendszer így is bajba kerül. A minták azt segítik, hogy a rendszer hibáit jobb módon kezelje. Nem szüntetik meg a nehéz döntések szükségességét.
Ezért az EuroOp LLC az AI-automatizálást elsődlegesen tervezési problémaként kezeli, nem pedig modellszintűként. A modell számít, de körülötte épülő rendszer ugyanannyit. A legbiztonságosabb rendszerek általában azok, amelyek a megfelelő helyeken „unalmasan” működnek. Kevesebbszer ismételgetnek. Nyomon követhetően mutatják a lépéseiket. Teret hagynak az emberek számára, hogy közbeléphessenek.
Az EuroOp Insights számára ez a gyakorlati tanulság, amelyhez folyamatosan visszatérünk: egy bevált kutató-fejlesztési minta, egy konkrét tanulság az EuroOp termékei mögötti fejlesztési folyamatból.