RAG iegulšanas modeļa maiņa: AI tērzēšanas botu migrācija bez zināšanu robiem

Iegulšanas (embedding) modelis visbiežāk darbojas neredzami RAG tērzēšanas bota fonā. Tas pārvērš jautājumus un zināšanu fragmentus skaitļu vektoros, lai varētu atrast semantiski atbilstošu saturu. Tā kā šī daļa reti parādās lietotāja saskarnē, modeļa maiņa pirmajā acu uzmetienā šķiet kā neliela konfigurācijas pielāgošana. Tomēr tehniski tiek izveidota pilnīgi jauna meklēšanas telpa. Esošajiem dokumentu vektoriem, jauno jautājumu vektoriem un indeksa definīcijai atkal ir savstarpēji jāatbilst.

Ikvienam, kurš vēlas mainīt RAG iegulšanas, nevajadzētu vienkārši aizstāt modeļa nosaukumu vaicājumu apstrādes ķēdē. Droša maiņa pret jauno indeksu izturas kā pret patstāvīgu versiju: tā tiek izveidota reproducējami, pārbaudīta ar tiem pašiem testa jautājumiem, sākotnēji darbināta paralēli un aktivizēta tikai pēc apzināta apstiprinājuma lēmuma. Tādējādi tīmekļa vietnes tērzēšanas bots paliek pieejams, kamēr komanda saglabā kontroli pār kvalitāti, izpildes laiku, izmaksām un atpakaļceļa iespējām.

Kāpēc iegulšanas nav patvaļīgi aizstājamas

Vektors ir jēgpilns tikai tajā telpā, kurā tas ir ģenerēts. Oficiālā Azure AI Search dokumentācija par vektoru indeksa izveidi raksturo indeksu kā tā paša modeļa vektoru iegulšanas telpu. Tā arī norāda, ka katra vektora dimensijai ir jāatbilst lauka definīcijai. Jaunam modelim var būt cita dimensija, cita valodu spēja vai citāds semantisko attālumu sadalījums.

Tikpat svarīga ir vaicājumu puse. Saskaņā ar Microsoft dokumentāciju par Vectorizer konfigurāciju indeksēšanai un vaicāšanai ir jāizmanto viens un tas pats iegulšanas modelis. Ja komanda sajauc vecos dokumentu vektorus ar jautājumiem no jauna modeļa, līdzības rādītāji (scores) vairs nav droši interpretējami. Pat ja dimensijas nejauši sakrīt, tas nepierāda semantisko savietojamību.

Pirms maiņas definējiet mērāmu mērķi

„Jaunāks” nav pietiekams pieņemšanas kritērijs. Pirms pirmās pārindeksēšanas komandai ir nepieciešams konkrēts iemesls migrācijai. Vai nepieciešams uzlabot meklēšanas kvalitāti nozares terminoloģijā? Vai ir nepieciešamas papildu valodas? Vai iepriekšējā modeļa atbalsts ir pārtraukts, tas ir pārāk lēns vai pārāk dārgs? Jeb vai mazāka vektoru dimensija palīdzēs ietaupīt atmiņas resursus? No mērķa izriet salīdzināmās metrikas.

• Kvalitāte: relevanti avoti starp Top-k rezultātiem, atbildamo jautājumu īpatsvars un galīgās atbildes kvalitāte.
• Veiktspēja un darbība: meklēšanas latentums, kļūdu līmenis, indeksēšanas ilgums un uzvedība daļēju kļūmju gadījumā.
• Izmaksas: visa dokumentu apjoma iegulšana, kārtējās izmaiņas, atmiņa un vaicājumi.
• Pārklājums: dokumenti, valodas, produktu versijas un piekļuves tiesību zonas jaunajā indeksā.

Sākotnējās vērtības ir jāiekļauj tajā pašā pārbaudes ziņojumā, kur kandidāta rezultāti. Ja komanda šim nolūkam jau uztur Golden Set, par pamatu var izmantot esošo pamācību par AI tērzēšanas bota atbilžu kvalitātes mērīšanu. Svarīgi ir nesalīdzināt tikai vidējo rādītāju: kritiski atbalsta jautājumi, reti lietoti nozares meklējumi un gadījumi bez rezultātiem ir pelnījuši atsevišķu izvērtēšanu.

