Vector Search

TL;DR — Vector search finds content by meaning instead of by matching the exact words you typed. It turns your query and every stored document into a list of numbers — a vector — and returns the documents whose numbers are closest to your query’s numbers. It’s how AI search and chatbots find the passages they answer from.

What vector search is

Vector search retrieves items by proximity in an embedding space, often using approximate nearest-neighbor indexes for scale. Evidence for this claim HNSW is an approximate nearest-neighbor method that organizes vectors in a multilayer navigable graph for efficient search. Scope: The HNSW algorithm and reported evaluations; production indexes may use different ANN methods and parameters. Confidence: high · Verified: 2026-07-14 Malkov and Yashunin: HNSW Similarity depends on the embedding model, distance function, and indexed data. Evidence for this claim Embedding vectors can be compared by distance to retrieve related items. Scope: OpenAI embedding guidance; retrieval quality depends on model choice, corpus, index, filters, and evaluation. Confidence: high · Verified: 2026-07-14 OpenAI: Embeddings guide

Old-school keyword search matches words. If you search “how to fix a slow website” and a page says “improve site performance,” a pure keyword engine might miss it — different words, same meaning.

Vector search fixes that. A model called an embeddings model reads text and turns it into a long list of numbers (a vector) that captures what the text means. Content about the same thing gets similar numbers, so it lands close together in a kind of mathematical map. Vector search just asks: which stored vectors are closest to the query’s vector?

So “fix a slow website” and “improve site performance” end up near each other on the map, and vector search finds the match even though the words don’t line up.

A simple mental model

Imagine every page on the web placed as a dot on a giant map, where dots about the same topic sit near each other — all the dog pages in one neighborhood, all the tax pages in another. When you search, your query becomes a dot too. Vector search finds the nearest dots and hands them back.

That’s the whole idea. The hard part is doing it fast when there are billions of dots — which is the next thing to understand.

Why “approximate”

Checking your query against every single stored vector would be far too slow at web scale. So real systems use clever shortcuts called approximate nearest neighbor (ANN) algorithms. They don’t check every dot — they take smart paths through the map to find the closest ones almost perfectly, in a few milliseconds. “Almost” is fine: missing the 19th-best result out of millions doesn’t change your answer, and the speed it buys is enormous.

Why this matters for you

In AI answers — Google’s AI Overviews, ChatGPT search, Perplexity — the system first retrieves a handful of relevant passages, then writes an answer from them. That retrieval step is vector search. If your content isn’t semantically close to the question, it never makes the shortlist, and it can’t be cited.

There’s no trick to “optimize for vector search.” What it rewards is what good content always required: clear, genuinely-on-topic writing with real depth. Thin, keyword-stuffed pages don’t land in a coherent neighborhood on the map, so they don’t get retrieved.

Want the algorithms (HNSW, ScaNN), the distance metrics, how Google actually uses this, and the full SEO picture? Switch to the Advanced tab.

TL;DR — Vector search retrieves the closest vectors to a query vector in a high-dimensional embedding space, using approximate nearest neighbor (ANN) algorithms — HNSW, IVF, FAISS, ScaNN — because exact comparison over billions of vectors is impossible in real time. ANN is approximate by design: it trades a sliver of recall for orders-of-magnitude speed. Vector search is a mechanism for semantic search, not a synonym for it, and it’s the retrieval step inside every RAG system (AI Overviews included). Production rarely runs it alone — the real pattern is hybrid: BM25 + vector + reranking. For SEO there’s no knob to turn; vector proximity is the gate into the candidate pool, and it rewards topically coherent, passage-level depth.

Where vector search sits

Vector retrieval is one component that can feed ranking or generation; it is not a complete search system by itself. Evidence for this claim HNSW is an approximate nearest-neighbor method that organizes vectors in a multilayer navigable graph for efficient search. Scope: The HNSW algorithm and reported evaluations; production indexes may use different ANN methods and parameters. Confidence: high · Verified: 2026-07-14 Malkov and Yashunin: HNSW No fixed distance threshold or index algorithm is universally best. Evidence for this claim Embedding vectors can be compared by distance to retrieve related items. Scope: OpenAI embedding guidance; retrieval quality depends on model choice, corpus, index, filters, and evaluation. Confidence: high · Verified: 2026-07-14 OpenAI: Embeddings guide

