In this article
A property boost changes ranking influence; a filter or token-match condition can remove a document from eligibility.
BM25F field weights in Weaviate change how lexical evidence contributes to ranking; they do not replace the decision about which evidence is searchable. Separate property selection, token matching and boosting before concluding that a title-heavy ranking needs another embedding model.
Identify the lexical evidence fields
The keyword-search reference supports choosing properties and weighting their contributions. A title can be a useful summary, while a body contains the actual answer. Decide whether both should participate and preserve that choice in the fixture. Copied menus, repeated page labels and imported boilerplate can otherwise provide many lexical matches without useful supporting content. Inspect actual stored field values before changing ranking weights.
Distinguish weighting from exclusion
A property boost changes influence; a filter removes eligibility. A token-match operator can change whether a document enters the lexical result at all. These are different interventions. If a supporting passage disappears after a configuration change, first establish which boundary changed. Increasing a body-field weight cannot recover a document excluded by the match condition. Similarly, a stronger title score does not prove that the body supports the requested claim.
Keep hybrid effects separate
Weaviate’s hybrid concepts explain that lexical and vector results contribute to a combined ranking. Changing BM25F fields therefore changes one input branch before fusion. Hold the embedding path and fusion settings fixed while evaluating field weights. Otherwise the experiment cannot explain whether an improvement came from better lexical candidates or a changed combination of unrelated signals.
Test an answer-bearing body
Create an illustrative set containing a matching title with an irrelevant body, a generic title with an answer-bearing body, and a document containing the exact requested code. Write relevance judgments from the full source content. Compare selected-property configurations, then inspect scores and supporting passages rather than accepting a familiar title as evidence.
| Document feature | Diagnostic question |
|---|---|
| Exact title terms | Does the body answer the question? |
| Body-only evidence | Can it enter lexical candidates? |
| Repeated boilerplate | Is it generating misleading matches? |
Preserve query-side settings
The hybrid query reference provides the branch-level configuration used by the application. Keep that actual request with the collection schema. A corrected import or field rename can leave an old query searching an obsolete property. Client and server versions also matter when adopting newer match or boost options. Validate the selected interface instead of borrowing an example from a different API generation.
Evaluate useful supporting content
Review identifier queries, title-like queries and natural questions separately. A single average can reward exact title matching while concealing lost body evidence. Preserve both document ranking and the passage that explains each judgment. The accepted configuration should describe searchable properties, weighting and matching behavior, including remaining failure cases. Its purpose is to make relevant evidence reachable, not merely increase scores of documents that look attractive in a search-results list.
Related reading: A local RAG server: placing components around the GPU; Evaluating embeddings for Russian language retrieval.