Why the words are not enough

The opener gave query understanding one section; it deserves its own, because it is where modern search stopped being a matching game. If an engine only looked up the literal words you typed, it would miss the page that says automobile when you searched car, return nothing for a typo, and rank a keyword-stuffed page above the one that actually answers you. Query understanding is the set of steps that close the gap between the string you typed and the thing you meant.

It happens in the moment you wait, before the ranked lookup against the inverted index. Think of it as several passes over the query, each one moving it closer to intent - from raw text, to clean tokens, to a corrected and expanded query, to an interpreted meaning.

Normalizing the text

The first pass is mechanical and identical to what happened to every page at index time - which is the point: the query and the documents must be processed the same way to match. The engine:

  • Tokenizes - splits the string into words.
  • Lowercases - so Tire and tire are one term.
  • Removes or downweights stop words - the, of, a carry little signal.
  • Reduces words to a root - stemming or lemmatization, so running, ran, and runs collapse to one concept.

None of this is glamorous, but it is load-bearing: skip it and half your matches disappear on a plural or a capital letter. It is also the last purely lexical step - everything after this starts guessing at meaning.

Correcting and expanding

Real queries are messy, so the engine rewrites them before matching. Two moves do most of the work:

  • Spelling correction. chnage a tire becomes change a tire - the "did you mean" you sometimes see, applied silently more often than not, learned from the billions of times other people corrected the same slip.
  • Query expansion. The engine adds synonyms and variants so a search for car can match a page that only says automobile, and tire reaches tyre. It widens the net from the exact words to the concept behind them.

The tradeoff here is precision versus recall. Expand too aggressively and you match pages that are merely related, burying the exact answer; expand too little and you miss the page that used a different word. Tuning that balance is a large part of what separates a good ranker from a literal one.

Reading intent

Beyond the words is what you are trying to do, and engines classify queries by intent because it changes what a good result even looks like. The classic buckets:

  • Informational - "how do i change a tire" wants an explanation or steps.
  • Navigational - "youtube" wants a specific site, not a page about YouTube.
  • Transactional - "buy running shoes" wants to act, not read.

Context sharpens it further. The same word, python, means the language or the animal depending on the words around it and on what most people who typed it went on to click - the aggregate behavior from ranking signals feeding back into interpretation. Get intent wrong and even a perfectly relevant page is the wrong answer, because it answers a question the user did not ask.

From words to meaning

Everything so far still operates on words - cleaned, corrected, expanded, but words. The limitation is real: two queries can share no words and mean the same thing ("how to fix a flat" vs "repairing a punctured tire"), and synonym lists never keep up with the ways people actually phrase things. Semantic search is the shift from matching words to matching meaning.

The move is to stop representing a query as a bag of terms and start representing it as a point in a space of meaning - where "flat tire" and "punctured tyre" land close together because they mean nearly the same thing, regardless of shared letters. That representation is an embedding, and it is the mechanism underneath.

Embeddings and vector search

An embedding is a list of numbers - a vector - that a model assigns to a piece of text so that similar meanings get nearby vectors. Encode every document and the query the same way, and "find relevant results" becomes "find the document vectors closest to the query vector" - a geometry problem, not a word-matching one.

// each text becomes a vector; closeness = similarity in meaning
embed("how to fix a flat tire")      // → [0.12, -0.04, 0.91, ...]
embed("repairing a punctured tyre")  // → [0.11, -0.05, 0.89, ...]  ← very close
embed("best pizza in chicago")       // → [-0.77, 0.32, 0.10, ...]  ← far away

// retrieval: rank documents by nearest vector to the query
nearestNeighbors(queryVector, documentVectors, k = 10);

Finding nearest neighbors among billions of vectors fast is its own engineering problem, solved with approximate-nearest-neighbor indexes built for exactly this. Modern engines run this alongside the classic inverted index, not instead of it - lexical matching still wins for exact terms, names, and codes, while vector search catches meaning the keywords miss. The blend is the current state of the art.

The bridge to AI answers

This is where the search series turns toward the AI layer. The retrieval step inside an AI answer engine - the "R" in retrieval-augmented generation - is exactly the semantic search described here: embed the question, find the nearest document vectors, feed them to the model. Query understanding is the shared foundation under both classic search and AI answers.

So the arc of the engine is one story: from matching cleaned-up words in an inverted index, to matching meaning through embeddings, to handing those retrieved meanings to a model that writes the answer. Understand the query side and the leap from "ten blue links" to "one generated paragraph" stops being a leap - it is the same retrieval, read one step further.

References