Candidate Sources Are a Portfolio

In one line: no single retriever covers the item space, so the candidate stage is several of them blended, and the blend is a design parameter.

Why not just use the best one

Because "best" is measured on the traffic you already have, and every source is blind somewhere.

A collaborative model is the strongest source on average and cannot say anything about an item nobody has interacted with — its embedding is untrained. A content model handles that item on day one and is systematically weaker where interaction data is rich, because item text is a poorer signal than a million observed co-views. Trending covers what is happening right now, which no model trained yesterday knows about.

The sources are not competing for the same slot. Each one exists because the others return nothing in some region.

The blend is the parameter nobody names

Having several sources, you must decide how many candidates each contributes. This is a real design decision and it gets skipped in most interview answers.

Two ways to do it:

Fixed quotas. Collaborative supplies 600, content 200, trending 100, exploration 100. Simple, predictable, easy to reason about, and it guarantees each source a floor — which matters, because a purely score-based blend lets the strongest source crowd everything else out on most requests, at exactly the times its blind spot matters.

Score-based. Every source produces calibrated scores; take the global top thousand. Better on average, and it requires scores that are comparable across sources, which they usually are not — a cosine similarity and a trending rank are not the same quantity.

Production systems typically use quotas with a dynamic adjustment: a new user gets more content-based and trending, an established user gets more collaborative. Which is another way of saying the blend is context-dependent.

Dedup, and the double-counting trap

Sources overlap. The same item arrives from collaborative and trending, and if you keep both you have quietly given it two chances at the ranker and consumed two quota slots.

Dedup on item id, keep the highest-scoring instance, and — this matters — record which sources retrieved it. That set is a feature: an item found by three independent sources is a different proposition from one found by a single source, and the ranker can use that.

What each source actually needs

The refresh column is where item freshness gets decided. If new items must be recommendable within an hour, the collaborative path cannot be the only source — its item tower runs in batch — so the content and trending sources are carrying that requirement, not the model.

Retrieval is where the ceiling is set

Worth restating in its own right, because it changes where you spend effort.

An item that no source retrieves cannot be recommended, no matter how good the ranker is. Ranking can only reorder what it is given. So the ceiling on the whole system is set at the candidate stage, and the metric that matters there is recall against some notion of what should have been retrievable.

That cycle is the first appearance of the feedback loop, and it is the reason the exploration source exists. Without a deliberate mechanism for showing items the model would not have chosen, the retrievable set only ever shrinks toward what was already retrievable.

Measuring a source

Two questions per source, and both need answers:

What is its unique contribution? Not its overall hit rate — the fraction of successful recommendations that only this source retrieved. A source whose contributions are all also found by collaborative is paying for itself twice.

Where does it win? Segment by user tenure, item age, session context. A content source that looks mediocre overall may be carrying the entire new-item experience, and an average metric hides that completely.

Next: the ranker, and the several things it predicts at once.