Az vállalati mesterséges intelligencia milyen problémát old meg, ha a cégnek már vannak adatok, szoftverek és alkalmazottai?
Ez a helyes kezdő kérdés, mert sok MI-kezdés akkor is kudarcot vall, mielőtt az első modell hasznossá válna. Ezek gyakran eszközökkel indulnak, nem céllal. Egy referencia-architektúra ezt orvosolja, mivel egyértelmű térképet ad arról, hogyan illeszkednek össze az adatok, modellek, munkafolyamatok és ellenőrzések.
A vállalati MI-referencia-architektúra egy terv arra, hogyan hozható be az MI a mindennapi üzleti munkába. Megmutatja, hogyan kapcsolódik minden rész a következőhöz. Az érték a felépítésben rejlik. Enélkül a csapatok különálló automatizálási zsákutcákat építenek, amelyek nem osztanak meg adatokat, szabályokat vagy eredményeket.
Kezdje az üzleti feladattal
Egy jó vállalati MI-kialakítás egyetlen valódi feladattal indul. Ez lehet csalásvizsgálat, elmaradás előrejelzése, kereslettervezés vagy ügyfélszolgálati továbbítás. A lényeg, hogy először definiálja a feladatot, majd erre a feladatra formálja a rendszert.
Ez azért fontos, mert az MI, amelynek nincs egyértelmű felhasználási esete, drága csőhálózat lesz. Hatásosnak tűnhet, mégis keveset segít az üzletnek. Egy kiskereskedelmi csapatnak, amely jobb készlettervezést szeretne, más kialakításra van szüksége, mint egy banknak, amely azonnali csalásjelzéseket akar. Az architektúrának a munkát kell követnie.
Egy egyszerű példa világosan mutatja ezt. Egy üzlet rendelkezésre áll tranzakciós adatokkal, amelyek egy vezérelt adattároló rétegben helyezkednek el. Egy feldolgozási réteg tisztítja és előkészíti őket. Egy modell vásárlási mintázatokat keres, és megjósolja, mi fog hamarosan eladni. Az eredmény segíthet az üzletnek abban, hogy a polcok feltöltve maradjanak, mielőtt a termékek elfogynának. Minden résznek egy szerepe van, és minden szerep ugyanazt a célt szolgálja.
Építse a rendszert rétegekben
Az adattároló réteg a tárolási alap. Nyers és rendezett vállalati adatokat tart egy olyan helyen, ahová más rendszerek is elérhetnek. Gondoljon rá, mint egy digitális könyvtárra. Ha az adatok szétszórtak, a rendszer többi része az időt azzal tölti, hogy keres, nem pedig tanul.
A feldolgozási keretrendszer a gépház. Tisztítja, átalakítja és elemzi az adatokat, így a modell használhatja őket. Ez a révégzi a nehéz számítást. Nagy rendszerekben ilyenkor gyakran használják a Spark eszközt, mert képes gyorsan kezelni nagy adatmennyiségeket.
Az MI-modell a döntési réteg. Mintázatokat tanul a feldolgozott adatokból, és előrejelzést vagy besorolást készít. Egy telekommodellszámíthatja, mely ügyfelek valószínűleg elhagyják a szolgáltatást. Egy pénzügyi modell csalásra utaló jeleket keres. A modell végzi az érvelést, de csak az adatok és a feladat által meghatározott határokon belül.
Az orchestrációs keretrendszer a mozgó részek felett helyezkedik el. Koordinálja a munka áramlását a rendszerben. Nem végez analitikát maga. Szerepe, hogy a részeket lépésben tartsa, ahogy egy karmester tempót diktál az zenekar számára. A Kubernetes egy gyakori példája ennek a fajta koordinációnak a modern telepítéseknél.
Az integrációs réteg összeköti az MIT a már használatban lévő rendszerekkel. Ez jelentheti egy CRM-et, egy számlázó platformot, egy ügyrendszert vagy egy öröklött adatbázist. Ez a réteg azért fontos, mert a legtöbb vállalat nem nulláról indul. Egy hasznos MI-rendszernek be kell illeszkednie azokba az eszközökbe, amelyeket az emberek már ma is bíznak és használnak.
A felhasználói felület a főbejárat. Ez az a rész, amit az emberek látnak és érintenek. Egy hasznos interfész elrejti a technikai káoszt egy egyszerű cselekvés mögött, például egy chatbottól kérdést kérdez, vagy megnyit egy irányítópultot, amely egyértelmű következő lépést mutat.
A visszacsatolási hurkok bezárják a kört. A felhasználói cselekvések és eredmények visszatáplálódnak a modellbe, így a jövőbeli eredmények javulnak. Ha az emberek kihagynek egy zenei javaslatot, mentenek egy mást, vagy újra lejátszanak egy számot, ez a viselkedés részévé válik a tanulás folyamatának. Így válik az egyszeri előrejelzés folyamatos rendszerré.
Helyezze bele az irányítást, biztonságot és skálázhatóságot már az elején
Sok csapat az irányítást papírmunkának kezeli a fejlesztés után. Ez hiba. Az irányítás a szabálykönyv, amely megmondja, milyen adatokat lehet használni, hogyan lehet használni, és ki láthatja. Az egészségügyben, a pénzügyekben és más érzékeny környezetekben ez a szabálykönyv maga az architektúra része.
A biztonság ugyanoda tartozik. A hozzáférés-vezérlések korlátozzák, ki nyithat rendszereket vagy adatokat. A titkosítás olvashatatlanul teszi a ellopt adatokat. Ezek alapvető védelmek, de csak akkor működnek jól, ha a verembe tervezésükkor belekerülnek.
A skálázhatóság is korai tervezést igényel. Egy rendszer, amely tíz rekordot kezel, megbukhat egymilliónál. Sokkal könnyebb olyan rendszert építeni, amely bővíthető, mint egy élő rendszert később kiszélesíteni. Ezért az architektúrának figyelembe kell vennie a növekedést, mielőtt a terhelés megérkezne.
A valós idejű feldolgozás szintén kialakítási döntés, nem utólagos kiegészítés. Néhány feladathoz azonnal döntés kell, amikor az adat megjelenik. A csalásmegfigyelés erre a világos eset. Ha a rendszer vár, az érték elveszik.
Az etikai ellenőrzések ugyanabba a keretbe tartoznak. A torzulás és diszkrimináció nem tűnik el magától. Az adatok, a modell és a használat körüli szabályok alakítják őket. Egy komoly architektúra ettől kezdve feltételezi ezt, és teret hagy az áttekintésnek.
A tanulság a moduláris kialakítás egyértelmű céllal
A legerősebb vállalati MI-rendszerek összekapcsolt modulokként készülnek. Mindegyiknek szűk feladata van. Az adattároló réteg tárol. A feldolgozási réteg előkészít. A modell előrejelzést készít. Az orchestrációs réteg koordinál. Az integrációs réteg összeköt. A felhasználói felület bemutatja. A visszacsatolási hurok megtanítja a rendszert, mi történt ezután.
Ez a moduláris forma kontrollt teremt. Segíti a csapatokat abban, hogy részeket teszteljenek anélkül, hogy tönkretennék az egész rendszert. Emellett megkönnyíti a változtatásokat, amikor az üzlet változik. Egy cég lecserélhet egy modellt, frissíthet egy csatlakozót, vagy szigoríthat egy szabályzatot anélkül, hogy mindent újra kellene építenie.
A gyakorlati tanulság egyszerű. Az egyértelmű felhasználási esetek őszintén tartják a rendszert. A moduláris kialakítás kezelhetővé teszi. Az irányítás biztonságossá teszi. A méretezhetőséget és sebességet be kell építeni, nem reménykedni benne később.
Egy olvasó, aki most megértette ezt, bármilyen vállalati MI-tervet megnézhet, és láthatja, hogy az valódi architektúra, vagy csak egy eszközhalom. Ez a különbség a hasznos rendszer és a költséges kísérlet között. Az EuroOp Insights ezt az alkalmazott mintát követi: egyértelmű probléma, működő szerkezet, gyakorlati tanulság a fejlesztési útvonalról.