Procjene kojima upravlja pristupnik za odabir modela umjetne inteligencije: promovirajte jeftinije ili brže modele bez tihe regresije

Timovi obično ne prekidaju tijek rada umjetne inteligencije zamjenom modela s očito lošim. Razbijaju ih uvođenjem razumne promjene usmjeravanja koja izgleda jeftinije, brže ili dostupnije, a kasnije otkrivaju da su sažeci manje vjerni, da su pozivi alata pogrešno oblikovani ili da se ponašanje odbijanja promijenilo zbog malog, ali važnog radnog opterećenja zakupca.

Praktični odgovor je tretirati rezultate procjene kao artefakt promocije unutar pristupnika. Prije no što pseudonim modela, profil stanara ili politika usmjeravanja usmjere na novog kandidata, pristupnik bi trebao moći pokazati koji je skup podataka korišten, koji su ocjenjivači pokrenuti, kako je kandidat u usporedbi s trenutnom osnovnom linijom, kakav je bio učinak na cijenu i kašnjenje, tko je odobrio promjenu i kako je vratiti.

Ovaj članak opisuje referentni uzorak za procjene kojima upravlja pristupnik za odabir AI modela. Fokusira se na kontrolu proizvodnje, a ne na jurnjava za referentnim vrijednostima.

Činjenice, preporuke i predviđanja

Činjenice: Moderni alati za procjenu mogu definirati skupove podataka za procjenu koji se mogu ponovno koristiti, pokrenuti višestruke konfiguracije modela i vratiti rezultate ocjenjivanja na izlaznoj razini, status prolaza, brojeve tokena i skupne metrike. Uobičajene vrste ocjenjivača uključuju točne provjere nizova, metrike sličnosti, provjere sheme ili izračunavanja i ocjenjivače temeljene na modelu. Evaluacija u parovima može usporediti odgovore kandidata s osnovnom linijom, dok evaluacija po točkama boduje jedan odgovor u odnosu na rubriku ili očekivani odgovor.

Preporuke: Koristite determinističke ocjenjivače gdje god zadatak ima jasan ugovor, kao što je važeći JSON, obavezna polja, dopuštene oznake, oblik argumenta alata, prisutnost citata, kategorija odbijanja ili numerička tolerancija. Upotrijebite prosudbenike temeljene na modelu za kvalitetu bez ograničenja tek nakon što ih provjerite s malim skupom ocijenjenim od strane ljudi. Nemojte promicati model samo iz javnog mjerila; promovirajte ga iz dokaza povezanih s vašim vlastitim tragovima, stanarima, alatima, proračunima i načinima neuspjeha.

Predviđanja: Promocija modela pomaknut će se s ad hoc odluka o aplikacijama u kontrolne ravnine pristupnika jer pristupnici već sadrže katalog modela, pravila usmjeravanja, tragove korištenja, pravila stanara i podatke o naplati koji su potrebni da bi se promjene modela mogle revidirati. Timovi koji drže procjene odvojene od usmjeravanja i dalje će izvoditi testove, ali će se mučiti da dokažu koji su dokazi podržavali promjenu pseudonima uživo.

Problem čitatelja: Promjene usmjeravanja trebaju dokaze

API s više modela olakšava promjenu ciljnog modela. To je korisno, ali također stvara problem kontrole. Tim će možda htjeti zamijeniti skupi model sažimanja podrške jeftinijim kandidatom, dodati rezervni model za dostupnost, premjestiti zadatke kodiranja na brži model ili preusmjeriti zakupce niskog prioriteta na nižu razinu.

Svaka promjena ima drugačiji profil rizika. Jeftiniji sažetak može izostaviti detalje eskalacije. Brži klasifikator može pogrešno rukovati rijetkim oznakama. Rezervni model može koristiti drugačiji format poziva alata. Noviji model rezoniranja može poboljšati teške slučajeve dok povećava latenciju p95. Bilješke o izdanju pružatelja usluga i javne ploče s najboljim rezultatima ne mogu odgovoriti jesu li ti kompromisi prihvatljivi za određenu aplikaciju.

