Kas ir mākslīgais intelekts mākoņdatošanā?

Kas ir mākslīgais intelekts mākoņdatošanā?

Īsa atbilde: mākslīgais intelekts mākoņdatošanā ir par mākoņplatformu izmantošanu datu glabāšanai, skaitļošanas resursu nomai, modeļu apmācībai, to izvietošanai kā pakalpojumiem un uzraudzībai ražošanas vidē. Tas ir svarīgi, jo lielākā daļa kļūmju rodas saistībā ar datiem, izvietošanu un darbībām, nevis matemātiku. Ja nepieciešama ātra mērogošana vai atkārtojamas versijas, mākonis + MLOps ir praktisks risinājums.

Galvenie secinājumi:

Dzīves cikls: datu ievākšana, funkciju izveide, apmācība, izvietošana un pēc tam nobīdes, latentuma un izmaksu uzraudzība.

Pārvaldība: jau no paša sākuma iestrādājiet piekļuves kontroles, audita žurnālus un vides atdalīšanu.

Atkārtojamība: Ierakstiet datu versijas, kodu, parametrus un vides, lai palaišanas būtu atkārtojamas.

Izmaksu kontrole: izmantojiet partijveida apstrādi, kešatmiņu, automātiskās mērogošanas ierobežojumus un lokālo/preemptīvo apmācību, lai izvairītos no rēķinu šokiem.

Izvietošanas modeļi: izvēlieties pārvaldītas platformas, Lakehouse darbplūsmas, Kubernetes vai RAG, pamatojoties uz komandas realitāti.

Kas ir mākslīgais intelekts mākoņdatošanā? Infografika

Raksti, kurus jūs varētu vēlēties izlasīt pēc šī raksta:

🔗 Labākie AI mākoņdatošanas biznesa pārvaldības rīki
Salīdziniet vadošās mākoņplatformas, kas racionalizē darbības, finanses un komandas.

🔗 Tehnoloģijas, kas nepieciešamas liela mēroga ģeneratīvajam mākslīgajam intelektam
Galvenā infrastruktūra, dati un pārvaldība, kas nepieciešama GenAI ieviešanai.

🔗 Bezmaksas mākslīgā intelekta rīki datu analīzei
Labākie bezmaksas mākslīgā intelekta risinājumi datu kopu tīrīšanai, modelēšanai un vizualizācijai.

🔗 Kas ir mākslīgais intelekts kā pakalpojums?
Izskaidro AIaaS, priekšrocības, cenu noteikšanas modeļus un izplatītākos uzņēmējdarbības lietošanas gadījumus.

Mākslīgais intelekts mākoņdatošanā: vienkārša definīcija 🧠☁️

Pēc būtības mākslīgais intelekts mākoņdatošanā nozīmē mākoņplatformu izmantošanu, lai piekļūtu:

Tā vietā, lai iegādātos savu dārgo aprīkojumu, jūs īrējat to, kas jums nepieciešams, kad tas jums nepieciešams NIST SP 800-145. Tas ir līdzīgi kā sporta zāles īrēšana vienam intensīvam treniņam, nevis sporta zāles uzbūvēšana garāžā un pēc tam skrejceliņa neizmantošana. Tas notiek ar labākajiem no mums 😬

Vienkārši sakot: tā ir mākslīgā intelekta sistēma, kas mērogojas, tiek piegādāta, atjaunināta un darbojas, izmantojot mākoņinfrastruktūru NIST SP 800-145.

Kāpēc mākslīgais intelekts + mākonis ir tik svarīgi 🚀

Būsim atklāti – vairums mākslīgā intelekta projektu neizdodas tāpēc, ka matemātika ir sarežģīta. Tie neizdodas tāpēc, ka “lietas ap modeli” sapinas:

  • dati ir izkliedēti

  • vides nesakrīt

  • modelis darbojas kāda klēpjdatorā, bet nekur citur

  • izvietošana tiek uzskatīta par pēcdomu

  • Drošība un atbilstība parādās vēlu kā nelūgts brālēns 😵

Mākoņplatformas ir noderīgas, jo tās piedāvā:

1) Elastīga zvīņa 📈

Īsu brīdi apmāciet modeli lielā klasterī un pēc tam izslēdziet to (NIST SP 800-145).

2) Ātrāka eksperimentēšana ⚡

Ātri palaidiet pārvaldītās piezīmju grāmatiņas, iepriekš izveidotus cauruļvadus un GPU instances Google mākonī: GPU mākslīgajam intelektam.

3) Vienkāršāka izvietošana 🌍

Izvietojiet modeļus kā API, pakešuzdevumus vai iegultos pakalpojumus. Red Hat: Kas ir REST API? SageMaker Batch Transform.

4) Integrētas datu ekosistēmas 🧺

Jūsu datu cauruļvadi, noliktavas un analītika bieži vien jau atrodas mākonī. AWS: datu noliktava vs datu ezers.

5) Sadarbība un pārvaldība 🧩

Atļaujas, audita žurnāli, versiju pārvaldība un koplietotie rīki ir iebūvēti (dažreiz sāpīgi, bet tomēr) Azure ML reģistros (MLOps).

Kā mākslīgais intelekts mākoņdatošanā darbojas praksē (īstā plūsma) 🔁

Lūk, vispārpieņemtais dzīves cikls. Nevis “ideālās diagrammas” versija… tā, kurā viss tiek lietots.

1. darbība: dati nonāk mākoņkrātuvē 🪣

