Zmena základného modelu AI bez poklesu kvality: Evals, Canary a Rollback

Nový základný model AI často sľubuje lepšie odpovede, nižšie náklady alebo rýchlejšie reakcie. Pre produkčného webového chatbota však jeho zmena nie je len bežnou výmenou softvérového balíka. Už nová verzia modelu môže inak vážiť pokyny, formulovať odpovede podrobnejšie, generovať štruktúrované dáta odlišne alebo volať nástroje v inom poradí. Migrácia je preto úspešná až vtedy, keď chatbot plní svoje konkrétne úlohy minimálne tak spoľahlivo ako predtým – a keď tím dokáže v prípade problémov prepnúť späť do niekoľkých minút.

Poskytovatelia pravidelne oznamujú ukončenie podpory modelov. Dokumentácia OpenAI k ukončeniu podpory uvádza termíny vypnutia a odporúčané náhradné modely; Anthropic vo svojom životnom cykle modelov rozlišuje stavy „Active“, „Legacy“, „Deprecated“ a „Retired“. Tieto termíny sú dôvodom na migráciu, no nie dôkazom jej kvality. Ten poskytne iba testovací a zavádzací postup prispôsobený vášmu vlastnému chatbotovi.

Čo sa vlastne mení pri zmene základného modelu

Tento proces treba jasne odlíšiť od migrácie embeddingového modelu. Pri výmene embeddingu sa musia dokumenty znova vektorizovať a vyhľadávacie indexy udržiavať kompatibilné. Pri zmene základného modelu vyhľadávací index zvyčajne zostáva nezmenený; mení sa model, ktorý generuje odpoveď zo systémových pokynov, konverzácie, nájdených zdrojov a výsledkov nástrojov. Testuje sa preto správanie pri odpovedaní, väzba na zdroje, formát, používanie nástrojov, bezpečnosť, latencia a náklady.

Ani všeobecný test v režime Shadow Mode pred spustením na webe nerieši celú úlohu. Shadow prevádzka dokáže napájať dva modely rovnakými vstupmi bez toho, aby odosielala novú odpoveď. Tu popísaná zmena základného modelu ide ďalej: vopred definuje akceptačnú maticu, smeruje malú časť reálnej prevádzky na nového kandidáta, monitoruje používateľské a systémové signály a drží pripravené otestované spätné prepnutie.

Pred testom: stanovenie jednoznačnej migračnej dohody

Porovnania nemajú hodnotu, ak sa počas nich mení viacero vecí naraz. Pre prvé kolo preto udržujte systémový prompt, konfiguráciu vyhľadávania, schémy nástrojov, teplotu, maximálnu dĺžku výstupu a bezpečnostné pravidlá v čo najväčšej miere konštantné a zdokumentujte nevyhnutné zmeny parametrov, napríklad nepodporované možnosti vzorkovania. Zdokumentujte doterajší model ako základ (base) a nový model ako kandidáta. Ak je to možné, používajte explicitné verzie modelov namiesto premenlivého aliasu. Alias môže neskôr ukazovať na iný snapshot a zmeniť tak zdanlivo reprodukovateľné porovnanie.

Migračná dohoda obsahuje aj skupiny používateľov a funkcie, ktoré zatiaľ zostávajú vylúčené. FAQ chatbot môže ísť napríklad do canary prevádzky skôr, zatiaľ čo zápisové operácie pri objednávkach, informácie o zmluvách alebo obzvlášť citlivé prípady podpory zostávajú dlhšie na pôvodnom základe. Riziko sa tak obmedzuje podľa dopadu na podnikanie, nie iba podľa technickej komplexnosti.

Testovacia sada musí odzrkadľovať reálnu prevádzku

Golden Set by nemal obsahovať iba čisté štandardné otázky. Zozbierajte anonymizované alebo synteticky vytvorené prípady z najdôležitejších zámerov (intents): jednoznačné otázky, nejednoznačné formulácie, doplňujúce otázky, chýbajúce dokumenty, rozporuplné zdroje, chyby nástrojov a vstupy, ktoré musia byť odovzdané človeku. Rozdeľte prípady podľa jazyka, zariadenia, typu zákazníka a rizikovej triedy. Vďaka tomu bude viditeľné, či dobré celkové hodnotenie neskrýva malé, ale pre podnikanie kritické podskupiny.

