Promjena temeljnog AI modela bez pada kvalitete: Evals, Canary i Rollback

Novi temeljni AI model često obećava bolje odgovore, niže troškove ili brže vrijeme odziva. Za produkcijski web chatbot, međutim, ta zamjena nije poput uobičajenog ažuriranja softverskog paketa. Čak i nova verzija modela može drugačije vrednovati upute, detaljnije formulirati odgovore, odstupati u generiranju strukturiranih podataka ili pozivati alate u drugom redoslijedu. Migracija je stoga uspješna tek kada chatbot svoje konkretne zadatke obavlja barem jednako pouzdano kao i prije – te kada se tim u slučaju problema može vratiti na prethodno stanje u nekoliko minuta.

Pružatelji usluga redovito najavljuju povlačenje modela. OpenAI dokumentacija o povlačenju modela navodi datume gašenja i preporučene zamjenske modele; Anthropic u svom životnom ciklusu modela razlikuje statuse „Active“, „Legacy“, „Deprecated“ i „Retired“. Takvi su rokovi povod za migraciju, ali nisu dokaz njezine kvalitete. Njega pruža samo postupak testiranja i uvođenja koji je prilagođen vašem chatbotu.

Što se zapravo mijenja pri zamjeni temeljnog modela

Ovaj se proces jasno razlikuje od migracije modela za ugrađivanje (embedding). Kod migracije embeddinga dokumenti se moraju ponovno vektorizirati i održavati kompatibilnost indeksa pretraživanja. Kod zamjene temeljnog modela indeks dohvaćanja (retrieval) obično ostaje nepromijenjen; mijenja se model koji iz sustavnih uputa, razgovora, pronađenih izvora i rezultata alata generira konačni odgovor. Stoga se testiraju ponašanje pri odgovaranju, oslanjanje na izvore, format, korištenje alata, sigurnost, latencija i troškovi.

Čak i općenito testiranje u načinu sjene (Shadow Mode) prije pokretanja rješava samo dio zadatka. Shadow Traffic može opskrbiti dva modela istim ulaznim podacima bez isporuke novog odgovora korisniku. Ovdje opisana zamjena temeljnog modela ide korak dalje: unaprijed definira matricu prihvaćanja, usmjerava mali udio stvarnog prometa prema kandidatu, prati signale korisnika i sustava te drži pripremljen i testiran plan povratka.

Prije testiranja: definiranje jasnog ugovora o migraciji

Usporedbe su bezvrijedne ako se istovremeno mijenja više stvari. Stoga u prvom krugu zadržite sistemski prompt, konfiguraciju dohvaćanja, sheme alata, temperaturu, maksimalnu duljinu izlaza i sigurnosna pravila što je više moguće konstantnima te dokumentirajte neizbježne promjene parametara, poput nepodržanih opcija uzorkovanja. Dokumentirajte dosadašnji model kao bazu, a novi model kao kandidata. Gdje god je moguće, koristite eksplicitne verzije modela umjesto promjenjivih alijasa. Alijas bi kasnije mogao pokazivati na drugi snimak (snapshot) i promijeniti usporedbu za koju ste mislili da je reproduktibilna.

Ugovor o migraciji također sadrži skupine korisnika i funkcije koje su u početku isključene. Na primjer, FAQ chatbot može rano ući u Canary fazu, dok pristupi pisanju narudžbi, informacije o ugovorima ili posebno osjetljivi slučajevi podrške duže ostaju na baznom modelu. Na taj se način rizik ograničava prema poslovnom utjecaju, a ne samo prema tehničkoj složenosti.

Skup za testiranje mora odražavati stvarni promet

Golden Set ne bi trebao sadržavati samo čista standardna pitanja. Prikupite anonimizirane ili sintetički stvorene slučajeve iz najvažnijih namjera (intents): jasna pitanja, višeznačne formulacije, naknadna pitanja, dokumente koji nedostaju, proturječne izvore, pogreške u alatima i upite koji se moraju proslijediti čovjeku. Podijelite slučajeve prema jeziku, uređaju, vrsti kupca i klasi rizika. Time ostaje vidljivo prikriva li dobra ukupna ocjena male, ali poslovno kritične podskupine.

