text-embedding-3-large is OpenAI's higher-quality embedding model, released January 25, 2024 alongside the smaller text-embedding-3-small. An embedding model does not generate text — it converts a piece of text into a fixed-length vector of numbers that captures its meaning, so that two pieces of text with similar meaning end up as vectors that sit close together in that numeric space. That property is what makes embeddings useful for semantic search, clustering, deduplication, recommendation, and retrieval-augmented generation (RAG), where a system needs to find the passages most relevant to a query before handing them to a language model.
What "large" buys over "small"
By default, text-embedding-3-large produces a 3,072-dimension vector, versus 1,536 for text-embedding-3-small. On OpenAI's own MTEB benchmark, a standard suite for evaluating embedding quality across retrieval, classification, and clustering tasks, large scores 64.6 against small's 62.3 — a real but not enormous quality gap. The larger model captures more nuance per embedding, which tends to matter most on harder retrieval tasks: distinguishing between closely related documents, working across less common domains or languages, or ranking many similar candidates against each other.
The dimensions parameter
Both models support a dimensions parameter that shortens the output vector by truncating it, without needing to re-embed the text through a different model. According to OpenAI, a text-embedding-3-large vector shortened to 256 dimensions still outperforms the older, unshortened text-embedding-ada-002 model at its native 1,536 dimensions. This matters operationally: a shorter vector takes less storage in a vector database and is cheaper and faster to compare at query time, so the dimensions parameter is a real lever for trading a small amount of retrieval quality for meaningfully lower index size and search latency — without switching models or re-architecting the pipeline.
Under the hood
Maximum input length is 8,192 tokens per request. Output is embedding-only — there is no text generation, no chat interface, no tool use. The model is text-in, vector-out, and nothing else, which keeps its integration surface small: a single API call takes a string and returns a fixed-size array of floats.
When to pick large over small
Reach for text-embedding-3-large when retrieval quality is the bottleneck: a RAG system missing relevant passages, a search feature that returns near-misses instead of the right result, or a clustering task where fine-grained distinctions between similar items matter. It is also the more defensible default when working in less common languages or specialized domains, where a smaller embedding space has less room to represent nuance.
For very high-volume indexing — millions of documents, or a workload where query latency and storage cost dominate the design — text-embedding-3-small, or a truncated large embedding via the dimensions parameter, is usually the more practical starting point. The MTEB gap between the two models is real but modest, so it is worth testing both against a representative sample of your own data rather than defaulting to large purely on the assumption that bigger is better.
Alternatives worth comparing
text-embedding-ada-002 remains available as OpenAI's previous-generation embedding model, but it is dominated on quality by both current models even at a fraction of their dimensionality, so there is little reason to choose it for new work. Outside OpenAI's own lineup, several other providers ship general-purpose text embedding models with comparable positioning; the right choice usually comes down to testing retrieval quality on your own corpus rather than benchmark scores alone, since MTEB performance does not always transfer cleanly to a specific domain.