What Are Embeddings? Text Vectors for Search and RAG

What an embedding is

An embedding model reads a passage and outputs a vector, for example 1,024 floating-point numbers. No single number means anything on its own. What matters is geometry: how do I cancel a running job and a passage about stopping work land near each other even if they share no words.

That is the strength and the limit. Embeddings capture meaning and paraphrase well, and capture exact strings badly. v2.11.162 and v2.11.163 look almost identical to an embedding model, which is why production search pairs vectors with a keyword index.

In a retrieval system, embeddings are computed twice. Every chunk is embedded once at ingest and stored in a vector index. Every query is embedded at search time with the same model, and the index returns the stored vectors closest to it. Because the corpus side is precomputed, query-time cost is one embedding call plus an index lookup.

How similarity is measured

Two embeddings are compared with cosine similarity, the cosine of the angle between them: 1 means same direction, 0 means unrelated. If a model outputs normalised vectors (length 1), cosine similarity and the dot product are the same number, which lets the index use the cheaper operation.

import numpy as np

def cosine(a, b):
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

q = embed("how do I rotate an api key")
d = embed("API keys can be regenerated from Settings")
print(cosine(q, d))   # higher = closer in meaning

At scale, nobody compares a query to every vector. An approximate nearest-neighbour index such as HNSW walks a graph and returns the best matches among the nodes it visits, trading a little recall for a lot of speed.

Symmetric and asymmetric models

Some models are asymmetric: they expect queries and passages to be marked differently, for example with query: and passage: prefixes, and recall drops if you forget. Symmetric models embed both sides the same way. Check your model's card before embedding anything.

Common pitfalls

Mixing models or versions. Vectors from two different models live in different spaces. Changing model or dimension means re-embedding the whole corpus.
Wrong prefixes. Using query prefixes on a symmetric model, or omitting them on an asymmetric one, quietly lowers recall.
Embedding junk. Short, generic text such as error pages embeds near the centre of the space and turns up for unrelated queries.
Too few candidates. Asking an approximate index for exactly the number of results you want leaves no room for re-ranking or fusion, and lost recall never shows up as an error.
Expecting exact matching. Identifiers, codes and names need a keyword index alongside.

How SarvCrawl handles it

Every chunk in a SarvCrawl knowledge base is embedded at ingest, in the same pass as chunking, into a 1,024-dimension vector stored beside its text and compared by cosine similarity. The embedding model is symmetric and normalised, so queries and passages need no prefixes. Chunks use contextual chunk embeddings, so a passage is embedded with the context it came from.

If an embedding call fails, the chunk is still indexed without a vector: it stays findable by keyword and is skipped by vector search. Vector results are always fused with keyword results; see hybrid search in production and the embed-search reference.

Frequently asked questions

What is the difference between an embedding and a vector?

An embedding is a vector with a purpose: it was produced by a model so that distance between vectors reflects similarity of meaning. Every embedding is a vector; not every vector is an embedding.

How many dimensions should an embedding have?

It is set by the model, commonly between a few hundred and a few thousand. More dimensions cost more storage and compute. Pick the model on retrieval quality for your data, then accept its dimension.

Can I switch embedding models later?

Yes, but you must re-embed and reindex every chunk, because vectors from different models are not comparable.

What are embeddings?