Piemēri: objektu krātuves konteineri, datu ezeri, mākoņdatu bāzes Amazon S3 (objektu krātuve) AWS: Kas ir datu ezers? Google mākoņkrātuves pārskats.

2. solis: datu apstrāde + funkciju veidošana 🍳

Tu to tīri, pārveido, izveido funkcijas, varbūt straumē.

3. solis: Modeļa apmācība 🏋️

Jūs izmantojat mākoņdatošanu (bieži vien GPU), lai apmācītu Google Cloud: GPU darbam ar mākslīgo intelektu:

4. solis: izvietošana 🚢

Modeļi tiek iesaiņoti un piegādāti, izmantojot:

5. darbība: uzraudzība + atjauninājumi 👀

Trase:

Tas ir dzinējspēks. Tā ir mākslīgā intelekta izmantošana mākoņdatošanā darbībā, ne tikai kā definīcija.

Kas veido labu mākslīgā intelekta versiju mākoņdatošanā? ✅☁️🤖

Ja vēlaties “labu” ieviešanu (ne tikai uzkrītošu demonstrāciju), koncentrējieties uz šiem aspektiem:

A) Skaidra problēmu nodalīšana 🧱

  • datu slānis (krātuve, pārvaldība)

  • apmācības slānis (eksperimenti, cauruļvadi)

  • apkalpojošais slānis (API, mērogošana)

  • uzraudzības slānis (metrika, žurnāli, brīdinājumi) SageMaker modeļa monitors

Kad viss tiek samīcīts kopā, atkļūdošana rada emocionālu kaitējumu.

B) Reproducējamība pēc noklusējuma 🧪

Laba sistēma ļauj bez roku vicināšanas norādīt:

  • dati, kas apmācīja šo modeli

  • koda versija

  • hiperparametri

  • vide

Ja atbilde ir "ēē, man šķiet, ka tas bija otrdienas skrējiens...", tad jau esi iekūlies nepatikšanās 😅

C) Izmaksu ziņā apzinīgs dizains 💸

Mākoņpakalpojumu mākslīgais intelekts ir spēcīgs, taču tas ir arī vienkāršākais veids, kā nejauši izveidot rēķinu, kas liek apšaubīt savas dzīves izvēles.

Labi iestatījumi ietver:

D) Drošība un atbilstība ir iebūvēta 🔐

Netiek vēlāk pieskrūvēta kā līmlente uz tekošas caurules.

E) Reāls ceļš no prototipa līdz ražošanai 🛣️

Šis ir galvenais. Laba mākslīgā intelekta “versija” mākonī ietver MLOps, izvietošanas modeļus un uzraudzību jau no paša sākuma. Google Cloud: Kas ir MLOps?Citādi tas ir zinātnes izstādes projekts ar izsmalcinātu rēķinu.

Salīdzināšanas tabula: populāras mākslīgā intelekta mākoņpakalpojumu iespējas (un kam tās paredzētas) 🧰📊

Zemāk ir īsa, nedaudz viedokļu ziņā ierobežota tabula. Cenas ir apzināti plašas, jo cenu noteikšana mākoņpakalpojumos ir kā kafijas pasūtīšana — bāzes cena nekad nav cena 😵💫

Rīks/platforma Auditorija Dārgs Kāpēc tas darbojas (iekļautas dīvainas piezīmes)
AWS SageMaker ML komandas, uzņēmumi Priekšapmaksa Pilna steka mašīnmācīšanās platforma — apmācība, galapunkti, cauruļvadi. Jaudīga, bet izvēlnes visur.
Google Vertex mākslīgais intelekts Mašīnmācīšanās komandas, datu zinātnes organizācijas Priekšapmaksa Spēcīga pārvaldīta apmācība + modeļu reģistrs + integrācijas. Jūtas vienmērīgi, kad noklikšķ.
Azure mašīnmācīšanās Uzņēmumi, uz MS orientētas organizācijas Priekšapmaksa Lieliski sader ar Azure ekosistēmu. Labas pārvaldības iespējas, daudz pogu.
Databricks (ML + Lakehouse) Datu inženierijas smagās komandas Abonements + lietošana Lieliski piemērots datu plūsmu un mašīnmācīšanās apvienošanai vienuviet. Bieži vien iecienīts praktisku komandu vidū.
Sniegpārslas mākslīgā intelekta funkcijas Analītikai orientētas organizācijas Lietošanas pamatā Labi, ja tava pasaule jau atrodas noliktavā. Mazāk “ML laboratorijas”, vairāk “mākslīgā intelekta SQL vidē”
IBM watsonx Regulētās nozares Uzņēmuma cenu noteikšana Liela uzmanība tiek pievērsta pārvaldībai un uzņēmuma kontrolei. Bieži tiek izvēlēta situācijām, kurās ir liela politikas ietekme.
Pārvaldīts Kubernetes (DIY ML) Platformu inženieri Mainīgais Elastīgs un pielāgots. Turklāt… jūs pats uzņematies sāpes, kad tas saplīst 🙃
Serveru nesaturoša secinājumu veikšana (funkcijas + galapunkti) Produktu komandas Lietošanas pamatā Lieliski piemērots intensīvai satiksmei. Vērojiet auksto startu un latentumu kā vanags.

Šeit nav runa par “labākā” izvēli — runa ir par atbilstību komandas realitātei. Tas ir klusais noslēpums.

Biežāk sastopamie mākslīgā intelekta lietošanas gadījumi mākoņdatošanā (ar piemēriem) 🧩✨

