Home / Query understanding / Query Expansion: Techniques and When They Help

Query Expansion: Techniques and When They Help

Query expansion adds related terms or alternative phrasings to a search query so that it matches relevant documents written in different words. Classic methods use synonym lists, stemming, or pseudo-relevance feedback, which borrows terms from the top results of a first search. Newer methods ask a language model to generate related terms, alternative queries, or a hypothetical answer. Expansion mainly widens recall, and it helps keyword search most, because keyword search cannot match synonyms on its own. It can also drift off topic. In this site’s test, pseudo-relevance feedback barely helped BM25 on paraphrased questions, because BM25’s first results were already wrong. A curated synonym list fixed every question. Vector search needed no expansion at all.

What is query expansion?

Query expansion is the technique of reformulating a search query by adding related terms or generating alternative queries, so the search can find relevant documents that do not share the user’s exact words. It is one of the oldest ideas in information retrieval.

Wikipedia’s overview dates automatic query expansion to 1960, when M. E. Maron and J. L. Kuhns proposed it. The goal has not changed since: users and authors describe the same thing in different words, and a search that matches only the user’s words misses documents written in the author’s. A query for “global warming” should also find documents about “climate change”, as Haystack’s article on the topic notes.

Expansion changes what is searched for, not how documents are scored. It sits in the query understanding stage, before retrieval. Query understanding covers that stage as a whole, and query rewriting covers the related step of restating a query rather than adding to it.

How does query expansion work in information retrieval?

Query expansion works in information retrieval by adding terms that raise the chance of matching relevant documents, usually with lower weight than the original terms so they cannot dominate. The trade is recall against precision.

Wikipedia describes the trade directly. Stemming a term, for example, matches alternate word forms, which increases recall. Expansion can also raise precision indirectly, by pulling in relevant documents that would otherwise be missed. But every added term can also match irrelevant documents, so precision can fall.

Haystack’s summary puts it simply: query expansion increases the number of results, so it increases recall at some cost to precision. Because BM25 favors precision and embedding retrieval favors recall, the article suggests expansion pays off most for keyword search. Our test agrees, though with a catch about which kind of expansion works.

What are the main query expansion techniques?

The main query expansion techniques are dictionary-based expansion with synonyms and stemming, feedback-based expansion from initial results or user behavior, and LLM-based expansion that generates terms, queries, or pseudo-answers. They differ in cost, coverage, and risk.

Rocchio’s relevance feedback dates to the SMART retrieval system in 1971 and remains the classic way to move a query toward relevant results. The hypothetical-answer method has its own page, HyDE, and generating several query variants is covered in multi-query retrieval.

Does classic query expansion help keyword and vector search?

Classic query expansion helped keyword search only when it supplied the right vocabulary, and it did not change vector search, in our test on 12 paraphrased support questions. Feedback-based expansion barely helped at all.

The corpus had 24 support passages: 12 answers and 12 same-topic distractors. Each question was paraphrased, such as “I forgot my login, how do I get back in?”, sharing few words with its answer. We compared BM25 and vector search with all-MiniLM-L6-v2, each with and without expansion. One expansion was pseudo-relevance feedback: add the 10 most frequent terms from the top 3 results at half weight. The other was a hand-written synonym list.

BM25 alone ranked the answer first for 2 of 12 questions, with mean reciprocal rank 0.304. Pseudo-relevance feedback raised that to 3 of 12 and 0.376, but made several questions worse. For “can I get my money back for something I bought”, feedback pushed the answer from no match to rank 22, because it borrowed terms from wrong passages. That is the known weakness of feedback: it amplifies whatever the first search found.

The synonym list took BM25 to 12 of 12. But it was written by someone who had seen the corpus, mapping “spreadsheet” to “CSV” and “coworker” to “member”, so it shows what a well-curated domain thesaurus can do, not a generic one. Vector search found all 12 answers first without any expansion, so neither Rocchio feedback nor synonyms had room to help.

How does LLM-based query expansion work?

LLM-based query expansion works by prompting a language model to write related terms, alternative queries, or a short passage about the query, then searching with the original query plus that generated text. The model supplies vocabulary from its training instead of from a thesaurus or the first results.

Rolf Jagerman and colleagues studied this in 2023, in “Query Expansion by Prompting Large Language Models”. They tested zero-shot, few-shot, and chain-of-thought prompts and found chain-of-thought prompts especially useful, because they break a query down step by step and produce many related terms. On MS MARCO and BEIR, LLM expansions could be more powerful than traditional pseudo-relevance feedback, which depends on retrieving good documents first.

Haystack’s version generates several similar queries. For “open source NLP frameworks”, an LLM produced “natural language processing tools”, “free nlp libraries”, and similar variants, each run as a search and merged. That suits keyword retrieval, which cannot match those variants on its own.

Does query expansion help embedding models?

Query expansion helps embedding models less than keyword search on average, and helps small models more than large ones, according to Jina AI’s experiments. It can also make results worse.

