DI veikimo sluoksniai: kodėl vertę kuria visa sistema, o ne vienas modelis

Apie DI dažnai kalbama pernelyg siaurai. Vienas kalba apie pokalbių robotą, kitas – apie kalbos modelį, trečias – apie agentus. Ketvirtas aptaria duomenų centrus, lustus ir „Nvidia“. Penktas – darbo pokyčius, automatizavimą ir tai, kaip mažesnės komandos gali nuveikti daugiau.

Visi iš dalies teisūs. Tačiau nė vieno požiūrio atskirai nepakanka.

Šiuolaikinis DI nėra viena programa, vienas modelis ar viena technologija. Jis apima visą veikimo sluoksnių visumą – nuo energijos ir duomenų centrų iki įmonių procesų, agentų, robotikos, vadovavimo ir atsakomybės. Todėl DI verta matyti kaip sluoksnių visumą, apimančią daugiau nei vien technologijas. Tikslesnis pavadinimas – veikimo sluoksniai. Jie parodo, kaip DI skaičiavimai virsta praktiniu darbu.

Šis straipsnis remiasi „Nvidia“ generalinio direktoriaus Jenseno Huango mintimis apie sluoksninę DI sandarą.

1. Kodėl verta DI suprasti kaip veikimo sluoksnius?

DI diskusijose kartojasi viena problema: pernelyg dažnai matome tik paviršių. Naudotojas mato pokalbių robotą, vadovai – licencijos sąnaudas, programuotojas – API, investuotojas – modelius kuriančią bendrovę, infrastruktūros įmonė – duomenų centrą. Darbuotojas mato naują įrankį, kuris arba palengvina kasdienybę, arba atrodo kaip dar viena sistema tarp daugelio kitų.

Tačiau tikrasis DI poveikis atsiranda tik sujungus šiuos požiūrius. Veikimo sluoksnių samprata padeda suprasti tris dalykus.

Pirma, DI nėra atskira programa. Jam reikia fizinio ir skaitmeninio pagrindo: energijos, skaičiavimo pajėgumų, tinklų, duomenų saugyklų ir lustų.

Antra, vien modelio nepakanka. Kalbos modelis gali daryti įspūdį, tačiau be tinkamų duomenų, konteksto, integracijų ir darbo eigų dažnai lieka bendros paskirties pagalbininku.

Trečia, DI diegimas yra ne tik technologinis projektas. Jis apima ir vadovavimą, atsakomybes, kompetenciją, vertinimą bei pokyčių valdymą.

Klausdama „Kokį DI įrankį turėtume įsidiegti?“ įmonė dažnai žiūri tik į programų sluoksnį. Klausdama „Kaip sukurti DI veikimo sluoksnius, kurie padėtų verslui?“ ji pradeda vertinti visą sistemą. Būtent čia atsiranda konkurencinis pranašumas.

2. DI – visa kūrimo ir taikymo grandinė

DI galima palyginti su elektra. Pasaulį pakeitė ne vien jos atsiradimas. Pokytis įvyko pritaikius elektrą gamyklose, apšvietime, namuose, transporte, ryšių srityje, įrenginiuose ir naujuose darbo būduose.

Tas pats galioja DI. Kalbos modelis svarbus, tačiau tėra visumos dalis. Tikrasis pokytis atsiranda sujungus modelį su duomenimis, įrankiais, programine įranga, procesais ir žmonių priimamais sprendimais.

Supaprastinta DI kūrimo ir taikymo grandinė atrodo taip:

• energija leidžia veikti duomenų centrams
• duomenų centrai suteikia skaičiavimo pajėgumus
• lustai leidžia mokyti ir naudoti modelius
• debesija ir tinklai leidžia plėsti paslaugų teikimą
• pamatiniai modeliai suteikia kalbos, vaizdo ir loginio apdorojimo gebėjimus
• optimizavimas paspartina ir atpigina naudojimą
• duomenys ir RAG suteikia įmonės kontekstą
• MCP ir integracijos suteikia DI prieigą prie įrankių
• orkestravimas paskirsto užduotis modeliams, agentams ir žmonėms
• programos leidžia praktiškai naudoti DI
• procesai paverčia DI verslo nauda
• fiziniame pasaulyje veikiantis DI pritaikomas robotikoje ir realioje aplinkoje
• vadovavimas, priežiūra ir atsakomybė užtikrina tvarų visumos veikimą

Ši grandinė svarbi, nes kiekvienas sluoksnis veikia kitą. Brangi infrastruktūra didina DI sąnaudas. Lėtas modelis prastina naudojimo patirtį. Nekokybiški duomenys lemia nepatikimus atsakymus. Be integracijų DI negali atlikti darbo. Be orkestravimo agentai veikia padrikai. Be vadovavimo didėja rizika.

Todėl DI nėra vien technologija. Tai nauja mąstymo, žinių, programinės įrangos ir darbo kūrimo grandinė.

3. 1 sluoksnis: energija ir duomenų centrai

DI prasideda nuo elektros. Tai skamba kasdieniškai, tačiau yra viena svarbiausių visos DI pertvarkos įžvalgų. DI nėra debesyse sklandanti stebuklinga jėga. Jis veikia duomenų centruose, kuriems reikia elektros, aušinimo, erdvės, tinklo ryšių, įrangos ir nuolatinės priežiūros.

Kai naudotojas paprašo DI analizės, vaizdo, kodo ar agento atliekamos užduoties, užkulisiuose vyksta daugybė skaičiavimų. Kuo daugiau DI naudojama, tuo daugiau pajėgumų reikia. Todėl energija tampa strateginiu klausimu.

