Related searches look like a small feature. On a platform with two million stored queries, they’re a ranking problem — and a good place to show what “AI where it moves a metric” means in practice.
Every search page on a content platform has a block of related queries. Most sites fill it with whatever shares a word with the current one. We wanted to know what actually earns a click.
Three candidates.
Text v2 — full-text match with tiered weighting. Fast, predictable, and blind to meaning: “red car” and “crimson automobile” never meet.
Vector kNN — embeddings over the query corpus, nearest neighbours by cosine distance. Finds synonyms and intent the text model misses, but surfaces plausible-looking queries nobody ever types.
Hybrid — text tier as the first filter, vector rank for ordering within the tier, then a log(search_count) boost so popular queries rise and long-tail noise sinks. Misspellings collapse into aliases before any of it runs.
How we compared them. Not on a benchmark — on an internal admin panel where the same query runs through all three rankers side by side, and then on live users with the ranker as an A/B dimension.
What happened. Vector-only looked impressive in the admin and underperformed in production: semantically close, behaviourally irrelevant. Text-only was the safe baseline. The hybrid beat both on click-through from the related block, with the popularity term doing more work than we expected — users click what other users search.
The part that matters for your platform. None of this required replacing the search engine. The ranker sits beside the existing Manticore index, reads the same query log, and writes to one block on one page. If it had lost the A/B test, removing it would have taken an afternoon.
That’s what a module is supposed to be.