OMX Helsinki — S&P 500 — DAX — NASDAQ 100 — STOXX 600 — EUR/USD — EUR/SEK — BTC/USD — ETH/USD — 3 mēnešu Euribor — 12 mēnešu Euribor —

MI darbības slāņi: kāpēc MI vērtību rada visa sistēma, nevis viens modelis

Mūsdienu mākslīgais intelekts nav viena lietotne, modelis vai tehnoloģija. Tas aptver veselus darbības slāņus — no enerģijas un datu centriem līdz uzņēmumu procesiem, aģentiem, robotikai un vadībai. MI vērtība rodas tikai tad, kad šie slāņi darbojas kopā.

Pārbaudīts

Par MI bieži runā pārāk šauri. Viens domā tērzēšanas robotus, otrs — valodu modeļus, trešais — aģentus. Ceturtais runā par datu centriem, mikroshēmām un Nvidia. Piektais pievēršas darba pārmaiņām, automatizācijai un tam, kā uzņēmumi ar mazākām komandām var paveikt vairāk.

Katram daļēji ir taisnība. Taču neviens no šiem skatījumiem atsevišķi nav pietiekams.

Mūsdienu MI nav viena lietotne, modelis vai tehnoloģija. Tas aptver veselu sistēmu — no enerģijas un datu centriem līdz uzņēmumu procesiem, aģentiem, robotikai, vadībai un atbildībai. Tāpēc MI vērts aplūkot kā slāņu kopumu, turklāt ne tikai tehniskā nozīmē. Precīzāks apzīmējums ir darbības slāņi. Tie parāda, kā MI no skaitļošanas pārtop praktiskā darbā.

Šis raksts balstīts Nvidia izpilddirektora Jensen Huang pārdomās par MI slāņveida uzbūvi.

1. Kāpēc MI jāaplūko pa darbības slāņiem?

Diskusijās par MI atkārtojas viena problēma: pārāk bieži redzam tikai virspusi. Lietotājs redz tērzēšanas robotu. Vadība — licences izmaksas. Izstrādātājs — API. Investors — modeļu uzņēmumu. Infrastruktūras uzņēmums — datu centru. Darbinieks redz jaunu rīku, kas vai nu atvieglo ikdienu, vai šķiet kārtējā sistēma līdzās pārējām.

Taču īstā MI ietekme rodas tikai tad, kad šie skatījumi savienojas. Domāšana darbības slāņos palīdz saprast trīs lietas.

Pirmkārt, Tā parāda, ka MI nav atrauta programmatūra. Tam vajadzīgs fizisks un digitāls pamats: enerģija, skaitļošana, tīkli, datu glabāšana un mikroshēmas.

Otrkārt, Tā parāda, ka ar modeli vien nepietiek. Valodas modelis var būt iespaidīgs, taču bez atbilstošiem datiem, konteksta, integrācijām un darba plūsmām tas bieži paliek vispārīgs palīgs.

Treškārt, Tā parāda, ka MI ieviešana nav tikai tehnoloģiju projekts. Tā ietver arī vadību, atbildību, prasmes, rezultātu mērīšanu un pārmaiņu vadību.

Jautājot “Kuru MI rīku mums ieviest?”, uzņēmums bieži raugās tikai uz lietotņu slāni. Jautājot “Kā izveidot MI darbības slāņus, lai tie atbalstītu biznesu?”, tas sāk aplūkot visu sistēmu. Tieši tur rodas konkurences priekšrocība.

2. MI nav viena lieta, bet ražošanas ķēde

MI var salīdzināt ar elektrību. Tās pastāvēšana vien pasauli nemainīja. Pārmaiņas sākās, kad elektrību izmantoja rūpnīcās, apgaismojumā, mājokļos, transportā, saziņā, ierīcēs un jaunās darba metodēs.

Tas pats attiecas uz MI. Valodas modelis ir svarīgs, taču tā ir tikai daļa no kopuma. Patiesas pārmaiņas rodas, modeli savienojot ar datiem, rīkiem, programmatūru, procesiem un cilvēku lēmumiem.

Vienkāršoti MI ražošanas ķēde izskatās šādi:

  • enerģija nodrošina datu centru darbību
  • datu centri nodrošina skaitļošanu
  • mikroshēmas nodrošina modeļu apmācību un lietošanu
  • mākonis un tīkli ļauj pakalpojumus izplatīt plašā mērogā
  • pamatmodeļi sniedz valodas, vizuālās un loģiskās spējas
  • optimizācija padara lietošanu ātrāku un lētāku
  • dati un RAG pievieno uzņēmuma paša kontekstu
  • MCP un integrācijas dod MI piekļuvi rīkiem
  • orķestrēšana sadala uzdevumus modeļiem, aģentiem un cilvēkiem
  • lietotnes padara MI lietojamu
  • procesi pārvērš MI ieguvumos uzņēmumam
  • fiziskais MI pārnes mākslīgo intelektu robotikā un reālajā pasaulē
  • vadība, uzraudzība un atbildība nodrošina visa kopuma ilgtspēju

Šī ķēde ir svarīga, jo katrs slānis ietekmē nākamo. Dārga infrastruktūra sadārdzina MI lietošanu. Lēns modelis pasliktina lietošanas pieredzi. Slikti dati rada neuzticamas atbildes. Bez integrācijām MI nevar veikt darbu. Bez orķestrēšanas aģenti darbojas nesaskaņoti. Bez vadības aug riski.

Tāpēc MI nav tikai tehnoloģija. Tā ir jauna domāšanas, informācijas, programmatūras un darba ražošanas ķēde.

3. 1. slānis: enerģija un datu centri

MI sākas ar elektrību. Tas izklausās ikdienišķi, taču ir viens no būtiskākajiem secinājumiem par MI pārmaiņām. MI nav mākonī peldoša maģija. Tas darbojas datu centros, kuriem vajadzīga elektrība, dzesēšana, telpas, tīkla savienojumi, iekārtas un nepārtraukta uzturēšana.

