Skift RAG-embedding-model: Migrer AI-chatbot uden videnshuller

En embedding-model arbejder som regel usynligt i baggrunden af en RAG-chatbot. Den oversætter spørgsmål og vidensbyggestene til talvektorer, så semantisk matchende indhold kan findes. Netop fordi denne del sjældent vises i en brugerflade, kan et modelskift let virke som en lille konfigurationsændring. Teknisk set opstår der dog et nyt søgerum. De eksisterende dokumentvektorer, vektorerne fra nye spørgsmål og indeksdefinitionen skal passe sammen igen.

Hvis du vil skifte RAG-embeddings, bør du derfor ikke bare udskifte modelnavnet i din query-pipeline. Et sikkert skift behandler det nye indeks som en selvstændig version: opbygget reproducerbart, testet med de samme testspørgsmål, i første omgang drevet parallelt og først aktiveret efter en bevidst godkendelsesbeslutning. På den måde forbliver website-chatbotten tilgængelig, mens teamet bevarer kontrollen over kvalitet, svartider, omkostninger og retrætevej.

Hvorfor embeddings ikke bare kan udskiftes efter behag

En vektor giver kun mening inden for det rum, den blev oprettet i. Den officielle dokumentation fra Azure AI Search om oprettelse af et vektorindeks beskriver indekset som et embedding-rum bestående af vektorer fra den samme model. Den gør desuden opmærksom på, at dimensionen af hver vektor skal passe til feltdefinitionen. En ny model kan have en anden dimension, andre sproglige styrker eller en anden fordeling af semantiske afstande.

Lige så vigtig er query-siden. Ifølge Microsoft-dokumentationen om vectorizer-konfiguration skal indeksering og forespørgsel bruge den samme embedding-model. Hvis et team blander gamle dokumentvektorer med spørgsmål fra en ny model, kan lighedsscores ikke længere fortolkes pålideligt. Selvom dimensionen tilfældigvis skulle være identisk, beviser det ikke semantisk kompatibilitet.

Definer et målbart mål før skiftet

"Nyere" er ikke et tilstrækkeligt godkendelseskriterium. Før den første genindeksering har teamet brug for en konkret grund til migrationen. Skal søgekvaliteten forbedres inden for fagterminologi? Er der brug for yderligere sprog? Er den hidtidige model udfaset, for langsom eller for dyr? Eller skal en mindre vektordimension spare lagerplads? Ud fra målet opstår sammenligningsmetrikkerne.

• Kvalitet: Relevante kilder i top-k, andel af besvarelige spørgsmål og kvaliteten af det endelige svar.
• Drift: Retrieval-latenstid, fejlrate, indekseringsvarighed og adfærd ved delvise fejl.
• Omkostninger: Embedding af hele datamængden, løbende ændringer, lagring og forespørgsler.
• Dækning: Dokumenter, sprog, produktversioner og rettighedsområder i det nye indeks.

Startværdierne hører til i den samme testrapport som kandidatens resultater. Hvis I allerede vedligeholder et Golden Set til dette, kan I bruge den eksisterende vejledning til måling af AI-chatbots svarkvalitet som grundlag. Det er vigtigt ikke kun at sammenligne en gennemsnitlig score: Kritiske supportspørgsmål, sjældne fagbegreber og tilfælde uden resultater fortjener deres egne evalueringer.

To indekser i stedet for ombygning på et aktivt system

Den robuste standard er et parallelt indeks. Det hidtidige indeks forbliver uændret og betjener live-trafikken. Ved siden af oprettes en ny samling eller et nyt indeks med sin egen model-ID, dimension, afstandsmetrik og versionsnummer. Begge opbygges ud fra den samme godkendte kildeversion. Dermed kan forskelle henføres til modellen eller indekskonfigurationen i stedet for at sammenligne indhold, der ændrer sig samtidig.

Den officielle Weaviate-vejledning til skift af en vectorizer viser adskilte samlinger og et alias som et reversibelt omskiftningspunkt. Det konkrete produkt kan udskiftes; princippet forbliver værdifuldt: isoler gamle og nye embeddings rent, kør adgangen via en kontrolleret router eller alias, og bevar den gamle tilstand i en begrænset rollback-periode.

