Making retrieval prefer fresh information when similarity alone misleads

Short answer·Medium·4.0 · 0·~3 min·Asked atElevenlabs Perplexity Unity

Attempt it

Semantic similarity is time blind: a year old document can be as similar to a query as today's. For a corpus where recency matters, how do you make retrieval prefer fresh information, and when should you NOT?

Free · 2 AI evals / day

Vector retrieval ranks chunks by how close their meaning is to the query. It has no idea when a document was written. So a year-old chunk that happens to be phrased like the query can score just as high as today's — bad for anything time-sensitive like prices, policies, or news. The fix is to add an explicit **recency signal** to ranking. There are three common ways. A time-decay weight scales the similarity score by a function of the document's age, so older content is gently pushed down. A date pre-filter restricts the search to a recency window before ranking, useful when anything past a cutoff is simply invalid. Or you feed recency as one feature into a reranker and let a learned model balance freshness against relevance. All three need two things: a reliable timestamp in each document's metadata, and a decay rate or window tuned to how fast that domain actually goes stale. When should you not do this? On timeless corpora — definitions, standards, foundational references — the newest version isn't more correct, and down-weighting older authoritative material would hurt. Recency is a knob you turn on per domain, not a default.

The core problem is that **semantic similarity is time-blind**. Cosine similarity scores meaning, so a stale chunk phrased close to the query can outrank the current one. For prices, policies, news, or changelogs, that's a correctness bug, and the retriever has no built-in way to break the tie in favor of fresh content. The fix is to inject recency as an explicit signal, and there are three levers. A time-decay weight combines age into the score — for example multiplying similarity by an exponential decay in age, so relevance and freshness trade off continuously. A date pre-filter is harder-edged: restrict the candidate set to a recency window before ranking, which is right when anything past a cutoff is simply invalid. The third lever treats recency as one feature in a reranker, letting a learned model combine freshness with relevance instead of a hand-tuned blend. All three depend on the same two inputs. The first is a reliable timestamp in metadata, and "reliable" is doing work — ingestion date is not the same as content date. The second is a decay rate or window tuned to the domain's actual staleness clock. News goes stale in hours; a benefits policy in months. When not to use it: timeless corpora. For definitions, standards, or foundational docs, the newest version isn't more correct, and recency weighting would demote older but authoritative material. Recency is a domain-specific knob; applying it as a universal default hurts the corpora that don't age.

TL;DR

Similarity ranks meaning, not time, so a stale but similar chunk can win. Add a recency signal — time-decay, date pre-filter, or rerank feature — but skip it on timeless reference corpora.

Memory aid

Easy to grasp

Imagine asking a friend for today's weather, and they hand you two notes that look almost identical — both say "sunny, 70 degrees." One was written this morning; the other is from a year ago. If your friend only matches notes by how well the words fit your question, they can't tell which is current, so they might give you the old one. The fix is to also check the date stamped on each note and lean toward the fresh one. But this only helps for things that change — weather, prices, news. For something timeless, like "how many days are in a week," the date on the note doesn't matter at all, and preferring the newest note could even make you toss out a perfectly good older answer. So checking the date is a setting you turn on only when the topic actually goes out of date.

Key concepts

Retrieval-Augmented Generation Vector Databases Embeddings

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Recency in retrieval is a question that separates people who've operated a RAG system from people who've only read about one. The naive view is "vector search finds the most relevant docs, done." The operational reality is that relevance and freshness are two different objectives, and a similarity score only optimizes the first.

What makes this a good interview question is the second half: when should you not prefer fresh content? A candidate who reflexively adds recency everywhere reveals they think of it as best practice rather than a tunable knob. The strong answer covers the mechanisms and then draws the boundary where they backfire.

Why similarity has no concept of time

An embedding maps text to a vector that captures meaning. Cosine similarity then measures the angle between the query vector and each document vector. Nothing in that pipeline encodes when a document was written — the date is metadata sitting beside the vector, not inside it.

So consider two chunks: this morning's price list and last year's, both saying "the standard plan is priced per seat." Their wording is nearly identical, so their embeddings are nearly identical, so their similarity to a pricing query is nearly identical. The retriever ranks them as essentially tied, and the tie breaks on tiny phrasing noise. Half the time you get the stale one.

For a timeless fact, this doesn't matter — both chunks are equally correct. For a time-sensitive fact, it's a correctness bug, and crucially it's not one you can fix by improving the embedding model. A better embedding encodes meaning more faithfully, which makes the two near-duplicate chunks even closer, not easier to separate. Time is orthogonal to meaning, so it has to enter ranking as a separate, explicit signal. That reframing — recency is a second objective, not a quality of the embedding — is the foundation everything else builds on.

Three levers and the shapes they impose

What recency ranking actually requires

The boundary: when recency weighting hurts

Recency ranking versus stale-index deletion — don't confuse them

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Lever	How it works	Best when
Time-decay weight	Scale similarity by a function of age (e.g. exp(-age/τ))	Old content is less preferred but still valid
Date pre-filter	Restrict candidates to a recency window before ranking	Anything past a cutoff is simply invalid
Rerank feature	Feed age as one input to a learned reranker	At scale, when freshness-relevance trade varies by query

Real products, models, and research that use this idea.

News and search RAG systems apply time-decay so today's coverage outranks a year-old article on the same event.
Vector stores like Qdrant and Pinecone support date metadata filters to restrict retrieval to a recency window.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you tune the time-decay half-life rather than guessing it?

Fit the decay rate to behavioral data — how quickly clicks or thumbs shift toward newer documents — or measure how fast answers go wrong by document age, and set τ to match.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Turning recency weighting on globally as a default. On a timeless reference corpus it down-weights authoritative older material for no reason — recency is a domain-specific knob, not a universal one.

60 second bullets to scan on the way to the call.

Why semantic similarity ignores document age
The three recency levers and how their shapes differ

Primary sources. Browse if you want the original framing.