Retrieval & Context

Vector Search (Similarity Retrieval)

Vector search retrieves the items whose embeddings are closest to a query embedding in high-dimensional space, ranking results by a distance or similarity metric rather than by keyword overlap. Approximate nearest neighbor algorithms make this fast at scale by trading a small amount of recall for large speed gains.

What Vector Search Is: Retrieval by Similarity, Not Keywords

Vector search is an information retrieval method that finds items by the similarity of their numeric representations rather than by matching the literal words a query contains. Each document, image, audio clip, or other unit of content is first converted into a vector (an embedding) produced by a machine learning model. A query is embedded the same way, and the system returns the stored vectors that sit closest to the query vector in the embedding space.

Because matching happens over embeddings instead of tokens, vector search can connect content that shares meaning without sharing words. As Microsoft's Azure AI Search documentation describes it, this allows matching across conceptual likeness (for example, 'dog' and 'canine'), across languages ('dog' and the German 'hund'), and even across modalities such as a text query against an image. This is the core distinction from lexical search, which can only retrieve documents that contain the query terms or close variants of them.

Two ideas are often conflated here. Vector search is the retrieval operation: compare a query embedding to stored embeddings and rank by closeness. The vector database or vector index is the storage and indexing system that holds those embeddings and answers the query efficiently. This page covers the retrieval concept; the storage and index machinery is a related but distinct topic.

Vector search ranks results by embedding distance or similarity, not keyword overlap.
It can match paraphrases, synonyms, cross-lingual content, and multiple modalities.
Retrieval (the similarity operation) is conceptually separate from the database or index that stores the vectors.

Vectors as Points in High-Dimensional Space

An embedding is an ordered list of numbers, and that list can be read as the coordinates of a point in a high-dimensional space. Common text embedding models output vectors with hundreds or low thousands of dimensions. The individual numbers usually have no human-interpretable meaning; what carries information is the geometry. Vectors that lie close together represent content the model judged to be semantically similar, and vectors far apart represent dissimilar content.

Embedding models are trained so that this geometric closeness aligns with meaning. During training, the model learns to place related inputs near one another and unrelated inputs far apart. Once trained, the same model must be used to embed both the stored corpus and incoming queries, because two different models generally produce incompatible spaces where distances are not comparable.

High dimensionality is what gives embeddings their expressive power, but it also shapes the engineering. Computing a distance between two vectors costs work proportional to the dimensionality, and the geometry of high-dimensional spaces (sometimes called the curse of dimensionality) makes naive indexing structures such as k-d trees degrade toward exhaustive scanning, which motivates the specialized algorithms discussed below.

An embedding is a point in a space of typically hundreds to thousands of dimensions.
Closeness in that space encodes semantic similarity; individual coordinates are not separately meaningful.
Queries and stored content must be embedded by the same model to be comparable.

Distance and Similarity Metrics

Vector search needs a precise definition of 'close.' Three metrics dominate in practice: cosine similarity, Euclidean (L2) distance, and the dot product (inner product). Each answers a slightly different question about two vectors.

Cosine similarity measures the angle between two vectors and ignores their magnitude: two vectors pointing the same direction score 1 regardless of length. Euclidean distance measures the straight-line distance between the two points and is sensitive to both direction and magnitude, so a longer vector is 'farther' even if it points the same way. The dot product combines direction and magnitude into a single value and is often the fastest to compute, which is why many systems use it as the underlying primitive.

A practical detail ties these together: when all vectors are normalized to unit length, ranking by cosine similarity, by dot product, and by Euclidean distance produces the same ordering of results. Many embedding models output normalized vectors by default, so the choice of metric is frequently a performance detail rather than a correctness one. The reliable rule is to use the metric the embedding model was trained with, since that is the geometry the model's notion of similarity actually lives in.

Cosine similarity compares direction only and is the common default for text embeddings.
Euclidean (L2) distance compares straight-line distance and is sensitive to magnitude.
Dot product folds magnitude and direction together and is cheap to compute.
On unit-normalized vectors, cosine, dot product, and Euclidean yield the same ranking; match the metric to how the model was trained.

Exact Nearest Neighbor vs Approximate Nearest Neighbor (ANN)

The retrieval task is formally a nearest neighbor search: given a query vector, return the k stored vectors with the smallest distance (or highest similarity). Done exactly, this is k-nearest-neighbor (kNN) search, and it guarantees the true closest results.

Exact search has a fixed cost. A brute-force scan compares the query against every stored vector, with time roughly proportional to the number of vectors multiplied by the dimensionality. That is exact and simple, and it is perfectly adequate for small collections, but the cost grows linearly with the corpus and becomes impractical as datasets reach millions or billions of vectors.

