Query Expansion for B2B Product AI: HyDE, Multi-Query Retrieval, and Synonym Injection

Real buyers don't write good queries.

They type things like "hex bolt 10mm stainless", "that flange we use for the pumps", or just "4S filter replacement". These fragments contain intent but almost no retrievable signal — they're too short for keyword search, too imprecise for exact-match, and too terse for dense vector retrieval to latch onto with confidence.

This is the query gap: the mismatch between what a buyer types and what your product knowledge base actually contains. Document chunks are dense, structured, specific. User queries are sparse, informal, incomplete.

Query expansion is a family of techniques that bridges this gap. Instead of sending the raw query directly to retrieval, you augment it — generating richer representations that cast a wider, smarter net. The result is dramatically better recall with no changes to your index.

This article covers three core techniques — Hypothetical Document Embeddings (HyDE), multi-query retrieval, and synonym injection — with practical guidance on when to apply each in B2B product contexts.

Why Short Queries Hurt RAG Systems

Before the solutions, it's worth being precise about the failure mode.

In a RAG pipeline, retrieval quality depends almost entirely on the semantic overlap between the query embedding and the chunk embeddings in your vector store. When a buyer writes "4S filter replacement", that query embeds into a relatively sparse point in vector space. There's not much signal to work with.

The relevant chunk in your catalog might read:

"FILTRUS-4S replacement cartridge kit, compatible with Series 4 hydraulic filtration systems. Rated for 20μm nominal filtration at flow rates up to 80 L/min. Includes O-ring seal and installation guide."

That chunk embeds into a dense, specific region of vector space. The short query might not land close enough to retrieve it in the top-K results — especially if there are dozens of similar filter products in the catalog.

The mismatch isn't a failure of your embedding model. It's a structural problem: short queries and long informative chunks live in different neighborhoods of semantic space. Query expansion is how you bring them closer together.

Technique 1: Hypothetical Document Embeddings (HyDE)

HyDE is an elegant inversion of the standard RAG pipeline. Instead of embedding the query directly, you first ask an LLM to generate a hypothetical document that would answer the query — then embed that document for retrieval.

How it works

Given the query "4S filter replacement", you send a prompt like:

"Write a short product description for a B2B industrial distributor that answers the following customer query: '4S filter replacement'"

The LLM generates something like:

"The Series 4 replacement filter cartridge (Part No. FILTRUS-4S) is designed for hydraulic filtration systems. Available in 10μm and 20μm grades, rated for continuous operation at up to 80 L/min. Sold individually or as a 5-pack. Compatible with all Series 4 housings manufactured after 2018."

This hypothetical document is rich, specific, and lives in a dense part of the same semantic space as your actual catalog chunks. When you embed it and run nearest-neighbor search, you retrieve chunks that a short query would have missed.

Why it works in B2B contexts

B2B product knowledge has predictable structure. There are only so many ways a product description is written — specs, compatibility notes, part numbers, application notes. An LLM trained on general text has excellent priors for this format, even if it hallucinates the specific details.

The key insight: HyDE doesn't need to generate a correct document. It just needs to generate a document that lives in the right region of embedding space. The retrieval step fetches the actual, accurate chunks. The hypothetical document is just a navigational tool.

When HyDE helps most

• Short or vague queries with intent but little specificity
• Queries that use informal language that doesn't appear verbatim in your docs
• Product categories where buyers often don't know the right terminology
• First-time buyers exploring a new category

When HyDE can hurt

HyDE adds LLM latency before retrieval — typically 200–800ms depending on generation length. For latency-sensitive applications (sub-500ms total response), this may be too expensive.

It also struggles with highly specific exact-match queries. If someone searches for part number 304-SS-HEX-M10-1.5-A2, HyDE generation adds noise. For queries that look like identifiers, fall back to direct retrieval or hybrid search combining BM25 and dense vectors.

A simple heuristic: detect query length and specificity. Queries under 4 tokens with alphanumeric patterns → skip HyDE. Queries 4+ tokens with natural language → apply HyDE.

Technique 2: Multi-Query Retrieval

