Similarity Search

The last several articles covered specific pieces — Vector Search’s scaling problem, HNSW’s indexing solution, and three different ways to measure closeness. This article names the broader activity all of those pieces exist to serve: similarity search.

The simple definition

Similarity search is the general task of finding items that are alike, in some meaningful sense, to a given query. It’s the umbrella term; everything covered so far in this phase — embeddings, vectors, cosine similarity, HNSW — are the specific tools and techniques modern AI systems use to actually perform it. Similarity search itself is older and broader than vectors and embeddings — it’s the underlying goal those newer technologies were built to serve well.

Why this deserves to be named as its own concept

It’s worth stepping back and being explicit about the full picture this phase has assembled. Raw data (text, images) gets converted into Embeddings — Vectors positioned so similar meaning lands close together. Those vectors get stored in a Vector Database. Finding the closest ones to a query is Vector Search, made fast at scale through Approximate Nearest Neighbor (ANN) techniques like HNSW, using a specific distance or similarity formula — Cosine Similarity, Euclidean Distance, or the Dot Product — to actually decide what “closest” means. Similarity search is the name for the whole activity all of these pieces work together to accomplish.

flowchart LR
    A[Raw data] --> B[Embedding: convert to meaningful vector]
    B --> C[Vector Database: store at scale]
    C --> D[Vector Search using ANN/HNSW]
    D --> E[Similarity metric: cosine, Euclidean, or dot product]
    E --> F[Similarity Search result: the closest matches]

ANALOGY vs. TECHNICAL REALITY

Analogy: Think of the general human task of finding “something like this” — recommending a movie similar to one you loved, matching a job candidate’s resume to a role, finding a song that sounds like another song. People have been doing versions of this task, using judgment and experience, for as long as recommendation and matching have existed.

Where this breaks down: A person doing this uses rich, contextual judgment, drawing on countless unstated factors. Modern AI-driven similarity search reduces this same broad human task to a precise, calculable pipeline — convert to a vector, measure a specific mathematical distance, return the closest matches — trading some of that human nuance for speed, consistency, and the ability to operate across millions of candidates instantly.

Similarity search existed before embeddings, and still does alongside them

This is worth being precise about, since it’s easy to assume “similarity search” and “vector search” are simply synonyms. They’re not quite — recall from the Sparse Vector article that classic keyword-based methods like BM25 are also a form of similarity search, just using sparse vectors and exact word overlap rather than dense, learned embeddings. Modern hybrid search systems, as covered in the Vector Database article’s discussion of Weaviate, deliberately combine both approaches — because, as the Sparse Vector article explained, exact keyword matching and flexible semantic matching genuinely capture different, complementary kinds of similarity.

A concrete example, layered

For a simple beginner example: a music app’s “songs you might like” feature is performing similarity search — finding tracks whose embeddings land close to the embeddings of songs you’ve already enjoyed, based on learned patterns in melody, rhythm, and other audio characteristics. For a production example: a legal research tool used by law firms performs similarity search across millions of past case documents, converting a new case’s key facts into an embedding and retrieving the most similar historical rulings — a real, valuable application where finding genuinely relevant precedent, even when the exact legal terminology differs from case to case, is precisely what embedding-based similarity search is good at that a simple keyword search would miss.

Where similarity search genuinely struggles

It’s worth naming a real, honest limitation rather than presenting this as a solved problem. Similarity search fundamentally depends on the quality of the embedding model producing the vectors — echoing the Embedding Model article’s point that a model trained on general web text may perform poorly on specialized domains. A similarity search system is only as good as its underlying embeddings; feeding it a poorly-suited embedding model will produce results that are mathematically “close” without being genuinely, usefully similar in the way a person actually cares about.

End-to-end similarity-search example

Stored items:

D1: "Steps to reset your password"
D2: "Change the billing address on an invoice"
D3: "Troubleshoot sign-in problems"

Query:

"I forgot my login secret"

flowchart LR
    A[Query text] --> B[Embedding model]
    B --> C[Query vector]
    C --> D[Compare with indexed document vectors]
    D --> E[Rank nearest candidates]
    E --> F[D1, then D3]

Similarity search is the general operation. When the objects are semantic text embeddings and the goal is meaning-based text retrieval, we commonly call the application semantic search.

Similarity search is broader than text

The same pattern can retrieve:

• Visually similar product images.
• Songs with similar audio characteristics.
• Users or products for recommendations.
• Source-code snippets with related functionality.
• Previously observed cases that resemble an anomaly.

The embedding model defines what “similar” means. A visual embedding and a text embedding may organize entirely different properties.

How similarity search connects to GPT and Gemini

Dedicated OpenAI and Gemini embedding models turn items into comparable vectors. A search engine ranks those vectors, retrieves the original content, and can supply it to a chat model.

sequenceDiagram
    participant U as User
    participant E as Embedding model
    participant S as Similarity index
    participant L as GPT or Gemini
    U->>E: Question
    E->>S: Query vector
    S-->>L: Relevant source chunks
    L-->>U: Answer using retrieved context

Similarity search can also run without a language model—for recommendations, duplicate detection, clustering, or image matching. GPT/Gemini generation is one possible consumer of the retrieved results, not a required part of similarity search itself.

Common misconception

A frequent beginner assumption: that similarity search always means the specific, modern combination of embeddings plus vector databases plus ANN algorithms covered throughout this phase. As this article has emphasized, similarity search is the older, broader goal; vectors and embeddings are simply the most powerful and currently dominant technique for achieving it, not the definition of the task itself.

Where this fits in what comes next

You now have the full picture this phase has built, tied together under one name. The final article in this phase, Semantic Search, covers the specific, most prominent real-world application of similarity search — using it to search by meaning rather than exact keywords, the capability powering modern AI-driven search bars and RAG systems.

In one sentence

Similarity search is the general task of finding things that are meaningfully alike, and while it predates modern AI, embeddings and vector search have become its most powerful and widely used technique — turning a fuzzy, human notion of “similar” into a precise, scalable, calculable pipeline.

Related Terms

• Vector Search
• Embedding
• Vector Database
• Cosine Similarity
• Semantic Search