Milyen problémát oldanak meg az AI-eszközök, és miért akadnak el ennyi projekt még az éles környezetbe kerülés előtt?
A válasz egyszerű. A legtöbb csapat nem bukik meg az AI-ötlet miatt. Hanem azon, hogy a probléma, az adat és az eszköz mennyire illenek egymáshoz. Egy jó platform egy homályos tervből működő rendszert varázsolhat. Egy gyenge viszont egy jó ötletből költséges kísérletté alakíthatja azt.
Az AI-bevezetés mindig egy választással kezdődik. Egyes eszközök abban segítik a csapatot, hogy gyorsan lekérjenek eredményt egy felhőalapú szolgáltatástól. Mások abban támogatják a mérnököket, hogy saját modelleket építsenek és tanítsanak. Vagy segítenek üzleti felhasználóknak kevesebb kóddal munkafolyamatokat létrehozni. Néhány pedig abban, hogy a modell pontossága megmaradjon indítás után. Mindegyik csoport a probléma ugyanazon egészének más-más részét oldja meg.
A felhőalapú AI-platformok gyakran az első állomásnak számítanak. Az Amazon, a Microsoft és a Google kész megoldásokat kínál szöveghez, képekhez, beszédhez és fordításhoz. Ezeket fogyasztás alapján fizetik, és nem igénylik, hogy a csapat saját modellveremet üzemeltessen. Ezért akkor hasznosak, amikor egy cég gyorsan le szeretne tesztelni egy ötletről, vagy egy szűk funkcionalitást szeretne beépíteni anélkül, hogy teljes értékű AI-csapatot építene ki.
Egy egyszerű példa világosan mutatja ezt. Egy élelmiszerlánc elküldhet polcképeket egy felhős látásszolgáltatónak, és majdnem valós időben észlelheti az üres helyeket. A lánccal nem kell nulláról kiképeznie egy látómodellt. Csak egy rendszerre van szüksége, amely elküldi a képet, fogadja az eredményt, és továbbítja azt az üzletüzemeltetésnek. Az eszköz illik a feladathoz.
Éppen ezért jól működik a felhős AI a kezdeti tesztek során. Csökkenti a beállítási munkát. Emellett olcsóbbá teszi a tévedést is. Ha az alkalmazási eset nem válik be, a cég nem költött hónapokat egy olyan egyedi modell fejlesztésére, amit senki sem használ.
A nyílt forráskódú keretrendszerek a verem másik végén találhatók. A TensorFlow és a PyTorch sokkal több kontrollt ad a csapatoknak a modelltervezés, a képzés és az hangolás terén. Akkor alkalmazzák őket, amikor a szabványos szolgáltatások túl korlátozottak vagy túl általánosak. Ez gyakran előfordul specializált területeken, mint például kereskedési rendszerek vagy robotikai látás esetén.
Ezek a keretrendszerek több munkát igényelnek. Nagyobb mérnöki szakértelmet, jobb adatkezelést és nagyobb odafigyelést kérnek a képzés során. A jutalom a rugalmasság. Egy pénzügyi csapatnak lehet, hogy olyan modellre van szüksége, amely a saját adataiban rejlő mintázatokra reagál. Egy robotikai csapatnak lehet, hogy olyan látómodell kelleni, ami a saját szenzoraihoz és fényviszonyaihoz van igazítva. A kereskedelmi kész megoldások ritkán oldják meg jól ezeket az eseteket.
A kód nélküli és alacsony kódot igénylő platformok eltérő utat választanak. Lehetővé teszik, hogy az üzleti csapatok kisebb műszaki ráfordítással képezzék ki vagy telepítsék a modelleket. A DataRobot, a Microsoft AutoML, a Google AutoML és a Microsoft Power Platform mind különböző módon illeszkedik ebbe a mintázatba. A cél ugyanaz: lehetővé tenni, hogy a nem szakemberek hasznos, AI-alapú munkafolyamatokat hozzanak létre azokban az eszközökben, amelyeket már ismernek.
Ez azért fontos, mert sok AI-szükséglet az operatív, az emberi erőforrás-, a marketing- és a ügyfélszolgálati csapatokon belül merül fel. Ezek a csapatok gyakran jobban ismerik a folyamatokat, mint a központi technológiai egység. Egy alacsony kódot igénylő rendszer lehetővé teszi számukra, hogy e tudásra alapozva cselekedjenek anélkül, hogy várniuk kellene egy teljes körű egyedi fejlesztésre. A gyakorlatban ez lerövidítheti az üzleti igény és a működőképes munkafolyamat közötti utat.
Az MLOps hozzáadja azt a részt, amit sok vezető elsikkaszt. Egy modell nem kész attól, hogy egyszer csak működik. Folyamatosan működnie kell akkor is, ha az adatok változnak. Egy leveszélyeztetett ügyfél-modell elcsúszhat egy új termék bevezetése után. Egy dokumentum-osztályozó gyengébb lehet, ha formátumok változnak. Az MLOps-eszközök figyelik ezeket az eltéréseket, futtatnak ellenőrzéseket, értesítéseket küldenek, és támogatják az újbóli betanítást.
Itt rejlik az éles körülmények közötti érték. A felhőszolgáltatások, a nyílt forráskódú eszközök és az alacsony kódot igénylő platformok mindegyike képes modellt létrehozni. Az MLOps segít abban, hogy ez a modell hasznos maradjon. Az MLflow, a Kubeflow és a nagy felhőszolgáltatók eszközei támogatják a verziózást, a tesztelést, a monitorozást és az újbóli képzést. Ez a különbség egy bemutató és egy működő rendszer között.
Léteznek újabb rétegek is, amelyek összekötik az egész vermet. Az AI-középszoftverek meglévő rendszereket, például CRM-platformokat vagy ellátási lánc-adatbázisokat kapcsolnak össze AI-szolgáltatásokkal. Mint egy tolmács működik. Segíti, hogy a különálló rendszerek ugyanabban a nyelvben kommunikáljanak. Ez csökkenti a részlegeken átívelő egyedi összekötő kódok szükségességét.
A generatív AI-nak is folyamatirányításra van szüksége. Az ilyen eszközök, mint a LangChain és a Microsoft Semantic Kernel kezelik a promptokat, irányítják a feladatokat, és kapcsolják össze a modelleket az adattárakkal. Ez segít a csapatoknak olyan asszisztenseket építeni, amelyek kérdésekre tudnak válaszolni, adatokat tudnak előhívni, és vezérelt módon tudnak akciókat indítani. Folyamatirányítás nélkül egy chatbot okosnak tűnhet, de éppen a döntő pillanatokban megbukhat.
A szintetikus adatok akkor jönnek jól, amikor a valós adatok hiányosak vagy érzékenyek. Valósághű tesztadatokat hoz létre fejlesztéshez és modellképzéshez. Ez hasznos az egészségügyben és a pénzügyben, ahol a magánéletet védő szabályok gátolhatják a nyers rekordok közvetlen használatát. Segít a csapatoknak prototípust készíteni még azelőtt, hogy az adatokhoz való hozzáférés teljesen megoldódna.
A címkézési eszközök egy régi problémát oldanak meg. A modellekhez tiszta, címkézett adatokra van szükség. Az ilyen eszközök, mint a Labelbox és a Snorkel csökkentik a manuális terhet azáltal, hogy automatizációt és emberi ellenőrzést kombinálnak. Ez kulcsfontosságú a sok dokumentumot igénylő munkában, ahol egy csapatnak rendeznie, címkéznie vagy jelentést kinyernie kell nagy fájlcsoportokból. A cél nem a tökéletes automatizálás. A cél, hogy a címkézési folyamat gyorsabb és következetesebb legyen.
A valódi döntés nem arról szól, melyik eszköz a legfejlettebb. Hanem arról, melyik illik a munkához. Egy cég, amely egyetlen kép-funkciót tesztel, elkezdhet egy felhős API-val. Egy specializált mérnöki csapatnak lehet, hogy a PyTorch vagy a TensorFlow kell. Egy üzleti egység több értéket hozhat ki az alacsony kódot igénylő automatizálásból. Egy éles rendszerű modell, amelynek megbízhatónak kell maradnia, már elejétől fogva igényli az MLOps-t.
Ezt a pontot könnyű mellékelni. Sok AI-program lelkesedéssel indul, karbantartási gondokkal végződik. Az eszközválasztás befolyásolja ezt az utat. Ha a verem nem tudja kezelni az adateltérést, a hozzáférés-kezelést, a monitorozást és az újbóli képzést, az első verzió lehet az utolsó, amely jól működik.
Egy gyakorlatias bevezetési terv gyakran kicsiben indul. Egy kész szolgáltatást használ szűk feladatra, majd hozzáadja a monitorozást, utána az integrációt, és végül az újbóli képzést, ha az alkalmazási eset életben marad. Ez a sorrend a tényleges üzleti igényhez köti a rendszert, nem pedig egy homályos ígérethez.
Az EuroOp LLC ezt tekinti az AI-munka központi, gyakorlati K+F mintázatának. A megfelelő platform nem helyettesíti az ítélőképességet. Hanem működőképes utat ad neki. Az EuroOp Insights ugyanerre a mintára épít: egy-egy gyakorlati K+F tanulság, egy konkrét gyakorlati levonás, amelyet a valós rendszerek mögötti folyamatok táplálnak.