Embeddings models compared for semantic search

An embedding is the way an AI represents the meaning of a piece of text as a list of numbers, so similar things can be compared mathematically. The embedding model is what produces those numbers. Pick a good one and your semantic-search, deduplication, classification, and RAG (retrieval-augmented generation — giving AI access to your specific documents) features work; pick a poor one and they don’t.

The embedding model decision quietly shapes every downstream retrieval choice. Once you’ve embedded 10 million documents in OpenAI text-embedding-3-large at 3,072 dimensions, you’re committed. Switching models means re-embedding the corpus and revalidating the vector database (a database that stores embeddings and lets you search by meaning). The “we’ll just pick one and move on” decision is the one that benefits most from honest comparison — the cost of getting it wrong is meaningful, and the marketing pages don’t surface the trade-offs that matter for your specific data.

Onward: retrieval-quality benchmarks, dimension-and-cost math, multilingual capability, self-hosting trade-offs, and the testing pattern that beats “pick the leader on MTEB and move on.”

For general-purpose RAG with broad ecosystem support — OpenAI text-embedding-3-large or text-embedding-3-small. The ecosystem support is the widest; every vector store has native OpenAI integration; the Matryoshka reduction lets you trade dimension for cost. Trade-off: not the cheapest at high volume, no native rerank.

For semantic-search workflows that benefit from a paired rerank model — Cohere embed-v3 with Cohere Rerank. The two-stage retrieve-then-rerank pattern with both from one vendor is well-documented; quality is competitive with OpenAI. Right for production search systems where rerank materially improves precision.

For long-context input (entire articles or documents per embedding) — Voyage AI’s voyage-3 with 32k input. Most other models cap at 512 or 8,192 tokens; voyage handles much longer inputs as a single embedding, which simplifies architectures that would otherwise need chunking. Right for whole-document retrieval workflows.

For multilingual workloads at moderate cost — Jina v3 or Cohere embed-v3. Both have documented strength on multilingual benchmarks; Jina trades slight quality for slightly lower cost at high volume. Right when your corpus spans many languages and per-language quality matters.

For privacy-sensitive or self-hosted operation — sentence-transformers (open-source). The all-mpnet-base-v2 and BGE family are competitive on quality with the commercial mid-tier, free software, and self-hostable on modest hardware. Right when data can’t leave your infrastructure (regulated industries, on-prem requirements).

For very-high volume cost optimisation — Either OpenAI text-embedding-3-small (good quality, low cost) or self-hosted open-source. At 100M+ embeddings, the cost differences compound significantly; rerun the math on your actual volume before defaulting.

The per-token cost is small; the dimension-driven storage cost adds up at scale. Choose the dimension that fits your retrieval quality bar — higher isn’t always better, especially after rerank.

• New models frequently. OpenAI, Cohere, Voyage, Jina all iterate; quality leaders shift on benchmarks every few months.
• Open-source catching up. Top open-source models (BGE, GTE, E5) regularly match mid-tier commercial on MTEB.
• Specialised embeddings. Domain-specific models (legal, medical, code) emerging with documented quality lifts on their domains.

Re-verify every 6 months for cost; quality benchmarks shift faster than pricing.

For the underlying embeddings mental model, see Embeddings explained without math. For the vector-database choice that stores these embeddings, see Vector databases compared. For the broader RAG pattern these power, see RAG explained without acronyms. For the internal-Q&A bot architecture that combines embeddings with generation, see Internal Q&A bot over company docs.