Čo problém rieši systém umelej inteligencie, keď opustí laboratórium a vstúpi do reálneho podnikového prostredia? Odpoveď zriedka spočíva len v modeli. Závisí od toho, kde sa model nachádza, kto ho ovláda a aká časť okolitého systému sa musí zmeniť, aby ho podporovala.
Referenčná architektúra poskytuje túto odpoveď vo forme, ktorú možno opakovať. Je to bežné usporiadanie služieb, dát a riadiacich bodov. Pri práci s AI toto usporiadanie formuje náklady, latenciu, governancu (riadenie) a množstvo operačných rizík, ktoré tím prijíma.
Prečo má umiestnenie význam
AI môže byť napojená do back-endu viacerými spôsobmi. Výber nie je kozmetický. Mení to, ako sa pohybujú požiadavky, kde sa spravujú podnety (prompty) a ako sa zvládajú chyby.
V jednom vzore funguje AI ako samostatná služba za bránou API. Iné aplikácie ju volajú cez čisté rozhranie. To udržiava spracovanie podnetov, sledovanie nákladov a pozorovateľnosť (observability) na jednom mieste. Tiež dáva tímom silnejšiu kontrolu, keď na rovnakej vrstve modelu závisí viacero služieb.
Táto štruktúra je užitočná, keď niekoľko systémov potrebuje zdieľané správanie AI. Predajná aplikácia, nástroj pre podporu zákazníkov a interný portál môžu všetky posielať požiadavky na tú istú službu AI. Brána môže vynucovať prístupové pravidlá a udržiavať viditeľnosť využitia. Kompromisom je pridaná architektúra. Viac komponentov znamená viac plánovania a viac koordinácie.
Iný vzor priamo zabudováva AI do malej aplikácie pomocou SDK. Aplikácia volá knižnicu modelu sama. To redukuje sieťové skoky a udržiava nasadenie jednoduchým. Pre úzky nástroj so skromnými potrebami môže byť táto cesta najčistejšia.
Slabinou je škálovateľnosť. Keď na tej istej logike začne závisieť viac tímov alebo pracovných tokov, kód sa môže zamotať. Zmeny podnetov, protokolovanie a kontroly nákladov sa môžu rozptýliť po celej aplikácii namiesto toho, aby žili na jednom mieste. Čo sa na začiatku zdá ľahké, môže neskôr narásť v náročnosti správy.
Bežné vzory v praxi
Pracovníci spúšťaní udalosťami tvoria ďalšiu referenčnú architektúru. Tu správa správ (message bus) spustí pracovníka, keď sa objaví úloha AI. Práca prebieha asynchrónne. To vyhovuje úlohám, kde rýchlosť odozvy je menej dôležitá ako priepustnosť a kontrola.
Sumarizácia sem dobre zapadá. Rovnako tak hromadné obohacovanie dát. Tieto práce môžu trvať a nemusí vždy vyžadovať okamžitú odpoveď. Pracovník môže spracovať jednu položku, zapísať výsledok a pokračovať ďalej. Zvyšok systému nemusí čakať.
Kompletnejší produkčný vzor kombinuje dedikovanú službu AI, úložisko na retrieval (vyhľadávanie kontextu) a vrstvu pozorovateľnosti. Toto je bežné v systémoch poháňaných znalosťami. Úložisko na retrieval dodáva kontext. Služba AI generuje odpoveď. Vrstva pozorovateľnosti zaznamenáva, čo sa stalo.
Táto štruktúra má význam, pretože mnohé podnikové otázky nie sú vyriešené iba generovaním. Model potrebuje správny kontext. Úložisko na retrieval môže obsahovať text politík, dokumentáciu produktov alebo interné poznámky. AI potom odpovedá s podložením z tohto úložiska, nie len z vlastnej pamäte. Pozorovateľnosť uzatvára slučku tým, že ukazuje, čo sa pýtalo, aký kontext bol použitý a kde mohol systém odbočiť.
Malý príklad pomáha urobiť to konkrétnym. Predstavte si interného asistenta politík pre stredne veľkú firmu. Priame zabudovanie cez SDK by fungovalo, ak je nástroj jednoduchý a používa ho jeden tím. Ak ten istý asistent musí obslúžiť HR, financie a operácie, dedikovaná služba AI za bránou sa stáva ľahšie spravovateľnou. Ak asistent musí tiež citovať pasáže politík, úložisko na retrieval sa stáva súčasťou dizajnu. Ak naraz prichádza mnoho otázok týkajúcich sa politík, pracovník spúšťaný udalosťami môže niektoré úlohy spracovávať na pozadí.
Od experimentu k produkcii
Prechod od skúšobného používania k produkčnej práci si vyžaduje disciplínu. Prvou otázkou nie je „Môže model odpovedať?“ Ale „Mala by byť táto úloha vôbec riešená AI?“
Niektoré úlohy stále patria do deterministického kódu. Prúdy s vysokou mierou compliance, pevné obchodné pravidlá a akcie, ktoré vyžadujú presné výsledky, často zostávajú pod tradičnou inžinierskou kontrolou. AI môže asistovať okolo týchto oblastí, ale nemala by ich rozmazávať. Jasné hranice znižujú prekvapenia.
Dizajn podnetov (promptov) treba tiež považovať za zmluvu o rozhraní. Podnet nie je náhodná poznámka pre model. Je súčasťou hraničnej vrstvy systému. Ak služba očakáva štruktúrované JSON, formát výstupu musí byť explicitný. Ak systém vyžaduje prísnu rolu alebo politiku, toto pravidlo musí byť zapísané do podnetu a vynútené v pracovnom toku.
Testovanie je tu dôležité, ale testy môžu zostať ľahké. Tím nemusí vždy potrebovať ťažký stack dátovej vedy. Vo mnohých prípadoch stačia jednoduché kontroly. Sleduje výstup požadovaný formát? Obsahuje požadované polia? Zostáva faktickým v rámci hraníc úlohy? Tieto kontroly zachytia veľkú časť integračných zlyhaní skôr, než dosiahnu používateľov.
Plánovanie nákladov a latencie patrí do tej istej diskusie. Využitie tokenov sa dá odhadnúť pred spustením. Rovnako rozpočty na čas odozvy. Tento odhad pomáha predísť bežnej chybe. Systém sa môže v demo verzii zdať lacným a v produkcii drahým. Systém sa môže pri jednej požiadavke zdať rýchly a pod záťažou pomalým. Referenčná architektúra núti tieto limity objaviť sa včas.
Najlepšie architektúry robia jednu vec dobre: robia správanie AI dostatočne viditeľným, aby mu bolo možné dôverovať. Nezakrývajú logiku podnetov náhodnými cestami kódu. Nenechávajú náklady a kvalitu na hádanky. Dávajú tímom tvar, ktorý sa dá prevádzkovať, inšpekčne kontrolovať a zlepšovať.
EuroOp LLC považuje toto za praktickú inžiniersku návyk. Dobrá architektúra AI nie je sľubom. Je to ovládací povrch. EuroOp Insights nasleduje tú istú myšlienku s jednou aplikovanou vzorkou výskumu a vývoja a jedným praktickým výstupom z pipeline za produktmi spoločnosti EuroOp.