Ocene, ki jih upravlja prehod za izbiro modela umetne inteligence: promovirajte cenejše ali hitrejše modele brez tihih regresij

Ekipe običajno ne prekinejo delovnih tokov AI z zamenjavo modela z očitno slabim. Zlomijo jih tako, da naredijo razumno spremembo usmerjanja, ki je videti cenejša, hitrejša ali bolj dostopna, nato pa kasneje odkrijejo, da so povzetki manj verodostojni, da so klici orodij napačno oblikovani ali da se zavrnitveno vedenje spremeni zaradi majhne, ​​a pomembne delovne obremenitve najemnika.

Praktičen odgovor je, da rezultate vrednotenja obravnavamo kot artefakt napredovanja znotraj prehoda. Preden vzdevek modela, profil najemnika ali politika usmerjanja pokaže na novega kandidata, bi moral biti prehod sposoben prikazati, kateri nabor podatkov je bil uporabljen, kateri ocenjevalniki so bili zagnani, kako se je kandidat primerjal s trenutno osnovno linijo, kakšen je bil učinek stroškov in zakasnitve, kdo je odobril spremembo in kako jo vrniti.

Ta članek opisuje referenčni vzorec za vrednotenje, ki ga upravlja prehod, za izbiro modela AI. Osredotoča se na nadzor proizvodnje, ne na lovljenje primerjalnih vrednosti.

Dejstva, priporočila in napovedi

Dejstva: Sodobna orodja za vrednotenje lahko definirajo nabore podatkov za vrednotenje, ki jih je mogoče ponovno uporabiti, zaženejo več konfiguracij modelov in vrnejo rezultate ocenjevanja na izhodni ravni, stanje uspešnosti, število žetonov in skupne meritve. Pogosti tipi ocenjevalcev vključujejo natančne preglede nizov, metrike podobnosti, preverjanja shem ali izračunov in ocenjevalnike na podlagi modela. Ocenjevanje po parih lahko primerja odgovore kandidatov z izhodiščem, medtem ko ocenjevanje po točkah oceni en odgovor glede na rubriko ali pričakovani odgovor.

Priporočila: Uporabite deterministične ocenjevalce, kjer ima naloga jasno pogodbo, kot so veljaven JSON, zahtevana polja, dovoljene oznake, oblika argumenta orodja, prisotnost navedbe, kategorija zavrnitve ali številčna toleranca. Uporabite ocenjevalce na podlagi modela za neomejeno kakovost šele potem, ko jih preverite z majhnim naborom, ki ga oceni človek. Ne promovirajte modela zgolj na podlagi javnega merila; promovirajte ga iz dokazov, povezanih z vašimi lastnimi sledmi, najemniki, orodji, proračuni in načini napak.

Predvidevanja: Promocija modela se bo premaknila iz ad hoc aplikacijskih odločitev v ravnine nadzora prehodov, ker prehodi že vsebujejo katalog modelov, pravila usmerjanja, sledi uporabe, politike najemnikov in podatke o zaračunavanju, ki so potrebni za pregledovanje sprememb modela. Ekipe, ki ohranjajo vrednotenje ločeno od usmerjanja, bodo še vedno izvajale preizkuse, vendar se bodo trudile dokazati, kateri dokazi so podprli spremembo vzdevka v živo.

Težava bralca: Spremembe usmerjanja potrebujejo dokaze

API za več modelov olajša spreminjanje ciljnega modela. To je koristno, vendar povzroča tudi težave pri nadzoru. Ekipa bo morda želela zamenjati dragi model povzemanja podpore s cenejšim kandidatom, dodati nadomestni model za razpoložljivost, premakniti naloge kodiranja na hitrejši model ali preusmeriti najemnike z nizko prioriteto na nižjo cenovno raven.

Vsaka sprememba ima drugačen profil tveganja. Cenejši povzemalnik lahko izpusti podrobnosti stopnjevanja. Hitrejši klasifikator lahko napačno obravnava redke oznake. Nadomestni model lahko uporablja drugačno obliko klica orodja. Novejši model sklepanja lahko izboljša težke primere in hkrati poveča zakasnitev p95. Opombe ob izdaji ponudnika in javne lestvice najboljših ne morejo odgovoriti, ali so ti kompromisi sprejemljivi za določeno aplikacijo.

