How do you fold document freshness into a relevance score without letting recency dominate?

## Why freshness needs shaping at all Sorting by date is not relevance tuning; it throws the text signal away and returns whatever was published most recently regardless of whether it answers the query. The opposite extreme — pure text relevance — returns a five-year-old page for a query about an event last week. Freshness tuning is the middle ground: keep relevance as the primary signal and let age modulate it. ## Multiplicative, not additive Relevance scores are not normalised. A query on a rare phrase can produce scores an order of magnitude larger than a query on common words, and the spread between the first and tenth result differs per query too. That makes an additive freshness bonus unmanageable: `score + 5` is decisive on a query whose scores range from 2 to 6 and invisible on one whose scores range from 40 to 90. A multiplier in a bounded range — say 0.3 to 1.0 — behaves the same on both queries, because it rescales rather than displaces. Multiplication also has a useful invariant: among documents of identical age, the multiplier is constant, so their relative order is exactly the text ranking. Freshness only ever competes *across* age groups, which is what you meant. ## The three common shapes **Exponential decay** falls fastest at the origin and flattens out, with a constant half-life: every N days the multiplier halves. It suits content that loses value steadily and never quite becomes worthless — documentation, forum answers. **Gaussian decay** is flat near the origin, drops steeply in the middle, then flattens again. It suits a notion of "about this recent": everything within a window is roughly equivalent, then relevance falls off a cliff, then everything ancient is equally ancient. **Linear decay** falls at a constant rate and reaches zero at a defined point. Its distinguishing property is that it *does* hit zero, which is occasionally what you want — an events listing where anything past the event date is genuinely worthless — and usually what you don't. A useful parameterisation, whichever shape you pick, has four knobs: the **origin** (usually "now"), a **plateau** or offset where no penalty applies at all, a **scale** with a stated multiplier value at that distance (a half-life is just "multiplier 0.5 at the scale"), and a **floor** below which the multiplier never falls. ``` lam = ln(2) / half_life_days decay = exp(-lam * max(0, age_days - plateau_days)) score = relevance * (floor + (1 - floor) * decay) ``` The plateau prevents pointless churn — without it, two articles published four minutes apart get different multipliers and the result page reshuffles constantly. The floor prevents the pathological case where an obscure, perfectly-matching ten-year-old document is mathematically unable to reach page one. ## Picking the half-life from data, not taste The half-life is an empirical property of the corpus, and you can measure it: for a sample of queries, look at the age distribution of the documents users actually engaged with, and pick a half-life where the multiplier decays at roughly the rate that engagement does. A news corpus may want hours; a knowledge base may want a year or no decay at all. Different query classes in the same corpus often want different half-lives, which is an argument for detecting query intent rather than applying one global curve. ## Not every query wants recency Applying freshness uniformly is the most common error. "Champions league result" wants today; "how does TCP congestion control work" wants the best explanation ever written. If you can classify intent — by query pattern, by category, by a temporal-intent classifier, or simply by which vertical the search came from — apply decay only where it belongs, and consider making the half-life a per-vertical setting rather than a global constant. ## Geography is the same function Distance from the user is structurally identical: origin is the user's location, the plateau is "anything in the same neighbourhood is equally close", the scale is a distance at which the multiplier halves, and a floor keeps a genuinely excellent distant result reachable. The Gaussian shape is a natural fit for geography because "nearby" really does behave like a flat zone followed by a fall-off. ``` decay = exp(-ln(2) * (distance_km / scale_km)^2) # half the multiplier at scale_km score = relevance * (0.2 + 0.8 * decay) ``` ## Operational consequences A score that depends on the current time is not reproducible. Two things follow. First, result caching becomes age-sensitive — cache keys must incorporate a coarsened time bucket, or the cache serves yesterday's decay. Second, a bug report saying "this ranked wrong at 09:14" cannot be reproduced later unless you can pin the origin to a fixed timestamp; make the evaluation harness able to freeze it. Bucketising age (hour, day, week) rather than using continuous seconds mitigates both problems at negligible relevance cost, and it also stops every document's score changing on every tick. Finally, do not implement freshness by re-indexing documents with a recomputed decay value on a schedule. That turns a cheap query-time arithmetic operation into a corpus-wide write amplification problem, and it makes the decay stale between runs.