Divi indeksi, nevis izmaiņas strādājošā sistēmā

Izturīgs standarts ir paralēlais indekss. Iepriekšējais indekss paliek nemainīts un apkalpo reālo lietotāju plūsmu. Līdzās tiek izveidota jauna kolekcija vai indekss ar savu modeļa identifikatoru, dimensiju, attāluma metriku un versijas numuru. Abi tiek izveidoti no tās pašas apstiprinātās avota versijas. Tādējādi atšķirības var attiecināt uz modeli vai indeksa konfigurāciju, nevis salīdzināt vienlaikus mainīgu saturu.

Oficiālā Weaviate pamācība par Vectorizer maiņu šim nolūkam parāda atsevišķas kolekcijas un aizstājējvārdu (alias) kā atgriezenisku pārslēgšanas punktu. Konkrētais produkts var atšķirties, taču princips paliek nemainīgi vērtīgs: tīri izolēt vecās un jaunās iegulšanas, nodrošināt piekļuvi caur kontrolētu maršrutētāju vai alias, kā arī saglabāt veco stāvokli ierobežotā atpakaļsoļošanas (rollback) periodā.

Stabilas identifikācijas katram zināšanu fragmentam

Katram fragmentam (chunk) ir nepieciešams stabils biznesa ID, kas nav atkarīgs no vektora. Lietderīga ir kombinācija no avota ID, avota versijas, sadaļas un fragmenta versijas. Papildus katram datu ierakstam vajadzētu saturēt modeļa nosaukumu, modeļa versiju, dimensiju, izveides laiku un iegultā teksta jauktās vērtības kodu (hash). Tādējādi apstrādes ķēde var precīzi noteikt, kas jau ir apstrādāts, kas jāiegulst no jauna un kuras kļūdas vēl ir atvērtas.

Reproducējama jaunās apstrādes ķēdes nostiprināšana

Pirms lielās datu pārrēķināšanas caur jauno apstrādes ķēdi ir jāizlaiž neliela, reprezentatīva datu kopa. Datu ieguve, tīrīšana un RAG fragmentēšana (chunking) sākotnēji paliek nemainīta. Ja komanda vienlaikus maina modeli, fragmentu robežas, metadatus un sarindošanu (ranking), vēlākās kvalitātes atšķirības būs gandrīz neiespējami izskaidrot.

Konfigurācijai kā versionētam manifestam jābūt pievienotai izpildes procesam: modelis un nodrošinātājs, dimensija, normalizācija, attāluma metrika, pakešu (batch) lielums, atkārtošanas noteikumi, fragmentētāja versija, atļautās valodas un nepieciešamie metadati. Piekļuves datiem tur kategoriski nevajadzētu atrasties. Katrai paketei tiek saglabāti tikai ID, skaitītāji, statuss un drošs kļūdas kods. Tas ļauj atsākt pārtrauktu izpildi, atkārtoti netērējot resursus jau veiksmīgi izveidotajām iegulšanām.

Kontrolēta atkārtota iegulšana un pilnīguma pierādīšana

Pārindeksēšana ir pabeigta tikai tad, kad plānotais un faktiskais datu apjoms pilnībā sakrīt. Ar lielu dokumentu skaits vien nepietiek. Apstrādes ķēdei katram avotam ir jāpārbauda, vai visi paredzētie fragmenti ir pieejami, vai to teksta jauktās vērtības kodi atbilst apstiprinātajai avota versijai un vai visi obligātie metadati ir pārņemti. Neveiksmīgie datu ieraksti tiek pārvietoti uz ierobežotu atkārtošanas rindkopu; pastāvīgās kļūdas paliek redzamas kopā ar to ID un nedrīkst pazust aiz zaļa kopējā statusa.

