What is a recommender system?

By MLRec Staff · Updated on September 22, 2026

What is a recommender system? A practical taxonomy for ML and data-mining researchers

A recommender system is a software system that estimates how relevant, useful, or desirable an item is to a particular user in a particular context, and then uses those estimates to select and rank what to display. This single-sentence definition glosses over the most interesting technical challenges: the estimation problem is often formulated as a classification task, the data are often implicit and biased, and the “ground truth” is rarely observed. When preparing a presentation for a venue like the MLRec workshop at the SIAM International Conference on Data Mining, or as a data scientist deciding what to build, the useful question is not simply “what is a recommender system?” but rather, “Which family of recommender systems am I actually building, and what does that require of me?”

This article provides a functional taxonomy, the trade-offs that divide these families, and the evaluation and implementation caveats that determine whether a system survives contact with real users.

The core formulation

Almost any recommender system can be expressed as a scoring function. Given a user $u$, an item $i$, and a context $c$ (time, device, session, location), the system learns or defines a score $s(u, i, c)$ and returns the top $k$ items according to that score, subject to constraints (availability, variety, business rules).

Two key factors differentiate this from ordinary supervised learning:

The label is often missing, not negative. A user who did not click on an item may simply not have seen it. Treating unobserved interactions as negative signals is the most common cause of silent errors in production recommendations.
The system changes the data it learns from. Recommendations influence what users see, which in turn affects future interactions. This feedback loop is why offline metrics can look excellent while online metrics remain stagnant.

The main families and their underlying assumptions

Collaborative filtering (CF)

CF assumes that users who agreed in the past will continue to agree in the future. It does not require any information about the item content itself.

Memory/Neighborhood-based methods. User-based CF finds users similar to the target and aggregates their ratings; Item-based CF finds items similar to those the target has already liked. Item-item similarity (popularized by Amazon’s item-to-item approach) tends to be more stable and less expensive to precompute than user-user similarity because item neighborhoods change more slowly than user preferences.
Model-based CF. Matrix factorization learns latent vectors for users and items such that their inner product approximates observed interactions. Simon Funk’s 2006 work on incremental SVD and the subsequent Netflix Prize era made this the industry standard for a decade. Modern variants add implicit feedback weighting (such as the work by Hu, Koren, and Volinsky), secondary information, or neural parameterization.

Trade-off: CF is powerful when interaction data is dense and the catalog is stable. However, it degrades significantly with “cold start” items and users and cannot explain why two items are similar.

Related: — Browser-based, hands-on ML and data-science tracks you can start in 10 minutes.

Content-based filtering

Content-based systems represent items based on their characteristics (text, tags, audio embeddings, product attributes) and associate them with a user profile created from that user’s history. They handle new items well because the characteristics of a new item are immediately available and interpretable (“We recommend this because it shares these attributes with items you have liked”).

Trade-off: These systems can become too specialized. A user reading an article on a specific topic may receive a feed of near-duplicates. They also struggle to discover cross-domain connections that are not explicitly encoded in the features.

Hybrid and ensemble designs

Most production systems are hybrids. Common patterns include:

Our pick: — University- and industry-branded ML specializations with graded assignments and shareable certificates.

Feature Improvement: Feeding CF embeddings and content embeddings into the same downstream classifier.
Cascade: Using a lightweight content-based retriever for cold starts and switching to CF as interactions accumulate.
Weighted Mixture: Combining results from separate models with weights adjusted online.

The architecture descriptions published by Netflix are an excellent reference for breaking down a large hybrid pipeline into retrieval, ranking, and re-ranking tiers.

Knowledge-based and constraint-based recommenders

When interaction data is sparse but domain knowledge is rich (e.g., configurable products, travel planning, financial services), systems rely on explicit constraints and rules rather than learned similarities. These are common in corporate environments and are usually the correct choice when the catalog is small and the risk of a bad recommendation is high.

Context-aware and sequential models