Lūk, kur izcili ir mākslīgā intelekta mākoņpakalpojumi:

1) Klientu atbalsta automatizācija 💬

2) Ieteikumu sistēmas 🛒

  • produktu ieteikumi

  • satura plūsmas

  • “cilvēki arī iegādājās”.
    Šiem risinājumiem bieži vien ir nepieciešama mērogojama secinājumu veikšana un gandrīz reāllaika atjauninājumi.

3) Krāpšanas atklāšana un riska novērtēšana 🕵️

Mākonis atvieglo datu pārraides impulsu apstrādi, notikumu straumēšanu un ansambļu vadīšanu.

4) Dokumentu izlūkošana 📄

  • OCR cauruļvadi

  • vienību ieguve

  • līgumu analīze

  • rēķinu parsēšana Snowflake Cortex AI funkcijas
    Daudzās organizācijās tieši šeit laiks tiek klusi atdots atpakaļ.

5) Prognozēšana un uz kompetenci vērsta optimizācija 📦

Pieprasījuma prognozēšana, krājumu plānošana, maršrutu optimizācija. Mākonis palīdz, jo datu apjoms ir liels un atkārtota apmācība ir nepieciešama bieži.

6) Ģeneratīvās mākslīgā intelekta lietotnes 🪄

  • satura izstrāde

  • koda palīdzība

  • iekšējie zināšanu roboti (RAG)

  • sintētisko datu ģenerēšana , paplašinātās ģenerēšanas (RAG) dokuments.
    Šis bieži vien ir brīdis, kad uzņēmumi beidzot saka: “Mums jāzina, kur atrodas mūsu datu piekļuves noteikumi.” 😬

Arhitektūras raksti, ko redzēsiet visur 🏗️

1. modelis: pārvaldīta mašīnmācīšanās platforma (ceļš “mēs vēlamies mazāk galvassāpju”) 😌

Labi darbojas, ja svarīgs ir ātrums un nevēlaties veidot iekšējos instrumentus no nulles.

2. modelis: Lakehouse + mašīnmācīšanās (maršruts “dati pirmajā vietā”) 🏞️

  • apvienojiet datu inženierijas un mašīnmācīšanās darbplūsmas

  • palaist piezīmju grāmatiņas, cauruļvadus, funkciju izstrādi datu tuvumā

  • spēcīgs risinājums organizācijām, kas jau darbojas lielās analītikas sistēmās Databricks Lakehouse

3. shēma: konteinerizēta mašīnmācīšanās Kubernetes platformā (maršruts “mēs vēlamies kontroli”) 🎛️

Pazīstams arī kā: “Mēs esam pārliecināti, un mums patīk atkļūdot neparastā laikā.”

4. modelis: RAG (atgūšanas papildinātā ģenerēšana) (ceļš “izmantojiet savas zināšanas”) 📚🤝

Šī ir būtiska mūsdienu sarunu par mākslīgo intelektu mākonī sastāvdaļa, jo tieši tā daudzi reāli uzņēmumi droši izmanto ģeneratīvo mākslīgo intelektu.

MLOps: Daļa, ko visi nenovērtē 🧯

Ja vēlaties, lai mākslīgais intelekts mākonī darbotos atbilstoši ražošanas videi, jums ir nepieciešams MLOps. Ne tāpēc, ka tas ir moderni, bet gan tāpēc, ka modeļi dreifē, dati mainās un lietotāji ir radoši vissliktākajā veidā. Google mākonis: Kas ir MLOps?.

Galvenās detaļas:

Ja to ignorēsi, beigās iegūsi “modeļa zoodārzu” 🦓, kur viss ir dzīvs, nekas nav marķēts un tev ir bail atvērt vārtus.

Drošība, privātums un atbilstība (ne pati jautrākā daļa, bet… jā) 🔐😅

Mākslīgais intelekts mākoņdatošanā rada dažus asus jautājumus:

Datu piekļuves kontrole 🧾

Kas var piekļūt apmācības datiem? Secinājumu žurnāliem? Uzvednēm? Izvades datiem?

Šifrēšana un noslēpumi 🗝️

Atslēgas, žetoni un akreditācijas dati ir jāapstrādā pareizi. “Konfigurācijas failā” netiek uzskatīta par apstrādi.

Izolācija un īrniecība 🧱

Dažām organizācijām ir nepieciešamas atsevišķas vides izstrādei, izmēģinājuma versijas izveidei un ražošanai. Mākonis palīdz — bet tikai tad, ja tas ir pareizi iestatīts.

Auditējamība 📋

Regulētām organizācijām bieži vien ir jāuzrāda:

  • kādi dati tika izmantoti

  • kā tika pieņemti lēmumi

  • Kas ko izvietoja

  • kad tas mainīja IBM watsonx.governance

Modeļa riska pārvaldība ⚠️

Tas ietver:

  • aizspriedumu pārbaudes

  • pretrunīga testēšana

  • ātra injekcijas aizsardzība (ģeneratīvajam mākslīgajam intelektam)

  • droša izejas filtrēšana

Tas viss atgriežas pie būtības: tā nav tikai “tiešsaistē mitināta mākslīgā intelekta” darbība. Tā ir mākslīgā intelekta darbība reālu ierobežojumu apstākļos.

Padomi par izmaksām un veiktspēju (lai vēlāk neraudātu) 💸😵💫

