Tekstembeddings uitgelegd: zo werken ze [+voorbeelden]

Ben je bekend met het basisconcept van tekstembeddings, maar vraag je je af hoe je ze in de praktijk inzet? Dan ben je hier aan het juiste adres. We ontleden vectoren, tokenisatie en gelijkenisberekening, duiken diep in het evalueren van embeddingmodellen en laten je praktijkvoorbeelden zien.

Wat zijn tekstembeddings?

Tekstembeddings zijn numerieke representaties van woorden, zinnen of documenten die hun semantische betekenis en onderlinge relaties vastleggen. Ze worden gegenereerd door embeddingmodellen die tekst omzetten in vectoren — reeksen getallen die machinelearningalgoritmen kunnen verwerken en vergelijken.

ML-engineers gebruiken tekstembeddings om softwareapplicaties te helpen relaties tussen woorden en zinnen te herkennen, waardoor het eenvoudiger wordt om grote hoeveelheden data te doorzoeken, te categoriseren en te analyseren.

Stel dat je dagelijks duizenden supporttickets binnenkrijgt. Klanten melden alle denkbare problemen, maar jij moet ze categoriseren en labelen. Een manier om dit proces te automatiseren is om met een voorgetraind tekstembeddingmodel elk ticket om te zetten in een vector.

Twee klanten sturen bijvoorbeeld de volgende berichten:

• “Er is twee keer voor mijn abonnement afgeschreven”: [0.21, -0.47, 0.83, ...]
• “Er staat een dubbele betaling op mijn account”: [0.19, -0.45, 0.80, ...]

Dit zijn vereenvoudigde vectoren ter illustratie.

Hoewel de klanten verschillende woorden gebruiken, beschrijven ze hetzelfde probleem. Het embeddingmodel legt dit verband vast door hun vectoren dicht bij elkaar te plaatsen in een wiskundige ruimte. Beide tickets worden gecategoriseerd en doorgestuurd naar het factureringsteam.

Toepassingen van tekstembeddings in het bedrijfsleven

Tekstembeddings worden gebruikt bij uiteenlopende taken binnen natural language processing (NLP), waaronder:

• Semantisch zoeken: Relevante informatie vinden op basis van betekenis. Delivery Hero gebruikt product- en zoekopdrachtembeddings naast zoeken op trefwoorden om klanten die boodschappen doen relevante producten te laten vinden. Een zoekopdracht naar “vetarme yoghurt” kan bijvoorbeeld Griekse yoghurt of yoghurt met 0,5% vet opleveren, zelfs zonder exacte overeenkomst in de formulering.
• Tekstclassificatie: Tekst categoriseren, bijvoorbeeld door spam-e-mails te herkennen of documenten op onderwerp te sorteren. MindCraft.ai ontwikkelde een documentclassificatiesysteem dat op transformers gebaseerde tekstembeddings en machine learning gebruikt om bedrijfsdocumenten te categoriseren en gevoelige informatie te identificeren voor naleving van de AVG.
• Clustering: Vergelijkbare documenten of tekstfragmenten groeperen om patronen te herkennen. Doczy.ai zet contracttekst om in embeddings en groepeert semantisch verwante clausules en concepten, zelfs wanneer verschillende contracten vergelijkbare verplichtingen in andere bewoordingen uitdrukken.
• Retrieval-augmented generation (RAG): Relevante informatie ophalen die een LLM kan gebruiken om nauwkeurigere, contextbewuste antwoorden te genereren. Ring gebruikt tekstembeddings van Amazon Titan in een meertalige RAG-chatbot om relevante supportdocumentatie op te halen voordat er antwoorden worden gegenereerd op vragen van klanten in internationale markten.
• Aanbevelingssystemen: Gerelateerde artikelen, producten of andere content voorstellen op basis van tekstuele overeenkomsten. Het JUDE-systeem van LinkedIn gebruikt door een LLM gegenereerde tekstembeddings van vacatureteksten en ledenprofielen om vacatureaanbevelingen te verbeteren, waarbij verbanden worden gelegd tussen de achtergrond van kandidaten en beschikbare functies.
• Named entity recognition (NER): Helpen bij het herkennen en classificeren van namen van personen, organisaties en plaatsen in tekst. Amazon Health Services gebruikt NER om medische concepten in vragen van klanten te herkennen, zoals ziekten, symptomen, medicijnen en behandelingen. Dat inzicht wordt gecombineerd met op embeddings gebaseerd zoeken naar gelijkenis om vragen te koppelen aan relevante zorgproducten en -diensten.
• Machinevertaling: Modellen ondersteunen die tekst van de ene naar de andere taal vertalen. Transglot gebruikt tekstembeddings in een semantisch vertaalgeheugen om eerder vertaalde passages met een vergelijkbare betekenis te herkennen, zodat lokalisatieworkflows bestaande vertalingen kunnen hergebruiken.

