RAG embedding modelio keitimas: DI pokalbių boto migravimas be žinių spragų

Embedding modelis dažniausiai veikia nematomai RAG pokalbių boto fone. Jis paverčia klausimus ir žinių fragmentus skaičių vektoriais, kad būtų surastas semantiškai tinkamas turinys. Kadangi ši dalis retai matoma vartotojo sąsajoje, modelio keitimas gali atrodyti kaip nedidelis konfigūracijos pakeitimas. Tačiau techniškai sukuriama visiškai nauja paieškos erdvė. Esami dokumentų vektoriai, naujų klausimų vektoriai ir indekso apibrėžimas turi vėl atitikti vienas kitą.

Norintys pakeisti RAG embeddings neturėtų tiesiog pakeisti modelio pavadinimo užklausų grandinėje (angl. query pipeline). Saugus keitimas vertina naująjį indeksą kaip atskirą versiją: atkuriamai sugeneruotą, patikrintą tais pačiais testiniais klausimais, iš pradžių naudojamą lygiagrečiai ir aktyvuojamą tik priėmus sąmoningą patvirtinimo sprendimą. Taip svetainės pokalbių botas išlieka pasiekiamas, o komanda kontroliuoja kokybę, veikimo laiką, kaštus ir grįžtamąjį kelią.

Kodėl embeddings nėra laisvai sukeičiami

Vektorius turi prasmę tik toje erdvėje, kurioje jis buvo sugeneruotas. Oficiali Azure AI Search dokumentacija apie mektorių indekso kūrimą apibūdina indeksą kaip to paties modelio vektorių embedding erdvę. Joje taip pat pažymima, kad kiekvieno vektoriaus dimensija turi atitikti lauko apibrėžimą. Naujas modelis gali turėti kitą dimensiją, kitokį kalbų palaikymą arba kitokį semantinių atstumų pasiskirstymą.

Ne mažiau svarbi yra užklausų pusė. Remiantis Microsoft dokumentacija apie Vectorizer konfigūraciją, indeksavimas ir užklausos turi naudoti tą patį embedding modelį. Jei komanda sumaišo senus dokumentų vektorius su klausimais iš naujo modelio, panašumo įverčiai (angl. similarity scores) nebegali būti patikimai interpretuojami. Net jei dimensijos atsitiktinai sutampa, tai neįrodo semantinio suderinamumo.

Prieš keitimą apibrėžkite išmatuojamą tikslą

„Naujesnis“ nėra pakankamas priėmimo kriterijus. Prieš pirmąjį perindeksavimą komandai reikia konkrečios migracijos priežasties. Ar norima pagerinti rezultatų kokybę specializuota lietuvių kalba? Ar reikalingos papildomos kalbos? Ar ankstesnis modelis nutraukiamas, yra per lėtas ar per brangus? Aišku, galbūt mažesnė vektoriaus dimensija leistų sutaupyti atminties? Iš šio tikslo formuojami palyginimo metrikos rodikliai.

• Kokybė: aktualūs šaltiniai tarp top-k rezultatų, atsakomų klausimų dalis ir galutinio atsakymo kokybė.
• Veikimas: paieškos delsa (angl. retrieval latency), klaidų dažnumas, indeksavimo trukmė ir elgsena esant dalinėms klaidoms.
• Išlaidos: visų duomenų embedding generavimas, einamieji pakeitimai, saugykla ir užklausos.
• Prieinamumas: dokumentai, kalbos, produkto versijos ir teisės naujajame indekse.

Pradinės vertės turi būti įtrauktos į tą pačią patikros ataskaitą kaip ir kandidato rezultatai. Jei tam jau naudojate „Golden Set“, galite remtis turimu gidu apie DI pokalbių boto atsakymų kokybės matavimą. Svarbu lyginti ne tik vidutinį įvertį: svarbūs palaikymo klausimai, retai naudojami terminai ir atvejai be rezultatų reikalauja atskiros analizės.

Du indeksai vietoje pakeitimų veikiančioje sistemoje

Patikimas standartas yra lygiagretus indeksas. Ankstesnis indeksas lieka nepakitęs ir aptarnauja realaus laiko srautą. Šalia sukuriama nauja kolekcija arba naujas indeksas su savo modelio identifikatoriumi, dimensija, atstumo metrika ir versijos numeriu. Abu kuriami iš tos pačios patvirtintos šaltinio versijos. Taip visi skirtumai gali būti priskirti modelio arba indekso konfigūracijai, o ne vienu metu besikeičiančiam turiniui.

Oficialus Weaviate vadovas apie Vectorizer keitimą rodo atskiras kolekcijas ir slapyvardį (angl. alias) kaip atšaukiamą perjungimo tašką. Konkretus produktas gali skirtis, tačiau principas išlieka naudingas: švariai izoliuoti senus ir naujus embeddings, nukreipti prieigą per valdomą maršrutizatorių arba alias, ir išsaugoti senąją būseną ribotam grąžinimo laikotarpiui.

Stabilūs tapatybės ID kiekvienam žinių fragmentui

