DI agentų vertinimas AWS pavyzdyje: vien gero atsakymo jau per mažai

·


DI agentų vertinimo schema su Strands ir AgentCore

DI agentų vertinimas š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ų?

AWS aprašė produkcinį DI agentų vertinimo pavyzdį su Strands ir AgentCore. Motorway atveju neteisingų rezultatų dalis sumažėjo nuo 1 iš 8 užklausų iki 1 iš 50.

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

Publikacijoje rodoma vertinimo linija: agento sesijos, testavimo užduotys, rezultatų analizė ir klaidų aptikimas. Tikslas paprastas – suprasti, kur agentas klysta, prieš tai pavirstant kliento problema.

Čia man labai patinka skaičius. Ne „mūsų agentas protingas“. O kiek kartų suklydo ir kiek po pakeitimų klysta dabar.

Č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 turi planą, įrankius, tarpinius žingsnius ir kontekstą. Vien pažiūrėti į galutinį atsakymą dažnai nepakanka.

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 agento paleidimas be vertinimo yra važiavimas užrištomis akimis. Gal nuvažiuosite. Bet jei kelias šlapias, sužinosite per vėlai.

  • turėti tipinių užduočių rinkinį
  • matuoti klaidas pagal verslo poveikį
  • saugoti agento tarpinius žingsnius
  • po pakeitimų kartoti tuos pačius testus

Paimkite 30 realių klientų užklausų ir pažymėkite teisingą rezultatą. Tada leiskite agentui jas spręsti po kiekvieno didesnio pakeitimo.

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 – testuoti tik lengvus pavyzdžius. Agentas gražiai atrodys demo, bet paslys ten, kur tikras klientas užduoda kreivą, neišsamų, žmogišką klausimą.

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ę susikurkite mažą agento testų lentelę. Net 20 užduočių jau geriau nei jausmas pilve.

Šaltinis: Amazon Web Services.

DUK

Kas yra DI agentų vertinimas?

Tai sistemingas agento atsakymų, veiksmų ir klaidų tikrinimas pagal realias užduotis.

Kodėl neužtenka žmogui patikrinti atsakymo?

Nes agentas gali suklysti tarpiniuose žingsniuose, o galutinis atsakymas kartais atrodo įtikinamai.

Nuo ko pradėti?

Nuo mažo realių užduočių rinkinio ir aiškaus teisingo rezultato aprašymo.

Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.