How search engines actually rank results

Finding matches is the easy 10%

Given a search index - essentially a hash table mapping each word to every document containing it - finding every document that contains your search terms is a fast, solved problem. The actual hard problem search engines spend most of their effort on is ranking: given a thousand documents that all technically contain your words, which handful are actually what you meant?

Two genuinely different techniques answer that question today, and most real search systems now combine both.

BM25: scoring exact word matches, properly

BM25 is a refinement of the intuitive idea "the more a document mentions your search term, the more relevant it probably is" - but a naive version of that idea breaks in an obvious way: a document that says a common word like "the" a hundred times shouldn't outrank one that precisely matches a rare, specific term once. BM25 corrects for this with two adjustments: it weights rarer terms more heavily than common ones (a match on "consistent hashingConsistent hashingA way of mapping keys to servers so that adding or removing one server only reshuffles a small fraction of keys, not nearly all of them. What makes it practical to grow or shrink a cache or shard set without a mass migration." counts for more than a match on "the"), and it dampens the benefit of a word appearing many more times, since going from 1 mention to 2 matters more than going from 20 mentions to 21.

Vector search: matching meaning instead of exact words

BM25 has a hard limit: it only matches words that are literally present. Search "how to make my APIAPIA defined way for one piece of code to ask another to do something, without needing to know how it happens internally. Not a specific technology - a function signature, a library's exports, and a REST endpoint are all APIs. faster" and BM25 won't surface a great document titled "reducing backend latencyLatencyHow long one specific operation takes to complete, from request to response. Different from throughput, which measures total work done over time - a system can be excellent at one and mediocre at the other.," because it shares no exact words with your query at all, despite meaning almost the same thing. Vector search solves this differently - a machine learning model converts both your query and every document into a list of numbers (an embedding) positioned in a high-dimensional space, such that texts with similar meaning end up mathematically close together, regardless of matching exact wording. Finding relevant results becomes a geometry problem: find the documents whose vectors are nearest to your query's vector.

Why real systems use both together

BM25 is fast, cheap, and extremely precise when someone searches for an exact term, a product code, or a specific name - vector search can actually do worse here, since "meaning-based" similarity sometimes blurs past an exact match that really mattered. Vector search wins when the query and the answer share intent but not vocabulary. Most production search systems today run hybrid search: both techniques score every candidate, and the two scores get combined (often with the vector score narrowing down candidates fast using an approximate nearest-neighbor index, and BM25 helping fine-tune the final ranking, or vice versa depending on the system).

The actual infrastructure underneath a vector search

Searching for "nearest" vectors among millions or billions of embeddings by brute-force distance calculation would be far too slow to run per query - so vector search systems use approximate nearest-neighbor indexes (HNSW is the most common one today), a data structure that trades a small amount of accuracy for a massive speedup, letting a similarity search that would otherwise scan the whole dataset instead touch only a small, relevant fraction of it. It's the same underlying trade-off bloom filters make - give up perfect precision deliberately, in exchange for being fast enough to actually use at scale.