Hoe werken tekstembeddings?

Hoe bepaalt een embeddingmodel dan welke numerieke waarden het aan een stuk tekst toekent, en waarom zouden we het vertrouwen?

Het begint allemaal met training. Embeddingmodellen leren van grote tekstverzamelingen en zoeken naar patronen in hoe woorden samen worden gebruikt. Traditionele modellen zoals Word2Vec leren bijvoorbeeld door een woord te voorspellen op basis van de omliggende woorden, of andersom. Moderne, op retrieval gerichte modellen gebruiken vaak contrastive learning. Ze worden getraind om relevante paren van zoekopdracht en document hogere gelijkenisscores te geven dan niet-gerelateerde paren.

Vergroten

Zodra het model is getraind, gebeurt het volgende wanneer je het een nieuw stuk tekst geeft:

1. Tokenisatie. Het model splitst de tekst eerst op in kleinere stukjes, die tokens worden genoemd. Dat kunnen hele woorden, delen van woorden of leestekens zijn. Elk token krijgt een numerieke ID uit de vocabulaire van het model, die op zichzelf geen betekenis heeft.
2. Encoding en pooling. Het model verwerkt deze tokens met de patronen die het tijdens de training heeft geleerd en produceert een vector. Elk getal in de vector is een coördinaat of component, en een dimensie is de as waarlangs dat getal de positie van de vector bepaalt. Elke waarde draagt bij aan de positie van de tekst in een wiskundige ruimte, die bekendstaat als een embeddingruimte.
3. Gelijkenisberekening. Om gerelateerde tekst te vinden, vergelijkt een retrievalsysteem de embedding van de zoekopdracht met documentembeddings aan de hand van een gelijkenismaat zoals cosinusgelijkenis of het inproduct

Zo tonen webwinkels bijvoorbeeld passende artikelen bij de zoekopdracht van een gebruiker.

Wat is het verschil tussen woord-, zins- en documentembeddings?

Vergroten

Het belangrijkste verschil is hoeveel tekst elke embedding in één vector vertegenwoordigt. Je kunt embeddings maken voor afzonderlijke woorden, volledige zinnen of hele documenten, afhankelijk van welke informatie je wilt vastleggen.

• Woordembeddings leggen relaties tussen afzonderlijke woorden vast en herkennen bijvoorbeeld dat “storing” en “uitval” verwante begrippen zijn.
• Zinsembeddings begrijpen de betekenis van hele zinnen, zelfs wanneer die hetzelfde idee in andere woorden uitdrukken.
• Documentembeddings representeren een volledig document als één vector, in plaats van voor elke zin een aparte vector te maken. Dit helpt om het algemene onderwerp te behouden en andere documenten over hetzelfde onderwerp te vinden; details zijn echter moeilijker (zo niet onmogelijk) op te halen.

Hoe fijnmazig moet je te werk gaan? Het juiste niveau hangt af van je data en van wat je wilt bereiken.

Bij grotere documenten is het gebruikelijk om de tekst op te splitsen in kleinere chunks en voor elke chunk een aparte embedding te genereren. Zo krijg je de algehele betekenis van het document ÉN specifieke details, die bij documentembeddings verloren kunnen gaan.

Hoeveel invloed heeft de chunkgrootte op de kwaliteit van embeddings?

Behoorlijk veel. Volgens Rahul Kumar, VP of AI Engineering bij Xenoss, zit de uitdaging in het vinden van een chunkgrootte die één volledig idee vastlegt zonder belangrijke context te verliezen. Hij legt de afweging uit:

“De chunkgrootte bepaalt hoeveel semantische context één embedding bevat. Een grotere chunk geeft de vector meer context, maar middelt ook meer onderwerpen uit in één vector. Een chunk die drie onderwerpen beslaat, belandt in het midden en komt met geen van alle goed overeen. Een kleinere chunk houdt de betekenis scherp, maar kan de context verliezen die hem vindbaar maakte.”

