Změna základního AI modelu bez ztráty kvality: Evals, Canary a Rollback

Nový základní AI model často slibuje lepší odpovědi, nižší náklady nebo rychlejší reakční dobu. Pro produkční webový chatbot však jeho výměna nepředstavuje pouhou záměnu jakéhokoli softwarového balíčku. I nová verze modelu může jinak vážit instrukce, formulovat odpovědi podrobněji, odlišně generovat strukturovaná data nebo volat nástroje v jiném pořadí. Migrace je proto úspěšná až tehdy, když chatbot plní své konkrétní úkoly minimálně stejně spolehlivě jako předtím – a když tým může v případě problémů během několika minut přepnout zpět.

Poskytovatelé pravidelně oznamují ukončení podpory modelů. Dokumentace OpenAI k ukončení podpory uvádí data vypnutí a doporučené náhradní modely; Anthropic ve svém životním cyklu modelů rozlišuje stavy „Active“, „Legacy“, „Deprecated“ a „Retired“. Takové lhůty jsou důvodem k migraci, nikoli však důkazem její kvality. Ten poskytne pouze testovací a nasazovací postup, který odpovídá vašemu vlastnímu chatbotu.

Co se při změně základního modelu skutečně mění

Tento proces je třeba jasně odlišit od migrace embeddingového modelu. Při změně embeddingu je nutné dokumenty znovu převektorovat a udržet vyhledávací indexy kompatibilní. Při změně základního modelu vyhledávací index obvykle zůstává; mění se model, který ze systémové instrukce, konverzace, nalezených zdrojů a výsledků nástrojů generuje odpověď. Testuje se proto chování při odpovídání, vazba na zdroje, formát, použití nástrojů, bezpečnost, latence a náklady.

Také obecný test v režimu stínového provozu (Shadow Mode) před spuštěním webu řeší pouze část úkolu. Stínový provoz může dodávat stejné vstupy dvěma modelům bez doručení nové odpovědi uživateli. Zde popsaná změna základního modelu jde dále: předem definuje akceptační matici, směruje malý podíl reálného provozu na kandidáta, sleduje uživatelské i systémové signály a drží připravené otestované zpětné přepnutí.

Před testem: stanovení jednoznačné migrační dohody

Srovnání nemají smysl, pokud se během nich mění více věcí najednou. Pro první kolo proto udržujte systémový prompt, konfiguraci vyhledávání, schémata nástrojů, teplotu, maximální délku výstupu a bezpečnostní pravidla pokud možno konstantní a dokumentujte nevyhnutelné změny parametrů (např. nepodporované možnosti vzorkování). Dokumentujte dosavadní model jako základ a nový model jako kandidáta. Pokud je to možné, používejte explicitní verze modelů namísto proměnlivého aliasu. Alias se může později odkazovat na jiný snímek (snapshot) a změnit tak zdánlivě reprodukovatelné srovnání.

Migrační dohoda dále obsahuje uživatelské skupiny a funkce, které zůstávají zpočátku vyloučeny. FAQ chatbot může jít do Canary provozu brzy, zatímco zápisové přístupy k objednávkám, informace o smlouvách nebo zvláště citlivé případy podpory zůstávají déle na základním modelu. Riziko je tak omezeno podle dopadu na podnikání, nikoli pouze podle technické složitosti.

Testovací sada musí odrážet reálný provoz

Zlatá sada (Golden Set) by neměla obsahovat pouze čisté standardní dotazy. Shromážděte anonymizované nebo synteticky vytvořené případy z nejdůležitějších uživatelských záměrů (intents): jednoznačné dotazy, mnohoznačné formulace, navazující dotazy, chybějící dokumenty, rozporuplné zdroje, chyby nástrojů a vstupy, které musí být předány člověku. Rozdělte případy podle jazyka, zařízení, typu zákazníka a rizikové třídy. Tím bude vidět, zda dobré celkové skóre neskrývá malé, ale pro podnikání kritické podskupiny.

Oficiální návod společnosti Anthropic ke kritériím úspěchu a Evals doporučuje specifická, měřitelná kritéria zaměřená na účel použití a reálné hraniční případy. Také návod OpenAI k Evals popisuje testy jako zásadní součást spolehlivých aplikací, zejména při upgradu nebo zkoušení nových modelů. Vzhledem k tomu, že OpenAI na stejné stránce oznamuje ukončení dosavadní platformy Evals, měla by být vaše vlastní Zlatá sada uložena v přenosném formátu a nebýt vázána na jediný řídicí panel.

Hodnoticí matice namísto jediné průměrné hodnoty

Následující mezní hodnoty jsou příkladem, nikoli univerzálním předpisem. Stanovte je na základě dosavadního produkčního výkonu a škody způsobené chybou. Kandidát nesmí vykupovat výhodnější cenu tokenu horší vazbou na zdroje.

Automatizované kontroly jsou vhodné pro schémata JSON, povinné formulace, cíle odkazů, argumenty nástrojů a deterministická obchodní pravidla. Pro tón, úplnost a užitečná vysvětlení je navíc potřeba jasná rubrika; namátkové kontroly odborníků kalibrují hodnotitel založený na LLM. Výsledky by měly být ukládány pro každý Intent a rizikovou třídu zvlášť, nikoli pouze jako jedno celkové skóre. Jak takovou sadu v základu sestavit, ukazuje také náš průvodce pro kvalitu odpovědí se Zlatou sadou.

Konkrétní příklad: Změna modelu v B2B podpoře