Embeddings give you the vectors — vector search is what you do with them. If embeddings are the “what is a vector” half of the story, this is the “now find the closest ones” half. And it’s worth being precise about a distinction the industry blurs constantly: semantic search is the goal; vector search is one method for reaching it. Semantic search can also lean on knowledge graphs, entity recognition, and intent matching. Vector search specifically means ANN retrieval over an embedding space — so the two aren’t synonyms, even though they’re used as if they were.

How vector search works, step by step

The pipeline is the same whether you’re Google or a weekend RAG project:

1. Embed the content. An encoder model converts each chunk of content into a vector. Note chunk — vector search doesn’t compare whole pages; it compares passages. Chunking is the unit of retrieval, which is why passage-level density matters more than page-level keyword presence.
2. Build an index. The vectors go into a vector index built for fast nearest- neighbor lookups (an ANN index — more below).
3. Embed the query. At query time the same model turns the user’s query into a vector in the same space.
4. Run ANN search. The index returns the top-k vectors closest to the query vector — the candidate set.
5. Rank and return. Those candidates get scored, often reranked, and the best are served (or, in RAG, passed to an LLM to generate from).

Approximate nearest neighbor — why “approximate”

Finding the exact nearest neighbors means comparing the query to every stored vector — O(N) per query. At billions of vectors, in milliseconds, that’s a non-starter. So production search uses ANN: indexing structures that find the nearest neighbors almost perfectly while skipping the vast majority of comparisons.

As Elastic puts it, ANN “sacrifices perfect accuracy in exchange for executing efficiently in high dimensional embedding spaces, at scale.” Weaviate frames the same tradeoff as trading “a bit of accuracy for a huge gain in speed.” This is not a bug — it’s the engineering choice that makes vector search possible at all. The metric for “how good is the approximation” is recall: Google defines it as “the percentage of nearest neighbors returned by the index that are actually true nearest neighbors.” Google’s own Vector Search service — rebranded from “Vertex AI Vector Search” and now documented under the Gemini Enterprise Agent Platform — reports recall of 95–98% — you give up a couple of percent of the true neighbors and get search at web scale in return.

Key ANN algorithms

You don’t need to implement these, but knowing the names demystifies a lot of AI- search discussion.

• HNSW (Hierarchical Navigable Small World) — the industry default. A multi- layer graph where the top layers are sparse “express lanes” with long-range connections for fast traversal, and the bottom layers are dense “local roads” for precise navigation. It achieves roughly logarithmic search complexity, which is why it dominates production. Used by Weaviate, Pinecone, pgvector, Qdrant, and more. The catch is memory: HNSW indexes are RAM-hungry. Pinecone’s verdict — “HNSW gives us great search-quality at very fast search-speeds — but there’s always a catch — HNSW indexes take up a significant amount of memory.”
• IVF (Inverted File Index) — partitions the space into clusters (k-means), then at query time only searches the few clusters nearest the query (nprobe). Pinecone calls it “a very popular index as it’s easy to use, with high search- quality and reasonable search-speed… a good scalable option.”
• FAISS — Facebook AI’s library (Johnson, Douze, Jégou) for billion-scale similarity search. It’s a toolbox, not a single algorithm: a flat exact baseline (IndexFlatL2), clustered IVF, product-quantized IVFPQ for 4–64x memory compression, and an HNSW implementation. Its GPU adaptation reported an 8.5x speedup on k-NN search.
• ScaNN (Scalable Nearest Neighbors) — Google’s library, open-sourced, the same family of tech behind Google Image Search, YouTube, and Google Play. Its innovation is anisotropic vector quantization: instead of minimizing average distance, it “more heavily penalizes quantization error that is parallel to the original vector,” because directional error disproportionately harms the high- inner-product (most relevant) results. The payoff: it “outperforms other vector similarity search libraries by a factor of two” on ann-benchmarks.com — roughly twice the queries per second at a given accuracy.
• Flat (exact) index — no approximation at all; brute-force, most accurate, slowest. Pinecone notes flat indexes “produce the most accurate results” and are the right call when search quality is paramount or the index is small (under ~10K vectors). Above that scale, you move to ANN.

