Laiko taisyklės DI agentams: kodėl leidimai turi priklausyti nuo veiksmų eilės
·
DI agentų leidimai š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ų leidimai negali būti vienkartinis „taip“ arba „ne“. AWS rugpjūčio 6 d. aprašė temporal policies AgentCore aplinkoje: agentui leidžiama veikti tik tada, kai prieš tai įvyko teisinga veiksmų seka.
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
Tradicinėse sistemose dažnai tikrinamas vienas veiksmas. Agentai sprendžia, kokius įrankius kviesti, kokia tvarka ir su kokiais argumentais. Todėl leidimas turi žiūrėti į laiką ir kontekstą.
Čia kaip su įmonės pirkimais. Vienas žmogus gali paruošti užsakymą, kitas patvirtinti. Jei tas pats žmogus staiga apeina abu žingsnius, sistema turi ne linktelėti, o sustoti.
Č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
Agentas gali padaryti teisingą veiksmą netinkamu metu. Pavyzdžiui, siųsti laišką prieš patvirtinimą arba paimti duomenis prieš vartotojo sutikimą.
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
Įmonėms tai ypač aktualu finansuose, klientų aptarnavime, HR, dokumentų valdyme ir visur, kur agentas turi prieigą prie jautrių įrankių.
- aprašyti veiksmų eiliškumą
- patvirtinimus laikyti proceso dalimi
- riboti veiksmus pagal ankstesnius žingsnius
- registruoti ne tik ką, bet ir kada agentas darė
Pasirinkite vieną procesą, pavyzdžiui, kliento sutarties paruošimą. Parašykite, kokia tvarka agentas gali rinkti duomenis, generuoti tekstą ir siųsti žmogui.
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 – duoti agentui bendrą leidimą ir tikėtis, kad jis pats supras procedūrą. Kartais nesupras. Ir padarys labai užtikrintai.
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 pridėkite taisyklę: kokio ankstesnio įvykio reikia, kad kitas veiksmas būtų leidžiamas.
Šaltinis: AWS Machine Learning Blog.
DUK
Kas yra temporal policies?
Tai taisyklės, kurios vertina ne tik veiksmą, bet ir jo vietą veiksmų sekoje.
Kodėl agentams to reikia?
Nes agentai patys pasirenka įrankius ir jų tvarką, todėl tradiciniai leidimai gali būti per platūs.
Kur tai pritaikyti?
Procesuose su patvirtinimais, jautriais duomenimis, mokėjimais, sutartimis ar klientų informacija.
Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.
