Akú úlohu rieši enterprise AI, keď model funguje, ale podnik ho stále nemôže využívať?
To je skutočnou skúškou pre produkčnú AI. Dobrý model v notebooku má malú hodnotu, ak sa nedostane cez dátové potrubia, neposkytuje predpovede a nedosahuje do pracovného postupu, kde ľudia na základe nich konajú.
Architektúra enterprise AI existuje preto, aby tento medzeru zaplnila. Definuje spôsob, akým sa prepojujú dáta, modely, aplikácie a infraštruktúra, aby AI bežala vnútri každodenných operácií namiesto toho, aby stála bokom.
Enterprise systémy potrebujú modulárny dizajn, pretože škálovanie vytvára tlak na rôznych miestach. Trénovanie môže vyžadovať výkonný výpočet po dobu hodín. Inferencia môže potrebovať rýchle odozvy pre tisíce používateľov. Riadenie (governance) môže vyžadovať schvaľovacie kroky, auditné stopy a bezpečnostné kontroly. Jeden tuhý zásobník tieto potreby zvláda zle.
Modulárna architektúra to rieši rozdelením systému na jasné časti. Zber dát, spracovanie funkcií, trénovanie modelu, registrácia modelu, poskytovanie služieb (serving), monitorovanie a business aplikácie robia každú jednu vec. Spájajú sa cez definované rozhrania, často API, takže jedna vrstva sa môže zmeniť bez toho, aby ju nútila meniť sa celý systém.
Záleží na tom, pretože enterprise AI je živý systém. Podnikový problém zostáva rovnaký, ale dáta okolo neho sa menia. Správanie zákazníkov sa posúva. Produkty sa menia. Ekonomické podmienky sa pohybujú. Model, ktorý bol presný v minulom štvrťroku, môže driftovať bez akejkoľvek zmeny kódu. Preto sú monitorovanie a re-trénovanie súčasťou architektúry, nie postrannou myšlienkou.
Základný tok je jednoduchý. Dáta prichádzajú zo zdrojov podniku. Potrubia ich čistia a pripravujú. Logika funkcií mení surové záznamy na vstupy modelu. Model beží v prostredí inferencie a vracia predpoveď. Aplikácie potom využívajú túto predpoveď v obrazovke, na dashboardu, v tikete alebo v automatizovanom rozhodnutí.
Ťažkou časťou je udržanie konzistentnosti tohto toku. Ak trénovanie používa jednu definíciu funkcie a produkcia inú, model vidí dva rôzne svety. To sa nazýva training-serving skew (skreslenie medzi trénovaním a poskytovaním). Často sa objavuje, keď je logika funkcií rozptýlená naprieč notebookmi, skriptmi a aplikáciami. Modulárny dizajn redukuje toto riziko centralizáciou definícií funkcií a ich verziovaním.
Malý príklad to urobí hmatateľným. Predstavte si údržbársky tím, ktorý chce predpovedať poruchu vybavenia. Model môže používať nedávne snímkovania senzorov, čas od poslednej servisu a trendy teplôt. Ak model vráti iba skóre do dashboardu, systém je nekompletný. Skóre musí tiež dosiahnuť údržbársky pracovný postup, kde technik môže konať alebo môže byť vytvorená pracovná objednávka. Hodnota pochádza z predania, nie len zo samotného skóre.
Preto enterprise AI často používa vrstvu poskytovania modelu za API. Aplikácia posiela vstup do služby. Služba načíta správnu verziu modelu, vykoná inferenciu a vráti výsledok. Aplikácia nepotrebuje vedieť, ako bol model tréningovaný. Toto oddelenie udržuje stabilnou business aplikáciu, zatiaľ čo model sa vyvíja.
Pomáha to aj so škálovaním a spoľahlivosťou. Vrstva poskytovania môže auto-škálovať, smerovať premávku, logovať požiadavky a podporovať fallback správanie, ak je služba modelu nedostupná. V niektorých systémoch stačí batch scoring (hromadné skórovanie). V iných je dôležitejšia odozva v reálnom čase. Správny dizajn závisí od latencie, objemu, dostupnosti, nákladov a veľkosti samotného modelu.
Dátové základy stále určujú limity. Ak sú dáta neúplné, oneskorené, nekonzistentné alebo nereprezentatívne, model si prevzia tieto chyby. Ak sú štítky zlé, supervidované učenie začína na slabom základe. Ak organizácia neskôr nedokáže rekonštruovať presný trénovací súbor, stráca sledovateľnosť. Riadenie a lineage (pôvod dát) sú súčasťou architektúry, pretože produkčná AI musí byť vysvetliteľná pre biznis, nielen pre inžiniersky tím.
Feature engineering (inžinierstvo funkcií) tiež prospeje z modularitu. Surové enterprise dáta sú zriedka vhodné pre vstup do modelu. Musia sa vyčistiť, spojiť, agregovať a transformovať. Feature pipeline môže zmeniť históriu transakcií na počet nákupov za posledných 30 dní alebo čas od poslednej objednávky. Keď sa táto logika opätovne použije v trénovaní aj inferencii, systém zostáva v súlade.
Ten istý princíp platí pre prácu s životným cyklom modelu. Trénovanie, vyhodnotenie, registrácia, nasadenie, inferencia, monitorovanie a re-trénovanie by mali tvoriť opakujúcu sa cestu. Každý krok má svoj účel. Trénovanie vytvára kandidátov. Vyhodnotenie ich kontroluje proti technickým a biznis potrebám. Registrácia zaznamenáva schválenú verziu. Nasadenie ju publikuje. Monitorovanie sleduje drift. Re-trénovanie obnovuje kvalitu, keď sa skutočné podmienky posunú.
Tu sa modulárny dizajn stáva biznis vzorcom, nie technickou preferenciou. Redukuje spriahnutie (coupling). Uľahčuje izoláciu zlyhania. Umožňuje tímom zlepšovať jednu vrstvu bez rozbíjania ostatných. A dáva vedeniu jasnejšiu cestu od dát k rozhodnutiu.
Enterprise AI funguje, keď inteligencia dosiahne pracovný postup, ktorý ju potrebuje. Modulárny dizajn je to, čo robí túto cestu dostatočne stabilnou na škálovanie.
EuroOp Insights existuje okolo tej istej myšlienky: jeden aplikovaný R&D vzorec, jeden praktický výstup, vychádzajúci z potrubia za produktmi EuroOp.