Query Understanding Is the Hidden Half of Search: From Broder's Taxonomy to LLM Query Rewriting

In 2023, Liang Wang, Nan Yang and Furu Wei prompted a 175-billion-parameter model to write a short passage answering each query, pasted it after the query, and handed the result to plain BM25. On TREC Deep Learning 2019 the untouched lexical retriever jumped from 51.2 to 66.2 nDCG@10 (Wang et al., 2023, Query2doc, arXiv:2303.07678). The same paper's limitations section carries a smaller table. BM25 answered in 16 ms. The expanded query took 177 ms to search, and waited more than 2,000 ms for the language model before searching could start.

Those two tables are the whole subject. Much of what search delivers is decided before any document is scored: whether "addidas" gets corrected, whether "jaguar" is a car or a cat, whether the user's words are the documents' words. That layer is query understanding, and it is where LLMs have changed the most and delivered the least cleanly.

Why this matters: Every retrieval system, from web search to RAG, is bounded by the query it executes. LLM rewriting adds double-digit gains on weak retrievers, subtracts quality on strong ones, costs one to two orders of magnitude more latency than retrieval, and fails by inventing constraints. Where it pays is a design decision, not a prompt tweak.

TL;DR

• Queries are short and noisy: about 2.4 terms on average, 10 to 15 percent misspelled, about 16 percent ambiguous. Ranking can only reorder what query understanding lets through.
• Generative expansion rescues weak retrievers: query2doc adds 15 nDCG@10 points to BM25 on TREC DL 2019, and HyDE lifts unsupervised Contriever from 44.5 to 61.3, near a fine-tuned model's 62.1.
• Gains shrink and often reverse as retrievers improve: across 11 methods, 12 datasets and 24 retrievers, expansion gains were strongly negatively correlated with base quality.
• Latency decides deployment. Taobao serves LLM rewrites from an offline store covering 27 percent of page views; Instacart sends about 2 percent of queries to a live 8B model it cut from about 700 ms to under 300 ms.
• A 770M T5 rewriter trained with reinforcement learning beat a ChatGPT rewriter on HotpotQA and AmbigNQ. The rewriter need not be the biggest model in the stack.
• The signature failure is the hallucinated constraint: a brand, size or attribute the user never typed, which can empty the result set while the page looks confident.

At a Glance

flowchart LR
    Q["Raw query string"] --> N["Normalise and spell-correct"]
    N --> S["Segment and link entities"]
    S --> I["Classify intent and vertical"]
    I --> C{"Rewrite cached?"}
    C -->|"head query"| R["Cached rewrite"]
    C -->|"tail miss"| L["Small LLM rewrite"]
    L --> G["Grounding guard"]
    R --> X["Structured query plan"]
    G --> X
    X --> RET["Lexical plus dense retrieval"]
    RET --> RK["Ranker"]

    classDef blue fill:#1e40af,stroke:#3b82f6,stroke-width:1px,color:#fff
    classDef purple fill:#6d28d9,stroke:#a78bfa,stroke-width:1px,color:#fff
    classDef teal fill:#0e7490,stroke:#22d3ee,stroke-width:1px,color:#fff
    classDef amber fill:#b45309,stroke:#fbbf24,stroke-width:1px,color:#fff
    classDef emerald fill:#047857,stroke:#34d399,stroke-width:1px,color:#fff
    classDef rose fill:#be123c,stroke:#fb7185,stroke-width:1px,color:#fff
    classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0

    class Q blue
    class N,S,I purple
    class C slate
    class R emerald
    class L amber
    class G rose
    class X,RET,RK teal

The distinctive part is the branch. Cheap deterministic stages run for every query; the generative stage runs only for what the cache cannot answer, and its output passes a guard before touching the index.

Before Language Models Wrote Queries

