Na ovoj stranici
Odgovor o vraćenoj narudžbi izgleda spreman za slanje: gramatički je točan, ljubazan i kratak. U ovom ilustrativnom slučaju automatizirana ocjena daje mu sve bodove. Pomoćnik također kaže kupcu da je povrat novca izvršen, iako nitko nije provjerio platni sustav.
Pogreška nije slaba rečenica. Pogreška je slaba definicija dobrog.
U zabilježenoj demonstraciji ocjenjivanja, tim gradi bodovanje za agenta koji piše softversku dokumentaciju. Zanimljiv je trenutak kada osoba koja poznaje posao opisuje kvalitetu, a alat opis pretvara u kriterije. Poslije niska ocjena izaziva pravo pitanje: treba li popraviti agenta ili ocjenjivanje?
Mjerila su teorija o zadatku. Testirajte teoriju.
Počnite pogreškom koja isključuje rezultat
Timovi često počinju dimenzijama koje je lako ocijeniti: jasnoća, ton, struktura i potpunost. Korisne su. Rijetko su dovoljne.
Za ilustrativni odgovor o povratu novca „nikada ne tvrdite da je povrat obavljen bez potvrde plaćanja” važnije je od kvalitete teksta. Za sinkronizaciju podataka „ne mapirajte adresu e-pošte za naplatu na adresu vlasnika računa” važnije je od dobrog objašnjenja mapiranja.
Zatražite od stručnjaka područja tri vrste slučajeva: očito dobar, očito pogrešan i jedan oko kojeg se upućeni ljudi mogu razići. Sačuvajte izvorne zapise i razlog svake ocjene. Ako slučaj ovisi o promjenjivom pravilu, pohranite verziju pravila uz oznaku.
Prvi skup može biti malen. Ne može biti neodređen.
- Vlasnik zadatka
dobri, loši i sporni slučajevi
- Točne provjere identitet · dopuštenje · odredište
kod provodi činjenice
- Značenjski kriteriji
ocjenjujte samo što traži tumačenje
- Pregled neslaganja
ispravite oznake i kriterije
| Provjera | Bolji nositelj | Zašto |
|---|---|---|
| Postoji potrebno dopuštenje | Kod i mjerodavni zapisi | Činjenica je točna i važna |
| Odredišni ID odgovara izvornom identitetu | Kod i testni zapis | Model ne treba pogađati identifikator |
| Odgovor rješava kupčevo pitanje | Kriteriji koje je pregledao čovjek, možda model-ocjenjivač | Značenje traži tumačenje |
| Ton odgovara situaciji | Kriteriji koje je pregledao čovjek, možda model-ocjenjivač | Više je prihvatljivih oblika |
Vodič za primjenu AI-ja u postojećim tijekovima postavlja istu granicu za odluke: kod čuva izvorne vrijednosti i provjerava ograničenja nakon što model izabere među mogućnostima. Modelova ocjena pouzdanosti ne postaje dopuštenje.
Rezultat nasljeđuje slijepe točke kriterija
Prigovor je pošten: „Čovjek ne može pregledati svako agentovo izvođenje. Treba nam ocjenjivač koji se može skalirati.” Da. Pitanje je što se skalira.
Ako kriteriji nagrađuju dotjeran odgovor, a nikad ne provjere je li novac doista vraćen, automatizacija će širiti propust. Broj s dvije decimale izgleda precizno. Može mjeriti pogrešnu stvar.
Google Cloud dokumentacija o ocjenjivanju modela-ocjenjivača opisuje praktičnu provjeru: pripremite slučajeve s ljudskim ocjenama, pokrenite modelsku mjeru i usporedite ocjene. Svrha nije tvrditi da je stav jedne osobe nepogrešiv. Modelu treba vanjsko mjerilo prije nego što njegov broj dobije težinu.
Pregledajte neslaganja, ne samo prosječno slaganje. Ako ocjenjivač prihvati odgovor koji je voditelj podrške odbio, pitajte koji kriterij nedostaje. Ako se dva stručnjaka ne slažu, sačuvajte obje oznake i pronađite pravilo koje tumače drukčije. Nemojte tiho izravnati spor prosjekom.
Odabir slučajeva važan je koliko i formulacija kriterija. Skup uobičajenih uspjeha može pokazati ocjenjivača pouzdanim, a teške slučajeve ostaviti netaknutima. Uključite nepotpune zapise, sukobljene upute i slučajeve u kojima je pravi odgovor stati i pitati. Sačuvajte odvojen skup slučajeva na kojem autori nisu ugađali kriterije, da se poboljšanje poznatih primjera mora dokazati i drugdje. Kada se poslovno pravilo promijeni, osvježite oznake i očekivane ishode; zamrznut skup testova može nagrađivati jučerašnju politiku.
Ostavite ishod spojen s ocjenjivanjem
Mjerila za agenta sinkronizacije trebaju pratiti kupčev rezultat. Je li promijenjen pravi kontakt? Je li poštovana privola? Može li se neuspjeli zapis ponovno izvesti bez ponavljanja radnje s posljedicama?
Vodič za Brevo poveznik objašnjava zašto uspješan API poziv može postojati uz atribut koji nedostaje. Ocjenjivanje koje provjerava samo je li agent pozvao endpoint promašit će ishod. Ocjenjivanje koje provjerava samo odredište može propustiti zabranjeni put koji je slučajno završio pravom vrijednošću. Oboje je važno kada put nosi rizik.
Počnite jednim uskim zadatkom i nekoliko načina pogreške. Označite slučajeve s osobom odgovornom za zadatak. Točne provjere stavite u kod, a model-ocjenjivač koristite samo gdje jezik ili prosudba to doista zahtijevaju. Iste slučajeve pokrenite nakon promjene upute, modela ili alata. Zabilježite što kasnije pogreške otkrivaju o kriterijima.
Cijena je vrijeme stručnjaka unaprijed. Dobitak je da svaki kasniji broj ima značenje koje netko može obraniti.
Nadzorna ploča može pokazati broj. Samo kriteriji govore što ste brojili.
Često postavljana pitanja
Tko treba odrediti kriterije ocjenjivanja agenta AI-ja?
Ljudi koji poznaju zadatak i njegove posljedice trebaju odrediti prihvatljive rezultate i pogreške koje ih diskvalificiraju. Inženjeri mogu te prosudbe pretvoriti u ponovljive provjere i ispitati slaže li se model-ocjenjivač s ljudskim ocjenama.
Dokazuje li visok rezultat ocjenjivača da agent radi?
Ne. Rezultat mjeri slaganje s kriterijima na testiranim slučajevima. Slabi kriteriji, nereprezentativni slučajevi ili loše podešen ocjenjivač mogu dati visoku ocjenu štetnom rezultatu.
Što treba provjeravati kodom umjesto modelom-ocjenjivačem?
Točna dopuštenja, identifikatore zapisa, obvezne pozive alata i stanje odredišta treba provjeravati kodom kad god je moguće. Model-ocjenjivač koristan je za značenjske osobine koje točna pravila ne mogu razriješiti.