Oficiálny návod od Anthropic k kritériám úspechu a Evals odporúča špecifické, merateľné kritériá viazané na účel použitia, ako aj reálne hraničné prípady. Aj návod od OpenAI k Evals popisuje testy predovšetkým pri aktualizácii alebo skúšaní nových modelov ako kľúčovú súčasť spoľahlivých aplikácií. Keďže OpenAI na rovnakej stránke oznamuje ukončenie doterajšej platformy Evals, vlastný Golden Set by mal byť uložený v prenosnom formáte a neviazaný na jediný dashboard.

Hodnotiaca matica namiesto jednej priemernej hodnoty

Nasledujúce hraničné hodnoty sú len príkladom, nie univerzálnym predpisom. Stanovte ich na základe doterajšieho produkčného výkonu a škody spôsobenej chybou. Kandidát si nesmie vykúpiť výhodnejšiu cenu tokenov horšou väzbou na zdroje.

Automatické kontroly sú vhodné pre JSON schémy, povinné formulácie, cieľové odkazy, argumenty nástrojov a deterministické biznis pravidlá. Pre tón, úplnosť a užitočné vysvetlenia je navyše potrebná jasná rubrika; namátkové kontroly odborníkmi kalibrujú hodnotiteľa založeného na LLM. Výsledky by sa mali ukladať pre každý zámer a rizikovú triedu osobitne, nie len ako jedno skóre. Ako v princípe zostaviť takúto sadu, ukazuje aj náš sprievodca pre kvalitu odpovedí s Golden Setom.

Konkrétny príklad: Zmena modelu v B2B podpore

Predpokladajme, že poskytovateľ B2B softvéru prevádzkuje chatbota pre produktové otázky, správu účtu a prípravu tiketov podpory. Tím vytvorí 240 testovacích prípadov: 120 častých vedomostných otázok, 40 nejednoznačných doplňujúcich otázok, 30 prípadov s chýbajúcim zdrojom, 25 simulácií nástrojov a 25 bezpečnostných prípadov alebo odovzdaní človeku. Oba modely dostanú presne rovnaké prompty, výsledky vyhľadávania a simulované výstupy nástrojov.

Kandidát odpovedá na štandardné otázky rýchlejšie a lacnejšie, ale pri piatich doplňujúcich otázkach stratí kontext predchádzajúcej správy. Celková známka by bola napriek tomu lepšia. Segmentová analýza však ukáže jasný pokles kvality. Tím nepridáva žiadnu svojvoľnú výnimku, ale spresní konverzačné pravidlo, rozšíri testovaciu sadu o podobné prípady a znova otestuje oba modely. Až keď kandidát splní všetky pevné brány, začína sa produkčná canary prevádzka.

Na začiatok sa kandidátovi priradia dve percentá vhodných nových konverzácií. Priradenie sa pri štarte konverzácie odvodí napríklad z hashu ID konverzácie a ukladá sa počas celej jej dĺžky; vyššie stupne canary sa vzťahujú len na nové konverzácie. Zápisové volania nástrojov a vysokorizikové zámery zostávajú zatiaľ na základnom modeli. Po dostatočne dlhom sledovacom okne nasleduje 10, 25, 50 a nakoniec 100 percent – ale iba vtedy, ak je každá brána stále zelená. Stupne a minimálne veľkosti vzoriek sa definujú vopred, aby časový tlak dodatočne nezmiernil pravidlá.

Online signály, na ktorých skutočne záleží

V canary prevádzke nestačia HTTP chyby a priemerná latencia. Sledujte mieru neodpovedania (No-Answer rate), predčasné ukončenie po prvej odpovedi, opakované otázky, mieru odovzdania človeku, kliknutia na zdroje, chyby schémy a zlyhania nástrojov oddelene pre základ aj kandidáta. Spoločná stopa (trace) prepája verziu modelu, verziu promptu, výsledky vyhľadávania a kroky nástrojov bez ukladania nepotrebných osobných údajov. Náš článok o observabilite chatbotov vysvetľuje túto kontrolnú stopu podrobnejšie.

