Zmena RAG-embeddingového modelu: Migrácia AI chatbota bez medzier v znalostiach

Embeddingový model funguje väčšinou neviditeľne na pozadí RAG chatbota. Prekladá otázky a znalostné prvky do číselných vektorov, aby bolo možné nájsť sémanticky vhodné odpovede. Práve preto, že sa táto časť zriedkavo objavuje v používateľskom rozhraní, sa výmena modelu môže zdať ako drobná zmena konfigurácie. Technicky však vzniká úplne nový vyhľadávací priestor. Existujúce dokumentové vektory, vektory nových otázok a definícia indexu musia opäť navzájom ladiť.

Ak chcete zmeniť RAG-embeddings, nemali by ste jednoducho vymeniť názov modelu v query pipeline. Bezpečná zmena pristupuje k novému indexu ako k samostatnej verzii: je reprodukovateľne vytvorený, overený na rovnakých testovacích otázkach, najprv prevádzkovaný paralelne a aktivovaný až po vedomom rozhodnutí o schválení. Takto zostane webový chatbot dostupný, zatiaľ čo tím má kvalitu, čas odozvy, náklady aj cestu späť pod kontrolou.

Prečo nie je možné embeddings ľubovoľne zamieňať

Vektor má zmysel len v rámci priestoru, v ktorom bol vytvorený. Oficiálna dokumentácia k Azure AI Search k vytvoreniu vektorového indexu popisuje index ako embeddingový priestor pozostávajúci z vektorov rovnakého modelu. Okrem toho upozorňuje, že dimenzia každého vektora musí zodpovedať definícii poľa. Nový model môže mať inú dimenziu, iné jazykové prednosti alebo iné rozloženie sémantických vzdialeností.

Rovnako dôležitá je aj strana dopytov (queries). Podľa dokumentácie Microsoftu ku konfigurácii vectorizera musia indexovanie a vyhľadávanie používať rovnaký embeddingový model. Ak tím zmieša staré dokumentové vektory s otázkami z nového modelu, skóre podobnosti už nie je možné spoľahlivo interpretovať. Ani prípadná náhodná zhoda dimenzií nedokazuje sémantickú kompatibilitu.

Pred zmenou definujte merateľný cieľ

„Novší“ nie je dostatočné kritérium pre prebratie. Pred prvým reindexovaním potrebuje tím konkrétny dôvod na migráciu. Má sa zvýšiť kvalita výsledkov v odbornej terminológii? Sú potrebné ďalšie jazyky? Je dosiaľ používaný model zastaraný, príliš pomalý alebo drahý? Alebo má menšia vektorová dimenzia ušetriť pamäť? Z cieľa potom vychádzajú porovnávacie metriky.

• Kvalita: relevantné zdroje v Top-k, podiel zodpovedateľných otázok a kvalita finálnej odpovede.
• Prevádzka: latencia vyhľadávania (retrieval), chybovosť, dĺžka indexovania a správanie pri čiastočných chybách.
• Náklady: vytvorenie embeddings pre celý obsah, priebežné zmeny, úložisko a dopyty.
• Pokrytie: dokumenty, jazyky, verzie produktov a oblasti oprávnení v novom indexe.

Východiskové hodnoty patria do rovnakej správy z testovania ako výsledky kandidátskeho modelu. Tímy, ktoré už na tento účel spravujú Golden Set, môžu použiť ako základ návod na meranie kvality odpovedí AI chatbota. Dôležité je neporovnávať len priemerné skóre: kritické otázky podpory, zriedkavé odborné výrazy a prípady bez výsledkov (No-Result) si zaslúžia samostatné vyhodnotenie.

Dva indexy namiesto zásahov na živom systéme

Robiť veci robustne znamená použiť paralelný index. Pôvodný index zostáva nezmenený a obsluhuje živú prevádzku. Vedľa neho vzniká nová kolekcia alebo nový index s vlastným označením modelu, dimenziou, metrikou vzdialenosti a číslom verzie. Oba sa zostavujú z rovnakej schválenej zdrojovej verzie. Vďaka tomu možno prípadné rozdiely pripísať modelu alebo konfigurácii indexu, namiesto porovnávania neustále sa meniaceho obsahu.

Oficiálny návod Weaviate na zmenu vectorizera ukazuje použitie oddelených kolekcií a aliasu ako reverzibilného bodu prepnutia. Konkrétny produkt sa môže líšiť, no princíp zostáva rovnaký: čisto izolovať staré a nové embeddings, spravovať prístup cez kontrolovaný smerovač (router) alebo alias a starý stav si ponechať po obmedzený čas pre prípadný návrat.

Stabilné identity pre každý znalostný prvok