Įmonės, valstybės ir technologijų bendrovės turi svarstyti, iš kur bus gaunama DI reikalinga energija, kur bus statomi duomenų centrai, kaip jie bus aušinami ir kaip skaičiavimo apimčių augimą derinti su klimato bei atsakingos veiklos tikslais.

Energijos ir duomenų centrų sluoksniui reikia gebėjimų, kurie neprimena įprastos DI kompetencijos, tačiau yra būtini:

• energetikos planavimo
• elektros tinklų išmanymo
• duomenų centrų architektūros
• aušinimo sprendimų
• nekilnojamojo turto ir pajėgumų planavimo
• tiekimo grandinių valdymo
• tvarumo vertinimo
• rizikos valdymo

Šis sluoksnis primena, kad DI ateitį lemia ne vien programuotojų darbas. Ji sprendžiama ir elektros tinkluose, duomenų centrų salėse bei priimant infrastruktūros sprendimus. Jei DI taps nauja ekonomikos gamybos technologija, energija bus jo kuras.

4. 2 sluoksnis: lustai ir skaičiavimo infrastruktūra

Kitas sluoksnis – skaičiavimo infrastruktūra: lustai, serveriai, spartintuvai, atminties sprendimai ir sistemų architektūra. Šiame sluoksnyje „Nvidia“ tapo DI amžiaus simboliu.

Šiuolaikiniams DI modeliams reikia milžiniško lygiagrečių skaičiavimų kiekio. Grafikos procesoriai, arba GPU, tam tinka, nes vienu metu gali atlikti daug skaičiavimų. Tačiau esmė nėra vienas lustas. DI skaičiavimo infrastruktūra – visuma, kurioje kartu veikia lustai, atmintis, tinklai, serveriai, programinės bibliotekos ir optimizavimo įrankiai.

Šiame sluoksnyje, be kita ko, sprendžiama:

• kaip greitai modeliai atsako
• kiek kainuoja vienas atsakymas
• kiek naudotojų sistema gali aptarnauti
• kaip sėkmingai galima plėsti agentų sistemas
• ar DI galima vykdyti debesijoje, savo aplinkoje, ar galiniuose įrenginiuose
• kaip optimizuoti skaičiavimus skirtingoms paskirtims

Šis sluoksnis ypač svarbus agentų laikais. Vienam pokalbių roboto atsakymui gali pakakti vieno modelio iškvietimo. O agentas atlikdamas vieną užduotį gali padaryti dešimtis ar šimtus iškvietimų: ieškoti informacijos, vertinti alternatyvas, naudoti įrankį, tikrinti rezultatą, rengti santrauką ir prašyti patvirtinimo.

DI pereinant nuo pavienių atsakymų prie daugiapakopio darbo, skaičiavimo poreikis nebūtinai mažėja, net jei modeliai tampa efektyvesni. Jis gali didėti. Todėl skaičiavimo infrastruktūra yra vienas strategiškai svarbiausių DI veikimo sluoksnių.

5. 3 sluoksnis: debesija, tinklai ir duomenų saugojimas

Debesija, tinklai ir duomenų saugojimas sudaro DI paslaugų teikimo sluoksnį. Jie leidžia DI paversti ne vieno kompiuterio ar laboratorijos galimybe, o plečiama paslauga, naudojama organizacijose, programose ir pasaulinėse darbo eigose.

Debesija lanksčiai suteikia skaičiavimo pajėgumus ir paslaugas. Tinklai jungia naudotojus, sistemas ir duomenų šaltinius. Duomenų saugojimas užtikrina, kad duomenys, modeliai, žurnalai, dokumentai ir naudojimo informacija būtų pasiekiami reikiamu metu.

Naudotojui šis sluoksnis dažnai nematomas, tačiau įmonei jis kritiškai svarbus. Lėti tinklai prastina DI naudojimo patirtį. Išskaidžius saugyklas RAG gali nerasti reikiamos informacijos. Brangi debesijos architektūra greitai išaugina žetonų ir modelio iškvietimų sąnaudas. Silpnas informacijos saugumas sustabdo DI plėtrą.

Čia tenka ir svarbus pasirinkimas: naudoti viešąją debesiją, savo aplinką, hibridinį sprendimą ar uždarą sektoriaus aplinką? Viešoji debesija leidžia greitai pradėti ir plėstis. Sava aplinka gali suteikti daugiau kontrolės. Hibridinis sprendimas gali derinti abu privalumus. Reguliuojamuose sektoriuose, pavyzdžiui, sveikatos apsaugoje, finansuose ar viešajame administravime, duomenų vieta ir valdymas gali būti lemiami.

DI paverčia debesijos ir duomenų architektūrą verslo klausimu. Jau nepakanka, kad sistemos tiesiog veiktų. Jos turi sudaryti sąlygas išmaniam, saugiam ir ekonomiškam darbui.

6. 4 sluoksnis: pamatiniai ir kalbos modeliai

Pamatiniai ir kalbos modeliai – matomiausias DI intelektinių gebėjimų sluoksnis. Jie suteikia sistemoms galimybę suprasti kalbą, kurti tekstą, interpretuoti vaizdus, rašyti kodą, rengti santraukas, samprotauti, klasifikuoti, kalbėtis ir vis dažniau vienu metu apdoroti kelių rūšių duomenis.

Vis dėlto kalbos modelis „mąsto“ kitaip nei žmogus. Atsakymus jis kuria remdamasis mokymo duomenimis, naudotojo pateiktu kontekstu ir prieinamais įrankiais. Praktinis poveikis gali būti milžiniškas, nes modelis geba apdoroti kalbą – pagrindinę žmogaus darbo sąsają.

