Změna RAG embedding modelu: Migrace AI chatbota bez výpadků znalostí

Embeddingový model funguje většinou neviditelně na pozadí RAG chatbota. Překládá dotazy a znalostní bloky do číselných vektorů, aby bylo možné najít sémanticky odpovídající obsah. Právě proto, že se tato část zřídka objevuje v uživatelském rozhraní, může změna modelu působit jako drobná úprava konfigurace. Technicky vzato však vzniká zcela nový vyhledávací prostor. Stávající dokumentové vektory, vektory nových dotazů a definice indexu musejí k sobě opět přesně pasovat.

Pokud chcete změnit RAG embeddings, neměli byste jednoduše vyměnit název modelu v query pipeline. Bezpečná změna přistupuje k novému indexu jako k samostatné verzi: je vytvořen reprodukovatelně, otestován na stejných testovacích dotazech, zpočátku provozován paralelně a aktivován až po vědomém schválení. Díky tomu zůstává webový chatbot neustále dostupný, zatímco tým drží kvalitu, dobu odezvy, náklady i cestu zpět plně pod kontrolou.

Proč embeddings nelze libovolně zaměňovat

Vektor má smysl pouze v rámci prostoru, ve kterém byl vytvořen. Oficiální dokumentace Azure AI Search pro vytvoření vektorového indexu popisuje index jako embeddingový prostor složený z vektorů téhož modelu. Dále upozorňuje, že dimenze každého vektoru musí odpovídat definici pole. Nový model může mít jinou dimenzi, odlišné jazykové silné stránky nebo jiné rozložení sémantických vzdáleností.

Stejně důležitá je strana dotazu. Podle dokumentace Microsoftu ke konfiguraci vectorizeru musí indexování i dotazování používat stejný embeddingový model. Pokud tým smíchá staré dokumentové vektory s dotazy z nového modelu, nelze skóre podobnosti spolehlivě interpretovat. Ani v případě, že je dimenze náhodou identická, to nezaručuje sémantickou kompatibilitu.

Před změnou definujte měřitelný cíl

Slovo „novější“ není dostatečným akceptačním kritériem. Před první reindexací potřebuje tým konkrétní důvod k migraci. Má se zvýšit kvalita vyhledávání v odborné terminologii? Jsou potřeba další jazyky? Je dosavadní model zastaralý, příliš pomalý nebo drahý? Nebo má menší dimenze vektorů ušetřit paměť? Z definovaného cíle pak vycházejí srovnávací metriky.

• Kvalita: relevantní zdroje v Top-k, podíl zodpověditelných dotazů a kvalita konečné odpovědi.
• Provoz: latence vyhledávání (retrieval), chybovost, doba indexace a chování při částečných selháních.
• Náklady: vytvoření embeddingů pro celý obsah, průběžné změny, úložiště a dotazy.
• Pokrytí: dokumenty, jazyky, verze produktů a přístupová oprávnění v novém indexu.

Výchozí hodnoty patří do stejné testovací zprávy jako výsledky nového kandidáta. Pokud k tomuto účelu již spravujete Golden Set, můžete použít stávající návod pro měření kvality odpovědí AI chatbota jako základ. Důležité je neporovnávat pouze průměrné skóre: kritické dotazy podpory, vzácné odborné výrazy a případy bez výsledků (no-result) si zaslouží samostatné vyhodnocení.

Dva indexy místo zásahu do živého systému

Spolehlivým standardem je paralelní index. Původní index zůstává nezměněn a obsluhuje živý provoz. Vedle něj vzniká nová kolekce nebo nový index s vlastní identifikací modelu, dimenzí, metrikou vzdálenosti a číslem verze. Oba se sestavují ze stejné schválené zdrojové verze. Díky tomu lze případné rozdíly připsat modelu nebo konfiguraci indexu, aniž by se zároveň porovnával měnící se obsah.

Oficiální návod Weaviate k přechodu na nový vectorizer k tomuto účelu využívá oddělené kolekce a alias jako vratný bod přepnutí. Konkrétní produkt je zaměnitelný, ale princip zůstává klíčový: staré a nové embeddings čistě izolovat, přístup řídit přes kontrolovaný router nebo alias a starý stav si ponechat po omezenou dobu pro případný rollback.

Stabilní identity pro každý znalostní blok