Prehod je naravno mesto za zapolnitev te vrzeli, saj vidi zahteve, odgovore, najemnike, ključe, vzdevke, stroške, zakasnitve, stopnje napak, klice orodij in odločitve pravilnikov. Ocene, ki jih upravlja prehod, spremenijo ta operativni kontekst v ponovljiv potek dela za promocijo.

Referenčna arhitektura

Praktična arhitektura ima sedem delov:

1. Vzorčevalnik sledenja: izbere elemente ocene kandidatov iz produkcijskega prometa, neuspešnih zahtev, dragih zahtev, vzorcev, ki jih je odobril najemnik, in znanih robnih primerov.
2. Urejanje in soglasje. preverja: odstrani ali prikrije občutljiva polja, uveljavi politiko beleženja in hrambe najemnikov ter blokira vzorce, ki jih ni mogoče uporabiti za vrednotenje.
3. Register nabora podatkov Eval: shrani nespremenljive različice nabora podatkov z vrsto opravila, obsegom najemnika, različico predloge poziva, različico sheme orodja, pričakovanimi izhodi, kjer so na voljo, in izvorom.
4. Zagon modela kandidata: ponovno predvaja elemente nabora podatkov glede na trenutno osnovno linijo in enega ali več kandidatnih modelov z uporabo nadzorovanih parametrov.
5. Ocenjevalci: uporabljajo deterministična preverjanja, meritve na podlagi izračunov in umerjeno presojo na podlagi modela.
6. Zapis odločitve o napredovanju: zajame ID evalvacije, različico nabora podatkov, ID osnovnega modela, ID kandidata, različice ocenjevalnika, pragovi, rezultati, lastnik, odobritev in cilj povrnitve.
7. Posodobitev vzdevka ali pravilnika o usmerjanju: posodobi prehod v živo šele, ko odločitev o napredovanju prestane zahtevana vrata.

To ohranja povezavo eval z uvajanjem. Eval run ni poročilo, ki ga je nekdo prilepil v nit klepeta.To je predmet nadzorne ravnine, potreben pred spreminjanjem vzdevka, kot je support-fast, coding-default ali summarize-cheap.

Izdelajte tri razrede nabora podatkov

1. Primeri zlate regresije

Zlati primeri so izbrani primeri s pričakovanimi odgovori ali strogimi merili uspeha. So dovolj majhni, da jih lahko ročno pregledate, in dovolj stabilni, da delujejo pri vsaki predlagani promociji.

Uporabite jih za opravila z jasnimi pogodbami: klasifikacija, ekstrakcija, strukturirani povzetki, politične odločitve, izbira orodij, usmerjevalne oznake in vedenje zavrnitve. Zlati element mora vključevati vnos, pričakovani izhod ali rubriko, dovoljeno različico, metapodatke opravila in morebitne sheme orodij, potrebne za reprodukcijo klica.

Primeri polj:

{
  "dataset_item_id": "support-summary-0421",
  "task": "support_summary",
  "tenant_scope": "shared_redacted",
  "vhodna_sporočila": [...],
  "expected_schema": "support_summary_v3",
  "required_facts": ["refund_requested", "order_id_present", "escalation_reason"],
  "disallowed_content": ["invented_refund_status"],
  "prompt_template_version": "support_summary_prompt_2026_08_14"
}

2. Robna ohišja, pridobljena iz proizvodnje

Ohišja, pridobljena iz proizvodnje, ujamejo napake, ki jih sintetični testi običajno zgrešijo. Dobri viri vključujejo zahtevke z visokimi stroški, ponovne poskuse, ročne preglasitve, popravke uporabnikov, izhode klasifikatorja z nizko stopnjo zaupanja, napake sheme, klice z dolgim ​​kontekstom, zahteve blizu omejitev zakasnitve in poteke dela najemnikov z nenavadno uporabo orodij.

Pravilo zasebnosti je preprosto: proizvodne sledi so uporabne samo, če so dovoljene. Prehod bi moral uveljaviti soglasje najemnika, politiko hrambe podatkov, redakcije in omejitve prebivališča, preden sled vstopi v nabor podatkov eval. Občutljivi najemniki bodo morda potrebovali izvedbo vrednotenja v okolju, sintetične ekvivalente ali redigirane sledi, ki odstranijo neobdelane pozive in identifikatorje.