Gateway je prirodno mjesto za uklanjanje te praznine jer vidi zahtjeve, odgovore, zakupce, ključeve, aliase, troškove, kašnjenje, stope pogrešaka, pozive alata i odluke o politici. Procjene kojima upravlja pristupnik pretvaraju taj operativni kontekst u ponovljivi tijek promocije.

Referentna arhitektura

Praktična arhitektura ima sedam dijelova:

1. Uzorkivač praćenja: odabire stavke procjena kandidata iz proizvodnog prometa, neuspjelih zahtjeva, skupih zahtjeva, uzoraka koje je odobrio stanar i poznatih rubnih slučajeva.
2. Redakcija i pristanak. provjerava: uklanja ili maskira osjetljiva polja, provodi politiku zapisivanja zakupca i zadržavanja i blokira uzorke koji se ne mogu koristiti za procjene.
3. Eval registar skupa podataka: pohranjuje nepromjenjive verzije skupa podataka s vrstom zadatka, opsegom zakupca, verzijom predloška upita, verzijom sheme alata, očekivanim rezultatima gdje su dostupni i porijeklom.
4. Pokretač modela kandidata: reproducira stavke skupa podataka u usporedbi s trenutnom osnovnom linijom i jednim ili više modela kandidata pomoću kontroliranih parametara.
5. Ocjenjivači: primjenjuju determinističke provjere, metrike temeljene na računanju i kalibrirane prosudbe temeljene na modelu.
6. Zapis odluke o promaknuću: bilježi ID procjene, verziju skupa podataka, ID osnovnog modela, ID modela kandidata, verzije ocjenjivača, pragovi, rezultati, vlasnik, odobrenje i cilj vraćanja.
7. Ažuriranje pseudonima ili pravila usmjeravanja: ažurira pristupnik uživo tek nakon što odluka o promociji prođe potrebna vrata.

Ovo održava evals povezanima s implementacijom. Eval run nije izvješće koje je netko zalijepio u nit razgovora.To je objekt kontrolne ravni koji je potreban prije promjene aliasa kao što je support-fast, coding-default ili summarize-cheap.

Izradite tri klase skupa podataka

1. Zlatni slučajevi regresije

Zlatni slučajevi odabrani su primjeri s očekivanim odgovorima ili strogim kriterijima uspjeha. Dovoljno su mali za ručni pregled i dovoljno stabilni za rad na svakoj predloženoj promociji.

Koristite ih za zadatke s jasnim ugovorima: klasifikacija, izdvajanje, strukturirani sažeci, odluke o politici, odabir alata, oznake usmjeravanja i ponašanje odbijanja. Zlatna stavka trebala bi uključivati unos, očekivani izlaz ili rubriku, dopuštenu varijaciju, metapodatke zadatka i sve sheme alata potrebne za reprodukciju poziva.

Primjeri polja:

{
  "dataset_item_id": "support-summary-0421",
  "task": "support_summary",
  "tenant_scope": "shared_redacted",
  "ulazne_poruke": [...],
  "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. Rubni slučajevi izvedeni iz proizvodnje

Kućišta izvedeni iz proizvodnje hvataju greške koje sintetički testovi obično propuštaju. Dobri izvori uključuju skupe zahtjeve, ponovne pokušaje, ručna nadjačavanja, ispravke korisnika, rezultate klasifikatora s niskom pouzdanošću, kvarove sheme, pozive dugog konteksta, zahtjeve blizu ograničenja latencije i tijekove rada zakupca s neuobičajenim korištenjem alata.

Pravilo privatnosti je jednostavno: proizvodni tragovi korisni su samo ako su dopušteni. Pristupnik bi trebao provoditi pristanak stanara, politiku zadržavanja podataka, redakciju i ograničenja boravka prije nego što praćenje uđe u skup podataka eval. Osjetljivi zakupci možda će trebati izvršenje procjene u okruženju, sintetičke ekvivalente ili redigirane tragove koji uklanjaju neobrađene upite i identifikatore.

3. Suparnički slučajevi i slučajevi politike

Suparnički slučajevi testiraju ponašanje koje ne uspijeva pod pritiskom: zlouporaba alata, brzo ubrizgavanje, nesigurno otkrivanje, ograničenja odbijanja, skriveni sukobi uputa, neispravne datoteke, nevažeći citati i dvosmisleni korisnički zahtjevi. Ovi slučajevi ne moraju biti dramatični. Oni moraju predstavljati načine na koje vaše aplikacije mogu uzrokovati štetu kada model postane previše popustljiv, previše poslušan ili previše nemaran.

Za agencijske tijekove rada uključite potpunu povijest poruka i kontekst poziva alata, a ne samo jednokratne upite. Kandidat koji dobro odgovori na jednookretno pitanje može ipak pasti kada mora provjeriti rezultate alata, sačuvati granice autoriteta i proizvesti valjane argumente za nizvodnu radnju.

Prvo koristite determinističke ocjenjivače

Počnite s ocjenjivačima koji ne zahtijevaju prosudbu. Oni su jeftiniji, brži, lakši za otklanjanje pogrešaka i manja je vjerojatnost da će se povući.

Korisne determinističke provjere uključuju:

• JSON uspješno analizira i odgovara traženoj shemi.
• Obavezna polja su prisutna, a zabranjena polja se ne pojavljuju.
• Izlaz klasifikacije jedna je od dopuštenih oznaka.
• Numerički odgovor spada unutar prihvaćenog. tolerancija.
• Naziv alata dopušten je za zakupca i tijek rada.
• Argumenti alata prolaze provjeru valjanosti sheme i pravila.
• Odgovor uključuje potrebne citate ili identifikatore izvora.
• Odgovor ne uključuje poznate zabranjene izraze, tajne ili interne oznake.
• Kategorija odbijanja odgovara očekivanom ishodu pravila.

Ovo provjere bi trebale biti stroge promotivne kapije. Ako kandidat ne može proizvesti valjani strukturirani izlaz ili sigurne pozive alata, dobar rezultat otvorenog pisanja ne bi ga trebao spasiti.

Pažljivo koristite prosudbe temeljene na modelu

Otvoreni zadaci i dalje zahtijevaju kvalitetnu procjenu. Sažeci mogu biti vjerni, ali ne i točni. Odgovori podrške mogu zahtijevati ton, potpunost i usklađenost s pravilima. Pomoć pri kodiranju može zahtijevati usporedbu u paru s osnovnim odgovorom.

Ocjene temeljene na modelu korisne su za ovaj sloj, ali ih se ne bi trebalo tretirati kao objektivnu istinu. Kalibrirajte ih prema malom ljudskom uzorku prije nego što blokiraju ili odobre promjene u proizvodnji. Provjeravajte slaže li se sudac s ljudskim oznakama dovoljno često za razinu rizika tijeka rada.Za suce u parovima, pazite na pristranost položaja, preferenciju opširnosti i neprimjećivanje da su oba odgovora neprihvatljiva.

Praktična rubrika suca za sažetak podrške mogla bi ocijeniti:

• Vjernost: Izbjegava li sažetak dodavanje činjenica koje nisu prisutne u razgovoru?
• Cjelovitost: Uključuje li problem klijenta, traženu radnju, relevantne pojedinosti o narudžbi i sljedeći korak?
• Mogućnost djelovanja: Može li ga agent koristiti bez ponovnog čitanja cijele niti?
• Prikladnost politike: Izbjegava li obećanje povrata novca, kredita ili eskalacije koji nisu odobreni?

Za promociju, kombinirajte minimalne bodove s usporedbom u paru. Stopa pobjeda u parovima korisna je pri zamjeni osnovne linije, ali može sakriti apsolutne neuspjehe ako su oba odgovora loša. Kandidat bi trebao zadovoljiti minimalne prolazne/neuspješne prolaze prije nego što kvaliteta po paru odluči je li bolji, ekvivalentan ili lošiji od trenutnog modela.

Definirajte karticu rezultata promocije

Kartica rezultata promocije pristupnika trebala bi kombinirati kvalitetu, latenciju, cijenu i radnu sigurnost. Točni pragovi ovise o radnom opterećenju, ali tablica rezultata trebala bi biti eksplicitna prije početka izvođenja.

Za svaki model kandidata pratite:

• Prolaznost kvalitete: postotak stavki skupa podataka koje prolaze potrebna deterministička i rubrička vrata.
• Stopa pobjede u paru: kandidat u odnosu na trenutnu osnovnu vrijednost na otvorenom. kvaliteta.
• p95 latencija: izmjereno prema reprezentativnim postavkama pristupnika.
• Procijenjeni trošak po uspješnom zadatku: ukupni procijenjeni trošak podijeljen s prihvaćenim izlazima, a ne neobrađenim pozivima.
• Valjanost strukturiranih izlaza: stopa prolaznosti sheme i stopa popravka.
• Valjanost poziva alata: dopuštena upotreba alata, valjano argumenti i odabir radnji u skladu s pravilima.
• Sigurnosni ili neuspjesi pravila: odbijanja, nesigurna dovršetka, markeri curenja podataka ili kršenja pravila stanara.
• Operativna kompatibilnost: ponašanje strujanja, sekvence zaustavljanja, ograničenja tokena, istek vremena i polja odgovora specifična za pružatelja usluga.

Cijena po uspješnom zadatku je važna. više od cijene po tokenu. Jeftiniji model koji ne prođe provjeru valjanosti sheme u 12 posto slučajeva može postati skuplji nakon ponovnih pokušaja, popravaka, ručnog pregleda i eskalacije podrške. Gateway ima analitiku naplate i upotrebe potrebnu za točan izračun.

Primjer: Zamjena modela sažimanja podrške

Pretpostavimo da trenutni alias support-fast ukazuje na skupi model koji se koristi za sažimanje razgovora korisnika u striktni JSON objekt. Tim želi promovirati jeftinijeg kandidata.

Tijek rada promocije mogao bi izgledati ovako:

1. Stvorite verziju skupa podataka support_summary_eval_2026_09_02 s 200 zlatnih slučajeva, 300 redigiranih rubnih slučajeva proizvodnje i 100 slučajeva kontradiktorne politike.
2. Pokrenite trenutnu osnovnu liniju i jeftinijeg kandidata s istim upitom predložak, shema, maksimalni izlazni tokeni i dostupnost alata.
3. Primijenite deterministička vrata: valjanost JSON-a na 99 posto ili više, potrebna pokrivenost činjenica na 97 posto ili više, nula zabranjenih obećanja povrata novca i nula nevažećih radnji alata.
4. Primijenite ocjenjivanje u paru temeljeno na modelu samo na stavke koje prolaze determinističke provjere.
5. Zahtijevajte od kandidata da izgubi za najviše definiranu marginu kvalitete u odnosu na osnovnu liniju, ostanite ispod trenutnog proračuna kašnjenja p95 i smanjite procijenjeni trošak po prihvaćenom sažetku.
6. Zabilježite ID evaluacijskog izvođenja, verziju skupa podataka, verzije ocjenjivača, ID modela kandidata, ID osnovnog modela, pragove, odobravatelja i cilj pseudonima vraćanja.
7. Canary pseudonim za ograničenu grupu stanara, nadgledajte kvarove sheme uživo i ispravke podrške, zatim proširite ili vratite nazad.

Ključna stvar je da kandidat nije primljen jer je jeftiniji. Prihvaća se samo ako dokaz o procjeni pokazuje da jeftiniji model ostaje unutar ugovora o zadatku.

Učinite zapise o promicanju nepromjenjivima

Gateway bi trebao sačuvati dovoljno detalja za odgovor na kasnije pitanje o incidentu: zašto je ovaj model promaknut?

Zapis o odluci o promicanju treba uključivati:

• ID promocije i ID nepromjenjivog izvođenja procjene.
• ID skupa podataka, skup podataka verzija i porijeklo skupa podataka.
• ID osnovnog modela i ID modela kandidata.
• Verzija predloška upita i skup parametara.
• Verzije sheme alata i ograničenja usmjeravanja.
• Imena ocjenjivača, verzije, pragovi i bilješke o kalibraciji.
• Zbirni rezultati i reference stavki koje nisu uspjele.
• Cijena i latencija procjene.
• Opseg zakupca i opseg uvođenja.
• Odobravač, vremenska oznaka i cilj vraćanja.

Ovo je posebno važno za pseudonime.Ako aplikacijski timovi pozivaju support-fast umjesto ID-a modela pružatelja, dobivaju stabilnost, ali pristupnik sada ima dužnost dokazati da su promjene pseudonima regulirane.

Kontrole privatnosti i zadržavanja

Procjene praćenja proizvodnje uvode obveze privatnosti. Uzorkivač praćenja nikada ne bi trebao zaobići pravila zakupca samo zato što su evaluacije interne. Prije pohranjivanja ili izvoza eval stavke, provjerite mogu li se zadržati neobrađeni upiti, jesu li dopušteni eval alati koje pruža pružatelj usluga, moraju li podaci ostati u određenoj regiji i sadrži li uzorak tajne, regulirane podatke ili identifikatore korisnika.

Za osjetljiva radna opterećenja upotrijebite jedan od tri sigurnija obrasca:

• Pokrenite eval unutar okruženja pristupnika bez slanja neobrađenih tragova hostiranom eval products.
• Koristite redigirane tragove koji čuvaju strukturu i način kvara, ali uklanjaju osjetljiva polja.
• Stvorite sintetičke slučajeve iz promatranih uzoraka kvarova bez kopiranja proizvodnog sadržaja.

Kompromis je stvaran. Procjene izvedene iz proizvodnje hvataju regresije specifične za radno opterećenje. Sintetičke ocjene smanjuju izloženost. Većina timova treba oboje.

Popis za provjeru implementacije

• Definirajte promicanje modela kao radni tijek kontrolne ravnine, a ne vježbu u bilježnici.
• Skupovi podataka o verziji, upiti, sheme alata, ocjenjivači i pragovi.
• Odvojite zlatne slučajeve, slučajeve koji proizlaze iz proizvodnje i kontradiktorne slučajeve.
• Pokrenite determinističke ocjenjivače prije nego suci temeljeni na modelu.
• Kalibrirajte suce u odnosu na uzorke koje su ocijenili ljudi za tijekove rada s velikim utjecajem.
• Mjerite cijenu po prihvaćenom zadatku, a ne samo cijenu po tokenu.
• Zahtijevajte ciljeve vraćanja prije promjena aliasa ili pravila usmjeravanja.
• Čuvajte evidenciju promocije za reviziju i pregled incidenta.
• Poštujte pristanak stanara, zadržavanje i prebivalište ograničenja za procjene temeljene na praćenju.
• Pratite žive kanarince jer procjene smanjuju rizik, ali ga ne uklanjaju.

Zaključak

Odabir AI modela ne bi trebao ovisiti o javnim mjerilima, bilješkama o izdanju ili ručnoj usporedbi jednog programera. U API pristupniku s više modela, promjene modela utječu na stanare, proračune, latenciju, ponašanje alata, strukturirane izlaze i sigurnosnu politiku. To procjene čini dijelom upravljanja proizvodnjom.

Uzorak koji se može učiniti je jednostavan: uzorkujte reprezentativne tragove, redigirajte ih i filtrirajte prema pravilima, verzirajte skup podataka o procjeni, pokrenite osnovnu liniju i kandidate, prvo ocijenite determinističkim provjerama, koristite kalibrirane prosudbenike za otvorenu kvalitetu, kombinirajte kvalitetu s kašnjenjem i cijenom i zahtijevajte nepromjenjivi zapis promocije prije promjene aliasa ili pravila usmjeravanja.

Rezultat je ne sporije usvajanje modela. To je usvajanje modela s dokazima. Jeftiniji i brži kandidati još uvijek mogu prijeći u proizvodnju, ali moraju dokazati da ušteda ne dolazi od tihe regresije zadatka.

Povezana literatura

• aliasi internog modela i spremni za vraćanje promocija
• testiranje obustave modela i runbookovi za migraciju
• praćenja pristupnika i sigurno brzo bilježenje