Kan flera inbäddningsmodeller samexistera i ett privat söksystem?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Can Multiple Embedding Models Coexist in One Private Search System?

Ja. Ett privat söksystem kan lagra och söka efter vektorinbäddningar från flera modeller samtidigt. Det säkra tillvägagångssättet är att behandla varje inbäddningsmodell som ett eget vektorutrymme med uttryckliga dimensioner, avståndsmått, version och indexkonfiguration. Blanda inte inkompatibla vektorer i en anonym kolumn och anta att de är jämförbara.

Flera modeller är användbara vid migreringar, flerspråkig sökning, sökning med bild och text, domänspecifika inbäddningar eller A/B-testning. Komplexiteten uppstår när du behöver kombinera resultat från dessa utrymmen.

Varför skulle du behålla mer än en inbäddningsmodell?

Orsak	Exempel
Modellmigrering	Den gamla kodaren förblir aktiv medan nya vektorer fylls på i efterhand
Flerspråkig sökning	Allmän engelsk modell + flerspråkig modell
Olika modaliteter	Textinbäddningar + bildinbäddningar
Domänspecialisering	Allmänna dokument + kodinbäddningar
Kvalitetstestning	A/B-hämtning innan produktionsmodellen ersätts
Sen interaktion	Tät retriever + ColBERT-liknande omrankning

En privat kunskapsbas utvecklas över tid. Om varje dokument permanent låses till den första inbäddningsmodell du valde blir uppgraderingar onödigt störande.

Olika modeller producerar olika vektorutrymmen

Två modeller kan båda generera vektorer med 768 dimensioner och ändå vara inkompatibla. Koordinaterna har bara betydelse i relation till modellen som genererade dem.

Dokument A
  |
  +-- Modell v1 -> vector_v1 [768]
  |
  +-- Modell v2 -> vector_v2 [1024]
  |
  +-- bildmodell -> vector_image [512]

En fråga som genererats med Modell v2 bör söka i v2-utrymmet. Att jämföra den direkt med Modell v1-vektorer är meningslöst även om ett API accepterar dimensionerna.

Qdrants aktuella dokumentation om namngivna vektorer stöder uttryckligen flera vektorer av olika storlekar och typer i samma punkt, där varje vektor ligger i ett separat namngivet vektorutrymme.

Använd ett modellregister, inte bara ett vektornamn

Registrera tillräckligt med metadata för att återskapa varje vektorinbäddning:

bäddningsutrymme: text_v2
modell-ID:        example/model-name
modellrevision:  sha-eller-version
vektordimension:      1024
mått:          cosinus
normaliserad:      true
segmenteringspolicy: semantisk-v3
skapad:      2026-09-03

Chunkning hör också hemma i registret. Om du ändrar både inbäddningsmodellen och hur dokumenten delas upp förändras hämtningen av två orsaker. Genom att göra pipelineversionen explicit blir jämförelse och återställning möjliga.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

En samling med namngivna vektorer eller separata samlingar?

Båda designerna kan vara korrekta.

Design	Bäst när	Avvägning
Namngivna vektorer på samma objekt	Samma dokument/nyttolast mellan modeller	Större objekt- och indexomfång
Separata samlingar	Olika scheman, livscykel, skala eller behörigheter	Mer synkroniseringsarbete
En Postgres-tabell + model_id	SQL-centrerad stack	Index måste begränsas korrekt

Weaviates dokumentation om samlingar stöder på liknande sätt flera namngivna vektorrymder per objekt, var och en med sin egen konfiguration för vektoriserare och index.

Om behörigheterna skiljer sig åt – till exempel mellan familjedokument och arbetsdokument – kan separata samlingar fortfarande vara renare än att lägga alla representationer i ett enda objekt.

Kan pgvector lagra olika dimensionaliteter?

Ja. PgVectors dokumentation visar en generell vector-kolumn med ett model_id och använder sedan uttrycks- och partiella index för rader med en viss dimensionalitet.

Principen är densamma: behåll modellidentiteten i datamodellen och bygg ANN-indexet endast över kompatibla rader.

Jämför inte råa likhetspoäng mellan modeller

Detta är det mest subtila felet. En cosinuslikhet på 0,78 från modell A innebär inte nödvändigtvis samma kvalitet som 0,78 från modell B. Poängfördelningarna beror på modellens träning, normalisering, mått, domän och indexets beteende.

Om du vill ha en enda resultatlista från två inbäddningsmodeller hämtar du först resultaten separat:

Fråga
  |
  +-- Modell A -> de 20 främsta resultaten + rangordningar
  |
  +-- Modell B -> de 20 främsta resultaten + rangordningar
                      |
                      v
               fusion / reranker
                      |
                      v
                  slutliga topp 10

Säkrare kombinationsmetoder omfattar rankfusion, modellspecifik poängnormalisering som kalibrerats utifrån dina data, eller en cross-encoder/reranker som utvärderar kandidattexten efter hämtningen.

Weaviates dokumentation om sökning med flera målvektorer beskriver sammanslagningsstrategier, inklusive normaliserade/viktade kombinationer, vilket illustrerar varför fusion över flera utrymmen kräver en uttrycklig strategi i stället för naiv sortering efter råpoäng.

