På denne side
Et svar om en returneret ordre ser klart ud til at blive sendt: sproget er korrekt, tonen venlig, og teksten kort. I dette tænkte tilfælde giver en automatisk score fuldt pointtal. Assistenten fortæller også kunden, at pengene er refunderet, selvom ingen har kontrolleret betalingssystemet.
Fejlen er ikke en dårlig sætning. Den er en dårlig definition af godt.
I en optaget demonstration af evaluering udvikler et team vurderingskriterier for en agent, der skriver softwaredokumentation. Det interessante øjeblik kommer, når den person, der kender arbejdet, beskriver kvalitet, og et værktøj gør beskrivelsen til kriterier. Senere udløser en lav score den rigtige tvivl: Måske skal agenten rettes, eller måske skal evalueringen.
Rubrikken er en teori om opgaven. Test teorien.
Begynd med den fejl, der diskvalificerer
Teams begynder ofte med dimensioner, som er nemme at bedømme: klarhed, tone, struktur og fuldstændighed. De er nyttige. De er sjældent nok.
For det tænkte svar om refusion bør »påstå aldrig, at en refusion er gennemført uden en kvittering fra betalingssystemet« stå over sproglig kvalitet. For en datasynkronisering er »map ikke en fakturerings-e-mail til kontoejerens e-mail« vigtigere end, om forklaringen af feltmappingen er velskrevet.
Bed fagpersonen om tre slags tilfælde: ét åbenlyst godt, ét åbenlyst forkert og ét, hvor kyndige personer kan være uenige. Bevar kildeposterne og begrundelsen for hver vurdering. Hvis et tilfælde afhænger af en regel, som kan ændres, skal reglen versionsstyres sammen med mærkningen.
Første runde må gerne være lille. Den må ikke være vag.
- Opgavens ejer
gode, dårlige og omstridte tilfælde
- Præcise kontroller identitet · tilladelse · destination
kode håndhæver fakta
- Rubrik for betydning
bedøm kun det, der kræver fortolkning
- Gennemgang af uenighed
ret mærkninger og kriterier
| Kontrol | Bedre ansvarlig | Hvorfor |
|---|---|---|
| Påkrævet tilladelse findes | Kode og autoritative poster | Faktummet er præcist og har konsekvenser |
| Destinationens id matcher identiteten i kilden | Kode og en testpost | En model bør ikke gætte et id |
| Svaret besvarer kundens spørgsmål | Menneskegennemgået rubrik, eventuelt modelbedømmer | Betydning kræver fortolkning |
| Tonen passer til situationen | Menneskegennemgået rubrik, eventuelt modelbedømmer | Flere former kan være acceptable |
Guiden til AI i eksisterende arbejdsgange placerer modelvurderingen i en arbejdsgang med kontroller og virkelige resultater. Ved denne grænse skal kode bevare de oprindelige værdier og kontrollere reglerne, efter at modellen vælger mellem muligheder. Modellens sikkerhed i vurderingen giver ikke tilladelse.
Scoren arver rubrikkens blinde vinkler
Indvendingen er rimelig: »Et menneske kan ikke gennemgå hver agentkørsel. Vi har brug for en bedømmer, der kan skaleres.« Ja. Spørgsmålet er, hvad bedømmeren skalerer.
Hvis rubrikken belønner et poleret svar og aldrig kontrollerer, om ordren faktisk blev refunderet, vil automatiseringen skalere udeladelsen. Et tal med to decimaler ser præcist ud. Det kan stadig måle det forkerte.
Google Clouds dokumentation om evaluering af bedømmermodeller beskriver en praktisk kontrol: Forbered tilfælde med menneskers vurderinger, kør den modelbaserede måling, og sammenlign pointene. Pointen er ikke, at én persons syn er ufejlbarligt. Modellen har brug for en ekstern målestok, før dens score kan få vægt.
Undersøg uenigheder, ikke kun den gennemsnitlige enighed. Hvis bedømmeren godkender et svar, som en ansvarlig for support afviste, så spørg, hvilket manglende kriterium der forklarer det. Hvis to fagfolk er uenige, så bevar begge mærkninger og find den regel, de fortolker forskelligt. Udjævn ikke uenigheden i tavshed.
Udvalget af testtilfælde er lige så vigtigt som kriteriets ordlyd. En samling rutinemæssige succeser kan få en bedømmer til at virke pålidelig uden at røre de svære tilfælde. Medtag ufuldstændige poster, modstridende instrukser og tilfælde, hvor det korrekte svar er at stoppe og spørge. Bevar et særskilt sæt tilfælde, som rubrikkens forfattere ikke har justeret efter, så en ændring, der forbedrer kendte eksempler, også skal bevise sig andre steder. Når forretningsreglen ændres, skal både mærkninger og forventede resultater opdateres; et fastlåst testsæt kan belønne gårsdagens politik.
Hold resultatet knyttet til evalueringen
En rubrik for en synkroniseringsagent bør følge kundens resultat. Ændrede den rigtige kontakt sig? Blev samtykket respekteret? Kan en fejlet post køres igen uden at gentage en handling med konsekvenser?
Brevo-connectorguiden forklarer, hvorfor et vellykket API-kald kan sameksistere med en manglende egenskab. En evaluering, der kun kontrollerer, om agenten kaldte API’et, overser resultatet. En evaluering, der kun ser på destinationen, kan overse en forbudt vej, som tilfældigvis gav den rigtige værdi. Begge dele betyder noget, når vejen rummer risiko.
Begynd med én afgrænset opgave og få fejltyper. Mærk tilfældene sammen med den, der ejer opgaven. Sæt præcise kontroller i kode, og brug kun en modelbedømmer, når sprog eller vurdering faktisk kræver det. Kør de samme tilfælde efter en ændring i prompt, model eller værktøj. Registrer, hvad senere fejl lærer teamet om rubrikken.
Det koster ekspertens tid i begyndelsen. Gevinsten er, at alle senere scorer har en betydning, nogen kan forsvare.
Et dashboard kan vise en score. Kun rubrikken fortæller, hvad du talte.
Ofte Stillede Spørgsmål
Hvem skal definere kriterierne for at evaluere en AI-agent?
De mennesker, der kender opgaven og dens konsekvenser, skal definere acceptable resultater og diskvalificerende fejl. Ingeniører kan omsætte vurderingerne til gentagelige kontroller og teste, om en modelbedømmer er enig med menneskers vurderinger.
Beviser en høj score, at agenten virker?
Nej. En score måler overensstemmelse med rubrikken på de testede tilfælde. En svag rubrik, ikke-repræsentative tilfælde eller en dårligt kalibreret bedømmer kan give en skadelig handling høj score.
Hvad skal kode kontrollere i stedet for en modelbedømmer?
Præcise tilladelser, post-id'er, krævede værktøjskald og destinationens tilstand bør kontrolleres med kode, når det er muligt. En modelbedømmer er nyttig til betydning og kvalitet, som præcise regler ikke kan afgøre.