Daži kaujas apstākļos pārbaudīti padomi:

  • Izmantojiet mazāko modeli, kas atbilst vajadzībām.
    Lielāks ne vienmēr ir labāks. Dažreiz tas vienkārši ir… lielāks.

  • Partiju secinājumu veikšana, ja iespējams.
    Lētāka un efektīvāka SageMaker partiju transformācija.

  • Kešatmiņā saglabāt agresīvi.
    Īpaši atkārtotiem vaicājumiem un iegulšanai.

  • Automātiska mērogošana, bet ierobežojiet to
    Neierobežota mērogošana var nozīmēt neierobežotus tēriņus Kubernetes: horizontāla poda automātiskā mērogošana. Jautājiet man, kā es to zinu… patiesībā, nejautājiet 😬

  • Izsekojiet izmaksas par katru galapunktu un katru funkciju.
    Pretējā gadījumā jūs optimizēsit nepareizo lietu.

  • Apmācībai izmantojiet vietas apsteidzošus aprēķinus.
    Lieliski ietaupījumi, ja jūsu apmācības darbi var apstrādāt pārtraukumus. Amazon EC2 vietas instances, Google Cloud apsteidzošas virtuālās mašīnas.

Kļūdas, ko cilvēki pieļauj (pat gudras komandas) 🤦♂️

  • Uztvert mākoņa mākslīgo intelektu kā "vienkārši pievienot modeli"

  • Datu kvalitātes ignorēšana līdz pēdējam brīdim

  • Modeļa nosūtīšana bez SageMaker Model Monitor

  • Neplānoju pārkvalificēties ritmam Google Cloud: Kas ir MLOps?

  • Aizmirstot, ka drošības komandas pastāv līdz pat palaišanas nedēļai 😬

  • Pārāk sarežģīta inženierija jau no pirmās dienas (dažreiz uzvar vienkārša bāzes līnija)

Un vēl viena klusa un nežēlīga problēma: komandas nenovērtē, cik ļoti lietotāji nicina latentumu. Bieži vien uzvar modelis, kas ir nedaudz mazāk precīzs, bet ātrs. Cilvēki ir nepacietīgi mazi brīnumi.

Svarīgākie secinājumi 🧾✅

Mākslīgais intelekts mākoņdatošanā ir pilnīga mākslīgā intelekta veidošanas un darbināšanas prakse, izmantojot mākoņinfrastruktūru — apmācības mērogošana, izvietošanas vienkāršošana, datu plūsmu integrēšana un modeļu ieviešana darbībā ar MLOps, drošību un pārvaldību. Google Cloud: Kas ir MLOps? NIST SP 800-145.

Īss kopsavilkums:

  • Mākonis nodrošina mākslīgā intelekta infrastruktūru mērogošanai un izplatīšanai 🚀 NIST SP 800-145

  • Mākslīgais intelekts mākoņa darba slodzēm piešķir “smadzenes”, kas automatizē lēmumu pieņemšanu 🤖

  • Maģija nav tikai apmācība — tā ir izvietošana, uzraudzība un pārvaldība 🧠🔐 SageMaker modeļu monitors

  • Izvēlieties platformas, pamatojoties uz komandas vajadzībām, nevis mārketinga miglu 📌

  • Vērojiet izmaksas un darbības kā vanags ar brillēm 🦅👓 (slikta metafora, bet jūs sapratāt)

Ja jūs šeit ieradāties, domājot, ka “mākslīgais intelekts mākoņdatošanā ir tikai API modelis”, tad nē – tā ir vesela ekosistēma. Dažreiz eleganta, dažreiz turbulenta, dažreiz abas vienā pēcpusdienā.

Reālās pasaules piemērs: mākoņa mākslīgā intelekta atbalsta pieprasījumu triāžas asistenta izveide 🎫☁️

Scenārijs

Iedomājieties SaaS uzņēmumu ar 40 cilvēkiem, kas nedēļā saņem aptuveni 180 klientu atbalsta pieprasījumus. Atbalsta komanda izmanto palīdzības dienesta rīku, taču katru pirmdienas rītu kādam joprojām ir jāizlasa jauni pieprasījumi, jāizlemj kategorija, jāiestata steidzamība, jāpārbauda, ​​vai klientam ir maksas plāns, un jānosūta problēma norēķinu, produktu, inženierijas vai vispārējā atbalsta nodaļai.

Uzņēmumam nav nepieciešama milzīga mākslīgā intelekta sistēma. Tam ir nepieciešama neliela mākoņpakalpojumos balstīta mākslīgā intelekta darbplūsma, kas var klasificēt pieprasījumus, apkopot problēmu, ieteikt nākamo darbību un atzīmēt riskantus gadījumus cilvēku pārskatīšanai.

Praktiska iestatīšana varētu izskatīties šādi:

Biļetes tiek eksportētas uz mākoņkrātuvi katru stundu

bezservera darbs attīra pieteikuma tekstu un noņem nevajadzīgus personas datus

klasifikācijas modelis vai mitinātās valodas modelis apzīmē biļeti

rezultāti tiek ierakstīti atpakaļ palīdzības dienesta sistēmā

Informācijas panelis izseko latentumu, ticamības rādītājus, maršrutēšanas precizitāti un izmaksas par biļeti

Galvenais: mākslīgais intelekts neaizstāj atbalsta komandu. Tas samazina atkārtoto šķirošanas darbu, lai cilvēki vairāk laika veltītu faktiskās problēmas risināšanai.

Kas asistentam ir nepieciešams