3. Primeri kontradiktornosti in politike

Primeri kontradiktornosti preizkušajo vedenje, ki ne uspe pod pritiskom: napačna uporaba orodja, takojšnje vstavljanje, nevarno razkritje, meje zavrnitve, skriti konflikti navodil, napačno oblikovane datoteke, neveljavni citati in dvoumne zahteve uporabnikov. Ni nujno, da so ti primeri dramatični. Predstavljati morajo načine, na katere lahko vaše aplikacije povzročijo škodo, ko model postane preveč popustljiv, preveč ubogljiv ali preveč nepreviden.

Za agentske poteke dela vključite celotno zgodovino sporočil in kontekst klica orodja, ne le pozivov z enim obratom. Kandidat, ki dobro odgovori na vprašanje z enim obratom, morda še vedno ne uspe, ko mora pregledati rezultate orodja, ohraniti avtoritete in ustvariti veljavne argumente za nadaljnje dejanje.

Najprej uporabite deterministične ocenjevalce

Začnite z ocenjevalci, ki ne zahtevajo presoje. So cenejši, hitrejši, enostavnejši za odpravljanje napak in manjša verjetnost, da se bodo premaknili.

Uporabna deterministična preverjanja vključujejo:

• JSON uspešno razčleni in se ujema z zahtevano shemo.
• Obvezna polja so prisotna in prepovedana polja niso prikazana.
• Izhod klasifikacije je ena od dovoljenih oznak.
• Numerični odgovor spada v sprejeto toleranca.
• Ime orodja je dovoljeno za najemnika in potek dela.
• Argumenti orodja prestanejo preverjanje veljavnosti sheme in pravilnika.
• Odziv vključuje zahtevane citate ali identifikatorje vira.
• Odziv ne vključuje znanih prepovedanih stavkov, skrivnosti ali notranjih označevalcev.
• Kategorija zavrnitve se ujema s pričakovanim izidom pravilnika.

Ti preverjanja morajo biti stroga promocijska vrata. Če kandidat ne more ustvariti veljavnega strukturiranega izhoda ali varnih klicev orodij, ga dober rezultat odprtega pisanja ne bi smel rešiti.

Previdno uporabljajte ocenjevalce na podlagi modela

Odprte naloge še vedno potrebujejo kakovostno presojo. Povzetki so lahko zvesti, vendar ne natančni. Odgovori podpore bodo morda potrebovali ton, popolnost in uskladitev s pravilnikom. Pomoč pri kodiranju bo morda potrebovala parno primerjavo z osnovnim odgovorom.

Ocene na podlagi modela so uporabne za to plast, vendar jih ne bi smeli obravnavati kot objektivno resnico. Umerite jih glede na majhen vzorec, ki ga oceni človek, preden blokirajo ali odobrijo proizvodne spremembe. Preverite, ali se sodnik dovolj pogosto strinja s človeškimi oznakami glede na stopnjo tveganja delovnega toka.Pri sodnikih v parih bodite pozorni na pristranskost položaja, preferenco dobesednosti in neopaznost, da sta oba odgovora nesprejemljiva.

Praktična rubrika sodnika za povzemanje podpore bi lahko ocenila:

• Zvestoba: Ali se povzetek izogiba dodajanju dejstev, ki niso prisotna v pogovoru?
• Popolnost: Ali vključuje težavo stranke, zahtevano dejanje, ustrezne podrobnosti o naročilu in naslednji korak?
• Možnost ukrepanja: Ali ga lahko agent uporabi, ne da bi ponovno prebral celotno nit?
• Ustreznost pravilniku: Ali se izogiba obljubam vračil, kreditov ali stopnjevanju, ki niso bila odobrena?

Za napredovanje združite minimalne točke po točkah s primerjavo po parih. Stopnja zmage v parih je uporabna pri zamenjavi osnovne linije, vendar lahko prikrije absolutne napake, če sta oba odgovora slaba. Kandidat mora izpolnjevati minimalna merila za sprejem/neuspeh, preden se kakovost po parih odloči, ali je boljši, enakovreden ali slabši od trenutnega modela.

Določite kartico napredovanja

