← Back to all posts

S&R: Why Do We Keep Confusing Search with Recommendation?

Why search and recommendation are different problems — and why conflating them is a costly engineering mistake. Covers the three traps, the user-posture divide, Peter Norvig's 80% rule, and the library/restaurant mental models that clarify the boundary.

searchrecommendationinformation-retrievalcollaborative-filteringarchitectureseries

S&R stands for Search & Recommendation — the two fundamental modes of information access. This post defines the distinction that the rest of the series builds on, and explains why conflating them is not merely a terminology error but an engineering one with production consequences.

Search is what happens when someone types "history of the Byzantine Empire" into a box and hits enter. They know what they want. They told you — explicitly, in words, 500 milliseconds ago. Your job is fidelity to those words. If they typed "Byzantine" and you returned results about the Ottoman Empire because "people who search for Byzantium also search for Ottomans," you have broken the contract.

Recommendation is what happens when someone opens an app and waits. They didn't type anything. They may not know what they want. They may not even know there is something to want. Your job is to infer it from what they did yesterday, last week, and five minutes ago — and to be right often enough that they keep opening the app. If you show them what they already know about, you have broken a different contract.

Search and recommendation are often described as "two sides of the same coin." Both match users with items. Both rank results. Both drive discovery. The phrase appears in conference papers and engineering blog posts alike.

It is also wrong — or at least, incomplete enough to be dangerous.

Search and recommendation are different problems. They emerged from different research communities, solved different user needs, developed different mathematical frameworks, and measure success differently. Confusing them produces systems that are bad at both: search results that drift into irrelevance under the weight of personalization, and recommendation feeds that fail to respect explicit intent.

This series traces the history, the mathematics, the architectures, and the convergence — arguing that the best engineering organizations don't collapse search and recommendation into one. They build systems that respect the distinction even as they blur it.

Let's start with the definitions.

What Search Is — And What It Is Not

Search is query-driven retrieval. A user has an information need, formulates it as a query, and expects the system to return items relevant to that query. The contract is: I tell you what I want. You find it.

# Search: the user specifies intent explicitly
def search(query: str, index: InvertedIndex, k: int = 10) -> list[Document]:
    """Return the top-k documents matching the query."""
    query_tokens = tokenize(query)
    candidates = set()
    for token in query_tokens:
        candidates.update(index.postings[token])  # exact or fuzzy match

    scored = [(doc, score(query_tokens, doc)) for doc in candidates]
    scored.sort(key=lambda x: x[1], reverse=True)
    return [doc for doc, _ in scored[:k]]

# The key: query comes from the user, right now.
# If the query is wrong, the results are wrong — but that's the user's problem,
# not the system's. The system's job is fidelity to the query.
results = search("history of the Byzantine Empire", index, k=10)

The critical property: the user actively formulates their need. They lean forward. They have a goal. Search is a tool the user operates.

What Recommendation Is — And What It Is Not

Recommendation is preference-driven filtering. The system infers what a user might want from their history, behavior, and context, then surfaces items unprompted. The contract is: I know something about you. Let me suggest what you might like.

# Recommendation: the system infers intent from behavior
def recommend(user_id: str, item_sim: dict, ratings: dict, k: int = 10) -> list[Item]:
    """Return top-k items the user might like, based on what they liked before."""
    liked_items = [item for item, rating in ratings[user_id].items() if rating > 3.5]

    candidates = {}
    for liked in liked_items:
        for similar_item, sim_score in item_sim[liked].items():
            if similar_item not in ratings[user_id]:  # don't recommend what they've seen
                candidates[similar_item] = candidates.get(similar_item, 0) + sim_score

    ranked = sorted(candidates.items(), key=lambda x: x[1], reverse=True)
    return [item for item, _ in ranked[:k]]

# The key: the user did NOT ask for anything. The system guessed.
# If the guess is wrong, that's the system's failure.
suggestions = recommend("user_42", item_similarity_matrix, ratings_matrix, k=10)

The critical property: the system initiates. The user leans back. They are open to suggestion. Recommendation is an experience the user receives.

The Difference in One Table

Dimension Search Recommendation
User intent Active: user formulates a query Passive: system surfaces items unprompted
Input Short, explicit query text Implicit user profile (history, behavior, context)
Core operation Query–document matching User–item matching
Information need Known: "I want to find X" Unknown: "Show me what I might like"
Evaluation Precision, recall, NDCG, MRR RMSE, AUC, CTR, retention, discovery
Serendipity Undesirable (should return what was asked for) Desirable (should surface unexpected gems)
Personalization Optional; applied sparingly at re-ranking Core to the entire pipeline
Theoretical roots Information Retrieval (library science, linguistics) Collaborative Filtering (HCI, ML)
User posture Lean forward — goal-directed Lean back — open to suggestion

Manning, Raghavan, and Schütze's canonical IR textbook formalizes this distinction in its opening chapter: information retrieval is query-driven; information filtering is profile-driven [5].

Why People Confuse Them — The Three Traps

