Which Search Are You Building

In one line: the four kinds of search have the same architecture and different definitions of a correct answer, so committing to one is the first real decision.

Four kinds

Web search has an adversary. A meaningful fraction of the corpus was written to rank rather than to inform, so a large part of the system is spam detection and authority estimation. Nobody is optimising against your internal wiki.

E-commerce search has a conversion objective, which is both easier and more dangerous. Easier because purchases are unambiguous labels. Dangerous because optimising purely on conversion promotes cheap, popular, low-margin items and buries anything new — the same popularity spiral as a recommender, with money attached. It is also where structured attributes matter most: red running shoes size 10 under £80 is four constraints and one topic.

Enterprise search has almost no interaction signal — a few thousand employees generate a click stream too sparse to train on. It has permissions, which must be enforced at retrieval and not by filtering afterwards, because a filtered-out result still leaked its existence through the result count. And its documents are a mess of formats.

In-app search — finding a contact, a setting, a past order — is mostly not a machine learning problem. Prefix matching, fuzzy matching, and recency get you most of the way. Saying this is a strong signal.

The two questions that decide the most

What counts as relevant here?

You cannot design ranking until this is answered, and the answers are genuinely different.

A web result is relevant if it answers the question authoritatively. A product is relevant if the shopper would buy it — which includes price and availability, so an out-of-stock perfect match is irrelevant. An enterprise document is relevant if it answers this employee's question and they are allowed to see it. An in-app result is relevant if it is the thing they were looking for, which they already know exists.

What does a wrong result cost?

Different by an order of magnitude, and it sets how conservative the ranking should be.

A bad web result costs a click and a back button. A bad product result costs a sale and possibly a return. A bad enterprise result can cost a permission violation. A bad in-app result is baffling, because the user knows the thing exists and your system just told them it does not.

That last one is worth dwelling on: in-app search has the least tolerance for a miss, because the user has certain knowledge that you are wrong.

Signal availability

The practical constraint that decides whether learning to rank is even available.

Web and e-commerce have millions of queries a day, so a click model has data. Enterprise has thousands, which is not enough to train a ranker per query segment — so it leans on BM25, structured metadata, and recency, with maybe a small reranker trained on judgements rather than clicks.

Scale, and what it actually changes

Three numbers, and only one of them usually matters.

Corpus size decides index architecture. Millions of documents fit on one machine; billions need sharding, and sharding a search index means scattering the query to every shard and gathering, so tail latency is set by your slowest shard rather than your average one.

Query rate decides the serving budget and caching strategy.

Update rate is the one people forget. A corpus where documents change constantly — prices, stock, availability — has a completely different indexing design from a static one. E-commerce is the hard case: an index that is an hour stale is showing items that are out of stock, and an out-of-stock result is irrelevant by this product's own definition.

Committing

An e-commerce search over about five million products, roughly two thousand queries per second at peak, with prices and stock changing continuously. Relevance means the shopper would buy it, so availability is part of relevance rather than a filter applied afterwards. Query understanding has to extract structured attributes, because a large share of queries carry constraints. And I have enough click volume to train a ranker, plus a judgement budget for a stable offline benchmark.

Every clause there is used later. Continuous stock changes force a near-line index update path. Attribute extraction forces a query understanding stage that does more than spelling. Enough click volume makes learning to rank available. And "availability is part of relevance" is the sentence that stops out-of-stock items ranking first.

Next: query understanding, and when rewriting makes things worse.