Andrei Broder's "A Taxonomy of Web Search" is short and still the first citation in most intent papers (Broder, 2002, SIGIR Forum 36(2)). Its claim was that many web users are not seeking information: some want a known site (navigational), some want to shop or download (transactional), the rest want to learn (informational). Broder measured this at AltaVista with a 2001 pop-up survey of 3,190 returns and a hand inspection of 400 logged queries. The survey put navigational queries at 24.5 percent and estimated transactional at about 36 percent; the log gave 20 percent navigational, 48 informational and 30 transactional. Broder called the log numbers "very soft".

The strings were short. More than a million Excite queries averaged about 2.4 terms (Spink et al., 2001, JASIST 52(3)). They were often wrong: Cucerzan and Brill estimated that "roughly 10-15% of the queries sent to search engines contain errors", and learned corrections from the query log itself (Cucerzan and Brill, 2004, EMNLP). Song and colleagues estimated about 16 percent of logged queries were ambiguous (Song et al., 2009, IP&M). Guo and colleagues reported that roughly 70 percent of queries contain a named entity (Guo et al., 2009, SIGIR), and Arguello and colleagues framed vertical selection, routing a query to news, images or shopping (Arguello et al., 2009, SIGIR).

Expansion is older still. Rocchio's 1971 relevance feedback in the SMART system moved a query vector toward documents a user marked relevant. Lavrenko and Croft recast feedback as estimating a relevance language model from top-ranked documents (Lavrenko and Croft, 2001, SIGIR); its interpolated form, RM3, became the standard toolkit baseline. In 2019 doc2query reversed direction, generating likely queries for each document at index time (Nogueira et al., 2019, arXiv:1904.08375).

timeline
    title Query understanding, from intent labels to generated queries
    1971 : Rocchio relevance feedback in SMART
    2001 : Lavrenko and Croft relevance-based language models
    2002 : Broder taxonomy of web search intent
    2004 : Cucerzan and Brill learn spelling from query logs
    2009 : Song et al. estimate 16 percent of queries ambiguous
         : Guo et al. named entity recognition in query
         : Arguello et al. vertical selection
    2019 : doc2query expands documents with predicted queries
    2022 : HyDE embeds a hypothetical answer document
    2023 : query2doc and Rewrite-Retrieve-Read
    2024 : Weller et al. show expansion hurts strong retrievers
         : Taobao BEQUE serves LLM rewrites from an offline store
    2025 : Instacart consolidates query understanding on a fine-tuned 8B model

What changed after 2022 was that instruction-following models could produce, zero-shot, what earlier methods estimated from noisy statistics: text that looks like a relevant document.