Įmonei svarbu klausti ne vien „Kuris modelis geriausias?“ Naudingesnis klausimas: Kuris modelis tinka kuriai užduočiai? Vienas modelis gali gerai tikti greitam klasifikavimui, kitas – išsamiai analizei, trečias – programavimui, ketvirtas – vaizdams apdoroti. Penktas gali būti pigus ir greitas vidinėms rutinoms, o šeštas – pakankamai saugus reguliuojamai aplinkai.

Ateities DI architektūroje įmonė nebūtinai viskam naudos vieną modelį. Ji turės modelių rinkinį. Todėl modelių vertinimas tampa nauja pagrindine kompetencija: organizacija turi išmanyti, kaip juos tikrinti, lyginti, vertinti kainas ir pasirinkti skirtingoms paskirtims.

Pamatinis modelis – galingas variklis. Tačiau vien variklis dar nėra paruošta transporto priemonė.

7. 5 sluoksnis: modelių optimizavimas ir vykdymas

Modelio vykdymas, angl. inference, reiškia DI naudojimą: momentą, kai modelis pateikia atsakymą, analizę, vaizdą, kodą, išvadą ar kitą darbo žingsnį. Daug dėmesio sulaukia mokymas, tačiau kasdienėje įmonių veikloje vykdymas dažnai svarbesnis. Čia atsiranda sąnaudos, delsa, naudojimo patirtis ir plėtros galimybės.

Kol DI naudojamas nedaug, sąnaudos gali atrodyti menkos. Tačiau integravus jį į klientų aptarnavimą, pardavimą, produktų kūrimą, analitiką, programavimą, ataskaitas ir agentų sistemas, naudojimo apimtis gali sparčiai augti. Kiekvienas modelio iškvietimas naudoja išteklius. Kiekvienas tarpinis agento žingsnis gali pareikalauti dar daugiau.

Todėl optimizavimas yra kritiškai svarbus sluoksnis. Jis gali apimti:

• mažesnio modelio naudojimą paprastai užduočiai
• galingesnio modelio naudojimą tik sudėtingiems etapams
• atsakymų saugojimą podėlyje
• užklausų trumpinimą
• RAG paieškos tobulinimą
• modelių kvantavimą, mažinant jų išteklių poreikį
• vykdymo perkėlimą į pigesnę aplinką
• užduočių paskirstymą keliems modeliams
• agentų sąnaudų ribų nustatymą

Čia atsiskleidžia ekonominė DI pusė. DI nėra nemokama stebuklų mašina. Jis atlieka skaičiavimus, o jie kainuoja. Įmonė turi išmokti valdyti žetonų sąnaudas, modelio iškvietimus, delsą ir kokybę taip pat, kaip kitus išteklius.

Geras DI sprendimas yra ne tik išmanus. Jis taip pat pakankamai greitas, nebrangus, patikimas ir pajėgus ten, kur to reikia.

8. 6 sluoksnis: duomenys, RAG ir kontekstas

Duomenų sluoksnyje bendros paskirties DI tampa pačios organizacijos įrankiu. Be įmonės duomenų DI gali pateikti bendrus atsakymus, aiškinti, siūlyti idėjas ir rengti juodraščius. Tačiau jis nežino, kas konkrečiai šioje įmonėje sutarta, kas pažadėta klientui, kuris projektas vėluoja ar kuri produkto versija naudojama.

RAG, arba Retrieval-Augmented Generation, reiškia paieška papildytą generavimą. Praktiškai DI pirmiausia suranda aktualią informaciją įmonės dokumentuose, duomenų bazėse ar kituose šaltiniuose, o tada ja remdamasis suformuoja atsakymą. Tai didelis pokytis: RAG leidžia DI geriau atsižvelgti į kontekstą.

Pavyzdžiui, jis gali padėti:

• rasti reikiamą instrukciją vidaus dokumentacijoje
• apibendrinti kliento istoriją
• palyginti sutartį su įmonės sąlygomis
• atsakyti į techninės pagalbos klausimą
• rasti tinkamą produkto dokumentacijos vietą
• analizuoti projekto būklę
• parengti vadovų komandai padėties apžvalgą

Tačiau RAG nėra stebuklingas sprendimas. Jo kokybė priklauso nuo pagrindinės informacijos. Pasenę dokumentai duoda pasenusią informaciją. Neaiškios prieigos teisės leidžia DI matyti per daug arba per mažai. Prastai susisteminti dokumentai trukdo paieškai. Jei šaltiniai nerodomi, naudotojas negali įvertinti atsakymo.

Todėl duomenų ir RAG sluoksnis kartu yra informacijos valdymo sluoksnis. DI verčia įmones klausti: kur mūsų informacija? Kas už ją atsako? Ar ji atnaujinta? Kas gali ją naudoti? Kaip tikrinami šaltiniai? Kaip šalinama sena informacija? Kaip sprendžiami prieštaravimai?

DI daugeliui organizacijų atskleidžia nemalonią tiesą: problema slypi jų pačių informacijos valdyme. Tai gera žinia, jei imamasi veiksmų.

9. 7 sluoksnis: MCP, integracijos ir prieiga prie įrankių

Jei duomenys suteikia DI atmintį, integracijos suteikia jam rankas. MCP, arba Model Context Protocol, yra atviras standartas, leidžiantis DI programoms valdomai jungtis prie išorinių įrankių, duomenų šaltinių ir sistemų. Jį galima laikyti DI jungtimi: bendra sąsaja, per kurią DI gali naudoti dokumentus, duomenų bazes, kalendorių, projektų valdymo ar CRM sistemas ir kūrėjų įrankius.

