Laiko taisyklės DI agentams: kodėl agentui reikia ne tik leidimo, bet ir istorijos
·
DI agentų laiko taisyklės šiandien nėra teorinis žaislas. Tai jau darbas, pinigai, duomenys ir kartais labai žemiškas klausimas: kas prisiims atsakomybę, kai DI pradės veikti už žmogų?
DI agentų laiko taisyklės skamba sausai. Bet AWS rugpjūčio 6 d. aprašytos AgentCore temporal policies pataiko į labai realią problemą: vienas agento veiksmas gali atrodyti leidžiamas, bet pavojus atsiranda veiksmų sekoje.
Turiu prisipažinti, tokias naujienas skaitau ne kaip blizgančią vitriną. Skaitau kaip žmogus, kuris iš karto galvoja apie komandą pirmadienio rytą. Kas iš to bus naudinga? Kur bus painiava? Ir kur po mėnesio kas nors pasakys: „mes galvojom, kad čia automatiškai susitvarkys“.
KAS NUTIKO
Temporal policies seka agento trajektoriją: ribotą veiksmų seką pagal principal ir session ID. Agentas nemato politikos logikos, negali jos keisti, o draudimas laimi prieš leidimą.
Čia kaip su vaikų saldainiais namie. Vieną paimti gal ir nieko. Dešimt per penkias minutes – jau turime kitą pokalbį.
Čia svarbi detalė: kalbame ne apie dar vieną gražų demonstracinį video. Kalbame apie produktus, politiką, infrastruktūrą arba tyrimus, kurie keičia, kaip žmonės dirba su DI realiose organizacijose.
KODĖL TAI SVARBU
Daug agentų rizikų atsiranda ne viename įrankio kvietime. Rizika atsiranda tada, kai agentas iš eilės skaito, kaupia, bando, siunčia ir kartoja.
DI jau išlipo iš „parašyk tekstą“ dėžutės. Jis naršo, jungiasi prie įrankių, analizuoja duomenis, planuoja veiksmus, kartais tvarko dokumentus ar padeda priimti sprendimą. Trumpai: jis artėja prie darbo proceso, ne tik prie pokalbio lango.
Ir čia smegenys mėgsta paslysti. Norisi sakyti: „ai, čia dar užsienyje“. Bet tas pats modelis ar funkcija rytoj atsiras kliento kompiuteryje, darbuotojo naršyklėje arba partnerio pasiūlyme.
KĄ TAI REIŠKIA VERSLUI
Verslui tai reiškia, kad saugumas turi žiūrėti į procesą, ne tik į atskirą API leidimą.
- riboti veiksmų sekas
- naudoti sesijų istoriją
- numatyti draudžiamus derinius
- neleisti agentui matyti kontrolės taisyklių
Pavyzdys: agentas gali perskaityti dokumentą ir paruošti santrauką, bet negali po to automatiškai išsiųsti jos išoriniam gavėjui be žmogaus patvirtinimo.
Man patinka paprastas testas: ar po šios naujienos tavo komanda turi vieną aiškesnį sprendimą? Jei ne, vadinasi dar tik skaitome. Skaityti galima. Tik nereikia apsimesti, kad tai jau strategija.
KUR GALI SKAUDĖTI
Rizika – manyti, kad role-based prieigos pakanka. Agentai veikia ilgiau ir jungia daugiau veiksmų, todėl reikia žiūrėti į seką.
Dažniausia klaida labai ūkiška. Žmonės įsijungia įrankį, pabando, nustemba, pasidžiaugia ir tada palieka viską savieigai. Po kelių savaičių paaiškėja, kad vieni darbuotojai kelia jautrius failus, kiti matuoja naudą iš jausmo, o treti net nežino, kas leidžiama.
Ne tragedija. Bet tvarkos reikia.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Šią savaitę vienam agentui parašykite tris draudžiamas veiksmų kombinacijas, ne tik tris draudžiamus veiksmus.
Šaltinis: AWS Machine Learning Blog.
DUK
Kas yra temporal policies?
Tai taisyklės, kurios vertina agento veiksmų seką per laiką, o ne tik vieną veiksmą atskirai.
Kodėl jos reikalingos?
Nes pavojus dažnai kyla iš veiksmų kombinacijos: skaitymo, kaupimo, siuntimo ar kartojimo.
Ar agentas gali apeiti taisykles?
AWS aprašo, kad agentas nemato politikos logikos ir negali keisti kontrolės būsenos.
Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.