Contextual recommenders account for time, location, companion, or session intent. Sequential models (session-based neural approaches, transformer-based recommenders) predict the next item based on an ordered history rather than a static preference vector. This is critical for messaging, short-form video, and e-commerce, where user intent can shift within minutes.

Comparison: choosing a family

Family	Data Required	Cold-start Behavior	Interpretability	Typical Failure Mode
Neighborhood CF	Dense user–item interactions	Poor	Medium (via neighbors)	Sparsity; popularity bias
Matrix Factorization	Interactions, optional side features	Poor to Medium	Low	Overfits popular items; opaque
Content-based	Item features + user history	Good for new items	High	Over-specialization; filter bubble
Hybrid / Cascade	Both	Good	Medium	Complexity; weight drift
Knowledge-based	Domain rules, catalog attributes	Good	High	Brittle rules; manual maintenance
Sequential / Session-based	Ordered interaction logs	Medium	Low	Short-horizon only; ignores long-term taste

How to decide: Start with your most restrictive constraint. If you have millions of interactions and a stable catalog, CF or a hybrid is the default. If your catalog is updated weekly, invest in content-based features first. If a false recommendation is costly (e.g., regulated products), a knowledge-based layer is mandatory.

The pipeline, not the model

A production recommendation system is a multi-stage process; the “model” is only one part:

Candidate Generation (Retrieval). Reduce millions of items to hundreds using cost-effective methods: Approximate Nearest Neighbor (ANN) search using embeddings, co-visitation, trending lists, or entity feeds.
Ranking. Evaluate candidates using a computationally expensive model that leverages rich cross-features.
Re-ranking/Filtering. Apply diversity, freshness, deduplication, business rules, and fairness constraints. This is where most “the model is fine but the results are bad” problems are solved.
Implementation and Tracking. Track impressions, not just clicks. Without impression records, you cannot correct for position bias.

This staging exists because it is computationally impossible to evaluate the entire catalog per query at scale, and different objectives (recall vs. precision) require different models.

Related: — Deep, project-driven ML books and video courses — including the MEAP early-access program.

Evaluation: where most papers and systems fail

Offline Evaluation

Rating Prediction Metrics (RMSE, MAE) measure how well a grade is predicted. They correlate weakly with ranking quality and are largely a legacy of explicit feedback datasets.
Ranking Metrics (Recall@k, NDCG@k, MAP, MRR, Hit Rate) are the correct tools for evaluating the top $k$ recommendations. Report these across multiple $k$ values; a model that wins at $k=10$ may lose at $k=100$.
Beyond Precision: Consider catalog coverage, intra-list diversity, novelty, and serendipity. A model that recommends the same 50 popular items to everyone may top the leaderboards but provide almost no actual value.

Bias Problems to Address

Position Bias: Items displayed higher are clicked more frequently, regardless of relevance. Correct this using propensity weighting or training with randomized data.
Exposure Bias: You only observe interactions for items the previous system chose to show. This creates a closed loop that reinforces existing biases.
Popularity Bias: Popular items accumulate more interactions, making them appear more relevant, which in turn makes them more popular.
Temporal Leakage: Random training/test splits on time-ordered data leak future information. Always use time-based splits for sequential and production-oriented evaluation.

Online Evaluation

Offline gains often do not translate to the real world. A rigorous evaluation stack consists of: offline filtering $\rightarrow$ counterfactual/off-policy estimation $\rightarrow$ online controlled experiments. Interleaving and A/B testing remain the ground truth. If you cannot test online, state this explicitly rather than claiming the system is “ready for implementation.”

Deployment caveats rarely found in papers

Latency budgets are hard constraints. A model that improves NDCG by 2% but adds 80ms of tail latency will likely fail an A/B test. Optimize latency during the retrieval phase.
Freshness vs. Stability. Indexes must be rebuilt as items and users change. Outdated embeddings silently degrade quality.
Exploration is necessary. Without conscious randomization (exploration), the system cannot learn about items it never displays.
Cold start is a product problem. Onboarding flows that collect explicit preferences often outperform any cold-start algorithm.
Privacy and Regulation. GDPR-style data minimization and the EU Digital Services Act’s transparency requirements affect how you record data and allow users to opt out of personalization.
Explainability. In sectors like credit, employment, or housing, recommendations are regulated decisions. Interpretability is a requirement, not a “nice-to-have.”

