text-embedding-3-small is OpenAI's kleinere, goedkopere embeddingmodel, uitgebracht op 25 januari 2024 naast het grotere text-embedding-3-large. Een embeddingmodel zet tekst om in een vector van getallen met vaste lengte die de betekenis ervan representeert, in plaats van nieuwe tekst te genereren — twee passages met vergelijkbare betekenis produceren vectoren die dicht bij elkaar terechtkomen in die numerieke ruimte. Die eigenschap ligt aan de basis van semantisch zoeken, clustering, deduplicatie, aanbeveling en retrieval-augmented generation (RAG), waarbij een systeem opgeslagen passages moet rangschikken op relevantie voor een query voordat een taalmodel ze ooit te zien krijgt.
Waarvoor het is gebouwd
Standaard geeft text-embedding-3-small een vector van 1.536 dimensies. Op OpenAI's eigen MTEB-benchmark — een standaard evaluatiesuite voor retrieval, classificatie en clustering — scoort het 62,3, vóór het oudere text-embedding-ada-002-model met 61,0, ondanks dat ada-002 dezelfde 1.536 dimensies gebruikt. Met andere woorden: deze generatie verbeterde de kwaliteit bij een ongewijzigde vectorgrootte, wat een eenvoudige upgrade is voor iedereen die nog op de vorige generatie draait.
De maximale invoerlengte is 8.192 tokens per aanvraag, gelijk aan het grotere model. Output is alleen embedding: geen chat, geen generatie, geen toolgebruik — één enkele aanroep neemt een string en geeft een array van floats met vaste grootte terug.
De dimensions-parameter
Net als zijn grotere zusje ondersteunt text-embedding-3-small een dimensions-parameter die de outputvector inkort tot een kortere lengte zonder opnieuw te embedden via een ander model. Het inkorten van de vector vermindert opslag in een vectordatabase en versnelt gelijkenisvergelijkingen bij het bevragen, wat nuttig is wanneer de index groot genoeg is dat opslag en zoeklatency de kosten beginnen te domineren — een gangbare situatie zodra een corpus miljoenen documenten bereikt.
Waar het zijn plek verdient
De kernreden voor text-embedding-3-small is volume: hoge documentaantallen, frequente herindexering, en een querypatroon waarbij latencybudgetten krap zijn. De lagere kosten per aanroep en kleinere standaardvectorgrootte stapelen op schaal — elk geïndexeerd document en elke ge-embedde query brengt echte, doorlopende opslag- en rekenkosten met zich mee, en voor grote corpora telt dat op, ongeacht hoe goed de kwaliteit per embedding is.
Het is ook een redelijke standaardkeuze voor retrievaltaken die niet adversarieel of fijnmazig zijn: algemeen documentzoeken, FAQ-matching, deduplicatie van bijna-identieke content, en RAG-pipelines waarbij de retrievalstap "goed genoeg" moet zijn in plaats van maximaal precies, omdat het taalmodel dat de opgehaalde passages leest wat ruis in wat wordt opgehaald kan verdragen.
Waar de grenzen zichtbaar worden
De MTEB-kloof met text-embedding-3-large is echt, hoewel bescheiden, en verbreedt doorgaans bij moeilijkere retrievaltaken — onderscheid maken tussen nauw verwante passages, werken in minder gangbare talen, of veel vergelijkbare kandidaten precies rangschikken. Voor een RAG-systeem dat meetbaar relevante passages mist, of een zoekfunctie die bijna-missers teruggeeft, is de oplossing vaak overstappen naar het grotere model in plaats van het kleinere verder af te stellen.
Alternatieven om te overwegen
text-embedding-3-large is het natuurlijke upgradepad wanneer retrievalkwaliteit, niet kosten, de bottleneck is. text-embedding-ada-002 blijft beschikbaar maar wordt op kwaliteit overtroffen door dit model bij dezelfde vectorgrootte, dus er is weinig reden om het te kiezen voor nieuw werk. Buiten OpenAI leveren verschillende providers vergelijkbare algemene embeddingmodellen; het testen van retrievalkwaliteit tegen een representatieve steekproef van je eigen corpus is een betere leidraad dan alleen benchmarkscores, aangezien embeddingprestaties niet altijd gelijkmatig overdragen tussen domeinen.