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 baznom 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 jurenje referentnih vrijednosti.

Č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ć drž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 boriti da dokažu koji dokazi podržavaju promjenu pseudonima uživo.

Problem čitača: Promjene usmjeravanja trebaju dokaze

Više modela API olakšava promjenu ciljanog 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ži nivo.

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, pseudonime, 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 ocjenjivanja kandidata iz proizvodnog prometa, neuspjelih zahtjeva, skupih zahtjeva, uzoraka koje su odobrili zakupci i poznate prednosti slučajevima.
2. Provjere redigiranja i pristanka: uklanja ili maskira osjetljiva polja, nameće politiku zapisivanja i zadržavanja stanara i blokira uzorke koji se ne mogu koristiti za procjene.
3. Eval registar skupa podataka: pohranjuje nepromjenjive verzije skupa podataka s vrstom zadatka, opsegom stanara, verzijom predloška upita, verzija sheme alata, očekivani rezultati gdje su dostupni i porijeklo.
4. Pokretač modela kandidata: ponovno prikazuje stavke skupa podataka u odnosu na trenutnu osnovnu liniju i jedan ili više modela kandidata koristeći kontrolirane parametre.
5. Ocjenjivači: primjenjuju determinističke provjere, metrike temeljene na izračunima i kalibriraju prosudba temeljena na modelu.
6. Zapis odluke o promaknuću: bilježi ID procjene, verziju skupa podataka, ID osnovnog modela, ID modela kandidata, verzije ocjenjivača, pragove, rezultate, vlasnika, odobrenje i cilj vraćanja.
7. Ažuriranje aliasa ili pravila usmjeravanja: pristupnik uživo tek nakon što odluka o promaknuću prođe potrebne pristupnike.

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

Izgradite 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 treba uključivati ​​unos, očekivani izlaz ili rubriku, dopuštenu varijaciju, metapodatke zadatka i sve sheme alata potrebne za reprodukciju poziva.

Primjer polja:

{
  "dataset_item_id": "support-summary-0421",
  "task": "support_summary",
  "tenant_scope": "shared_redacted",
  "input_messages": [...],
  "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

Slučajevi 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 prebivališta 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. Adversarial and Policy Cases

Adversarial Cases testira 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 zahtjevi korisnika. Ovi slučajevi ne moraju biti dramatični.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 agentske tijekove rada, uključite potpunu povijest poruka i kontekst poziva alata, a ne samo jednokratne upite. Kandidat koji dobro odgovori na jednokratno pitanje može još uvijek 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 raščlanjuje i podudara se s potrebnom shemom.
• Obavezna polja su prisutna, a zabranjena polja se ne pojavljuju.
• Izlaz klasifikacije jedan je od dopuštenih oznake.
• Numerički odgovor je unutar prihvaćene tolerancije.
• Naziv alata dopušten je za stanara 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 fraze, tajne ili interni markeri.
• Kategorija odbijanja odgovara očekivanom ishodu pravila.

Ove provjere trebale bi biti stroga ograničenja promocije. 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 prosudbu. 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 ne treba 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 paru, pazite na pristranost položaja, preferenciju opširnosti i neprimjećivanje da su oba odgovora neprihvatljiva.

Praktična sučeva rubrika za sažetak podrške može ocijeniti:

• Vjernost: Izbjegava li sažetak dodavanje činjenica koje nisu prisutne u razgovor?
• Cjelovitost: Uključuje li problem klijenta, traženu radnju, relevantne pojedinosti o narudžbi i sljedeći korak?
• Mogućnost djelovanja: Može li agent to upotrijebiti bez ponovnog čitanja cijele niti?
• Prikladnost pravila: Izbjegava li obećanje povrati, krediti ili eskalacije koje nisu odobrene?

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 treba 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

Tabela 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 otvorene kvalitete.
• p95 latencija: izmjereno pod reprezentativnim postavkama pristupnika.
• Procijenjeni trošak po uspješnom zadatku: ukupni procijenjeni trošak podijeljen s prihvaćenim izlazima, a ne neobrađenim pozivima.
• Strukturirani izlaz valjanost: stopa prolaznosti sheme i stopa popravka.
• Valjanost poziva alata: dopuštena upotreba alata, važeći argumenti i odabir radnji usklađenih s pravilima.
• Sigurnost ili greške u politici: odbijanja, nesigurna dovršetka, oznake curenja podataka ili politika stanara kršenja.
• 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 važnija je 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 predloškom upita, shema, maksimalni izlazni tokeni i dostupnost alata.
3. Primijeni deterministička vrata: JSON valjanost 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. Primijeni parno ocjenjivanje temeljeno na modelu samo na stavke koje prolaze deterministički provjere.
5. Zahtijevati od kandidata da gubi za najviše definiranu marginu kvalitete u odnosu na osnovnu liniju, ostati ispod trenutnog proračuna kašnjenja p95 i smanjiti procijenjeni trošak po prihvaćenom sažetku.
6. Zabilježite ID procjene, verziju skupa podataka, verzije ocjenjivača, ID modela kandidata, ID osnovnog modela, pragove, odobravatelja i pseudonim vraćanja target.
7. Canary je pseudonim za ograničenu grupu stanara, nadzire kvarove sheme uživo i podržava ispravke, zatim proširi ili vrati nazad.

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

Učinite zapise o promaknuću nepromjenjivima

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

Zapis o odluci o promaknuću treba uključivati:

• ID promocije i nepromjenjivi izlazak za procjenu ID.
• ID skupa podataka, verzija skupa podataka 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.
• Procjene troškova i kašnjenja.
• Opseg zakupca i opseg uvođenja.
• Odobravač, vremenska oznaka i cilj vraćanja.

Ovo je posebno važno za aliasi. Ako aplikacijski timovi pozovu 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 hostira 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 koristite jedan od tri sigurnija obrasca:

• Pokrenite evals unutar pristupnika okruženje bez slanja neobrađenih tragova hostiranim eval proizvodima.
• Koristite redigirana praćenja koja čuvaju strukturu i način kvara, ali uklanjaju osjetljiva polja.
• Stvorite sintetičke slučajeve iz uočenih uzoraka kvarova bez kopiranja proizvodnog sadržaja.

Razvoj 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.

Kontrolni popis za implementaciju

• Definirajte promicanje modela kao radni tijek kontrolne ravnine, a ne vježbu u bilježnici.
• Skupovi podataka verzija, upute, sheme alata, ocjenjivači i pragovi.
• Odvojite zlatne, proizvodno izvedeni i kontradiktorni slučajevi.
• Pokrenite determinističke ocjenjivače prije sudaca temeljenih na modelu.
• Kalibrirajte suce u odnosu na uzorke ocijenjene od strane ljudi za tijekove rada s visokim učinkom.
• Izmjerite cijenu po prihvaćenom zadatku, a ne samo cijenu po tokenu.
• Zahtijevajte ciljeve vraćanja prije aliasa ili promjene pravila usmjeravanja.
• Sačuvajte zapise o promicanju za reviziju i pregled incidenta.
• Poštujte pristanak stanara, zadržavanje i ograničenja boravka za procjene temeljene na praćenju.
• Pratite žive kanarince jer procjene smanjuju rizik, ali ne eliminiraju it.

Zaključak

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

Uzorak koji se može učiniti je jednostavan: uzorkujte reprezentativne tragove, redigirajte ih i filtrirajte prema politici, verzirajte eval skup podataka, 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 usmjeravanja pravila.

Rezultat nije 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

• interni aliasi modela i promocija spremna za vraćanje na staro stanje
• testiranje zastarjelog modela i migracija runbooks
• tragovi pristupnika i sigurno brzo zapisivanje