Předpokládejme, že poskytovatel B2B softwaru provozuje chatbota pro dotazy k produktu, správu účtu a přípravu tiketů podpory. Tým vytvoří 240 testovacích případů: 120 běžných znalostních dotazů, 40 mnohoznačných navazujících dotazů, 30 případů s chybějícím zdrojem, 25 simulací nástrojů a 25 bezpečnostních případů nebo případů předání. Oběma modelům jsou předány přesně stejné prompty, nalezené dokumenty a simulované výsledky nástrojů.

Kandidát odpovídá na standardní dotazy rychleji a levněji, ale u pěti navazujících dotazů ztrácí vazbu na předchozí zprávu. Celková známka by přesto byla lepší. Segmentová analýza však ukazuje jasný pokles kvality. Tým nepřidává žádnou svévolnou výjimku, ale zpřesňuje konverzační pravidlo, rozšiřuje testovací sadu o podobné případy a znovu testuje oba modely. Teprve až kandidát splní všechny tvrdé brány, začíná produkční Canary provoz.

Pro začátek jsou dvě procenta vhodných nových konverzací přiřazena kandidátovi. Přidělení se při zahájení konverzace odvodí například z hashe Conversation ID a uloží se pro celou konverzaci; vyšší Canary stupně platí pouze pro nové konverzace. Zápisová volání nástrojů a vysoce rizikové Intents zůstávají zpočátku na základu. Po dostatečně dlouhém pozorovacím období následuje 10, 25, 50 a nakonec 100 procent – ale pouze v případě, že každá brána zůstává zelená. Stupně a minimální velikosti vzorků se stanovují předem, aby časový tlak dodatečně nerozvolnil pravidla.

Online signály, na kterých skutečně záleží

V Canary provozu nestačí sledovat HTTP chyby a průměrnou latenci. Sledujte míru neodpovězení, opuštění po první odpovědi, opakované dotazy, míru předání člověku, kliknutí na zdroje, chyby schématu a selhání nástrojů odděleně pro základ a kandidáta. Společná stopa (trace) propojuje verzi modelu, verzi promptu, nalezené zdroje a kroky nástrojů, aniž by ukládala zbytečné osobní údaje. Náš článek o observabilitě chatbotů vysvětluje tuto kontrolní stopu do detailu.

Srovnávejte také náklady na úspěšně vyřešený případ namísto pouhých nákladů na milion tokenů. Levnější model, který často vyžaduje doplňující dotazy nebo lidskou práci, může být provozně dražší. Naopak mírné zvýšení latence může být akceptovatelné, pokud v důležité rizikové třídě prokazatelně přináší přesnější odpovědi.

Rollback je funkce, nikoli dokument

Zpětná cesta musí být technicky otestována před prvním stupněm Canary provozu. ID modelu a příslušné parametry patří do verzované konfigurace nebo řízeného příznaku funkce (Feature Flag). Dokud poskytovatel stále podporuje předchozí verzi, zůstává během Canary provozu k dispozici jako záložní cíl; před datem jejího ukončení je navíc potřeba podporovaný záložní cíl. Stávající konverzace by měly buď konzistentně zůstat na původním modelu, nebo přejít podle výslovně otestovaného pravidla.

Definujte tvrdé spouštěče: například chybu schématu u zápisové akce, zhoršení bezpečnostně relevantního Intentu, výrazný skok v chybovosti nebo překročení rozpočtu latence. Při takovém signálu se systém přepne zpět automaticky nebo prostřednictvím jasně určené pohotovostní služby. Poté zůstávají protokoly, verze kandidáta i dotčený vzorek zachovány, aby bylo možné analyzovat příčinu. Připravený postup je výrazně spolehlivější než spontánní nasazení kódu; jako doplněk pomáhá kompletní playbook pro reakci na incidenty.

Kontrolní seznam pro schválení

• Zaznamenat datum ukončení podpory, náhradní model a dotčené koncové body z oficiální dokumentace poskytovatele.
• Zafixovat základ a kandidáta s nezměněnou konfigurací promptů, vyhledávání a nástrojů.
• Rozdělit Zlatou sadu podle Intentu, jazyka a rizikové třídy; doplnit hraniční případy a reálné chybové scénáře.
• Definovat tvrdé brány pro vazbu na zdroje, strukturované výstupy, nástroje, bezpečnost a předání člověku.
• Měřit latenci, chybovost, tokeny a náklady na vyřešený případ.
• Udržovat přiřazení Canary provozu stabilní pro celé konverzace a citlivé funkce zpočátku vyloučit.
• Před nasazením zdokumentovat stupně, minimální vzorek, dobu pozorování a limity pro přerušení.
• Technicky otestovat návrat (Rollback), určit odpovědné osoby a udržovat k dispozici záložní cíl podporovaný poskytovatelem.
• Po dosažení 100 % dále sledovat a rozšiřovat Zlatou sadu o nově objevené produkční případy.

Závěr: Název modelu je pouze začátek

Řízená změna základního modelu spojuje kvalitu produktu a provozní bezpečnost. Oficiální informace o životním cyklu poskytují lhůtu, Evals přinášejí důkazy o vhodnosti, Canary provoz omezuje dopad neznámých chyb a otestovaný návrat zkracuje reakční dobu. Kdo zavede tyto čtyři stavební kameny jako opakovatelný proces, může využívat nové modely, aniž by ze svého webového chatbota udělal experiment pro všechny uživatele.

Chcete strukturovaně naplánovat verzi modelu, brány kvality a nasazení vašeho webového chatbota? ChatReact vám pomůže nastavit znalostní bázi, chování při odpovídání a předávání tak, aby změny zůstaly měřitelné a pod kontrolou.