Mi azt a problémát oldja meg az vállalati mesterséges intelligencia, amikor a modell működik, de a vállalkozás mégsem tudja használni?
Ez a valós próbakő a termelési AI számára. Egy jó modellnek notebookban kevés értéke van, ha nem képes áthaladni az adatvezetékeken, szolgáltatni a előrejelzéseket, és eljutni ahhoz a munkafolyamathoz, ahol az emberek ezeket felhasználják.
A vállalati AI-architektúra arra szolgál, hogy ezt a hézagot bezárja. Meghatározza, hogyan kapcsolódnak össze az adatok, modellek, alkalmazások és infrastruktúrák, így az AI a mindennapi műveleteken belül fut, nem pedig mellettük áll.
A vállalati rendszerek moduláris tervezést igényelnek, mert a méret növekedése különböző helyeken nyomást gyakorol. A tanítás órákig nagy számítási kapacitást igényelhet. Az inferenciának gyors válaszokat kell nyújtania több ezer felhasználó számára. A szabályozás jóváhagyási lépéseket, ellenőrzési naplókat és biztonsági ellenőrzéseket igényelhet. Egy egyetlen, merev rétegcsomag ezekre a szükségletekre rosszul reagál.
A moduláris architektúra ezt úgy oldja meg, hogy a rendszert egyértelmű részekre bontja. Az adatgyűjtés, funkciófeldolgozás, modelltanítás, modellnyilvántartás, kiszolgálás, figyelés és üzleti alkalmazások mindegyike egy feladatot lát el. Definiált interfészen, gyakran API-n keresztül kapcsolódnak, így egy réteg változhat anélkül, hogy az egész rendszernek is változnia kellene vele együtt.
Ez azért fontos, mert a vállalati AI egy élő rendszer. Az üzleti probléma ugyanaz marad, de körülötte az adatok változnak. Az ügyfél viselkedése eltolódik. A termékek változnak. A gazdasági körülmények mozognak. Egy modell, amely tavaly negyedévben pontos volt, elcsúszhat kódváltoztatás nélkül. Ezért a figyelés és az újratanítás része az architektúrának, nem utólagos gondolat.
Az alapfolyamat egyszerű. Az adatok beáramlanak a vállalati forrásokból. A vezetékek megtisztítják és előkészítik. A funkciólogika nyers rekordokat alakít át modellbemenetökké. A modell egy inferenciás környezetben fut, és visszaad egy előrejelzést. Az alkalmazások ezután használják ezt az előrejelzést egy képernyőn, egy irányítópulton, egy jegyben vagy egy automatikus döntésben.
A nehéz rész ennek a folyamatnak a következetes fenntartása. Ha a tanítás egy definíciót használ egy funkcióra, és a termelés egy másikat, a modell két különböző világot lát. Ezt training-serving skew-nek (tanítás-kiszolgálás torzítás) nevezik. Gyakran akkor jelenik meg, amikor a funkciólogika szétvan szórta notebookokban, scriptekben és alkalmazásokban. Egy moduláris design csökkenti ezt a kockázatot a funkciódefiníciók centralizálásával és verziókezelésével.
Egy kis példa ezt konkrétummá teszi. Képzeljen el egy karbantartó csapatot, amely szeretné megjósolni a berendezések meghibásodását. A modell lehet, hogy a legutóbbi szenzorolvasásokat, az elmúlt szerviz óta eltelt időt és a hőmérsékleti trendeket használja. Ha a modell csak egy pontszámot ad vissza egy irányítópultra, a rendszer hiányos. A pontszámnak el kell jutnia a karbantartási munkafolyamathoz is, ahol egy technikussal cselekedhet rajta, vagy létrejön egy munkarendelés. Az érték a kézbesítésben rejlik, nem önmagában a pontszám.
Ezért használ gyakran a vállalati AI egy modellkiszolgáló réteget egy API mögött. Az alkalmazás bemenetet küld egy szolgáltatáshoz. A szolgáltatás betölti a megfelelő modellverziót, elvégezi az inferenciát, és visszaadja az eredményt. Az alkalmazásnak nem kell tudnia, hogyan lett a modell tanítva. Ez a szétválasztás stabilan tartja az üzleti alkalmazást, miközben a modell fejlődik.
Ez segít a skálázhatóságban és a megbízhatóságban is. Egy kiszolgáló réteg automatikusan skálázódhat, forgalmat irányíthat, naplózhatja a kéréseket, és támogatott viselkedést biztosíthat, ha a modell szolgáltatás elérhetetlen. Néhány rendszerben a kötegelt scoring elegendő. Másokban a valós idejű válaszok fontosabbak. A helyes dizájn a késleltetésen, a térfogaton, az elérhetőségen, a költségen és maga a modell méretén múlik.
Az adatalapok továbbra is meghatározzák a határokat. Ha az adatok hiányosak, késlesek, inkonzisztensek vagy nem reprezentatívak, a modell örökli ezeket a hibákat. Ha a címkék rosszok, a felügyelt tanulás gyenge alapról indul. Ha a szervezet nem tudja később rekonstruálni a pontos tanító készletet, elveszíti a nyomkövethetőséget. A szabályozás és a származtatás (lineage) része az architektúrának, mert a termelési AI-nak magyarázhatónak kell lennie az üzlet számára, nemcsak a mérnöki csapat számára.
A funkcióinženiería is profitál a modularitásból. A nyers vállalati adat ritkán alkalmas modellbemenetre. Tisztítani, összekapcsolni, aggregálni és transzformálni kell. Egy funkcióvezeték átalakíthatja a tranzakciós előzményeket a vásárlások számává az elmúlt 30 napban, vagy az elmúlt rendelés óta eltelt idővel. Amikor ezt a logikát újrahasználják mind a tanításban, mind az inferenciában, a rendszer egységes marad.
Ugyanez az elv vonatkozik a modelléletciklus munkájára is. A tanítás, értékelés, regisztráció, telepítés, inferencia, figyelés és újratanítás ismételhető útvonalat kell alkossanak. Minden lépésnek van célja. A tanítás jelölteket hoz létre. Az értékelés ellenőrzi őket technikai és üzleti szempontból. A regisztráció rögzíti a jóváhagyott verziót. A telepítés kiadja azt. A figyelés a csúszásra figyel. Az újratanítás helyreállítja a minőséget, amikor a valós körülmények eltolódnak.
Itt válik a moduláris design üzleti mintává, nem csak technikai preferenciává. Csökkenti a kapcsolódást (coupling). Könnyebbé teszi a hibák izolálását. Lehetővé teszi, hogy a csapatok javítsanak egy réteget anélkül, hogy a többit tönkretennék. És világosabb utat ad a vezetőségnek az adatoktól a döntésig.
A vállalati AI akkor működik, amikor az intelligencia eljut ahhoz a munkafolyamathoz, amelyre szüksége van. A moduláris design az, ami ezt az utat elég stabiltá teszi a skálázáshoz.
A EuroOp Insights ezen az ötleten alapul: egy alkalmazott K+F minta, egy gyakorlati tanulság, amelyet a EuroOp termékei mögötti vezetékből vontunk le.