The through-line: every ANN index is a dial between recall, latency, throughput, and memory. As Weaviate puts it, most vector databases let you “configure how your ANN algorithm should behave… to find the right balance.”

Distance metrics

“Closest” needs a definition. Three are common:

• Cosine similarity — the default for text. It measures the angle between two vectors, ignoring magnitude, so a short document and a long one on the same topic score alike. Weaviate: “Cosine similarity is commonly used in Natural Language Processing… It measures the similarity between documents regardless of the magnitude.”
• Dot product (inner product) — used when relevance is defined by inner product (the MIPS problem ScaNN optimizes for).
• Euclidean distance (L2) — straight-line distance; used when magnitude carries meaning.

Here’s the practical shortcut: for normalized vectors, cosine similarity and dot product give identical rankings, and most modern embedding models normalize their output to unit length. OpenAI says it plainly — “We recommend cosine similarity. The choice of distance function typically doesn’t matter much” — precisely because their embeddings are length-1. The real rule, per Weaviate: “Use the distance metric that matches the model that you’re using… There is no ‘one size fits all’.”

Vector databases

A vector database stores vectors and runs ANN over them so you don’t build the index infrastructure yourself. The common names — Pinecone (managed), Weaviate (hybrid search built in), Chroma and FAISS (great for prototyping/in-process), Qdrant, Milvus (self-hosted scale), and pgvector (a Postgres extension, for teams already on SQL). I’m listing, not ranking — the right choice depends on scale, whether you want managed vs. self- hosted, and whether you need hybrid search out of the box. At Google/Bing scale, the “database” is internal ScaNN/ANN infrastructure rather than any of these.

Hybrid search — how production actually works

The “keyword search vs. vector search” framing is a false binary. Pure vector search misses exact-match queries — error codes, SKUs, proper nouns — and pure keyword search misses semantic variants. So serious systems run hybrid search: keyword (BM25) and vector retrieval in parallel, results fused (commonly with Reciprocal Rank Fusion), then the top candidates reranked by a cross-encoder. Microsoft defines hybrid search as “the execution of vector search and keyword search in the same request… The queries execute in parallel, and the results are merged into a single response and ranked accordingly.” Google’s Vector Search supports the same three modes — dense (semantic), sparse (keyword), and hybrid. If you take one thing from this section: production retrieval is almost never vector-only. It’s the combination that wins.

How Google (and Bing) actually use vector search

This is not a 2023 ChatGPT-era novelty. The infrastructure predates the LLM wave by years:

• ScaNN (ICML 2020, open-sourced) powers Google Image Search, YouTube, and Google Play, and underpins Google’s Vector Search product (the service formerly branded Vertex AI Vector Search) — which “shares the same backend” as those consumer products. Google’s Kaz Sato called the technology “one of the most important components of Google’s core services.” Performance spec: “tens of thousands of requests per second… in less than 10 ms for the 90th percentile with a recall rate of 95–98%.”
• Bing was running 100B+ vector indexes by 2019. In Microsoft’s own words, Bing could “search through this giant index of 100 billion-plus vectors to find the most related results in 5 milliseconds.” That’s six-plus years ago.
• Dense Passage Retrieval (DPR, EMNLP 2020) proved dense vector retrieval could beat Lucene-BM25 by 9–19% absolute in top-20 passage retrieval accuracy with a simple dual-encoder. DPR is the blueprint modern RAG retrieval follows — the retrieval step behind AI Overviews is a descendant of this pattern.
• MUVERA (2025) makes multi-vector retrieval as fast as single-vector search — roughly “10% higher recall with ~90% lower latency” than prior methods.
• TurboQuant (ICLR 2026) compresses vectors for nearest-neighbor search with reported 6x memory reduction and effectively zero accuracy loss.

