Zamenjava osnovnega modela AI brez padca kakovosti: Evals, Canary in Rollback

Nov osnovni model AI pogosto obljublja boljše odgovore, nižje stroške ali hitrejše odzivne čase. Za produkcijski spletni klepetalnik pa zamenjava vseeno ni le zamenjava poljubnega programskega paketa. Že nova različica modela lahko drugače vrednoti navodila, podrobneje formulira odgovore, drugače ustvarja strukturirane podatke ali kliče orodja v drugem vrstnem redu. Migracija je zato uspešna šele takrat, ko klepetalnik svoje konkretne naloge opravlja vsaj tako zanesljivo kot prej – in ko lahko ekipa ob težavah v nekaj minutah preklopi nazaj.

Ponudniki redno napovedujejo umik modelov. OpenAI dokumentacija o umiku modelov navaja datume izklopa in priporočene nadomestne modele; Anthropic v svojem življenjskem ciklu modela razlikuje med statusi »Active«, »Legacy«, »Deprecated« in »Retired«. Takšni roki so povod za migracijo, ne pa tudi dokaz njene kakovosti. Tega zagotavlja le postopek testiranja in uvajanja, ki ustreza vašemu klepetalniku.

Kaj se dejansko spremeni pri zamenjavi osnovnega modela

Ta proces je treba jasno ločiti od migracije modela za vgradnjo (embedding). Pri zamenjavi vgradnje je treba dokumente znova vektorizirati in vzdrževati združljivost iskalnih indeksov. Pri zamenjavi osnovnega modela iskalni indeks običajno ostane nespremenjen; spremeni se model, ki iz sistemskih navodil, pogovora, najdenih virov in rezultatov orodij ustvari odgovor. Zato se testirajo obnašanje pri odgovarjanju, vezanost na vire, format, uporaba orodij, varnost, zakasnitev (latenca) in stroški.

Tudi splošno testiranje v načinu senc (Shadow Mode) pred lansiranjem na spletnem mestu reši le del naloge. Senčni promet lahko oskrbuje dva modela z istimi vnosi, ne da bi dostavil nov odgovor. Tu opisana zamenjava osnovnega modela gre dlje: vnaprej opredeli prevzemno matriko, usmeri majhen delež pravega prometa na kandidata, spremlja signale uporabnikov ter sistema in ima pripravljeno preizkušeno možnost povratnega preklopa.

Pred testiranjem: določite jasno migracijsko pogodbo

Primerjave so brez vrednosti, če se medtem spremeni več stvari hkrati. Zato za prvi krog ohranite sistemske pozive, konfiguracijo pridobivanja podatkov (retrieval), sheme orodij, temperaturo, največjo dolžino izpisa in varnostna pravila čim bolj konstantne ter dokumentirajte neizogibne spremembe parametrov, kot so nepodprte možnosti vzorčenja. Dokumentirajte dosedanji model kot osnovo (baseline) in nov model kot kandidata. Če je mogoče, uporabljajte eksplicitne različice modelov namesto premičnih vzdevkov (alias). Vzdevek lahko pozneje pokaže na drug posnetek stanja in spremeni domnevno ponovljivo primerjavo.

Migracijska pogodba vsebuje tudi uporabniške skupine in funkcije, ki so sprva izključene. Klepetalnik za pogosta vprašanja (FAQ) lahko na primer zgodaj vstopi v Canary fazo, medtem ko dostopi za zapisovanje naročil, informacije o pogodbah ali posebej občutljivi primeri podpore dlje ostanejo na osnovnem modelu. Tako se tveganje omeji glede na poslovni vpliv in ne le glede na tehnično kompleksnost.

Testni nabor mora odražati stvarni promet

Zlati nabor (Golden Set) ne bi smel vsebovati le čistih standardnih vprašanj. Zberite anonimizirane ali sintetično poustvarjene primere iz najpomembnejših namenov (intents): jasna vprašanja, dvoumne formulacije, nadaljevalna vprašanja, manjkajoče dokumente, protislovne vire, napake orodij in vnose, ki jih je treba predati človeku. Primere razdelite po jeziku, napravi, tipu stranke in razredu tveganja. S tem ostane vidno, ali dobra skupna ocena prikriva majhne, a za posel ključne podskupine.