Službeni Anthropic vodič o kriterijima uspjeha i evaluacijama preporučuje specifične, mjerljive kriterije prilagođene svrsi primjene te realistične rubne slučajeve. Također, OpenAI vodič o evaluacijama opisuje testove kao ključnu komponentu pouzdanih aplikacija, osobito pri nadogradnji ili isprobavanju novih modela. Budući da OpenAI na istoj stranici najavljuje gašenje dosadašnje Evals platforme, vlastiti Golden Set treba pohraniti u prenosivom formatu i ne vezati ga uz pojedinačnu upravljačku ploču.

Matrica vrednovanja umjesto jedne prosječne vrijednosti

Sljedeće granične vrijednosti služe kao primjer, a ne kao univerzalno pravilo. Postavite ih na temelju dosadašnjih performansi u produkciji i štete koju bi pogreška mogla uzrokovati. Kandidat ne smije postići nižu cijenu tokena na račun lošijeg oslanjanja na izvore.

Automatske provjere prikladne su za JSON sheme, obvezne formulacije, odredišta poveznica, argumente alata i deterministička poslovna pravila. Za ton, potpunost i korisna objašnjenja dodatno je potrebna jasna rubrika; nasumične provjere od strane stručnjaka kalibriraju evaluator zasnovan na LLM-u. Rezultate bi trebalo spremati po namjeri i klasi rizika, a ne samo kao jedinstvenu ocjenu. Kako se takav skup u osnovi gradi, prikazuje i naš vodič za kvalitetu odgovora uz Golden Set.

Konkretan primjer: zamjena modela u B2B podršci

Pretpostavimo da B2B pružatelj softvera upravlja chatbotom za pitanja o proizvodima, upravljanje računima i pripremu zahtjeva za podršku. Tim stvara 240 testnih slučajeva: 120 čestih pitanja o znanju, 40 višeznačnih naknadnih pitanja, 30 slučajeva s nedostajućim izvorom, 25 simulacija alata i 25 slučajeva sigurnosti ili preusmjeravanja. Oba modela dobivaju potpuno iste promptove, rezultate dohvaćanja dokumenta i simulirane rezultate alata.

Kandidat brže i povoljnije odgovara na standardna pitanja, ali u pet naknadnih pitanja gubi kontekst s prethodnom porukom. Ukupna ocjena i dalje bi bila bolja. Međutim, analiza po segmentima pokazuje jasan pad kvalitete. Tim ne dodaje proizvoljnu iznimku, već precizira pravilo razgovora, proširuje testni skup sličnim slučajevima i ponovno testira oba modela. Tek nakon što kandidat zadovolji sva stroga vrata, započinje produkcijski Canary.

Za početak se dva posto odgovarajućih novih razgovora dodjeljuje kandidatu. Dodjela se na početku razgovora derivira, primjerice, iz sažetka (hash) ID-a razgovora i perzistira za cijeli razgovor; više Canary razine primjenjuju se samo na nove razgovore. Pozivi alata koji vrše upis i visokorizične namjere u početku ostaju na baznom modelu. Nakon dovoljno velikog prozora promatranja slijede deset, 25, 50 i na kraju 100 posto – ali samo ako su sva vrata i dalje zelena. Faze i minimalne veličine uzoraka definiraju se unaprijed kako vremenski pritisak ne bi naknadno ublažio pravila.

Online signali koji stvarno vrijede