Lai tas labi izdotos, komandai jāsagatavojas:

biļešu kategoriju saraksts, piemēram, Rēķini, Pieteikšanās, Kļūda, Funkciju pieprasījums, Atcelšana, Drošība un Vispārīgi

20–50 reālu iepriekšējo biļešu piemēri katrā kategorijā

katras nodaļas maršrutēšanas noteikumi

prioritātes noteikumi, piemēram, “drošības problēma = steidzama” vai “uzņēmuma klienta elektroenerģijas padeves pārtraukums = steidzama”

īss saraksts ar lietām, ko asistents nekad nedrīkst darīt, piemēram, solīt atmaksu, atzīt juridisko vainu vai mainīt konta iestatījumus

piekļuves kontroles, lai mākslīgā intelekta darbplūsma redzētu tikai tos biļešu laukus, kas tai patiešām nepieciešami

rezerves noteikums neskaidriem gadījumiem

Vienkāršs rezerves noteikums varētu būt:

Ja ticamības līmenis ir zem 80% vai pieprasījumā ir minēti juridiskie, drošības, atmaksas, atcelšanas, datu noplūdes vai medicīniska/finansiāla kaitējuma jautājumi, nosūtiet to cilvēkam, kurš veic pārskatīšanu, nevis izmantojiet automātisko maršrutēšanu.

Instrukcijas piemērs

Jūs esat atbalsta pieprasījumu triāžas asistents B2B SaaS uzņēmumā.

Izlasiet klienta ziņojumu un atgrieziet:

  1. Vienteikuma kopsavilkums par problēmu

  2. Viena kategorija no šī saraksta: Norēķini, Pieteikšanās, Kļūda, Funkciju pieprasījums, Atcelšana, Drošība, Vispārīgi

  3. Prioritāte: Zema, Vidēja, Augsta vai Steidzama

  4. Labākā komanda, kas ar to tiks galā: Atbalsts, Rēķini, Produkti, Inženierija, Drošība vai Klientu apkalpošana

  5. Vai nepieciešama cilvēka veikta pārskatīšana: Jā vai Nē

  6. Īss jūsu lēmuma iemesls

Noteikumi:

Nesoliet naudas atmaksu.
Nenoskaidrojiet juridisko vai drošības atbildību. Neizdomājiet
konta informāciju.
Ja ziņojums nav skaidrs, izvēlieties “Vispārīgi” un pieprasiet cilvēka pārskatīšanu.
Ja klients piemin datu noplūdi, konta pārņemšanu, maksājuma neizdošanos vai pakalpojuma pārtraukumu, pieprasiet cilvēka pārskatīšanu.

Kā to pārbaudīt

Pirms ieviešanas ražošanā, pārbaudiet to ar nelielu reālu vai anonimizētu vēsturisku biļešu kopu.

Izmantojiet 100 iepriekšējās biļetes un salīdziniet asistenta maršrutu ar komandas sākotnējo maršrutēšanas lēmumu.

Pārbaudiet:

cik kategoriju atbilda cilvēka etiķetei

cik steidzamu pieprasījumu tika pareizi eskalēti

cik daudz zemas prioritātes biļešu tika kļūdaini atzīmētas kā steidzamas

vai sensitīvas biļetes tika nosūtītas cilvēku pārskatīšanai

vidējais vienas biļetes apstrādes laiks

cena par 100 biļetēm

Pēc tam veiciet otro testu ar nekārtīgiem piemēriem:

klients raksta ar lielajiem burtiem

biļete satur trīs problēmas vienlaikus

ziņojums ir tikai divus vārdus garš, piemēram, “nevar pieteikties”

lietotājs pieprasa atmaksu un draud ar tiesvedību

klients ziņo par iespējamu drošības incidentu

Šie testi ir svarīgi, jo tīras demonstrācijas biļetes ir viegli izveidot. Reāli lietotāji raksta nesakārtoti, ar nabadzīgu kontekstu un neparedzamām pieturzīmēm.

Rezultāts

Ilustratīvais rezultāts: balstīts uz piecu uzdevumu manuālās triāžas parauga laika mērīšanu pirms un pēc šīs darbplūsmas izmantošanas.

Manuāls process:

180 biļetes nedēļā
Vidējais manuālās atlases laiks: 2 minūtes 30 sekundes uz vienu biļeti
Kopējais atlases laiks: 450 minūtes nedēļā jeb 7,5 stundas

Mākoņa mākslīgā intelekta atbalstīts process:

Vidējais mākslīgā intelekta apstrādes laiks: mazāk nekā 10 sekundes uz vienu biļeti
Vidējais cilvēka pārskatīšanas laiks atzīmētajām biļetēm: 1 minūte 30 sekundes
Cilvēka pārskatīšanas līmenis: 25% biļešu
Paredzamais nedēļas atlases laiks: 67,5 minūtes

Tas ļauj ietaupīt aptuveni 6,4 stundas nedēļā.

Precizitāte jāmēra atsevišķi. Reālistiskā testā komanda varētu iestatīt palaišanas noteikumu, piemēram:

vismaz 90% kategorijas atbilstība cilvēku izmantotajām etiķetēm

100% ar drošību saistīto pieprasījumu nosūtīti cilvēku pārskatīšanai

mazāk nekā 5% biļešu tika novirzītas uz nepareizo nodaļu

vidējās izmaksas zem £0,05 par biļeti

Ja asistents neatbilst šiem skaitļiem testa komplektā, tam vajadzētu palikt pārskatīšanas režīmā, nevis automātiski novirzīt tiešraides pieprasījumus.