Porovnávajte tiež náklady na úspešne vyriešený prípad namiesto samotných nákladov na milión tokenov. Lacnejší model, ktorý častejšie vyžaduje doplňujúce otázky alebo ľudský zásah, môže byť v prevádzke drahší. Naopak, mierne zvýšenie latencie môže byť prijateľné, ak preukázateľne prináša presnejšie odpovede vo dôležitej rizikovej kategórii.

Rollback je funkcia, nie dokument

Spätná cesta musí byť technicky otestovaná ešte pred prvou fázou canary prevádzky. ID modelu a príslušné parametre patria do verziovanej konfigurácie alebo pod kontrolovaný feature flag. Kým poskytovateľ stále podporuje doterajšiu verziu, zostáva počas canary dostupná ako cieľ pre návrat; pred jej vypnutím je navyše potrebný podporovaný fallback. Existujúce konverzácie by mali buď konzistentne zostať na svojom pôvodnom modeli, alebo sa prepnúť podľa výslovne otestovaného pravidla.

Definujte pevné spúšťače rollbacku: napríklad chybu schémy pri zápisovej akcii, zhoršenie pri bezpečnostne kritickom zámere, výrazný nárast chybovosti alebo prekročenie rozpočtu latencie. Pri takomto signáli sa prepnutie späť vykoná automaticky alebo prostredníctvom jasne určenej pohotovostnej služby. Logy, verzia kandidáta a dotknutá vzorka sa potom zachovajú, aby sa dala analyzovať príčina. Pripravený postup je oveľa spoľahlivejší než spontánne nasadenie kódu; ako doplňujúci nástroj pomôže kompletný playbook reakcie na incidenty.

Kontrolný zoznam pre schválenie

• Zistiť termín ukončenia podpory, náhradný model a dotknuté koncové body z oficiálnej dokumentácie poskytovateľa.
• Pevne stanoviť základ a kandidáta s nezmenenou konfiguráciou promptov, vyhľadávania a nástrojov.
• Rozdeliť Golden Set podľa zámeru, jazyka a rizikovej triedy; doplniť hraničné prípady a reálne chybové scenáre.
• Definovať pevné brány pre väzbu na zdroje, štruktúrované výstupy, nástroje, bezpečnosť a odovzdanie človeku.
• Merať latenciu, chybovosť, tokeny a náklady na vyriešený prípad.
• Udržať priradenie do canary prevádzky stabilné pre celé konverzácie a citlivé funkcie nateraz vylúčiť.
• Zdokumentovať fázy, minimálnu veľkosť vzorky, dĺžku pozorovania a limity pre zrušenie pred nasadením.
• Technicky otestovať rollback, určiť zodpovedné osoby a udržať dostupný záložný cieľ podporovaný poskytovateľom.
• Po dosiahnutí 100 percent pokračovať v sledovaní a rozširovať Golden Set o nové reálne prípady z produkcie.

Záver: Názov modelu je len začiatok

Kontrolovaná zmena základného modelu spája kvalitu produktu a prevádzkovú bezpečnosť. Oficiálne informácie o životnom cykle určujú termíny, Evals poskytujú dôkazy o vhodnosti, canary prevádzka obmedzuje dopad neznámych chýb a otestovaný rollback skracuje čas reakcie. Ak tieto štyri stavebné kamene zavediete ako opakovateľný proces, môžete využívať nové modely bez toho, aby sa váš webový chatbot stal experimentom pre všetkých používateľov.

Chcete štruktúrovane naplánovať verziu modelu, kritériá kvality a nasadenie vášho webového chatbota? ChatReact vám pomôže nastaviť znalostnú bázu, správanie pri odpovedaní a odovzdávanie tak, aby zmeny zostali merateľné a pod kontrolou.