RAG-embedding-mallin vaihto: AI-chatbotin migraatio ilman aukkoja tietopohjassa

Embedding-malli toimii yleensä näkymättömissä RAG-chatbotin taustalla. Se kääntää kysymykset ja tietoelementit lukubiotreiksi, jotta semanttisesti sopiva sisältö löytyy. Juuri siksi, että tämä osa näkyy harvoin käyttöliittymässä, mallin vaihtaminen saattaa vaikuttaa vain pieneltä konfiguraatiomuutokselta. Teknisesti se kuitenkin luo täysin uuden hakuavaruuden. Olemassa olevien dokumenttivektorien, uustien kysymysvektorien ja indeksin määrittelyn on jälleen sovittava yhteen.

Jos haluat vaihtaa RAG-embeddingejä, sinun ei pitäisi vain vaihtaa mallin nimeä kyselyputkessa (query pipeline). Turvallinen vaihto kohtelee uutta indeksiä itsenäisenä versiona: se rakennetaan reprodusoitavasti, testataan samoilla testikysymyksillä, sitä käytetään ensin rinnakkain ja se aktivoidaan vasta tietoisen hyväksyntäpäätöksen jälkeen. Näin verkkosivuston chatbot pysyy saatavilla, kun taas tiimi pitää laadun, suorituskyvyn, kustannukset ja palautusreitin hallinnassa.

Miksi embeddingit eivät ole vapaasti vaihdettavissa

Vektori on mielekäs vain siinä avaruudessa, jossa se on luotu. Virallinen Azure AI Search -dokumentaatio vektori-indeksin luomisesta kuvaa indeksin embedding-avaruutena, joka koostuu saman mallin vektoreista. Siinä huomautetaan myös, että jokaisen vektorin dimensioiden on vastattava kentän määrittelyä. Uudella mallilla voi olla eri dimensio, erilaiset vahvuudet eri kielissä tai eri lailla jakautuneet semanttiset etäisyydet.

Yhtä tärkeää on kyselypuoli. Microsoftin dokumentaation mukaan vectorizer-konfiguraatiosta indeksoinnin ja kyselyn on käytettävä samaa embedding-mallia. Jos tiimi sekoittaa vanhoja dokumenttivektoreita uuden mallin kysymyksiin, samanlaisuuspesiä (similarity scores) ei voida enää tulkita luotettavasti. Vaikka dimensio sattuisi olemaan täysin sama, se ei todista semanttisesta yhteensopivuudesta.

Määritä mitattava tavoite ennen vaihtoa

”Uudempi” ei ole riittävä hyväksyntäkriteeri. Ennen ensimmäistä uudelleenindeksointia tiimi tarvitsee konkreettisen syyn migraatiolle. Pitäisikö tulosten laadun parantua tietyssä ammattisanastossa? Tarvitaanko lisäkieliä? Onko aiempi malli vanhentunut, liian hidas tai liian kallis? Vai pitäisikö pienemmän vektoridimension säästää muistia? Tavoitteesta muodostuvat vertailumetriikat.

• Laatu: relevantit lähteet Top-k-tuloksissa, vastattavissa olevien kysymysten osuus ja lopullisen vastauksen laatu.
• Toiminta: haun viive (latency), virheprosentti, indeksoinnin kesto ja käyttäytyminen osittaisissa virhetilanteissa.
• Kustannukset: koko kannan embeddingien luonti, jatkuvat muutokset, tallennustila ja kyselyt.
• Kattavuus: dokumentit, kielet, tuoteversiot ja käyttöoikeusalueet uudessa indeksissä.

Lähtöarvot kuuluvat samaan testiraporttiin kuin ehdokkaan tulokset. Ne, jotka pitävät jo yllä Golden Setiä, voivat käyttää olemassa olevaa opasta AI-chatbotin vastauslaadun mittaamiseen pohjana. On tärkeää olla vertailematta vain keskimääräistä pistemäärää: kriittiset tukikysymykset, harvinaiset ammattitermit ja ”ei tuloksia” -tapaukset ansaitsevat omat analyysinsä.

Kaksi indeksiä suoran muokkauksen sijaan

Vankka standardi on rinnakkaisindeksi. Aiempi indeksi pysyy muuttumattomana ja palvelee live-liikennettä. Sen rinnalle luodaan uusi kokoelma tai indeksi, jolla on oma mallitunniste, dimensio, etäisyysmetriikka ja versionumero. Molemmat rakennetaan samasta hyväksytystä lähdeversiosta. Tämän ansiosta erot voidaan kohdentaa malliin tai indeksin konfiguraatioon sen sijaan, että vertailtaisiin samanaikaisesti muuttuvia sisältöjä.

Virallinen Weaviate-ohje vectorizerin vaihtamisesta näyttää tätä varten erilliset kokoelmat ja aliaksen peruutettavana kytkentäpisteenä. Tietty tuote on korvattavissa; periaate säilyy arvokkaana: eristä vanhat ja uudet embeddingit siististi, ohjaa pääsyä hallitun reitittimen tai aliaksen kautta ja säilytä vanha tila rajoitetun rollback-ajan verran.