Každý chunk potrebuje stabilné funkčné ID, ktoré nezávisí od vektora. Vhodná je kombinácia ID zdroja, verzie zdroja, sekcie a verzie chunku. Okrem toho by mal každý záznam obsahovať názov modelu, verziu modelu, dimenziu, čas vytvorenia a hash embedovaného textu. Pipeline tak dokáže presne rozpoznať, čo už bolo spracované, čo treba znova embedovať a ktoré chyby ešte zostávajú otvorené.

Reprodukovateľné ukotvenie novej pipeline

Pred veľkým plným reindexovaním (backfill) by mal cez novú pipeline prejsť malý reprezentatívny vzor údajov. Extrakcia, čistenie a RAG chunking zostávajú nateraz nezmenené. Ak tím súčasne zmení model, hranice chunkov, metadáta aj ranking, neskoršie rozdiely v kvalite sa budú dať len ťažko vysvetliť.

Konfigurácia patrí do verzovaného manifestu spojeného s daným spustením: model a poskytovateľ, dimenzia, normalizácia, metrika vzdialenosti, veľkosť dávky (batch size), pravidlá pre opakované pokusy, verzia chunkeru, povolené jazyky a potrebné metadáta. Prihlasovacie údaje tam jednoznačne nepatria. Pre každú dávku sa ukladajú iba ID, počítadlá, stav a bezpečný chybový kód. Prerušený beh tak možno obnoviť bez toho, aby sa museli nákladne opakovať už úspešné vytvorenia embeddings.

Kontrolované opätovné embedovanie a dôkaz úplnosti

Reindexovanie je úplné až vtedy, keď sa cieľový a skutočný stav zhodujú. Samotný vysoký počet dokumentov nestačí. Pipeline by mala pre každý zdroj overiť, či sú prítomné všetky očakávané chunky, či ich textové hashe zodpovedajú schválenej zdrojovej verzii a či boli prevzaté všetky povinné metadáta. Záznamy, ktoré zlyhali, idú do obmedzenej fronty na opakovanie; trvalé chyby zostávajú viditeľné so svojím ID a nesmú zmiznúť za celkovým zeleným stavom.

1. Zmraziť alebo jednoznačne označiť zdrojový stav a rozhodujúci dátum verzie.
2. Vytvoriť novú štruktúru indexu so zodpovedajúcou dimenziou a metrikou.
3. Embedovať a zapísať chunky v obmedzených, idempotentných dávkach.
4. Porovnať počty dokumentov, chunkov a metadát voči cieľovému stavu.
5. Skontrolovať vzorku na základe textového hashu, ID zdroja a dostupného obsahu.

Porovnanie vyhľadávania (retrieval) pomocou rovnakých otázok

Teraz sa rovnaké testovacie otázky spustia voči obom indexom. Okrem miery úspešnosti a pozície výsledkov by mal tím porovnať skutočne vrátené zdroje. Posunul nový index nahor úseky, ktoré sú sémanticky podobné, ale odborne nesprávne? Stratil presné kódy produktov? Dajú sa lepšie nájsť zložené slová alebo viacjazyčné otázky? Existujúca koncepcia hybridného vyhľadávania a rerankingu musí byť pre oba kandidátske indexy nakonfigurovaná identicky, aby bolo porovnanie férové.

V dokumentácii Azure o relevantnosti a rankingu vektorov sa spomína vyčerpávajúce vyhľadávanie k-nearest-neighbor ako možnosť na vytvorenie referenčnej množiny (ground truth) pre vyhodnotenie výťažnosti (recall) približnej metódy ANN. Nie je to univerzálny prah, ale užitočný kontrolný test: najprv presná referencia, potom rýchlejšie produkčné vyhľadávanie. Pre chatbota je navyše rozhodujúce, či nájdené zdroje umožňujú vytvoriť správnu a doloženú odpoveď.

Kontrolujte nie len výsledky vyhľadávania, ale finálnu odpoveď

Lepšie poradie vo vyhľadávaní ešte nezaručuje lepšiu odpoveď chatbota. Porovnanie by preto malo zahŕňať aj nadväznosť na zdroje, úplnosť, prípustnú miera neistoty a bezpečné prerušenie pri nedostatočných podkladoch. Generatívny model, systémové inštrukcie a teplota (temperature) musia pritom zostať čo najviac konštantné. Inak bude test merať viacero zmien naraz.

Shadow Reads pred reálnym prepnutím (cutover)

Po offline testovaní môže malá časť reálnych, z hľadiska ochrany údajov úsporne spracovaných vyhľadávacích dopytov bežať paralelne aj voči novému indexu bez toho, aby sa ich výsledok zobrazoval používateľom. Tento „Shadow Read“ meria reálny jazyk, latenciu a správanie pri dopytoch bez výsledku. Súkromný obsah, osobné údaje a kompletné histórie konverzácií do porovnávacích logov bez kontroly nepatria. Často postačujú pseudonymizované kategórie dopytov, ID výsledkov a technické metriky.