Stabile identiteter for hver vidensbyggesten

Hver chunk har brug for et stabilt fagligt ID, der ikke afhænger af vektoren. En fornuftig løsning er en kombination af kilde-ID, kildeversion, afsnit og chunk-version. Derudover bør enhver datapost indeholde modelnavn, modelversion, dimension, oprettelsestidspunkt og hash af den embeddede tekst. På den måde kan pipelinen præcist registrere, hvad der allerede er behandlet, hvad der skal embeddes igen, og hvilke fejl der stadig er åbne.

Fastlås den nye pipeline reproducerbart

Før den store genindeksering bør en lille, repræsentativ delmængde køre igennem den nye pipeline. Her forbliver ekstraktion, oprydning og RAG-chunking i første omgang uændret. Hvis teamet samtidig ændrer model, chunk-grænser, metadata og ranking, kan en senere kvalitetsforskel næppe forklares.

Konfigurationen hører til som et versioneret manifest til kørslen: model og udbyder, dimension, normalisering, afstandsmetrik, batchstørrelse, genprøvningsregler, chunker-version, tilladte sprog og nødvendige metadata. Adgangsoplysninger hører udtrykkeligt ikke til heri. For hvert batch gemmes blot ID'er, tællere, status og en sikker fejlkode. Dermed kan en afbrudt kørsel genoptages uden dyre gentagelser af vellykkede embeddings.

Gen-embed kontrolleret, og bevis fuldstændighed

En re-indeksering er først fuldført, når den faktiske og den forventede mængde stemmer overens. Et højt antal dokumenter er ikke nok i sig selv. Pipelinen bør for hver kilde kontrollere, om alle forventede chunks er til stede, om deres tekst-hashes passer til den godkendte kildeversion, og om alle obligatoriske metadata er overført. Fejlede dataposter ryger i en begrænset genprøvningskø; permanente fejl forbliver synlige med deres ID og må ikke forsvinde bag en grøn samlet status.

1. Frys kildemængden og versionsskæringsdatoen, eller marker dem entydigt.
2. Opret en ny indeksstruktur med passende dimension og metrik.
3. Embed og skriv chunks i begrænsede, idempotente batches.
4. Afstem dokument-, chunk- og metadata-antal i forhold til mål-mængden.
5. Test en stikprøve baseret på tekst-hash, kilde-ID og tilgængeligt indhold.

Sammenlign retrieval med identiske spørgsmål

Nu køres de samme testspørgsmål mod begge indekser. Ud over træfrate og rangplacering bør teamet sammenligne de faktiske kilder, der returneres. Har det nye indeks skubbet semantisk lignende, men fagligt forkerte afsnit op i toppen? Mister det præcise produktkoder? Bliver sammensatte ord eller flersprogede spørgsmål fundet bedre? Et eksisterende Hybrid Search- og Reranking-koncept skal konfigureres ens for begge kandidater, så sammenligningen forbliver retfærdig.

I Azure-dokumentationen om vektorrelevans og ranking nævnes udtømmende k-nearest-neighbor-søgning som en mulighed for at opbygge et Ground Truth-sæt til recall-evaluering af en tilnærmet ANN-metode. Det er ikke en universel tærskelværdi, men en nyttig kontroltest: Først den eksakte reference, derefter den hurtigere produktionssøgning. For chatbotten tæller det desuden, om de fundne kilder muliggør et korrekt, underbygget svar.

Kontroller ikke kun søgeresultater, men det færdige svar

En bedre retrieval-placering garanterer endnu ikke et bedre chatbot-svar. Derfor bør sammenligningen også omfatte kildereference, fuldstændighed, tilladt usikkerhed og sikker afbrydelse ved utilstrækkelig dokumentation. Her holdes svarmodel, systeminstruktion og temperatur så vidt muligt konstante. Ellers måler testen flere ændringer på én gang.

Shadow reads før det reelle cutover

Efter offline-testen kan en lille andel af reelle, dataminimerede søgeforespørgsler desuden køres mod det nye indeks, uden at resultatet vises til brugerne. Denne shadow read måler reelt sprog, latenstid og adfærd ved manglende resultater. Privat indhold, personhenførbare data og komplette samtalehistorikker hører ikke til i sammenligningslogs uden kontrol. Ofte er det nok med pseudonymerede query-klasser, resultat-ID'er og tekniske måleværdier.