Kas var noiet greizi

Visbiežāk sastopamā kļūme ir neskaidras kategorijas. Ja “Kļūda”, “Tehniska problēma” un “Produkta problēma” nozīmē aptuveni vienu un to pašu, asistents klasificēs nekonsekventi.

Vēl viens risks ir pārmērīga automatizācija. Problēmas ar pieteikumu par to, ka “manam kontam piekļuva kāds cits”, nevajadzētu tikt nosūtīta nejauši kā parasta pieteikšanās problēma. Tam nepieciešama eskalācija, reģistrēšana un, iespējams, drošības darbplūsma.

Nepareiza reģistrēšana var radīt arī privātuma problēmas. Uzvednes, pieteikuma teksts, modeļa izvades un kļūdu izsekošanas dati var saturēt sensitīvus klientu datus. Saglabājiet tikai nepieciešamo informāciju, ierobežojiet piekļuvi un iestatiet saglabāšanas noteikumus.

Arī izmaksas var nedaudz pieaugt. Ja katra biļete tiek nosūtīta uz lielu modeli, kad darbotos mazāks klasifikators, sistēma kļūst nevajadzīgi dārga. Sāciet ar mazāko uzticamāko variantu un pēc tam jauniniet tikai tur, kur precizitāte patiešām uzlabojas.

Praktiska līdzņemšana

Labs mākoņa mākslīgā intelekta iestatījums sākas ar nelielu apjomu: viena darbplūsma, skaidri noteikumi, testēšanas dati, cilvēka veikta pārskatīšana un izmērāmi mērķi. Atbalsta triāžas gadījumā ieguvums nav “mākslīgais intelekts visu apstrādā”. Ieguvums ir ātrāka šķirošana, mazāk neatbildētu steidzamu pieprasījumu, skaidrāka nodošana un sistēma, ko komanda var uzraudzīt, nevis akli uzticēties.

Bieži uzdotie jautājumi

Ko ikdienas izpratnē nozīmē “mākslīgais intelekts mākoņdatošanā”

Mākslīgais intelekts mākoņdatošanā nozīmē, ka jūs izmantojat mākoņplatformas, lai glabātu datus, aktivizētu skaitļošanas procesus (CPU/GPU/TPU), apmācītu modeļus, tos izvietotu un uzraudzītu — nepiederot aparatūrai. Praksē mākonis kļūst par vietu, kur norit viss jūsu mākslīgā intelekta dzīves cikls. Jūs nomājat to, kas jums nepieciešams, kad tas ir nepieciešams, un pēc tam samaziniet tā apjomu, kad esat pabeidzis.

Kāpēc mākslīgā intelekta projekti neizdodas bez mākoņdatošanas infrastruktūras un MLOps

Lielākā daļa kļūmju rodas ap modeli, nevis tā iekšpusē: nekonsekventi dati, nesaskaņotas vides, nestabilas izvietošanas un uzraudzības trūkums. Mākoņrīki palīdz standartizēt krātuves, aprēķinu un izvietošanas modeļus, lai modeļi neiesprūstu pie “tas darbojās manā klēpjdatorā”. MLOps pievieno trūkstošo līmi: izsekošanu, reģistrus, cauruļvadus un atcelšanu, lai sistēma paliktu reproducējama un uzturama.

Tipiska mākslīgā intelekta darbplūsma mākoņdatošanā, sākot no datiem līdz ražošanai

Bieži sastopama plūsma ir šāda: dati nonāk mākoņkrātuvē, tiek apstrādāti funkcijās, pēc tam modeļi tiek apmācīti mērogojamā skaitļošanas vidē. Pēc tam tiek veikta izvietošana, izmantojot API galapunktu, pakešdarbu, bezservera iestatīšanu vai Kubernetes pakalpojumu. Visbeidzot, tiek uzraudzīta latentums, novirze un izmaksas, un pēc tam tiek veikta atkārtota apmācība un drošāka izvietošana. Lielākā daļa reālo cauruļvadu pastāvīgi darbojas cilpas veidā, nevis tiek piegādāti tikai vienu reizi.

Izvēle starp SageMaker, Vertex AI, Azure ML, Databricks un Kubernetes

Izvēlieties, balstoties uz savas komandas realitāti, nevis uz “labākās platformas” mārketinga troksni. Pārvaldītās mašīnmācīšanās platformas (SageMaker/Vertex AI/Azure ML) samazina darbības galvassāpes, izmantojot apmācības uzdevumus, galapunktus, reģistrus un uzraudzību. Databricks bieži vien ir piemērots komandām, kurās dominē datu inženierija un kuras vēlas mašīnmācīšanos tuvu cauruļvadiem un analītikai. Kubernetes nodrošina maksimālu kontroli un pielāgošanu, taču jūs pats pārvaldāt arī uzticamību, mērogošanas politikas un atkļūdošanu, ja rodas problēmas.

Arhitektūras modeļi, kas mūsdienās visbiežāk parādās mākslīgā intelekta mākoņa iestatījumos

Pastāvīgi redzēsiet četrus modeļus: pārvaldītas mašīnmācīšanās platformas ātrumam, Lakehouse + mašīnmācīšanās organizācijām, kurās prioritāte ir dati, konteinerizēta mašīnmācīšanās Kubernetes platformā kontrolei un RAG (izguves papildināta ģenerēšana) “drošai iekšējo zināšanu izmantošanai”. RAG parasti ietver dokumentus mākoņkrātuvē, iegultus failus + vektoru krātuvi, izguves slāni un piekļuves kontroli ar reģistrēšanu. Jūsu izvēlētajam modelim ir jāatbilst jūsu pārvaldības un darbību briedumam.

