Candidate Generation

Candidate generation retrieves a small set of plausible items from a large catalog so a slower ranking model does not score everything. Sources often include item-based collaborative filtering, content-based recommendation, trending items, subscriptions, and business rules.

Merging candidate sources

If sources $S_1,\dots ,S_m$ return scored item sets, a simple merge is

$$s(i)=\underset{j}{\max }\frac{s_j(i)}{{\max }_{k\in S_j}{s}_j(k)}.$$

The production contract is usually: retrieve many, deduplicate, enforce eligibility, then send candidates to the retrieval and ranking architecture.

Worked example

Three candidate sources might emit scores on different scales:

Source	Raw candidates	Source maximum	Normalized candidates
ALS	A: 0.91, B: 0.72, C: 0.15	0.91	A: 1.000, B: 0.791, C: 0.165
Content	B: 0.63, D: 0.81, E: 0.35	0.81	B: 0.778, D: 1.000, E: 0.432
Trending	A: 0.25, D: 0.40, F: 0.77	0.77	A: 0.325, D: 0.519, F: 1.000

Taking the maximum normalized score per item gives A: 1.000, B: 0.791, C: 0.165, D: 1.000, E: 0.432, and F: 1.000. The top four candidates are A, D, F, and B. Normalizing per source lets different candidate generators contribute, while the ranker can later learn which source is trustworthy for which user or context.

Caveats

Candidate recall limits final quality: the ranker cannot recover items never retrieved. Per-source normalization can overpromote weak sources. Log source membership and retrieval scores so offline evaluation can diagnose where good items were dropped.

References

• Li et al., 2010, A Contextual-Bandit Approach to Personalized News Article Recommendation
• scikit-learn documentation: cosine_similarity

Nav

Section — Recommendation Systems and Personalization

← Hybrid Recommenders Ranking →