Agentų laikais šis sluoksnis lemiamas. Be prieigos prie įrankių DI daugiausia gali siūlyti. Turėdamas prieigą, jis gali veikti:

• gauti kliento duomenis iš CRM
• sukurti užduotį projektų valdymo sistemoje
• patikrinti kalendorių
• skaityti kodo saugyklą
• vykdyti testus
• atidaryti pagalbos užklausą
• atnaujinti dokumentą
• pateikti duomenų bazės užklausą
• paleisti automatizavimo veiksmą
• parengti ataskaitą ir išsaugoti ją tinkamoje vietoje

Būtent todėl šis sluoksnis ir rizikingas. Kuo daugiau teisių gauna DI, tuo atidžiau reikia nustatyti ribas. Įmonė turi apibrėžti, ką DI gali skaityti, keisti, siųsti ir šalinti, kada būtinas žmogaus patvirtinimas, kokiu naudotojo vaidmeniu jis veikia, kaip viskas registruojama žurnaluose ir kaip veiklą sustabdyti.

Integracijos daro DI naudingą. Valdymas daro jį saugų. Be abiejų gaunamas arba neveiksmingas pagalbininkas, arba pavojingas automatizavimas.

10. 8 sluoksnis: orkestravimas ir agentų sistemos

Orkestravimas – DI darbo koordinavimo sluoksnis. Naudojant kelis modelius, duomenų šaltinius, įrankius, agentus ir žmonių darbą, reikia būdo valdyti visumą. Orkestravimas nustato, kas ką daro, kokia tvarka, kokiomis teisėmis ir su kokiomis patikromis.

Paprastam pokalbių robotui daug orkestravimo nereikia. Agentų sistemai jo reikia. Agentas gali suplanuoti užduotį, ieškoti informacijos, naudoti įrankius, tikrinti rezultatus ir pereiti prie kito etapo. Jei organizacijoje agentų keli, būtina aiški struktūra. Pavyzdžiui, klientų aptarnavimo agentų sistema galėtų veikti taip:

1. klasifikavimo agentas nustato klausimo pobūdį
2. RAG agentas suranda instrukcijas ir kliento istoriją
3. atsakymo agentas parengia sprendimo juodraštį
4. rizikos modelis įvertina, ar atsakymą galima siųsti
5. integravimo agentas atnaujina CRM
6. žmogus patikrina išskirtinius atvejus
7. stebėsenos agentas vertina kokybę

Tai jau darbo eiga, apimanti daugiau nei vieną DI atsakymą. Orkestravimas padeda atsakyti: kurį modelį rinktis užduočiai? Kada naudoti įmonės duomenis? Kada agentui leidžiama naudoti įrankį? Kada tvirtina žmogus? Ką daryti, jei atsakymas neaiškus? Kaip riboti sąnaudas? Kaip aptikti klaidas? Kaip dokumentuoti veiklą?

Čia atsiranda ir agentų ūkio samprata. Agentų ūkis – specializuotų agentų grupė, atliekanti skirtingas užduotis: vienas stebi konkurentus, kitas analizuoja klientų atsiliepimus, trečias rengiasi pardavimui, ketvirtas tikrina kodą, penktas rengia ataskaitas.

Agentų ūkis gali smarkiai padidinti našumą. Tačiau be orkestravimo jis gali virsti chaosu.

11. 9 sluoksnis: programinė įranga ir programos

Naudotojas DI galiausiai mato programinėje įrangoje ir programose. Šiame sluoksnyje technologija virsta naudojimo patirtimi. Tačiau DI keičia ir pačių programų veikimo logiką.

Tradicinėje programinėje įrangoje naudotojas pats spusteli, pildo, filtruoja, kopijuoja, įklijuoja, išsaugo ir siunčia. DI programinė įranga vis labiau remiasi tikslais. Užuot sakęs „Eksportuok šį CSV failą, filtruok B stulpelį, sudaryk suvestinę lentelę ir nubraižyk diagramą“, naudotojas sako: „Išanalizuok praėjusio mėnesio pardavimą, rask nukrypimus ir parenk vadovams trijų punktų santrauką.“

Tai keičia programų projektavimą. Gera DI programa nėra vien sena programa su pridėtu pokalbio langu. Ji supranta naudotojo tikslą, surenka tinkamą kontekstą, naudoja tinkamus įrankius, parodo neaiškumus, prašo patvirtinimo ir pateikia lengvai patikrinamą rezultatą.

Tai didelė galimybė SaaS bendrovėms, teikiančioms debesijos programinę įrangą. Joms reikia iš naujo apmąstyti produktą: ko naudotojas siekia? Kuriuos etapus gali atlikti DI? Kokių duomenų reikia? Kokius įrankius DI gali naudoti? Kur sprendžia naudotojas? Kaip pateikiamas rezultatas? Kaip kuriamas pasitikėjimas?

DI nepanaikina programinės įrangos. Jis paverčia ją iš pasyvių įrankių aktyviomis darbo aplinkomis.

12. 10 sluoksnis: įmonių procesai ir darbo eigos

Šiame sluoksnyje atsiranda tikroji DI verslo vertė: procese, o ne modelyje, demonstracijoje ar įspūdingoje sąsajoje.

Įmonės procesas gali būti pardavimas, klientų aptarnavimas, sąskaitų išrašymas, darbuotojų atranka, ataskaitų rengimas, produktų kūrimas, pirkimas, kokybės kontrolė ar projektų valdymas. DI tampa vertingas tik keisdamas šių procesų spartą, kokybę, sąnaudas ar klientų patirtį.

