Hello, I'm Rijul, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.
When you work with RAG systems and come across scenarios where keyword matching is relevant, you might come across a term called BM25.
It sounds like some technical code word, but it is actually quite straightforward.
BM25 = Best Matching 25
It's essentially the name researchers landed on for this particular ranking function. The "25" doesn't have a deeper meaning.
So what exactly is BM25?
BM25 is a ranking formula used to score how relevant a document is to a search query.
Instead of simply asking:
"Does this word appear: yes/no?"
BM25 calculates a relevance score based on three main ideas.
The Three Ingredients of BM25
1. Term Frequency
This basically means: how many times does the word show up?
If you search for:
"dog training"
A document that mentions "dog" 5 times is probably more relevant to dogs than one that mentions it once.
More mentions can mean more relevance.
But there is an important nuance.
The benefit of additional mentions decreases as the word appears more often.
Going from 1 mention to 2 matters more than going from 20 mentions to 21.
BM25 has a built-in diminishing returns effect, so a document can't simply win by repeating the same word hundreds of times.
2. Inverse Document Frequency (IDF)
This basically means:
How rare or special is this word?
Common words like:
"the", "is", "and"
appear in almost every document.
So matching on them tells you very little.
Rare words like:
"gnocchi" or "arrhythmia"
appear in far fewer documents.
If both the query and a document contain a rare word, that can be a much stronger signal of relevance.
BM25 therefore gives more weight to rare terms and less weight to common terms.
3. Document Length Normalization
This basically asks:
Is this document relevant, or is it just really long?
A 5,000-word document will naturally contain more words and potentially more repetitions than a 50-word document.
That doesn't necessarily mean it is more relevant.
BM25 adjusts the score based on document length so that long documents don't get an unfair advantage simply because they contain more words.
It compares each document's length with the average document length in the collection and uses that information when calculating the score.
An Example
Let's say the query is:
"laptop battery life"
We have two documents.
Document A
A 200-word product review that says:
- "battery" 4 times
- "laptop" 3 times
- "life" 2 times
Document B
A 3,000-word laptop manual that says:
- "battery" 4 times
- "laptop" several times
- "life" isn't used in the relevant context
BM25 can rank Document A higher because it matches more of the query terms, while its shorter length also means those occurrences carry more weight relative to the document as a whole.
Document B's greater length can work against it through the length-normalization component.
Why Is BM25 Still Used Today?
Despite embeddings being the newer approach, BM25 is decades old and is still widely used.
It doesn't require model training or a GPU. It can run efficiently on CPUs and is particularly useful when exact terms matter.
For example:
- Product IDs
- Error codes
- Names
- Technical terms
- Exact phrases
This is why BM25 remains an important part of search systems and is often combined with dense retrieval in hybrid search.
Wrapping Up
BM25 is a way of ranking documents based on how well their terms match a query.
It considers three main things:
Term frequency → How often does the term appear?
Inverse document frequency → How rare is the term?
Document length → Is the document unusually long?
Together, these produce a relevance score that helps the search system decide which documents should appear first.
Even with modern embedding-based retrieval, BM25 remains useful because semantic similarity and exact keyword matching solve different problems.
Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.
I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.
Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.
Spend code review effort where business risk is highest — not spread evenly across every diff.
⭐ Star it on GitHub:
HexmosTech
/
LiveReview
Blast-Radius Aware AI Code Review for Business-Critical Systems
LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems
LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.
| The exact math, not a black box | Visualize blast radius at a glance | Every factor that feeds the score |
|---|---|---|
 |
 |
 |
How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:
- A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.
- A 300-line UI change in one file, fully covered by…
Click below to try LiveReview with your codebase:
Top comments (2)
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support
The hybrid point is the key one. Pure dense retrieval tends to smear rare exact tokens like error codes and product IDs into generic semantic neighborhoods, so BM25 works less as a fallback and more as a lexical anchor that keeps identifiers recoverable. The real design question is how to fuse the two score distributions — reciprocal rank fusion is a fine baseline, but the tuned weights end up mattering a lot more as the corpus skews toward identifiers versus prose.