Ja. Eén privézoeksysteem kan tegelijkertijd inbeddingen van meerdere modellen opslaan en doorzoeken. De veilige aanpak is om elk inbeddingsmodel te behandelen als een eigen vectorruimte met expliciete dimensies, afstandsmetriek, versie en indexconfiguratie. Meng incompatibele vectoren niet in één anonieme kolom en ga er niet van uit dat ze vergelijkbaar zijn.
Meerdere modellen zijn nuttig voor migraties, meertalig zoeken, retrieval op basis van beeld en tekst, domeinspecifieke inbeddingen of A/B-testen. De complexiteit ontstaat wanneer je resultaten uit die ruimten moet combineren.
Waarom zou je meer dan één inbeddingsmodel gebruiken?
| Reden | Voorbeeld |
|---|---|
| Modelmigratie | De oude encoder blijft actief terwijl nieuwe vectoren op de achtergrond worden aangevuld |
| Meertalige zoekopdrachten | Algemeen Engels model + meertalig model |
| Verschillende modaliteiten | Tekstinbeddingen + beeldinbeddingen |
| Domeinspecialisatie | Algemene documenten + code-inbeddingen |
| Kwaliteitstests | A/B-retrieval voordat je het productiemodel vervangt |
| Late interactie | Dichte retriever + ColBERT-achtige herordening |
Een private kennisbank ontwikkelt zich. Elk document permanent koppelen aan het eerste inbeddingsmodel dat je hebt gekozen, maakt upgrades onnodig ingrijpend.
Verschillende modellen produceren verschillende vectorruimten
Twee modellen kunnen beide vectoren met 768 dimensies produceren en toch incompatibel zijn. De coördinaten hebben alleen betekenis in relatie tot het model dat ze heeft geproduceerd.
Document A
|
+-- Model v1 -> vector_v1 [768]
|
+-- Model v2 -> vector_v2 [1024]
|
+-- beeldmodel -> vector_image [512]
Een query die met Model v2 is gegenereerd, moet de v2-ruimte doorzoeken. Deze rechtstreeks vergelijken met Model v1-vectoren is betekenisloos, zelfs als een API de dimensies accepteert.
De huidige documentatie over benoemde vectoren van Qdrant ondersteunt expliciet meerdere vectoren met verschillende groottes en typen in hetzelfde punt, elk in een afzonderlijke benoemde vectorruimte.
Gebruik een modelregister, niet alleen een vectornaam
Leg voldoende metadata vast om elke inbedding te reproduceren:
inbeddingsruimte: text_v2
model-id: example/model-name
modelrevisie: sha-of-versie
vectordimensie: 1024
metriek: cosine
genormaliseerd: waar
chunkingsbeleid: semantische-v3
gemaakt op: 2026-09-03
Ook chunking hoort in het register. Als je zowel het embeddingmodel als de manier waarop documenten worden opgesplitst wijzigt, verandert het ophalen om twee redenen. Door de pipelineversie expliciet bij te houden, worden vergelijking en terugdraaien mogelijk.
Eén collectie met benoemde vectoren of afzonderlijke collecties?
Beide ontwerpen kunnen correct zijn.
| Ontwerp | Het meest geschikt wanneer | Afweging |
|---|---|---|
| Benoemde vectoren op hetzelfde object | Dezelfde documenten/payload voor alle modellen | Grotere object-/indexvoetafdruk |
| Afzonderlijke collecties | Verschillende schema's, levenscycli, schaal of toegangsrechten | Meer synchronisatiewerk |
| Eén Postgres-tabel + model_id | SQL-gerichte stack | Indexen moeten correct worden afgebakend |
De collectiedocumentatie van Weaviate ondersteunt eveneens meerdere benoemde vectorruimten per object, elk met een eigen vectorizer- en indexconfiguratie.
Als de toegangsrechten verschillen, bijvoorbeeld tussen gezinsdocumenten en werkdocumenten, kunnen afzonderlijke collecties overzichtelijker zijn dan alle representaties in één object te plaatsen.
Kan pgvector verschillende dimensionaliteiten opslaan?
Ja. De documentatie van pgvector toont een generieke kolom van het type vector met een model_id en gebruikt vervolgens expressie- en partiële indexen voor rijen met een specifieke dimensionaliteit.
Het principe is hetzelfde: houd de modelidentiteit bij in het datamodel en bouw de ANN-index alleen over compatibele rijen.
Vergelijk geen ruwe overeenkomstsscores tussen modellen
Dit is de meest subtiele fout. Een cosinusovereenkomst van 0,78 van Model A betekent niet noodzakelijk dezelfde kwaliteit als 0,78 van Model B. Scoreverdelingen zijn afhankelijk van modeltraining, normalisatie, metriek, domein en indexgedrag.
Als je één resultatenlijst wilt maken op basis van twee embeddingmodellen, haal je de resultaten eerst afzonderlijk op:
Query
|
+-- Model A -> top 20 resultaten + posities
|
+-- Model B -> top 20 resultaten + posities
|
v
fusion / reranker
|
v
uiteindelijke top 10
Veiligere combinatiemethoden zijn onder meer rank fusion, modelspecifieke score-normalisatie die op je gegevens is afgestemd, of een cross-encoder/reranker die de kandidaattekst na het ophalen beoordeelt.
De zoekdocumentatie van Weaviate over zoeken met meerdere doelen beschrijft combinatiestrategieën, waaronder genormaliseerde/gewogen combinaties. Dit illustreert waarom fusie tussen ruimtes een expliciete strategie vereist in plaats van naïef sorteren op onbewerkte scores.
Hoe migreer je zonder downtime naar een nieuw inbeddingsmodel?
Verwijder de oude inbeddingen niet als eerste. Gebruik een parallelle migratie:
- registreer het nieuwe model en de nieuwe vectorruimte;
- genereer nieuwe inbeddingen voor nieuw geïmporteerde documenten;
- vul oude documenten in batches aan;
- voer schaduwzoekopdrachten uit in beide ruimtes;
- vergelijk recall en taakuitvoering op echte vragen;
- schakel over naar de standaardqueryruimte;
- behoud de oude vectoren gedurende een terugvalperiode;
- verwijder ze pas wanneer het vertrouwen groot is.
Weaviate vermeldt dat het toevoegen van een nieuwe benoemde vector bestaande objecten niet automatisch opnieuw van vectoren voorziet. Dat is nuttig om te onthouden, omdat “schema ondersteunt nieuw model” en “alle oude gegevens hebben nieuwe vectoren” afzonderlijke mijlpalen zijn.
Meerdere inbeddingen vergroten de opslag sneller dan veel gebruikers verwachten
Elke extra vectorrepresentatie kan nog een dichte array plus een extra ANN-index toevoegen. Een tweede inbeddingsmodel kan het vector-/indexgedeelte van de database daardoor ruwweg vermenigvuldigen, ook al worden de oorspronkelijke documenten maar één keer opgeslagen.
Schatting:
vectorbytes ~=
documentsegmenten
x dimensies
x bytes per element
x aantal inbeddingsruimtes
+ overhead van ANN-index
+ metadata-/payload-indexen
Kwantificering of indexen met halve precisie kunnen de voetafdruk verkleinen, maar test de retrievalkwaliteit voordat je compressie op elk model toepast.
Dit sluit weer aan bij de vraag naar de architectuur van een lokale kennisbank: inbeddingen zijn vervangbare afgeleide gegevens, terwijl de brondocumenten en metadata de duurzame assets zijn waarmee je ze opnieuw kunt opbouwen.
Gebruik verschillende modellen voor verschillende queryroutes
Je hoeft niet voor elke vraag elke vectorruimte te doorzoeken. Stuur queries op basis van de behoefte:
| Query | Inbeddingsruimte |
|---|---|
| Engelse handleidingen voor thuis | general_text_v2 |
| Chinese + Engelse notities | multilingual_v1 |
| Vraag over broncode | code_v1 |
| Vergelijkbare foto vinden | image_v1 |
| Onbekende / brede zoekopdracht | twee ruimtes + rangfusie |
Een kleine queryclassifier kan de juiste ruimte selecteren, terwijl ambigue zoekopdrachten over twee representaties kunnen worden verspreid en de resultaten kunnen worden samengevoegd.
Machtigingen moeten vóór fusie worden toegepast
Haal geen onbevoegde kandidaten op uit elke vectorruimte in de hoop dat de uiteindelijke herordener ze verbergt. Pas gebruikers- en documentmachtigingen in elke ophaalfase toe, zodat gevoelige fragmenten niet in de kandidatenset, logboeken of prompt van de herordener terechtkomen.
Voor zoeken op een privé-NAS moet dezelfde regel voor toegangsbeheer standhouden tijdens modelmigraties. Een nieuwe index moet de machtigingsmetadata van het document overnemen en geen tijdelijk onbeveiligd exemplaar worden.
De gids voor een privé-AI-assistent biedt de bredere context: zoeken op vectoren is alleen nuttig als het dezelfde grenzen voor privégegevens respecteert als de bestandsopslag.
Checklist voor QA met meerdere inbeddingen
- Geef elke inbeddingsruimte een unieke model-/versie-ID.
- Leg dimensies, normalisatie en afstandsmetriek vast.
- Versioneer chunking en voorbewerking.
- Gebruik nooit de vector van het ene model als query voor de index van een ander model.
- Vergelijk onbewerkte scores uit verschillende ruimten niet rechtstreeks zonder kalibratie.
- Pas in elk ophaalpad toegangsrechten toe.
- Bouw nieuwe vectoren vooraf op voordat je de standaardinstelling wijzigt.
- Evalueer met echte vragen en documenten waarvan de relevantie bekend is.
- Behoud de vorige index gedurende een periode waarin terugdraaien mogelijk is.
- Neem extra vectoren en indexen mee in de capaciteitsplanning voor schijf en RAM.
Veelgestelde vragen
Kunnen twee inbeddingsmodellen verschillende dimensies gebruiken in één database?
Ja, als de database afzonderlijke benoemde vectorruimten, collecties of indexen ondersteunt voor elke compatibele dimensie. Qdrant, Weaviate en pgvector bieden hier allemaal patronen voor.
Kan ik van inbeddingsmodel wisselen zonder oude documenten opnieuw in te bedden?
Niet als je de oude documenten doorzoekbaar wilt maken in de vectorruimte van het nieuwe model. Een nieuwe queryvector is niet compatibel met inbeddingen die door een ander model zijn geproduceerd.
Moet ik oude inbeddingen voor altijd bewaren?
Nee. Bewaar ze tijdens de evaluatie en voor terugdraaien. Zodra het nieuwe model is gevalideerd en de migratie is voltooid, kunnen verouderde vectoren aanzienlijk wat opslagruimte en indexgeheugen vrijmaken.
Eindoordeel
Meerdere inbeddingsmodellen kunnen probleemloos naast elkaar bestaan in één privézoeksysteem, zolang hun vectorruimten expliciet blijven. Sla model- en pijplijnmetadata op, bevraag elke ruimte met de bijbehorende encoder, voeg resultaten doelbewust samen en migreer door ze parallel opnieuw op te bouwen. Het gevaarlijke ontwerp is niet „meer dan één model”. Het is niet meer weten welk model welke vector heeft geproduceerd en doen alsof elke gelijkenisscore hetzelfde betekent.
Tech & AI HUB
Meer om te lezen

Top 10 lokale AI-webinterfaces voor homelabs in 2026
Vergelijk 10 lokaal zelfgehoste AI-webinterfaces voor homelabs, met aandacht voor Ollama-ondersteuning, RAG, agents, toegang voor meerdere gebruikers, installatie-inspanning en ideale gebruiksscenario’s.

Hoeveel kost GPT-6 Astra in de loop der tijd? Wanneer cloud-AI zinvol is versus lokale AI
Een praktische kostengids voor GPT-6 Astra over tokengebruik, langdurige AI-workloads, de afwegingen tussen cloud en lokaal, en waarom hybride AI-infrastructuur belangrijk is.

GPT-6 Astra versus lokale AI: Welke onderdelen van een agent moeten op je thuisserver blijven?
GPT-6 Astra kan in de cloud blijven, terwijl je thuisserver bestanden, geheugen, RAG, tools, machtigingen en duurzame agentstatus lokaal beheert.

