How AI Search Actually Finds You: Keyword, Vector, and Hybrid Retrieval

AI search finds you through a retrieval layer that runs before the model writes a single word — it matches your pages by exact terms and by meaning, then reranks the survivors to decide which few become eligible to be cited. This is the plumbing beneath every AI answer. Understanding it tells you why some pages get pulled in and others, no less relevant to a human, never make it into the room.

This is the architecture angle. The companion piece, how AI engines choose citations, covers the selection judgment — relevance, authority, freshness. Here we look one layer down: the mechanics of how passages get found in the first place.

How does a query become a search?

A query becomes a search the moment the engine decides it needs outside information rather than answering from memory. The system takes the user's question — often rewritten or expanded into several variants — and issues it against a search index built from crawled pages. That index does not store whole documents; it stores passages, small chunks created by chunking each page so the engine can pull the exact paragraph that answers a question rather than a 3,000-word article.

Two scoring methods then run against those chunks. One matches literal words. The other matches meaning. The engine keeps the best of both, because each is blind to something the other sees clearly. This is the retrieval stage, and it is governed by the extractability pillar: a passage that is hard to isolate and score is a passage that loses here.

What is keyword (sparse) retrieval?

Keyword retrieval scores pages by how well their literal terms overlap with the query's literal terms. The dominant algorithm is BM25, a refinement of TF-IDF: it rewards a page for containing the query's words, weights rarer words more heavily, and discounts words that appear everywhere. It is called sparse because each document is represented as a long, mostly-empty vector of term counts.

BM25 is fast, transparent, and unbeatable at exact matches — a product SKU, a person's name, a specific error code, a precise phrase. Its weakness is that it has no idea what words mean. Ask it about "cars that sip fuel" and it will not connect that to a page about "fuel-efficient vehicles" unless the words literally overlap. That blind spot is exactly what vector retrieval was built to cover.

What is vector (dense) retrieval?

Vector retrieval scores pages by meaning rather than by matching words. An embeddings model converts the query and every candidate passage into a dense list of numbers — a vector — positioned so that texts with similar meaning sit close together in that space. The engine then measures closeness with cosine similarity and, because comparing against millions of vectors exactly would be too slow, uses approximate nearest neighbor search to find the closest matches quickly.

This is vector search, and its strength is paraphrase: it finds your "fuel-efficient vehicles" page from a "cars that sip fuel" query because the two mean the same thing. Its weakness is the mirror image of BM25's — it can rate a passage highly for being broadly on-topic even when it never answers the question, and it can fumble rare exact terms that have weak meaning signals.

Why do engines use hybrid retrieval?

Engines use hybrid retrieval — running keyword and vector search together and merging their scores — because the two methods fail in opposite directions. Keyword search anchors the result set to the literal terms that matter; vector search rescues the relevant passages that used different words. Fuse the two rankings and you recover more genuinely relevant candidates than either produces alone, with fewer of each method's characteristic mistakes.

For you, that has a concrete consequence: covering only one register is leaving retrieval on the table. A page that uses jargon but never the plain-language question may match vectors yet miss keyword scoring on the terms people actually type — and vice versa. The fix is to write both: the exact question a person asks as a heading, and a complete, meaning-rich answer beneath it.

What does the reranker do before the answer?

After hybrid retrieval produces a merged candidate set, a reranker re-scores those candidates against the exact query and keeps only the top few. This is reranking, usually performed by a cross-encoder — a model that reads the query and a passage together and judges how well that passage actually answers the question, rather than comparing two precomputed vectors at a distance. It is slower than retrieval, so it only runs on the shortlist, and it is precise where retrieval is merely fast.

The reranker is where retrieval ends and selection begins — and it is covered in depth in how AI engines choose citations and what is a reranker. The point to carry from here is that nothing reaches the reranker unless retrieval found it first.

What does this mean for your content?

It means you optimize for the whole pipeline, not one stage. Match keyword retrieval by using the literal words people search; match vector retrieval by answering the real intent completely; survive the reranker by being the clearly best, self-contained answer to the exact question. These are not three different jobs — they are one well-shaped passage that happens to satisfy every stage.

The retrieval layer is also why how RAG works and embeddings are worth understanding directly: they are the machinery deciding, before any answer is written, whether you are in the conversation at all.