Každý chunk potřebuje stabilní doménové ID, které nezávisí na vektoru. Vhodná je kombinace ID zdroje, verze zdroje, sekce a verze chunku. Každý záznam by navíc měl nést název modelu, verzi modelu, dimenzi, čas vytvoření a hash vloženého textu. Zpracovatelská pipeline tak přesně pozná, co už bylo zpracováno, co je třeba znovu embeddedovat a které chyby zůstávají nevyřešeny.

Definujte novou pipeline reprodukovatelným způsobem

Před velkým reindexováním celého obsahu (backfill) by měl novou pipelinou projít malý reprezentativní vzorek. Extrakce, čistění textu i RAG chunking přitom zůstávají zpočátku nezměněny. Pokud tým současně změní model, hranice chunků, metadata i reranking, půjde následný rozdíl v kvalitě jen stěží vysvětlit.

Konfigurace patří jako verzovaný manifest k danému běhu: model a poskytovatel, dimenze, normalizace, metrika vzdálenosti, velikost batchů, pravidla pro opakování (retry), verze chunkeru, povolené jazyky a požadovaná metadata. Přístupové údaje do manifestu zásadně nepatří. Pro každý batch se ukládají pouze ID, čítače, stav a bezpečný kód chyby. Přerušený běh tak lze obnovit, aniž by se drahé úspěšné embeddingy musely opakovat.

Řízený re-embedding a důkaz úplnosti

Reindexace je kompletní teprve tehdy, když cílový a skutečný stav přesně souhlasí. Pouhý vysoký počet dokumentů nestačí. Pipeline by měla pro každý zdroj ověřit, zda jsou přítomny všechny očekávané chunky, zda jejich textové hashe odpovídají schválené verzi zdroje a zda byla převzata všechna povinná metadata. Neúspěšné záznamy putují do omezené fronty pro opakování; trvalé chyby zůstávají viditelné se svým ID a nesmějí zmizet pod falešným zeleným celkovým stavem.

1. Zmrazte nebo jednoznačně označte zdrojová data a rozhodné datum verze.
2. Vytvořte novou strukturu indexu s odpovídající dimenzí a metrikou.
3. Generateujte embeddings a zapisujte chunky v omezených, idempotentních dávkách (batches).
4. Porovnejte počty dokumentů, chunků a metadat s požadovaným cílovým stavem.
5. Zkontrolujte náhodný vzorek podle textového hashe, ID zdroje a načitatelného obsahu.

Porovnání vyhledávání na identických dotazech

Nyní se spouštějí stejné testovací dotazy proti oběma indexům. Vedle úspěšnosti vyhledávání (hit rate) a pozice v žebříčku by měl tým porovnat skutečně vrácené zdroje. Posunul nový index nahoru úseky, které jsou sice sémanticky podobné, ale věcně nesprávné? Neztrácí přesné kódy produktů? Nachází lépe složená slova nebo vícejazyčné dotazy? Stávající koncept hybridního vyhledávání a rerankingu musí být pro oba kandidáty nakonfigurován identicky, aby srovnání zůstalo spravedlivé.

Dokumentace k Azure ohledně vektorové relevanci a rankingu uvádí exaktní vyhledávání k-nejbližších sousedů (k-NN) jako možnost, jak vytvořit datovou sadu „Ground Truth“ pro vyhodnocení úspěšnosti (recall) přibližné metody ANN. Nejde o univerzální práh, ale o užitečný kontrolní test: nejprve přesná reference, pak rychlejší produkční vyhledávání. Pro chatbota hraje roli i to, zda nalezené zdroje umožňují sestavit správnou a doloženou odpověď.

Kontrolujte nejen vyhledané zdroje, ale i hotovou odpověď

Lepší pozice ve vyhledávání ještě nezaručuje lepší odpověď chatbota. Porovnání by proto mělo zahrnovat také odkazování na zdroje, úplnost, přípustnou míru nejistoty a bezpečné ukončení v případě nedostatečných podkladů. Generativní model odpovědí, systémové instrukce a teplota (temperature) přitom zůstávají co nejvíce konstantní. Jinak by test měřil více změn najednou.

Shadow reads před skutečným překlopením

Po offline testování lze malou část reálných dotazů (s ohledem na ochranu dat) paralelně posílat i proti novému indexu, aniž by se výsledek zobrazoval uživatelům. Tento „Shadow Read“ měří reálnou řeč, latenci a chování v případech bez nalezených výsledků. Soukromý obsah, osobní údaje a kompletní historie konverzací nepatří bez kontroly do srovnávacích logů. Často postačí pseudonymizované třídy dotazů, ID výsledků a technické metriky.

