RAG-embedding modell váltása: AI-chatbot migrálása tudásrések nélkül

Egy embedding modell többnyire láthatatlanul működik egy RAG-chatbot hátterében. Kérdéseket és tudásblokkokat fordít számszerű vektorokká, hogy megtalálja a szemantikailag releváns tartalmakat. Pontosan azért, mert ez a rész ritkán jelenik meg a felhasználói felületen, a modellváltás könnyen tűnhet egy egyszerű konfigurációmódosításnak. Technikai szempontból azonban egy új keresési tér jön létre. A meglévő dokumentumvektoroknak, az új kérdések vektorainak és az index definíciójának ismét illeszkedniük kell egymáshoz.

Aki a RAG-embeddingek váltása mellett dönt, nem szabad egyszerűen kicserélnie a modell nevét a lekérdezési folyamatban (query pipeline). A biztonságos váltás az új indexet önálló verzióként kezeli: reprodukálhatóan épül fel, ugyanazokkal a tesztkérdésekkel van ellenőrizve, először párhuzamosan fut, és csak egy tudatos jóváhagyási döntés után válik aktívvá. Így a weboldali chatbot elérhető marad, miközben a csapat kézben tartja a minőséget, a futásidőt, a költségeket és a visszalépési útvonalat.

Miért nem cserélhetők fel tetszőlegesen az embeddingek?

Egy vektor csak abban a térben bír értelemmel, amelyben létrejött. Az Azure AI Search vektorindex létrehozásáról szóló hivatalos dokumentációja az indexet ugyanazon modell vektoraiból álló embedding-térként írja le. Arra is rámutat, hogy az egyes vektorok dimenziójának illeszkednie kell a meződefinícióhoz. Egy új modellnek eltérő dimenziója, más nyelvi erősségei vagy a szemantikai távolságok másfajta eloszlása lehet.

Ugyanilyen fontos a lekérdezési oldal (query side). A Vectorizáció konfigurációjáról szóló Microsoft-dokumentáció szerint az indexelésnek és a lekérdezésnek ugyanazt az embedding modellt kell használnia. Ha egy csapat a régi dokumentumvektorokat egy új modellből származó kérdésekkel keveri, a hasonlósági pontszámok (similarity scores) többé nem értelmezhetők megbízhatóan. Még ha a dimenzió véletlenül meg is egyezik, ez nem bizonyít szemantikai kompatibilitást.

A váltás előtt határozzon meg mérhető célt

Az, hogy valami „újabb”, nem elegendő elfogadási kritérium. Az első újraindexelés előtt a csapatnak konkrét okra van szüksége a migrációhoz. A szaknyelvi találati minőséget szeretnék növelni? További nyelvekre van szükség? A korábbi modell kivezetésre kerül, túl lassú vagy túl drága? Vagy egy kisebb vektordimenzióval szeretnének tárhelyet megtakarítani? A célból származnak az összehasonlító mutatók.

• Minőség: releváns források a Top-k találatokban, a megválaszolható kérdések aránya és a végleges válasz minősége.
• Üzemeltetés: lekérdezési latencia (retrieval latency), hibaarány, indexelési időtartam és a részleges hibák kezelése.
• Költségek: a teljes állomány beágyazása, a folyamatos módosítások, a tárhely és a lekérdezések költsége.
• Lefedettség: dokumentumok, nyelvek, termékverziók és jogosultsági területek az új indexben.

A kiindulási értékeknek ugyanabba az ellenőrzési jelentésbe kell kerülniük, mint a jelölt eredményeinek. Aki ehhez már fenntart egy Golden Setet, alapként használhatja a az AI-chatbot válaszminőségének méréséről szóló úmutatót. A fontos az, hogy ne csak egy átlagos pontszámot hasonlítsunk össze: a kritikus támogatási kérdések, a ritka szakkifejezések és a találat nélküli esetek (No-Result) külön értékelést érdemelnek.

Két index az élő rendszer átalakítása helyett

A robusztus standard a párhuzamos index. A korábbi index változatlan marad, és kiszolgálja az élő forgalmat. Mellette létrejön egy új gyűjtemény (collection) vagy egy új index saját modellazonosítóval, dimenzióval, távolsági metrikával és verziószámmal. Mindkettő ugyanabból a jóváhagyott forrásverzióból épül fel. Ez lehetővé teszi, hogy az eltéréseket a modellnek vagy az indexkonfigurációnak tulajdonítsuk, ahelyett hogy a folyamatosan változó tartalmakat hasonlítanánk össze.

A hivatalos Weaviate-útmutató a vectorizer váltásáról erre a célra különálló gyűjteményeket és egy aliast mutat be reverzibilis átváltási pontként. A konkrét termék felcserélhető; az elv értékes marad: a régi és az új embeddingeket tisztán el kell különíteni, a hozzáférést egy ellenőrzött útválasztón (router) vagy aliason keresztül kell vezetni, és a régi állapotot meg kell őrizni egy korlátozott visszagörgetési időszakra.

Stabil azonosítók minden tudásblokkhoz