Pardavimo srityje DI gali surinkti kliento informaciją, išanalizuoti ankstesnius pokalbius, pastebėti pirkimo signalus, pasiūlyti kitą žinutę, parengti pasiūlymą, atnaujinti CRM ir priminti tolesnius veiksmus.

Klientų aptarnavimo srityje DI gali nustatyti klausimo pobūdį, rasti instrukcijas, patikrinti kliento situaciją, pasiūlyti atsakymą, išspręsti įprastą atvejį, sudėtingą klausimą perduoti žmogui ir užregistruoti rezultatą.

Kuriant produktus DI gali analizuoti naudotojų atsiliepimus, rašyti specifikacijas, generuoti kodą, kurti testus, ieškoti klaidų, dokumentuoti pakeitimus ir rengti leidimo aprašus.

Čia svarbus AI-first požiūris. Jis nereiškia, kad DI naudojamas visur. Jis reiškia, kad projektuojant procesą klausiama: Kaip ši darbo eiga atrodytų, jei šiandien ją kurtume pasitelkdami DI, duomenis, agentus ir automatizavimą? Šis klausimas greitai atskleidžia, kur senasis darbo būdas tėra įprotis.

13. 11 sluoksnis: fiziniame pasaulyje veikiantis DI ir robotika

DI neapsiriboja ekranu. Fiziniame pasaulyje veikiantis DI naudojamas robotuose, transporto priemonėse, gamyklose, sandėliuose, laboratorijose, ligoninėse, žemės ūkyje ir miestuose.

Šis sluoksnis suteikia DI naują apčiuopiamumą. Skaitmeninis agentas gali klaidingai parašyti ataskaitą. Tai problema, bet dažnai pataisoma. Fizinis robotas gali netinkamai pajudinti daiktą, susidurti, sugadinti įrenginį ar sukelti saugos riziką. Todėl reikalavimai fiziniame pasaulyje veikiančiam DI griežtesni.

Jam reikia:

• jutiklių
• kamerų
• robotikos
• modeliavimo
• sprendimų realiuoju laiku
• saugos sistemų
• mechatronikos
• paribio skaičiavimo
• žmogaus ir mašinos sąveikos
• reguliavimo išmanymo

Tai ir didelė galimybė. Pramonėje DI gali optimizuoti gamybą, sandėliuose – valdyti robotus. Sveikatos apsaugoje jis gali padėti vaizdinimo, logistikos ir laboratorijų automatizavimo srityse. Žemės ūkyje – tiksliau ūkininkauti, transporte – geriau planuoti maršrutus ir tobulinti autonomines sistemas.

Fiziniame pasaulyje veikiantis DI grąžina mus prie materialiosios aplinkos. Jis primena, kad DI apima daugiau nei kalbą ir kodą. Jis taip pat gali judinti, matuoti, pastebėti ir veikti.

14. 12 sluoksnis: vadovavimas, priežiūra ir atsakomybė

Paskutinis sluoksnis galbūt svarbiausias. Vadovavimas, priežiūra ir atsakomybė lemia, ar DI taps organizacijos konkurenciniu pranašumu, ar nevaldoma rizika.

Kai DI tik rengia juodraščius, gali pakakti paprastesnės kontrolės. Kai jis pradeda naudoti įrankius, apdoroti klientų duomenis, atnaujinti sistemas, teikti sprendimų pasiūlymus ir vykdyti darbo etapus, būtinos aiškios taisyklės. Įmonė turi žinoti:

• kur naudojamas DI
• kas jį naudoja
• kokie duomenys naudojami
• kokie modeliai naudojami
• kokie agentai veikia
• kokias teises turi agentai
• kiek kainuoja naudojimas
• kaip vertinama kokybė
• kaip taisomos klaidos
• kas atsako už rezultatą

Tai nauja vadovavimo sritis. DI valdysena, angl. AI governance, negali likti vien teisininkų dokumentu ar informacijos saugumo draudimų sąrašu. Ji turi būti praktiškas būdas sudaryti sąlygas saugiai naudoti DI.

Geras valdymas nestabdo plėtros, o leidžia ją tęsti didesniu mastu. Be valdymo DI lengvai lieka pavienių darbuotojų bandymu. Dar blogiau – gali atsirasti šešėlinis DI, kai niekas nežino, kokie įrankiai naudojami, kur pateikiami duomenys ir ką veikia agentai.

Vadovų užduotis – nustatyti DI veikimo ribas. Jos neturi lėtinti darbo. Jos leidžia saugiai didinti tempą.

15. Visiems sluoksniams reikalingi gebėjimai

Bendrieji gebėjimai itin svarbūs, nes neapsiriboja vienu sluoksniu. Jie reikalingi visoje sistemoje.

Informacijos saugumas ir privatumas

DI gali apdoroti jautrius duomenis, klientų informaciją, asmens duomenis, sutartis, pirminį kodą ir komercines paslaptis. Todėl informacijos saugumas yra pagrindinis reikalavimas, o ne papildomas priedas.

Kokybės valdymas

DI atsakymas gali skambėti gerai ir vis tiek būti klaidingas. Kokybės valdymas apima testus, vertinimą, palyginimą, grįžtamąjį ryšį, šaltinių tikrinimą ir klaidų stebėseną.

Sąnaudų valdymas

Žetonai, API iškvietimai, tarpiniai agentų žingsniai, RAG paieškos ir skaičiavimai kainuoja. Nestebint sąnaudų DI gali atrodyti našus, tačiau tapti brangus.

