Why expand 'PTO' to 'paid time off' before searching an HR policy index?

## The mismatch expansion fixes Search works on overlap. If the user writes one word for a thing and the corpus writes another, a purely lexical match finds nothing, and even a semantic match may be weak. Employee-facing corpora are full of this. Internal HR policy is written in formal, legally-reviewed language — "paid time off", "annual leave", "statutory holiday entitlement" — while employees type the three-letter abbreviation they use in chat. The document that answers the question exists, is correctly indexed, and still does not surface. Query expansion inserts the missing bridge: before retrieval, the query "PTO balance" becomes something closer to "PTO paid time off vacation annual leave balance". Now the query and the document share surface terms, and the retrieval step has something to work with. ## The three things usually expanded - **Acronyms and abbreviations.** The highest-value case, because the acronym often appears nowhere in the corpus at all. - **Synonyms and near-synonyms.** Different words for the same concept, especially where users and authors belong to different professional communities. - **Morphological and phrasing variants.** Plural forms, verb forms, and the reordering of multi-word terms. ## Where it pays, and where the encoder already handles it A modern dense embedding model has seen enormous amounts of text and represents common synonym pairs close together on its own, so expanding "car" with "automobile" adds little. Expansion earns its keep in the places the encoder's training distribution did not cover: - **Internal vocabulary.** Product codenames, team names, ticket prefixes, in-house process names — the encoder has no idea these are synonymous with anything. - **Rare or industry-specific abbreviations**, where the general-purpose sense the model learned is not your sense. - **The lexical half of a hybrid retrieval setup**, where matching is on terms rather than meaning, and a missing surface form is simply a miss. ## The ambiguity cost Expansion is not free, and its cost is not compute — it is committing to a meaning. "PTO" in an HR corpus means paid time off. In an agricultural machinery corpus it means the power take-off shaft on a tractor. Expand blindly and you may inject vocabulary from a completely different domain into the query, after which retrieval will confidently return the wrong material. The same hazard applies to any polysemous term: expanding a word with the synonyms of the wrong sense is worse than not expanding it, because the added terms outnumber the original. A second, subtler cost is dilution. A query stuffed with a dozen variants spreads its signal thin; the distinctive term the user actually cared about ("balance", "carryover", "accrual") now competes with the noise you added. Keeping expansions short and targeted matters. ## Curated versus generated expansions There are two ways to produce the variants: - **A curated glossary or synonym map**, maintained alongside the corpus. It is deterministic, auditable, cheap at query time, and it encodes your organisation's meaning of a term rather than the world's. Its cost is human maintenance — someone has to keep it current as vocabulary changes. - **Model-generated expansion at query time.** Flexible, needs no upkeep, covers terms nobody thought to list. But it re-introduces the ambiguity problem: the model picks a sense using its training priors, not your corpus, and it costs a generation call on the request path. In practice the safe default for a bounded internal domain is a curated map for the terms you know are problematic, with model generation reserved for open-domain corpora where no glossary could be complete. Domain context in the prompt — telling the model this is an HR corpus — removes most of the collision risk when generation is used. ## How to tell whether it is working Hold out a set of real user queries with known correct documents, and measure recall with expansion on and off. Segment the measurement: expansion typically helps a lot on the acronym-and-jargon slice and does nothing, or slightly hurts, on already-well-phrased natural-language queries. An aggregate number can hide both effects cancelling out.