Uradna Anthropic navodila o merilih uspeha in evalvacijah (Evals) priporočajo specifična, merljiva in na namen uporabe vezana merila ter realistične robne primere. Tudi OpenAI navodila o evalvacijah (Evals) opisujejo testiranje kot bistven sestavni del zanesljivih aplikacij, zlasti pri nadgradnji ali preizkušanju novih modelov. Ker OpenAI na isti strani napoveduje umik dosedanje platforme Evals, je treba lasten zlati nabor shraniti v prenosljivem formatu in ga ne vezati na posamezno nadzorno ploščo.

Ocenjevalna matrika namesto ene same povprečne vrednosti

Naslednje mejne vrednosti so primer in ne univerzalna navodila. Določite jih na podlagi dosedanje zmogljivosti v produkciji in škode ob napaki. Kandidat ne sme nižje cene žetonov doseči s slabšo vezanostjo na vire.

Samodejna preverjanja so primerna za JSON-sheme, obvezne formulacije, cilje povezav, argumente orodij in deterministična poslovna pravila. Za ton, popolnost in koristna pojasnila pa je dodatno potrebna jasna rubrika; vzorčni pregledi strokovnjakov kalibrirajo ocenjevalca, ki temelji na LLM. Rezultate je treba shranjevati po namenih in razredih tveganja, ne le kot eno skupno oceno. Kako se takšen nabor načeloma sestavi, prikazuje tudi naš vodnik za kakovost odgovorov z zlatim naborom.

Konkreten primer: Zamenjava modela pri B2B podpori

Predpostavimo, da ponudnik programske opreme B2B upravlja klepetalnik za vprašanja o izdelkih, upravljanje računov in pripravo zahtevkov za podporo. Ekipa ustvari 240 testnih primerov: 120 pogostih vprašanj o znanju, 40 dvoumnih nadaljevalnih vprašanj, 30 primerov z manjkajočim virom, 25 simulacij orodij in 25 primerov varnosti ali predaje. Oba modela prejmeta natanko iste pozive, ujemajoče se dokumente in simulirane rezultate orodij.

Kandidat odgovarja na standardna vprašanja hitreje in ceneje, vendar pri petih nadaljevalnih vprašanjih izgubi povezavo s prejšnjim sporočilom. Skupna ocena bi bila kljub temu boljša. Vendar pa segmentna analiza pokaže jasen padec kakovosti. Ekipa ne doda poljubne izjeme, temveč natančneje opredeli pogovorno pravilo, razširi testni nabor s podobnimi primeri in znova testira oba modela. Šele ko kandidat izpolni vsa stroga vrata (Gates), se začne produkcijski Canary.

Za začetek se dvema odstotkoma primernih novih pogovorov dodeli kandidat. Dodelitev se ob začetku pogovora izpelje na primer iz zgoščene vrednosti (hash) ID-ja pogovora in se ohrani za celoten pogovor; višje stopnje Canaryja veljajo le za nove pogovore. Pozivi z orodji, ki zapisujejo podatke, in nameni z visokim tveganjem sprva ostanejo na osnovnem modelu. Po dovolj velikem oknu opazovanja sledijo stopnje 10, 25, 50 in na koncu 100 odstotkov – vendar le, če so vsa vrata še naprej zelena. Stopnje in najmanjše velikosti vzorcev se določijo vnaprej, da časovni pritisk pozneje ne razvodeni pravil.

Spletni signali, ki resnično štejejo