Stebėsena ir stebimumas

Stebimumas – gebėjimas matyti, kas vyksta sistemoje. DI srityje tai reiškia žinoti, ką atsakė modelis, kokiais šaltiniais rėmėsi, kokius įrankius kvietė agentas, kur įvyko klaida ir kiek ji kainavo.

Kompetencija ir kultūra

DI neduoda naudos, jei žmonės nemoka jo naudoti arba kultūra trukdo eksperimentuoti. Reikia mokymų, pavyzdžių, vidaus praktikos ir padrąsinimo.

Pokyčių valdymas

DI keičia vaidmenis, procesus ir darbo pasidalijimą. Palikus pokyčius pavienių žmonių atsakomybei, rezultatai lieka nevienodi.

Etika ir reguliavimas

Kuo daugiau DI veikia žmones, sprendimus ir visuomenę, tuo svarbiau apgalvoti teisingumą, skaidrumą, atsakomybę ir reguliavimą.

Šie bendrieji gebėjimai primena laikančiąsias pastato konstrukcijas. Jų negalima pabaigoje pridėti kaip puošmenos.

16. Įmonių požiūris: kaip veikimo sluoksniai keičia strategiją?

DI veikimo sluoksniai įmonei yra praktiškas žemėlapis. Jie padeda suprasti, kodėl vieni DI projektai nepavyksta, o kiti pasiseka.

Nesėkmingas DI projektas dažnai sutelkia dėmesį tik į vieną sluoksnį. Nuperkama programa, bet duomenys prasti. Sukuriamas agentas, bet trūksta integracijų. Pasirenkamas galingas modelis, bet procesas nesikeičia. Vykdomas bandomasis projektas, bet sąnaudos nematuojamos. Darbuotojai mokomi, bet vadovavimas nesikeičia.

Sėkmingas DI projektas apima visą veikimo grandinę. Jame klausiama: kokią verslo problemą sprendžiame? Kurį procesą keičiame? Kokių duomenų reikia? Kurį modelį naudojame? Kokius įrankius DI gali pasitelkti? Kur tvirtina žmogus? Kaip vertinama kokybė? Kaip matomos sąnaudos? Kas atsako už sprendimą? Kaip jį plėsime?

Tai keičia ir biudžeto planavimą. DI nėra vien programinės įrangos licencija. Jį sudaro licencijos, žetonų sąnaudos, integracijos, informacijos saugumas, mokymai, pokyčių įgyvendinimas ir stebėsena.

Įmonėms verta pradėti vertinti DI kaip investiciją į našumą. Jei specialistų darbo užmokestis sudaro reikšmingą sąnaudų dalį, natūralu svarstyti, kokią jos dalį verta investuoti į DI, kad padidėtų darbuotojų našumas, kokybė ir sparta. Tai nereiškia neapgalvotų išlaidų. Tai reiškia matomas ir valdomas DI sąnaudas.

17. Startuolių požiūris: kur atsiranda naujas konkurencinis pranašumas?

Startuoliams DI veikimo sluoksniai yra ir galimybė, ir perspėjimas. Galimybė, nes maža komanda gali sukurti daugiau nei kada nors anksčiau. DI gali padėti programuoti, vykdyti rinkodarą, analizuoti, aptarnauti klientus, rengti dokumentaciją, parduoti ir tvarkyti vidaus procesus. Perspėjimas, nes vien teiginys „turime DI“ jau nebėra konkurencinis pranašumas.

Kai modeliai prieinami daugeliui, vertė atsiranda kitur:

• geresniuose duomenyse
• geresnėje darbo eigoje
• sektoriaus išmanyme
• platinime
• naudotojo sąsajoje
• pasitikėjime
• integracijose
• agentų orkestravime
• sąnaudų efektyvume
• gebėjime išspręsti tikrą problemą

Nuo pat pradžių DI pagrindu kuriamas startuolis neprideda DI funkcijos prie seno produkto. Jis klausia: Kaip šis sektorius atrodytų, jei būtų kuriamas iš naujo aplink DI, agentus, automatizavimą ir duomenis?

Pavyzdžiui, teisinių technologijų srityje DI pagrindu sukurtas produktas nėra vien pokalbių robotas, atsakantis į teisės klausimus. Tai gali būti darbo eiga, kuri skaito sutartis, nustato riziką, lygina su įmonės nuostatomis, siūlo pakeitimus, prašo teisininko patvirtinimo ir atnaujina sutarčių duomenų bazę. Sveikatos apsaugoje toks sprendimas yra ne vien simptomų klausimynas, o sistema, padedanti specialistui rinkti informaciją, analizuoti vaizdus, rengti pacientų instrukcijas ir koordinuoti gydymo eigą. B2B pardavimo srityje tai ne vien el. laiškų generatorius, o agentų sistema, kuri stebi signalus, papildo klientų duomenis, siūlo susisiekti, rengia medžiagą ir atnaujina CRM.

Taigi startuolių konkurencinis pranašumas priklauso nuo to, kaip gerai jie sujungia sluoksnius. Vien DI naudojimo nepakanka.

18. Darbo pokyčiai: ką žmonėms reikės mokėti ateityje?

DI veikimo sluoksniai keičia ir kompetencijos poreikius. Ne visi turi mokėti kurti modelius, išmanyti lustų architektūrą ar technines MCP detales. Tačiau vis daugiau žmonių turi suprasti, kurią visumos dalį sudaro jų darbas.