1. Nostiprināt vai skaidri atzīmēt avotu stāvokli un versijas laika zīmogu.
2. Izveidot jaunu indeksa struktūru ar atbilstošu dimensiju un metriku.
3. Iegult un ierakstīt fragmentus ierobežotās, idempotentās paketēs.
4. Salīdzināt dokumentu, fragmentu un metadatu skaitu ar plānoto stāvokli.
5. Pārbaudīt izlasi, izmantojot teksta jauktās vērtības kodu, avota ID un pieejamo saturu.

Meklēšanas rezultātu salīdzināšana ar identiskiem jautājumiem

Tagad tie paši testa jautājumi tiek palaisti pret abiem indeksiem. Papildus precizitātei un pozīcijai sarakstā komandai ir jāsalīdzina faktiski atgrieztie avoti. Vai jaunais indekss ir izvirzījis augstāk semantiski līdzīgas, bet pēc būtības nepareizas sadaļas? Vai tas nezaudē precīzus produktu kodus? Vai labāk tiek atrasti salikti vārdi vai daudzvalodu jautājumi? Esošajai hibrīdās meklēšanas un pārsarindošanas (reranking) koncepcijai jābūt konfigurētai identiski abiem kandidātiem, lai salīdzinājums būtiski godīgs.

Azure dokumentācija par vektoru relevanci un sarindošanu min izsmeļošu k-tuvāko kaimiņu (k-nearest-neighbor) meklēšanu kā iespēju izveidot patiesās atbilstības (ground truth) kopu aptuvenās ANN metodes novērtēšanai. Tas nav universāls slieksnis, bet gan noderīgs kontroles meklējums: vispirms precīza atsauce, pēctam ātrāka ražošanas meklēšana. Tērzēšanas botam papildus ir svarīgi, vai atrastie avoti nodrošina pareizu, pamatotu atbildi.

Pārbaudiet ne tikai atbilstības, bet arī galīgo atbildi

Labāka meklēšanas pozīcija vēl negarantē labāku tērzēšanas bota atbildi. Tāpēc salīdzinājumā jāiekļauj arī atsauce uz avotiem, pilnīgums, pieļaujamā nenoteiktība un droša darbības pārtraukšana nepietiekamu pierādījumu gadījumā. Tajā pašā laikā atbilžu modelim, sistēmas norādījumiem un temperatūras parametram jāpaliek pēc iespējas nemainīgiem. Pretējā gadījumā tests mērīs vairākas izmaiņas vienlaikus.

Ēnu nolasīšana (Shadow Reads) pirms reālās pārslēgšanas

Pēc bezsaistes testa nelielu daļu reālo, no datu aizsardzības viedokļa droši apstrādāto meklēšanas vaicājumu var papildus palaist pret jauno indeksu, neparādot tā rezultātus lietotājiem. Šī ēnu nolasīšana mēra reālo lietotāju valodu, latentumu un uzvedību situācijās, kad rezultāti netiek atrasti. Privāts saturs, personas dati un pilnas sarunu vēstures nedrīkst nekontrolēti nonākt salīdzināšanas žurnālos. Bieži vien pietiek ar pseidonimizētām vaicājumu klasēm, rezultātu ID un tehniskajām metrikām.

Pats pārslēgšanas brīdis (cutover) ir neliela, skaidri novērojama izmaiņa: alias, maršrutētāja mērķis vai funkcijas karogs (feature flag) pārslēdzas no indeksa A uz indeksu B. Pirmajā fāzē spēkā ir stingrākas trauksmes robežas attiecībā uz trūkstošiem avotiem, meklēšanas kļūdām, latentumu un nodošanas operatoram (handoff) rādītājiem. Pakāpeniska pārslēgšana ir lietderīga, ja arhitektūra to atbalsta bez jauktiem sesiju stāvokļiem.

Atpakaļsoļošanas praktiska testēšana pirms pārslēgšanas

Atpakaļsoļošanas plāns ir uzticams tikai tad, ja vecais indekss joprojām ir pietiekami atjaunināts un atpakaļpārslēgšanas ceļš ir praktiski pārbaudīts. Tāpēc paralēlās fāzes laikā jaunajiem vai izmainītajiem avotiem kontrolēti jāplūst uz abām apstrādes ķēdēm. Vai arī komanda dokumentē īslaicīgu izmaiņu apturēšanu un skaidru vēlāku sinhronizāciju. Esošā pamācība par incidentu novēršanu un atpakaļsoļošanu palīdz noteikti sprūda nosacījumus un atbildības.

