KI bazinio modelio keitimas be kokybės praradimo: Evals, Canary ir Rollback

Naujas KI bazinis modelis dažnai žada geresnius atsakymus, mažesnes išlaidas arba trumpesnį reakcijos laiką. Tačiau veikiančiam svetainės pokalbių robotui šis keitimas nėra tiesiog bet kokios programinės įrangos paketo pakeitimas. Net ir nauja modelio versija gali kitaip sverti nurodymus, išsamiau formuluoti atsakymus, kitaip generuoti struktūrizuotus duomenis arba kviesti įrankius kita tvarka. Todėl migracija yra sėkminga tik tada, kai pokalbių robotas savo konkrečias užduotis atlieka bent jau taip pat patikimai kaip anksčiau – ir kai komanda, kilus problemoms, gali per kelias minutes grįžti prie ankstesnės versijos.

Tiekėjai reguliariai praneša apie modelių palaikymo pabaigą. „OpenAI“ dokumentacijoje apie palaikymo pabaigą pateikiamos išjungimo datos ir rekomenduojami pakaitiniai modeliai; „Anthropic“ savo modelių gyvavimo cikle išskiria būsenas „Active“, „Legacy“, „Deprecated“ ir „Retired“. Tokie terminai yra migracijos priežastis, tačiau jie nėra jos kokybės įrodymas. Kokybės įrodymą pateikia tik testavimo ir išskleidimo (rollout) procesas, pritaikytas jūsų pačių pokalbių robotui.

Kas iš tikrųjų pasikeičia keičiant bazinį modelį

Šį procesą reikia aiškiai atskirti nuo Embedding modelio migracijos. Keičiant Embedding modelį, dokumentus reikia iš naujo paversti vektoriais ir užtikrinti paieškos indeksų suderinamumą. Keičiant bazinį modelį, paieškos indeksas paprastai lieka tas pats; pasikeičia modelis, kuris iš sistemos nurodymų, pokalbio, rastų šaltinių ir įrankių rezultatų sugeneruoja atsakymą. Todėl testuojama atsakymų elgsena, sąsaja su šaltiniais, formatas, įrankių naudojimas, saugumas, delsa ir išlaidos.

Taip pat ir bendras Shadow mode testas prieš paleidimą svetainėje išsprendžia tik dalį užduoties. Shadow srautas gali pateikti tuos pačius įvesties duomenis dviem modeliams, nepateikdamas naujo atsakymo vartotojui. Čia aprašytas bazinio modelio keitimas eina toliau: jis iš anksto apibrėžia priėmimo matricą, nukreipia nedidelę dalį tikrojo srauto kandidatui, stebi vartotojų bei sistemos signalus ir turi paruoštą bei patikrintą grąžinimo mechanizmą.

Prieš testą: nustatykite aiškią migracijos sutartį

Palyginimai beverčiai, jei tuo pačiu metu keičiasi keli dalykai. Todėl pirmajam etapui išlaikykite sistemos Prompt, paieškos konfigūraciją, įrankių schemas, temperatūrą, maksimalų išvesties ilgį ir saugumo taisykles kuo labiau suderinamus bei nekintančius, taip pat dokumentuokite neišvengiamus parametrų pokyčius, pavyzdžiui, nepalaikomas Imties (Sampling) parinktis. Dokumentuokite iki šiol naudotą modelį kaip bazinį, o naująjį – kaip kandidatą. Jei įmanoma, naudokite aiškias modelių versijas, o ne kintantį pseudonimą (alias). Pseudonimas vėliau gali rodyti į kitą momentinę nuotrauką (snapshot) ir pakeisti tariamai atkuriamą palyginimą.

Migracijos sutartyje taip pat nurodomos vartotojų grupės ir funkcijos, kurios iš pradžių neįtraukiamos. Pavyzdžiui, DUK pokalbių robotas gali anksti patekti į Canary etapą, o rašymo prieiga prie užsakymų, informacija apie sutartis ar ypač jautrūs pagalbos atvejai ilgiau lieka baziniame modelyje. Taip rizika apribojama pagal poveikį verslui, o ne tik pagal techninį sudėtingumą.

Testavimo rinkinys turi atspindėti tikrąjį srautą