V Canary fazi HTTP napake in povprečna zakasnitev ne zadoščajo. Spremljajte stopnjo brez odgovora (No-Answer), prekinitev po prvem odgovoru, ponavljajoča se vprašanja, stopnjo predaje (Handoff), klike na vire, napake v shemi in prekinitve orodij ločeno za osnovni model in kandidata. Skupna sled (Trace) povezuje različico modela, različico poziva, ujemajoče se vire in korake orodij, ne da bi shranjevala nepotrebne osebne podatke. Naš prispevek o observabilnosti klepetalnika podrobno pojasnjuje to sledilno pot.

Poleg tega primerjajte stroške na uspešno rešen primer namesto le stroškov na milijon žetonov. Cenejši model, ki pogosteje sproži dodatna vprašanja ali ročno delo ljudi, je lahko operativno dražji. Nasprotno pa je lahko rahlo povečanje zakasnitve sprejemljivo, če dokazljivo prinaša natančnejše odgovore v pomembnem razredu tveganja.

Povratni preklop (Rollback) je funkcija, ne dokument

Pot nazaj mora biti tehnično preizkušena pred prvo Canary stopnjo. ID modela in pripadajoči parametri sodijo v verzionirano konfiguracijo ali nadzorovano funkcijsko zastavico (Feature Flag). Dokler ponudnik še podpira dosedanjo različico, ta med Canary fazo ostaja na voljo kot rezervni cilj; pred datumom njenega izklopa je dodatno potreben podprt fallback. Obstoječi pogovori morajo ostati dosledno na svojem izvirnem modelu ali pa preklopiti po izrecno preizkušenem pravilu.

Določite stroge sprožilce: na primer napako v shemi pri dejanju zapisovanja, poslabšanje varnostno pomembnega namena, opazen skok v stopnji napak ali prekoračitev proračuna zakasnitve. Ob takšnem signalu se preklop nazaj izvede samodejno ali prek jasno določene dežurne ekipe. Po tem se dnevniki (logs), različica kandidata in prizadeti vzorec ohranijo, da se lahko analizira vzrok. Pripravljen postopek je bistveno bolj zanesljiv kot spontana namestitev kode; v pomoč je tudi popoln priročnik za odzivanje na incidente (Incident Response Playbook).

Kontrolni seznam za odobritev

• Zabeležite datum izklopa, nadomestni model in prizadete končne točke iz uradne dokumentacije ponudnika.
• Določite osnovo in kandidata z nespremenjeno konfiguracijo pozivov, pridobivanja podatkov in orodij.
• Razdelite zlati nabor glede na namen, jezik in razred tveganja; dodajte robne primere in dejanske vzorce napak.
• Določite stroga vrata (Gates) za vezanost na vire, strukturirane izpise, orodja, varnost in predajo.
• Izmerite zakasnitev, stopnjo napak, žetone in stroške na rešen primer.
• Ohranite Canary dodelitev stabilno za celotne pogovore in sprva izključite občutljive funkcije.
• Dokumentirajte stopnje, minimalni vzorec, trajanje opazovanja in meje prekinitve pred uvajanjem.
• Tehnično preizkusite povratni preklop (Rollback), določite odgovorne in imejte na voljo rezervni cilj, ki ga ponudnik podpira.
• Po doseženih 100 odstotkih nadaljujte s spremljanjem in razširite zlati nabor z novo odkritimi primeri iz produkcije.

Zaključek: Ime modela je šele začetek

Nadzorovana zamenjava osnovnega modela združuje kakovost izdelka in operativno varnost. Uradna obvestila o življenjskem ciklu določajo rok, evalvacije (Evals) zagotavljajo dokaze o primernosti, Canary promet omejuje vpliv neznanih napak, preizkušen Rollback pa skrajša odzivni čas. Kdor te štiri gradnike vzpostavi kot ponovljiv proces, lahko uporablja nove modele, ne da bi svoj spletni klepetalnik spremenil v poskus za vse uporabnike.

Želite strukturirano načrtovati različico modela, kontrole kakovosti in uvajanje vašega spletnega klepetalnika? ChatReact vam pomaga nastaviti bazo znanja, obnašanje pri odgovarjanju in predaje tako, da spremembe ostanejo merljive in pod nadzorom.