What is an embedding?

What is an embedding and what are the numbers?

An embedding model takes text in and returns a vector: a list of floating point numbers of a fixed length, the same length for every input. No single number in that list means anything you could name. What carries meaning is the arrangement, because the model was trained so that inputs humans would call similar produce vectors that point in similar directions. Comparing two texts then becomes arithmetic, usually cosine similarity between their vectors.

The length of the vector is the dimension count, and it is a cost dial rather than a quality ranking. OpenAI's text-embedding-3-small returns 1536 dimensions and text-embedding-3-large returns 3072, both capped at 8192 tokens of input, and the API accepts a dimensions parameter that shortens the vector. The documentation makes the trade explicit: on the MTEB benchmark, a 3-large embedding shortened to 256 dimensions still outperforms an unshortened ada-002 embedding at 1536. Smaller vectors cost less to store and compare, so the honest question is not how many dimensions you can get but how few you can live with.

Nothing here requires an API. Open embedding models run locally through libraries such as sentence-transformers, and for a corpus you have to re-index often that changes the economics, because embedding is the step you repeat every time your chunking or your model changes.

Not every model vendor sells one

It is easy to assume your chat provider also supplies your embeddings. Anthropic's own documentation says otherwise, in one line: Anthropic does not offer its own embedding model. It points at Voyage AI instead, whose current family runs from voyage-4-large down to voyage-4-nano, with a 32,000 token context length and 1024 dimensions by default plus 256, 512 and 2048 as options, and with voyage-4-nano published under Apache 2.0 as open weights.

The practical consequence is that your embedding provider is a separate decision from your generation provider, with its own price list, rate limits and failure modes. Two vendors also means two things that can change under you, which is exactly the risk the next section is about.

The trap: embeddings are model-specific

Vectors from two different models are not comparable, even when the dimension counts happen to match. There is no conversion. If you switch embedding models, or the provider retires the one you use, you re-embed the entire corpus before a single query returns sensible results. On a large index that is the real migration cost, and it is measured in compute and hours, not in a code change.

Which is why every vector you store should carry the model name, the dimension count and the chunking rules that produced it. Without that metadata you cannot tell a stale vector from a current one, and a half-migrated index fails quietly: queries still return results, they are just the wrong ones.

What an embedding is not

An embedding is not memory. It is a lookup key for text you already stored, so it lets a system find something relevant; remembering is what your code does with the result. It is not a database either, and a vector store is a place to keep embeddings, not a source of the meaning in them.

Most importantly, similarity is not relevance. Two passages can be near neighbours in vector space and still be useless for the question asked, and exact terms such as error codes, version numbers or product names are precisely where semantic search is weakest. That is why serious retrieval stacks run keyword search alongside vector search and merge the results, rather than trusting the vectors alone.

# both sides of a comparison must come from the SAME model
q = embed("why did my deploy fail", model="text-embedding-3-small")  # 1536 floats
d = embed(chunk_text,                model="text-embedding-3-small")  # 1536 floats

score = dot(q, d) / (norm(q) * norm(d))   # cosine similarity, -1 .. 1

# what you actually store next to every vector
{
  "vector": [0.0121, -0.0387, ...],
  "model": "text-embedding-3-small",   # switch this and the row is dead
  "dimensions": 1536,
  "chunk": "800 tokens, 100 overlap",
  "source": "docs/deploy.md#L42-L78"
}