AgentOps: DI agentams reikia operacijų drausmės

Svarbiausia

• Kas yra AgentOps? Tai praktikos, skirtos DI agentams kurti, paleisti, stebėti ir valdyti produkcinėje aplinkoje.
• Ar AgentOps reikalingas mažai įmonei? Taip, jei agentas daro veiksmus su duomenimis, klientais ar pinigais.
• Nuo ko pradėti? Nuo ribų, logų ir žmogaus patvirtinimo jautrioms užduotims.

AgentOps skamba kaip dar viena DI naujiena iš didelės kompanijos. Bet aš į tokias naujienas žiūriu paprastai: ar tai padeda žmogui pirmadienio rytą, kai Outlook’as pilnas, Slack’as mirksi, o vadovas klausia, kur rezultatas?

AWS naujame įraše aiškiai sako: kai DI agentai pradeda veikti savarankiškiau, jiems reikia ne tik gero prompto, bet ir operacinės drausmės.

Ir čia prasideda įdomioji dalis. Ne spaudos pranešime. Darbe. Ten, kur gražūs pažadai arba tampa procesu, arba tampa dar vienu įrankiu, kurį nusipirkome ir po dviejų savaičių pamiršome.

Kas nutiko

AWS aprašė AgentOps praktiką su keturiais ramsčiais: valdymu ir saugumu, kūrimu ir operacijomis, vertinimu bei stebėsena. Pavyzdžiai remiasi Amazon Bedrock AgentCore.

Tai nėra gražus terminas prezentacijai. Tai bandymas DI agentus priartinti prie to, kaip jau seniai valdome programinę įrangą: su versijomis, testais, logais ir aiškiomis teisėmis.

Kodėl tai svarbu

Agentai skiriasi nuo paprastų automatizacijų tuo, kad jie renkasi veiksmus. O kai sistema renkasi veiksmus, įmonė turi žinoti, kur prasideda ir baigiasi jos laisvė.

Man čia labai norisi įjungti šaltą dušą sau pačiam. DI nėra stebuklinga šluota. Jei komandoje nėra aiškių taisyklių, kas ką daro, DI tik greičiau pagamins triukšmą. Kartais labai gražų triukšmą.

Ką tai reiškia verslui

Verslui AgentOps reiškia paprastą dalyką: DI agentas neturi gyventi kaip eksperimentas kažkieno naršyklėje. Jis turi turėti savininką, ribas, matavimus ir išjungimo mygtuką.

• aprašyti, kokius veiksmus agentas gali atlikti
• įjungti žmogaus patvirtinimą jautrioms užduotims
• kaupti veiksmų žurnalą
• vertinti ne tik atsakymą, bet ir visą sesijos rezultatą

Geras pirmas bandymas – vidinis agentas, kuris ruošia savaitinę klientų klausimų suvestinę, bet nieko nesiunčia klientui be žmogaus peržiūros.

Kur pasislėpusi rizika

Didžiausia rizika – manyti, kad agento klaidos bus tokios pačios kaip žmogaus. Nebūtinai. Agentas gali labai tvarkingai pakartoti klaidą šimtą kartų.

Gera ribų taisyklė: jeigu DI gali atlikti veiksmą, kažkas turi matyti pėdsaką. Kas paprašė? Ką sistema padarė? Kokiais duomenimis rėmėsi? Kur sustojo? Be šitų klausimų agentai virsta ne pagalbininkais, o mandagiais improvizatoriais.

Ką pasidaryti šią savaitę

Paimkite vieną planuojamą DI agento idėją ir šalia jos parašykite tris ribas: ko jis negali daryti, kada privalo klausti žmogaus ir kas peržiūri logus.