RAG-embedding-model wijzigen: AI-chatbot migreren zonder kenniskloof

Een embedding-model werkt meestal onzichtbaar op de achtergrond van een RAG-chatbot. Het vertaalt vragen en kennisbouwstenen naar getallenvectoren, zodat semantisch passende inhoud wordt gevonden. Juist omdat dit onderdeel zelden op een gebruikersinterface verschijnt, voelt een modelwissel gemakkelijk aan als een kleine configuratiewijziging. Technisch gezien ontstaat er echter een nieuwe zoekruimte. De bestaande documentvectoren, de vectoren van nieuwe vragen en de definitie van de index moeten weer op elkaar aansluiten.

Wie RAG-embeddings wil wijzigen, moet daarom niet simpelweg de modelnaam in de query-pipeline vervangen. Een veilige overstap behandelt de nieuwe index als een zelfstandige versie: reproduceerbaar opgebouwd, getest met dezelfde testvragen, eerst parallel gebruikt en pas na een bewuste vrijgavebeslissing geactiveerd. Zo blijft de website-chatbot bereikbaar, terwijl het team kwaliteit, runtime, kosten en het terugpad onder controle houdt.

Waarom embeddings niet zomaar uitwisselbaar zijn

Een vector heeft alleen zin binnen de ruimte waarin hij is gegenereerd. De officiële documentatie van Azure AI Search over het aanmaken van een vectorindex beschrijft de index als een embedding-ruimte bestaande uit vectoren van hetzelfde model. Er wordt bovendien op gewezen dat de dimensie van elke vector moet passen bij de velddefinitie. Een nieuw model kan een andere dimensie, andere taalsterktes of een andere verdeling van semantische afstanden hebben.

Even belangrijk is de query-zijde. Volgens de Microsoft-documentatie over vectorizer-configuratie moeten indexering en zoekopdracht hetzelfde embedding-model gebruiken. Als een team oude documentvectoren mengt met vragen uit een nieuw model, zijn overeenkomstscores niet langer betrouwbaar te interpreteren. Zelfs als de dimensies toevallig identiek zijn, bewijst dat nog geen semantische compatibiliteit.

Definieer een meetbaar doel vóór de overstap

"Nieuwer" is geen voldoende acceptatiecriterium. Vóór de eerste herindexering heeft het team een concrete reden voor de migratie nodig. Moet de trefferkwaliteit in het vakjargon verbeteren? Zijn er extra talen nodig? Is het huidige model afgekondigd, te traag of te duur? Of moet een kleinere vectordensiteit opslagruimte besparen? Uit het doel ontstaan de vergelijkingsstatistieken.

• Kwaliteit: relevante bronnen in de top-k, aandeel beantwoordbare vragen en kwaliteit van het uiteindelijke antwoord.
• Werking: retrieval-latentie, foutpercentage, indexeringsduur en gedrag bij gedeeltelijke storingen.
• Kosten: embedding van het gehele bestand, lopende wijzigingen, opslag en zoekopdrachten.
• Dekking: documenten, talen, productversies en autorisatiegebieden in de nieuwe index.

De uitgangswaarden horen in hetzelfde testrapport thuis als de resultaten van de kandidaat. Wie hiervoor al een Golden Set onderhoudt, kan de bestaande gids voor het meten van de antwoordkwaliteit van AI-chatbots als basis gebruiken. Het is belangrijk om niet alleen een gemiddelde score te vergelijken: kritieke supportvragen, zeldzame vaktermen en situaties zonder resultaat verdienen hun eigen evaluaties.

Twee indexen in plaats van verbouwen aan een live systeem

De robuuste standaard is een parallelle index. De huidige index blijft ongewijzigd en bedient het live dataverkeer. Daarnaast ontstaat een nieuwe collection of index met een eigen model-ID, dimensie, afstandsmetriek en versienummer. Beide worden opgebouwd uit dezelfde vrijgegeven bronversie. Hierdoor kunnen verschillen worden toegeschreven aan het model of de indexconfiguratie, in plaats van aan tegelijkertijd veranderende inhoud.

De officiële Weaviate-handleiding voor het overstappen van vectorizer toont hiervoor gescheiden collections en een alias als omkeerbaar schakelpunt. Het specifieke product is inwisselbaar; het principe blijft waardevol: oude en nieuwe embeddings zuiver isoleren, de toegang via een gecontroleerde router of alias laten verlopen en de oude stand bewaren voor een beperkte rollback-periode.