Etaloniniame rinkinyje (Golden Set) neturėtų būti tik tvarkingi standartiniai klausimai. Surinkite nuasmenintus arba sintetiškai atkartotus atvejus iš svarbiausių intencijų (Intents): aiškius klausimus, dviprasmiškas formuluotes, papildomus klausimus, trūkstamus dokumentus, prieštaringus šaltinius, įrankių klaidas ir įvestis, kurias reikia perduoti žmogui. Padalinkite atvejus pagal kalbą, įrenginį, kliento tipą ir rizikos klasę. Taip matysite, ar geras bendras įvertinimas neslepia mažų, bet verslui kritiškai svarbių pogrupių.

Oficiali „Anthropic“ instrukcija apie sėkmės kriterijus ir Evals rekomenduoja specifinius, išmatuojamus ir su naudojimo tikslu susijusius kriterijus bei tikroviškus kraštutinius atvejus. Taip pat ir „OpenAI“ instrukcija apie Evals aprašo testus, ypač atnaujinant ar išbandant naujus modelius, kaip esminę patikimų programų dalį. Kadangi „OpenAI“ tame pačiame puslapyje praneša apie ikišiolinės Evals platformos palaikymo pabaigą, nuosavas Golden Set turėtų būti išsaugotas nešiojamu formatu ir nepririštas prie vieno prietaisų skydelio (dashboard).

Vertinimo matrica vietoje vieno vidurkio

Šios ribinės vertės yra pavyzdys, o ne visuotinė taisyklė. Nustatykite jas remdamiesi ikišioliniu produkto našumu ir galimu žalos dydžiu įvykus klaidai. Kandidatas negali išpirkti pigesnės žetonų (tokens) kainos prastesniu atitikimu šaltiniams.

Automatiniai patikrinimai tinka JSON schemoms, privalomoms formuluotėms, nuorodų tikslams, įrankių argumentams ir deterministinėms verslo taisyklėms. Tonui, išsamumui ir naudingiems paaiškinimams papildomai reikalinga aiški vertinimo sistema; specialistų atliekamos atrankinės patikros kalibruoja LLM paremtą vertintoją. Rezultatai turėtų būti išsaugoti kiekvienai intencijai ir rizikos klasei atskirai, o ne tik kaip vienas bendras balas. Kaip iš esmės sukurti tokį rinkinį, taip pat rodo mūsų gidas apie atsakymų kokybę su Golden Set.

Konkretus pavyzdys: modelio keitimas B2B palaikymo sistemoje

Pavyzdžiui, B2B programinės įrangos tiekėjas valdo pokalbių robotą, skirtą klausimams apie produktą, paskyros valdymui ir pagalbos užklausų paruošimui. Komanda sukuria 240 testavimo atvejų: 120 dažnų žinių klausimų, 40 dviprasmiškų papildomų klausimų, 30 atvejų su trūkstamu šaltiniu, 25 įrankių simuliacijas ir 25 saugumo arba perdavimo atvejus. Abu modeliai gauna visiškai tokius pačius promptus, dokumentų atitikmenis ir imituotus įrankių rezultatus.

Kandidatas į standartinius klausimus atsako greičiau ir pigiau, tačiau penkiuose papildomuose klausimuose praranda ryšį su ankstesne žinute. Bendras įvertinimas vis tiek būtų geresnis. Tačiau segmentų analizė rodo aiškų kokybės pablogėjimą. Komanda netaiko jokios savavališkos išimties, o patikslina pokalbio taisyklę, papildo testavimo rinkinį panašiais atvejais ir iš naujo patikrina abu modelius. Tik po to, kai kandidatas atitinka visus griežtus reikalavimus, prasideda gamybinis Canary etapas.

Pradžiai du procentai tinkamų naujų pokalbių priskiriami kandidatui. Priskyrimas pokalbio pradžioje gaunamas, pavyzdžiui, iš Conversation-ID maišos (hash) ir išsaugomas visam pokalbiui; aukštesni Canary etapai taikomi tik naujiems pokalbiams. Rašymo veiksmai įrankiuose ir didelės rizikos intencijos iš pradžių lieka baziniame modelyje. Po pakankamai ilgo stebėjimo periodo seka 10, 25, 50 ir galiausiai 100 procentų – bet tik tada, jei kiekvienas slenkstis išlieka žalias. Etapai ir minimalios imtys nustatomi iš anksto, kad laiko spaudimas vėliau nesumažintų reikalavimų.

Tiesioginio darbo (Online) signalai, kurie iš tiesų svarbūs