Samotné překlopení (cutover) je pak malou, jasně pozorovatelnou změnou: alias, cíl routeru nebo feature flag se přepne z indexu A na index B. Během první fáze platí přísnější limity pro alarmy ohledně chybějících zdrojů, chyb vyhledávání, latence a míry předání na živého operátora (handoff rate). Postupné překlopení po procentech dává smysl, pokud ho architektura podporuje bez míšení stavů relací.

Před přepnutím prakticky otestujte rollback

Plán pro návrat k předchozímu stavu (rollback) je spolehlivý pouze tehdy, pokud starý index zůstává dostatečně aktuální a cesta k opětovnému přepnutí byla otestována. Během paralelní fáze by proto nové nebo změněné zdroje měly řízeně proudit do obou pipelin. Alternativně může tým zdokumentovat krátké pozastavení změn obsahu a následné doindexování. Stávající průvodce pro incident response a rollback pomůže stanovit spouštěče a odpovědnosti.

Typické signály pro návrat zpět nejsou jen technické chyby. Významný pokles v relevantních Top-k nálezech, nové mezery v jazykové podpoře, neobvykle vysoký počet nezodpovězených dotazů nebo špatně aplikované přístupové filtry rovněž ospravedlňují návrat. Starý index se smaže až po uplynutí sledovacího období, zdokumentovaném schválení k vymazání a vyřešení všech nejasných rozdílů v kvalitě.

Časté chyby při migraci embeddingů

• Změna pouze na straně dotazu: Nové vektory dotazů se porovnávají se starým dokumentovým prostorem.
• Záměna stejné dimenze za kompatibilitu: Délka číselného pole a sémantický prostor nejsou totéž.
• Změna více proměnných současně: Model, chunking i reranking se mění najednou; příčina efektu zůstává nejasná.
• Sledování pouze průměrných hodnot: Vzácné, pro podnikání kritické a vícejazyčné dotazy se v průměru ztratí.
• Příliš brzký úklid: Starý index je smazán dříve, než reálná zátěž a data o kvalitě potvrdí stabilní provoz.
• Opomenutí filtrů: Jazyk, verze a přístupová práva neplatí v novém indexu přesně tak jako ve starém.

Praktický checklist pro webové týmy

• Cíl, baseline, akceptační kritéria, schvalující osoba a spouštěč rollbacku jsou zdokumentovány.
• Starý a nový index zůstávají oddělené; model, dimenze a metrika jsou jednoznačně verzovány.
• Oba indexy pocházejí ze stejné schválené verze zdrojů a chunkování.
• Proces backfillu je idempotentní, obnovitelný a zkontrolovaný oproti cílovému stavu.
• Golden Set, kritické dotazy, jazyky, případy bez výsledků a přístupové filtry úspěšně prošly srovnáním.
• Shadow reads zaznamenávají pouze nezbytná technická data.
• Překlopení (cutover) a zpětné přepnutí jsou malé, pozorovatelné a prakticky otestované kroky.
• Starý obsah se maže až po uplynutí lhůty pro sledování a zdokumentovaném schválení.

Závěr: Nový vektorový prostor vyžaduje vlastní release proces

Změna RAG embeddingů představuje datovou migrací a migraci kvality, nikoli pouhé přepnutí jednoho parametru. Kdo nový vyhledávací prostor buduje odděleně, provádí kompletní re-embedding, porovnává výsledky na identických dotazech a aktivaci provádí přes vratný bod přepnutí, ten výrazně snižuje rizika výpadků i zhoršení kvality. Pro webové týmy se vyplatí krátký, opakovaně použitelný proces: zajistit baseline, postavit paralelní index, otestovat vyhledávání a odpovědi, sledovat shadow data, řízeně přepnout a nechat otevřenou cestu zpět.

Pokud váš AI chatbot již využívá znalostní bázi RAG, nezačínejte migraci samotnou změnou nastavení, ale přípravou testovací datové sady. Deset až dvacet obzvláště důležitých kategorií dotazů, doplněných o složité jazykové, produktové a oprávnění týkající se případy, vytvoří rozdíl mezi pouhou domněnkou a prokazatelně bezpečným releasem.

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