Kā komandas ievieš mākoņa mākslīgā intelekta modeļus: REST API, pakešuzdevumus, bezserveru risinājumus vai Kubernetes

REST API ir izplatītas reāllaika prognozēm, kad produkta latentums ir svarīgs. Pakešu secinājumi ir lieliski piemēroti plānotai vērtēšanai un izmaksu efektivitātei, īpaši, ja rezultātiem nav jābūt tūlītējiem. Bezserveru galapunkti var labi darboties ar pikantu datplūsmu, taču jāpievērš uzmanība aukstajai palaišanai un latentumam. Kubernetes ir ideāli piemērots, ja nepieciešama detalizēta mērogošana un integrācija ar platformas rīkiem, taču tas palielina darbības sarežģītību.

Kas jāuzrauga ražošanas vidē, lai uzturētu mākslīgā intelekta sistēmas veselas

Vismaz jāizseko latentums, kļūdu biežums un izmaksas uz prognozi, lai uzticamība un budžets būtu redzami. Mašīnmācīšanās pusē jāuzrauga datu novirzes un veiktspējas novirzes, lai pamanītu, kad modelī mainās realitāte. Svarīga ir arī robežgadījumu un sliktu rezultātu reģistrēšana, īpaši ģeneratīvus lietošanas gadījumus, kur lietotāji var radoši konkurēt. Laba uzraudzība atbalsta arī atcelšanas lēmumus, kad modeļi regresē.

Mākoņa mākslīgā intelekta izmaksu samazināšana, nemazinot veiktspēju

Izplatīta pieeja ir izmantot mazāko modeli, kas atbilst prasībai, un pēc tam optimizēt secinājumus ar partijveida apstrādi un kešatmiņu. Automātiskā mērogošana palīdz, taču tai ir nepieciešami ierobežojumi, lai “elastīgums” nekļūtu par “neierobežotiem tēriņiem”. Apmācības gadījumā lokāla/preemptējama skaitļošana var daudz ietaupīt, ja jūsu darbi panes pārtraukumus. Izmaksu izsekošana par katru galapunktu un katru funkciju neļauj optimizēt nepareizo sistēmas daļu.

Lielākie drošības un atbilstības riski, kas saistīti ar mākslīgo intelektu mākonī

Lielākie riski ir nekontrolēta piekļuve datiem, vāja noslēpumu pārvaldība un trūkstošas ​​auditācijas takas par to, kas ko apmācīja un izvietoja. Ģeneratīvais mākslīgais intelekts rada papildu galvassāpes, piemēram, tūlītēju ievadīšanu, nedrošas izvades un sensitīvu datu parādīšanos žurnālos. Daudziem cauruļvadiem ir nepieciešama vides izolācija (izstrāde/izstādīšana/ražošana) un skaidras politikas attiecībā uz uzvednēm, izvadēm un secinājumu reģistrēšanu. Drošākās iestatīšanas uzskata pārvaldību par galveno sistēmas prasību, nevis palaišanas nedēļas ielāpu.

Atsauces

  1. Nacionālais standartu un tehnoloģiju institūts (NIST) — SP 800-145 (galīgā versija) — csrc.nist.gov

  2. Google Cloud — GPU mākslīgajam intelektam — cloud.google.com

  3. Google Cloud — mākoņa TPU dokumentācija — docs.cloud.google.com

  4. Amazon Web Services (AWS) — Amazon S3 (objektu krātuve) — aws.amazon.com

  5. Amazon Web Services (AWS) — Kas ir datu ezers? — aws.amazon.com

  6. Amazon Web Services (AWS) — Kas ir datu noliktava? — aws.amazon.com

  7. Amazon Web Services (AWS) — AWS mākslīgā intelekta pakalpojumi — aws.amazon.com

  8. Google Cloud — Google Cloud mākslīgā intelekta API — cloud.google.com

  9. Google Cloud — Kas ir MLOps? — cloud.google.com

  10. Google Cloud — Vertex mākslīgā intelekta modeļu reģistrs (ievads) — docs.cloud.google.com

  11. Red Hat — Kas ir REST API? — redhat.com

  12. Amazon Web Services (AWS) dokumentācija — SageMaker partijas transformācija — docs.aws.amazon.com

  13. Amazon Web Services (AWS) — datu noliktava vs datu ezers vs datu tirgus — aws.amazon.com

  14. Microsoft Learn — Azure ML reģistri (MLOps) — learn.microsoft.com

  15. Google Cloud — Google mākoņkrātuves pārskats — docs.cloud.google.com

  16. arXiv — Raksts par izguves paplašinātās ģenerēšanas (RAG) metodi — arxiv.org

  17. Amazon Web Services (AWS) dokumentācija — SageMaker Serverless secinājumi — docs.aws.amazon.com

  18. Kubernetes — horizontālā poda automātiskā mērogošana — kubernetes.io

  19. Google Cloud — Vertex AI partijas prognozes — docs.cloud.google.com

  20. Amazon Web Services (AWS) dokumentācija — SageMaker modeļu monitors — docs.aws.amazon.com

  21. Google Cloud — Vertex AI modeļa uzraudzība (izmantojot modeļu uzraudzību) — docs.cloud.google.com

  22. Amazon Web Services (AWS) — Amazon EC2 Spot instances — aws.amazon.com

  23. Google Cloud — iepriekšēji atbloķējamas virtuālās mašīnas — docs.cloud.google.com

  24. Amazon Web Services (AWS) dokumentācija — AWS SageMaker: Kā tas darbojas (apmācība) — docs.aws.amazon.com

  25. Google mākonis — Google Vertex mākslīgais intelekts — cloud.google.com

  26. Microsoft Azure — Azure mašīnmācīšanās — azure.microsoft.com

  27. Databricks — Databricks Lakehouse — databricks.com

  28. Snowflake dokumentācija — Snowflake mākslīgā intelekta funkcijas (pārskata rokasgrāmata) — docs.snowflake.com

  29. IBM — IBM watsonx — ibm.com

  30. Google Cloud — mākoņa dabiskās valodas API dokumentācija — docs.cloud.google.com

  31. Snowflake dokumentācija — Snowflake Cortex mākslīgā intelekta funkcijas (AI SQL) — docs.snowflake.com

  32. MLflow — MLflow izsekošana — mlflow.org

  33. MLflow — MLflow modeļu reģistrs — mlflow.org

  34. Google Cloud — MLOps: nepārtrauktas piegādes un automatizācijas cauruļvadi mašīnmācībā — cloud.google.com

  35. Amazon Web Services (AWS) — SageMaker funkciju veikals — aws.amazon.com

  36. IBM — IBM watsonx.pārvaldība — ibm.com