[IMAGE: Two stacked horizontal bars comparing Broder's AltaVista measurements: survey (navigational 24.5 percent, transactional estimated 36, informational estimated 39) and 400-query log sample (20, 30, 48). Caption: "The first intent census of web search. Broder called the log split very soft, which is why modern systems predict a distribution over intents, not a label."]

How Query Understanding Actually Works

The stack is a sequence of stages that rewrite the string or attach structure to it, cheap and deterministic early, expensive and generative late. Errors compound forward.

Intent is a distribution, not a label

Treat intent as a latent variable \(z\) with classifier output \(P(z \mid q, u)\) for query \(q\) and context \(u\). The results page \(B\) maximising expected satisfaction is

where \(U(B \mid z)\) is the utility of page \(B\) for a user whose true intent is \(z\). A peaked posterior yields a single-intent page; a flat one, as for the ambiguous 16 percent, yields a blended page, because a page that is mediocre under every intent beats one that is useless under most. A hard classifier sets \(P = 1\) on its top label and optimises the wrong objective.

Spelling as a noisy channel

Correction picks the intended query \(c\) for typed query \(q\):

\(P(c)\) is a language model over queries, estimated from query frequency; \(P(q \mid c)\) is an error model over edits, estimated from observed typos. Cucerzan and Brill's ablation shows which term carries the weight: flattening the error model so every edit cost the same barely hurt (66.1 percent recall), while replacing the query-log language model with unigram statistics "crippled the system" to 41.7 percent. The harder decision is whether to correct at all, since product codes look like typos: apply silently only when the likelihood ratio clears a threshold \(\tau\) and the original returns nothing, otherwise suggest.

Segmentation and entity linking attach structure

Segmentation chooses the phrase split with the highest n-gram score, so "new york" beats "new" plus "york" (Hagen et al., 2011, WWW). Entity linking then maps segments to typed entries. In commerce the types are the catalogue schema, and this is where a string becomes a query plan: "adidas running shoes under 80" becomes brand, category and a price ceiling, with no free text left.

Pseudo-relevance feedback and its drift

Relevance models estimate a term distribution from the top \(k\) documents \(D_k\) of a first pass:

Each feedback document votes for its terms in proportion to how likely it was to generate the query. RM3 interpolates with the original query model so expansion cannot run away:

The weakness is structural: \(P(w \mid R)\) is only as good as \(D_k\). If the first pass retrieved the wrong "jaguar", the relevance model learns the wrong sense and the second pass is more confidently wrong. On MS MARCO, RM3 lowered BM25's MRR@10 from 18.4 to 15.8 while nudging recall at 1,000 from 85.7 to 86.4, in the query2doc paper's reproduction.

Generative expansion replaces the feedback set

LLM methods keep this skeleton but generate the feedback document instead of retrieving it. query2doc builds the sparse query as

where \(d'\) is a pseudo-document of at most 128 tokens from a 4-shot prompt and the query is repeated \(n\) times. BM25 weights terms by query frequency, so without repetition a 60-word passage drowns a 4-word query. Repeating it five times (untuned per dataset) keeps the user's terms dominant while the passage adds vocabulary: RM3's \(\lambda\) implemented as string repetition.

HyDE does the same for dense retrieval. It samples \(N\) hypothetical documents and averages their embeddings with the query's under a document encoder \(f\) (Gao et al., 2022, arXiv:2212.10496):

The encoder acts as a lossy compressor that keeps topic and discards false details. The paper states its boundary condition: the expectation assumes a unimodal distribution, "i.e. the query is not ambiguous". Averaging two senses of "jaguar" yields a vector between the car and the cat, near neither.

Rewrite-Retrieve-Read trains the query, not the retriever

Rewrite-Retrieve-Read freezes the retriever and reader and trains only the query (Ma et al., 2023, arXiv:2305.14283). A T5-large rewriter (770M parameters) is warmed up on ChatGPT rewrites, then optimised with PPO against a frozen reader using Bing as the retriever. The reward is

where EM and \(F_1\) score the reader's answer and Hit records whether retrieval surfaced the gold answer; a KL penalty against the warm-up policy keeps the rewriter from drifting into degenerate strings. The small rewriter beat the ChatGPT rewriter on HotpotQA (34.38 against 32.80 EM) and AmbigNQ (47.80 against 46.40), and lost narrowly on PopQA (45.72 against 46.00).

The latency arithmetic

Let \(t_0\) be the deterministic pipeline's latency, \(p\) the fraction of queries that call a live model, and \(t_g\) the generation latency. Mean added latency is \(p \, t_g\), but the tail is governed by the misses:

With query2doc's figures, \(t_0 = 16\) ms and \(t_g > 2{,}000\) ms, so any \(p\) above 1 percent turns a 16 ms p99 into one above two seconds. Hence Instacart, with about 2 percent of queries on its live path, spent its effort shrinking \(t_g\) itself.

[IMAGE: Two latency histograms on a log-scale x-axis. Left: deterministic pipeline peaked near 16 ms. Right: the same pipeline with 5 percent of queries calling a 2,000 ms model, with an unchanged median and a second mode that owns p95 and p99. Caption: "An LLM stage touching more than one query in a hundred sets the p99 by itself."]

Seeing It in Motion

The arithmetic implies the architecture: generate offline, look up online. Taobao and Instacart both describe versions of it.

flowchart TB
    subgraph OFF["Offline, hours to days"]
        LOG["Query logs"] --> SEL["Select torso and tail queries"]
        SEL --> BIG["Large LLM generates rewrites"]
        BIG --> SIM["Simulate retrieval per rewrite"]
        SIM --> KEEP["Keep rewrites that raise relevance"]
        KEEP --> KV["Rewrite store"]
        KEEP --> FT["Training data for small model"]
    end
    subgraph ON["Online, milliseconds"]
        UQ["User query"] --> DET["Deterministic stages"]
        DET --> LOOK{"Store hit?"}
        LOOK -->|"yes"| MERGE["Union of original and rewrite recall"]
        LOOK -->|"no, gated"| SMALL["Distilled small model"]
        SMALL --> MERGE
    end
    KV --> LOOK
    FT --> SMALL

    classDef blue fill:#1e40af,stroke:#3b82f6,stroke-width:1px,color:#fff
    classDef purple fill:#6d28d9,stroke:#a78bfa,stroke-width:1px,color:#fff
    classDef teal fill:#0e7490,stroke:#22d3ee,stroke-width:1px,color:#fff
    classDef amber fill:#b45309,stroke:#fbbf24,stroke-width:1px,color:#fff
    classDef emerald fill:#047857,stroke:#34d399,stroke-width:1px,color:#fff
    classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0

    class LOG,UQ blue
    class SEL,DET purple
    class BIG,SMALL amber
    class SIM,KEEP emerald
    class KV,FT,LOOK slate
    class MERGE teal

Note the union node. Taobao does not replace the query with the rewrite; both are matched against the inverted index and their candidate sets merged. A bad rewrite can add candidates the ranker must demote, but cannot remove what the original found. For a tail query that misses the store, the online request looks like this:

sequenceDiagram
    participant U as Shopper
    participant QU as Query understanding
    participant KV as Rewrite store
    participant M as Small LLM
    participant IDX as Retrieval
    U->>QU: addidas running shoes flat feet under 80
    QU->>QU: Correct brand, segment, parse price
    QU->>KV: Lookup normalised query
    KV-->>QU: Miss
    QU->>M: Rewrite with parsed slots
    M-->>QU: Rewrite plus proposed attributes
    QU->>QU: Drop attributes not traceable to query
    QU->>IDX: Original OR rewrite, with filters
    IDX-->>QU: Candidates for ranking
    QU-->>U: Results page

[IMAGE: Mock results page for a shoe query with three callouts: the correction notice "Showing results for adidas", a removable price chip "Under 80", and a greyed chip for an attribute the rewriter proposed and the guard dropped. Caption: "Every structured constraint on the page should trace to something the shopper typed, and be removable."]

By the Numbers

Sources: Broder (2002); Cucerzan and Brill (2004); query2doc Tables 1 and 6 (Wang et al., 2023); HyDE Table 1 (Gao et al., 2022); Rewrite-Retrieve-Read Table 2 (Ma et al., 2023); Weller et al. (2024); BEQUE Section 3.5 and Table 6 (Peng et al., 2024); Instacart (Zhu et al., 2025). Instacart's figures are self-reported and not independently measured. query2doc's LLM latency was a hosted API call and, per the authors, depends on server load.

[IMAGE: Scatter plot of base retriever quality (x) against gain from query2doc (y) for BM25, DPR, SimLM and E5 from the paper's Table 1, with a downward fitted line approaching zero at the strongest model. Caption: "The better the retriever, the less an LLM-written passage adds. Weller et al. found the same slope across 24 retrievers."]

A Concrete Example

One e-commerce query, end to end. All latencies and candidate counts are illustrative, chosen as plausible for a 2-million-product catalogue on one shard; none is measured. The arithmetic is exact given those inputs.

The shopper types addidas running shoes flat feet under 80.

Step 1: Normalise (0.2 ms). Seven tokens: addidas, running, shoes, flat, feet, under, 80.

Step 2: Baseline without understanding. AND returns 0 candidates; OR returns 182,000, ballet flats included.

Step 3: Spelling (2 ms). Suppose the query language model gives \(P(\text{adidas}) = 3.1 \times 10^{-4}\) and \(P(\text{addidas}) = 2.0 \times 10^{-7}\), the error model gives 0.02 for a doubled consonant, and the probability of typing the intended string unchanged is 0.95. Then

With \(\tau = 10\) and zero AND-results for the original, the correction applies with a "showing results for adidas" notice.

Step 4: Segment and link (4 ms). [adidas] → brand; [running shoes] → category; [under 80] → price at most 80. [flat feet] links to nothing in the schema and stays free text.

Step 5: Intent (6 ms). \(P(\text{product search}) = 0.93\), \(P(\text{advice article}) = 0.06\), \(P(\text{store locator}) = 0.01\). Expected utility gives a product grid plus one guide link.

Step 6: Structured recall (12 ms).

Three is too few: listings say "stability", not "flat feet". Deterministic stages cannot bridge that vocabulary gap.

Step 7: Store lookup (1 ms). Miss. The pipeline gates live generation to queries whose structured recall falls under 20, so this one qualifies.

Step 8: Live rewrite (180 ms). The distilled model returns adidas stability running shoes men's Ultraboost with attributes {support: stability, gender: men, line: Ultraboost}.

Step 9: Guard (1 ms). "stability" is the bridge from "flat feet": keep it as a soft boost, not a filter. "men's" and "Ultraboost" trace to nothing the shopper typed: drop both. Applied as filters, they would have cut 540 candidates to 7, and since all 7 Ultraboost listings in this catalogue cost more than 80, the price filter would have left 0.

Step 10: Union (15 ms). Filtered recall stays at 540, with the 96 stability-tagged products boosted. A dense retriever over the rewrite adds 500 neighbours, 430 already present, so the ranker receives \(540 + 70 = 610\) candidates.

Total: \(0.2 + 2 + 4 + 6 + 12 + 1 + 180 + 1 + 15 \approx 221\) ms, 81 percent of it the rewrite. On a store hit the same query costs about 41 ms. Only the gated tail pays \(t_g\).

[IMAGE: Funnel for the worked example: 182,000 (OR baseline, greyed), 41,200 brand, 1,860 category, 540 price, 3 with lexical "flat feet"; a side branch shows the unguarded rewrite collapsing 540 to 7 to 0, and the guarded path widening to 610. Caption: "Structured constraints narrow recall; one invented constraint empties it."]

Where It Breaks

Hallucinated constraints

Step 9 is not a corner case: rewriters are pushed toward specific text, and specificity is what invention looks like. In structured search attributes become filters, and filters multiply. If a rewrite adds \(m\) constraints each retaining fraction \(r_i\) of candidates, recall shrinks by \(\prod_i r_i\); two invented constraints at 10 percent retention remove 99 percent of candidates. The mitigations are mechanical: execute the original alongside the rewrite and take the union; let rewrites add terms but not filters unless a filter traces to an entity link; fall back when rewritten recall drops below a floor.

When the model lacks domain knowledge, its pseudo-document is fluent and wrong. Corpus-Steered Query Expansion has the LLM select pivotal sentences from first-pass documents and expands with those alongside its own text, helping most where the model lacks knowledge (Lei et al., 2024, EACL, arXiv:2402.18031).

Strong retrievers stop benefiting

Weller and colleagues ran eleven generative query and document expansion techniques over twelve datasets and twenty-four retrievers and found a strong negative correlation between base performance and expansion gain: expansion helped weaker models and generally harmed stronger ones (Weller et al., 2024, Findings of EACL, arXiv:2309.08541). Their explanation is that generated text adds vocabulary and noise, blurring the top of a strong model's ranking.

Jagerman and colleagues at Google reported that LLM expansions, especially chain-of-thought prompts, can beat classical pseudo-relevance feedback on MS MARCO and BEIR (Jagerman et al., 2023, arXiv:2305.03653), and query2doc reports gains on every retriever it tested. The positions reconcile once baselines are compared: the favourable results are largest against BM25 and unsupervised encoders and shrink toward zero on distilled dense models. Whether expansion works is a statement about your retriever.

Ambiguity is averaged away

HyDE's expectation assumes one intent. The model commits to the commoner sense, or averages across senses into empty space, and the minority sense leaves the candidate set before ranking can diversify.

Drift compounds across stages

A wrong correction ("pytorch" to "python") followed by an expansion that is right for the corrected string produces a confident answer to a question nobody asked. Evaluate the pipeline end to end on per-query win and loss counts, not mean nDCG, because expansion helps modestly where queries already work and hurts badly where they were failing.

Caches go stale and silence hides gaps

Offline stores go stale when catalogues change, so invalidate on catalogue events, not only time. When a zero-result query is silently rewritten into a successful one, logs record success and the vocabulary gap never reaches the team that could fix the catalogue. Log the original, the rewrite and both recall counts.

Alternative Designs

No row dominates. Rules still handle the head underneath everything; generative rows earn their place where the tail carries revenue, and offline variants where latency carries users.

How It Is Used in Practice

Taobao describes the most conservative deployment in print (Peng et al., 2024, WWW Companion, arXiv:2311.03758). BEQUE fine-tunes Qwen 7B on 419,806 rewrite pairs filtered by rejection sampling from about 20 million logged rewrites, plus 155,662 manual rewrites. Candidates are ranked by what they retrieve offline and the model aligned to that order. Calling online serving "almost impractical", the authors run inference offline on torso and tail queries (results under 70 percent related) into a key-value store, then match query and rewrite separately and union them. In a 14-day A/B test GMV rose 0.40 percent overall and 18.66 percent on few-recall queries, concentrating where the original string found little.

Instacart consolidated separate query models into an LLM-centred system (Zhu et al., 2025, Instacart engineering). A large model labels queries offline, filling a head cache and training a LoRA fine-tuned Llama-3-8B. The company reports 95.7 percent F1 against 95.8 for a larger model, latency cut from nearly 700 ms (A100) to under 300 ms by merging adapters and moving to H100s, live inference for about 2 percent of queries, and 50 percent fewer tail-query complaints. All are company-reported.

RAG systems have looser budgets: when answer generation takes seconds, a 200 ms rewrite is a small share, so HyDE-style rewriting is far more affordable there than in commerce search.

Commerce taxonomies differ from Broder's. Sondhi and colleagues found five query categories with distinct behaviour in a major e-commerce engine's logs, including short, vague "shallow exploration" queries used to browse (Sondhi et al., 2018, SIGIR).

[IMAGE: Side-by-side architecture cards for Taobao BEQUE and Instacart, each showing offline large model, online store or cache, live model if any, traffic share per path (27 percent of page views covered offline; about 2 percent live), and reported latency. Caption: "Two answers to the same latency problem: precompute what you can, and make what remains live as small as possible."]

Insights Worth Remembering

1. Ranking can only reorder what query understanding lets through. A candidate the executed query never retrieved does not exist for the ranker, and recall failures are invisible in precision metrics.

2. Generative expansion is a relevance model with a different feedback set. query2doc's query repetition and RM3's \(\lambda\) solve the same problem, keeping the user's words dominant.

3. Expansion patches weak retrievers, and its value decays as they improve. Fifteen nDCG points on BM25 and under half an MRR point on SimLM, same method, same paper. Re-evaluate it with every retriever upgrade.

4. One query in a hundred sets your p99. A live model stage touching more than 1 percent of traffic owns tail latency.

5. The rewriter need not be the smartest model in the system. A 770M T5 trained on the reader's reward beat a ChatGPT rewriter on two of three benchmarks.

6. Union, never replace. Running the original beside the rewrite turns the worst case from empty results into extra candidates.

7. Every structured constraint should trace to something the user typed. Invented filters multiply; a trace check costs a millisecond.

Open Questions

Can retrieval absorb rewriting? Known: distilled 8B rewriters run in hundreds of milliseconds. Unknown: whether an instruction-following retriever can internalise rewriting so no separate generation step is needed at commerce scale.

Does the retriever-strength slope hold for multi-constraint and multi-hop needs? Weller et al. measured it on twelve benchmark datasets. Rewrite-Retrieve-Read found raw multi-hop queries hurt the reader on HotpotQA, suggesting complex needs may keep benefiting from rewriting even with strong retrievers; that is untested.

How should rewriting handle genuine ambiguity? Averaging erases minority senses and single rewrites commit to one reading. Whether per-interpretation retrieval justifies its multiplied cost is unreported in production.

How often do deployed rewriters invent constraints? Taobao, Rewrite-Retrieve-Read and Instacart each evaluate rewrites differently. No shared benchmark measures hallucinated constraints directly, and no deployed rate has been published.

How fast do rewrite stores go stale? The half-life of a cached rewrite's quality, and whether refresh should follow time, catalogue change or online recall monitoring, is absent from the public literature.

Sources and Further Reading

1. Broder, A. (2002). "A Taxonomy of Web Search." ACM SIGIR Forum, 36(2), 3-10. doi:10.1145/792550.792552
2. Spink, A., et al. (2001). "Searching the Web: The Public and Their Queries." JASIST, 52(3), 226-234. RePEc
3. Cucerzan, S., & Brill, E. (2004). "Spelling Correction as an Iterative Process that Exploits the Collective Knowledge of Web Users." EMNLP 2004. ACL Anthology
4. Song, R., et al. (2009). "Identification of Ambiguous Queries in Web Search." Information Processing and Management. doi:10.1016/j.ipm.2008.09.005
5. Guo, J., et al. (2009). "Named Entity Recognition in Query." SIGIR 2009, 267-274. doi:10.1145/1571941.1571989
6. Arguello, J., et al. (2009). "Sources of Evidence for Vertical Selection." SIGIR 2009, 315-322. doi:10.1145/1571941.1571997
7. Hagen, M., et al. (2011). "Query Segmentation Revisited." WWW 2011. doi:10.1145/1963405.1963423
8. Lavrenko, V., & Croft, W. B. (2001). "Relevance-Based Language Models." SIGIR 2001. PDF
9. Nogueira, R., et al. (2019). "Document Expansion by Query Prediction." arXiv:1904.08375
10. Gao, L., et al. (2022). "Precise Zero-Shot Dense Retrieval without Relevance Labels." ACL 2023. arXiv:2212.10496
11. Wang, L., Yang, N., & Wei, F. (2023). "Query2doc: Query Expansion with Large Language Models." EMNLP 2023. arXiv:2303.07678
12. Jagerman, R., et al. (2023). "Query Expansion by Prompting Large Language Models." arXiv:2305.03653
13. Ma, X., et al. (2023). "Query Rewriting for Retrieval-Augmented Large Language Models." EMNLP 2023. arXiv:2305.14283
14. Weller, O., et al. (2024). "When do Generative Query and Document Expansions Fail?" Findings of EACL 2024. arXiv:2309.08541
15. Lei, Y., et al. (2024). "Corpus-Steered Query Expansion with Large Language Models." EACL 2024. arXiv:2402.18031
16. Peng, W., et al. (2024). "Large Language Model based Long-tail Query Rewriting in Taobao Search." WWW 2024 Companion. arXiv:2311.03758
17. Zhu, Y., et al. (2025). "Building The Intent Engine: How Instacart is Revamping Query Understanding with LLMs." Instacart engineering, November 2025. Link
18. Sondhi, P., et al. (2018). "A Taxonomy of Queries for E-commerce Search." SIGIR 2018, 1245-1248. doi:10.1145/3209978.3210152

Free to read, no ads, no sign-up. If it was useful you can buy me a coffee.