The research frontier

For those writing for MLRec or similar venues, these are the current open challenges:

Counterfactual and off-policy evaluation that is robust to unobserved confounding factors.
LLM-based recommendation: Using Large Language Models for zero-shot ranking, conversational recommendation, and feature generation. Key questions remain regarding cost, latency, hallucinations, and rigorous offline evaluation.
Graph Neural Networks (GNNs) on user-item-context graphs and how to scale them without exploding neighborhood sizes.
Multi-stakeholder objectives: Simultaneously optimizing for users, item providers, and the platform with formal guarantees.
Reproducibility. Standardized splits, fixed negative sampling protocols, and open-source code remain inconsistent across the field.

Key Takeaways

A recommender system estimates relevance for a (user, item, context) triple and returns the top $k$ results. The primary challenges are missing labels, feedback loops, and multi-stage delivery.
The main families (collaborative, content-based, hybrid, knowledge-based, and sequential) differ primarily in their data requirements and cold-start behavior.
Select a family based on binding constraints (data density, catalog churn, cost of errors), not on leaderboard rankings.
Offline metrics are necessary but insufficient; position, exposure, and popularity biases must be explicitly addressed.
Production systems are pipelines (Retrieval $\rightarrow$ Ranking $\rightarrow$ Re-ranking), and most gains come from the latter stages.
Online experiments are the ultimate truth; treat offline gains as a filter, not proof of success.

Frequently Asked Questions

What is a recommender system in simple terms?

It is a system that predicts which items a user is most likely to want and displays them in that order. Examples include streaming services suggesting movies or online stores suggesting products. In the background, it scores candidate items for a user and returns the highest-rated ones, filtered by rules like availability.

Where we would start: — One-off, low-cost ML and recommender-systems courses you own forever.

What is the difference between collaborative filtering and content-based filtering?

Collaborative filtering learns from user behavior patterns (who liked what) and doesn’t need item descriptions. Content-based filtering learns from item characteristics and maps them to a user’s preferences. CF can suggest surprising, diverse items but struggles with new ones; content-based filtering handles new items well but can become too narrow.

What are the main types of recommender systems?

The primary families are collaborative filtering (neighborhood and model-based), content-based filtering, hybrid approaches, knowledge-based/constraint-based systems (for data-sparse domains), and sequential or context-aware models. Most real-world systems combine several of these in a staged pipeline.

Why do recommender systems sometimes give bad recommendations?

Common causes include treating unobserved interactions as negative feedback, popularity bias, outdated embeddings, and feedback loops. Position bias (clicking what is at the top) also distorts training data if impressions aren’t tracked.

How are recommender systems evaluated?

Offline, ranking metrics like Recall@k, NDCG@k, and MAP are standard, alongside measures of coverage and diversity. Because offline results are often misleading, a serious evaluation includes counterfactual estimates and online A/B tests or interleaved studies.

Do recommender systems use machine learning?

Most modern systems do, but not all. Knowledge-based systems can operate on pure rules. When ML is used, it typically happens in phases: embedding models for retrieval, deep or gradient-boosted models for ranking, and learned policies for exploration.

What is “cold start” in recommender systems?

Cold start occurs when there is little to no interaction data—either for a new user, a new item, or a brand-new system. Solutions include using content features, onboarding preference surveys, and hybrid cascades. It is both a product design and a modeling challenge.

MLRec is a workshop on machine learning and data mining for recommender systems held in parallel to the SIAM International Conference on Data Mining. Researchers and practitioners are encouraged to submit contributions and join the program committee.

P.S. A few readers have asked which marketplace courses we actually reach for — it's Udemy; if you want the current details.

Frequently asked questions