Selve cutoveret er en lille, klart observerbar ændring: Alias, router-destination eller feature flag skifter fra indeks A til indeks B. I den første fase gælder der snævrere alarmgrænser for manglende kilder, retrieval-fejl, latenstid og handoff-rate. En gradvis udrulning er fornuftig, hvis arkitekturen understøtter det uden blandede tilstande i sessionerne.

Test rollback i praksis før omskiftning

En rollback-plan er kun robust, hvis det gamle indeks stadig er tilstrækkeligt opdateret, og tilbagekoblingsvejen er blevet testet. I den parallelle fase bør nye eller ændrede kilder derfor kontrolleret strømme ind i begge pipelines. Alternativt kan teamet dokumentere et kort ændringsstop og en klar efterfølgende opdatering. Den eksisterende vejledning om Incident Response og Rollback hjælper med at fastlægge udløsere og ansvarsområder.

Typiske genoprettelsessignaler er ikke kun tekniske fejl. Også et markant fald i relevante top-k-træffere, nye sproglige mangler, usædvanligt mange ubesvarede spørgsmål eller forkert håndhævede adgangsfiltre retfærdiggør en tilbagekobling. Det gamle indeks slettes først, når overvågningsperioden er udløbet, slettegodkendelsen er dokumenteret, og der ikke længere er uafklarede kvalitetsforskelle.

Hyppige fejl ved embedding-migration

• Kun at skifte query-siden: Nye spørgsmålsvektorer sammenlignes med et gammelt dokumentrum.
• At forveksle samme dimension med kompatibilitet: Tallængde og semantisk rum er ikke det samme.
• At ændre flere variabler på én gang: Model, chunking og ranking ændres samtidig; årsagen til en effekt forbliver uklar.
• Kun at se på gennemsnitsværdier: Sjældne, forretningskritiske og flersprogede spørgsmål forsvinder i gennemsnittet.
• At rydde op for tidligt: Det gamle indeks slettes, før reel belastning og kvalitetsdata udviser en stabil drift.
• At glemme filtre: Sprog, version og adgang gælder ikke nøjagtigt på samme måde i det nye indeks som i det gamle.

Praktisk tjekliste til website-teams

• Mål, baseline, godkendelseskriterier, godkendelsesansvarlig og rollback-signal er dokumenteret.
• Gammelt og nyt indeks forbliver adskilt; model, dimension og metrik er entydigt versioneret.
• Begge indekser stammer fra den samme godkendte kilde- og chunk-version.
• Backfill er idempotent, kan genoptages og er kontrolleret mod mål-mængden.
• Golden Set, kritiske spørgsmål, sprog, tilfælde uden resultater og adgangsfiltre bestpr sammenligningen.
• Shadow reads logger kun nødvendige tekniske data.
• Cutover og rollback er små, observerbare og testet i praksis.
• Den gamle datamængde slettes først efter overvågningsperioden og dokumenteret godkendelse.

Konklusion: Det nye vektorrum kræver sin egen release-proces

At skifte RAG-embeddings er en data- og kvalitetsmigration, ikke blot et skift af en modelkontakt. Hvis I opbygger det nye søgerum separat, foretager en komplet gen-embedding, sammenligner med identiske spørgsmål og aktiverer via et reversibelt omskiftningspunkt, reducerer I risikoen for nedetid og kvalitetstab betragteligt. For website-teams kan det betale sig med en kort, genanvendelig runbook-proces: Sikre baseline, byg et parallelt indeks, kontroller retrieval og svar, overvåg shadow-data, skift kontrolleret om, og hold retrætevejen åben.

Hvis jeres AI-chatbot allerede bruger en RAG-vidensbase, bør I ikke starte med migrationen, men med testdatasættet. Ti til tyve særligt vigtige spørgsmålsklasser, suppleret med svære sprog-, produkt- og rettighedstilfælde, gør forskellen på et sandsynligt modelskift og en beviseligt sikker release.

Kilder

• 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