Okapi BM25

Okapi BM25 ("Best Matching 25") is a probabilistic ranking function that scores how relevant a document is to a keyword query. Developed by Stephen Robertson and Karen Sparck Jones around the Okapi information retrieval system, it remains the default sparse-retrieval baseline in modern search engines and the keyword half of most hybrid search stacks. Unlike dense vector methods, BM25 matches literal terms, which makes it strong exactly where neural methods are weak: exact phrases, product codes, error strings, and rare technical jargon. Ask it for "BM1398" or a specific kernel-log error and it will find the document containing that token every time — no model required.

The three ingredients

BM25 combines three signals. Term frequency (TF) rewards documents that use a query term more often, but through a saturation function with diminishing returns: the tenth occurrence adds far less than the second, so a page cannot win simply by chanting a keyword. Inverse document frequency (IDF) rewards rare terms, so a distinctive token like a chip part number counts for far more than a common word that appears everywhere. Document-length normalisation penalises long documents so they do not win merely by containing more words. Two tunable parameters govern the blend — conventionally k1 (how quickly term frequency saturates, typically around 1.2–2.0) and b (how strongly length normalisation applies, typically around 0.75) — and the defaults are good enough that most deployments never touch them. Together these produce a relevance score markedly more robust than classic TF-IDF, which is why BM25 quietly replaced it as the standard.

Where it fits in a self-hosted stack

BM25 needs no model training, no GPU, and no embeddings; it runs on a plain inverted index, which makes it fast, cheap, and fully transparent for a self-hosted search box — you can explain exactly why a result ranked where it did, term by term. For a sovereign operator indexing their own documentation, node logs, or the manuals for every miner on the rack, that transparency and zero-dependency footprint matter: search that runs on the same modest box as everything else, with no API key and no phone-home. Engines like Elasticsearch, OpenSearch, and SQLite's FTS5 all ship BM25 or close variants as the default scorer, so it is likely already inside software you run.

The blind spot, and the fix

BM25's weakness is paraphrase and vocabulary mismatch: it cannot match "car" to "automobile," or connect "miner won't start" to a document that says "fails to boot," because it sees tokens, not meaning. That blind spot is exactly why operators pair it with vector-based semantic search and merge the two ranked lists with Reciprocal Rank Fusion. The combination gives a private RAG pipeline both literal precision and conceptual recall — BM25 catches the part numbers and exact error strings, the dense side catches the paraphrases, and the fusion step means neither has to be perfect. In practice, keeping BM25 in the loop is one of the cheapest quality wins in local retrieval: a keyword engine from the 1990s regularly rescues queries that a modern embedding model fumbles, and it costs essentially nothing to run alongside.

The craftsman's summary: before reaching for anything neural, index your corpus with BM25 and see how far exact terms take you. For technical material — specs, logs, error codes — the answer is usually "surprisingly far."