Support receives an ordinary question.
“What is a personal account?”
There are 4,862 pages in the knowledge base. The answer is there — more than once.
The first page explains what this part of the site is, how to sign in, and what a person can do there. The second is an old list of service changes. The third is a long page where the phrase “personal account” appears twenty-seven times. The fourth explains password recovery and calls it a “user profile.”
Search chooses the third page.
It is not broken. It has honestly found more matches.
That is precisely why it is dangerous.
Someone who opens the third page spends time reading and returns with the same question. Someone who lands on the right section of the first page immediately understands what the area is for. The first page ought to be the main result for this query. The difference is not the quality of the writing or the user’s ability to search. It is how the system understands a document.
For a person, a document has never been just a bag of words. The heading “Personal account: sign in and features” means one thing. The same words in an archive of changes mean another. A feature table, a page address, and body text all carry different kinds of information. Search has to notice that difference; otherwise it will return an instruction and its shadow with equal confidence.
BM25F is one answer to that problem.
When a document stopped being flat text
For a long time, classical search models used a convenient simplification: a document was a sequence of words. The system knew that a rare word was usually more useful than a common one, and that several matches were better than one. That logic produced TF-IDF, a model that assesses word rarity, and then BM25 — a formula for ordering the pages that were found.
BM25 added two important limits. Repeating a word should not endlessly increase confidence that a page is useful: the first mention of “personal account” matters, the second confirms the topic, and the twenty-seventh does not make the page twenty-seven times more useful. A long document should not win merely because it has more room for accidental matches.
That made BM25 a strong foundation for full-text search. But as documents gained more structure, a limitation appeared: BM25 works with words, yet it does not know where they stand in the document.
One phrase, four different signals
“personal account” in a page title tells us the page’s topic.
“personal account” in a section heading names the topic of a particular fragment.
“personal account” in a feature table may be one available option.
“personal account” in body text may be an instruction, context, or a passing mention.
This is not a difference in formatting. For search, it is a difference in meaning.
The obvious solution has a flaw
Once documents had structured parts, the first response was almost inevitable: count matches in the page title, body text, and page address separately, then add the scores. Give the title a weight of ten and the body a weight of one. In documentation, add a section heading, its place in the table of contents, and the names of important objects.
It sounds reasonable. But the order of calculation matters.
BM25 is designed so that each additional repetition adds less confidence. If a system scores every part of a document first and adds the finished scores afterwards, that logic changes. Each part reaches its own limit, and the system then treats them as independent pieces of evidence.
The problem is not the weights. It is when they enter the search.
In 2004, Stephen Robertson, Hugo Zaragoza, and Michael Taylor described a more careful approach in Simple BM25 Extension to Multiple Weighted Fields. That was BM25F: an extension of BM25 for documents divided into parts. See source 1.
What BM25F changes
BM25F first gathers matches from different parts of a document, taking their weight and length into account. It then applies BM25’s nonlinear saturation to the combined signal.
In simplified form:
For every word in the query:
combined signal =
page title × its weight
+ section heading × its weight
+ object names × their weight
+ body text × its weight
Then the combined signal goes through BM25 saturation.In the full formula, every part of a document has its own length adjustment. This matters: a page title has a few words and body text may have thousands. Using the same length adjustment for both would be as mistaken as treating a match in a heading and a footer as identical.
A thought experiment
In document A, “personal account” appears in the title and in a section heading, “What can I do in my personal account?” In document B, the same phrase appears eight times in a frequently asked questions section.
BM25F does not have to choose A every time. It does make it possible to explain why two strong structural signals may outweigh eight repetitions in a long text.
In this example, the first page should become the main result because it answers the whole question. The long list of changes remains in the results, but no longer obscures the explanation the person needs.
That is how search can be tuned for different document types. In a catalogue, brand, category, and product properties matter most. In a research collection, it is the paper title, abstract, and keywords. In a site help centre, it is the page title, section heading, and body text.
Where the idea is used
BM25F did not remain a university formula. Apache Lucene has a mechanism that treats several parts of a document as a whole and allows their relative importance to be set. See source 2.
SharePoint explicitly calls its field-based form of BM25 “BM25F” and allows weights and length adjustments for managed properties. See source 3.
Manticore Search offers BM25F as a separate way to order results using the weights of document parts. See source 4.
These ideas should not be confused. Searching across several parts of a document, or giving a page title an artificial priority, does not automatically mean classical BM25F. A system may assess parts independently, amplify an already found match, or combine text differently. Those approaches can be useful, but they behave differently.
The boundary of an exact match
Return to the original question. While the person types “personal account,” BM25F works in its strongest area: it sees those words and their place in the document.
But the question may be phrased differently: “Where can I see charges and pay an invoice?” It may lead to the personal account but does not contain its name. A field-based model can no longer rely on an exact match.
That is not a defect in BM25F; it is the boundary of its task. It answers: where do the query words stand in the most appropriate part of a document? It is not required to understand on its own that two phrases describe the same situation.
Search does not choose one winner
An exact name, error code, setting name, or product number — exact-match search.
A rephrased question — meaning-based search, which compares phrases that are close in meaning.
Related documents — search through connections between pages and concepts.
Several strong options — an additional comparison of results.
In a good search system, these methods do not displace one another. Exact-match search holds on to error codes, tariff names, setting names, legal wording, and product numbers. Meaning-based search helps when a person remembers the situation but not the exact name. The system then compares several strong results and chooses those that answer the question as a whole.
Where Dzen fits
In Dzen, word-based search also takes the structure of a source into account: page title, page address, fragment heading, and body text are treated differently. That makes exact matches a distinct signal rather than an accidental side effect.
But that signal does not get the last word. It is combined with meaning-based search and search through connections between pages; several results are then compared before an answer is prepared. An exact match in a heading is not lost, yet it cannot decide alone which source a person sees.
The idea of BM25F matters here more than the exact formula. It reminds us that search should see the shape of knowledge: not only which words a document contains, but what role those words play in it.
How search chooses a page about a personal account
Switch between search methods and change how much the page title and section heading matter.
