Data mesh agentams: DI be tvarkingų duomenų greitai pradeda improvizuoti
·
data mesh agentams skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?
AWS aprašė, kaip moderni data mesh strategija gali tapti saugiu pagrindu agentinėms DI programoms. Skamba kaip duomenų architektų tema. Bet vadovams čia yra labai praktiška žinutė: agentas be tvarkingų duomenų pradeda spėlioti.
Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?
KAS NUTIKO
AWS rodo, kaip kurti valdomą, serverless data mesh su Amazon Bedrock AgentCore, Knowledge Bases, Athena, Redshift, S3, Glue, Lake Formation, Cognito ir kitomis paslaugomis. Tikslas – saugiai duoti agentams prieigą prie tinkamų duomenų.
Čia kaip naujam darbuotojui pasakyti: „visa informacija kažkur diske“. Jis gal protingas, bet jei nežino, kuris failas teisingas, pradės klausinėti, spėlioti arba naudoti seną versiją.
KODĖL TAI SVARBU
Data mesh agentams svarbus todėl, kad agentai ne tik atsako. Jie daro veiksmus, jungia šaltinius ir priima tarpinius sprendimus. Jei duomenų nuosavybė, teisės ir kokybė neaiškios, klaidos bus gražiai automatizuotos.
DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.
KĄ TAI REIŠKIA VERSLUI
Verslui tai reiškia, kad DI projektas dažnai prasideda ne nuo modelio, o nuo duomenų tvarkos. Kas yra duomenų savininkas? Kas gali skaityti? Kas gali keisti? Kokia versija patvirtinta?
- paskirti duomenų savininkus
- atskirti skaitymo ir keitimo teises
- žymėti patvirtintus duomenų šaltinius
- testuoti agentą su ribotomis teisėmis
Pavyzdys: pardavimų agentas gali skaityti patvirtintus klientų segmentus ir produktų kainodarą, bet negali pats keisti nuolaidų taisyklių be žmogaus patvirtinimo.
KUR PASISLĖPUSI RIZIKA
Rizika – uždėti agentą ant duomenų chaoso ir tikėtis, kad jis jį sutvarkys. Dažniau jis tą chaosą tik pagreitina.
Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Prieš kitą DI agento bandymą susirašykite tris šaltinius, kuriais jis remsis, ir pažymėkite, kas už juos atsako.
Šaltinis: Amazon Web Services.
DUK
Kas yra data mesh agentams?
Tai duomenų valdymo principas, kai skirtingos komandos valdo savo duomenis kaip produktus, o agentams suteikiama kontroliuota prieiga.
Kodėl tai svarbu DI agentams?
Agentai remiasi duomenimis veiksmams ir išvadoms, todėl prieiga ir kokybė turi būti aiškios.
Nuo ko pradėti?
Nuo duomenų savininkų, patvirtintų šaltinių ir ribotų agento teisių.
Jei norite DI naudoti ne dėl mados, pradėkite nuo vieno proceso. Paimkite užduotį, kuri kartojasi kas savaitę, susirašykite žingsnius ir tik tada junkite įrankį. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.