Minden chunkhoz (szövegrészlethez) szükség van egy stabil szakmai ID-ra, amely nem függ a vektortól. Célszerű a forrás-ID, forrásverzió, fejezet és chunk-verzió kombinációja. Ezenkívül minden adatrekordnak tartalmaznia kell a modell nevét, modellverzióját, dimenzióját, a létrehozás időpontját és a beágyazott szöveg hash-értékét. Így a pipeline pontosan fel tudja ismerni, mi lett már feldolgozva, mit kell újra beágyazni, és mely hibák nyitottak még.

Rögzítse az új pipeline-t reprodukálható módon

A nagy feltöltés (backfill) előtt egy kis, reprezentatív részhalmaznak kell átmennie az új pipeline-on. Ennek során a kinyerés (extraction), a tisztítás és a RAG-chunking egyelőre változatlan marad. Ha a csapat egyidejűleg változtatja meg a modellt, a chunk-határokat, a metaadatokat és a rangsorolást, a későbbi minőségbeli eltérés aligha lesz megmagyarázható.

A konfiguráció verziózott manifesztként tartozik a futtatáshoz: modell és szolgáltató, dimenzió, normalizálás, távolsági metrika, batch-méret, újrapróbálkozási szabályok (retry rules), chunker-verzió, engedélyezett nyelvek és szükséges metaadatok. A hozzáférési adatok kifejezetten nem tartoznak ide. Minden egyes batch esetében csupán az ID-k, számlálók, státuszok és egy biztonságos hibakód kerül mentésre. Ez lehetővé teszi a megszakadt futtatás folytatását anélkül, hogy a sikeres beágyazásokat drága módon meg kellene ismételni.

Ellenőrzött újrabeágyazás és a teljesség igazolása

Az újraindexelés csak akkor teljes, ha a cél- és a tényleges állomány megegyezik. A magas dokumentumszám önmagában nem elegendő. A pipeline-nak forrásonként ellenőriznie kell, hogy minden elvárt chunk jelen van-e, a szöveges hash-értékeik illeszkednek-e a jóváhagyott forrásverzióhoz, és minden kötelező metaadat átvételre került-e. A sikertelen adatrekordok egy korlátozott újrapróbálkozási sorba kerülnek; a tartós hibák láthatóak maradnak az ID-jukkal, és nem tűnhetnek el egy zöld összegző státusz mögött.

1. Befagyasztja vagy egyértelműen megjelöli a forrásállományt és a verziós határidőt.
2. Létrehozza az új indexstruktúrát a megfelelő dimenzióval és metrikával.
3. A chunkokat korlátozott, idempotens batchekben beágyazza és kiírja.
4. Összeveti a dokumentum-, chunk- és metaadatszámokat a célállománnyal.
5. Ellenőriz egy mintát a szöveges hash, forrás-ID és lekérdezhető tartalom alapján.

Hasonlítsa össze a lekérdezést azonos kérdésekkel

Most ugyanazok a tesztkérdések futnak le mindkét indexen. A találati arány és a rangsorpozíció mellett a csapatnak össze kell hasonlítania a ténylegesen visszakapott forrásokat is. Vajon az új index bár szemantikailag hasonló, de szakmailag téves szakaszokat sorolt előre? Elveszíti a pontos termékkódokat? A összetett szavak vagy a többnyelvű kérdések jobban megtalálhatók? Egy már meglévő hibrid keresési és reranking koncepciót mindkét jelöltnél azonosan kell konfigurálni, hogy az összehasonlítás tisztességes maradjon.

A vektorrelevanciáról és rangsorolásról szóló Azure-dokumentáció az k-legközelebbi szomszéd (k-nearest-neighbor) keresést említi lehetőségként egy Ground Truth készlet felépítésére egy hozzávetőleges ANN-eljárás felidézési (recall) értékeléséhez. Ez nem egy univerzális küszöbérték, de hasznos ellenőrző teszt: először a pontos referencia, majd a gyorsabb termelési keresés. A chatbot szempontjából emellett az is számít, hogy a megtalált források lehetővé tesznek-e egy helyes, alátámasztott választ.

Ne csak a találatokat, hanem a kész választ is ellenőrizze

A jobb lekérdezési rangsor még nem garantálja a jobb chatbot-választ. Ezért az összehasonlításnak ki kell terjednie a forráshivatkozásra, a teljességre, a megengedett bizonytalanságra és a hiányos bizonyítékok esetén történő biztonságos leállításra is. Ennek során a válaszmodell, a rendszerutasítás és a hőmérséklet (temperature) lehetőség szerint változatlan marad. Ellenkező esetben a teszt egyszerre több változást mérne.

Árnyéklekérdezések (shadow reads) az igazi átállás előtt

Az offline teszt után a valós, adattakarékosan kezelt keresési lekérdezések egy kis hányada párhuzamosan futtatható az új indexen is anélkül, hogy annak eredményét megjelenítenénk a felhasználóknak. Ez az árnyéklekérdezés a valós nyelvezetet, a latenciát és a találat nélküli viselkedést méri. A privát tartalmak, a személyes adatok és a teljes beszélgetési előzmények nem tartoznak ellenőrizetlenül az összehasonlító naplókba. Gyakran elegendők a pszeudonimizált lekérdezési osztályok, eredmény-ID-k és technikai mérési értékek.