The point isn’t to memorize the roadmap — it’s that embedding-based retrieval is how the big engines find relevant content, and has been for years.

What this means for SEO

Let me be careful here, because this is where SEO advice usually overreaches.

Vector proximity is the new gate into the candidate pool. In RAG-based answers, retrieval happens before generation. If your passage isn’t semantically close to the query embedding, it never enters the shortlist the model writes from — so it can’t be cited. That’s the mechanism.

But there is no “vector search optimization” knob. The underlying signal is semantic coherence and topical depth — which is what quality content always required. Vector search doesn’t reward a new trick; it penalizes thin content and keyword stuffing (which don’t form a coherent neighborhood in embedding space) and rewards genuinely comprehensive, well-structured coverage. As I put it in the embeddings piece, echoing Danny Sullivan on BERT: there’s largely nothing to “optimize for” here — you make your content cluster cleanly near the queries it should answer.

Two concrete implications that do follow:

• Chunking matters. Retrieval operates on passages, not whole pages. A page can rank for nothing if no individual passage is a clean semantic match. Write passages that stand on their own.
• Topical depth and entity coverage are how you occupy the right neighborhood in embedding space. Shallow, scattered content embeds into a fuzzy region near nothing in particular.

Vector search is the retrieval engine behind RAG and AI answers; passage ranking is what happens to the candidates after retrieval; and the AI crawlers feeding these systems embed and vector-index what they fetch. For the wider pipeline, see How Search Works.

AI summary

A condensed take on the Advanced version:

• Vector search = find the closest vectors to a query vector in a high- dimensional embedding space. It matches meaning, not exact words.
• Embeddings produce the vectors; vector search retrieves over them. And it’s a mechanism for semantic search, not a synonym — semantic search is the goal.
• ANN is approximate by design. Exact comparison over billions of vectors is impossible in real time, so HNSW / IVF / FAISS / ScaNN trade a sliver of recall (Google reports 95–98%) for orders-of-magnitude speed.
• HNSW is the production default (graph-based, logarithmic search, memory- hungry). ScaNN is Google’s open-sourced library behind Image Search, YouTube, and Google Play. Flat/exact indexes only make sense under ~10K vectors.
• Cosine similarity is the text default; for normalized vectors (most modern models, including OpenAI’s) cosine and dot product give identical rankings.
• Production is hybrid, not vector-only: BM25 + vector in parallel, fused with Reciprocal Rank Fusion, then reranked with a cross-encoder.
• It predates the LLM wave: Bing ran 100B+ vector indexes in 2019; ScaNN and DPR are from 2020. DPR beat BM25 by 9–19% and is the RAG-retrieval blueprint.
• SEO upshot: vector proximity is the gate into the AI-answer candidate pool, but there’s no knob to turn — it rewards topically coherent, passage-level depth and penalizes thin, keyword-stuffed content. Chunk-level clarity matters.

Official documentation

Primary-source documentation on vector / embedding search from the engines and the embedding-model providers.

Google

• Vector Search overview — the ScaNN-powered service, rebranded from “Vertex AI Vector Search” and now documented under the Gemini Enterprise Agent Platform; dense, sparse, and hybrid embeddings; the recall definition.
• Announcing ScaNN: Efficient Vector Similarity Search — anisotropic vector quantization and the 2x-faster benchmark result.
• Find anything blazingly fast with Google’s vector search technology — Kaz Sato’s explainer; keyword vs. vector; performance specs.
• RAG infrastructure using Agent Platform and Vector Search — how vector search is the retrieval step in RAG (page retitled from “Vertex AI and Vector Search” as Google folded this under the Gemini Enterprise Agent Platform).
• MUVERA: multi-vector retrieval as fast as single-vector search.
• TurboQuant: extreme compression for vector search.

Microsoft / Bing / Azure

• Vector Search overview — Azure AI Search — the engine-side definition of vector and hybrid search.
• As search needs evolve… (Bing vector search) — the 2019 piece showing Bing’s 100B+ vector index.

Embedding-model / vendor docs