Multi-query retrieval takes a different approach: instead of transforming the query into a hypothetical document, you generate multiple query variants and run retrieval for each.

How it works

Given "do you have something for sealing pipe threads", you prompt the LLM to generate 3–5 rewritten versions:

1. "pipe thread sealant tape PTFE"
2. "anaerobic thread sealant paste for metal pipes"
3. "thread lock compound NPT fittings"
4. "pipe dope sealing compound plumbing"
5. "thread sealing products for hydraulic fittings"

Each variant retrieves its own top-K results. You then merge the result sets (deduplicating by chunk ID) and either take the union or use a fusion scoring method like Reciprocal Rank Fusion (RRF) to re-rank.

Reciprocal Rank Fusion in practice

RRF is simple but effective. For each retrieved chunk, you compute a score based on its rank across the individual query retrievals:

RRF_score(chunk) = Σ 1 / (k + rank_in_query_i)

Where k is typically 60. A chunk that appears at rank 1 in two different query retrievals gets a much higher fused score than one that appears at rank 10 in one retrieval.

The practical effect: chunks that are semantically relevant across multiple phrasings of the same intent float to the top, while false positives that only match one variant get demoted.

The B2B synonym problem

Multi-query retrieval is particularly valuable in B2B because of industry-specific synonym proliferation. The same product concept may appear as:

• Trade names vs. generic names: "Loctite" vs. "thread locking compound"
• Regional terminology: "fitting" vs. "connector" vs. "coupling"
• Industry standards: "M10 bolt" vs. "10mm metric fastener"
• Customer vernacular: "the big blue valve" vs. "DN50 ball valve PN16"

A single query variant locks you into one vocabulary. Multiple variants spread the net across the synonym landscape automatically, without requiring you to manually build synonym tables.

Latency management

Multi-query retrieval is embarrassingly parallel — you run N vector searches simultaneously. In practice, 3–4 query variants add minimal retrieval latency (vector search is fast). The bottleneck is the LLM call to generate variants.

Mitigate this by keeping generation prompts short and caching query variants for repeated or similar queries. If the same buyer asks about pipe sealants twice in the same session, you don't need to regenerate variants.

Technique 3: Synonym and Domain Vocabulary Injection

The first two techniques use LLM generation at query time. Synonym injection is simpler and cheaper: you maintain a structured vocabulary map and expand queries deterministically before embedding.

Building a B2B synonym index

A synonym index for product AI is different from a general thesaurus. It should capture:

Trade names ↔ generic names:

"teflon tape" → ["PTFE tape", "thread seal tape", "plumber's tape"]
"scotch brite" → ["non-woven abrasive pad", "surface conditioning disc"]

Abbreviations and expansions:

"SS" → "stainless steel"
"GI" → "galvanized iron"
"DN50" → "50mm nominal diameter"
"PN16" → "pressure nominal 16 bar"

Application synonyms:

"for the pump" → ["centrifugal pump", "hydraulic pump", "pump fitting", "pump connector"]
"heat resistant" → ["high temperature", "thermal", "fire rated", "refractory"]

When a query matches a synonym trigger, you inject the expansion terms before embedding — effectively widening the semantic footprint of the query.

Combining with metadata filtering

Synonym injection pairs naturally with metadata filtering. You can use detected synonyms to infer filter values:

• Query contains "stainless steel" → filter to material: stainless_steel category
• Query contains "DN50" → filter to nominal_diameter: 50mm
• Query contains "hydraulic" → filter to application_domain: hydraulic

This combines the breadth of synonym expansion (better recall) with the precision of metadata filtering (fewer false positives).

Maintenance costs

The downside of synonym injection is ongoing maintenance. You need to curate and update the vocabulary as your product range evolves, as industry terminology shifts, and as you observe query patterns you didn't anticipate.

Practical approach: start with a small, high-confidence synonym map (50–100 entries covering your most common query patterns) and expand based on retrieval analytics. When you see queries with poor retrieval scores, check whether a synonym entry would fix them. Treat the vocabulary as a living document.

Combining the Techniques: A Practical Stack

In production, you don't have to choose. The three techniques are complementary:

Tier 1 — Always on: Synonym injection. Fast, deterministic, no LLM cost. Runs as a preprocessing step on every query.

Tier 2 — For natural language queries: Multi-query generation. Triggered when the query contains 4+ tokens and reads as natural language rather than a part number or code. Runs 3 parallel vector searches and fuses results.

Tier 3 — For vague, intent-heavy queries: HyDE. Triggered when the query is ambiguous or exploratory (e.g., "something for X" or "which product is best for Y"). Adds an LLM generation step before retrieval.

A simple query intent classification layer can route queries through the appropriate tier automatically, minimizing latency costs for exact-match lookups while applying full expansion for exploratory searches.

Measuring the Impact

Query expansion is only valuable if you can measure it. The metrics that matter:

Retrieval recall@K: Did the correct chunk appear in the top K results? Compare baseline vs. expanded queries on a labeled evaluation set. A well-tuned HyDE implementation typically improves recall@5 by 15–30% for short or ambiguous queries.

Answer relevance: Beyond retrieval, does the final LLM response correctly answer the query? Use an LLM-as-judge evaluation to score answer relevance at scale.

Latency percentiles: Track p50, p95, and p99 latency. Query expansion adds latency — make sure the quality gains are worth it and that p99 latency stays within acceptable bounds for your UX.

Miss rate: Track queries where retrieval returns no useful results. This is the clearest signal that expansion techniques are needed. A high miss rate on short queries is usually a symptom of the query gap described above.

Implementation Notes

A few practical details worth keeping in mind as you implement:

Prompt design for HyDE and multi-query generation matters. Prompts that include context about your product domain (e.g., "You are an assistant for an industrial B2B distributor...") generate better expansions than domain-agnostic prompts. A few examples in the prompt (few-shot) improve quality substantially.

Caching generated expansions is high ROI. Many queries recur. Cache HyDE documents and query variant sets by query hash (after normalization) with a TTL of 24–48 hours. This eliminates LLM costs for frequent queries and reduces median latency.

Watch for expansion drift. Multi-query generation can occasionally produce query variants that wander semantically (e.g., turning a query about "pump seals" into a variant about "swimming pools"). Include a semantic similarity filter: discard generated variants whose embedding is too far from the original query embedding.

Embedding consistency. Your query expansions must be embedded with the same model used to embed your document chunks. Mixed embedding models will destroy retrieval quality. This sounds obvious but is a real source of bugs during model upgrades — always version your embedding models and keep query and document pipelines synchronized.

When Query Expansion Isn't the Answer

Query expansion addresses the query side of the retrieval problem. It won't fix:

• Poor document chunking. If your chunks are too long, too short, or split at bad boundaries, no amount of query expansion will retrieve the right content. Fix document chunking first.
• Missing content. Query expansion can't retrieve information that isn't in your knowledge base. If buyers ask about products that aren't ingested, expansion just retrieves the least-wrong alternatives.
• Index staleness. If your product catalog has changed and your index hasn't been updated, query expansion will surface outdated information. Keep your index fresh as a prerequisite.

Think of query expansion as an amplifier for your retrieval system, not a fix for upstream data problems.

Conclusion

The query gap is one of the most underestimated challenges in B2B product AI. Most deployments optimize heavily for embedding quality, chunking, and index size — but leave significant recall on the table because raw buyer queries are too sparse to retrieve reliably.

HyDE, multi-query retrieval, and synonym injection each address the gap from a different angle:

• HyDE transforms a sparse query into a dense hypothetical document that retrieves across intent
• Multi-query spreads retrieval across synonym and phrasing variants simultaneously
• Synonym injection applies domain-specific vocabulary knowledge deterministically and cheaply

Used together in a tiered stack — with intent classification routing queries to the appropriate tier — these techniques can dramatically improve recall for the short, informal, and ambiguous queries that dominate real B2B usage.

The goal isn't to make buyers write better queries. It's to build a system that handles the queries buyers actually write.

Want to see query expansion in action on your product catalog? Axoverna applies these retrieval techniques automatically, tuned for B2B product knowledge. Start your free trial and watch recall improve from day one.