Recommender systems are taste machines

Recommender systems are taste machines.

That sounds a little grand until you work through what they actually do. They take a noisy world, choose a candidate set, score it, and then teach the product what to pay attention to next. The product is not just showing items. It is rehearsing a theory of taste.

I like thinking about recommendations that way because it keeps the hard part visible. The model is not only deciding what matches. It is deciding what the product will remember about the user, the catalog, and the feedback loop between them.

taste begins before the model

The first mistake is treating recommendations as a single scoring function.

Before scoring, something decides what is even eligible:

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

If the right thing never enters the set, no ranking layer can rescue it. That is why feed quality often starts with candidate generation, not with the final model.

For a store, taste might mean style and price fit. For a music app, it might mean mood and history. For a news product, it might mean relevance without replaying the same story forever. For an internal tool, it might mean what deserves the operator’s attention first. The same machinery behaves differently once the product decides what taste means.

feedback is the part that bites

Recommendations are dangerous because they learn from themselves.

If the top item gets more clicks because it was top, the model receives a biased label. If popular items are shown more often, they collect more evidence and become even more popular. If the system never shows the long tail, it never learns whether the long tail was actually useful.

That is not a bug in a corner. That is the product.

I want recommender systems to make the feedback path obvious:

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

The team should know which signals came from exposure and which signals came from actual preference. Otherwise the system ends up optimising for visibility masquerading as taste.

the model should not be the only source of truth

When recommendations work well, they feel obvious in retrospect. That creates a trap. People start thinking the model is reading intent directly. It is not. It is combining weak signals.

Useful signals are often boring:

• recency
• repetition
• ownership
• locale
• device
• follow graph
• past dismissals
• price band
• item availability
• editorial or policy constraints

The important part is not that one of these wins. It is that the product can explain why the item rose.

I like outputs that leave evidence:

{
  "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"
}

That record is not for the end user. It is for the engineer trying to answer, “Why did the product think this was a good idea?”

diversity is a product choice

Taste machines get boring fast if they keep serving one flavor.

The system needs to know when repetition is good and when it is just noise. A music app may want a few similar songs in a row. A storefront may want some variety so the page does not feel like one narrow bet. A news app may need to avoid turning a user’s feed into a single topic tunnel. An internal dashboard may need to surface both urgent and merely frequent issues.

The product is deciding how much sameness is enough.

That is why diversity terms in the score are not decoration. They are a statement about product behavior. If the system boosts diversity, it should know what dimension it is diversifying across and what cost it is willing to pay.

evaluation has to match the experience

Offline metrics matter, but the useful question is whether the list feels right when a real person uses it.

I care about:

• 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

And I care just as much about the things the metric does not say: does the page feel stuck, too clever, too repetitive, or oddly random?

That is the uncomfortable truth with recommender systems. They are part model, part policy, part UX, part memory. The score is only one layer. The product’s taste is the rest of it.

I trust recommender systems most when they admit they are making taste visible, not objective truth. The system is not discovering the best thing in the universe. It is deciding what to put first.