Hoe kiest u het juiste embedding-model (inclusief het Nederlands)

Als een klant vraagt om "een RAG-systeem over onze technische documentatie", draait de eerste discussie vrijwel altijd om het grote taalmodel: Claude of GPT? Llama of Mistral? Lokaal of cloud? Het embedding-model blijft daarbij buiten beeld — de meeste teams grijpen naar OpenAI text-embedding-ada-002 omdat ze dat model in de eerste quickstart tegenkwamen, of naar wat de documentatie van het gekozen framework toevallig noemt.

De praktijk leert iets anders: het embedding-model is de plek waar 15–20 % van de totale kwaliteit van een retrieval pipeline wordt bepaald. Een slecht gekozen model zorgt ervoor dat relevante documenten wel in de top-20 terechtkomen, maar niet in de top-5 — waarna de LLM vanuit irrelevante context antwoordt. Voor Nederlandstalige inhoud is dit effect sterker dan voor Engelstalige, omdat de meeste populaire modellen overwegend op Engelse data zijn getraind. Dit artikel biedt een concreet selectiekader, inclusief wat wel en wat niet werkt voor het Nederlands.

Wat een embedding-model doet — en waarom de keuze ertoe doet

Een embedding-model zet tekst (document, vraag, zin) om in een vector — een reeks getallen waarbij gelijksoortige teksten geometrisch dicht bij elkaar liggen. Retrieval zoekt vervolgens naar vectoren die dicht bij de query liggen. Alles in de RAG-pipeline staat of valt met de vraag of "dichtbij in de ruimte" ook daadwerkelijk "semantisch relevant" betekent.

Twee dimensies waarop modellen van elkaar verschillen:

Vectordimensie (768, 1 024, 3 072, 4 096) — een hogere dimensie laat meer semantische informatie vast te leggen, maar verhoogt de geheugenbehoeften, opslagkosten en latentie bij similarity search. Moderne Matryoshka-modellen staan toe de dimensie na het trainen te verkleinen (bijv. van 3 072 naar 768) met minimaal kwaliteitsverlies — relevant bij het schalen naar tientallen miljoenen vectoren.

Contextvenster — hoeveel tokens het model effectief verwerkt bij het embedden van één chunk. Oudere modellen hadden een effectief venster van circa 512 tokens, ook al was de nominale limiet 8 192; moderne modellen (BGE-M3, Qwen3-Embedding, NV-Embed-v2) verwerken lange documenten zonder noemenswaardig kwaliteitsverlies. Voor een RAG-pipeline met document-aware chunking is dit direct relevant — als uw chunks 600–800 tokens bevatten, knipt een model met een effectief venster van 512 tokens ze af.

MTEB: handig hulpmiddel, geen dogma

MTEB (Massive Text Embedding Benchmark) is de meest gebruikte benchmark voor embedding-modellen. Het meet de prestaties op tientallen taken: retrieval, clustering, classificatie en semantische gelijkenis. De resultaten zijn openbaar beschikbaar op de Hugging Face-leaderboard en vormen een goed startpunt.

Drie beperkingen om in gedachten te houden:

• MTEB is primair Engelstalig. Een meertalig spoor bestaat, maar dekt slechts een deel van de talen — Nederlands is geen standaard MTEB-taalpad. De resultaten op MTEB Multilingual zijn dus indicatief, geen garantie voor Nederlandse prestaties.
• Benchmarkdata wijkt af van uw eigen data. Een model met een MTEB-score van 70 kan op uw specifieke domeininhoud (technische documentatie, juridische teksten, servicehandleidingen) aanzienlijk slechter presteren dan een model met score 65 dat op vergelijkbare inhoud is getraind.
• Benchmarkscores meten geen latentie of kosten. Een model met MTEB 70 en 400 ms latentie is voor een real-time applicatie een slechtere keuze dan een model met MTEB 67 en 15 ms.

MTEB is dus geschikt om een shortlist van 3–5 kandidaten samen te stellen. De uiteindelijke beslissing neemt u op basis van een test op uw eigen data.

Open-weight modellen: wanneer en waarom

Voor Europese bedrijven is het argument voor een self-hosted embedding-model sterker dan voor een zelf gehoste LLM. Een embedding-model:

• Draait op een gewone GPU-server. BGE-M3 haalt op een standaard GPU-server een latentie van tientallen milliseconden per request. Dat zijn heel andere hardwarevereisten dan voor een 70B LLM.
• Geen datalekkage. Documenten blijven in uw eigen infrastructuur — relevant voor gereguleerde sectoren en GDPR-compliance.
• Voorspelbare kosten. De geamortiseerde kosten van een GPU-server zijn vast; cloud-API-kosten groeien lineair met het volume.
• Aanpasbaarheid. Met voldoende domeindata kunt u het model natrainen (fine-tunen) op uw teksten — iets wat bij een cloud-API niet mogelijk is.

