When a user enters a query on Google, the search results page shows a list of “related searches” at the bottom: queries that other users have issued in the same session, or queries that are semantically close to the original. These suggestions help users refine their intent, discover alternative phrasings, and navigate to adjacent topics, and they drive a significant fraction of query reformulations. Generating them at scale requires a deep embedding model that maps queries into a semantic space where nearby queries are related, plus a retrieval mechanism that can surface the best candidates from billions of historical queries in milliseconds. The model must handle the long tail of rare queries that have little or no co-occurrence history, distinguish genuinely related queries from merely popular ones, and avoid suggesting queries that lead to harmful or policy-violating content.
How would you design this model? Cover the candidate embedding architectures (dual-encoder trained on query co-occurrence vs contrastive learning on query-query pairs vs LLM-based query expansion), how you build the retrieval index over billions of queries, how you handle the long tail of rare and unseen queries, how you filter harmful or policy-violating suggestions, and how you evaluate related-search quality (click-through rate, reformulation success rate, relevance judgments).
The Problem: billions of past queries could fill the three empty slots under the results, most of them were typed only once, some of them should never be shown, and the choice must be made in a few milliseconds.
Answer
The design is a contrastive query encoder: a BERT-base transformer (110M, 256-d output projection) trained with InfoNCE on query-query pairs harvested from session reformulations and same-click queries, using in-batch negatives plus mined hard negatives and a logQ popularity correction so that cosine similarity means “related” rather than “popular”. Every historical query is embedded once offline into an approximate nearest-neighbor index, and at serve time the live query is encoded and its neighbors are pulled out and filtered. LLM query expansion is deliberately not the online model. It runs offline to synthesize and relabel training pairs and to generate grounded candidates for tail queries that have no usable neighbors. The two pivotal decisions are to train on semantic pairs with explicit popularity debiasing instead of factorizing raw co-occurrence counts, and to keep the LLM offline and grounded so that every displayed suggestion is a real, auditable query.
(1) Dual-Encoder on Co-occurrence: two towers whose training target is the session co-occurrence matrix; a sampled softmax predicts the next or co-session query, which effectively factorizes the count matrix into embeddings.
(2) Contrastive Query-Query Encoder: one shared transformer trained with InfoNCE on curated positive pairs (reformulations, same-click queries, paraphrases), in-batch and mined hard negatives, a temperature, and a logQ correction; retrieval is cosine k-NN over the index.
(3) LLM-Based Query Expansion: a generative model writes related queries directly from the query text, or synthesizes and labels pairs for distillation; generated strings are snapped to real historical queries before use.
Figure 1: The contrastive query encoder is trained once on pairs, embeds the whole historical corpus offline, and serves each live query with one cheap forward pass plus a nearest-neighbor lookup.
Clarify Before Designing:
(1) Candidate Pool: must every suggestion be a real historical query (grounded, auditable), or may the system show generated strings nobody has typed?
(2) Latency and Compute Budget: how many milliseconds and FLOPs per query for encode plus retrieve, and may head queries be precomputed and cached?
(3) Training Signal: which logs exist at what volume: session reformulations, same-click query pairs, human relevance judgments; how many languages?
(4) Definition of Related: refinements, broadenings, lateral topics, or all three, and how much diversity is wanted versus precision?
(5) Tail Share: what fraction of distinct queries and of traffic is seen fewer than a handful of times, and must those queries receive suggestions or is an empty slot acceptable?
(6) Safety Bar: which policy categories apply (health misinformation, harassment, adult content, queries about private individuals), and is any false negative tolerable?
Leave a Reply