Should synonym expansion happen at index time or query time in a search system?

## What synonym expansion does A synonym filter maps tokens to alternatives so that vocabulary mismatch between authors and searchers does not cost recall. Users type *tv*, documents say *television*; users type *laptop*, documents say *notebook*. The filter injects the alternative into the token stream, typically at the **same position** as the original, so both are candidates at that spot and phrase/proximity logic still lines up. Rules come in two shapes. **Two-way (equivalent)** rules make a set of terms interchangeable: any of them matches any other. **One-way (replacement)** rules expand in a single direction — searching a broader term finds the narrower ones, but not the reverse. Direction matters enormously in practice: making *shoe* and *sneaker* equivalent means someone searching for formal shoes gets sneakers, whereas a one-way rule from the broad to the narrow term expresses the taxonomy correctly. ## Index-time expansion The synonyms are applied during document analysis, so the injected tokens become real terms in the postings. *Advantages.* Queries remain single-token and fast; there is no per-query expansion work. Phrase and proximity behaviour is well defined because the injected tokens occupy real positions. Multi-word synonyms are much easier here, since you control the whole document token stream at write time. *Disadvantages.* The list is baked in. Any addition, removal or correction requires reindexing the corpus, which for a large index is a multi-hour operation and a deployment event rather than a config change — a serious problem for a list that merchandising or support teams want to edit weekly. The index grows with the injected tokens. Most importantly, **term statistics are corrupted**: injecting *television* into every document that says *tv* raises *television*'s document frequency above its true corpus value, lowering its IDF and changing how every query containing it is ranked, including queries that never touch the synonym rule. ## Query-time expansion The synonyms are applied while parsing the query, rewriting one token into a set of alternatives. *Advantages.* The list is configuration, not data: change it and the next query sees it, so iteration and A/B testing are cheap. The index stays a faithful record of the corpus, so IDF stays honest. Removing a bad rule is instant rather than an incident. *Disadvantages.* Every affected query becomes wider — more terms, more postings lists, more work — which matters at high query volume with large expansion sets. And the two hard problems: **Multi-word synonyms.** Mapping *ny* to *new york* means a single query token expands into a two-token sequence. A flat token list cannot represent "either this one token or those two tokens at this position", so the query parser must build a **token graph** and generate the correct alternatives. This has historically been a notorious source of wrong results, especially when combined with phrase matching or a minimum-match requirement, and it interacts badly with any filter that changes token counts. **IDF asymmetry.** If the query expands *tv* to include the much rarer *telly*, the rare term carries a far higher IDF, so a document matching only *telly* can outrank a squarely relevant document matching *tv*. Some engines let a synonym group be scored using blended statistics precisely to avoid this; where they do not, expansion sets should be kept to terms of broadly similar frequency, or the expansions down-weighted. ## Ordering inside the analysis chain Synonyms interact with the rest of the chain, and the ordering bug is extremely common: if the stemmer runs before the synonym filter, your rules must be written in **stemmed** form or they will never fire, because the token arriving at the filter is `runn`-shaped, not `running`. If synonyms run first, the injected tokens are then stemmed along with everything else, which is usually what you want. Similarly, case and accent folding must happen before matching a rule list written in lowercase. Whatever the order, the synonym list is part of the analysis contract and must be tested as such. ## Choosing The practical default is **query-time** expansion, because editability usually dominates and modern query parsing handles the common cases. Move a rule to index time when it is stable, when the query-side cost is measurable at your traffic level, or when it is a multi-word mapping the query path handles badly. Many systems do both: a small, stable, curated set at index time, plus a larger, evolving set at query time. Whatever you pick, treat synonyms as a relevance intervention, not a text-processing detail. They change recall and ranking together, they are easy to add and hard to evaluate one at a time, and a synonym list left to accumulate for two years is one of the most common causes of mysteriously bad relevance. Measure the effect of rule sets, keep them reviewable, and prefer directional rules over blanket equivalence.