Daarom raadt Kumar aan om een chunkingstrategie te kiezen op basis van de content, in plaats van vast te houden aan één vaste grootte. Zoals hij het zegt: “een vaste grootte met overlap is alleen geschikt voor uniforme tekst, zoals e-mails of gescrapete webpagina's.”

Voor gestructureerde documenten zoals contracten of beleidsstukken past recursief, structuurbewust opsplitsen beter. Semantische chunking kan daarentegen goed werken voor transcripten, omdat de tekst wordt opgesplitst waar het onderwerp of de betekenis verschuift.

Tekstembeddings vs. zoeken op trefwoorden

Waarom zou je tekstembeddings gebruiken als je ook gewoon op trefwoorden kunt zoeken? Omdat zoeken op trefwoorden afhankelijk is van overeenkomende termen, terwijl semantisch zoeken op basis van embeddings relevante informatie kan ophalen, zelfs wanneer de zoekopdracht en het document verschillende woorden gebruiken.

Maar semantische gelijkenis betekent niet altijd relevantie. Shaw Talebi, oprichter van AI Builder Academy, demonstreert deze beperking aan de hand van een zoeksysteem voor cv's. Toen Talebi zocht naar een “data engineer met ervaring met Apache Airflow”, noemde slechts één van de vijf beste resultaten Apache Airflow, en dat resultaat stond op de derde plaats — terwijl drie andere cv's in de dataset die vaardigheid wel vermeldden.

Semantisch zoeken is dus nuttig om conceptueel verwante informatie te vinden, maar kan exacte vereisten missen, zoals technische vaardigheden, product-ID's of foutcodes.

Om dit probleem op te lossen, raadt Rahul Kumar aan een retrievalaanpak te kiezen op basis van waar het retrievalsysteem tekortschiet:

• Hybride zoeken (de combinatie van trefwoordmatching en semantisch zoeken) is de standaard wanneer zoekopdrachten exacte termen bevatten, zoals SKU's, foutcodes of juridische verwijzingen.
• Rerankers zijn hun kosten waard wanneer alleen de bovenste paar resultaten ertoe doen, zoals bij antwoorden die worden gegenereerd uit opgehaalde context.
• Graph retrieval helpt wanneer het antwoord verspreid is over meerdere verbonden gegevensbronnen.

Kumar vertelde ook hoe zijn team deze benaderingen in de praktijk toepaste. In één project voerden ze BM25-trefwoordzoekopdrachten en vectorzoekopdrachten naast elkaar uit, voegden ze de resultaten samen met reciprocal rank fusion (RRF) en gebruikten ze een LLM om de 124 beste resultaten opnieuw te rangschikken en terug te brengen tot 6.

“De overstap naar graph-first retrieval, waarbij vectorzoekopdrachten vergelijkbare latente ruimtes vinden en daarna een graafwandeling van twee hops volgt, verhoogde de rankingkwaliteit (nDCG) van 0,58 naar 0,67 en verkortte de p90-retrievaltijd van 19 s naar minder dan 3 s”, voegt Kumar toe.

Soorten tekstembeddingmodellen

Alle embeddingmodellen doen in grote lijnen hetzelfde: ze leren relaties in tekst. Ze verschillen echter in de taak waarvoor ze zijn getraind, de informatie die ze meewegen en de taken waarvoor ze zijn ontworpen.

Statische woordembeddingmodellen

Traditionele woordembeddingmodellen leren dense numerieke representaties van woorden op basis van patronen in woordgebruik in grote tekstverzamelingen. Deze embeddings zijn statisch, wat betekent dat elk woord dezelfde vector krijgt, ongeacht de betekenis ervan in een bepaalde context.

Twee bekende methoden zijn:

• Word2Vec: Dit model, in 2013 ontwikkeld door Google, leert representaties op basis van naburige woorden met behulp van twee architecturen: Continuous Bag of Words (CBOW), dat een woord voorspelt op basis van de woorden eromheen, en skip-gram, dat naburige woorden voorspelt op basis van een gegeven woord.
• GloVe (Global Vectors for Word Representation): Dit model, in 2014 ontwikkeld aan Stanford, gebruikt statistieken over het samen voorkomen van woorden om relaties tussen woorden te leren.

Gecontextualiseerde taalmodellen

In tegenstelling tot statische embeddings produceren algemene taalmodellen contextuele representaties die veranderen afhankelijk van de omliggende tekst. Zo kunnen modellen onderscheid maken tussen verschillende betekenissen van hetzelfde woord.