BGE-M3 (BAAI/FlagEmbedding) is in 2026 de productiestandaard voor open-weight meertalige deployments. Het combineert in één doorgang drie retrieval-typen: dense (semantisch), sparse (keyword-gebaseerd, BM25-stijl) en multi-vector (ColBERT-stijl, nauwkeuriger). Meer dan 100 talen inclusief Nederlands. Contextvenster van 8 192 tokens. Dimensie 1 024 (dense). Dit is onze interne default bij EU-klanten met lokale deployment.

Qwen3-Embedding (modelreeks van Alibaba, inclusief een 8B-variant) behaalt in 2026 de hoogste scores op de MTEB Multilingual-leaderboard — circa 70,58 voor Qwen3-Embedding-8B. Flexibele Matryoshka-dimensie (32–4 096), lang contextvenster van 32 768 tokens. Voor niet-Engelstalige retrieval is dit momenteel de sterkste open-weight kandidaat, mits u over voldoende hardware beschikt (het 8B-model vereist circa 16 GB VRAM bij volledige precisie, minder bij kwantisering).

Llama-Embed-Nemotron-8B (NVIDIA) behoort tot de top van de meertalige MTEB (250+ talen, open-weight, gratis). Als u NVIDIA-hardware hebt en de maximale score in de open-weight categorie nodig hebt, is dit een sterke kandidaat.

Voor snelle prototyping of lage-kostendeployments volstaan kleinere modellen uit de sentence-transformers-reeks — all-mpnet-base-v2 of paraphrase-multilingual-mpnet-base-v2 — maar hun prestaties voor het Nederlands liggen duidelijk lager dan die van BGE-M3.

Cloud-API-modellen: wanneer ze zinvol zijn

Cloud embedding-API's (OpenAI, Google, Cohere, Voyage AI) zijn zinvol in drie situaties:

1. 1.U beschikt niet over een eigen GPU. Deployment via een cloud-API is eenvoudiger, zonder hardwarebeheer.
2. 2.Aanvragen zijn sporadisch en het volume is laag. Bij enkele duizenden requests per dag loont het niet om de kosten van een eigen server te amortiseren.
3. 3.Multimodale vereisten. Als u tekst en afbeeldingen samen embedt (bijv. catalogi met technische tekeningen), lopen cloud-modellen zoals Cohere Embed v4 voorop.

OpenAI text-embedding-3-large (3 072 dimensies, Matryoshka, ~$0,13/1M tokens) is een betrouwbare, goed gedocumenteerde keuze voor Engelstalige inhoud. Voor Nederlandstalige inhoud zijn de prestaties iets lager dan bij meertalig geoptimaliseerde modellen.

OpenAI text-embedding-3-small (~$0,02/1M tokens) is interessant vanuit kostenperspectief — voor het Engels biedt het een goede prijs-kwaliteitverhouding, maar voor meertalig gebruik adviseren we 3-large of een overstap naar Cohere.

Cohere Embed v4 onderscheidt zich op twee punten: een contextvenster van 128 000 tokens (extreem lange documenten zonder chunking) en native multimodale ondersteuning (tekst + afbeeldingen). Prijs ~$0,12/1M tokens. Voor bedrijven die technische documentatie met afbeeldingen of schema's embedden, is dit een relevante combinatie.

Gemini Embedding 001 (Google) staat in 2026 bij de hoogste scores op MTEB English (~68), met Matryoshka-ondersteuning van 768 tot 3 072 dimensies. Prijs ~$0,004/1K tekens. Voor Engelstalige retrieval is dit een sterke cloud-keuze; voor Nederlandstalige inhoud geldt dezelfde kanttekening als bij de OpenAI-modellen.

Nederlands: wat werkt en wat niet

Nederlands is geen apart taalpad in de standaard MTEB-benchmark. Geverifieerde NL-specifieke benchmarks voor embedding-modellen zijn niet openbaar beschikbaar. Wat we weten uit de praktijk en aanverwante benchmarks (MIRACL, MKQA):

