Under the Hood: Bridging the Vocabulary Mismatch
Users express search intent using incomplete, misspelled, or ambiguous queries (e.g. "cheap nike shoes red size 10"). A naive literal keyword search against an inverted index frequently returns zero results. The Query Understanding Pipeline transforms raw user queries into rich structured search intents before querying the index.
The Multi-Stage Query Understanding Flow
Under the Hood: Machine Learning at the Query Boundary
- Named Entity Recognition (NER): Lightweight transformer models (DistilBERT) or fast linear CRF models identify brand names, product models, sizes, and colors in sub-10 milliseconds.
- Synonym Expansion: Expands query terms using offline word embedding graphs (e.g. mapping "hoodie" to "sweatshirt"). Expansion weights are discounted (weight = 0.5) so exact matches rank higher than synonym matches.
- Query Relaxation: If a strict boolean query yields zero results, the pipeline automatically relaxes constraints (e.g. dropping non-essential adjective tokens) while warning the user: "No exact match found; showing results for Nike shoes".
Worked example: one query through the pipeline
Raw input: red nkie runnign shoes size 10
| Stage | Output | Typical budget |
|---|---|---|
| Normalise | lowercase, trim, Unicode fold | under 1 ms |
| Spell correct | red nike running shoes size 10 | 1 to 3 ms |
| Segment and tag | colour=red, brand=nike, category=running shoes, size=10 | 2 to 10 ms |
| Classify intent | product purchase, category footwear, confidence 0.93 | 2 to 5 ms |
| Rewrite | filter brand=nike and category=footwear, boost colour=red and size=10, text match running shoes with synonym trainers at weight 0.5 | under 1 ms |
Notice the split between hard filters (high-confidence brand and category) and soft boosts (colour, size). If the shop has Nike running shoes in size 10 but none in red, the user still sees results rather than an empty page.
Trade-offs
| Choice | Upside | Downside |
|---|---|---|
| Dictionary and rules | Fast, explainable, easy to hot-fix | Poor coverage of the long tail |
| ML taggers and classifiers | Generalise to unseen phrasing | Need labelled data; silent errors |
| LLM rewriting | Handles complex natural language | Latency and cost; must be cached or used only on tail queries |
Failure modes: over-correction ("iphone" corrected to "phone"), brand collisions ("apple" the fruit), and feedback loops where a bad rewrite reduces clicks, which then looks like low demand. Always log the original and rewritten query so relevance engineers can debug.
How real systems do it
Large e-commerce engines typically keep a curated dictionary of brands, categories and attributes built from the catalogue itself, run fast taggers against it, and fall back to learned models for ambiguous tokens. Results for the most frequent few hundred thousand queries are precomputed and cached, so heavy models only run on the long tail. Every rewrite is logged next to the original query for offline analysis.