• BERT (2018, Google): Gebruikt bidirectionele self-attention om rekening te houden met woorden aan beide kanten van een token. Het genereert bijvoorbeeld verschillende representaties voor “bank” in “Ik heb geld bij de bank gestort” en “Ik zat op de bank aan de rivier.”
• GPT (2018, OpenAI): Gebruikt op transformers gebaseerde representaties die rekening houden met voorafgaande tekst bij het voorspellen van het volgende token. GPT-modellen zijn primair ontworpen voor het genereren van taal.

Embeddingmodellen voor zinnen en documenten

Deze modellen representeren langere stukken tekst, van afzonderlijke zinnen tot alinea's en hele documenten, als vectoren.

• Doc2Vec: Breidt leren in de stijl van Word2Vec uit naar zinnen, alinea's en documenten. Het kan helpen om verwante artikelen te groeperen of documenten op onderwerp te classificeren.
• Universal Sentence Encoder (USE): In 2018 ontwikkeld door Google om representaties met een vaste lengte van zinnen en korte alinea's te genereren voor semantische gelijkenis en tekstclassificatie.
• Sentence-BERT (SBERT, 2019): Dit model, ontwikkeld door Nils Reimers en Iryna Gurevych aan de Technische Universität Darmstadt, bouwt voort op het BERT-model van Google en wordt veel gebruikt voor semantisch zoeken, het detecteren van parafrasen en clustering.
• pplx-embed-v1 (2026, Perplexity): Deze familie van state-of-the-art tekstembeddingmodellen, gebouwd voor retrieval op webschaal in de praktijk, gebruikt op diffusie gebaseerde pretraining om een causaal taalmodel om te zetten in een bidirectionele encoder. Het model genereert dense embeddings voor onafhankelijk gecodeerde zoekopdrachten en documenten, met quantization-aware training om de opslagkosten te verlagen. Ons 4B INT8-model behaalde 69,66 nDCG@10 op de meertalige MTEB-retrievalbenchmark, tegenover 67,71 voor gemini-embedding-001 van Google.
• pplx-embed-context-v1 (2026, Perplexity): Pakt een veelvoorkomend probleem bij het opdelen van documenten in chunks aan: passages kunnen hun betekenis verliezen wanneer ze los van de omliggende tekst staan. Met late chunking verwerkt het model eerst het document voordat het gecontextualiseerde tokenrepresentaties poolt tot afzonderlijke chunkembeddings. Ons 4B-model behaalde 81,96 nDCG@10 op ConTEB, tegenover 79,45 voor voyage-context-3.
• pplx-embed-v2-context (2026, Perplexity): Gaat nog een stap verder met contextuele retrieval. In plaats van alleen te trainen op het vinden van de passage die een antwoord bevat, leert het model ondersteunende passages te herkennen die helpen dat antwoord uit te leggen of te verifiëren. Tijdens de training gebruikt het model relevantiesignalen die zijn gedistilleerd uit een model voor contextcompressie, zonder dat dat teachermodel nodig is tijdens inferentie. Onze 9B-preview behaalde een antwoordrecall van 45,5% en een bewijsrecall van 40,6% bij 10 resultaten op context-bench.

De modellen van Perplexity maken het ook mogelijk om embeddings op grote schaal op te slaan. Ze produceren INT8- en binaire embeddings, waardoor de benodigde opslag respectievelijk 4x en 32x kleiner wordt dan bij FP32.

Dimensies, contextlengte, kwantisatie en poolingconfiguratie van de pplx-embed-modellen

Dense, sparse en multivectorembeddings

Er is nog één onderscheid dat de moeite waard is om te begrijpen, vooral voor semantisch zoeken. Embeddingmodellen kunnen verschillen in hoe ze tekst representeren en relevantie berekenen.

• Dense embeddings: Representeren tekst met compacte vectoren waarin de meeste waarden niet nul zijn.
• Sparse embeddings: Gebruiken vectoren die grotendeels uit nullen bestaan, met aangeleerde gewichten die aan belangrijke termen zijn gekoppeld. Modellen zoals SPLADE (2021) leren welke termen ertoe doen bij het ophalen van relevante documenten.
• Multivectorembeddings: Behouden meerdere vectoren voor een stuk tekst, waardoor gedetailleerdere vergelijkingen tussen zoekopdrachten en documenten mogelijk zijn. Modellen zoals ColBERT (2020) gebruiken deze representaties voor gedetailleerdere vergelijkingen tussen zoekopdracht en document.
• Modellen die meerdere benaderingen combineren: BGE-M3 (2024), ontwikkeld door BAAI, ondersteunt dense, sparse en multivector-retrieval binnen hetzelfde model.

