Query understanding: from typed text to a search request
Turning what people type into something an index can answer: normalisation, tokenising, spelling, synonyms, intent and what to do when nothing matches.
On the roadmap:Staff Engineer · step 1: Search and relevance
Lesson 3 of 10 · 10 min read · quiz · exercise
Why the query needs work
People type fast and loosely: "iphon 15 pro case blk", "restaurants near me", "python". An index can only match exact terms, so something has to translate the typed text into a request the index understands. That layer is query understanding, and it often matters more for result quality than the ranking formula.
Figure SDA-SAG-03-1 · A query understanding pipeline · © forcsguy.com
The steps
- Normalise and tokenise. Whatever you do at index time you must do at query time, or terms will never match. Be careful with tokens that carry meaning: c++, .net, 3.5mm.
- Spell correction. Compare against a dictionary and, better, against what other people searched and clicked. Suggest "did you mean" when unsure; auto-correct only when confident.
- Synonyms and abbreviations. "tv" and "television", "nyc" and "new york". Store them as curated lists, applied at query time so you can change them without reindexing.
- Intent and entities. "red nike running shoes size 10" contains a colour, brand, category and size. Mapping them to filters is more accurate than hoping words match.
- Autocomplete and recent searches feed this layer with clean, popular queries; see the autocomplete lesson.
Precision, recall and the empty page
Every step moves a trade-off. Expanding synonyms finds more (higher recall) but can add junk (lower precision). Strict matching is precise but can return nothing. A robust pattern is tiered relaxation:
Figure SDA-SAG-03-2 · Relax the query only when needed · © forcsguy.com
Log and learn
Log each query with what was shown and clicked (respecting privacy rules). Queries with no results, quick reformulations and low click rates show where the pipeline fails. They are also the data you need for better spelling suggestions, synonyms and evaluation, which the next lesson covers.
Real-world reading
Related reading
- Introduction to Information Retrieval: evaluationManning, Raghavan and Schutze · Stanford UniversityBooks
- Elasticsearch GuideElasticDocumentation
- Moving Core Business Search to Elasticsearch at YelpYelp engineers · YelpCase Studies
- Cross-Lingual End-to-End Product Search with Deep Learning at ZalandoZalando engineers · ZalandoCase Studies
Show 1 moreShow fewer
Check your understanding
Question 1 of 3
0 correct so far
Why normalise text (lowercase, accents, unicode) before searching?
Go deeper
- Introduction to Information Retrieval: tolerant retrieval by Manning, Raghavan and Schutze: spelling correction and wildcard queries
- Query Understanding by Daniel Tunkelang: a book and blog series on the whole topic
Practise it: Common queries repeat
Everything below is already set up for this lesson: change the design, run the traffic, and see whether you meet the goal.
- 1The task
- 2Build and test
A few hundred queries account for most search traffic.
Goal: Database below 50% busy at 3,500 queries per second.
Which part could remember the answers to common queries?
Try it yourself
Design the query pipeline for a product search box. List the steps, say what each does, and name one failure each step can cause.
Click what a strong design here would need:
More in Real systems
© 2026 forcsguy.com. Original lesson text and diagrams. Books and sites linked above belong to their authors.