• OpenAI — Vector embeddings — distance functions and why the choice rarely matters for normalized vectors.
• Weaviate — Vector Search Explained and Distance Metrics in Vector Search.
• Pinecone — What is Similarity Search? and Nearest Neighbor Indexes.
• Elastic — What is vector search?.

Quotes from the source

On-the-record statements from Google and Microsoft/Bing. Each link is a deep link that jumps to the quoted passage on the source page.

Google

• “The vector similarity search (or nearest neighbor search or simply vector search) capabilities of the Vertex AI Matching Engine… share the same backend as Google Image Search, YouTube, Google Play, and more.” — Kaz Sato, Developer Advocate, Cloud AI. Jump to source
• “Vector search provides a much more refined way to find content, with subtle nuances and meanings. Vectors can represent the meaning of content where ‘films’, ‘movies’, and ‘cinema’ are all collected together.” Jump to source
• “The technology is one of the most important components of Google’s core services.” — Kaz Sato. Jump to quote
• “Today, we’re just beginning the migration from traditional search technology to new vector search. Over the next 5 to 10 years, many more best practices and tools will be developed.” — Kaz Sato. Jump to quote
• ScaNN “outperforms other vector similarity search libraries by a factor of two on ann-benchmarks.com.” Jump to quote

Microsoft / Bing

• “Vector search is an information retrieval approach that supports indexing and querying over numeric representations of content. Because the content is numeric rather than plain text, matching is based on vectors that are most similar to the query vector.” — Azure AI Search documentation. Read the doc
• “Keyword search algorithms just fail when people ask a question or take a picture and ask the search engine, ‘What is this?’” — Rangan Majumder, Group Program Manager, Bing (2019). Read the source
• “Bing processes billions of documents every day, and the idea now is that we can represent these entries as vectors and search through this giant index of 100 billion-plus vectors to find the most related results in 5 milliseconds.” — Jeffrey Zhu, Program Manager, Bing (2019). Read the source

OpenAI (embedding-model provider, on distance metrics)

• “An embedding is a vector (list) of floating point numbers. The distance between two vectors measures their relatedness.” … “We recommend cosine similarity. The choice of distance function typically doesn’t matter much.” Read the doc

The mental models

1. The map. Every chunk of content is a dot on a high-dimensional map, with similar meanings placed near each other. The query is a dot too. Vector search returns the nearest dots. Everything else is an optimization of that.

2. Goal vs. mechanism. Semantic search is the goal (match meaning and intent). Vector search is one mechanism for reaching it (ANN over embeddings). Keep them separate and a lot of muddled AI-search writing snaps into focus.

3. The recall–speed dial. Every ANN index trades recall against latency, throughput, and memory. Exact (flat) = perfect recall, doesn’t scale. HNSW = near-perfect recall, fast, memory-hungry. There is no free lunch — there’s a dial, and you pick the setting.

4. Hybrid is the default, not the exception. Real retrieval = BM25 (keyword recall, catches exact tokens) + vector (semantic recall, catches meaning) + reranking (cross-encoder quality). If you picture production search as “vector vs. keyword,” you’ve got the wrong picture.

5. Retrieval is a gate, generation comes after. In RAG/AI answers, vector search decides the candidate pool before the model writes anything. Not in the pool → can’t be cited. This is why semantic proximity, not on-page keyword count, is the thing that gates inclusion.

6. The unit is the chunk, not the page. Vectors are computed per passage. A great page made of vague passages can match nothing. Write self-contained, on-topic chunks.

Vector search — cheat sheet

ANN index types

Distance metrics

Fast facts

• ANN is approximate by design — trades a sliver of recall for huge speed. Google’s Vector Search (formerly “Vertex AI Vector Search”) reports 95–98% recall.
• HNSW dominates production (Weaviate, Pinecone, pgvector, Qdrant). Logarithmic search; memory-hungry.
• ScaNN is Google’s open-sourced lib — same backend as Image Search, YouTube, Google Play; ~2x the QPS of the next library at equal accuracy.
• For normalized vectors, cosine = dot product in ranking. Most modern models (incl. OpenAI) normalize.
• Hybrid is the real production pattern: BM25 + vector, fused with RRF, then cross-encoder reranking.
• Vector databases: Pinecone, Weaviate, Chroma, Qdrant, Milvus, pgvector (listed, not ranked).
• DPR (2020) beat BM25 by 9–19% in passage retrieval — the RAG-retrieval blueprint. Bing ran 100B+ vector indexes in 2019.