Kad lietotājs lūdz MI veikt analīzi, radīt attēlu, kodu vai izpildīt aģenta uzdevumu, fonā notiek milzīgs skaitļošanas darbs. Jo vairāk MI izmanto, jo lielāka jauda vajadzīga. Tādēļ enerģija kļūst par stratēģisku jautājumu.

Uzņēmumiem, valstīm un tehnoloģiju uzņēmumiem jādomā, no kurienes nāks MI vajadzīgā enerģija, kur izvietot datu centrus, kā tos dzesēt un kā skaitļošanas pieaugumu saskaņot ar klimata un atbildīgas darbības mērķiem.

Enerģijas un datu centru slānī vajadzīgas prasmes, kas neatgādina ierastās MI prasmes, taču ir neaizstājamas:

  • enerģētikas plānošana
  • izpratne par elektrotīkliem
  • datu centru arhitektūra
  • dzesēšanas risinājumi
  • nekustamo īpašumu un jaudas plānošana
  • piegādes ķēžu pārvaldība
  • ilgtspējas novērtēšana
  • risku pārvaldība

Šis slānis atgādina, ka MI nākotne neizšķirsies tikai pie programmētāju galdiem. Tā izšķirsies arī energotīklos, datu centru zālēs un infrastruktūras lēmumos. Ja MI kļūst par ekonomikas jauno ražošanas tehnoloģiju, enerģija ir tā degviela.

4. 2. slānis: mikroshēmas un skaitļošanas infrastruktūra

Nākamais slānis ir skaitļošanas infrastruktūra: mikroshēmas, serveri, paātrinātāji, atmiņas risinājumi un sistēmu arhitektūra. Šajā slānī Nvidia kļuvusi par MI laikmeta simbolu.

Mūsdienu MI modeļiem vajadzīga milzīga paralēlās skaitļošanas jauda. Grafiskie procesori jeb GPU tam ir piemēroti, jo vienlaikus spēj veikt daudz aprēķinu. Taču runa nav tikai par atsevišķu mikroshēmu. MI skaitļošanas infrastruktūrā kopā darbojas mikroshēmas, atmiņa, tīkli, serveri, programmatūras bibliotēkas un optimizācijas rīki.

Šajā slānī cita starpā nosaka:

  • cik ātri modeļi atbild
  • cik maksā vienas atbildes sagatavošana
  • cik lietotāju sistēma spēj apkalpot
  • cik labi aģentu sistēmas mērogojas
  • vai MI var darbināt mākonī, savā vidē vai perifērijas ierīcēs
  • kā optimizēt skaitļošanu dažādiem lietojumiem

Aģentu laikmetā šis slānis ir īpaši svarīgs. Vienai tērzēšanas robota atbildei var pietikt ar vienu modeļa izsaukumu. Taču aģents viena uzdevuma laikā var veikt desmitiem vai simtiem izsaukumu: meklēt informāciju, izvērtēt iespējas, izmantot rīku, pārbaudīt rezultātu, uzrakstīt kopsavilkumu un lūgt apstiprinājumu.

MI pārejot no atsevišķām atbildēm uz vairāku posmu darbu, skaitļošanas vajadzība var nesamazināties, lai gan modeļi kļūst efektīvāki. Tā var pieaugt. Tāpēc skaitļošanas infrastruktūra ir viens no stratēģiski svarīgākajiem MI darbības slāņiem.

5. 3. slānis: mākonis, tīkli un datu glabāšana

Mākonis, tīkli un datu glabāšana veido MI piegādes slāni. Tie ļauj MI pārtapt no viena datora vai laboratorijas iespējām mērogojamā pakalpojumā, ko izmanto organizācijās, lietotnēs un globālās darba plūsmās.

Mākonis elastīgi nodrošina skaitļošanu un pakalpojumus. Tīkli savieno lietotājus, sistēmas un datu avotus. Datu glabāšana nodrošina datu, modeļu, žurnālu, dokumentu un lietošanas situāciju pieejamību vajadzīgajā brīdī.

Lietotājam šis slānis bieži ir neredzams, bet uzņēmumam — kritiski svarīgs. Lēni tīkli pasliktina MI lietošanas pieredzi. Izkaisīti glabāšanas risinājumi traucē RAG atrast pareizo informāciju. Dārga mākoņa arhitektūra strauji palielina tokenu un modeļu izsaukumu izmaksas. Vāja informācijas drošība aptur MI plašāku ieviešanu.

Šajā slānī jāizvēlas publisks mākonis, sava vide, hibrīdrisinājums vai nozarei paredzēta slēgta vide. Publisks mākonis ir ātrs un mērogojams. Sava vide var dot lielāku kontroli. Hibrīds var apvienot abus. Regulētās nozarēs, piemēram, veselības aprūpē, finansēs vai valsts pārvaldē, datu atrašanās vieta un pārvaldība var būt izšķiroša.

MI padara mākoņa un datu arhitektūru par biznesa jautājumu. Vairs nepietiek, ka sistēmas darbojas. Tām jānodrošina gudrs, drošs un izmaksu ziņā efektīvs darbs.

6. 4. slānis: pamatmodeļi un valodu modeļi

Pamatmodeļi un valodu modeļi ir redzamākais MI intelekta slānis. Tie ļauj sistēmām saprast valodu, radīt tekstu, interpretēt attēlus, rakstīt kodu, veidot kopsavilkumus, spriest, klasificēt, sarunāties un arvien biežāk vienlaikus apstrādāt dažādus datu veidus.

Valodas modelis tomēr nedomā kā cilvēks. Tas rada atbildes, balstoties uz apmācības datiem, lietotāja sniegto kontekstu un pieejamajiem rīkiem. Tomēr praktiskā ietekme var būt milzīga, jo modelis prot apstrādāt valodu — galveno cilvēku darba saskarni.