If the distinction is so clear, why do smart engineers keep conflating them? Three traps account for most of the damage.

Trap 1: They share the same surface shape. Both produce a ranked list of items. Type a query into Google, get a list. Open Netflix, get a list. The visual output is identical, so the mental model defaults to "they're the same thing with different inputs." This is like assuming a taxi and a personal chauffeur are the same because both are cars. The interface is the same; the contract is not.

Trap 2: They use the same mathematical machinery. Both problems can be formulated as learning a matching function f(x, y) → relevance_score. Search learns f(query, document). Recommendation learns f(user, item). The architectures — two-tower encoders, dot-product scoring, ANN retrieval — are often identical:

# Both problems use the same architecture shape — but the semantics differ
class TwoTowerModel(nn.Module):
    """A shared architecture. But what the towers encode is completely different."""
    def __init__(self, input_dim: int, hidden_dim: int):
        super().__init__()
        self.tower_a = nn.Sequential(
            nn.Linear(input_dim, hidden_dim),
            nn.ReLU(),
            nn.Linear(hidden_dim, hidden_dim // 2)
        )
        self.tower_b = nn.Sequential(
            nn.Linear(input_dim, hidden_dim),
            nn.ReLU(),
            nn.Linear(hidden_dim, hidden_dim // 2)
        )

    def forward(self, x_a, x_b):
        return torch.cosine_similarity(self.tower_a(x_a), self.tower_b(x_b))

# FOR SEARCH: tower_a encodes QUERY text, tower_b encodes DOCUMENT text
# The query is an explicit string the user typed 500ms ago.

# FOR RECOMMENDATION: tower_a encodes USER profile, tower_b encodes ITEM features
# The user profile is a latent representation of years of behavior, updated daily.

# Same architecture. Completely different semantics.
# When the code looks the same, the problems feel the same. They aren't.

This is the second trap. The math is identical. The semantics are not.

Trap 3: LLMs make the boundary genuinely fuzzy. Ask an LLM "What should I watch tonight? I loved Dark and Severance" and it will produce recommendations. Ask the same LLM "Find me mind-bending sci-fi shows like Dark" and it will produce search results. The same model, the same prompt interface, the same output format. The temptation to conclude "search and recommendation are the same now" is powerful — and wrong. The LLM is a substrate, not a solution. It can perform either task, but optimizing for both simultaneously without awareness of which mode is active produces the worst of both worlds.

Peter Norvig's Insight: The Error Bar Is Different

Peter Norvig, Director of Research at Google, captured the consequence of the search–recommendation distinction with characteristic precision. When asked about the shift from retrieval to proactive assistance, he noted:

"With information retrieval, anything over 80% recall and precision is pretty good — not every suggestion has to be perfect, since the user can ignore the bad suggestions. With assistance, there is a much higher barrier."

The bar is different because the contract is different. In search, the user is the arbiter — they scan results, skip what's irrelevant, and reformulate if necessary. In recommendation, the system is the arbiter — it decides what the user sees. If it's wrong, the user doesn't skip a result; they lose trust in the system itself.

def measure_search_satisfaction(precision_at_10: float) -> str:
    """Norvig's rule: 80% is good enough for search."""
    if precision_at_10 >= 0.80:
        return "acceptable — user can scroll past the 20% that's wrong"
    return "needs improvement — too many irrelevant results visible"

def measure_recommendation_satisfaction(ndcg_at_10: float) -> str:
    """No equivalent 80% rule for recommendations."""
    if ndcg_at_10 >= 0.95:
        return "acceptable — nearly everything shown is relevant"
    # A recommendation that misses 20% is showing wrong items to users
    # who can't scroll past — they just see a bad experience.
    return "needs improvement — every wrong item erodes trust cumulatively"

Getting search wrong loses a query. Getting recommendation wrong loses a user.

Herlocker et al. established the standard evaluation framework for collaborative filtering, noting that recommendation metrics must capture user satisfaction in ways that precision and recall alone cannot [6].

The Library Analogy

Three scenarios make the distinction concrete:

  1. You walk into a library and ask the librarian, "Where are the books on the history of the Byzantine Empire?" The librarian walks you to a specific shelf. That's search.

  2. You walk into the same library and the librarian says, "I notice you've been reading a lot about medieval trade routes. We just got a new book on the Silk Road you might enjoy." That's recommendation.

  3. You walk into the library, glance around, and say, "I'm not sure what I want. Something historical but not too heavy, maybe with a good story?" The librarian pauses, then suggests three books and asks which one sounds right. That's the boundary — where search and recommendation blur into conversation.

These three scenarios feel different. They engage different cognitive postures, demand different system designs, and tolerate different kinds of errors:

  • A search error is visible and attributable: "This librarian doesn't know where the books are."
  • A recommendation error is invisible and cumulative: "This librarian doesn't understand my taste."
  • A boundary error is recoverable through conversation: "Not that one — what else do you have?"

The Restaurant Analogy

When you sit down at a restaurant and scan the menu, you're doing search. You have an intent — "I feel like pasta" — and you're scanning a structured catalog for matches. Your satisfaction depends on whether the menu accurately represents what the kitchen can deliver. A mistake here: "I ordered the carbonara and got the bolognese."

When the chef sends out a tasting menu — "trust me, you'll love this" — you're receiving a recommendation. The chef has built a model of what you might enjoy and is making predictions. Your satisfaction depends on whether the chef's model of you is accurate, and whether they can surprise you in a good way. A mistake here: "The chef brought me a dish centered on mushrooms, which I hate."

The first failure is a retrieval error. The second is a modeling error. Different failures, different fixes, different systems.

The Surveys Agree: Different Fields, Different Literatures

The best survey papers in each field make the distinction structurally. The Recommender Systems Handbook (Ricci, Rokach, and Shapira, 3rd edition, 2022) — the canonical 1,060-page reference — organizes recommendation into its own taxonomy: collaborative filtering, content-based, context-aware, session-based, and sequential methods [1]. The parallel information retrieval surveys — Guo et al.'s A Deep Look into Neural Ranking Models for Information Retrieval (2020) and Hambarde and Proença's Information Retrieval: Recent Advances and Beyond (2023) — organize around query-document matching, retrieval stages, and ranking objectives that have no equivalent in the recommendation literature [2][3].

These surveys do not reference each other much. That is not an accident. It is evidence that the fields have different problem statements, different evaluation cultures, and different assumptions about what "good" means.

What's Ahead

The remaining posts in this series cover: the fifty-year history of search technology, the thirty-year history of recommendation, the Netflix case study, how Spotify, DoorDash, Airbnb, and Pinterest draw the boundary, what LLMs change — and what they don't, and a practical architecture for building systems that handle both. Each stands alone; read in any order.

Open Questions

  1. If the distinction is so clear, why do most ML curricula still teach search and recommendation as variants of the same ranking problem? What would a curriculum look like that treated them as separate disciplines with shared infrastructure?

  2. Norvig's 80% rule suggests search tolerates error better than recommendation. But as search engines become answer engines (via RAG), the error bar rises. At what point does search become assistance — and inherit recommendation's trust problem?

  3. The three traps explain why engineers do conflate search and recommendation. But what incentives — organizational, metric, career — make them want to? Is unification sometimes a political choice rather than a technical one?

  4. Belkin and Croft asked in 1992 whether IR and information filtering were two sides of the same coin. Thirty-four years later, with LLMs in the picture, is the answer different than it was then? Or did they get it right the first time? Jannach et al.'s introductory textbook on recommender systems reinforces the distinction structurally: it treats the search/recommendation boundary as a design choice, not a convergence point — search is about satisfying a stated need, while recommendation is about anticipating an unstated one [8].

References

  1. Francesco Ricci, Lior Rokach, and Bracha Shapira (editors). Recommender Systems Handbook, 3rd Edition. Springer, 2022.

  2. Jiafeng Guo, Yixing Fan, Liang Pang, Liu Yang, Qingyao Ai, Hamed Zamani, W. Bruce Croft, et al. A Deep Look into Neural Ranking Models for Information Retrieval. Information Processing & Management, 57(6), 2020.

  3. Kailash Hambarde and Hugo Proença. Information Retrieval: Recent Advances and Beyond. arXiv:2301.08801, 2023.

  4. Nicholas J. Belkin and W. Bruce Croft. Information Filtering and Information Retrieval: Two Sides of the Same Coin?. Communications of the ACM, 35(12): 29–38, 1992.

  5. Christopher D. Manning, Prabhakar Raghavan, and Hinrich Schütze. Introduction to Information Retrieval. Cambridge University Press, 2008. The canonical IR textbook covering Boolean retrieval, vector space models, probabilistic retrieval, and evaluation.

  6. Jonathan L. Herlocker, Joseph A. Konstan, Loren G. Terveen, and John T. Riedl. Evaluating Collaborative Filtering Recommender Systems. ACM Transactions on Information Systems, 22(1): 5–53, 2004. The definitive paper on recommendation evaluation metrics.

  7. Carlos A. Gomez-Uribe and Neil Hunt. The Netflix Recommender System: Algorithms, Business Value, and Innovation. ACM Transactions on Management Information Systems, 6(4): 1–19, 2015. Netflix's own description of their recommendation architecture and business impact.

  8. Dietmar Jannach, Markus Zanker, Alexander Felfernig, and Gerhard Friedrich. Recommender Systems: An Introduction. Cambridge University Press, 2010. A comprehensive introductory textbook.

  9. W. Bruce Croft, Donald Metzler, and Trevor Strohman. Search Engines: Information Retrieval in Practice. Pearson, 2010. A practical textbook covering search engine architecture, indexing, and ranking.

  10. Tefko Saracevic. Relevance: A Review of the Literature and a Framework for Thinking on the Notion in Information Science, Part II. Journal of the American Society for Information Science and Technology, 58(13): 1915–1933, 2007. A comprehensive review of relevance — the central concept in information retrieval.