Hodnocení řízené bránou pro výběr modelu AI: Propagujte levnější nebo rychlejší modely bez tichých regresí

Týmy obvykle nenarušují pracovní postupy AI tím, že nahrazují model zjevně špatným. Rozbijí je tím, že provedou rozumnou změnu směrování, která vypadá levněji, rychleji nebo dostupněji, a později zjistí, že souhrny jsou méně věrné, volání nástrojů mají nesprávný formát nebo se chování při odmítnutí změnilo kvůli malé, ale důležité zátěži nájemce.

Praktická odpověď je považovat výsledky eval za artefakt propagace uvnitř brány. Než alias modelu, profil tenanta nebo zásady směrování nasměrují na nového kandidáta, brána by měla být schopna ukázat, která datová sada byla použita, které srovnávače běžely, jak kandidát v porovnání s aktuálním výchozím stavem, jaký byl dopad na náklady a latenci, kdo schválil změnu a jak ji vrátit zpět.

Tento článek popisuje referenční vzor pro hodnocení modelu spravovaného bránou pro AI. Zaměřuje se na řízení výroby, nikoli na honbu za benchmarky.

Fakta, doporučení a předpovědi

Fakta: Moderní nástroje eval mohou definovat opakovaně použitelné datové sady hodnocení, spouštět konfigurace více modelů a vracet výsledky hodnocení na úrovni výstupu, stav průchodu, počty tokenů a souhrnné metriky. Mezi běžné typy srovnávačů patří přesné kontroly řetězců, metriky podobnosti, kontroly schémat nebo výpočtů a srovnávače založené na modelu. Párové hodnocení může porovnávat odpovědi kandidátů se základní linií, zatímco bodové hodnocení hodnotí jednu odpověď oproti rubrice nebo očekávané odpovědi.

Doporučení: Deterministické srovnávače používejte všude tam, kde má úkol jasnou smlouvu, jako je platný JSON, povinná pole, povolené štítky, tvar argumentu nástroje, přítomnost citace, kategorie odmítnutí nebo číselná tolerance. Posuzujte podle modelů pro neomezenou kvalitu pouze po jejich porovnání s malou sadou hodnocenou lidmi. Nepropagujte model pouze z veřejného benchmarku; propagujte jej z důkazů spojených s vašimi vlastními trasováními, nájemci, nástroji, rozpočty a režimy selhání.

Předpovědi: Propagace modelu se přesune z ad hoc rozhodnutí o aplikacích do rovin ovládání brány, protože brány již obsahují katalog modelu, pravidla směrování, trasování použití, zásady tenantů a fakturační údaje potřebné k auditování změn modelu. Týmy, které udržují hodnoty oddělené od směrování, budou stále provádět testy, ale budou se snažit prokázat, které důkazy podporují změnu živého aliasu.

Problém čtenáře: Změny směrování potřebují důkaz

Rozhraní API pro více modelů usnadňuje změnu cílového modelu. To je užitečné, ale také to vytváří problém s ovládáním. Tým může chtít nahradit vysokonákladový model sumarizace podpory levnějším kandidátem, přidat záložní model pro dostupnost, přesunout úlohy kódování na rychlejší model nebo přesměrovat nájemce s nízkou prioritou do nižší úrovně.

Každá změna má jiný rizikový profil. Levnější sumarizátor může vynechat detaily eskalace. Rychlejší klasifikátor může špatně zacházet se vzácnými štítky. Záložní model může používat jiný formát volání nástroje. Novější model uvažování může zlepšit těžké případy a zároveň zvýšit latenci p95. Poznámky k vydání poskytovatele a veřejné žebříčky nedokážou odpovědět, zda jsou tyto kompromisy přijatelné pro konkrétní aplikaci.

Brána je přirozeným místem, kde lze tuto mezeru zacelit, protože vidí požadavky, odpovědi, nájemce, klíče, aliasy, náklady, latenci, chybovost, volání nástrojů a politická rozhodnutí. Hodnocení řízená bránou přeměňují tento provozní kontext na opakovatelný pracovní postup propagace.

Referenční architektura

Praktická architektura má sedm částí:

1. Trace maska: vybírá položky hodnocení kandidátů z produkčního provozu, neúspěšné požadavky, drahé požadavky, vzorky schválené tenantem a známé případy kontroly souhlasu a mezních případů. citlivá pole, vynucuje protokolování a uchovávání tenantů a blokuje vzorky, které nelze použít pro evals.
2. Registr datové sady Eval: ukládá neměnné verze datové sady s typem úlohy, rozsahem tenanta, verzí šablony výzvy, verzí schématu nástroje, očekávanými výstupy, jsou-li k dispozici, a provenience.
3. Candidate model runner více modelů dat: s použitím jednoho aktuálního kandidáta nebo položky opakovaného přehrávání. parametry.
4. Srovnávače: aplikují deterministické kontroly, metriky založené na výpočtech a kalibrovaný úsudek na základě modelu.
5. Záznam rozhodnutí o povýšení: zachycuje ID hodnocení, verzi datové sady, ID základního modelu, ID modelu kandidáta, verze srovnávače, prahové hodnoty, výsledky, vlastníka, schválení, a návrat k cíli
aktualizuje živou bránu pouze poté, co rozhodnutí o povýšení projde požadovanými branami.

Tímto způsobem zůstanou evals připojeny k nasazení. Eval run není zpráva, kterou někdo vložil do vlákna chatu.Je to objekt řídicí roviny, který je vyžadován před změnou aliasu, jako je support-fast, coding-default nebo summarize-cheap.

Sestavení tří tříd datové sady

1. Případy zlaté regrese

Zlaté případy jsou vybrané příklady s očekávanými odpověďmi nebo přísnými kritérii úspěchu. Jsou dostatečně malé na to, aby je bylo možné kontrolovat ručně, a dostatečně stabilní, aby se spustily při každé navrhované propagaci.

Používejte je pro úkoly s jasnými smlouvami: klasifikace, extrakce, strukturované souhrny, rozhodnutí o politice, výběr nástrojů, štítky směrování a chování při odmítnutí. Zlatá položka by měla obsahovat vstup, očekávaný výstup nebo rubriku, povolené variace, metadata úkolu a veškerá schémata nástrojů potřebná k reprodukci volání.

Příklad polí:

{
  "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. Pouzdra s hranami odvozenými z výroby

Pouzdra odvozená z výroby zachycují selhání, která syntetické testy obvykle minou. Mezi dobré zdroje patří nákladné požadavky, opakované pokusy, ruční přepisy, uživatelské opravy, výstupy klasifikátorů s nízkou spolehlivostí, selhání schémat, volání s dlouhým kontextem, požadavky blízké limitům latence a pracovní postupy nájemců s neobvyklým použitím nástrojů.

Pravidlo ochrany osobních údajů je jednoduché: produkční trasování je užitečné, pouze pokud je povoleno. Brána by měla vynucovat souhlas nájemce, zásady uchovávání dat, redigování a omezení pobytu předtím, než trasování vstoupí do eval datové sady. Citliví nájemci mohou potřebovat provádění hodnocení v prostředí, syntetické ekvivalenty nebo redigovaná trasování, která odstraňují nezpracované výzvy a identifikátory.

3. Adversarial and Policy Cases

Nepříznivé případy testují chování, které pod tlakem selže: zneužití nástroje, rychlé vložení, nebezpečné odhalení, hranice odmítnutí, skryté konflikty instrukcí, chybně naformátované soubory, neplatné citace a nejednoznačné požadavky uživatelů. Tyto případy nemusí být dramatické. Musí reprezentovat způsoby, jak mohou vaše aplikace způsobit poškození, když se model stane příliš tolerantním, příliš poslušným nebo příliš nedbalým.

Pro agentní pracovní postupy zahrňte úplnou historii zpráv a kontext volání nástrojů, nikoli pouze výzvy k jednomu otočení. Kandidát, který dobře odpoví na jednokolovou otázku, může stále selhat, když musí zkontrolovat výsledky nástroje, zachovat hranice autority a předložit platné argumenty pro následnou akci.

Nejdřív použijte deterministické srovnávače

Začněte s hodnotiteli, kteří nevyžadují úsudek. Jsou levnější, rychlejší, snáze se ladí a je méně pravděpodobné, že se budou odchylovat.

K užitečným deterministickým kontrolám patří:

• JSON analyzuje úspěšně a odpovídá požadovanému schématu.
• Povinná pole jsou přítomna a žádná zakázaná pole se nezobrazují.
• Výstup klasifikace je jedním z povolených štítků.
je přijata tolerance.Numeric> answer. tenant a pracovní postup.
• Argumenty nástroje projdou ověřením schématu a kontrolami zásad.
• Odpověď obsahuje požadované citace nebo identifikátory zdroje.
• Odpověď nezahrnuje známé zakázané fráze, tajemství ani interní značky.
• Kategorie odmítnutí odpovídá očekávanému výsledku brány zásad.

Tyto kontroly by měly být. Pokud kandidát nemůže produkovat platný strukturovaný výstup nebo bezpečná volání nástrojů, dobré skóre otevřeného psaní by ho nemělo zachránit.

Používejte soudce založené na modelu opatrně

Otevřené úkoly stále vyžadují kvalitní posouzení. Souhrny mohou být věrné, ale ne přesné. Odpovědi podpory mohou vyžadovat tón, úplnost a sladění zásad. Pomoc s kódováním může vyžadovat párové srovnání se základní odpovědí.

Pro tuto vrstvu jsou užiteční soudci na základě modelů, ale neměli by být považováni za objektivní pravdu. Než zablokují nebo schválí změny ve výrobě, zkalibrujte je proti malému vzorku hodnocenému lidmi. Kontrolujte, zda soudce souhlasí s lidskými nálepkami dostatečně často pro míru rizika pracovního postupu.U párových porotců sledujte zkreslení pozice, preferenci upovídanosti a nevšimnete si, že obě odpovědi jsou nepřijatelné.

Praktická porota pro shrnutí podpory může bodovat:

• Věrnost: Vyhýbá se shrnutí přidávání faktů, které se v konverzaci nevyskytují?
• Úplnost a další požadovaný zákaznický problém, Zahrnuje podrobnosti o objednávce: krok?
• Akce: Může jej agent použít, aniž by znovu četl celé vlákno?
• Zásady vyhovují: Vyhýbá se slibování vrácení peněz, kreditů nebo eskalace, které nebyly schváleny?

Pro propagaci zkombinujte bodové minimální skóre s párovým porovnáním. Míra výher v páru je užitečná při nahrazení základní linie, ale může skrýt absolutní selhání, pokud jsou obě odpovědi špatné. Než se párová kvalita rozhodne, zda je lepší, ekvivalentní nebo horší než aktuální model, měl by kandidát splnit minimální brány pro úspěšné/nevyhovující.

Definování hodnotící karty propagace

Výsledková karta propagace brány by měla kombinovat kvalitu, latenci, náklady a provozní bezpečnost. Přesné prahové hodnoty závisí na pracovním vytížení, ale před zahájením běhu by měl být přehled výsledků explicitní.

U každého kandidátského modelu sledujte:

• Míra úspěšnosti kvality: procento položek datové sady, které prošly požadovanými deterministickými a rubrikovými branami.
• Párová míra výher: kandidát versus současná výchozí hodnota: měřená reprezentativní kvalita s otevřeným koncem55. nastavení brány.
• Odhadované náklady na úspěšnou úlohu: celkové odhadované náklady dělené přijatými výstupy, nikoli nezpracovanými hovory.
• Platnost strukturovaného výstupu: četnost průchodu schématu a četnost oprav.
• Platnost volání nástroje: povolené použití nástroje, platné argumenty a zásady selhání výběru nebo akce v souladu se zásadami. odmítnutí, nebezpečná dokončení, značky úniku dat nebo porušení zásad tenantů.
• Provozní kompatibilita: chování streamování, zastavovací sekvence, limity tokenů, časové limity a pole odpovědí specifická pro poskytovatele.

Na ceně za úspěšný úkol záleží více než na ceně za token. Levnější model, který ve 12 procentech případů neprojde ověřením schématu, se může po opakovaných pokusech, opravách, ruční kontrole a eskalacích podpory prodražit. Brána má analýzu fakturace a využití potřebnou ke správnému výpočtu.

Příklad: Nahrazení modelu sumarizace podpory

Předpokládejme, že aktuální alias support-fast ukazuje na model s vysokými náklady, který se používá ke shrnutí konverzací se zákazníky do striktního objektu JSON. Tým chce propagovat levnějšího kandidáta.

Pracovní postup propagace by mohl vypadat takto:

1. Vytvořte verzi datové sady support_summary_eval_2026_09_02 s 200 zlatými případy, 300 zredigovanými případy produkčních okrajových případů a 100 případy kontradiktorních zásad>Spustit stejného kandidáta a levnější se šablonou,
2. schéma, maximální výstupní tokeny a dostupnost nástrojů.
3. Použijte deterministická hradla: platnost JSON na 99 procent nebo vyšší, požadované pokrytí faktů na 97 procent nebo vyšší, nula zakázaných slibů vrácení peněz a nula neplatných akcí nástroje.
4. Aplikujte párové posuzování založené na modelu pouze na položky, které projdou deterministicky definovanou kontrolou kvality,
5. Nevyžadujte více než stávajícího kandidáta, abyste ztráceli na základní úrovni. rozpočet latence a snížit odhadované náklady na přijatý souhrn.
6. Zaznamenejte si ID hodnocení, verzi datové sady, verze srovnávače, ID modelu kandidáta, ID základního modelu, prahové hodnoty, schvalovatel a cílový alias pro vrácení zpět.
7. Canary alias pro omezenou skupinu tenantů, monitorujte selhání živého schématu a opravy podpory, poté
Klíčový bod není akceptován. levnější. Přijímá se pouze v případě, že důkazy o hodnocení ukazují, že levnější model zůstává ve smlouvě o úkolu.

Udělejte neměnné záznamy o povýšení

Brána by měla zachovat dostatek podrobností, aby mohla odpovědět na pozdější otázku týkající se incidentu: proč byl tento model povýšen?

Záznam rozhodnutí o povýšení by měl obsahovat:

• ID povýšení a neměnnou verzi, ID sady dat eval dat, ID datové sady eval. provenience.
• ID výchozího modelu a ID modelu kandidáta.
• Výzva verze šablony a sada parametrů.
• Verze schématu nástroje a omezení směrování.
• Názvy, verze, prahové hodnoty a poznámky ke kalibraci srovnávačů.
• Souhrnné výsledky a odkazy na položky, které selžou,Cli>Cli> rozsah.
• Schvalovatel, časové razítko a cíl vrácení.

To je důležité zejména pro aliasy.Pokud aplikační týmy místo ID modelu poskytovatele zavolají support-fast, získají stabilitu, ale brána má nyní povinnost prokázat, že změny aliasů byly řízeny.

Ovládání soukromí a uchování

Produkce-trace zavádí povinnosti ochrany soukromí. Vzorkovač trasování by nikdy neměl obcházet zásady tenanta jen proto, že hodnoty jsou interní. Před uložením nebo exportem položky eval zkontrolujte, zda mohou být zachovány nezpracované výzvy, zda jsou povoleny nástroje eval hostované poskytovatelem, zda data musí zůstat v konkrétní oblasti a zda vzorek obsahuje tajemství, regulovaná data nebo identifikátory zákazníků.

U citlivých úloh použijte jeden ze tří bezpečnějších vzorů:

• Spouštějte evals do hostitelského prostředí nezpracovaného prostředí. produkty.
• Používejte redigované stopy, které zachovávají strukturu a způsob selhání, ale odstraňují citlivá pole.
• Vytvářejte syntetické případy z pozorovaných vzorců selhání bez kopírování obsahu výroby.

Ten kompromis je skutečný. Hodnoty odvozené z výroby zachycují regrese specifické pro pracovní zátěž. Syntetické evaly snižují expozici. Většina týmů potřebuje obojí.

Kontrolní seznam implementace

• Definujte propagaci modelu jako pracovní postup v řídicí rovině, nikoli jako cvičení se zápisníkem.
• Datové sady verzí, výzvy, schémata nástrojů, srovnávače a prahové hodnoty.
• Oddělte zlaté případy, případy odvozené z výroby a případy protivníků.
• Run. soudci.
• Kalibrujte soudce podle vzorků hodnocených lidmi pro pracovní postupy s vysokým dopadem.
• Měřte náklady na přijatý úkol, nejen náklady na token.
• Vyžadujte cíle vrácení před změnami aliasů nebo zásad směrování.
• Uchovejte záznamy o propagaci pro účely auditu a kontroly incidentů.
• Respektování souhlasu, respektování a omezení tendencí na základě respektování. evals.
• Monitorujte živé kanárky, protože evaly snižují riziko, ale neeliminují je.

Závěr

Výběr modelu umělé inteligence by neměl záviset na veřejných srovnávacích testech, poznámkách k vydání ani na ručním srovnání jednoho vývojáře. Ve vícemodelové bráně API ovlivňují změny modelu nájemce, rozpočty, latenci, chování nástrojů, strukturované výstupy a zásady bezpečnosti. Díky tomu jsou hodnocení součástí řízení výroby.

Akční vzor je přímočarý: vzorujte reprezentativní stopy, redigujte je a filtrujte je podle zásad, verzujte datovou sadu hodnocení, spusťte základní linii a kandidáty, ohodnoťte nejprve deterministickými kontrolami, použijte kalibrované soudce pro kvalitu s otevřeným koncem, zkombinujte kvalitu s latencí a výsledkem a před změnou povýšení vyžadujte neměnná pravidla. není pomalejší adopce modelu. Je to modelová adopce s důkazy. Levnější a rychlejší kandidáti se stále mohou přesunout do výroby, ale musí prokázat, že úspory nepocházejí z tiché regrese úkolu.

Související informace

• internal model a rollback>internal model a rollback>Runbooky pro testování ukončení podpory a migraci
• trasování brány a bezpečné rychlé protokolování