Samiotné prepnutie (cutover) je malá, jasne sledovateľná zmena: alias, cieľ routera alebo feature flag sa preklopí z indexu A na index B. Počas prvej fázy platia prísnejšie limity pre alarmy na chýbajúce zdroje, chyby vyhľadávania, latenciu a mieru odovzdania živému operátorovi (handoff). Postupné preklápanie trafiku má zmysel vtedy, ak ho architektúra podporuje bez zmiešania stavov relácií (sessions).

Pred prepnutím si prakticky vyskúšajte rollback

Plán návratu (rollback) je spoľahlivý len vtedy, ak je starý index stále dostatočne aktuálny a postup návratu bol otestovaný. Počas paralelnej fázy by preto mali nové alebo zmenené zdroje kontrolovane prúdiť do oboch pipelines. Alternatívne tím zdokumentuje krátke pozastavenie zmien a následné presné dopĺňanie. Existujúci sprievodca pre incident response a rollback pomôže definovať spúšťače a zodpovednosti.

Typickými signálmi pre návrat nie sú len technické chyby. Návrat ospravedlňuje aj výrazný pokles relevantných Top-k výsledkov, nové medzery v jazykovom pokrytí, neobvykle vysoký počet nezodpovedaných otázok alebo nesprávne aplikované prístupové filtre. Starý index sa odstráni až vtedy, keď skončí obdobie pozorovania, je zdokumentované schválenie na vymazanie a nezostali žiadne neobjasnené rozdiely v kvalite.

Časté chyby pri migrácii embeddings

• Zmena len na strane dopytu (query): Nové vektory otázok sa porovnávajú so starým priestorom dokumentov.
• Zámieňa rovnakej dimenzie za kompatibilitu: Dĺžka číselného reťazca a sémantický priestor nie sú to isté.
• Menenie viacerých premenných naraz: Model, chunking aj ranking sa menia súčasne; príčina výsledného efektu zostáva nejasná.
• Sledovanie len priemerných hodnôt: Zriedkavé, pre podnikanie kritické a viacjazyčné otázky v priemernej hodnote zaniknú.
• Príliš skoré čistenie: Starý index sa vymaže skôr, než reálna záťaž a dáta o kvalite potvrdia stabilnú prevádzku.
• Zabudnuté filtre: Jazyk, verzia a prístupové práva nenefungujú v novom indexe presne tak ako v starom.

Praktická kontrolná lišta pre webové tímy

• Cieľ, východiskový stav, kritériá prebratia, schvaľujúca osoba a signál na rollback sú zdokumentované.
• Starý a nový index zostávajú oddelené; model, dimenzia a metrika sú jednoznačne verzované.
• Oba indexy pochádzajú z rovnakej schválenej verzie zdrojov a chunkov.
• Backfill je idempotentný, obnoviteľný a skontrolovaný voči cieľovému stavu.
• Golden Set, kritické otázky, jazyky, prípady bez výsledku a prístupové filtre úspešne prešli porovnaním.
• Shadow Reads zaznamenávajú iba nevyhnutné technické údaje.
• Prepnutie (cutover) aj návrat sú malé, sledovateľné a prakticky otestované kroky.
• Starý stav sa vymaže až po uplynutí obdobia pozorovania a zdokumentovanom schválení.

Záver: Nový vektorový priestor vyžaduje vlastný proces vydávania (release)

Zmena RAG-embeddings je dátová migrácia a migrácia kvality, nie iba jednoduché prepnutie modelu. Kto nový vyhľadávací priestor buduje oddelene, kompletne znova embeduje, porovnáva s rovnakými otázkami a aktivuje ho cez reverzibilný bod prepnutia, výrazne znižuje riziko výpadkov a straty kvality. Pre webové tímy sa vyplatí krátky, opakovane použiteľný postup (runbook): zaistiť baseline, vytvoriť paralelný index, skontrolovať vyhľadávanie a odpovede, sledovať shadow dáta, kontrolovane prepnúť a nechať otvorenú cestu späť.

Ak váš AI chatbot už využíva bázu znalostí RAG, nezačínajte migráciu samotným modelom, ale testovacími dátami. Desať až dvadsať obzvlášť dôležitých kategórií otázok, doplnených o náročné jazykové, produktové a prístupové prípady, spraví rozdiel medzi zdanlivo fungujúcou zmenou modelu a preukázateľne bezpečným vydaním do prevádzky.

Zdroje

• 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