An embedding is a list of numbers that represents a piece of text, produced by a model so that texts with similar meaning get similar numbers. Search then becomes arithmetic: embed the query, embed the documents, and return the documents whose vectors sit closest.
The idea in one example
Say you search your repository for "retry failed uploads." No file contains that exact phrase. One function is called resend_pending_files with a comment about network errors. A keyword search misses it. An embedding search can find it, because a trained model places both texts near each other.
The Sentence Transformers documentation describes the workflow plainly. You call an encode method on your inputs to get vectors, then a similarity method to compare them. Its own example turns three sentences into 384-dimensional vectors, meaning each sentence becomes a list of 384 numbers.
How closeness is measured
Two common measures are cosine similarity, which compares the direction of two vectors, and dot product. If vectors are normalised to unit length, cosine and dot product give the same ranking. Ollama's embedding endpoint returns normalised vectors, and its documentation suggests cosine similarity for most semantic search.
You never read the individual numbers. A single dimension has no human meaning. Only the distances between vectors matter.
A rule that causes real bugs
Use the same embedding model for indexing and for querying. Ollama's documentation says that mixing models produces incompatible vectors. This bites teams when they upgrade the model for new queries but forget to rebuild the old index. Results get strange rather than failing loudly, which makes it hard to notice.
Store the model name and version next to the index. When it changes, re-embed everything.
What embeddings are good at
- Finding code by what it does, not what it is called.
- Matching a natural language question to documentation.
- Grouping near duplicates.
- Handling paraphrase and different vocabulary between a question and an answer.
What they are bad at
Exact strings. An error code, a function name, a CVE identifier or a config key often works better with plain keyword matching. Anthropic's write-up on retrieval notes that embeddings can miss exact matches, while lexical methods help with identifiers and technical terms. That is why many systems run both. See keyword or vector search for code.
There is also no universal winner among embedding models. The MTEB benchmark paper, which covered 8 task types, 58 datasets and 33 models, concluded that no text embedding method dominates across all tasks. Test candidates on your own code, not on a leaderboard alone. More on that in choosing an embedding model.
Embeddings leak
A vector is not an anonymised version of the text. OWASP lists embedding inversion, where attackers recover much of the original information from vectors, as a risk. Protect the vector store as you would protect the source. Our piece on vector and embedding weaknesses goes deeper.
Quick check
Do I need a GPU to create embeddings?
Not necessarily. Small embedding models run on a laptop CPU. It is slower for large repositories, but indexing is a one time cost plus small updates.
Can I compare vectors from two different models?
No. Each model has its own space. Compare only vectors made by the same model.
Sources
- Sentence Transformers documentation
- Ollama embeddings documentation
- Contextual Retrieval, Anthropic
- MTEB: Massive Text Embedding Benchmark
- OWASP LLM08:2025 Vector and Embedding Weaknesses
Last reviewed: 19 October 2026.
