Codex stebėsena per AWS: kodėl agento logai tampa tokie pat svarbūs kaip jo atsakymas

Codex stebėsena š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ų?

Codex stebėsena AWS tinklaraštyje rugpjūčio 6 d. aprašyta per OpenTelemetry ir Amazon CloudWatch. Skamba techniškai, bet pamoka labai paprasta: agento atsakymo nepakanka, reikia matyti jo kelią.

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 rodo, kaip rinkti agento veiksmų, užklausų, klaidų ir veikimo metrikas, kai Codex naudojamas per Amazon Bedrock. OpenTelemetry padeda standartizuoti stebėseną, o CloudWatch leidžia matyti sisteminį vaizdą.

Čia kaip su nauju darbuotoju. Jei jis atneša gerą rezultatą, smagu. Bet jei nežinai, iš kur paėmė duomenis, ką pakeitė ir kur užstrigo, po pirmos klaidos prasideda rankų skėsčiojimas.

Č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

DI agentai dažnai veikia per kelis žingsnius. Jie kviečia modelius, įrankius, API, duomenų šaltinius. Kai kažkas nepavyksta, reikia ne spėti, o matyti pėdsaką.

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 produkciniai agentai turi būti stebimi kaip bet kuri kita svarbi sistema. Ypač jei jie rašo kodą, keičia failus ar jungiasi prie vidinių įrankių.

• rinkti užklausų ir klaidų metrikas
• matyti įrankių kvietimų seką
• sieti kaštus su konkrečia užduotimi
• turėti aiškų incidento tyrimo kelią

Jei naudojate kodavimo agentą, paprašykite techninės komandos parodyti ne tik rezultatą, bet ir logus: ką agentas kvietė, kiek kainavo, kur klydo.

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 – laikyti agentą stebuklinga dėže. Stebuklingos dėžės gražios iki pirmo incidento. Po jo visi nori žurnalų.

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 DI agentui susitarkite, kokius tris logų laukus privaloma rinkti kiekvienai užduočiai.

Šaltinis: AWS Machine Learning Blog.

DUK

Kas yra Codex stebėsena?

Tai agento veiksmų, klaidų, užklausų, įrankių kvietimų ir kaštų matymas per stebėsenos sistemas.

Kam čia OpenTelemetry?

Jis padeda standartizuoti metrikas ir pėdsakus, kad agentą būtų lengviau stebėti įvairiose sistemose.

Kodėl tai svarbu verslui?

Be logų sunku tirti incidentus, skaičiuoti kainą ir pasitikėti produkciniu agentu.

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