Karta napredovanja prehoda mora združevati kakovost, zakasnitev, stroške in varnost delovanja. Natančni pragovi so odvisni od delovne obremenitve, vendar mora biti preglednica rezultatov eksplicitna pred začetkom izvajanja.

Za vsak kandidatni model spremljajte:

• Stopnja uspešnosti kakovosti: odstotek elementov nabora podatkov, ki prestanejo zahtevana deterministična in rubrična vrata.
• Stopnja zmage v parih: kandidat v primerjavi s trenutno osnovno linijo na odprtem kakovost.
• zakasnitev p95: izmerjeno v reprezentativnih nastavitvah prehoda.
• Ocenjeni stroški na uspešno nalogo: skupni ocenjeni stroški, deljeni s sprejetimi izhodi, ne neobdelanimi klici.
• Veljavnost strukturiranih izhodov: stopnja uspešnosti sheme in stopnja popravil.
• Veljavnost klica orodja: dovoljena uporaba orodja, veljavno argumenti in izbira dejanj, skladnih s pravilnikom.
• Varnost ali napake pravilnika: zavrnitve, nevarna dokončanja, označevalci uhajanja podatkov ali kršitve pravilnika najemnika.
• Operativna združljivost: pretočno vedenje, zaustavitvena zaporedja, omejitve žetonov, časovne omejitve in polja odgovorov, specifična za ponudnika.

Pomembna je cena na uspešno opravilo več kot cena na žeton. Cenejši model, ki v 12 odstotkih primerov ne uspe preveriti sheme, lahko postane dražji po ponovnih poskusih, popravilih, ročnem pregledu in eskalaciji podpore. Prehod ima analitiko obračunavanja in uporabe, ki je potrebna za pravilen izračun.

Primer: Zamenjava modela povzemanja podpore

Predpostavimo, da trenutni vzdevek support-fast kaže na model z visokimi stroški, ki se uporablja za povzemanje pogovorov strank v strogi objekt JSON. Ekipa želi promovirati cenejšega kandidata.

Potek dela za promocijo bi lahko izgledal takole:

1. Ustvarite različico nabora podatkov support_summary_eval_2026_09_02 z 200 zlatimi primeri, 300 redigiranimi robnimi primeri proizvodnje in 100 primeri kontradiktorne politike.
2. Zaženite trenutno osnovno linijo in cenejšega kandidata z istim pozivom predloga, shema, maksimalni izhodni žetoni in razpoložljivost orodja.
3. Uporabite deterministična vrata: veljavnost JSON pri 99 odstotkih ali več, zahtevana pokritost dejstev pri 97 odstotkih ali več, nič prepovedanih obljub vračil in nič neveljavnih dejanj orodij.
4. Uporabite parno ocenjevanje na podlagi modela samo za elemente, ki prestanejo deterministična preverjanja.
5. Zahtevajte, da kandidat izgubi za največ definirano mejo kakovosti v primerjavi z izhodiščem, ostati pod trenutnim proračunom zakasnitve p95 in zmanjšati ocenjene stroške na sprejeti povzetek.
6. Zabeležite ID zagona eval, različico nabora podatkov, različice ocenjevalnika, ID modela kandidata, ID osnovnega modela, pragove, odobritelja in ciljni vzdevek za povrnitev.
7. Canary vzdevek za omejeno skupino najemnikov, spremljajte napake sheme v živo in podprite popravke, nato razširite ali prevrnite nazaj.

Bistveno je, da kandidat ni sprejet, ker je cenejši. Sprejme se le, če dokaz o vrednotenju kaže, da cenejši model ostane v pogodbi o opravilu.

Naredite zapise napredovanja nespremenljive

Prehod mora ohraniti dovolj podrobnosti za odgovor na kasnejše vprašanje incidenta: zakaj je bil ta model napredovan?

Zapis o odločitvi o napredovanju mora vključevati:

• ID napredovanja in ID nespremenljivega izvajanja vrednotenja.
• ID nabora podatkov, nabor podatkov različica in izvor nabora podatkov.
• ID osnovnega modela in ID kandidatnega modela.
• Različica in nabor parametrov predloge poziva.
• Različice sheme orodja in omejitve usmerjanja.
• Imena ocenjevalcev, različice, pragovi in opombe o umerjanju.
• Združeni rezultati in sklicevanja na neuspele elemente.
• Stroški in zakasnitve ocene.
• Obseg najemnika in obseg uvajanja.
• Odobritelj, časovni žig in cilj povrnitve.

