KI bāzes modeļa maiņa bez kvalitātes zuduma: Evals, Canary un Rollback

Jauns KI bāzes modelis bieži sola labākas atbildes, zemākas izmaksas vai īsāku reakcijas laiku. Tomēr produktīvam vietnes tērzēšanas botam modeļa maiņa nav vienkārša jebkādas programmatūras pakotnes nomaiņa. Pat jauna modeļa versija var citādi izsvērt norādījumus, formulēt atbildes izvērstāk, atšķirīgi ģenerēt strukturētus datus vai izsaukt rīkus citā secībā. Tāpēc migrācija ir veiksmīga tikai tad, ja tērzēšanas bots pilda savus konkrētos uzdevumus vismaz tikpat uzticami kā iepriekš – un ja komanda problēmu gadījumā dažu minūšu laikā var pārslēgties atpakaļ.

Piegādātāji regulāri paziņo par modeļu dzīvescikla beigām. OpenAI dokumentācija par modeļu lietošanas pārtraukšanu atspoguļo izslēgšanas datumus un ieteiktos aizstājējmodeļus; Anthropic savā modeļa dzīvesciklā izšķir statusus "Active", "Legacy", "Deprecated" un "Retired". Šādi termiņi ir iemesls migrācijai, taču tie nav tās kvalitātes pierādījums. To nodrošina tikai testa un ieviešanas procedūra, kas ir piemērota jūsu tērzēšanas botam.

Kas faktiski tiek mainīts bāzes modeļa maiņas laikā

Šis process ir skaidri jānošķir no iegulšanas (embedding) modeļa migrācijas. Mainot iegulšanas modeli, dokumenti ir jāvektorizē no jauna un meklēšanas indeksi jāsaglabā savietojami. Bāzes modeļa maiņas gadījumā meklēšanas indekss parasti paliek nemainīgs; tiek mainīts modelis, kas ģenerē atbildi no sistēmas norādēm, sarunas, atrastajiem avotiem un rīku rezultātiem. Tāpēc tiek testēta atbilžu uzvedība, saistība ar avotiem, formāts, rīku izmantošana, drošība, latentums un izmaksas.

Arī vispārīgs Shadow Mode tests pirms vietnes palaišanas atrisina tikai daļu no uzdevuma. Shadow satiksme var padot vienus un tos pašus ievaddatus diviem modeļiem, nesūtot jauno atbildi lietotājam. Šeit aprakstītā bāzes modeļa maiņa iet tālāk: tā iepriekš definē pieņemšanas matriču, novirza nelielu daļu reālās satiksmes uz kandidātu, pārrauga lietotāju un sistēmas signālus un uztur pārbaudītu atpakaļpārslēgšanas iespēju.

Pirms testa: noteikt skaidru migrācijas līgumu

Salīdzinājumi ir bezvērtīgi, ja to laikā mainās vairākas lietas. Tāpēc pirmajai kārtai saglabājiet sistēmas uzvedni, meklēšanas konfigurāciju, rīku shēmas, temperatūru, maksimālo izvades garumu un drošības noteikumus pēc iespējas nemainīgus un dokumentējiet neizbēgamās parametru izmaiņas, piemēram, neatbalstītās paraugu ņemšanas opcijas. Dokumentējiet līdzšinējo modeli kā bāzi un jauno modeli kā kandidātu. Ja iespējams, izmantojiet eksplicītas modeļu versijas, nevis mainīgu aizstājējvārdu (alias). Aizstājējvārds vēlāk var norādīt uz citu momentuzņēmumu un izmainīt domājams reproducējamo salīdzinājumu.

Migrācijas līgums ietver arī lietotāju grupas un funkcijas, kas sākotnēji tiek izslēgtas. Piemēram, BUJ tērzēšanas bots var agri pāriet uz Canary satiksmi, savukārt rakstīšanas piekļuve pasūtījumiem, līgumu informācija vai īpaši jutīgi atbalsta gadījumi ilgāk paliek uz bāzes modeļa. Tādējādi risks tiek ierobežots pēc ietekmes uz biznesu, nevis tikai pēc tehniskās sarežģītības.

Testa kopai jāatspoguļo reālā satiksme