Specialistas turi suprasti, kaip DI gali padėti jo darbo eigai. Vadovas – kaip DI veikia procesus ir sąnaudas. Programuotojas – kaip sujungti modelius, duomenis ir įrankius. Informacijos saugumo komanda turi suprasti agentų teises, personalo skyrius – kompetencijų pokyčius, finansų vadovai – žetonus ir DI sąnaudas, o produkto vadovai – kaip programoje atsiranda agentų veikimas.

Ateities darbe ypač svarbūs šie gebėjimai:

• problemos apibrėžimas
• procesų skaidymas
• DI galimybių atpažinimas
• duomenų kokybės vertinimas
• kritinis šaltinių vertinimas
• kokybės tikrinimas
• žmogaus ir DI darbo pasidalijimas
• automatizavimo ribų supratimas
• sąnaudų suvokimas
• etinis vertinimas
• gebėjimas keistis

Vienas svarbiausių gebėjimų – atskirti, ką verta automatizuoti, o ko neverta. Ne kiekvienas pasikartojantis darbas tinkamas automatizuoti. Jei darbo etapas veikia žmonių teises, saugumą, sveikatą, pinigus ar reputaciją, reikia atidesnės priežiūros.

DI nepanaikina būtinybės apgalvotai vertinti. Jis dar labiau padidina jos svarbą.

19. Rizika ir spąstai

DI veikimo sluoksnių samprata padeda tiksliau pamatyti riziką. Ji neapsiriboja klaidingu DI atsakymu. Rizika kyla kiekviename sluoksnyje.

Infrastruktūros rizika

Duomenų centrų sąnaudos, energijos vartojimas, pajėgumų trūkumas ir geopolitinės priklausomybės gali paveikti DI prieinamumą ir kainą.

Modelio rizika

Modelis gali haliucinuoti, būti šališkas, neteisingai suprasti užduotį ar pateikti įtikinamą, bet klaidingą atsakymą.

Duomenų rizika

Įmonės informacija gali būti pasenusi, prieštaringa, neišsami arba apsaugota netinkamomis prieigos teisėmis.

Integracijų rizika

DI gali gauti per plačias teises arba netinkamai naudoti įrankį. Užklausų įterpimo atakomis, angl. prompt injection, gali būti mėginama paskatinti agentą atlikti neleistinus veiksmus.

Agentų rizika

Agentas gali tęsti užduotį netinkama kryptimi, atlikti per daug tarpinių žingsnių, didinti sąnaudas ar sukelti klaidų grandinę.

Programos rizika

Naudotojas gali pernelyg pasitikėti DI atsakymu, jei sąsaja neparodo neaiškumų, šaltinių ar patvirtinimo poreikio.

Proceso rizika

Senas procesas gali būti automatizuotas nepakeistas, nors jau buvo prastas. Tuomet DI tik paspartina netinkamą veiklą.

Vadovavimo rizika

Jei niekas neatsako už DI visumą, organizacijoje atsiranda šešėlinis DI, dubliuojami įrankiai, neaiškios atsakomybės ir nevaldomos sąnaudos.

Gera žinia – šias rizikas galima valdyti. Tačiau tik atpažinus jas kiekviename sluoksnyje.

20. Ateitis: DI tampa darbo infrastruktūra

Kitas DI etapas – daugiau nei geresnis pokalbių robotas. Tai darbo infrastruktūra. Ateityje DI gali dalyvauti beveik visuose žinių darbo etapuose: informacijos paieškoje, analizėje, sprendimų rengime, programavime, darbe su klientais, ataskaitose, mokymuose, planavime ir automatizavime. Kartu DI pereina į fizinį pasaulį: robotus, transporto priemones, laboratorijas, pramonę ir logistiką.

Tai nereiškia, kad viskas pasikeis per naktį. Tikėtinesnė laipsniška raida:

1. Pirmiausia DI padeda pavieniams darbuotojams.
2. Tada integruojamas į programas.
3. Tada sujungiamas su įmonės duomenimis.
4. Tada gauna ribotą prieigą prie įrankių.
5. Tada atsiranda agentai.
6. Tada agentai koordinuojami procesuose.
7. Galiausiai ima keistis įmonės veiklos modelis.

Svarbiausias skirtumas nuo dabarties – DI neliks atskiru įrankiu. Jis įsilies į sistemas, procesus ir sprendimų priėmimą. Tuomet klausimas bus nebe „Ar naudojame DI?“, o: „Kaip DI integruotas į mūsų darbo būdą?“

21. Išvados

DI veikimo sluoksniai pateikia DI pertvarkos žemėlapį. Jie padeda suprasti, kad DI nėra vien pokalbių robotas, kalbos modelis ar atskira programa. Tai visa sistema, jungianti energiją, duomenų centrus, lustus, debesiją, modelius, optimizavimą, duomenis, integracijas, agentus, programinę įrangą, procesus, robotiką ir vadovavimą.

Svarbiausia įžvalga tokia: DI vertę kuria sluoksnių sąveika. Vien galingo modelio nepakanka. Nepakanka vien duomenų, integracijos, agento ar programos. Reikia visumos.

Įmonėms tai reiškia, kad DI strategija turi apimti daugiau nei įrankių sąrašą. Ji turi parodyti, kaip DI susijęs su infrastruktūra, duomenimis, procesais, žmonėmis, sąnaudomis, rizika ir vadovavimu. Startuoliams tai reiškia, kad konkurencinis pranašumas vis dažniau atsiranda sujungiant sluoksnius: geriau derinant modelius, duomenis, darbo eigas, integracijas ir naudojimo patirtį. Žmonėms tai reiškia, kad DI raštingumas jau neapsiriboja užklausų rašymu. Tai gebėjimas suprasti, kurioje veikimo grandinės vietoje DI naudojamas, ko jam reikia sėkmei ir kur žmogus turi vadovauti, vertinti bei prisiimti atsakomybę.