Approximate nearest neighbor (ANN) search relaxes the guarantee. Instead of always returning the exact top k, an ANN algorithm returns vectors that are very likely to be among the closest, using a precomputed index that lets the search skip most of the dataset. The accuracy of an ANN system is measured by recall: the fraction of the true nearest neighbors it actually returns. ANN trades a small, tunable amount of recall for very large reductions in query latency.

Exact kNN guarantees the true closest results but costs a full scan per query.
ANN returns probable nearest neighbors using an index, skipping most of the data.
Recall (fraction of true neighbors retrieved) measures ANN accuracy and is tunable.

Why Brute Force Does Not Scale, and How ANN Trades Recall for Speed

Brute-force search has time complexity proportional to the number of vectors times the dimensionality, so doubling the corpus doubles the query cost. At large scale this linear growth, combined with high dimensionality, makes exhaustive scanning too slow for interactive applications.

ANN indexes break that linear relationship. The dominant family in production today is the Hierarchical Navigable Small World (HNSW) graph, introduced by Malkov and Yashunin (2016). HNSW builds a multi-layer proximity graph in which elements are assigned to layers with exponentially decaying probability; search starts at a sparse top layer and descends, which the authors show yields logarithmic scaling of search complexity. Other ANN approaches include inverted-file clustering (IVF) and product quantization, and these techniques are often combined.

The recall-for-speed trade is explicit and controllable. With HNSW, increasing the efSearch parameter widens the candidate set explored at query time, raising recall at the cost of latency; build-time parameters control how many links each node keeps and how hard the index works during construction. A common rule of thumb is that accepting a few percent of recall loss can accelerate search by orders of magnitude compared with exact scanning, which is part of why ANN is the default for large-scale vector search.

Brute-force cost scales linearly with corpus size, so it breaks down at millions to billions of vectors.
HNSW graphs give roughly logarithmic search scaling and are a dominant production ANN method.
Parameters like efSearch let operators dial recall up or latency down on the same index.

From Query to Results: Embed, Search, Rank

At query time, a vector search pipeline typically runs three steps. First, the user's input is embedded with the same model used to encode the corpus, turning the query into a vector. Second, that vector is compared against the index, and the ANN (or exact) search returns the k nearest stored vectors. Third, the matches are returned ranked by their similarity score, optionally filtered by metadata constraints such as date, source, or access permissions.

Many systems support filtered vector search, where a structured filter on non-vector fields is combined with the similarity query so that only eligible items are considered or returned. The value of k (how many neighbors to retrieve) is a deliberate choice: a small k is fast and precise, while a larger k feeds more candidates into a downstream stage such as reranking or a language model.

The quality of the whole pipeline is bounded by the embedding model. If the model places two genuinely related items far apart, no amount of index tuning will retrieve one given the other. Embedding quality, chunking strategy for long documents, and metric choice therefore matter as much as the search algorithm itself.

python

import numpy as np

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

q = embed(query)                      # query -> vector
scores = [(cosine(q, v), doc) for v, doc in index]
top_k = sorted(scores, reverse=True)[:5]   # rank by similarity

The embed-search-rank loop: turn the query into a vector, score every indexed vector by cosine similarity, then return the top-k most similar items.

Three stages: embed the query, search the index for nearest neighbors, return ranked results.
Metadata filters can constrain results before or after the similarity step.
Retrieval quality is ultimately capped by the embedding model and how content was chunked.

Vector Search vs Keyword Search vs Hybrid Search

Keyword (lexical) search, classically using algorithms such as BM25, ranks documents by term overlap and statistics. It excels at exact matches: product codes, named entities, rare technical terms, and precise phrases. Its weakness is that it cannot bridge vocabulary gaps; a query and a relevant document that use different words may never match.

Vector search has the complementary profile. It handles paraphrase, synonymy, and conceptual queries well, but it can underweight exact matches on rare tokens that a lexical engine would catch immediately, because a rare literal string may not be strongly represented in the embedding geometry.

Hybrid search runs both and fuses the results, which often beats either method alone. A common fusion method is Reciprocal Rank Fusion (RRF), which scores each document by the sum of 1/(k + rank) across the retrievers, using rank position rather than raw scores to avoid comparing incomparable score scales; the constant k is commonly set to 60. Because lexical and semantic scores are not directly comparable, rank-based fusion is a reliable default for combining them.

Keyword search (BM25) wins on exact terms, codes, and named entities but misses paraphrase.
Vector search wins on meaning and synonyms but can miss rare exact-string matches.
Hybrid search fuses both, often with Reciprocal Rank Fusion (RRF), and frequently outperforms either alone.

