Relevance Tuning

## Two different jobs Every search request does two separable things. It decides **which documents are eligible** to be returned at all, and it decides **in what order** the eligible ones appear. A filter belongs to the first job; a boost belongs to the second. Confusing them is the most common early mistake in relevance work, because in English both are phrased the same way — "prefer documents like this", "only show me things that…" — and because a big enough boost *looks* like it excludes things right up until the day it doesn't. ## What a filter does A filter is a boolean predicate evaluated per document: it matches or it does not. Documents that fail are removed from the candidate set and contribute nothing further. Because the answer is binary, the engine needs no term frequencies, no field lengths and no scoring machinery to evaluate it, which is why filter clauses are typically far cheaper than scoring clauses, and why their results are usually cacheable — the set of documents where `category = shoes` is the same for every user who asks, so an engine can keep that document set around and reuse it across requests. Filters are the right tool for **correctness rules**: access control and tenant isolation, geographic or legal availability, soft-deleted or unpublished records, expired listings, content the user has explicitly blocked. The test is blunt: if a user seeing this document at position 50 would be a bug, an incident, or a compliance violation, it is a filter. ## What a boost does A boost changes the score of documents satisfying some condition, or scales the contribution of a particular field or clause. Every document remains eligible; only the order changes. Because relevance scores are relative and unbounded — a document matching a rare phrase can score many times higher than one matching a single common term — a boost is a statement about *preference strength*, never a guarantee. Give in-stock items a 1.5x multiplier and an out-of-stock item with an outstanding text match may still rank first. That is the intended semantics, not a defect. Boosts are the right tool for **quality signals**: freshness, popularity, stock status, document quality, the user's language, profitable categories. ## Why the substitution fails in both directions *Boost used as a filter.* Suppose restricted documents get a 0.01 multiplier instead of being filtered out. For most queries they sink far enough that nobody notices. Then a query arrives whose only good match is a restricted document — a narrow tail query, or a query where the restricted item matches an exact phrase — and it surfaces. Every access-control leak of this shape looks the same in the post-mortem: someone expressed a binary rule as a graded one. *Filter used as a boost.* The opposite mistake is quieter but costs more traffic. Product teams accumulate constraints — in stock, ships to this region, above a rating threshold, not on clearance, has an image — and each one is added as a hard filter because that is easy. On head queries the catalogue is dense enough that results survive. On tail queries the constraint stack empties the page, and an empty search result is the single worst outcome in a search product: users don't refine, they leave. ## The zero-results path Deciding the filter/boost split is really an exercise in writing down which constraints are *mandatory*. Everything else becomes a boost, and you handle the empty case explicitly: 1. Detect that the constrained query returned nothing (this deserves its own metric and its own alert). 2. Relax the weakest non-mandatory constraints in a defined order, and re-run. 3. Tell the user what you did — "no exact matches, showing related results" — and offer the dropped constraint back as a one-click refinement. Silently dropping a constraint the user explicitly asked for is worse than an honest empty state; silently dropping one *you* added on their behalf is usually the right call. ## Cost and caching Because filters are boolean and user-independent, they cache well and cut the candidate set before the expensive scoring work happens. A selective filter therefore makes a query faster; a boost never does, because everything still gets scored. That is a secondary reason to express genuinely binary conditions as filters rather than as scoring clauses with a huge weight — but it must not be the primary one. Correctness decides the split; performance is a bonus that falls out of it. ## A practical inventory For any search surface, write the constraint list down once and label each entry: - **Mandatory (filter)** — permissions, tenancy, legal availability, deletion state. - **Strong preference (large boost)** — in stock, in the user's language, complete records. - **Weak preference (small boost)** — freshness, popularity, margin. That document is worth more than any individual weight, because it is the thing new engineers get wrong, and it is the thing that quietly grows a filter per quarter until the tail of your query traffic returns nothing.