Canary etape nepakanka vien HTTP klaidų ir vidutinės delsos. Stebėkite No-Answer rodiklį, nutraukimą po pirmo atsakymo, pasikartojančius klausimus, Handoff dalį, paspaudimus ant šaltinių, schemų klaidas ir įrankių nutraukimus atskirai bazei ir kandidatui. Bendras pėdsakas (Trace) sujungia modelio versiją, Prompt versiją, paieškos atitikmenis ir įrankių žingsnius, neįrašant nereikalingų asmens duomenų. Mūsų straipsnis apie pokalbių robotų stebimumą (Observability) išsamiai paaiškina šį patikrinimo pėdsaką.

Taip pat palyginkite išlaidas vienam sėkmingai išspręstam atvejui, o ne tik išlaidas už milijoną žetonų (Tokens). Pigesnis modelis, kuris dažniau reikalauja papildomų klausimų arba žmogaus įsikišimo, operaciniu požiūriu gali būti brangesnis. Ir priešingai, nedidelis delsos padidėjimas gali būti priimtinas, jei jis svarbioje rizikos klasėje užtikrina įrodomai tikslesnius atsakymus.

Rollback yra funkcija, o ne dokumentas

Grįžimo kelias turi būti techniškai patikrintas dar prieš pirmąjį Canary etapą. Modelio ID ir susiję parametrai priklauso versijuojamai konfigūracijai arba valdomam Feature Flag. Kol tiekėjas dar palaiko ankstesnę versiją, ji Canary metu lieka prieinama kaip atsarginis tikslas; prieš jos išjungimo terminą papildomai reikalinga palaikoma atsarginė galimybė. Esami pokalbiai turėtų arba nuosekliai likti savo pradiniame modelyje, arba pereiti pagal aiškiai patikrintą taisyklę.

Apibrėžkite griežtus suveikimo veiksnius: pavyzdžiui, schemos klaidą atliekant rašymo veiksmą, saugumui svarbios intencijos pablogėjimą, žymų klaidų skaičiaus šuolį arba delsos biudžeto viršijimą. Esant tokiam signalui, automatiškai arba per aiškiai paskirtą budintį asmenį atliekamas grąžinimas. Po to žurnalai (Logs), kandidato versija ir susijusi imtis išsaugomi, kad būtų galima išanalizuoti priežastį. Paruošta procedūra yra daug patikimesnė nei skubus kodo diegimas; papildomai padeda pilnas Incident Response Playbook.

Patvirtinimo kontrolinis sąrašas

• Užfiksuokite išjungimo datą, pakaitinį modelį ir susijusius galinius punktus (Endpoints) iš oficialios tiekėjo dokumentacijos.
• Fiksuokite bazę ir kandidatą su nepakitusia prompto, paieškos ir įrankių konfigūracija.
• Padalykite Golden Set pagal intenciją, kalbą ir rizikos klasę; papildykite kraštutiniais atvejais ir tikrais klaidų pavyzdžiais.
• Apibrėžkite griežtus slenksčius atitikimui šaltiniams, struktūrizuotoms išvestims, įrankiams, saugumui ir Handoff.
• Išmatuokite delsą, klaidų dažnumą, žetonus ir išlaidas vienam išspręstam atvejui.
• Išlaikykite stabilų Canary priskyrimą visiems pokalbiams ir iš pradžių neįtraukite jautrių funkcijų.
• Dokumentuokite etapus, minimalią imtį, stebėjimo trukmę ir nutraukimo ribas prieš išskleidimą.
• Techniškai patikrinkite Rollback, paskirkite atsakingus asmenis ir turėkite tiekėjo palaikomą atsarginį modelį.
• Pasiekę 100 procentų, toliau stebėkite ir papildykite Golden Set naujai atrastais gamybiniais atvejais.

Išvada: modelio pavadinimas yra tik pradžia

Valdomas bazinio modelio keitimas sujungia produkto kokybę ir veikimo saugumą. Oficialios gyvavimo ciklo nuorodos pateikia terminus, Evals pateikia tinkamumo įrodymus, Canary srautas apriboja nežinomų klaidų poveikį, o patikrintas Rollback sutrumpina reakcijos laiką. Kas šiuos keturis komponentus įdiegia kaip kartojamą procesą, gali naudoti naujus modelius nepaversdamas savo svetainės pokalbių roboto eksperimentu visiems vartotojams.

Norite struktūrizuotai suplanuoti savo svetainės pokalbių roboto modelio versiją, kokybės slenksčius ir išskleidimą? ChatReact padeda jums taip paruošti žinių bazę, atsakymų elgseną ir perdavimus, kad pokyčiai išliktų išmatuojami ir valdomi.