Where Vector Search Fits in RAG and AI Memory Pipelines

Vector search is the retrieval core of retrieval-augmented generation (RAG). In a RAG system, a corpus is chunked and embedded ahead of time; at query time the user's question is embedded, vector search fetches the most relevant chunks, and those chunks are inserted into a language model's prompt as grounding context. The model then answers using retrieved evidence rather than relying solely on parametric memory.

The same retrieval pattern underlies AI memory and second-brain applications, which store a personal corpus of notes, documents, and other artifacts and use semantic search to surface the right item when asked in plain language. MemX, for example, applies semantic retrieval over stored documents, photos, and voice notes so users can find them by describing what they want.

In both settings, vector search is one stage in a larger pipeline. Its job is high-recall candidate retrieval: surface a manageable set of plausibly relevant items quickly, so that later stages (filtering, reranking, and generation) can operate on a small, high-quality shortlist instead of the entire corpus.

In RAG, vector search retrieves grounding chunks that are fed into the model's prompt.
AI memory and second-brain tools use the same semantic retrieval to find stored content by description.
Vector search typically acts as the fast, high-recall candidate stage ahead of reranking and generation.

Limitations: Recall, Latency, and the Need for Reranking

The central tension in vector search is between recall and latency. ANN indexes are fast precisely because they may skip the true nearest neighbor, so a system tuned for very low latency can quietly miss relevant results. Recall is measurable and tunable, but pushing it higher costs query time and often memory, so production systems pick an operating point rather than a perfect one.

Bi-encoder retrieval (embedding query and document separately, then comparing vectors) is also a coarse relevance signal. It compresses each item into a single fixed vector before the query is known, which can blur fine distinctions. This is why two-stage retrieval is common: vector search returns a shortlist, then a cross-encoder reranker re-scores those candidates by processing the query and each document together with full attention. Cross-encoders are more accurate but far too expensive to run over an entire corpus, so they are reserved for re-ordering a short candidate list.

Other practical limits include sensitivity to embedding quality and chunking, the cost of re-embedding a corpus when the model changes, and the difficulty of exact-match and freshness-sensitive queries, which is part of why hybrid search and reranking are frequently layered on top of raw vector retrieval.

Lower latency can mean lower recall; ANN systems choose an operating point on that curve.
Single-vector (bi-encoder) similarity is coarse, motivating a cross-encoder reranking stage.
Cross-encoders rerank a short shortlist because they are too costly to run over the full corpus.
Embedding quality, chunking, exact-match queries, and re-embedding costs remain practical constraints.

Key takeaways

Vector search retrieves items by the distance between query and document embeddings, so it matches meaning rather than literal keywords.
Cosine similarity, Euclidean distance, and dot product are the main metrics; on unit-normalized vectors they produce the same ranking, so match the metric to how the embedding model was trained.
Exact (brute-force) kNN scales linearly with corpus size; approximate nearest neighbor methods such as HNSW trade a small, tunable amount of recall for order-of-magnitude speedups.
Hybrid search fuses vector and keyword (BM25) retrieval, often via Reciprocal Rank Fusion, to capture both semantic and exact matches.
Vector search is the fast high-recall stage in RAG and AI memory pipelines, usually followed by a cross-encoder reranking step for precision.

Frequently asked questions

Vector search is the retrieval operation: comparing a query embedding to stored embeddings and ranking by distance or similarity. A vector database (or vector index) is the storage and indexing system that holds the embeddings and executes that search efficiently. One is the algorithmic operation, the other is the infrastructure that runs it.

Use the metric the embedding model was trained with, since that defines its notion of similarity. Cosine similarity is a common default for text embeddings. If your vectors are normalized to unit length, cosine, dot product, and Euclidean distance all produce the same ranking, so the choice becomes a performance detail rather than a correctness one.

ANN search returns vectors that are very likely to be the closest matches, using a precomputed index that skips most of the dataset instead of scanning every vector. It is used because exact brute-force search scales linearly with corpus size and becomes too slow at millions or billions of vectors. ANN trades a small, tunable loss in recall for very large gains in speed.

Neither is universally better; they have complementary strengths. Keyword search excels at exact matches like codes and named entities, while vector search handles paraphrase and conceptual similarity. Hybrid search runs both and fuses the results, often with Reciprocal Rank Fusion, and frequently outperforms either method used alone.

Put the idea into practice

MemX is an AI memory agent built on these ideas: store anything, skip the folders, and find it again by asking in plain English.

Try MemX Free