SEO one-liner: vector proximity is the gate into the AI-answer candidate pool — no knob to turn; it rewards topical depth and clean, self-contained passages.

Test yourself: Vector search

Resources worth your time

Related on this site

• Embeddings — read this first: where the vectors come from.
• Semantic Search — the goal that vector search is a method for.
• RAG — vector search is the retrieval step inside it.
• Chunking — the passages that get embedded and searched.
• How Search Works — the broader crawl → index → retrieve → rank pipeline.

Foundational papers

• Dense Passage Retrieval for Open-Domain QA (Karpukhin et al., EMNLP 2020) — the dual-encoder retrieval blueprint that beat BM25 by 9–19%.
• The Faiss library (2024) — comprehensive overview of FAISS index types.
• HNSW — the algorithm behind most production vector databases (Malkov & Yashunin, 2018).

Open-source libraries

• ScaNN — Google’s similarity-search library.
• FAISS — Facebook AI’s billion-scale similarity search.
• DPR — Dense Passage Retrieval reference implementation.

Vendor explainers (clear and well-illustrated)

• Pinecone — What is Similarity Search?
• Weaviate — Vector Search Explained
• Elastic — What is vector search?

From around the industry

• iPullRank — The Evolution of Information Retrieval: From Lexical to Neural — Mike King’s deep dive on how search moved from lexical to neural/vector retrieval; useful framing for the SEO angle.
• Search Engine Land — The shift to semantic SEO: What vectors mean for your strategy — practitioner-focused look at how vector-based retrieval changes content strategy.
• Search Engine Land — New Google TurboQuant algorithm improves vector search speed — coverage of Google’s 2026 compression breakthrough for nearest-neighbor search.
• Search Engine Journal — Semantic Search With Vectors — accessible explainer tying vector similarity search to SEO outcomes.
• IBM — What is vector search? — solid vendor-neutral overview of the fundamentals; one of the top-ranking reference pages on the topic.
• Oracle — What Is Vector Search? The Ultimate Guide — comprehensive guide covering indexing, distance metrics, and database integration.
• Microsoft Bing Blog — Microsoft Open-Sources Industry-Leading Embedding Model (Harrier) — April 2026 release of Microsoft’s Harrier embedding model, ranking 1st on the multilingual MTEB-v2 benchmark; directly relevant to the Bing vector search context.

Vector Search

Vector search finds content by comparing the meaning of a query against stored content as numerical vectors, retrieving the closest ones in a high-dimensional embedding space. At scale it uses approximate nearest neighbor (ANN) algorithms — not exact comparison — to search billions of vectors in milliseconds.

Related: Embeddings, Semantic Search, Retrieval-Augmented Generation (RAG)

Vector Search

Vector search is an information-retrieval method that finds the most similar items in a high-dimensional embedding space by comparing numerical vectors with a distance metric. Instead of matching keywords, it converts both the query and the candidate content into vectors, then retrieves the candidates whose vectors sit closest to the query vector — measuring “closeness” with cosine similarity, dot product, or Euclidean distance.

Comparing every vector exhaustively is too slow at billion-item scale, so production systems use Approximate Nearest Neighbor (ANN) algorithms — HNSW, IVF, FAISS, ScaNN — that trade a tiny fraction of recall for orders-of-magnitude speed. Vector search is one mechanism for achieving semantic search (the goal), and it’s the retrieval step inside every modern RAG pipeline. Most serious production systems don’t run it alone: they pair it with keyword search (BM25) in a hybrid setup, then rerank the top results.

Related: Embeddings, Semantic Search, Retrieval-Augmented Generation (RAG)

Changelog