Ranking

Ranking orders candidate items for a user or context. In a recommender, the ranker usually combines predicted relevance with freshness, diversity, eligibility, risk, and product constraints. It sits after candidate generation in most retrieval and ranking architectures.

Pointwise, pairwise, and listwise

A pointwise ranker might score

$$s(u,i)=f_{\theta }(x_{u,i})-\lambda \mathrm{age}(i),$$

Here $u$ is the user or request context, $i$ is a candidate item, $x_{u,i}$ contains user-item features, and $f_{\theta }$ is the learned relevance model. The penalty weight $\lambda$ controls how strongly stale items are pushed down through the item age term.

then sort by $s$. A list-level postprocessor can add constraints such as author diversity or inventory caps. Evaluation of recommenders then uses top-k metrics such as NDCG or recall.

Worked example

Apply a freshness penalty of $0.03$ per age unit, then enforce author diversity in the top two:

Item	Relevance	Age	Author	Score $rel-0.03age$
0	0.90	1	0	0.87
1	0.85	10	0	0.55
2	0.70	2	1	0.64
3	0.60	0	1	0.60

The raw score order is item 0, item 2, item 3, then item 1. Item 1 has high base relevance but is stale and from the same author as item 0, so item 2 enters the top list. This connects ranking directly to diversity, novelty, coverage, and serendipity.

Caveats

Pointwise relevance can over-optimize short-term clicks. List constraints can hide relevance regressions if they are not logged and measured. Rankers trained on historical positions need bias correction or online validation because exposure shapes the labels.

References

• scikit-learn documentation: ndcg_score
• Herlocker et al., 2004, Evaluating Collaborative Filtering Recommender Systems

Nav

Section — Recommendation Systems and Personalization

← Candidate Generation Retrieval and Ranking Architectures →