To je še posebej pomembno za vzdevke.Če skupine aplikacij namesto ID-ja modela ponudnika pokličejo support-fast, pridobijo stabilnost, vendar je prehod zdaj dolžan dokazati, da so bile spremembe vzdevkov urejene.

Nadzor zasebnosti in hrambe

Ocene sledenja proizvodnje uvajajo obveznosti glede zasebnosti. Vzorčevalnik sledenja nikoli ne bi smel zaobiti pravilnika najemnika samo zato, ker so ocene notranje. Preden shranite ali izvozite element vrednotenja, preverite, ali se neobdelani pozivi lahko ohranijo, ali so dovoljena orodja za vrednotenje, ki jih gosti ponudnik, ali morajo podatki ostati v določeni regiji in ali vzorec vsebuje skrivnosti, nadzorovane podatke ali identifikatorje strank.

Za občutljive delovne obremenitve uporabite enega od treh varnejših vzorcev:

• Zaženite vrednotenja znotraj okolja prehoda, ne da bi pošiljali neobdelane sledi gostovanemu eval products.
• Uporabite redigirane sledi, ki ohranijo strukturo in način napake, vendar odstranijo občutljiva polja.
• Ustvarite sintetične primere iz opaženih vzorcev napak brez kopiranja proizvodne vsebine.

Kompromis je resničen. Iz proizvodnje izpeljane vrednosti ujamejo regresije, specifične za delovno obremenitev. Sintetične ocene zmanjšajo izpostavljenost. Večina ekip potrebuje oboje.

Kontrolni seznam za implementacijo

• Promocijo modela opredelite kot potek dela na nadzorni ravnini, ne kot vadbo v beležnici.
• Nabori podatkov različic, pozivi, sheme orodij, ocenjevalniki in pragovi.
• Ločite zlate primere, primere, ki izhajajo iz proizvodnje, in kontradiktorne primere.
• Preden zaženite deterministične ocenjevalce sodniki, ki temeljijo na modelih.
• Umerite sodnike glede na vzorce, ki jih ocenijo ljudje, za poteke dela z velikim vplivom.
• Izmerite stroške na sprejeto nalogo, ne le stroške na žeton.
• Zahtevajte cilje povrnitve pred spremembami vzdevkov ali pravilnika usmerjanja.
• Ohranite zapise o napredovanju za revizijo in pregled incidentov.
• Spoštujte soglasje najemnika, zadrževanje in bivanje. omejitve za vrednotenja, ki temeljijo na sledenju.
• Spremljajte žive kanarčke, ker vrednotenja zmanjšujejo tveganje, vendar ga ne odpravijo.

Zaključek

Izbira modela umetne inteligence ne sme biti odvisna od javnih meril uspešnosti, opomb ob izdaji ali ročne primerjave posameznega razvijalca. V prehodu API z več modeli spremembe modela vplivajo na najemnike, proračune, zakasnitev, obnašanje orodja, strukturirane rezultate in varnostno politiko. Zaradi tega so vrednotenja del upravljanja proizvodnje.

Uporabni vzorec je preprost: vzorčite reprezentativne sledi, jih redigirajte in filtrirajte po pravilniku, različico nabora podatkov o vrednotenju, zaženite osnovno linijo in kandidate, najprej ocenite z determinističnimi preverjanji, uporabite umerjene sodnike za neomejeno kakovost, združite kakovost z zakasnitvijo in stroški ter zahtevajte nespremenljiv zapis napredovanja, preden spremenite vzdevke ali pravila usmerjanja.

Rezultat je ne počasnejše sprejemanje modela. Gre za posvojitev modela z dokazi. Cenejši in hitrejši kandidati se lahko še vedno premaknejo v proizvodnjo, vendar morajo dokazati, da prihranki ne izvirajo iz tihe regresije opravil.

Sorodno branje

• notranji vzdevki modela in pripravljenost za povrnitev nazaj promocija
• preizkušanje zastarelosti modela in selitveni zvezki
• sledi prehodov in varno beleženje pozivov