• Modellen die primair op het Engels zijn getraind (oudere ada-002, all-MiniLM) presteren voor Nederlandstalige teksten duidelijk onder hun Engelse benchmarkscore.
• BGE-M3, Qwen3-Embedding en Llama-Embed-Nemotron dekken het Nederlands als onderdeel van hun meertalige trainingsset — hun prestaties liggen dicht bij die op verwante Germaanse talen (Duits, Zweeds), wat in de praktijk goed werkt.
• Voor Nederlandstalige technische documentatie (machinebouwhandleidingen, elektrische projecten, NEN/ISO-normen) hebben wij interne tests uitgevoerd met BGE-M3 versus OpenAI text-embedding-3-large — BGE-M3 liet consistent 8–12 % hogere precision@5 zien. Geen dramatisch verschil, maar het loopt op bij complexere inhoud.
• Als u over voldoende Nederlandstalige domeindata beschikt (~5 000+ documenten), kunt u een embedding-model natrainen op uw inhoud (fine-tuning via de sentence-transformers-bibliotheek). In gereguleerde sectoren (recht, geneeskunde) kan dat de precisie nog eens 5–10 % verbeteren.

Voor hybride search (BM25 + vectoren) geldt dat voor Nederlandstalige inhoud met precieze terminologie (normnummers, wetsartikelen, onderdeelcodes) de BM25-trefwoordlaag belangrijker is dan bij het Engels — het embedding-model kan morfologische varianten normaliseren ("aandrijving" vs. "aandrijvingen"), maar exacte tekenreeksen worden door BM25 betrouwbaarder opgevangen.

Dimensie versus kwaliteit versus kosten: een praktisch kader

Het is niet zo dat een hogere dimensie automatisch betere prestaties geeft. Matryoshka-modellen maken het mogelijk om op de volledige dimensie te trainen (3 072 of 4 096) en bij inference te reduceren (256, 512, 768) — het kwaliteitsverlies is minimaal, terwijl de winst in snelheid en opslagkosten reëel is.

Indicatieve keuzes voor verschillende scenario's:

• Snelle PoC, Engelstalige inhoud, cloud: text-embedding-3-small (1 536 dim, lage kosten) of text-embedding-3-large gereduceerd naar 512 dim via Matryoshka.
• Productie cloud, meertalige EU-inhoud: Cohere Embed v4 (multimodaal + lange context) of Gemini Embedding 001.
• Self-hosted, NL/DE/PL-inhoud: BGE-M3 is de default. Voor een groter model met hogere score: Qwen3-Embedding-8B of Llama-Embed-Nemotron-8B.
• Schalen naar tientallen miljoenen vectoren: overweeg Matryoshka-dimensiereductie (bijv. naar 768) — bij 50 M vectoren is de opslagbesparing aanzienlijk.
• Multimodale inhoud (tekst + afbeeldingen): Cohere Embed v4 of Voyage AI voyage-multimodal-3.5.

Voor een vergelijking van de vectordatabases waarin u deze embeddings opslaat, zie Vectordatabases — vergelijking Qdrant, Weaviate, pgvector, Milvus.

Domain fit: de meest over het hoofd geziene factor

Een MTEB-benchmarkscore zegt iets over gemiddelde prestaties op gevarieerde testsets. Uw werkelijke inhoud is smal en specifiek:

• Machinebouwdocumentatie (tekenaantekeningen, servicehandleidingen, ISO-normen) — technische taal met precieze terminologie, afkortingen, onderdeelnummers. Dense embedding legt de semantiek vast; de BM25-laag vangt exacte codes op. De hybride modus van BGE-M3 is hier een voordeel.
• Juridische teksten (arbeidswetboek, contracten, normen) — formele taal, artikelverwijzingen, nadruk op exacte bewoordingen. Tests tonen aan dat een domeinspecifiek nagetraind model (fine-tuned op Nederlandstalige juridische teksten) een generiek model met 10–15 % precisie overtreft.
• Interne bedrijfs-KB (e-mails, vergaderverslagen, procesbeschrijvingen) — gevarieerde taal, uiteenlopende schrijfstijlen. Een generiek model werkt hier goed; natraining heeft pas zin bij grote volumes (50k+ documenten).
• Productcatalogus (SKU's, beschrijvingen, technische parameters) — korte teksten, exacte overeenkomsten. Voor e-commerce of distributiecatalogi weegt BM25 zwaar mee; het embedding-model vult de semantiek aan ("blauwe bout met metrische schroefdraad" = "M6 blauwe bout DIN 912").

Stel uzelf vóór de modelkeuze de vraag: welk deel van uw zoekvragen vereist semantisch begrip versus exacte lexicale overeenkomst? Voor industriële bedrijven met technische documentatie is hybride retrieval vrijwel altijd de juiste keuze — en bij hybride retrieval heeft u een embedding-model nodig dat native sparse vectoren ondersteunt (BGE-M3), of u moet bereid zijn een apart BM25-index te beheren.

Evaluatie: hoe test u vóór deployment

Baseer uw beslissing niet alleen op MTEB — bouw een mini-evaluatieset:

1. 1.Selecteer 100–200 echte zoekvragen die uw productie-use-case weerspiegelen.
2. 2.Identificeer voor elke vraag handmatig de "ideale" brondocumenten (ground truth).
3. 3.Voer retrieval uit (top-5 of top-10) voor elk kandidaatmodel.
4. 4.Meet precision@5 en recall@10 — het percentage relevante documenten in de top-5/10.
5. 5.Vergelijk ook de latentie en de kosten van het embedden van het volledige corpus.

Met 2–3 dagen werk toont deze test het werkelijke verschil tussen modellen op uw data. Ervaringsregel: voor Engelstalige inhoud liggen kandidaten 3–8 % precision uit elkaar. Voor Nederlandstalige technische inhoud zijn de verschillen groter — wij hebben verschillen van 15–20 % gemeten tussen een zwakker EN-primair model en BGE-M3.

Voor de evaluatie van de volledige RAG-pipeline (niet alleen retrieval, maar ook generatiekwaliteit), zie Hoe evalueert u RAG (RAGAS).

Veelgestelde vragen

Is BGE-M3 nog steeds een actuele keuze in 2026?

Ja. BGE-M3 blijft de productiestandaard voor open-weight meertalige deployments, juist vanwege de unieke combinatie van dense + sparse + multi-vector retrieval in één doorgang — geen enkel ander open-weight model biedt dit in één model. Qwen3-Embedding-8B haalt hogere MTEB-scores, maar vereist meer hardware en levert geen native sparse retrieval. Voor de meeste EU-klanten met een bestaande GPU-server blijft BGE-M3 een uitstekende default.

Heb ik voor het Nederlands een speciaal model nodig?

Niet per se. BGE-M3, Qwen3-Embedding en Llama-Embed-Nemotron dekken het Nederlands als onderdeel van hun trainingsset en functioneren goed in de praktijk. Een speciaal op het Nederlands getraind embedding-model bestaat in 2026 niet als publiek open-weight SOTA-model. Als u een groot volume Nederlandstalige domeindata hebt (10k+ documenten), kan het natrainen van een generiek meertalig model op uw inhoud betere resultaten opleveren — maar dat is op zichzelf een project, niet iets dat kant-en-klaar beschikbaar is.

Kan ik één embedding-model gebruiken voor zowel retrieval als reranking?

Nee — een embedding-model (bi-encoder) en een reranker (cross-encoder) zijn architecturaal verschillend. Het embedding-model codeert documenten en queries onafhankelijk als vector (snel); de reranker beoordeelt een paar (query + document) gezamenlijk (nauwkeuriger, langzamer). Voor een complete pipeline heeft u beide nodig — meer hierover in het artikel RAG-pipeline — 3 instellingen die de kwaliteit bepalen.

Wat kost het embedden van een volledige bedrijfskennisbank?

Dat hangt af van het volume. Indicatief: 1 miljoen tokens via OpenAI text-embedding-3-large kost ~$0,13; via 3-small ~$0,02. Voor een corpus van 10 000 pagina's PDF (~5 M tokens) bedragen de eenmalige embeddingkosten via cloud-API enkele tientallen dollars. Bij self-hosted BGE-M3 zijn de kosten na de aanschaf van de GPU-server vrijwel nul. Her-embedden (bij modelwisseling of gewijzigde chunking) kost hetzelfde bedrag opnieuw — reden te meer om meteen het juiste model te kiezen.

Wanneer is fine-tuning van een embedding-model zinvol?

Wanneer u domeininhoud heeft waarop een generiek model systematisch tekortschiet (precisie onder 70 %), u over voldoende data beschikt (doorgaans 5 000+ relevante query-documentparen) en u een productiesysteem heeft waarbij elk procentpunt precisie zakelijke waarde heeft. Gereguleerde sectoren (recht, geneeskunde) zijn het klassieke voorbeeld. Voor een doorsnee interne kennisbank is fine-tuning buiten proportie — BGE-M3 of Qwen3-Embedding volstaat.

*MP Industrial Solutions helpt bedrijven bij het ontwerpen en uitrollen van RAG-architectuur, van de keuze van het embedding-model via de chunkingstrategie tot de vectordatabase en de evaluatie-harness. Als u voor een keuze staat of de prestaties van een bestaande deployment wilt meten, voeren wij graag een gratis audit van 90 minuten uit.*