På denne siden
Et svar om en returnert ordre ser klart ut til å sendes: grammatisk korrekt, vennlig og kort. I dette tenkte tilfellet gir et automatisk vurderingssystem toppscore. Assistenten sier også til kunden at refusjonen er gjennomført, selv om ingen har sjekket betalingssystemet.
Feilen er ikke en svak setning. Det er en svak definisjon av godt.
I en demonstrasjon av evaluering lager et team poeng for en agent som skriver programvaredokumentasjon. Det interessante øyeblikket er når personen som kjenner arbeidet, beskriver hva kvalitet betyr, og et verktøy gjør beskrivelsen om til kriterier. Senere vekker en lav score riktig tvil: Kanskje agenten trenger en rettelse, eller kanskje evalueringen gjør det.
Vurderingsskjemaet er en teori om oppgaven. Test teorien.
Start med feilen som diskvalifiserer
Team begynner ofte med dimensjoner som er lette å gi poeng: klarhet, tone, struktur og fullstendighet. De er nyttige. De er sjelden nok.
For det tenkte svaret om refusjon bør «hev aldri at en refusjon er gjennomført uten en kvittering fra betalingssystemet» veie tyngre enn tekstkvalitet. For en datasynkronisering er «ikke map e-postadressen for fakturering til kontoeierens e-postadresse» viktigere enn om forklaringen av feltmappingen er velskrevet.
Be fageksperten om tre typer tilfeller: ett åpenbart godt, ett åpenbart feil og ett der informerte personer kan være uenige. Behold kildepostene og begrunnelsen for hver vurdering. Hvis et tilfelle avhenger av en regel som kan endres, lagre regelversjonen sammen med merkingen.
Den første runden kan være liten. Den kan ikke være vag.
- Oppgaveeier
gode, dårlige og omstridte tilfeller
- Eksakte kontroller identitet · tillatelse · målsystem
kode håndhever fakta
- Vurdering av mening
bruk dommer bare der tolkning trengs
- Gjennomgang av uenighet
rett merking og kriterier
| Kontroll | Bedre ansvarlig | Hvorfor |
|---|---|---|
| Påkrevd tillatelse finnes | Kode og autoritative poster | Faktumet er eksakt og viktig |
| Målsystemets ID samsvarer med identiteten i kilden | Kode og en testpost | En modell bør ikke gjette en identifikator |
| Svaret besvarer kundens spørsmål | Vurderingsskjema gjennomgått av mennesker, eventuelt med modelldommer | Mening krever tolkning |
| Tonen passer situasjonen | Vurderingsskjema gjennomgått av mennesker, eventuelt med modelldommer | Flere uttrykksmåter kan være akseptable |
Vår guide til AI i eksisterende arbeidsflyter trekker samme grense for beslutninger i en arbeidsflyt: Kode bør bevare de opprinnelige verdiene og sjekke begrensninger etter at modellen har valgt mellom alternativer. Modellens konfidens gir ikke tillatelse.
En score arver blindsonene i skjemaet
Innvendingen er rimelig: «Et menneske kan ikke gjennomgå hver agentkjøring. Vi trenger en dommer som kan brukes i stor skala.» Ja. Spørsmålet er hva dommeren gjør i stor skala.
Hvis skjemaet belønner et polert svar og aldri sjekker om ordren faktisk ble refundert, vil automatisering spre utelatelsen. Et tall med to desimaler ser presist ut. Det kan fortsatt måle feil ting.
Google Clouds dokumentasjon om evaluering av dommermodeller beskriver en praktisk sjekk: Lag tilfeller med menneskelige vurderinger, kjør den modellbaserte målingen og sammenlign scorene. Poenget er ikke at én persons vurdering er ufeilbarlig. Det er at modellen trenger en standard utenfor seg selv før scorene kan bære vekt.
Undersøk uenighetene, ikke bare gjennomsnittlig samsvar. Hvis dommeren godtar et svar en leder for kundestøtte avviste, spør hvilket manglende kriterium som forklarer det. Hvis to eksperter er uenige, behold begge merkingene og finn regelen de tolker ulikt. Ikke la uenigheten forsvinne i et gjennomsnitt.
Utvalget betyr like mye som ordlyden i et kriterium. En samling vanlige suksesser kan få dommeren til å se pålitelig ut mens de vanskelige tilfellene ikke er testet. Ta med ufullstendige poster, instrukser i konflikt og tilfeller der riktig svar er å stoppe og spørre. Behold et eget sett som de som laget skjemaet, ikke har justert mot, slik at en endring som forbedrer kjente eksempler, også må bevise seg andre steder. Når forretningsregelen endres, oppdater både merkingen og forventede resultater. Et fastlåst testsett kan belønne gårsdagens regel.
Hold resultatet knyttet til evalueringen
Et skjema for en synkroniseringsagent bør følge kundens resultat. Ble riktig kontakt endret? Ble samtykket respektert? Kan en feilet post kjøres på nytt uten å gjenta en handling med konsekvenser?
Guiden til Brevo-koblingen forklarer hvorfor et vellykket API-kall kan ende med et manglende attributt. En evaluering som bare sjekker om agenten kalte endepunktet, overser resultatet. En som bare sjekker målsystemet, kan overse en forbudt vei som tilfeldigvis endte med riktig verdi. Begge deler teller når fremgangsmåten har risiko.
Start med én smal oppgave og noen få feiltyper. Merk tilfellene sammen med den som eier oppgaven. Legg eksakte sjekker i kode, og bruk modelldommer bare der språk eller skjønn virkelig krever det. Kjør de samme tilfellene etter endringer i prompt, modell eller verktøy. Registrer hva senere feil avslører om skjemaet.
Kostnaden er eksperttid i starten. Gevinsten er at hver senere score har en betydning noen kan forsvare.
Et dashboard kan vise et tall. Bare vurderingsskjemaet forteller hva du telte.
Ofte Stilte Spørsmål
Hvem bør definere kriteriene for å vurdere en AI-agent?
De som kjenner oppgaven og konsekvensene, bør definere akseptable resultater og feil som diskvalifiserer dem. Utviklere kan gjøre vurderingene om til gjentakbare kontroller og teste om en modelldommer er enig med menneskelige vurderinger.
Er en høy dommerscore bevis for at agenten virker?
Nei. En score måler samsvar med et vurderingsskjema på tilfellene som ble testet. Et svakt skjema, lite representative tilfeller eller en dårlig kalibrert dommer kan gi høy score til et skadelig resultat.
Hva bør sjekkes med kode i stedet for en modelldommer?
Nøyaktige tillatelser, postidentifikatorer, påkrevde verktøykall og tilstanden i målsystemet bør sjekkes med kode når det er mulig. En modelldommer er nyttig for meningsinnhold som eksakte regler ikke kan avgjøre.