U Canary fazi HTTP pogreške i prosječna latencija nisu dovoljni. Pratite stopu bez odgovora, odustajanje nakon prvog odgovora, ponovljena pitanja, stopu preusmjeravanja na čovjeka, klikove na izvore, pogreške u shemi i prekide alata odvojeno za bazni model i kandidata. Zajednički trag (trace) povezuje verziju modela, verziju prompta, pogoditke dohvaćanja i korake alata, bez spremanja nepotrebnih osobnih podataka. Naš članak o promatrivosti chatbota (observability) detaljno objašnjava taj trag provjere.

Usporedite i troškove po uspješno riješenom slučaju, umjesto samo troškova po milijunu tokena. Povoljniji model koji češće uzrokuje dodatna pitanja ili ručni rad ljudi u konačnici može biti operativno skuplji. Suprotno tome, blago povećanje latencije može biti prihvatljivo ako u važnoj klasi rizika dokazano donosi preciznije odgovore.

Rollback je funkcionalnost, a ne dokument

Put povratka mora biti tehnički testiran prije prve Canary faze. ID modela i pripadajući parametri spadaju u verzioniranu konfiguraciju ili kontroliranu zastavicu značajke (feature flag). Dok god pružatelj usluge podržava dosadašnju verziju, ona ostaje dostupna kao cilj povratka tijekom Canary faze; prije datuma njezinog gašenja dodatno je potreban podržani zamjenski izbor (fallback). Postojeći razgovori trebali bi ili ostati dosljedno na svom izvornom modelu ili se prebaciti prema izričito testiranom pravilu.

Definirajte stroge okidače: primjerice, pogrešku u shemi pri radnji pisanja, pogoršanje sigurnosno relevantne namjere, značajan skok stope pogrešaka ili prekoračenje proračuna latencije. Pri takvom signalu vraćanje na prethodno stanje izvršava se automatski ili putem jasno određene dežurne osobe. Nakon toga se zapisnici (logs), verzija kandidata i pogođeni uzorak zadržavaju kako bi se mogao analizirati uzrok. Pripremljeni postupak znatno je pouzdaniji od spontane primjene koda (deploy); kao dopuna pomaže cjeloviti priručnik za odgovor na incidente.

Kontrolni popis za odobrenje

• Evidentirati datum gašenja, zamjenski model i pogođene krajnje točke iz službene dokumentacije pružatelja usluge.
• Fiksirati bazni model i kandidata s nepromijenjenom konfiguracijom prompta, dohvaćanja i alata.
• Podijeliti Golden Set prema namjeri, jeziku i klasi rizika; dodati rubne slučajeve i stvarne primjere pogrešaka.
• Definirati stroga vrata za oslanjanje na izvore, strukturirane izlaze, alate, sigurnost i preusmjeravanje.
• Izmjeriti latenciju, stopu pogrešaka, tokene i trošak po riješenom slučaju.
• Održavati dodjelu Canaryja stabilnom za cijele razgovore i u početku isključiti osjetljive funkcije.
• Dokumentirati faze, minimalni uzorak, trajanje promatranja i granice prekida prije uvođenja.
• Tehnički testirati Rollback, imenovati odgovorne osobe i održavati dostupnim cilj povratka koji podržava pružatelj usluge.
• Nakon dostizanja 100 posto nastaviti s praćenjem i proširiti Golden Set novootkrivenim slučajevima iz produkcije.

Zaključak: Naziv modela samo je početak

Kontrolirana zamjena temeljnog modela spaja kvalitetu proizvoda i operativnu sigurnost. Službene obavijesti o životnom ciklusu daju rok, evaluacije daju dokaze o prikladnosti, Canary promet ograničava utjecaj nepoznatih pogrešaka, a testirani Rollback skraćuje vrijeme reakcije. Tko uspostavi ove četiri komponente kao ponovljiv proces, može koristiti nove modele bez pretvaranja svog web chatbota u eksperiment za sve korisnike.

Želite li strukturirano planirati verziju modela, vrata kvalitete i uvođenje vašeg web chatbota? ChatReact vam pomaže postaviti bazu znanja, ponašanje pri odgovaranju i preusmjeravanja tako da promjene ostanu mjerljive i pod kontrolom.