Recommender systems are taste machines

A recommender does more than sort a list. It decides which items deserve to enter the conversation, which signals count as preference, and what the product will learn from the next interaction.

That makes it a taste machine. Not because it discovers an objective best item, but because it turns a set of product judgments into repeated exposure.

Ranking starts after a choice

The final score gets most of the attention. Candidate generation often determines the outcome earlier.

The eligible set might combine:

• search results
• recently viewed items
• items from followed creators
• similar products
• editorial picks
• sponsored placements
• business-priority content

If a useful item never enters that set, a better ranker cannot recover it. Feed quality is therefore partly a retrieval problem and partly a policy problem.

The product also has to define what taste means. A store may care about style and price. A music app may care about mood, history, and a willingness to hear something unfamiliar. A news product has to balance relevance against repeating the same story. An internal dashboard may be ranking attention rather than objects.

Feedback is not neutral

The system learns from its own decisions.

An item at the top gets more chances to earn a click. Popular items collect more impressions and therefore more evidence. A long-tail item that is never shown cannot demonstrate that it would have been useful.

That feedback loop belongs in the product model, not in a footnote about data quality:

impression -> click -> dwell -> save -> return visit -> purchase

Those events do not all mean the same thing. An impression is exposure. A click may be curiosity. A save may be a stronger preference signal. The team should be able to tell which signals came from being seen and which came from being wanted.

Keep a reason nearby

Recommendations can look more certain than they are. In practice, the model is combining weak signals such as recency, repetition, ownership, locale, device, follows, dismissals, price, availability, and editorial constraints.

I want the system to leave an explanation for the engineer who has to investigate it:

{
  "item_id": "item_918",
  "signals": {
    "collaborative": 0.71,
    "freshness": 0.22,
    "price_fit": 0.43,
    "editorial_boost": 0.10
  },
  "reason": "similar users saved this and it is still in stock"
}

This need not become a user-facing paragraph. A compact record is enough to answer a more useful question than “What was the score?”: why did the product think this was worth putting first?

Variety is a policy

A system can become boring while its metrics improve. Repetition may be exactly right for a short playlist, but it can make a storefront feel narrow or turn a news feed into a topic tunnel.

Diversity terms in a ranking function are therefore product choices. The team should name the dimension it is diversifying across, whether that means creator, topic, price, style, or novelty, and decide how much relevance it is willing to trade for variety.

Evaluate the session, not only the row

Offline metrics are useful. They are not the whole experience.

Relevant checks include:

• recall of relevant items
• top-K precision
• diversity across the page or session
• novelty when the product needs it
• stability across repeated visits
• business constraints that override the model

The missing questions are experiential. Does the feed feel stuck? Is it too random? Does every visit repeat the same safe choice? A ranker can improve a number while making the product less useful.

Recommenders sit between model, policy, UX, and memory. The score is only one layer of the taste the product is expressing. Treating that taste as a decision rather than as objective truth makes the feedback loop easier to inspect.