Uzņēmumam būtisks jautājums nav tikai “Kurš modelis ir labākais?”. Labāk jautāt: Kurš modelis der kuram uzdevumam? Viens modelis var būt labs ātrā klasificēšanā. Otrs der padziļinātai analīzei. Trešais ir spēcīgs programmēšanā. Ceturtais apstrādā attēlus. Piektais ir lēts un ātrs iekšējai rutīnai. Sestais ir pietiekami drošs regulētai videi.

Nākotnes MI arhitektūrā uzņēmums, iespējams, neizmantos vienu modeli visam. Tas izmantos modeļu klāstu. Tādēļ modeļu novērtēšana kļūst par jaunu pamatprasmi: organizācijai jāsaprot, kā modeļus testēt, salīdzināt, novērtēt to cenu un izvēlēties konkrētam lietojumam.

Pamatmodelis ir jaudīgs dzinējs. Taču dzinējs vēl nav gatavs transportlīdzeklis.

7. 5. slānis: modeļu optimizācija un inference

Inference nozīmē MI izmantošanu — brīdi, kad modelis rada atbildi, analīzi, attēlu, kodu, secinājumu vai nākamo darba soli. Apmācībai pievērš daudz uzmanības, taču uzņēmuma ikdienā inference bieži ir svarīgāka. Tieši tur veidojas izmaksas, aizkave, lietošanas pieredze un mērogojamība.

Ja MI izmanto maz, izmaksas var šķist nelielas. Taču, to iestrādājot klientu apkalpošanā, pārdošanā, produktu izstrādē, analītikā, programmēšanā, ziņojumu sagatavošanā un aģentu sistēmās, lietojums var strauji augt. Katrs modeļa izsaukums patērē resursus. Katrs aģenta starpsolis var patērēt vēl vairāk.

Tāpēc optimizācija ir kritiski svarīgs slānis. Tā var ietvert, piemēram:

  • mazāka modeļa izmantošanu vienkāršam uzdevumam
  • jaudīgāka modeļa izmantošanu tikai sarežģītos posmos
  • atbilžu saglabāšanu kešatmiņā
  • uzvedņu saīsināšanu
  • RAG meklēšanas uzlabošanu
  • modeļu kvantēšanu jeb resursu prasību samazināšanu
  • izpildes pārcelšanu uz lētāku vidi
  • uzdevumu sadalīšanu vairākiem modeļiem
  • izmaksu limitu noteikšanu aģentiem

Te atklājas MI ekonomiskā puse. MI nav bezmaksas burvju mašīna. Tā ir skaitļošana, un skaitļošana maksā. Uzņēmumam jāiemācās pārvaldīt tokenu izmaksas, modeļu izsaukumus, aizkavi un kvalitāti tāpat kā citus resursus.

Labs MI risinājums nav tikai gudrs. Tas ir arī pietiekami ātrs, lēts, uzticams un vajadzīgajā brīdī pietiekami jaudīgs.

8. 6. slānis: dati, RAG un konteksts

Dati ir slānis, kurā MI no vispārīga intelekta pārtop organizācijas paša rīkā. Bez uzņēmuma datiem MI var sniegt vispārīgas atbildes, skaidrot, piedāvāt idejas un sagatavot melnrakstus. Taču tas nezina, kas tieši šajā uzņēmumā ir norunāts, kas apsolīts klientam, kurš projekts kavējas vai kura produkta versija tiek izmantota.

RAG jeb Retrieval-Augmented Generation nozīmē ģenerēšanu ar informācijas izgūšanas atbalstu. Praksē MI vispirms atrod atbilstošu informāciju uzņēmuma dokumentos, datubāzēs vai citos avotos un tad veido atbildi. Tā ir būtiska pārmaiņa: RAG ļauj MI labāk ņemt vērā kontekstu.

Tas var palīdzēt, piemēram:

  • atrast pareizo instrukciju iekšējā dokumentācijā
  • apkopot klienta vēsturi
  • salīdzināt līgumu ar uzņēmuma noteikumiem
  • atbildēt uz tehniskā atbalsta jautājumu
  • atrast pareizo vietu produkta dokumentācijā
  • analizēt projekta stāvokli
  • sagatavot vadības komandai situācijas pārskatu

Taču RAG nav burvju risinājums. Tas darbojas tikai tik labi, cik laba ir pamatā esošā informācija. Ja dokumenti ir novecojuši, MI atrod novecojušu informāciju. Neskaidru piekļuves tiesību dēļ MI var redzēt pārāk daudz vai pārāk maz. Slikti strukturēti dokumenti apgrūtina meklēšanu. Bez parādītiem avotiem lietotājs nevar izvērtēt atbildi.

Tāpēc datu un RAG slānis ir arī informācijas pārvaldības slānis. MI liek uzņēmumiem jautāt: kur ir mūsu informācija? Kam tā pieder? Vai tā ir aktuāla? Kas to drīkst izmantot? Kā pārbauda avotus? Kā dzēš novecojušu informāciju? Kā atrisina pretrunas?

Līdz ar MI ieviešanu daudzas organizācijas atklāj nepatīkamu patiesību: problēma ir pašu informācijas pārvaldībā, nevis MI. Tā ir laba ziņa, ja uzņēmums ķeras pie tās risināšanas.

9. 7. slānis: MCP, integrācijas un savienojumi ar rīkiem

Ja dati dod MI atmiņu, integrācijas dod tam rokas. MCP jeb Model Context Protocol ir atvērts standarts, kas ļauj MI lietotnēm kontrolētā veidā savienoties ar ārējiem rīkiem, datu avotiem un sistēmām. To var uztvert kā MI savienotāju — kopīgu saskarni, caur kuru MI var izmantot, piemēram, dokumentus, datubāzes, kalendāru, projektu pārvaldību, CRM sistēmu vai izstrādātāju rīkus.