Stabiele identiteiten voor elke kennisbouwsteen

Elke chunk heeft een stabiele functionele ID nodig die niet afhankelijk is van de vector. Een combinatie van bron-ID, bronversie, paragraaf en chunk-versie is verstandig. Bovendien moet elk datarecord de modelnaam, modelversie, dimensie, het tijdstip van aanmaken en een hash van de geüploade tekst bevatten. Zo kan de pipeline exact herkennen wat al is verwerkt, wat opnieuw moet worden ge-embed en welke fouten nog openstaan.

Leg de nieuwe pipeline reproduceerbaar vast

Vóór de grote backfill moet een kleine, representatieve subset door de nieuwe pipeline lopen. Daarbij blijven extractie, opschoning en RAG-chunking in eerste instantie ongewijzigd. Als het team tegelijkertijd het model, de chunk-grenzen, metadata en ranking aanpast, is een later kwaliteitsverschil nauwelijks meer te verklaren.

De configuratie hoort als een geversioneerd manifest bij de uitvoering: model en provider, dimensie, normalisatie, afstandsmetriek, batchgrootte, retry-regels, chunker-versie, toegestane talen en vereiste metadata. Inloggegevens horen hier uitdrukkelijk niet in thuis. Voor elke batch worden enkel ID's, tellers, status en een veilige foutcode opgeslagen. Daarmee kan een onderbroken uitvoering worden hervat zonder succesvolle embeddings kostbaar te herhalen.

Gecontroleerd opnieuw embedden en volledigheid aantonen

Een herindexering is pas compleet wanneer het beoogde en werkelijke bestand overeenkomen. Een hoog aantal documenten alleen is niet genoeg. De pipeline moet per bron controleren of alle verwachte chunks aanwezig zijn, of de tekst-hashes overeenkomen met de vrijgegeven bronversie en of alle verplichte metadata zijn overgenomen. Mislukte records gaan naar een beperkte retry-wachtrij; permanente fouten blijven zichtbaar met hun ID en mogen niet verdwijnen achter een groene totaalstatus.

1. Bevries het bronbestand en de versiestatumaanwijzing of markeer ze eenduidig.
2. Maak een nieuwe indexstructuur aan met de juiste dimensie en metriek.
3. Embed en schrijf chunks in beperkte, idempotente batches.
4. Vergelijk aantallen documenten, chunks en metadata met het beoogde bestand.
5. Controleer een steekproef op basis van tekst-hash, bron-ID en opvraagbare inhoud.

Vergelijk retrieval met identieke vragen

Nu worden dezelfde testvragen afgevoerd naar beide indexen. Naast het trefferpercentage en de rangpositie moet het team de daadwerkelijk geretourneerde bronnen vergelijken. Herschuift de nieuwe index weliswaar semantisch soortgelijke, maar inhoudelijk onjuiste paragrafen naar boven? Verliest hij exacte productcodes? Worden samengestelde woorden of meertalige vragen beter gevonden? Een reeds aanwezig concept voor hybride zoeken en reranking moet voor beide kandidaten identiek zijn geconfigureerd om de vergelijking eerlijk te houden.

De Azure-documentatie over vectorrelevantie en ranking noemt een uitputtende k-nearest-neighbor-zoekopdracht als een manier om een ground-truth-set op te bouwen voor de recall-evaluatie van een benaderende ANN-methode. Dat is geen universele drempelwaarde, maar wel een nuttige controle: eerst de exacte referentie, daarna de snellere productie-zoekopdracht. Voor de chatbot telt daarnaast of de gevonden bronnen een correct, onderbouwd antwoord mogelijk maken.

Controleer niet alleen treffers, maar ook het uiteindelijke antwoord

Een betere retrieval-ranggarantie biedt nog geen beter chatbot-antwoord. Daarom moet de vergelijking ook de bronvermelding, volledigheid, toegestane onzekerheid en de veilige afbreking bij onvoldoende bewijs omvatten. Houd hierbij het antwoordmodel, de systeeminstructie en de temperatuur zo constant mogelijk. Anders meet de test meerdere wijzigingen tegelijk.

Shadow reads vóór de daadwerkelijke cutover

Na de offline test kan een klein deel van de echte, privacyvriendelijk verwerkte zoekopdrachten extra tegen de nieuwe index worden uitgevoerd, zonder dat het resultaat aan de gebruikers wordt getoond. Deze shadow read meet de werkelijke taal, latentie en het gedrag bij situaties zonder resultaat. Privé-inhoud, persoonsgegevens en volledige gespreksverlopen horen niet ongecontroleerd in vergelijkingslogs thuis. Vaak volstaan gepseudonimiseerde query-klassen, resultaat-ID's en technische meetwaarden.