Tipiski atpakaļsoļošanas signāli ir ne tikai tehniskas kļūdas. Arī būtisks kritums svarīgos Top-k meklēšanas rezultātos, jauni robi valodu atbalstā, neparasti liels neatbildēto jautājumu skaits vai nepareizi piemēroti piekļuves filtri attaisno atgriešanos. Vecais indekss tiek dzēsts tikai tad, kad novērošanas periods ir beidzies, dzēšanas apstiprinājums ir dokumentēts un vairs nav neatrisinātu kvalitātes atšķirību.

Biežākās kļūdas iegulšanas migrācijā

• Tikai vaicājuma puses maiņa: Jauni jautājumu vektori tiek salīdzināti ar veco dokumentu telpu.
• Vienādas dimensijas sajaukšana ar savietojamību: Skaitļu garums un semantiskā telpa nav viens un tas pats.
• Vairāku mainīgo lielumu mainīšana vienlaikus: Modelis, fragmentēšana un sarindošana mainās reizē; efekta cēlonis paliek neskaidrs.
• Tikai vidējo vērtību analīze: Reti, biznesam kritiski un daudzvalodu jautājumi pazūd vidējā rādītājā.
• Pārāk agra vecā indeksa dzēšana: Vecais indekss tiek izdzēsts, pirms reālā slodze un kvalitātes dati apliecina stabilu darbību.
• Aizmirsti filtri: Valoda, versija un piekļuves tiesības jaunajā indeksā nedarbojas precīzi tāpat kā vecajā.

Praktisks kontrolsaraksts tīmekļa vietņu komandām

• Mērķis, bāzes līnija, pieņemšanas kritēriji, atbildīgā persona un atpakaļsoļošanas signāls ir dokumentēti.
• Vecais un jaunais indekss paliek nošķirti; modelis, dimensija un metrika ir skaidri versionēti.
• Abi indeksi ir izveidoti no tās pašas apstiprinātās avotu un fragmentu versijas.
• Atkārtotā aizpildīšana (backfill) ir idempotenta, atsākama un pārbaudīta pret plānoto stāvokli.
• Golden Set, kritiski jautājumi, valodas, bezrezultātu gadījumi un piekļuves filtri veiksmīgi iztur salīdzinājumu.
• Ēnu nolasīšana protokolē tikai nepieciešamos tehniskos datus.
• Pārslēgšana un atpakaļpārslēgšana ir nelielas, novērojamas un praktiski pārbaudītas darbības.
• Vecais saturs tiek izdzēsts tikai pēc novērošanas perioda un dokumentēta apstiprinājuma.

Secinājums: Jaunajai vektoru telpai ir nepieciešams savs laidiena process

RAG iegulšanas maiņa ir datu un kvalitātes migrācija, nevis vienkārša modeļa pārslēgšana. Komanda, kas jauno meklēšanas telpu izveido atsevišķi, pilnībā no jauna iegulst datus, salīdzina tos ar identiskiem jautājumiem un aktivizē ar atgriezeniska pārslēgšanas punkta palīdzību, būtiski samazina dīkstāves un kvalitātes riskus. Tīmekļa vietņu komandām ir vērts ieviest īsu, atkārtoti izmantojamu instrukcijas procesu: fiksēt bāzes līniju, izveidot paralēlo indeksu, pārbaudīt meklēšanu un atbildes, novērot ēnu datus, kontrolēti pārslēgties un saglabāt atpakaļceļa iespēju.

Ja jūsu AI tērzēšanas bots jau izmanto RAG zināšanu bāzi, nesāciet migrāciju ar koda izmaiņām, bet gan ar pārbaudes datu kopu. Desmit līdz divdesmit īpaši svarīgas jautājumu klases, kas papildinātas ar sarežģītiem valodu, produktu un piekļuves tiesību gadījumiem, veido atšķirību starp šķietami ticamu modeļa maiņu un pierādāmi drošu laidienu.

Avoti

• 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