Site search that
finds the thing.

When we are asked to improve search, the first thing we look at is the catalogue, not the ranking. In most cases the product data is inconsistent in ways that make good retrieval impossible: attributes populated for some suppliers and not others, colour recorded three different ways, descriptions written by whoever loaded the product, categories that made sense five years ago.

A semantic search layer over that catalogue improves matters, sometimes substantially, because embeddings tolerate vocabulary mismatch in a way keyword matching does not. But it cannot invent the fact that a product is waterproof if nothing in its record says so, and no amount of model sophistication fixes an attribute that does not exist.

So the honest sequence is: fix and enrich the catalogue — which language models are genuinely good at, extracting structured attributes from supplier descriptions and images at a scale nobody would fund manually — then put semantic retrieval and reranking over the result. Teams that do it in that order tend to get large improvements. Teams that skip the first step tend to get a modest one and conclude the technology is oversold.

Search changes are measured by experiment, not by inspection. Conversion from search, null-result rate, click position, and search abandonment — split-tested, because search relevance is precisely the kind of thing where a change that looks obviously better in a demo performs worse in production.

The null-result rate deserves particular attention because it is the cheapest thing to fix and the most directly commercial. Every query returning nothing is a customer who told you exactly what they wanted, and the log of those queries is the most valuable catalogue-gap dataset you own.

We also watch latency as a first-class metric. A reranker that improves relevance and adds a hundred milliseconds may lose more revenue than it gains, and that trade-off has to be measured rather than assumed in either direction.