Stabiilit identiteetit jokaiselle tietoelementille

Jokainen chunk (tietopala) tarvitsee stabiilin liiketoiminnallisen ID:n, joka ei riipu vektorista. Järkevä yhdistelmä on lähde-ID, lähdeversio, osio ja chunk-versio. Lisäksi jokaisessa tietueessa tulisi olla mallin nimi, malliversio, dimensio, luontiaika ja embeddatun tekstin tiiviste (hash). Näin putki pystyy tunnistamaan täsmällisesti, mitä on jo käsitelty, mitä on embeddattava uudelleen ja mitkä virheet ovat edelleen auki.

Määritä uusi putki toistettavasti

Ennen suurta taustasynkronointia (backfill) pieni edustava osajoukko tulisi ajaa uuden putken läpi. Tällöin teksti-uutanta, puhdistus ja RAG-palastelu (chunking) pidetään aluksi muuttumattomina. Jos tiimi muuttaa samanaikaisesti mallia, chunk-rajoja, metastatiedostoja ja rankingia, myöhempää laatueroa on lähes mahdotonta selittää.

Konfiguraatio kuuluu versioituna manifestina ajoon: malli ja tarjoaja, dimensio, normalisointi, etäisyysmetriikka, eräkoko (batch size), uudelleenyrityssäännöt, chunker-versio, sallitut kielet ja tarvittavat metatiedot. Kirjautumistiedot eivät kuulu tähän. Jokaiselle erälle tallennetaan vain ID:t, laskurit, tila ja turvallinen virhekoodi. Tämän ansiosta keskeytynyt ajo voidaan jatkaa ilman, että onnistuneita embeddingejä tarvitsee toistaa kalliisti.

Aja uudet embeddingit hallitusti ja todista täydellisyys

Reindex on valmis vasta, kun tavoite- ja toteutunut kanta täsmäävät. Pelkkä suuri dokumenttimäärä ei riitä. Putken tulisi tarkistaa lähdekohtaisesti, ovatko kaikki odotetut chunkit olemassa, vastaavatko niiden tekstitiivisteet hyväksyttyä lähdeversiota ja onko kaikki pakolliset metatiedot siirretty. Epäonnistuneet tietueet siirtyvät rajoitettuun uudelleenyritysjonoon; pysyvät virheet pysyvät näkyvissä ID:nsä kanssa eivätkä saa hävitä vihreän kokonaistilan taakse.

1. Pakasta lähdekanta ja version määräpäivä tai merkitse ne yksiselitteisesti.
2. Luo uusi indeksirakenne, jossa on sopiva dimensio ja metriikka.
3. Generoi embeddingit ja kirjoita chunkit rajoitetuissa, idempotentissa erissä.
4. Vertaa dokumentti-, chunk- ja metatietomääriä tavoitekantaan.
5. Tarkista pistokoe tekstitiivisteen, lähde-ID:n ja haettavan sisällön perusteella.

Vertaa hakutuloksia (retrieval) samalla kysymyssetillä

Nyt samat testikysymykset ajetaan kumpaakin indeksiä vastaan. Osumatarkkuuden ja rang-sijoituksen lisäksi tiimin tulisi vertailla tosiasiallisesti palautettuja lähteitä. Onko uusi indeksi nostanut kärkeen semanttisesti samanlaisia, mutta asiavirheellisiä osioita? Menettääkö se tarkan tuotekoodin? Löytyvätkö yhdyssanat tai monikieliset kysymykset paremmin? Olemassa oleva Hybrid Search- ja Reranking-konsepti on konfiguroitava täysin samalla tavalla molemmille ehdokkaille, jotta vertailu säilyy reiluna.

Azure-dokumentaatio vektorirelevanssista ja rankingista mainitsee tyhjentävän k-nearest-neighbor -haun mahdollisuutena luoda Ground Truth -joukko likimääräisen ANN-menetelmän Recall-arviointia varten. Tämä ei ole universaali kynnysarvo, mutta hyödyllinen kontrollitesti: ensin tarkka referenssi, sitten nopeampi tuotantohaku. Chatbotille merkitsee lisäksi se, mahdollistavatko löydetyt lähteet oikean ja perustellun vastauksen.

Tarkista osumien lisäksi valmis vastaus

Parempi hakuranki ei vielä takaa parempaa chatbot-vastausta. Siksi vertailun tulisi kattaa myös lähdeviitteet, täydellisyys, sallittu epävarmuus ja turvallinen keskeytys, jos todisteet ovat riittämättömät. Vastausmalli, järjestelmäohje (system prompt) ja lämpötila (temperature) pidetään mahdollisimman vakaina. Muuten testi mittaa useita muutoksia samanaikaisesti.

Shadow reads ennen todellista vaihtoa