Maga az átállás (cutover) egy kicsi, jól megfigyelhető változtatás: az alias, a router célja vagy a feature-flag az A indexről a B indexre vált. Az első fázisban szigorúbb riasztási határértékek érvényesek a hiányzó forrásokra, lekérdezési hibákra, latenciára és az emberi ügyintézőnek történő átadási arányra (handoff rate). A fokozatos átirányítás akkor célszerű, ha az architektúra kevert munkamenet-állapotok nélkül támogatja azt.

Gyakorlatban tesztelje a rollbacket az átkapcsolás előtt

A visszagörgetési terv (rollback plan) csak akkor megbízható, ha a régi index továbbra is elég naprakész, és a visszakapcsolási útvonalat tesztelték. A párhuzamos fázisban ezért az új vagy módosított forrásoknak ellenőrzötten mindkét pipeline-ba be kell áramolniuk. Alternatív megoldásként a csapat dokumentál egy rövid módosítási tilalmat (change freeze) és egy egyértelmű utólagos frissítést. Az incidenskezelésről és rollbackről szóló meglévő útmutató segít a kiváltó okok és a felelősségek meghatározásában.

A tipikus visszagörgetési jelzések nem csak technikai hibák lehetnek. A releváns Top-k találatok jelentős visszaesése, az új nyelvi hiányosságok, a szokatlanul sok megválaszolatlan kérdés vagy a hibásan alkalmazott hozzáférési szűrők is igazolják a visszatérést. A régi indexet csak akkor távolítják el, ha a megfigyelési időszak lezárult, a törlési jóváhagyás dokumentálva van, és nem maradt nyitott, tisztázatlan minőségi eltérés.

Gyakori hibák az embedding-migráció során

• Csak a lekérdezési oldal cseréje: Az új kérdésvektorok a régi dokumentumtérrel kerülnek összehasonlításra.
• Az azonos dimenzió összekeverése a kompatibilitással: A számsor hossza és a szemantikai tér nem ugyanaz.
• Több változó egyidejű módosítása: A modell, a chunking és a rangsorolás egyszerre változik; egy hatás oka tisztázatlan marad.
• Csak az átlagértékek figyelembevétele: A ritka, üzletileg kritikus és többnyelvű kérdések eltűnnek az átlagban.
• Túl korai takarítás: A régi index törlésre kerül, mielőtt a valós terhelés és a minőségi adatok stabil működést mutatnának.
• A szűrők elfelejtése: A nyelv, a verzió és a hozzáférés az új indexben nem pontosan úgy érvényesül, mint a régiben.

Gyakorlati ellenőrzőlista weboldal-üzemeltető csapatoknak

• A cél, az alapvonal (baseline), az elfogadási kritériumok, a jóváhagyó személy és a rollback jelzés dokumentálva van.
• A régi és az új index elkülönítve marad; a modell, a dimenzió és a metrika egyértelműen verziózott.
• Mindkét index ugyanabból a jóváhagyott forrás- és chunk-verzióból származik.
• A feltöltés (backfill) idempotens, folytatható és ellenőrizve van a célállománnyal szemben.
• A Golden Set, a kritikus kérdések, a nyelvek, a találat nélküli esetek és a hozzáférési szűrők átmennek az összehasonlításon.
• Az árnyéklekérdezések (shadow reads) csak a szükséges technikai adatokat naplózzák.
• Az átállás és a visszakapcsolás kicsi, megfigyelhető és a gyakorlatban tesztelt.
• A régi állomány csak a megfigyelési időszak és a dokumentált jóváhagyás után kerül törlésre.

Összegzés: Az új vektortérnek saját kiadási folyamatra (release process) van szüksége

A RAG-embeddingek váltása adat- és minőségi migráció, nem csupán egy egyszerű modellkapcsoló. Aki az új keresési teret külön építi fel, teljesen újra beágyazza, azonos kérdésekkel hasonlítja össze és egy reverzibilis átváltási ponton keresztül aktiválja, jelentősen csökkenti a leállási és minőségi kockázatokat. A weboldal-üzemeltető csapatok számára megéri egy rövid, újrafelhasználható forgatókönyv-folyamat (runbook): alapvonal biztosítása, párhuzamos index kiépítése, lekérdezés és válaszok ellenőrzése, árnyékadatok megfigyelése, ellenőrzött átváltás és a visszalépési út nyitva tartása.

Ha az Ön AI-chatbota már használ RAG-tudásbázist, ne a migrációval kezdje, hanem az ellenőrzési adatbázissal. Tíz-húsz különösen fontos kérdésosztály – kiegészítve a nehéz nyelvi, termék- és jogosultsági esetekkel – jelenti a különbséget egy feltételezhetően jó modellváltás és egy bizonyíthatóan biztonságos kiadás között.

Források

• 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