Zo kies en evalueer je een tekstembeddingmodel

Openbare benchmarks zoals MTEB zijn een goed startpunt. Gebruik ze om een shortlist te maken van twee of drie modellen die jouw talen, invoerlengtes en implementatievereisten ondersteunen. Maar wijs nog geen winnaar aan. We kunnen niet genoeg benadrukken hoe belangrijk het is om die modellen op je eigen data te testen.

Dit is een praktische evaluatieworkflow:

1. Stel een testdataset samen. Verzamel 50 tot 100 representatieve zoekopdrachten als eerste evaluatieset (mogelijk heb je er meer nodig), inclusief lastige gevallen zoals parafrasen, technische terminologie en exacte foutcodes. Bepaal voor elke zoekopdracht welke documenten of passages relevante antwoorden bevatten. Deze relevantielabels vormen je ground truth.
2. Meet de retrievalkwaliteit. Test elk model op dezelfde evaluatiedataset en houd de documentvoorbereiding en de retrievalomstandigheden vergelijkbaar, terwijl je de modelspecifieke vereisten voor queryopmaak, normalisatie en gelijkenisscores volgt. Bereken vervolgens de volgende metrics met de InformationRetrievalEvaluator van Sentence Transformers:
   • Recall@k: Geeft het aandeel relevante passages dat in de eerste k resultaten voorkomt.
   • MRR: Meet hoe hoog het eerste relevante resultaat in de rangschikking staat.
   • nDCG@k: Meet hoe goed de eerste k resultaten op basis van hun relevantie zijn gerangschikt.
3. Benchmark de latentie en doorvoer. Meet hoe lang elk model nodig heeft om een query te embedden en rapporteer idealiter de mediane latentie (p50) en de latentie op het 95e percentiel (p95) onder realistische belasting.
4. Bereken de opslag- en bedrijfskosten. Vectoropslag hangt af van het aantal embeddings, hun dimensies en de numerieke precisie. Zo is voor een miljoen 768-dimensionale FP32-embeddings ongeveer 3,1 GB aan ruwe vectoropslag nodig, exclusief de overhead voor indexering. Om de benodigde opslag te verkleinen, kun je de vectoren kwantiseren naar een lagere numerieke precisie. Overstappen van FP32 naar INT8 vermindert de ruwe vectoropslag bijvoorbeeld ongeveer met een factor 4. Compressie kan echter de retrievalkwaliteit beïnvloeden, dus voer je evaluaties opnieuw uit om de afweging te controleren.

Vergelijk ten slotte de resultaten naast elkaar: retrievalmetrics, p95-latentie, doorvoer, opslag en kosten. Kies het model dat binnen je productiebeperkingen aan je kwaliteitseisen voldoet.

Wanneer gebruik je embeddings in plaats van een LLM?

Nu LLM's alles afhandelen, van documentanalyse tot complex redeneren, is het erg verleidelijk om al je tekst in een model te stoppen en het dat zelf te laten uitzoeken. Maar daar betaal je waarschijnlijk niet graag voor.

Bovendien zijn LLM's beter in beoordelen en formuleren, maar worden ze beperkt door hoeveel informatie er in één prompt past. Embeddings zijn daarentegen goedkoop, snel en consistent, en werken op schaal van miljoenen items.

“Embeddings winnen bij zoeken, aanbevelingen (‘meer zoals dit’), het opsporen van duplicaten, zoals herhaalde supporttickets, en het groeperen van grote hoeveelheden content op onderwerp. Ze presteren ook goed in meerdere talen. Een LLM wint wanneer de taak redeneren vereist: samenvatten, opties vergelijken of een antwoord schrijven. De meeste echte systemen hebben beide nodig, waarbij elk het deel doet waar het goed in is”, concludeert Kumar.

Wat ontwikkelaars fout doen bij tekstembeddings

Om te ontdekken wat ontwikkelaars vaak over het hoofd zien, sprak ik met Rahul Kumar en Xibeijia Guan, datawetenschapper bij Ahrefs. Zij wezen op zes fouten waar je op moet letten:

• Tekstvoorbewerking overslaan. Als de invoergegevens HTML, navigatiemenu's, advertenties of andere irrelevante content bevatten, kunnen voorbewerkingsstappen zoals het verwijderen van boilerplate de embeddingkwaliteit verbeteren door onnodige informatie weg te halen.
• De maximale invoerlengte van het model negeren. Verschillende modellen hebben verschillende tokenlimieten en verschillend afkapgedrag. Tekst die de limiet overschrijdt, kan worden afgekapt, waardoor belangrijke informatie verloren gaat.
• Modelspecifieke vereisten niet volgen. Sommige embeddingmodellen vereisen specifieke prefixen, zoals query: en passage:, of verschillende instructies voor verschillende taken. Als je deze vereisten niet volgt, kunnen de retrievalprestaties afnemen.
• Een incompatibele gelijkenismaat gebruiken. Cosinusgelijkenis en het inwendig product (dot product) zijn niet altijd uitwisselbaar. Controleer of de embeddings genormaliseerd zijn en gebruik de scoringsmethode die wordt aanbevolen voor het model en de vectorindex.
• Thematische gelijkenis verwarren met relevantie. In collecties binnen een smal domein kunnen veel documenten semantisch op elkaar lijken zonder dezelfde vraag te beantwoorden. Analyseer mislukte query's en rangschikkingsverdelingen. Test lexicale of hybride retrieval, reranking en metadatafilters wanneer gebruikers exacte informatie nodig hebben.
• Normalisatie van embeddings negeren. Verschillende embeddingmodellen kunnen genormaliseerde of niet-genormaliseerde vectoren opleveren. Controleer of de embeddings genormaliseerd zijn en of extra normalisatie nodig is, afhankelijk van de gelijkenismetriek die je gebruikt.

Veelgestelde vragen over tekstembeddings

1. Hoe genereer ik tekstembeddings?

De eenvoudigste aanpak is een vooraf getraind embeddingmodel te gebruiken. Met de Python-bibliotheek Sentence Transformers kun je bijvoorbeeld een model zoals all-MiniLM-L6-v2 laden, je tekst doorgeven aan model.encode(), en een numerieke vector terugkrijgen. Je kunt embeddings ook via een API genereren.

Voor semantisch zoeken of RAG splits je je documenten doorgaans op in chunks, genereer je voor elke chunk een embedding en sla je de vectoren op in een doorzoekbare index.

2. Wat zijn de beste embeddingmodellen voor tekst?

Afhankelijk van wat je bouwt, zijn verschillende modellen het overwegen waard:

• pplx-embed-v1 van Perplexity: Gebouwd voor grootschalige dense retrieval, met INT8- en binaire embeddings die de benodigde vectoropslag verkleinen.
• pplx-embed-context-v1 van Perplexity: Handig voor het ophalen van passages uit lange documenten waarin afzonderlijke chunks zonder hun omringende context hun betekenis verliezen.
• all-MiniLM-L6-v2: Geschikt voor lichtgewicht, lokaal semantisch zoeken, clustering en taken rond zinsgelijkenis. Produceert compacte 384-dimensionale vectoren, maar kapt invoer af die langer is dan 256 woorddelen (word pieces).
• BGE-M3: Handig voor meertalige RAG en hybride retrieval. Ondersteunt meer dan 100 talen en combineert dense, sparse en multivectorrepresentaties.
• Qwen3-Embedding: Een sterke kandidaat voor meertalig zoeken, het ophalen van code en taakspecifieke embeddings. Biedt open-weight-modellen van 0,6B, 4B en 8B met ondersteuning voor instructies.
• text-embedding-3-large van OpenAI: Een API-gebaseerde optie voor semantisch zoeken en het ophalen van documenten als je zelf geen model wilt hosten. Ondersteunt tot 3.072 dimensies, die je kunt verminderen om opslag te besparen.
• De Gemini Embedding-modellen van Google: Handig voor beheerde retrievaltoepassingen. Gemini Embedding 2 ondersteunt bovendien zoeken in tekst, afbeeldingen, audio, video en pdf's binnen een gedeelde embeddingruimte.

3. Kan ik een LLM als embeddingmodel gebruiken?

Ja, maar er is een verschil tussen een LLM voor algemene doeleinden en een LLM dat is geoptimaliseerd voor embeddings. LLM's produceren interne vectorrepresentaties van tekst, die je kunt extraheren en poolen tot één embedding. Zonder aanvullende training zijn die vectoren echter niet per se bruikbaar voor semantisch zoeken.

Qwen3-Embedding gebruikt bijvoorbeeld een LLM-backbone die verder is getraind voor embedding- en retrievaltaken. Je kunt een LLM dus wel aanpassen om embeddings te genereren, maar een speciaal embeddingmodel is meestal het praktischere startpunt.