Aģentu laikmetā šis slānis ir izšķirošs. MI bez piekļuves rīkiem galvenokārt var ieteikt. MI ar piekļuvi rīkiem var darīt. Tas var:

  • iegūt klienta datus no CRM
  • izveidot uzdevumu projektu pārvaldības sistēmā
  • pārbaudīt kalendāru
  • lasīt koda repozitoriju
  • palaist testus
  • izveidot atbalsta pieteikumu
  • atjaunināt dokumentu
  • veikt datubāzes vaicājumu
  • iedarbināt automatizāciju
  • sagatavot ziņojumu un saglabāt to pareizajā vietā

Taču tieši tāpēc šis slānis ietver riskus. Jo vairāk tiesību MI piešķir, jo rūpīgāk jānosaka robežas. Uzņēmumam jādefinē, ko MI drīkst lasīt, mainīt, sūtīt un dzēst, kad vajadzīgs cilvēka apstiprinājums, kādā lietotāja lomā tas darbojas, kā visu reģistrē žurnālos un kā darbību var apturēt.

Integrācijas padara MI noderīgu. Pārvaldība padara to drošu. Bez abām rodas vai nu neefektīvs palīgs, vai bīstama automatizācija.

10. 8. slānis: orķestrēšana un aģentu sistēmas

Orķestrēšana ir MI darba vadības slānis. Ja izmanto vairākus modeļus, datu avotus, rīkus, aģentus un cilvēkus, vajadzīgs veids, kā vadīt kopumu. Orķestrēšana nosaka, kurš ko dara, kādā secībā, ar kādām tiesībām un pārbaudēm.

Vienkāršam tērzēšanas robotam daudz orķestrēšanas nevajag. Aģentu sistēmai gan vajag. Aģents var plānot uzdevumu, meklēt informāciju, izmantot rīkus, pārbaudīt rezultātus un turpināt nākamo posmu. Ja organizācijā ir vairāki aģenti, vajadzīga skaidra struktūra. Piemēram, klientu apkalpošanas aģentu sistēma varētu darboties šādi:

  1. klasificēšanas aģents atpazīst jautājumu
  2. RAG aģents atrod instrukcijas un klienta vēsturi
  3. atbilžu aģents sagatavo risinājumu
  4. riska modelis izvērtē, vai atbildi drīkst sūtīt
  5. integrācijas aģents atjaunina CRM
  6. cilvēks pārbauda izņēmuma gadījumus
  7. uzraudzības aģents mēra kvalitāti

Tā vairs nav viena MI atbilde. Tā ir darba plūsma. Orķestrēšana atbild, piemēram, uz jautājumiem: kuru modeli izvēlēties uzdevumam? Kad izmantot uzņēmuma datus? Kad aģents drīkst izmantot rīku? Kad apstiprina cilvēks? Ko darīt, ja atbilde ir nedroša? Kā ierobežot izmaksas? Kā atklāt kļūdas? Kā dokumentēt darbību?

Te rodas arī aģentu kopas ideja. Tā ir specializētu aģentu grupa ar dažādiem uzdevumiem: viens seko konkurentiem, otrs analizē klientu atsauksmes, trešais gatavo pārdošanu, ceturtais pārbauda kodu, piektais sagatavo ziņojumus.

Aģentu kopa var ievērojami kāpināt produktivitāti. Taču bez orķestrēšanas tā var pārvērsties haosā.

11. 9. slānis: programmatūra un lietotnes

Lietotājs MI galu galā redz programmatūrā un lietotnēs. Šajā slānī tehnoloģija pārtop lietošanas pieredzē. Taču MI maina arī lietotņu darbības loģiku.

Tradicionālā programmatūrā lietotājs dara pats: klikšķina, aizpilda, filtrē, kopē, ielīmē, saglabā un sūta. MI programmatūra arvien vairāk balstās uz mērķiem. Lietotājs var neteikt “Eksportē šo CSV failu, filtrē B kolonnu, izveido rakurstabulu un diagrammu.” Viņš saka: “Analizē pagājušā mēneša pārdošanu, atrodi novirzes un sagatavo vadībai trīs punktu kopsavilkumu.”

Tas maina lietotņu projektēšanu. Laba MI lietotne nav veca programma ar pievienotu tērzēšanas logu. Tā saprot lietotāja mērķi, atrod pareizo kontekstu, izmanto atbilstošos rīkus, parāda neskaidrības, lūdz apstiprinājumu un padara rezultātu viegli pārbaudāmu.

Tā ir liela iespēja SaaS uzņēmumiem jeb mākoņprogrammatūras nodrošinātājiem. Tiem no jauna jāizvērtē savs produkts: ko lietotājs vēlas panākt? Kurus posmus var veikt MI? Kādi dati vajadzīgi? Kurus rīkus MI drīkst izmantot? Kur jālemj lietotājam? Kā parādīt rezultātu? Kā veidot uzticēšanos?

MI neatceļ programmatūru. Tas pārvērš programmatūru no pasīviem rīkiem aktīvā darba vidē.

12. 10. slānis: uzņēmumu procesi un darba plūsmas

Šajā slānī rodas patiesā MI vērtība uzņēmumam. Procesā, nevis modelī, demonstrācijā vai skaistā saskarnē.

Uzņēmuma process var būt, piemēram, pārdošana, klientu apkalpošana, rēķinu izrakstīšana, personāla atlase, pārskatu sagatavošana, produktu izstrāde, iepirkumi, kvalitātes kontrole vai projektu pārvaldība. MI kļūst vērtīgs tad, kad maina šo procesu ātrumu, kvalitāti, izmaksas vai klientu pieredzi.

Piemēram, pārdošanā MI var atrast klienta pamatinformāciju, analizēt agrākās sarunas, atpazīt pirkšanas signālus, ieteikt nākamo ziņu, sagatavot piedāvājumu, atjaunināt CRM un atgādināt par turpmāko rīcību.

