How recommendation systems work

01 THE PROBLEM IS TOO MANY CHOICES

A recommendation system exists because a catalogue is larger than a person’s attention. A streaming service may contain more films than one viewer can sample. A store may have millions of products. A social feed can generate new candidates faster than anyone can read them. The system’s job is to reduce that search space into an ordered set of possibilities.

“Relevant” is not one thing. It can mean likely to click, likely to finish, likely to buy, useful for learning, novel enough to surprise, or safe to show in a particular context. Every product chooses an objective, whether it states that objective publicly or hides it inside an optimization metric.

The first consequence is that recommendations are not neutral windows onto a catalogue. They are a selection mechanism. What is retrieved, ranked, filtered, and omitted determines which choices become visible. Understanding the system means following that chain rather than imagining one magical algorithm that knows what a person likes.

02 COLLECT SIGNALS WITHOUT A TASTE LABEL

The system observes events: a play, pause, skip, search, purchase, hover, follow, repeat visit, or explicit rating. It may also use item metadata such as genre, creator, language, price, length, or topic. Context—time, device, location, and session position—can change the meaning of the same event. A late-night skip is not necessarily a permanent dislike.

Most signals are indirect. A click can mean genuine interest, accidental contact, curiosity, or a compelling thumbnail. A long watch can mean satisfaction or that the video was left playing in another tab. Designers assign different weights and often combine many weak signals instead of trusting a single behavioral label.

Privacy and governance begin at collection. The model can only personalize from data it is permitted to use, and the user may not know which actions become training evidence. A responsible system should minimize data, explain important controls, and keep sensitive attributes from becoming invisible proxies for exclusion.

03 RETRIEVAL FINDS THE CANDIDATES

A large service cannot compare every item with every user at request time. Recommendation architectures therefore split the job into stages. Candidate generation quickly retrieves a few hundred or thousand plausible items from a much larger corpus. It can use recent behavior, similar users, item embeddings, subscriptions, trending pools, or a mixture of sources.

Content-based retrieval compares item attributes with a user’s observed interests. If someone reads several articles about battery chemistry, the system can find other items with related embeddings or tags. Collaborative retrieval instead uses patterns across people: users whose histories overlap may be useful signals for one another. Hybrid systems combine both to handle sparse data and new items.

Approximate nearest-neighbor indexes make vector retrieval fast enough for interactive systems. They trade a small amount of exactness for speed and scale. The candidate stage is deliberately broad; it is better to pass along several plausible options than to discard a useful item before the more expensive ranking model sees it.

04 RANKING PREDICTS A RESPONSE

The ranking model scores candidates for a particular user and context. It may estimate the probability of a click, the expected watch time, the chance of a repeat purchase, or a multi-objective value that combines several outcomes. Features can include the user’s history, item properties, freshness, social context, and interactions between them.

Collaborative filtering often represents users and items as vectors in a latent space. A user vector captures patterns in behavior without needing a human-readable list of preferences. An item vector captures the people and contexts associated with it. Their similarity—or a learned interaction between them—becomes one input to the ranking score.

Neural ranking models can learn nonlinear relationships and long sequences of behavior, but complexity does not remove the need for evaluation. Offline metrics such as precision, recall, ranking loss, or normalized discounted cumulative gain are useful diagnostics. They are not the product outcome. A model can improve a benchmark while making a feed repetitive, manipulative, or less valuable over time.

05 FILTERS, DIVERSITY, AND POLICY

The highest-scoring list is rarely the final list. A service may remove unsafe, illegal, duplicate, unavailable, or already-seen items. It may enforce age restrictions, rights windows, regional rules, or a creator’s frequency limit. A diversity layer can prevent ten nearly identical recommendations from crowding out every alternative.

These decisions are part of the system’s behavior, not an afterthought. A ranking model may predict that sensational items generate attention, while a policy layer chooses to limit them. A music service may balance familiarity with discovery. A news product may include source diversity even when a narrow topic cluster would maximize immediate engagement.

Users experience the combined result as “the algorithm.” In reality it is a stack of retrieval models, rankers, business rules, safety systems, and interface choices. Auditing the stack requires asking which layer made an item visible, which layer excluded another, and which objective each layer was optimizing.

06 THE FEEDBACK LOOP CHANGES THE DATA

After a recommendation is shown, the user’s response becomes new evidence. A click can reinforce the features that produced it. A skip can lower their future score. Over time, the system learns from a population whose choices have already been shaped by previous recommendations. This is a feedback loop, not a passive measurement process.

The loop creates a tension between exploitation and exploration. Exploitation shows items the model already expects to work. Exploration deliberately tests uncertain items so the system can learn about new interests and new content. Without exploration, a model can become overconfident in a narrow picture of the user and never discover what lies outside it.

Evaluation must therefore distinguish correlation from causation. A recommendation may receive a click because it was placed first, not because it was intrinsically better. Randomized experiments, holdouts, counterfactual methods, and long-term measures help estimate the incremental effect of the system rather than simply counting what happened after exposure.

07 COLD START, BIAS, AND SURPRISE

New users and new items have little interaction history. This cold-start problem forces the system to use metadata, popularity, onboarding questions, or carefully chosen exploration. A new creator can remain invisible if the model only trusts accumulated engagement, while a new user can receive generic bestsellers until the system learns enough to personalize.

Popularity bias compounds the problem. Items that are already visible collect more interactions, which make them easier to recommend, which generates still more interactions. Feedback loops can amplify existing inequalities, favor a small number of creators, and make the catalogue appear less diverse than it is. Correcting that pattern requires explicit exposure goals, not merely a more accurate click predictor.

Surprise is a design variable too. People use recommendation systems for continuity, but they also use them to encounter something they would not have searched for. The strongest systems make relevance and discovery coexist: they explain why an item appears, provide controls to steer the feed, and leave room for the user to change their mind. A recommendation is a hypothesis, not a verdict.