Offline-testin jälkeen pieni osa todellisista, tietosuojatusti käsitellyistä hakukyselyistä voidaan lisäksi ajaa uutta indeksiä vastaan ilman, että tulosta näytetään käyttäjille. Tämä Shadow Read mittaa todellista kieltä, viivettä ja ”ei tuloksia” -käyttäytymistä. Yksityiset sisällöt, henkilötiedot ja täydelliset keskusteluhistoriat eivät kuulu tarkistamattomina vertailulogeihin. Usein riittävät pseudonyymisoidut kyselyluokat, tulos-ID:t ja tekniset mittausarvot.

Itse vaihto (cutover) on pieni, selkeästi havainnoitava muutos: alias, reititinkohde tai feature flag kytkeytyy indeksistä A indeksiin B. Ensimmäisen vaiheen aikana sovelletaan tiukempia hälytysrajoja puuttuville lähteille, hakuvirheille, viiveelle ja ihmiselle ohjaamisen määrälle (handoff rate). Vaiheittainen siirtymä on järkevä, jos arkkitehtuuri tukee sitä ilman sekoittuneita istuntotiloja.

Testaa rollback käytännössä ennen kytkentää

Rollback-suunnitelma on luotettava vain, jos vanha indeksi pysyy riittävän ajantasaisena ja takaisinkytkentäreitti on testattu. Rinnakkaisvaiheen aikana uusien tai muuttuneiden lähteiden tulisi siksi virrata hallitusti molempiin putkiin. Vaihtoehtoisesti tiimi dokumentoi lyhyen muutoskiellon ja selkeän jälkisynkronoinnin. Olemassa oleva opas Incident Responssiin ja rollbackiin auttaa määrittämään laukaisimet ja vastuualueet.

Tyypillisiä palautussignaaleja eivät ole vain tekniset virheet. Myös selkeä pudotus relevanteissa Top-k-osumissa, uudet kielelliset aukot, epätavallisen monet vastaamattomat kysymykset tai väärin sovelletut pääsysuodattimet oikeuttavat paluun. Vanha indeksi poistetaan vasta, kun seuranta-aika on päättynyt, poistolupa on dokumentoitu eikä selittämättömiä laatueroja ole enää auki.

Yleiset virheet embedding-migraatiossa

• Vain kyselypuolen vaihtaminen: Uusia kysymysvektoreita verrataan vanhaan dokumenttiavaruuteen.
• Saman dimension sekoittaminen yhteensopivuuteen: Numeroiden pituus ja semanttinen avaruus eivät ole sama asia.
• Useiden muuttujien muuttaminen kerralla: Malli, chunking ja ranking vaihtuvat samanaikaisesti; tietyn vaikutuksen syy jää epäselväksi.
• Pelkkien keskiarvojen tarkastelu: Harvinaiset, liiketoiminnalle kriittiset ja monikieliset kysymykset häviävät keskiarvoon.
• Liian aikainen siivous: Vanha indeksi poistetaan ennen kuin todellinen kuormitus ja laatudata näyttävät stabiilia toimintaa.
• Suodattimien unohtaminen: Kieli, versio ja pääsyongelmat eivät päde uudessa indeksissä täsmälleen kuten vanhassa.

Käytännön muistilista verkkosivutiimeille

• Tavoite, baseline, hyväksyntäkriteerit, hyväksyjä ja rollback-signaali on dokumentoitu.
• Vanha ja uusi indeksi pidetään erillään; malli, dimensio ja metriikka on versioitu selkeästi.
• Molemmat indeksit ovat peräisin samasta hyväksytystä lähde- ja chunk-versiosta.
• Backfill on idempotentti, jatkettavissa ja tarkistettu tavoitekantaa vastaan.
• Golden Set, kriittiset kysymykset, kielet, ”ei tuloksia” -tapaukset ja pääsysuodattimet läpäisevät vertailun.
• Shadow readit kirjaavat vain välttämättömät tekniset tiedot.
• Cutover ja palautus ovat pieniä, havainnoitavia ja käytännössä testattuja.
• Vanha kanta poistetaan vasta seuranta-ajan ja dokumentoidun hyväksynnän jälkeen.

Yhteenveto: Uusi vektoriavaruus tarvitsee oman julkaisuprosessin

RAG-embeddingien vaihtaminen on data- ja laatumigraatio, ei pelkkä mallin kytkin. Se, joka rakentaa uuden hakuavaruuden erillään, luo embeddingit uudelleen täydellisesti, vertailee samalla kysymyssetillä ja aktivoi sen peruutettavan kytkentäpisteen kautta, pienentää käyttökatko- ja laaturiskejä merkittävästi. Verkkosivutiimeille kannattaa luoda lyhyt, uudelleenkäytettävä runbook-prosessi: varmista baseline, rakenna rinnakkaisindeksi, tarkista haku ja vastaukset, seuraa shadow-dataa, vaihda hallitusti ja pidä palautusreitti auki.

Jos AI-chatbotisi käyttää jo RAG-tietopohjaa, älä aloita migraatiosta vaan testidatasetistä. 10–20 erityisen tärkeää kysymysluokkaa täydennettynä vaikeilla kieli-, tuote- ja käyttöoikeustapauksilla tekevät eron näennäisen mallinvaihdon ja todistetusti turvallisen julkaisun välillä.

Lähteet

• 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