Elasticsearch BM25 is the default similarity module that scores how well documents match a query. It implements the Okapi BM25 probabilistic relevance function, replacing the older TF-IDF model. The algorithm calculates a score based on term frequency, inverse document frequency, and document length normalization, using the k1 and b parameters to control saturation and length penalties respectively.
Glossary
Elasticsearch BM25

What is Elasticsearch BM25?
Elasticsearch BM25 is the default relevance scoring algorithm in Elasticsearch since version 5.0, implementing the Okapi BM25 probabilistic function to calculate similarity between a query and documents in a sharded index.
In a sharded Elasticsearch deployment, BM25 statistics are computed per shard by default, which can lead to slightly different scores for identical documents on different shards. The dfs_query_then_fetch search type can be used to gather global term statistics before scoring, improving consistency at the cost of an extra round trip. The k1 and b parameters are configurable per index via the similarity settings.
Key Features of Elasticsearch BM25
Since version 5.0, Elasticsearch has used the Okapi BM25 algorithm as its default relevance scoring function. This probabilistic model replaces the older TF-IDF-based practical scoring function to provide more accurate, non-linear relevance ranking across sharded indices.
Non-Linear Term Frequency Saturation
BM25 applies a saturation function to term frequency, preventing a document from being scored disproportionately higher just because a query term appears many times. The impact of each additional occurrence diminishes logarithmically, controlled by the k1 parameter. This means a document with 5 occurrences of a term is not scored 5 times higher than one with a single occurrence, reflecting real-world relevance perception more accurately.
Document Length Normalization via the b Parameter
BM25 normalizes scores based on document length relative to the average document length in the index. The b parameter (default 0.75) controls this normalization strength:
- b = 1: Full normalization, scaling proportionally to average length
- b = 0: No normalization at all This prevents longer documents from having an unfair advantage due to naturally higher term frequencies, while acknowledging that longer documents are statistically more likely to contain a given term.
Probabilistic IDF Calculation
Elasticsearch BM25 uses the Robertson-Spärck Jones weighting for its inverse document frequency component. Unlike classic TF-IDF, this formula is derived from a probabilistic relevance framework that estimates a term's informativeness based on the ratio of total documents to documents containing the term. The formula log(1 + (N - n + 0.5) / (n + 0.5)) provides a smoother, theoretically grounded IDF curve that handles edge cases like terms appearing in all documents more gracefully.
Shard-Level Statistics and the dfs_query_then_fetch Mode
By default, Elasticsearch calculates BM25 statistics locally per shard, which can cause scoring inconsistencies across shards with different term distributions. For precise global scoring, use the dfs_query_then_fetch search type, which performs an initial round-trip to gather global term frequencies across all shards before executing the final query. This trade-off increases latency but ensures identical scores regardless of shard allocation.
Explain API for Score Transparency
Elasticsearch provides the Explain API (GET /index/_explain/doc_id) to decompose a document's BM25 score into its constituent components:
- Term frequency component: The saturated TF value
- IDF component: The inverse document frequency weight
- Field length norm: The normalization factor applied This transparency is critical for debugging relevance issues and tuning the k1 and b parameters for specific use cases.
Elasticsearch BM25 vs. TF-IDF
A technical comparison of the probabilistic BM25 ranking function against the classical TF-IDF vector space model for full-text search relevance.
| Feature | Elasticsearch BM25 | TF-IDF |
|---|---|---|
Theoretical Foundation | Probabilistic Relevance Framework (Robertson-Spärck Jones) | Vector Space Model (Salton) |
Default in Elasticsearch | ||
Term Frequency Saturation | Non-linear (k1 parameter) | Linear (raw count) |
Document Length Normalization | Configurable (b parameter, 0-1) | Cosine normalization or none |
Average Document Length Awareness | ||
Handles Term Frequency Exploitation | ||
Configurable Parameters | k1 (default 1.2), b (default 0.75) | None (fixed formula) |
Score Range | Unbounded positive | [0, 1] with cosine normalization |
Frequently Asked Questions
Clear, technical answers to the most common questions about how Elasticsearch implements the Okapi BM25 algorithm for relevance scoring.
Elasticsearch BM25 is the default relevance scoring algorithm in Elasticsearch since version 5.0, implementing the Okapi BM25 probabilistic relevance function to calculate a similarity score between a query and each document in a sharded index. It works by combining three primary signals: term frequency (how often a query term appears in a document, with a non-linear saturation curve), inverse document frequency (how rare or common that term is across the entire index), and document length normalization (preventing longer documents from dominating results simply due to size). The algorithm operates on top of an inverted index data structure, where each unique term maps to a postings list of document identifiers. During query execution, Elasticsearch traverses these postings lists, computes the BM25 score for each matching document, and returns results sorted by descending relevance. Unlike the older TF-IDF model, BM25's saturation function ensures that the fifth occurrence of a term contributes far less than the first, preventing keyword stuffing from gaming the ranking.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Core concepts that interact with and extend the default BM25 similarity in Elasticsearch, from index structures to scoring extensions.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us