Hur migrerar man till en ny inbäddningsmodell utan driftstopp?

Ta inte bort de gamla inbäddningarna först. Använd en parallell migrering:

registrera den nya modellen och vektorutrymmet;
generera nya inbäddningar för nyligen importerade dokument;
fyll på gamla dokument i batcher;
kör skuggsökningar mot båda utrymmena;
jämför återkallning och uppgiftsframgång med verkliga frågor;
byt standardutrymme för frågor;
behåll de gamla vektorerna under en period för återställning;
ta bort dem först när du känner dig säker.

Weaviate påpekar att när en ny namngiven vektor läggs till sker ingen automatisk omvektorisering av befintliga objekt. Det är värt att komma ihåg, eftersom ”schemat stöder en ny modell” och ”alla gamla data har nya vektorer” är separata milstolpar.

Flera inbäddningar ökar lagringsbehovet snabbare än många förväntar sig

Varje extra vektorrepresentation kan lägga till ytterligare en tät array och ytterligare ett ANN-index. En andra inbäddningsmodell kan därför ungefär fördubbla vektor-/indexdelen av databasen, trots att originaldokumenten bara lagras en gång.

Uppskattning:

vektorbyte ~=
  dokumentsegment
  x dimensioner
  x byte per element
  x antal inbäddningsutrymmen

+ omkostnad för ANN-index
+ metadata-/payloadindex

Kvantiserade index eller index med halva precisionen kan minska storleken, men testa hämtningens kvalitet innan du tillämpar komprimering på varje modell.

Detta knyter an till frågan om arkitektur för lokala kunskapsbaser: inbäddningar är utbytbara härledda data, medan källdokumenten och metadata är beständiga tillgångar som låter dig återskapa dem.

Använd olika modeller för olika frågerutter

Du behöver inte söka i varje vektorutrymme för varje fråga. Dirigera efter behov:

Fråga	Inbäddningsutrymme
Engelska hemmanualer	general_text_v2
Anteckningar på kinesiska och engelska	multilingual_v1
Källkodsfråga	code_v1
Hitta liknande foto	image_v1
Okänd/bred sökning	två utrymmen + rangfusion

En liten frågeklassificerare kan välja rätt utrymme, medan tvetydiga sökningar kan spridas över två representationer och slå ihop resultaten.

Behörigheter måste tillämpas före fusion

Hämta inte obehöriga kandidater från varje vektorrymd och hoppas att den slutliga omrankaren döljer dem. Tillämpa användar- och dokumentbehörigheter i varje hämtningssteg så att känsliga segment inte hamnar i kandidatmängden, loggarna eller omrankarens prompt.

För privat NAS-sökning måste samma åtkomstkontrollregel överleva modellmigreringar. Ett nytt index bör ärva dokumentets behörighetsmetadata i stället för att bli en tillfälligt oskyddad kopia.

Guiden om privata AI-assistenter ger det större sammanhanget: vektorsökning är bara användbar när den respekterar samma gränser för privata data som fillagringen.

Checklista för kvalitetssäkring av flera inbäddningar

Ge varje inbäddningsrymd ett unikt modell-/versions-ID.
Registrera dimensioner, normalisering och avståndsmått.
Versionshantera segmentering och förbehandling.
Fråga aldrig en modells vektor mot en annan modells index.
Jämför inte råpoäng direkt mellan vektorrymder utan kalibrering.
Tillämpa behörigheter i varje hämtningsväg.
Skapa nya vektorer i efterhand innan du ändrar standardmodellen.
Utvärdera med verkliga frågor och kända relevanta dokument.
Behåll det tidigare indexet under en period för återställning.
Inkludera extra vektorer och index i kapacitetsplaneringen för disk och RAM.

Vanliga frågor

Kan två inbäddningsmodeller använda olika dimensioner i samma databas?

Ja, om databasen stöder separata namngivna vektorrymder, samlingar eller index för varje kompatibel dimension. Qdrant, Weaviate och pgvector erbjuder alla mönster för detta.

Kan jag byta inbäddningsmodell utan att skapa nya inbäddningar för gamla dokument?

Inte om du vill att de gamla dokumenten ska vara sökbara i den nya modellens vektorrymd. En ny frågevektor är inte kompatibel med inbäddningar som skapats av en annan modell.

Bör jag behålla gamla inbäddningar för alltid?

Nej. Behåll dem under utvärdering och återställning. När den nya modellen har validerats och migreringen är klar kan borttagning av föråldrade vektorer frigöra betydande lagringsutrymme och indexminne.

Slutgiltigt besked

Flera inbäddningsmodeller kan samexistera smidigt i ett privat söksystem när deras vektorrymder förblir tydligt åtskilda. Lagra metadata om modell och pipeline, fråga varje vektorrymd med motsvarande kodare, slå ihop resultaten medvetet och migrera genom att fylla på parallellt. Den farliga designen är inte ”mer än en modell”. Det är att tappa reda på vilken modell som skapade vilken vektor och låtsas att alla likhetspoäng betyder samma sak.