Kiekvienam fragmentui (angl. chunk) reikalingas stabilus verslo ID, nepriklausantis nuo vektoriaus. Prasminga derinti šaltinio ID, šaltinio versiją, skyrių ir fragmento versiją. Papildomai kiekvienas duomenų įrašas turėtų turėti modelio pavadinimą, modelio versiją, dimensiją, sukūrimo laiką ir įtraukto teksto kontrolinę sumą (angl. hash). Taip sistema gali tiksliai atpažinti, kas jau apdorota, ką reikia įtraukti iš naujo ir kurios klaidos dar neišspręstos.

Atkuriamas naujos grandinės užfiksavimas

Prieš atliekant didelį duomenų atnaujinimą, nedidelė reprezentatyvi imtis turėtų būti perleista per naująją grandinę. Ekstrahavimas, valymas ir RAG fragmentavimas (chunking) iš pradžių lieka nepakitę. Jei komanda vienu metu keičia modelį, fragmentų ribas, metaduomenis ir rangavimą, vėliau pastebėtą kokybės skirtumą bus beveik neįmanoma paaiškinti.

Konfigūracija priklauso versijuojamam manifestui: modelis ir tiekėjas, dimensija, normalizavimas, atstumo metrika, paketo dydis (angl. batch size), kartojimo taisyklės, fragmentavimo versija, leidžiamos kalbos ir reikalingi metaduomenys. Prisijungimo duomenų čia griežtai neturi būti. Kiekvienam paketui išsaugomi tik ID, skaitikliai, būsena ir saugus klaidos kodas. Tai leidžia tęsti nutrūkusį procesą iš naujo nekartojant sėkmingai atliktų embedding procesų.

Kontroliuojamas naujų embeddings kūrimas ir išsamumo įrodymas

Reindeksavimas yra baigtas tik tada, kai esami duomenys tiksliai atitinka planuojamus. Vien tik didelio dokumentų skaičiaus neužtenka. Grandinė turėtų patikrinti kiekvienam šaltiniui, ar yra visi tikėtini fragmentai, ar jų teksto hash atitinka patvirtintą šaltinio versiją ir ar perkelti visi privalomi metaduomenys. Nepavykę įrašai perkeliami į ribotą kartojimo eilutę; ilgalaikės klaidos lieka matomos su savo ID ir negali pradingti po žalia bendra būsena.

1. Užfiksuoti arba aiškiai pažymėti šaltinių būseną ir versijos datą.
2. Sukurti naują indekso struktūrą su atitinkama dimensija ir metrika.
3. Generuoti fragmentų embeddings ir įrašyti ribotais, idempotentiškais paketai.
4. Palyginti dokumentų, fragmentų ir metaduomenų skaičių su planuojama būsena.
5. Patikrinti imtį pagal teksto hash, šaltinio ID ir pasiekiamą turinį.

Paieškos palyginimas naudojant identiškus klausimus

Dabar tie patys testiniai klausimai teikiami abiem indeksams. Be tikslumo rodiklio ir pozicijos sąraše, komanda turėtų palyginti faktiškai grąžintus šaltinius. Ar naujas indeksas iškėlė semantiškai panašias, bet techniškai klaidingas atskaitas? Ar neprarandami tikslūs produktų kodai? Ar geriau randami lietuviški sudurtiniai žodžiai arba keliomis kalbomis pateikti klausimai? Jau turima hibridinės paieškos ir reranking koncepcija turi būti sukonfigūruota identiškai abiem kandidatams, kad palyginimas būtų sąžiningas.

Microsoft dokumentacijoje apie vektorių aktualumą ir rangavimą minima išsami k-artimiausių kaimynų (kNN) paieška kaip galimybė sukurti etaloninį rinkinį (angl. ground truth) apytikslio ANN metodo įvertinimui. Tai nėra universalus slenkstis, bet naudingas kontrolinis testas: iš pradžių tiksli atskaita, paskui greitesnė gamybinė paieška. Pokalbių botui papildomai svarbu, ar rasti šaltiniai leidžia pateikti teisingą ir pagristą atsakymą.

Tikrinkite ne tik paieškos rezultatus, bet ir galutinį atsakymą

Geresnė paieškos pozicija negarantuoja geresnio pokalbių boto atsakymo. Todėl palyginimas taip pat turėtų apimti nuorodas į šaltinius, išsamumą, leistiną neapibrėžtumą ir saugų nutraukimą, kai įrodymų nepakanka. Atsakymo modelis, sisteminė instrukcija ir temperatūra turėtų likti kuo stabilesni. Priešingu atveju testas matuos kelis pakeitimus vienu metu.

Šešėlinės užklausos (Shadow Reads) prieš tikrąjį perjungimą

Po atjungties (offline) testo nedidelė dalis tikrų, privatumą tausojančių užklausų gali būti papildomai nukreipta į naująjį indeksą, nerodant jo rezultatų vartotojams. Šis šešėlinis skaitymas matuoja realią kalbą, delsą ir elgseną, kai rezultatų nerandama. Privatus turinys, asmens duomenys ir visi pokalbių įrašai neturėtų patekti į palyginimo žurnalus nepatikrinti. Dažniausiai pakanka pseudonimizuotų užklausų kategorijų, rezultatų ID ir techninių matavimų.