Klientu apkalpošanā MI var atpazīt jautājumu, atrast instrukcijas, pārbaudīt klienta situāciju, ieteikt atbildi, atrisināt rutīnas gadījumu, nodot sarežģītu jautājumu cilvēkam un reģistrēt rezultātu.

Produktu izstrādē MI var analizēt lietotāju atsauksmes, rakstīt specifikācijas, ģenerēt kodu, rakstīt testus, meklēt kļūdas, dokumentēt izmaiņas un sagatavot informāciju par jauno versiju.

Te svarīga ir AI-first pieeja. Tā nenozīmē izmantot MI visur. Tā nozīmē, projektējot procesu, jautāt: Kā šī darba plūsma izskatītos, ja mēs to šodien veidotu ar MI, datiem, aģentiem un automatizāciju? Šis jautājums ātri atklāj, kur vecais darbības veids saglabājies tikai ieraduma dēļ.

13. 11. slānis: fiziskais MI un robotika

MI nepaliks tikai ekrānā. Fiziskais MI darbojas fiziskajā pasaulē: robotos, transportlīdzekļos, rūpnīcās, noliktavās, laboratorijās, slimnīcās, lauksaimniecībā un pilsētvidē.

Šis slānis padara MI taustāmu jaunā veidā. Digitāls aģents var nepareizi uzrakstīt ziņojumu. Tā ir problēma, taču bieži labojama. Fizisks robots var nepareizi pārvietot priekšmetu, sadurties, sabojāt iekārtu vai apdraudēt drošību. Tāpēc fiziskajam MI prasības ir stingrākas.

Fiziskajam MI vajag:

  • sensorus
  • kameras
  • robotiku
  • simulācijas
  • lēmumu pieņemšanu reāllaikā
  • drošības sistēmas
  • mehatroniku
  • perifēro skaitļošanu
  • cilvēka un mašīnas mijiedarbību
  • izpratni par regulējumu

Tā ir arī liela iespēja. Rūpniecībā MI var optimizēt ražošanu. Noliktavās tas var vadīt robotus. Veselības aprūpē tas var palīdzēt attēldiagnostikā, loģistikā un laboratoriju automatizācijā. Lauksaimniecībā tas var atbalstīt precīzāku saimniekošanu. Transportā tas var uzlabot maršrutu plānošanu un autonomās sistēmas.

Fiziskais MI atgriež mākslīgo intelektu materiālajā pasaulē. Tas atgādina, ka MI nav tikai valoda un kods. Tas var arī pārvietot, mērīt, uztvert un rīkoties.

14. 12. slānis: vadība, uzraudzība un atbildība

Pēdējais slānis varbūt ir pats svarīgākais. Vadība, uzraudzība un atbildība nosaka, vai MI organizācijai kļūs par konkurences priekšrocību vai nekontrolētu risku.

Kamēr MI tikai raksta melnrakstus, pārvaldība var būt vienkāršāka. Kad tas sāk izmantot rīkus, apstrādāt klientu datus, atjaunināt sistēmas, sagatavot lēmumu priekšlikumus un veikt darba posmus, vajadzīgi skaidri noteikumi. Uzņēmumam jāzina:

  • kur MI tiek izmantots
  • kas to izmanto
  • kādi dati tiek izmantoti
  • kādi modeļi tiek izmantoti
  • kādi aģenti darbojas
  • kādas tiesības ir aģentiem
  • cik maksā lietošana
  • kā mēra kvalitāti
  • kā labo kļūdas
  • kas atbild par rezultātu

Tā ir jauna vadības joma. AI governance jeb MI pārvaldības modelis nedrīkst būt tikai juristu dokuments vai informācijas drošības aizliegumu saraksts. Tam jābūt praktiskam veidam, kā nodrošināt drošu MI lietošanu.

Laba pārvaldība neaptur attīstību. Tā ļauj attīstībai iegūt mērogu. Bez pārvaldības MI viegli paliek atsevišķu darbinieku eksperimentos. Vēl sliktāk — rodas ēnu MI, un neviens nezina, kādus rīkus izmanto, kur ievada datus un ko dara aģenti.

Vadības uzdevums ir izveidot MI aizsargbarjeras. To mērķis nav mazināt ātrumu. To mērķis ir ļaut droši palielināt ātrumu.

15. Caurviju spējas: kas vajadzīgs visos slāņos?

Caurviju spējas ir ļoti svarīgas, jo nepieder tikai vienam slānim. Tās caurvij visus slāņus.

Informācijas drošība un privātums

MI var apstrādāt sensitīvus datus, klientu informāciju, personas datus, līgumus, pirmkodu un komercnoslēpumus. Tāpēc informācijas drošība nav papildinājums. Tā ir pamatprasība.

Kvalitātes pārvaldība

MI atbilde var skanēt labi un tomēr būt nepareiza. Kvalitātes pārvaldība ietver testus, novērtēšanu, salīdzināšanu, atgriezenisko saiti, avotu pārbaudi un kļūdu uzskaiti.

Izmaksu pārvaldība

Tokeni, API izsaukumi, aģentu starpsoļi, RAG meklējumi un skaitļošana maksā. Ja izmaksām neseko, MI var izskatīties produktīvs, taču kļūt dārgs.

Uzraudzība un novērojamība

Novērojamība ir spēja redzēt, kas sistēmā notiek. MI gadījumā tas nozīmē, piemēram, zināt, ko modelis atbildēja, kādus avotus izmantoja, kurus rīkus aģents izsauca, kur radās kļūda un cik tas maksāja.

Prasmes un kultūra

MI nedod labumu, ja cilvēki to neprot izmantot vai kultūra kavē eksperimentēšanu. Vajadzīgas mācības, piemēri, iekšējā prakse un iedrošinājums.

Pārmaiņu vadība

