The Embeddings Stack in 2026: Brute Force, Open Weights, and Provider Portability

Vector embeddings (numbers that represent the meaning of text so models can compare similarity) are the foundation of semantic search, RAG (Retrieval-Augmented Generation, where the model looks up documents before answering), and recommendation systems. In 2026, teams choose between proprietary APIs (OpenAI, Cohere, Google) and self-hosted open-weight models (BGE-M3, GTE-Qwen2). The right choice depends on your volume, latency needs, and data residency requirements.

How Embedding Models Work in 2026

An embedding model converts text into a fixed-length array of numbers (a vector). Two pieces of text with similar meanings produce vectors that are close together in the mathematical space. This enables semantic search: find documents whose meaning matches a query, even if the exact words differ.

The pipeline looks like this:

1. Send text to the embedding API (Application Programming Interface, a standard way for programs to communicate).

2. Receive a vector (array of floats, typically 384 to 3072 dimensions).

3. Store the vector in a vector database (Pinecone, Weaviate, Qdrant, pgvector).

4. At query time, embed the search query and find the nearest vectors using cosine similarity.

Brute Force vs Approximate Search

When your vector database has millions of embeddings, finding the nearest neighbors requires a search strategy:

Brute force (exact search)

Compare the query vector against every stored vector. This gives perfect recall (you always find the true nearest neighbors) but scales linearly with database size. At 10 million vectors, brute force takes 50-200ms per query. Fine for batch jobs, too slow for real-time search.

Approximate nearest neighbor (ANN)

Use index structures like HNSW (Hierarchical Navigable Small World) or IVF (Inverted File Index) to skip most vectors and only compare against likely candidates. This trades a small recall loss (typically 95-99% of true results) for 10-50x speed improvement. At 10 million vectors, ANN returns results in 2-10ms.

Most production systems use ANN. The recall loss is negligible for search and RAG use cases, and the speed gain makes real-time applications possible.

Choosing an Embedding Model

When to use proprietary APIs

Proprietary embedding APIs make sense when:

• Your volume is moderate (under 100M tokens/month), so API costs stay manageable.

• You need the latest model improvements without managing infrastructure.

• Your application is English-dominant and quality is the top priority.

OpenAI text-embedding-3-large remains the quality leader on English benchmarks. Cohere embed-v4 is the best choice for multilingual applications, supporting 100+ languages with consistent quality.

When to use open-weight models

Open-weight models make sense when:

• Your volume is high (above 100M tokens/month), making API costs significant.

• You need EU data residency and cannot send text to US-based APIs.

• You want to fine-tune embeddings on domain-specific data.

GTE-Qwen2-7B now matches or exceeds proprietary models on several MTEB tasks while supporting a 32K token context window. BGE-M3 is the go-to for multilingual open-weight embeddings with support for dense, sparse, and multi-vector representations.

The Provider Portability Problem

Here is the catch with embedding models: vectors from different providers are not interchangeable. An embedding from OpenAI lives in a different mathematical space than one from Cohere. You cannot mix them in the same vector database, and you cannot switch providers without re-embedding your entire corpus.

This creates vendor lock-in. Once you embed 10 million documents with OpenAI, switching to Cohere means re-processing all 10 million documents, which costs time and money.

Solutions to the portability problem:

1. Commit to one provider and negotiate. If you are locked in, use that leverage for better pricing.

2. Use open-weight models from day one. Self-hosted models give you the option to switch infrastructure without re-embedding.

3. Abstract the embedding call behind a gateway. Eden AI lets you call embeddings through a unified API, making it easier to test different providers during development before committing to one.

import requests
import os

headers = {
    "Authorization": "Bearer " + os.environ["EDENAI_API_KEY"],
    "Content-Type": "application/json"
}

# Generate embeddings through Eden AI unified API
response = requests.post(
    "https://api.edenai.run/v3/universal-ai",
    headers=headers,
    json={
        "model": "text/embeddings/openai",
        "input": {"text": "How does vector search work?"}
    }
)

embedding = response.json()["embedding"]
print(f"Vector dimensions: {len(embedding)}")

Cost at Scale

Embedding costs compound quickly at production volume:

Google's embedding API is 26x cheaper than OpenAI per token, with only a small quality gap (64.0% vs 66.8% on MTEB). For cost-sensitive applications, this tradeoff is usually worth it. Self-hosting becomes cost-effective above 1-5 billion tokens per month.

Last updated: 2026-08-02

Conclusion

The embeddings landscape in 2026 offers genuine choice between convenience and control. Proprietary APIs lead on quality and ease of use. Open-weight models provide sovereignty and cost savings at scale. The key decision is not which model is best in isolation, but which combination of model, search strategy, and infrastructure fits your specific volume, latency, and compliance requirements. A gateway layer keeps your options open during the evaluation phase.

You can find them at Eden AI.

Login to the platform to test it yourself.

FAQ