Zelta kopai (Golden Set) vajadzētu saturēt ne tikai tīrus standarta jautājumus. Apkopojiet anonimizētus vai sintētiski atdarinātus gadījumus no svarīgākajiem nolūkiem (intents): nepārprotami jautājumi, divdomīgi formulējumi, papildjautājumi, trūkstoši dokumenti, pretrunīgi avoti, rīku kļūdas un ievaddati, kas jānodod cilvēkam. Sadaliet gadījumus pēc valodas, ierīces, klienta tipa un riska klases. Tādējādi paliek redzams, vai labs kopējais vērtējums nenosedz mazas, bet biznesam kritiskas apakšgrupas.

Oficiālā Anthropic pamācība par veiksmes kritērijiem un Evals iesaka specifiskus, mērāmus un lietojuma mērķim atbilstošus kritērijus, kā arī reālistiskus robežgadījumus. Arī OpenAI pamācība par Evals apraksta testus kā būtisku uzticamu lietotņu sastāvdaļu, īpaši atjauninot vai izmēģinot jaunus modeļus. Tā kā OpenAI tajā pašā lapā paziņo par līdzšinējās Evals platformas izmantošanas izbeigšanu, sava Zelta kopa jāsaglabā pārnesamā formātā un nav jāpiesaista vienam panelim.

Novērtēšanas matrica viena vidējā rādītāja vietā

Turpmākās robežvērtības ir piemērs, nevis universāls noteikums. Noteiciet tās, balstoties uz līdzšinējo ražošanas veiktspēju un kļūdas radītajiem zaudējumiem. Kandidāts nedrīkst panākt zemāku žetonu (token) cenu uz sliktākas avotu sasaistes rēķina.

Automātiskās pārbaudes ir piemērotas JSON shēmām, obligātajiem formulējumiem, saišu mērķiem, rīku argumentiem un deterministiskiem biznesa noteikumiem. Toņa, pilnīguma un noderīgu paskaidrojumu izvērtēšanai papildus ir nepieciešama skaidra rubrika; speciālistu veiktas izlases pārbaudes kalibrē uz LLM balstītu vērtētāju. Rezultāti jāsaglabā katram nolūkam un riska klasei, nevis tikai kā viens rādītājs. Kā šāda kopa tiek pamatā izveidota, parāda arī mūsu ceļvedis par atbilžu kvalitāti ar Zelta kopu.

Konkrēts piemērs: modeļa maiņa B2B atbalstā

Pieņemsim, ka B2B programmatūras nodrošinātājs uztur tērzēšanas botu jautājumiem par produktiem, kontu pārvaldību un atbalsta pieteikumu sagatavošanu. Komanda izveido 240 testa gadījumus: 120 bieži uzdotus zināšanu jautājumus, 40 divdomīgus papildjautājumus, 30 gadījumus ar trūkstošu avotu, 25 rīku simulācijas un 25 drošības vai nodošanas gadījumus. Abi modeļi saņem precīzi tās pašas uzvednes, dokumentu atbilstības un simulētos rīku rezultātus.

Kandidāts atbild uz standarta jautājumiem ātrāk un lētāk, taču piecos papildjautājumos zaudē saikni ar iepriekšējo ziņojumu. Kopējais vērtējums tomēr būtu labāks. Segmentu analīze rāda skaidru kvalitātes zudumu. Komanda nepievieno patvaļīgu izņēmumu, bet gan precizē sarunas noteikumu, paplašina testa kopu ar līdzīgiem gadījumiem un no jauna testē abus modeļus. Tikai pēc tam, kad kandidāts izpilda visus stingros vārtus, sākas produktīvā Canary satiksme.

Sākumā divi procenti no piemērotajām jaunajām sarunām tiek novirzīti kandidātam. Piešķiršana sarunas sākumā tiek atvasināta, piemēram, no Conversation ID jaucējkoda (hash) un saglabāta visai sarunai; augstāki Canary līmeņi attiecas tikai uz jaunām sarunām. Rakstošie rīku izsaukumi un augsta riska nolūki sākotnēji paliek uz bāzes modeļa. Pēc pietiekami liela novērošanas loga seko desmit, 25, 50 un visbeidzot 100 procenti – bet tikai tad, ja visi vārti joprojām ir zaļi. Pakāpes un minimālās izlases tiek noteiktas iepriekš, lai laika trūkums vēlāk nemazinātu noteikumu stingrību.

Tiešsaistes signāli, kuriem tiešām ir nozīme

