Tylūs agentų gedimai: kai sistema šypsosi ir klysta
·
tylūs agentų gedimai šiandien nėra vien dar vienas įrašas DI naujienų sraute. Čia signalas, kur juda praktinis darbas: agentai, modelių valdymas, paieška, saugumas ir labai žemiškas klausimas – kas už rezultatą atsako?
AWS liepos 23 d. rašė apie tylų DI agentų gedimą. Tai situacija, kai visi techniniai indikatoriai žali, serveriai veikia, klaidos nemeta, bet agentas vis tiek duoda blogą rezultatą. Smagiausia? Niekas iš karto nepastebi.
Atvirai? Mane tokiose naujienose vis mažiau domina blizgus demo. Daug labiau domina, ar žmogus pirmadienį ryte su tuo sutaupys valandą, ar tiesiog gaus dar vieną vietą, kurią reikia prižiūrėti.
KAS NUTIKO
Amazon Bedrock AgentCore optimization skirta aptikti elgsenos klaidas produkciniuose agentuose: rasti modelius per sesijas, paaiškinti, kas kartojasi, ir padėti komandai taisyti didžiausios žalos vietas pirmiausia.
Čia toks pat jausmas kaip gauti mandagų, tvarkingą, gramatiškai gražų laišką su neteisinga sąskaita. Iš pirmo žvilgsnio viskas gerai. Po to pradedi skaičiuoti nuostolį.
KODĖL TAI SVARBU
Tylūs agentų gedimai svarbūs todėl, kad jie neatrodo kaip klasikinė IT klaida. Agentas gali būti gyvas, greitas ir paslaugus, bet pasirinkti blogą veiksmą arba praleisti svarbų kontekstą.
DI versle jau perėjo iš smalsumo fazės į tvarkos fazę. Čia nebeužtenka pasakyti „turime įrankį“. Reikia žinoti, kokiai užduočiai jis skirtas, kokius duomenis liečia, kiek kainuoja ir kada privalo sustoti.
KĄ TAI REIŠKIA VERSLUI
Lietuviškame versle tai ypač aktualu klientų aptarnavimui, finansams, pardavimams ir dokumentų procesams. Ten klaida gali atrodyti maža, kol ją pamato klientas.
- stebėti ne tik uptime, bet ir atsakymo kokybę
- rinkti nepavykusių užduočių pavyzdžius
- lyginti agento veiksmus su žmogaus sprendimu
- turėti aiškią perdavimo žmogui taisyklę
Pirmas pratimas: kartą per savaitę peržiūrėkite 20 agento sesijų ir pažymėkite, kur jis pasielgė formaliai teisingai, bet versliškai blogai.
KUR PASISLĖPUSI RIZIKA
Rizika – pasitikėti prietaisų skydeliu, kuriame rodoma tik technika. Agentui reikia ir kokybės skydelio.
Čia labai lengva apsigauti. DI atsakymas dažnai atrodo tvarkingas net tada, kai viduje jis pastatytas ant smėlio. Gražus sakinys nėra įrodymas. Nuoroda, testas, logas ir žmogaus peržiūra – jau arčiau tiesos.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Prie savo agento KPI pridėkite vieną rodiklį: kiek atsakymų žmogus priėmė be taisymo. Tai labai greitai numuša rožinius akinius.
Mano paprasta taisyklė: jei negali pamatuoti, ar DI atliko darbą gerai, dar ne laikas jo leisti į produkciją. Pirma pasidaryk egzaminą. Tada jau kalbėk apie mastelį.
Šaltinis: Amazon Web Services.
DUK
Kas yra tylūs agentų gedimai?
Tai klaidos, kai DI agentas techniškai veikia, bet priima blogą sprendimą arba pateikia neteisingą rezultatą.
Kodėl tai pavojinga?
Nes tokios klaidos dažnai nepasirodo įprastuose serverių ar klaidų loguose.
Kaip nuo to gintis?
Reikia kokybės matavimo, sesijų peržiūros ir žmogaus perdavimo taisyklių.
Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Ne nuo visos įmonės. Vienas pasikartojantis darbas, aiškus matavimas ir žmogaus peržiūra. Daugiau praktinių DI taikymo pavyzdžių rasi MasterSprint.