MI maina lomas, procesus un darba sadali. Ja pārmaiņas atstāj atsevišķu cilvēku ziņā, rezultāti būs nevienmērīgi.

Ētika un regulējums

Jo vairāk MI ietekmē cilvēkus, lēmumus un sabiedrību, jo svarīgāk domāt par taisnīgumu, pārredzamību, atbildību un regulējumu.

Šīs caurviju spējas līdzinās ēkas nesošajām konstrukcijām. Tās nevar beigās pievienot kā dekorāciju.

16. Uzņēmumu skatījums: kā darbības slāņi maina stratēģiju?

MI darbības slāņi uzņēmumam sniedz praktisku karti. Tie palīdz saprast, kāpēc vieni MI projekti neizdodas, bet citi izdodas.

Neveiksmīgs MI projekts bieži koncentrējas uz vienu slāni. Nopērk lietotni, bet dati ir slikti. Izveido aģentu, bet trūkst integrāciju. Izvēlas jaudīgu modeli, bet process nemainās. Veic pilotprojektu, bet nemēra izmaksas. Apmāca darbiniekus, bet vadība nemainās.

Veiksmīgs MI projekts aplūko visu darbības ķēdi. Tas jautā: kādu biznesa problēmu risinām? Kuru procesu mainām? Kādi dati vajadzīgi? Kuru modeli izmantosim? Kurus rīkus MI drīkst lietot? Kur apstiprina cilvēks? Kā mēra kvalitāti? Kā redzamas izmaksas? Kas atbild par risinājumu? Kā to mērogot?

Tas maina arī budžeta plānošanu. MI nav tikai programmatūras licence. Tas apvieno licences, tokenu izmaksas, integrācijas, informācijas drošību, mācības, pārmaiņu darbu un uzraudzību.

Uzņēmumiem vērts sākt uztvert MI kā ieguldījumu produktivitātē. Ja speciālistu darba samaksa veido būtisku izmaksu daļu, ir loģiski apsvērt, kādu daļu no tās ieguldīt MI, lai uzlabotu darbinieku produktivitāti, kvalitāti un ātrumu. Tas nenozīmē tērēt neapdomīgi. Tas nozīmē padarīt MI izmaksas redzamas un tās pārvaldīt.

17. Jaunuzņēmumu skatījums: kur rodas jauna konkurences priekšrocība?

Jaunuzņēmumam MI darbības slāņi ir gan iespēja, gan brīdinājums. Iespēja, jo maza komanda var izveidot vairāk nekā jebkad agrāk. MI var palīdzēt programmēšanā, mārketingā, analīzē, klientu apkalpošanā, dokumentācijā, pārdošanā un iekšējos procesos. Brīdinājums, jo ar apgalvojumu “Mums ir MI” vairs nepietiek konkurences priekšrocībai.

Kad modeļi ir pieejami daudziem, vērtība rodas citur:

  • labākos datos
  • labākā darba plūsmā
  • nozares zināšanās
  • izplatīšanā
  • lietotāja saskarnē
  • uzticībā
  • integrācijās
  • aģentu orķestrēšanā
  • izmaksu efektivitātē
  • spējā atrisināt īstu problēmu

Jaunuzņēmums, kas no sākuma veidots uz MI pamata, nepievieno MI funkciju vecam produktam. Tas jautā: Kāda izskatītos šī nozare, ja to no pašiem pamatiem veidotu ap MI, aģentiem, automatizāciju un datiem?

Piemēram, juridisko tehnoloģiju jomā uz MI pamata veidots produkts nav tikai robots, kas atbild uz juridiskiem jautājumiem. Tā var būt darba plūsma, kas lasa līgumus, atpazīst riskus, salīdzina ar uzņēmuma vadlīnijām, iesaka labojumus, lūdz jurista apstiprinājumu un atjaunina līgumu datubāzi. Veselības aprūpē šāds risinājums nav tikai simptomu anketa, bet sistēma, kas palīdz speciālistam apkopot informāciju, analizēt attēlus, sagatavot norādījumus pacientiem un koordinēt aprūpes ceļu. B2B pārdošanā tas nav tikai e-pastu ģenerators, bet aģentu sistēma, kas seko signāliem, bagātina klientu datus, iesaka sazināties, sagatavo materiālus un atjaunina CRM.

Tātad jaunuzņēmumu konkurences priekšrocība rodas no tā, cik labi tie savieno slāņus. Ar MI izmantošanu vien nepietiek.

18. Darba pārmaiņas: kas cilvēkiem būs jāprot turpmāk?

MI darbības slāņi maina arī vajadzīgās prasmes. Ne visiem jāprot veidot modeļus. Ne visiem jāsaprot mikroshēmu arhitektūra. Ne visiem tehniski jāpārzina MCP. Taču arvien vairāk cilvēkiem jāsaprot, kur kopējā sistēmā atrodas viņu darbs.

Speciālistam jāsaprot, kā MI var palīdzēt viņa darba plūsmā. Vadītājam jāsaprot MI ietekme uz procesiem un izmaksām. Izstrādātājam jāprot savienot modeļus, datus un rīkus. Drošības speciālistiem jāsaprot aģentu tiesības. HR jāizprot prasmju pārmaiņas. Finanšu vadībai jāsaprot tokeni un MI izmaksas. Produktu vadībai jāsaprot, kā lietotne kļūst par aģentu sistēmu.

Nākotnes darbā īpaši svarīgas būs šādas prasmes:

  • problēmas definēšana
  • procesu sadalīšana posmos
  • MI iespēju atpazīšana
  • datu kvalitātes novērtēšana
  • avotu kritiska izvērtēšana
  • kvalitātes pārbaude
  • darba sadale starp cilvēku un MI
  • izpratne par automatizācijas robežām
  • izmaksu apzināšanās
  • ētisks izvērtējums
  • spēja pielāgoties pārmaiņām