Canary satiksmē ar HTTP kļūdām un vidējo latentumu nepietiek. Pārraugiet bezatbildes rādītāju, pārtraukšanu pēc pirmās atbildes, atkārtotus jautājumus, nodošanas rādītāju, klikšķus uz avotiem, shēmu kļūdas un rīku pārtraukumus atsevišķi bāzei un kandidātam. Kopīgs izsekošanas ieraksts (trace) savieno modeļa versiju, uzvednes versiju, meklēšanas atbilstības un rīku soļus, nesaglabājot nevajadzīgu personīgo saturu. Mūsu raksts par tērzēšanas bota novērojamību detalizēti izskaidro šo pārbaudes pēdu.

Tāpat salīdziniet izmaksas par veiksmīgi atrisinātu gadījumu, nevis tikai izmaksas par miljonu žetonu. Lētāks modelis, kas biežāk rada papildu jautājumus vai prasa cilvēka iesaisti, operacionāli var būt dārgāks. Un otrādi, neliels latentuma pieaugums var būt pieņemams, ja tas svarīgā riska klasē pierādāmi nodrošina precīzākas atbildes.

Atpakaļvērse (rollback) ir funkcija, nevis dokuments

Atpakaļceļam jābūt tehniski pārbaudītam pirms pirmā Canary posma. Modeļa ID un saistītie parametri pieder versijotai konfigurācijai vai kontrolētai funkciju karodziņu (feature flag) sistēmai. Kamēr piegādātājs joprojām atbalsta līdzšinējo versiju, tā Canary laikā paliek pieejama kā rezerves mērķis; pirms tās atslēgšanas datuma papildus ir nepieciešama atbalstīta rezerves opcija. Esošajām sarunām vai nu konsekventi jāpaliek pie sākotnējā modeļa, vai arī jāpāriet saskaņā ar skaidri pārbaudītu noteikumu.

Definējiet stingrus izraisītājus: piemēram, shēmas kļūda rakstīšanas darbības laikā, ar drošību saistīta nolūka pasliktināšanās, ievērojams kļūdu līmeņa lēciens vai latentuma budžeta pārsniegšana. Saņemot šādu signālu, pārslēgšanās atpakaļ notiek automātiski vai caur skaidri nozīmētu dežūrpersonālu. Pēc tam žurnāli, kandidāta versija un ietekmētā izlase tiek saglabāta, lai varētu izanalizēt cēloni. Sagatavots process ir krietni uzticamāks par spontānu koda izvietošanu; papildus palīdz pilnīga incidentu reaģēšanas rokasgrāmata (playbook).

Pārbaudes lapa apstiprināšanai

• Atslēgšanas datuma, aizstājējmodeļa un ietekmēto galapunktu fiksēšana no oficiālās piegādātāja dokumentācijas.
• Bāzes un kandidāta nofiksēšana ar nemainīgu uzvednes, meklēšanas un rīku konfigurāciju.
• Zelta kopas sadalīšana pēc nolūka, valodas un riska klases; robežgadījumu un reālu kļūdu piemēru pievienošana.
• Stingru vārtu definēšana avotu sasaistei, strukturētai izvadei, rīkiem, drošībai un nodošanai.
• Latentuma, kļūdu līmeņa, žetonu un izmaksu par atrisināto gadījumu mērīšana.
• Canary piešķiršanas stabilitātes uzturēšana visām sarunām un jutīgu funkciju sākotnēja izslēgšana.
• Posmu, minimālās izlases, novērošanas ilguma un atcelšanas robežu dokumentēšana pirms ieviešanas.
• Atpakaļvērses tehniskā pārbaude, atbildīgo iecelšana un piegādātāja atbalstīta rezerves mērķa uzturēšana.
• Pēc 100% sasniegšanas turpināt novērošanu un paplašināt Zelta kopu ar jauniem ražošanas gadījumiem.

Secinājums: Modeļa nosaukums ir tikai sākums

Kontrolēta bāzes modeļa maiņa apvieno produkta kvalitāti un darbības drošību. Oficiālās dzīvescikla norādes nodrošina termiņu, Evals sniedz pierādījumus par piemērotību, Canary satiksme ierobežo nezināmu kļūdu ietekmi, un pārbaudīta atpakaļvērse saīsina reakcijas laiku. Tie, kas šos četrus blokus ievieš kā atkārtojamu procesu, var izmantot jaunus modeļus, nepadarot savas vietnes tērzēšanas botu par eksperimentu visiem lietotājiem.

Vai vēlaties strukturēti plānot savas vietnes tērzēšanas bota modeļa versiju, kvalitātes vārtus un ieviešanu? ChatReact palīdz jums izveidot zināšanu bāzi, atbilžu uzvedību un nodošanas procesus tā, lai izmaiņas paliktu mērāmas un kontrolējamas.