DI ateitis nėra vienas itin protingas mygtukas. Tai nauja veiklos aplinka. Joje seksis tiems, kurie supranta visumą.

22. Praktiniai modeliai ir darbo šablonai

1. DI veikimo sluoksnių kontrolinis sąrašas

Naudokite jį vertindami DI sprendimą ar planuodami naują taikymo atvejį.

Infrastruktūra ir skaičiavimai

• Kur veikia sprendimas?
• Kokių skaičiavimo pajėgumų jam reikia?
• Kaip keičiasi sąnaudos didėjant mastui?
• Ar delsa priimtina?
• Ar sprendimas priklauso nuo vieno tiekėjo?

Modeliai

• Kuris modelis naudojamas?
• Kodėl pasirinktas būtent jis?
• Ar užduotis paprasta, ar reikia stiprių samprotavimo gebėjimų?
• Ar modelis išbandytas su savais duomenimis?
• Kaip stebima modelio kokybė?

Duomenys ir kontekstas

• Kokių duomenų reikia?
• Ar duomenys atnaujinti?
• Kas atsako už duomenis?
• Kaip valdomos prieigos teisės?
• Ar naudotojui rodomi šaltiniai?

Integracijos ir įrankiai

• Prie kokių sistemų DI gauna prieigą?
• Ar jis gali tik skaityti, ar ir keisti?
• Kada reikia patvirtinimo?
• Kaip naudojimas registruojamas žurnaluose?
• Kaip ribojamos teisės?

Agentai ir orkestravimas

• Ar reikia vieno atsakymo, ar kelių etapų užduoties?
• Kuriuos etapus atlieka DI?
• Kuriuos etapus atlieka žmogus?
• Kas vyksta įvykus klaidai?
• Ar agentui nustatyta sąnaudų riba?

Programa ir naudojimo patirtis

• Kaip naudotojas supranta, ką padarė DI?
• Ar matomi šaltiniai, neaiškumai ir tolesni žingsniai?
• Ar rezultatą lengva patikrinti?
• Ar naudotojas gali pataisyti arba atmesti pasiūlymą?

Procesas ir verslas

• Kuris procesas tobulinamas?
• Kuris rodiklis keičiasi?
• Ar sutaupoma laiko?
• Ar gerėja kokybė?
• Ar spartėja klientų aptarnavimas?
• Ar mažėja rankinio darbo?

Vadovavimas ir atsakomybė

• Kas atsako už sprendimą?
• Kas atsako už klaidas?
• Kaip stebimas naudojimas?
• Kaip teikiamos sąnaudų ataskaitos?
• Kaip audituojamas sprendimas?

2. AI-first proceso modelis

Pasirinkite vieną įmonės procesą ir peržiūrėkite jį taip:

1. Koks yra proceso tikslas?
2. Kurie etapai kartojasi?
3. Kur reikia informacijos?
4. Kur būtinas žmogaus vertinimas?
5. Kur DI gali parengti pirmąją versiją?
6. Kur DI gali ieškoti informacijos?
7. Kur DI gali naudoti įrankį?
8. Kur DI gali automatiškai atlikti etapą?
9. Kur būtinas patvirtinimas?
10. Kaip matuojamas rezultatas?

Šio modelio tikslas – rasti tinkamą žmogaus, DI ir sistemų darbo pasidalijimą, o ne automatizuoti viską.

3. Atsakomybės pagal sluoksnius modelis

Kiekvienam sluoksniui verta paskirti atsakingą asmenį.

4. Minimalus agento diegimo modelis

Prieš leisdami agentui atlikti tikrą darbą, apibrėžkite jo paskirtį, duomenų šaltinius, įrankius, teises, draudžiamus veiksmus, patvirtinimo vietas, sąnaudų ribą, žurnalų registravimą, kokybės rodiklius, atsakingą asmenį ir išjungimo mechanizmą.

Jei agentas neturi savininko, jo negalima leisti į produkcinę aplinką.

5. Klausimai vadovams

Vadovų komandai verta reguliariai klausti:

1. Kuriuose procesuose DI jau teikia išmatuojamą naudą?
2. Kur DI dar tėra bandymas?
3. Kokių duomenų DI reikia, bet jis jų dar negauna?
4. Kurios integracijos duotų daugiausia naudos?
5. Kur agentai galėtų saugiai dirbti?
6. Kur būtinas žmogaus patvirtinimas?
7. Kiek DI kainuoja per mėnesį?
8. Kaip keičiasi žetonų sąnaudos?
9. Kokias klaidas daro DI?
10. Kas atsako už DI kokybę ir riziką?
11. Kokios kompetencijos trūksta organizacijoje?
12. Kurio proceso jau nebekurtume senuoju būdu?

6. Praktinis patarimas

Vertindami DI sprendimą, neapsiribokite sąsaja ar modelio pavadinimu. Pasidomėkite visa veikimo grandine:

„Kokios infrastruktūros reikia, kokie duomenys naudojami, prie kokių sistemų leidžiama prieiti, kokius darbo etapus galima atlikti, kas prižiūri veiklą ir kaip matuojami nauda, kokybė, sąnaudos bei rizika?“

Būtent tai skiria DI bandymą nuo tikro gebėjimo jį taikyti.

Šaltiniai

1. „Nvidia“ generalinio direktoriaus Jenseno Huango interviu apie sluoksninę DI sandarą („YouTube“)