Atrodiet jaunāko mākslīgo intelektu oficiālajā mākslīgā intelekta palīgu veikalā

Par mums

Atpakaļ uz emuāru

Papildu bieži uzdotie jautājumi

  • Kā mākslīgais intelekts mākoņdatošanā uzlabo datu glabāšanu?

    Mākslīgais intelekts mākoņdatošanā izmanto mākoņplatformas, lai glabātu datus mērogojamā un elastīgā vidē, piemēram, datu ezeros vai objektu glabātuvē. Tas nodrošina efektīvu datu pārvaldību un vienkāršāku piekļuvi modeļu apmācībai un izvietošanai.

  • Kāda ir MLOps loma mākslīgā intelekta mākoņdatošanā?

    MLOps jeb mašīnmācīšanās operācijas ir būtiskas mākslīgā intelekta modeļu dzīves cikla pārvaldībai mākonī. Tās koncentrējas uz reproducējamības nodrošināšanu, eksperimentu izsekošanu, modeļu izvietošanu un to veiktspējas uzraudzību, lai saglabātu efektivitāti un lietderību.

  • Kāpēc uzņēmumiem vajadzētu apsvērt mākoņinfrastruktūras izmantošanu mākslīgā intelekta projektiem?

    Mākoņinfrastruktūra piedāvā elastīgu mērogojamību, ļaujot uzņēmumiem pēc nepieciešamības nomāt skaitļošanas jaudu, kas ir ļoti svarīgi lielu modeļu apmācībai. Tā arī atvieglo ātrāku eksperimentēšanu un vienkāršāku mākslīgā intelekta lietojumprogrammu izvietošanu.

  • Kādas ir izplatītākās mākslīgā intelekta modeļu izvietošanas metodes mākonī?

    Mākslīgā intelekta modeļus var izvietot mākonī, izmantojot REST API reāllaika prognozēm, pakešuzdevumus plānotai apstrādei, bezserveru iestatījumus mainīgu darba slodžu apstrādei vai Kubernetes konteinerizētām lietojumprogrammām.

  • Kā izmaksu pārvaldība darbojas mākonī balstītos mākslīgā intelekta risinājumos?

    Izmaksu pārvaldība mākoņa mākslīgā intelekta risinājumos parasti ietver tādu metožu izmantošanu kā partijveida apstrāde, kešatmiņa un automātiskā mērogošana, lai optimizētu resursu izmantošanu. Automātiskās mērogošanas ierobežojumu noteikšana un vietas/preemptīvu instanču izmantošana apmācībai var arī ievērojami samazināt izmaksas.

  • Kādas ir drošības bažas, kas saistītas ar mākslīgo intelektu mākoņdatošanā?

    Drošības apsvērumi ietver datu piekļuves kontroli, šifrēšanas atslēgu pārvaldību un atbilstības nodrošināšanu noteikumiem. Ir ļoti svarīgi izveidot skaidras datu apstrādes un audita reģistrēšanas politikas, lai mazinātu ar mākslīgā intelekta ieviešanu saistītos riskus.

  • Vai mākslīgais intelekts mākoņdatošanā var palīdzēt datu pārvaldībā?

    Jā, mākslīgais intelekts mākoņdatošanā atbalsta datu pārvaldību, integrējot tādas funkcijas kā piekļuves kontrole, audita žurnāli un vides atdalīšana, kas uzlabo drošību un nodrošina atbilstību dažādiem noteikumiem.

  • Kādi ir daži izplatītākie mākslīgā intelekta lietošanas gadījumi mākonī?

    Biežāk sastopamie lietošanas gadījumi ietver klientu atbalsta automatizāciju, ieteikumu sistēmas, krāpšanas atklāšanu, dokumentu izlūkošanu un ģeneratīvās mākslīgā intelekta lietojumprogrammas. Šīs lietojumprogrammas izmanto mākoni, lai apstrādātu lielus datu kopumus un efektīvi veiktu sarežģītas analīzes.