Na tej strani
Odgovor o vrnjenem naročilu je videti pripravljen za pošiljanje: slovnično pravilen, prijazen in kratek. V tem ponazoritvenem primeru mu samodejno ocenjevanje dodeli najvišjo oceno. Pomočnik stranki tudi pove, da je bilo vračilo denarja izvedeno, čeprav nihče ni preveril plačilnega sistema.
Napaka ni v šibkem stavku. Napaka je v šibki definiciji dobrega.
V pregledani predstavitvi ocenjevanja ekipa gradi ocene za agenta, ki piše dokumentacijo programske opreme. Zanimiv trenutek nastopi, ko oseba, ki pozna delo, opiše kakovost, orodje pa opis pretvori v merila. Pozneje nizka ocena sproži pravi dvom: morda je treba popraviti agenta, morda pa samo ocenjevanje.
Merila so teorija o nalogi. Teorijo preizkusite.
Začnite z napako, ki izključi rezultat
Ekipe pogosto začnejo z merili, ki jih je lahko oceniti: jasnostjo, tonom, strukturo in popolnostjo. Koristna so. Redko pa zadostujejo.
Pri ponazoritvenem odgovoru o vračilu denarja mora pravilo „nikoli ne trdi, da je bilo vračilo izvedeno, brez potrdila o vračilu denarja“ stati pred kakovostjo sloga. Pri sinhronizaciji podatkov je „ne preslikaj e-poštnega naslova za račune v e-poštni naslov lastnika računa“ pomembnejše od tega, ali je razlaga preslikave lepo napisana.
Strokovnjaka za področje prosite za tri vrste primerov: očitno dober, očitno napačen in tak, pri katerem se lahko dobro obveščeni ljudje ne strinjajo. Shranite izvorne zapise in razlog za vsako presojo. Če je primer odvisen od pravila, ki se lahko spremeni, shranite različico pravila skupaj z oznako.
Prvi pregled je lahko majhen. Ne sme pa biti nejasen.
- Lastnik naloge
dobri, slabi in sporni primeri
- Natančni pregledi identiteta · dovoljenje · ciljni sistem
koda uveljavi dejstva
- Pomenska merila
model presoja le, kar zahteva razlago
- Pregled nesoglasij
popravite oznake in merila
| Preverjanje | Primernejši nosilec | Zakaj |
|---|---|---|
| Zahtevano dovoljenje obstaja | Koda in avtoritativni zapisi | Dejstvo je natančno in ima posledice |
| ID v ciljnem sistemu ustreza izvorni identiteti | Koda in preizkusni zapis | Model ne sme ugibati identifikatorja |
| Odgovor odgovori na strankino vprašanje | Merila, pregledana od ljudi, morda model za ocenjevanje | Pomen zahteva razlago |
| Ton ustreza položaju | Merila, pregledana od ljudi, morda model za ocenjevanje | Sprejemljivih oblik je več |
Naš vodnik za uporabo AI v obstoječih potekih dela prav tako ločuje presojo modela od nadzora izvedbe. Ko model izbere med kandidati, naj koda kopira prvotne vrednosti in nato preveri omejitve. Gotovost modela sama po sebi ne postane dovoljenje.
Ocena podeduje slepe pege meril
Ugovor je pošten: „Človek ne more pregledati vsake izvedbe agenta. Potrebujemo ocenjevalca, ki ga lahko uporabljamo v velikem obsegu.“ Da. Vprašanje je, kaj ta ocenjevalec ponavlja v velikem obsegu.
Če merila nagrajujejo uglajen odgovor in nikoli ne preverijo, ali je bilo vračilo dejansko izvedeno, bo avtomatizacija ponavljala izpustitev. Številka z dvema decimalnima mestoma je videti natančna. Še vedno lahko meri napačno stvar.
Dokumentacija Google Cloud o vrednotenju ocenjevalnih modelov opisuje praktičen pregled: pripravite primere s človeškimi ocenami, zaženite metriko na osnovi modela in njene ocene primerjajte s človeškimi. To ne pomeni, da je pogled ene osebe nezmotljiv. Model potrebuje zunanje merilo, preden ima njegova ocena težo.
Preglejte nesoglasja, ne le povprečne skladnosti. Če model odobri odgovor, ki ga vodja podpore zavrne, vprašajte, katero manjkajoče merilo to pojasni. Če se dva strokovnjaka ne strinjata, ohranite obe oznaki in poiščite pravilo, ki ga različno razumeta. Spora ne skrijte v povprečju.
Vzorčenje je prav tako pomembno kot besedilo merila. Zbirka običajnih uspehov lahko ocenjevalca prikaže kot zanesljivega, težke primere pa pusti nedotaknjene. Vključite nepopolne zapise, nasprotujoča si navodila in primere, ko je pravilen odgovor ustavitev in vprašanje. Ohranite ločen nabor primerov, na katerem avtorji meril niso prilagajali meril, da mora sprememba, ki izboljša znane primere, dokazati vrednost tudi drugje. Ko se poslovno pravilo spremeni, osvežite oznake in pričakovane rezultate; zamrznjen preizkusni nabor lahko nagrajuje včerajšnjo politiko.
Rezultat naj ostane povezan z ocenjevanjem
Merila za agenta, ki sinhronizira podatke, naj sledijo rezultatu stranke. Ali se je spremenil pravi stik? Ali je bila privolitev spoštovana? Ali je mogoče neuspešen zapis ponoviti brez podvajanja dejanja s posledicami?
Vodnik za priključek Brevo pojasnjuje, zakaj lahko uspešen klic API obstaja skupaj z manjkajočim atributom. Ocenjevanje, ki preveri samo klic končne točke, bo spregledalo rezultat. Ocenjevanje, ki preveri le ciljni sistem, lahko spregleda prepovedano pot, ki je po naključju pripeljala do pravilne vrednosti. Oboje je pomembno, kadar pot nosi tveganje.
Začnite z eno ozko nalogo in nekaj načini odpovedi. Primere označite z osebo, ki nalogo pozna. Natančna preverjanja postavite v kodo, model uporabite le tam, kjer jezik ali presoja to res potrebujeta. Iste primere zaženite po spremembi poziva, modela ali orodja. Zabeležite, kaj poznejše napake razkrijejo o merilih.
Cena je čas strokovnjakov na začetku. Dobiček je pomen, ki ga lahko nekdo zagovarja pri vsaki poznejši oceni.
Nadzorna plošča pokaže oceno. Samo merila povedo, kaj ste šteli.
Pogosto Zastavljena Vprašanja
Kdo naj določi merila za ocenjevanje agenta AI?
Ljudje, ki poznajo nalogo in njene posledice, naj določijo sprejemljive rezultate in izključujoče napake. Razvijalci lahko presoje pretvorijo v ponovljive preglede in preverijo, ali se model za ocenjevanje ujema s človeškimi ocenami.
Ali visoka ocena modela dokazuje, da agent deluje?
Ne. Ocena meri skladnost z merili na preizkušenih primerih. Slaba merila, nereprezentativni primeri ali slabo umerjen ocenjevalni model lahko škodljiv rezultat ocenijo visoko.
Kaj naj namesto modela preveri koda?
Natančna dovoljenja, identifikatorje zapisov, zahtevane klice orodij in stanje ciljnega sistema naj po možnosti preverja koda. Model je uporaben za pomenske lastnosti, ki jih natančna pravila ne morejo razrešiti.