Agentų kaštai AWS pavyzdyje: kai vienas veiksmas dar nieko nepasako
·

agentų kaštai š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ų?
Agentų kaštai nebesibaigia vienu modelio atsakymu. AWS rugpjūčio 6 d. pristatė Bedrock AgentCore galimybes, kurios leidžia nustatyti ribas visai užduočiai: kiek agentas gali veikti, kiek įrankių kviesti ir kada sustoti.
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
AWS rašo, kad komandoms reikia lubų, kurios laikytųsi net tada, kai agentas elgiasi netikėtai. Naujos AgentCore kontroles leidžia riboti veiksmų sekas, stebėti išlaidas ir valdyti agento darbą ne tik vieno įrankio lygyje.
Čia labai žemiška tema. Visi nori agento, kuris „pats padarys“. Bet kai jis pradeda pats bandyti, kviesti, taisyti, kartoti ir dar kartą kviesti, sąskaita pradeda kalbėti garsiau už demo.
Č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 nėra paprastas chatbotas. Jis gali planuoti ir atlikti kelis veiksmus. Todėl biudžetas turi būti skaičiuojamas per visą užduotį, o ne per vieną gražiai atrodantį atsakymą.
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 DI agentų diegimas turi prasidėti nuo ribų: pinigų, laiko, įrankių, duomenų ir žmogaus patvirtinimo.
- nustatyti vienos užduoties biudžetą
- riboti įrankių kvietimų skaičių
- matuoti baigtas užduotis, ne tik tokenus
- turėti aiškų stop signalą
Paimkite vieną agento scenarijų ir paskaičiuokite blogiausią atvejį: kiek kainuos, jei agentas tris kartus bandys tą patį kelią ir dar pakvies papildomą paiešką?
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 paprasta: komanda mato pigų testą, tada paleidžia produkcijoje, o po mėnesio aiškinasi, kodėl automatizavimas kainavo daugiau nei žmogaus darbas.
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ę kiekvienam agentui įrašykite vieną skaičių: maksimalus vienos užduoties biudžetas.
Šaltinis: AWS Machine Learning Blog.
DUK
Kodėl agentų kaštai skiriasi nuo chatbotų?
Agentai atlieka kelis veiksmus, kviečia įrankius ir gali kartoti užduotį, todėl reikia skaičiuoti visą eigą.
Ką siūlo AWS AgentCore?
AWS pristato kontroles, kurios padeda valdyti agento elgesį ir kainą per visą užduotį.
Nuo ko pradėti įmonei?
Nuo vienos užduoties biudžeto, veiksmų ribų ir audito žurnalo.
Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.