Viena no svarīgākajām prasmēm ir atšķirt, ko vērts automatizēt un ko ne. Ne visu atkārtotu darbu var automātiski automatizēt. Ja darba posms skar cilvēku tiesības, drošību, veselību, naudu vai reputāciju, vajadzīga rūpīgāka uzraudzība.

MI neatceļ nepieciešamību spriest. Tas padara cilvēka spriedumu vēl svarīgāku.

19. Riski un klupšanas akmeņi

Domāšana MI darbības slāņos palīdz precīzāk saskatīt riskus. Risks nav tikai nepareiza MI atbilde. Riski rodas katrā slānī.

Infrastruktūras risks

Datu centru izmaksas, enerģijas patēriņš, jaudas trūkums un ģeopolitiskā atkarība var ietekmēt MI pieejamību un cenu.

Modeļa risks

Modelis var halucinēt, būt neobjektīvs, pārprast uzdevumu vai sniegt pārliecinošu, taču kļūdainu atbildi.

Datu risks

Uzņēmuma informācija var būt novecojusi, pretrunīga, nepilnīga vai aizsargāta ar nepareizām piekļuves tiesībām.

Integrācijas risks

MI var saņemt pārāk plašas tiesības vai nepareizi izmantot rīku. Uzvedņu injekcijas uzbrukumi var mēģināt panākt, lai aģents dara to, ko tam nevajadzētu darīt.

Aģenta risks

Aģents var virzīt uzdevumu nepareizā virzienā, veikt pārāk daudz starpsoļu, palielināt izmaksas vai radīt kļūdu ķēdi.

Lietotnes risks

Lietotājs var pārāk uzticēties MI atbildei, ja saskarne neparāda nenoteiktību, avotus vai vajadzību pēc apstiprinājuma.

Procesa risks

Vecu procesu var automatizēt nemainītu, lai gan tas jau sākotnēji ir slikts. Tad MI tikai paātrina sliktu darbību.

Vadības risks

Ja neviens neatbild par MI kopumā, organizācijā rodas ēnu MI, dublējoši rīki, neskaidra atbildība un nekontrolētas izmaksas.

Labā ziņa — šos riskus var pārvaldīt. Taču tikai tad, ja tos atpazīst katrā slānī.

20. Nākotne: MI kļūst par darba infrastruktūru

Nākamais MI posms nav tikai labāks tērzēšanas robots. Tā ir darba infrastruktūra. Nākotnē MI var piedalīties gandrīz visos zināšanu darba posmos: informācijas meklēšanā, analīzē, lēmumu sagatavošanā, programmēšanā, darbā ar klientiem, pārskatu veidošanā, mācībās, plānošanā un automatizācijā. Vienlaikus MI nonāk fiziskajā pasaulē: robotos, transportlīdzekļos, laboratorijās, rūpniecībā un loģistikā.

Tas nenozīmē, ka viss mainīsies vienā naktī. Ticamāka ir pakāpeniska attīstība pa slāņiem:

  1. Vispirms MI palīdz atsevišķiem darbiniekiem.
  2. Tad to iestrādā lietotnēs.
  3. Tad to savieno ar uzņēmuma datiem.
  4. Tad tas saņem ierobežotus savienojumus ar rīkiem.
  5. Tad rodas aģenti.
  6. Tad aģentus orķestrē procesos.
  7. Visbeidzot sāk mainīties uzņēmuma darbības modelis.

Lielākā atšķirība no šodienas būs tā, ka MI nepaliks atsevišķs rīks. Tas iekļausies sistēmās, procesos un lēmumu pieņemšanā. Tad jautājums vairs nebūs “Vai mēs izmantojam MI?”, bet gan: “Kā MI ir iestrādāts mūsu darba veidā?”

21. Secinājumi

MI darbības slāņi sniedz karti MI pārmaiņām. Tie palīdz saprast, ka MI nav tikai tērzēšanas robots, valodas modelis vai atsevišķa lietotne. Tā ir vesela sistēma, kurā savienojas enerģija, datu centri, mikroshēmas, mākonis, modeļi, optimizācija, dati, integrācijas, aģenti, programmatūra, procesi, robotika un vadība.

Svarīgākā atziņa ir šāda: MI vērtība rodas slāņu mijiedarbībā. Ar jaudīgu modeli vien nepietiek. Nepietiek tikai ar datiem, integrāciju, aģentu vai lietotni. Vajadzīgs kopums.

Uzņēmumiem tas nozīmē, ka MI stratēģijai jābūt plašākai par rīku sarakstu. Tai jāparāda MI saistība ar infrastruktūru, datiem, procesiem, cilvēkiem, izmaksām, riskiem un vadību. Jaunuzņēmumiem konkurences priekšrocību arvien biežāk rada slāņu savienošana — labāka modeļu, datu, darba plūsmu, integrāciju un lietošanas pieredzes apvienošana. Cilvēkiem tas nozīmē, ka MI pratība vairs nav tikai uzvedņu rakstīšana. Tā ir spēja saprast, kurā darbības ķēdes vietā MI darbojas, kas tam vajadzīgs panākumiem un kur cilvēkam jāvada, jāvērtē un jāuzņemas atbildība.

MI nākotne nav viena supergudra poga. Tā ir jauna darbības vide. Tajā sekmēsies tiem, kuri saprot kopumu.

22. Praktiski modeļi un darba veidnes

1. MI darbības slāņu kontrolsaraksts

Izmanto to, izvērtējot MI risinājumu vai plānojot jaunu lietojumu.

Infrastruktūra un skaitļošana

  • Kur risinājums darbojas?
  • Kāda skaitļošana tam vajadzīga?
  • Kā izmaksas mainās, pieaugot mērogam?
  • Vai aizkave ir pieņemama?
  • Vai risinājums ir atkarīgs no viena piegādātāja?

