What is Recommendation System?
Recommendation System is a decision system that selects and orders a limited set of items for a user or context from a larger catalog, using available content, interaction, policy, and operational signals.
Quick Facts
| Created | 1990s with early systems like GroupLens and Amazon's item-to-item collaborative filtering |
|---|---|
| Specification | Official Specification |
How It Works
Separate candidate generation, scoring, and re-ranking
Candidate generation favors coverage and latency, often combining collaborative, content-based, popularity, and approximate-nearest-neighbor sources. A scoring model estimates task-specific utility on the smaller pool. Re-ranking then applies hard filters and list-level constraints such as deduplication, diversity, freshness, inventory, age suitability, or creator exposure. A sophisticated ranker cannot recover an item omitted by retrieval, so each stage needs its own contract and metrics.
Treat interaction logs as policy-shaped observations
Clicks, watch time, ratings, and purchases are useful but incomplete feedback. Users can react only to items they were shown, position changes attention, and the current recommender determines future training data. Missing interaction is therefore not automatically a negative preference. Record exposure, position, policy version, timestamp, and eligible catalog state; use exploration or justified counterfactual methods when causal claims matter.
Connect offline ranking quality to online outcomes
Evaluate retrieval coverage and Recall@K before ranking metrics such as NDCG@K, then inspect latency, calibration, catalog coverage, novelty, diversity, and important user or item slices. Use temporal holdouts to reduce future leakage and compare against popularity and non-personalized baselines. Online experiments are still needed because offline logs cannot fully reveal behavior under a new policy; pair the primary outcome with guardrails for harm, retention, and ecosystem health.
Key Characteristics
- Produces an ordered, capacity-limited decision rather than predicting every catalog item equally
- Usually separates high-recall retrieval from richer scoring and policy-aware re-ranking
- Learns from explicit feedback and policy-biased implicit interactions
- Must handle new users, new items, sparse histories, and changing intent
- Balances relevance with diversity, freshness, safety, fairness, and business constraints
- Requires stage-level offline tests plus controlled online evaluation
Common Use Cases
- Ordering products or offers under availability and policy constraints
- Selecting videos, music, articles, or courses from a large catalog
- Ranking feed items while controlling duplication and creator exposure
- Matching jobs and candidates in a two-sided marketplace
- Choosing the next support article or action for a current session
Example
Loading code...Frequently Asked Questions
Why do recommendation systems use retrieval and ranking stages?
A rich model cannot score every item in a large catalog within a tight latency budget. Retrieval cheaply preserves likely relevant items, scoring applies more expensive features to that smaller pool, and re-ranking enforces eligibility and list-level constraints. Each stage trades coverage, quality, and cost differently.
What is the difference between collaborative and content-based recommendation?
Collaborative methods learn from interaction relationships among users and items; content-based methods match item attributes to a user or context profile. Collaborative signals can discover latent taste but struggle with unseen entities. Content features help cold start but depend on descriptive metadata. Production retrieval often combines both.
Why is an unclicked item not necessarily a negative example?
The user may never have seen it, may have seen it in a weak position, or may have lacked time to respond. Logged feedback is conditioned on the previous policy and interface. Preserve impression and position data, distinguish exposed from unexposed items, and avoid treating every missing interaction as dislike.
How should a recommendation system be evaluated offline?
Use temporal or policy-aware holdouts, measure candidate Recall@K before ranking NDCG@K or related list metrics, and inspect latency, coverage, diversity, novelty, calibration, and slices. Compare with simple popularity and non-personalized baselines. Offline gains remain proxies because the new policy changes exposure.
How do you handle recommendation cold start?
For new items, use content, metadata, quality review, and controlled exploration. For new users, use current context, explicit preference collection, safe popularity priors, or session behavior. Track cold-start cohorts separately; fabricating interaction history or mixing them into mature-user averages hides the real problem.