Jina AI tested LLM expansions of 100, 150, and 250 words, generated with Gemini 2.0 Flash, on five BEIR datasets. For the small all-MiniLM-L6-v2 model, the best expansion length raised average nDCG@10 by 6.51 points. For the larger jina-embeddings-v3, the best gain was 1.48 points. On TREC-COVID, MiniLM rose from 47.25 to 70.18; on FiQA, it fell from 36.87 to as low as 31.84.

The authors suggest small models struggle with technical terms and rare words, which expansions explain in plainer language. Task-specific prompts raised gains further, though MiniLM still did not profit on FiQA. They list the conditions where LLM expansion makes sense: a model that handles long queries well, retrieval that is not good enough, and quality that matters more than speed.

How do you stop query expansion from drifting off topic?

You stop query expansion from drifting by weighting added terms less than the original ones and limiting how many you add. Keep the original query in every search, and rerank merged results against it. Drift is the main failure mode.

Drift happens when added terms pull in documents about something else. Our feedback test showed it: borrowing terms from wrong passages moved one answer from no match to rank 22. LLM expansions drift too, as Jina’s FiQA results show. Long generated text can bury the user’s actual intent.

• Down-weight additions: give expanded terms half weight or less, as our feedback run did.
• Cap the expansion: a few strong terms beat dozens of weak ones.
• Keep the original: always include the user’s query as one of the searches.
• Rerank: score merged results against the original query with a cross-encoder.
• Protect exact terms: never expand codes, names, or quoted phrases.

Filters help as well. If the user’s query implies a product, version, or date, apply it as a filter so expanded terms cannot pull in out-of-scope documents. Query intent classification covers detecting when expansion is appropriate at all.

What is query expansion in RAG?

Query expansion in RAG is expanding the user’s question before retrieval so that more relevant chunks reach the language model, especially when the question is short, vague, or worded differently from the documents. It is a pre-retrieval step.

Haystack’s article frames it around RAG: the generation step can only be as good as the context it receives, and retrieval depends on the query. Vague or poorly formed questions are where expansion helps most. Weaviate’s context engineering article makes a related point: users rarely type ideal queries, and different parts of a system need the query in different forms.

In RAG, keep the expansion cheap relative to the rest of the pipeline. Each LLM-generated expansion adds a model call before retrieval. For short keyword-style questions over a BM25 index, expansion often pays off; for full natural-language questions over a good embedding model, it often adds cost with little gain. Query decomposition handles a different problem: questions that need several separate searches.

How do you use query expansion with Weaviate?

You use query expansion with Weaviate either through the Query Agent, which expands queries for you, or by expanding queries in your own code and running them as hybrid or keyword searches. Both keep the original query in the search.

Weaviate’s Query Agent lists query expansion among its built-in features, describing it as enriching a query with semantically related terms to raise recall without curating synonyms. Its Search Mode has a filtering option: “recall” generates several queries across interpretations, while “precision” generates a single query for the most likely one. Weaviate also publishes a recipe notebook for query expansion with Haystack.

import weaviate

client = weaviate.connect_to_local()
docs = client.collections.use("Doc")

def expanded_search(query, expansions, k=10):
    """Run the original query and each expansion; keep each object's best score."""
    best = {}
    for q in [query] + expansions:
        res = docs.query.hybrid(query=q, alpha=0.5, limit=k)
        for rank, o in enumerate(res.objects):
            best[o.uuid] = min(best.get(o.uuid, rank), rank)
    return sorted(best, key=best.get)[:k]

ids = expanded_search("global warming effects", ["climate change impacts", "rising temperatures"])
client.close()

Generate the expansions with any language model or a domain synonym list. For keyword-heavy collections, lower alpha so the added terms matter; for semantic search, test whether expansion helps at all before paying for it. Typo tolerance and spelling correction and semantic autocomplete cover neighboring query-side fixes.

When should you use query expansion?

You should use query expansion when queries are short or vague, when keyword search misses documents written in different vocabulary, or when a small embedding model struggles with your domain’s terms. Measure before and after.

Our test and the published results point to the same rules. Keyword search benefits most, because it cannot match synonyms itself. Feedback-based expansion fails when the first search fails. LLM expansion helps small embedding models more than strong ones, and can hurt on some datasets. A good embedding model on natural-language questions may need no expansion.

Run your labeled queries with and without expansion, split by query type, and keep it only where it raises recall without lowering precision at the depth you show. How to evaluate semantic search covers building the test set.

Query expansion widens what a search can match by adding related terms or alternative queries. It helps keyword search most, because keyword search cannot match synonyms on its own; it helps small embedding models more than large ones; and it can drift. The test traced the limits of the classic tools: feedback could not rescue BM25 from a bad first search, while a curated synonym list fixed every question and vector search needed no help. Use expansion where vocabulary gaps are real, keep the original query in the search, and measure the result.