Modeļi

  • Kuru modeli izmanto?
  • Kāpēc tieši šo modeli?
  • Vai uzdevums ir vienkāršs vai prasa padziļinātu spriešanu?
  • Vai modelis ir testēts ar pašu materiāliem?
  • Kā uzrauga modeļa kvalitāti?

Dati un konteksts

  • Kādi dati vajadzīgi?
  • Vai dati ir aktuāli?
  • Kam dati pieder?
  • Kā darbojas piekļuves tiesības?
  • Vai lietotājam parāda avotus?

Integrācijas un rīki

  • Kurām sistēmām MI var piekļūt?
  • Vai tas drīkst tikai lasīt vai arī mainīt?
  • Kad vajadzīgs apstiprinājums?
  • Kā lietošanu reģistrē žurnālos?
  • Kā ierobežo tiesības?

Aģenti un orķestrēšana

  • Vai tā ir atsevišķa atbilde vai vairāku posmu uzdevums?
  • Kurus posmus veic MI?
  • Kurus posmus veic cilvēks?
  • Kas notiek kļūdas gadījumā?
  • Vai aģentam ir izmaksu limits?

Lietotne un lietošanas pieredze

  • Kā lietotājs saprot, ko MI paveica?
  • Vai redzami avoti, neskaidrības un nākamie soļi?
  • Vai rezultātu ir viegli pārbaudīt?
  • Vai lietotājs var labot vai noraidīt priekšlikumu?

Process un bizness

  • Kuru procesu uzlabo?
  • Kurš rādītājs mainās?
  • Vai tiek ietaupīts laiks?
  • Vai uzlabojas kvalitāte?
  • Vai klientu apkalpošana kļūst ātrāka?
  • Vai samazinās manuālais darbs?

Vadība un atbildība

  • Kas atbild par risinājumu?
  • Kas atbild par kļūdām?
  • Kā uzrauga lietošanu?
  • Kā ziņo par izmaksām?
  • Kā auditē risinājumu?

2. AI-first procesa modelis

Izvēlies vienu uzņēmuma procesu un izskati to šādi:

  1. Kāds ir procesa mērķis?
  2. Kuri posmi atkārtojas?
  3. Kur vajadzīga informācija?
  4. Kur nepieciešams cilvēka vērtējums?
  5. Kur MI var sagatavot pirmo versiju?
  6. Kur MI var meklēt informāciju?
  7. Kur MI var izmantot rīku?
  8. Kur MI var automātiski izpildīt posmu?
  9. Kur nepieciešams apstiprinājums?
  10. Kā mēra rezultātu?

Šī modeļa mērķis nav automatizēt visu. Tā mērķis ir atrast pareizo darba sadali starp cilvēku, MI un sistēmām.

3. Atbildības modelis pa slāņiem

Katram slānim vērts noteikt atbildīgo.

SlānisGalvenais jautājumsIespējamais atbildīgais
Enerģija un datu centriKā nodrošina jaudu un atbildīgu darbību?IT / infrastruktūra / iepirkumi
Mikroshēmas un skaitļošanaKā optimizē skaitļošanu?tehnoloģiju vadība
Mākonis un datu glabāšanaKur atrodas dati un pakalpojumi?IT arhitektūra
ModeļiKādus modeļus izmanto un kāpēc?MI komanda / izstrāde
OptimizācijaKā līdzsvaro kvalitāti, ātrumu un cenu?MI inženierija
Dati un RAGKur iegūst informāciju, un vai tā ir uzticama?par datiem atbildīgie
MCP un integrācijasKam MI var piekļūt?IT / informācijas drošība
Orķestrēšana un aģentiKurš ko dara un ar kādām tiesībām?MI produkta īpašnieks
LietotnesKā lietotājs uztver MI?produktu vadība
ProcesiKurš darbs mainās?biznesa vadība
Fiziskais MIKā nodrošina drošību?operatīvā vadība
Vadība un atbildībaKas uzņemas kopējo atbildību?vadības komanda

4. Aģenta ieviešanas minimālais modelis

Pirms aģentu pielaiž īstam darbam, nosaki tā mērķi, izmantojamos datu avotus un rīkus, tiesības, aizliegtās darbības, apstiprinājuma punktus, izmaksu limitu, žurnalēšanu, kvalitātes rādītājus, atbildīgo un izslēgšanas mehānismu.

Ja aģentam nav atbildīgā, to nevajadzētu nodot ekspluatācijā.

5. Jautājumi vadībai

Vadības komandai regulāri jāvaicā:

  1. Kuros procesos MI jau dod izmērāmu labumu?
  2. Kur MI vēl ir tikai eksperiments?
  3. Kādi dati MI vajadzīgi, bet vēl nav pieejami?
  4. Kuras integrācijas dotu lielāko ieguvumu?
  5. Kur aģenti varētu droši veikt darbu?
  6. Kur cilvēka apstiprinājums ir obligāts?
  7. Cik MI maksā mēnesī?
  8. Kā mainās tokenu izmaksas?
  9. Kādas kļūdas MI pieļauj?
  10. Kas atbild par MI kvalitāti un riskiem?
  11. Kādu prasmju organizācijā trūkst?
  12. Kuru procesu mēs vairs neveidotu pa vecam?

6. Praktisks padoms

Izvērtējot MI risinājumu, neskaties tikai uz saskarni vai modeļa nosaukumu. Izvaicā visu darbības ķēdi:

“Kāda infrastruktūra tam vajadzīga, kādus datus tas izmanto, kurām sistēmām drīkst piekļūt, kurus darba posmus spēj veikt, kas uzrauga darbību un kā mēra ieguvumus, kvalitāti, izmaksas un riskus?”

Tieši te rodas atšķirība starp MI eksperimentu un reālu MI veiktspēju.

Avoti

  1. Intervija ar Nvidia izpilddirektoru Jensen Huang par MI slāņveida uzbūvi (YouTube)
Atvērt MI asistenta tērzēšanu. Tērzēšana tiek ielādēta tikai tad, kad to atverat.