Pats perjungimas (angl. cutover) yra nedidelis, aiškiai stebimas pakeitimas: alias, maršrutizatoriaus tikslas arba funkcijos vėliavėlė (angl. feature flag) pasikeičia iš indekso A į indeksą B. Pirmuoju etapu taikomos griežtesnės aliarmo ribos trūkstamiems šaltiniams, paieškos klaidoms, delsimui ir perdavimo žmogui rodikliui. Dalaus perjungimo etapas yra naudingas, jei architektūra jį palaiko be sumaišytų seanso būsenų.

Praktiškai išbandykite atstatymą (Rollback) prieš perjungimą

Atstatymo planas yra patikimas tik tada, jei senasis indeksas išlieka pakankamai atnaujintas ir grąžinimo kelias buvo išbandytas. Lygiagretaus etapo metu nauji arba pakeisti šaltiniai turėtų būti kontroliuojamai nukreipiami į abejas grandines. Alternatyviai komanda fiksuoja trumpą pakeitimų sustabdymą ir aiškų vėlesnį atnaujinimą. Turimas gidas apie reagavimą į incidentus ir atstatymą padeda nustatyti priežastis ir atsakomybes.

Tipiški atstatymo signalai yra ne tik techninės klaidos. Ryškus svarbių top-k rezultatų sumažėjimas, naujos kalbinės spragos, neįprastai daug neatsakytų klausimų arba netinkamai pritaikyti prieigos filtrai taip pat pateisina grįžimą prie senos versijos. Senasis indeksas pašalinamas tik pasibaigus stebėjimo laikotarpiui, dokumentavus ištrynimo patvirtinimą ir nelikus neišaiškintų kokybės skirtumų.

Dažnos klaidų priežastys migruojant embeddings

• Keičiama tik užklausų pusė: Nauji klausimų vektoriai lyginami su sena dokumentų erdve.
• Sutampanti dimensija maišoma su suderinamumu: Skaičių ilgis ir semantinė erdvė nėra tas pats.
• Keičiami keli kintamieji vienu metu: Modelis, fragmentavimas ir rangavimas keičiami kartu; poveikio priežastis lieka neaiški.
• Vertinami tik vidurkiai: Reti, verslui kritiškai svarbūs ir daugiakalbiai klausimai pradingsta vidutinėse vertėse.
• Per ankstyvas valymas: Senas indeksas ištrinamas prieš tai, kai reali apkrova ir kokybės duomenys parodo stabilų veikimą.
• Pamiršti filtrai: Kalba, versija ir prieigos teisės naujajame indekse negalioja tiksliai taip, kaip senajame.

Praktinis kontrolinis sąrašas svetainių komandoms

• Tikslas, pradinė būsena, priėmimo kriterijai, atsakingas asmuo ir atstatymo signalas yra dokumentuoti.
• Senas ir naujas indeksai lieka atskirti; modelis, dimensija ir metrika yra aiškiai versijuoti.
• Abu indeksai sukurti iš tos pačios patvirtintos šaltinių ir fragmentų versijos.
• Procesas yra idempotentiškas, atkuriamas ir patikrintas pagal planuojamą kiekį.
• „Golden Set“, svarbūs klausimai, kalbos, atvejai be rezultatų ir prieigos filtrai praeina palyginimą.
• Šešėlinės užklausos fiksuoja tik būtinus techninius duomenis.
• Perjungimas ir atstatymas yra nedideli, stebimi ir praktiškai išbandyti.
• Senieji duomenys ištrinami tik po stebėjimo laikotarpio ir dokumentuoto patvirtinimo.

Išvada: naujai vektorių erdvei reikia atskiro leidimo (release) proceso

RAG embeddings keitimas yra duomenų ir kokybės migracija, o ne paprastas modelio jungiklis. Tie, kurie kuria naują paieškos erdvę atskirai, atlieka visišką reindeksavimą, lygina su identiškais klausimais ir aktyvuoja per atšaukiamą perjungimo tašką, žymiai sumažina prastovų ir kokybės rizikas. Svetainių komandoms verta turėti trumpą, pakartotinai naudojamą procedūrą: išsaugoti pradinę būseną, sukurti lygiagretų indeksą, patikrinti paiešką ir atsakymus, stebėti šešėlinius duomenis, kontroliuojamai perjungti ir palikti atvirą kelį atgal.

Jei jūsų DI pokalbių botas jau naudoja RAG žinių bazę, pradėkite ne nuo migracijos, o nuo testavimo duomenų rinkinio. Dešimt–dvišimties ypač svarbių klausimų kategorijų, papildytų sudėtingais kalbos, produktų ir teisių atvejais, padarys skirtumą tarp plausible modelio keitimo ir įrodomai saugaus išleidimo.

Šaltiniai

• Microsoft Learn: Create a vector index in Azure AI Search
• Microsoft Learn: Configure a vectorizer in Azure AI Search
• Microsoft Learn: Relevance in vector search
• Weaviate Documentation: Switching vectorizers