De cutover zelf is een kleine, duidelijk waarneembare verandering: alias, routerdoel of feature-flag schakelt over van index A naar index B. Tijdens de eerste fase gelden er strengere alarmgrenzen voor ontbrekende bronnen, retrieval-fouten, latentie en de handoff-rate. Een stapsgewijze uitrol is verstandig als de architectuur dit ondersteunt zonder gemengde sessiestatussen.

Test de rollback praktisch vóór het omschakelen

Een rollback-plan is alleen betrouwbaar als de oude index actueel genoeg blijft en het terugpad is getest. Tijdens de parallelle fase moeten nieuwe of gewijzigde bronnen daarom gecontroleerd naar beide pipelines stromen. Als alternatief documenteert het team een korte stop op wijzigingen en een duidelijke inhaalslag. De bestaande gids voor incident response en rollback helpt bij het vastleggen van triggers en verantwoordelijkheden.

Typische rollback-signalen zijn niet alleen technische fouten. Ook een duidelijke daling in relevante top-k-treffers, nieuwe taalkloven, ongebruikelijk veel onbeantwoorde vragen of verkeerd toegepaste toegangsfilters rechtvaardigen een terugkeer. De oude index wordt pas verwijderd als de observatieperiode is afgelopen, de goedkeuring voor verwijdering is gedocumenteerd en er geen onverklaard kwaliteitsverschil meer openstaat.

Veelgemaakte fouten bij embedding-migratie

• Alleen de query-zijde wijzigen: Nieuwe vraagvectoren worden vergeleken met een oude documentruimte.
• Gelijke dimensie verwarren met compatibiliteit: Getallenlengte en semantische ruimte zijn niet hetzelfde.
• Meerdere variabelen tegelijk wijzigen: Model, chunking en ranking veranderen gelijktijdig, waardoor de oorzaak van een effect onduidelijk blijft.
• Alleen naar gemiddelden kijken: Zeldzame, bedrijfskritische en meertalige vragen verdwijnen in het gemiddelde.
• Te vroeg opruimen: De oude index wordt gewist voordat echte belasting en kwaliteitsgegevens een stabiele werking aantonen.
• Filters vergeten: Taal, versie en toegang gelden in de nieuwe index niet exact zoals in de oude.

Praktische checklist voor website-teams

• Doel, baseline, acceptatiecriteria, goedkeurder en rollback-signaal zijn gedocumenteerd.
• Oude en nieuwe index blijven gescheiden; model, dimensie en metriek zijn eenduidig geversioneerd.
• Beide indexen zijn afkomstig uit dezelfde vrijgegeven bron- en chunk-versie.
• Backfill is idempotent, hervatbaar en gecontroleerd op basis van het beoogde bestand.
• Golden Set, kritieke vragen, talen, situaties zonder resultaat en toegangsfilters doorstaan de vergelijking.
• Shadow reads loggen alleen de noodzakelijke technische gegevens.
• Cutover en terugschakeling zijn klein, observeerbaar en praktisch getest.
• Het oude bestand wordt pas gewist na de observatieperiode en een gedocumenteerde vrijgave.

Conclusie: De nieuwe vectorruimte heeft een eigen releaseproces nodig

Het overstappen van RAG-embeddings is een data- en kwaliteitsmigratie, geen eenvoudige modelschakelaar. Wie de nieuwe zoekruimte gescheiden opbouwt, volledig opnieuw embedt, vergelijkt met identieke vragen en activeert via een omkeerbaar schakelpunt, vermindert de risico's op uitval en kwaliteitsverlies aanzienlijk. Voor website-teams is een kort, herbruikbaar runbook-proces de moeite waard: baseline beveiligen, parallelle index bouwen, retrieval en antwoorden controleren, shadow-data monitoren, gecontroleerd omschakelen en de weg terug openhouden.

Als uw AI-chatbot al gebruikmaakt van een RAG-kennisbank, begin dan niet met de migratie, maar met de testdataset. Tien tot twintig bijzonder belangrijke vraagklassen, aangevuld met moeilijke taal-, product- en autorisatiegevallen, maken het verschil tussen een aannemelijke modelwissel en een aantoonbaar veilige release.

Bronnen

• 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