Multi-Entity Query Decomposition for B2B Product AI

Most retrieval systems are built for a simple mental model of search.

A user asks about one thing. The system finds documents about that thing. The model summarizes what it found.

That works reasonably well for straightforward questions like:

• "What is the pressure rating of part X?"
• "Do you have a 24V DIN rail power supply?"
• "Show me alternatives to SKU 48192."

But a large share of valuable B2B product conversations do not look like that.

They look more like this:

• "I need a stainless pump for a corrosive fluid, compatible with our current 1.5 inch tri-clamp fittings, suitable for 80°C operation, and ideally available in Europe this week."
• "Which replacement motor works with the older Series 9 housing if we keep the existing mounting plate and need ATEX certification?"
• "Compare the three valves we shortlisted, explain which one matches our flow range, and tell me what accessories we would need to order with it."

These are not single-entity questions. They are multi-entity, multi-constraint, multi-step decision requests.

If your product AI treats them like plain semantic search, performance drops fast. Retrieval misses one of the constraints. The model answers one part and ignores the rest. It recommends the right family but the wrong configuration. Or it pulls a technically plausible answer that is impossible to order.

That is why mature B2B product AI stacks need query decomposition.

Instead of asking retrieval to solve the whole problem in one hop, you break the request into smaller retrievable subproblems, solve each one against the right evidence, and then recombine the result into a grounded answer.

Done well, this improves accuracy, transparency, and conversion quality. Done badly, it adds latency and creates brittle pipelines. The difference is in how you decompose, what state you preserve, and when you decide decomposition is worth it at all.

---

Why Multi-Entity Queries Break Naive RAG

A standard RAG pipeline usually does this:

1. embed the whole query
2. retrieve top-k chunks
3. pass the chunks to the model
4. generate an answer

That pipeline assumes the user intent is coherent enough to be represented by one dense vector and one retrieval pass.

For B2B catalog questions, that assumption often fails for four reasons.

1. Different parts of the question map to different evidence types

A single prompt might include:

• a product family reference
• a compatibility constraint
• an environmental operating condition
• a geography or availability requirement
• a commercial preference like MOQ or lead time

Those facts may live in completely different systems or document types. Compatibility may sit in technical manuals. Temperature limits may be in spec tables. Regional availability may come from ERP or distributor feeds. Accessory requirements may be buried in application notes.

One retrieval pass rarely surfaces all of that cleanly.

2. The most important token is not always the most retrievable one

In multi-constraint questions, some terms are easy for retrieval but low-value for decision quality. Others are hard to retrieve but decisive.

A model may lock onto "stainless pump" because there are many chunks about pumps, while quietly missing the critical term "corrosive fluid" or "tri-clamp fittings". The answer then sounds helpful but fails the real buying need.

This is closely related to why metadata filtering matters in product catalogs and why structured product data improves RAG quality.

3. Composite questions often hide intermediate reasoning steps

A buyer asking for a replacement part is not always asking for lexical similarity. They may really mean:

• resolve the original part identity
• determine what version or supersession chain applies
• infer the retained surrounding components
• validate compatibility constraints
• check what documentation supports the recommendation

If the system does not expose those steps internally, it often jumps straight from query to recommendation and skips the evidence chain.

4. Long prompts dilute retrieval focus

Ironically, richer buyer prompts can make retrieval worse. The embedding averages many concepts into one representation, and the top results become a compromise rather than a fit.

This is one reason why query intent classification should not be treated as a nice-to-have. Before you retrieve, you need to understand whether the user is doing lookup, comparison, compatibility validation, substitution, bundle design, or application guidance.

---

What Query Decomposition Actually Means

Query decomposition is not just "split the sentence into keywords."

In a B2B product AI context, it means turning one natural-language request into a set of structured sub-tasks that can be solved against the right evidence sources.

A good decomposition usually creates some combination of these units:

• entity extraction: products, brands, part numbers, standards, dimensions, certifications
• constraint extraction: pressure, voltage, temperature, material, region, lead time, mounting type
• task identification: find, compare, substitute, verify, configure, explain
• relationship resolution: compatible with, replaces, requires, includes, fits, certified for
• evidence routing: which source should answer which sub-question

For example, take this query:

"Need an alternative to part A17 that works with the current enclosure, supports 230V input, and can ship to Germany within five business days."

A useful internal decomposition might be:

1. Resolve part A17 to canonical catalog entity.
2. Retrieve supersession and alternative candidates.
3. Retrieve enclosure compatibility constraints for A17's current installation context.
4. Filter candidates to 230V input.
5. Check regional fulfillment data for Germany and lead-time threshold.
6. Rank remaining options by compatibility confidence and availability.
7. Generate an answer with evidence and any missing assumptions.

Notice what happened here: the system turned one vague semantic search into an executable plan.

That is where the quality lift comes from.

---

When You Should Decompose, and When You Should Not

Not every query needs this machinery.

If the user asks, "What is the IP rating of part 34811?" full decomposition is overkill. The extra orchestration adds latency for almost no quality gain.

Decomposition is most valuable when one or more of these conditions are true:

• the query contains multiple explicit constraints
• multiple product entities are mentioned
• the request implies a comparison or substitution workflow
• different evidence types are required
• the answer affects compatibility, safety, or orderability
• the first retrieval pass is low-confidence or internally inconsistent

A practical production pattern is adaptive decomposition.

Start with intent classification and lightweight parsing. Only trigger the heavier multi-step flow when the query appears composite or high risk. This aligns well with the broader idea of adaptive retrieval based on query difficulty.

---

A Practical Architecture for Decomposition

There are many ways to build this, but the most reliable pattern has five layers.

1. Parse the query into entities, constraints, and task type

You need a parser that turns messy language into a structured working representation.

That representation does not need to be perfect. It just needs to be useful enough for downstream routing.

A minimal schema might include:

• referenced products or part numbers
• requested product class
• hard constraints versus soft preferences
• relationship verbs like "replace," "compare," or "compatible with"
• geographic/commercial constraints
• confidence score per extracted field

This is also where unit normalization becomes essential. If the parser treats 1.5 inch, 38.1 mm, and DN40-adjacent user language as unrelated concepts, the whole chain gets weaker.

2. Build a task graph, not just a flat list

Multi-entity questions often have dependency order.

You cannot validate replacement compatibility until you know the canonical source part. You cannot recommend accessories until the primary product candidate is known. You cannot finalize options until orderability checks are complete.

Representing the workflow as a task graph helps prevent premature answers.

Typical nodes include:

• entity resolution
• candidate generation
• attribute filtering
• compatibility validation
• commercial validation
• citation assembly
• response synthesis

This is conceptually related to the constraint logic we discussed in constraint propagation for B2B product AI.

3. Route each sub-task to the best evidence source

This is where many teams leave performance on the table.

They decompose the query, but every sub-task still goes to the same vector index. That is better than nothing, but it is not enough.

In a strong implementation, each sub-task can route differently:

• spec questions to structured catalog attributes
• compatibility checks to relationship tables or manuals
• certification claims to approved documentation
• orderability to live ERP or inventory feeds
• installation/accessory questions to application notes and BOM logic

Decomposition without source-aware routing only solves half the problem. For deeper background on this design principle, see source-aware RAG for product knowledge.

4. Recombine with explicit evidence tracking

Once sub-results come back, do not throw them into a prompt as undifferentiated text.

Carry forward structured evidence:

• which claim came from which source
• whether each constraint is satisfied, violated, or unknown
• which assumptions were inferred rather than proven
• where the remaining ambiguity lives

This makes the final answer safer and more explainable. It also supports better abstention. If two critical sub-checks disagree, the system should not confidently improvise.

5. Generate an answer that preserves decision structure

Many final responses flatten the work too much.

A better answer format for B2B buyers is often:

• best-fit recommendation or shortlist
• why each option qualifies
• which constraints were satisfied
• what still needs confirmation
• what accessory, configuration, or handoff is required next

This produces an answer that feels less like a chatbot and more like a competent product specialist.

---

The Hard Part: Preserving Business Context During Decomposition

One of the biggest risks in query decomposition is losing the real intent while splitting the problem.

Imagine this request:

"We need a lower-cost alternative to our current assembly for a food processing line, but it cannot create extra cleaning complexity."

If your system only extracts product attributes, it may optimize for cost and miss the operational meaning of "cannot create extra cleaning complexity." That phrase could imply surface finish, sanitary design, tool-less disassembly, certification requirements, or compatibility with existing cleaning protocols.

This is why decomposition cannot be purely syntactic. It needs a business-aware ontology.

In practice, that means mapping phrases into domain concepts such as:

• sanitary compliance
• maintenance burden
• installation constraints
• replacement versus redesign intent
• downtime sensitivity
• buyer role, such as procurement versus engineering

Without that layer, you risk decomposing the words while losing the decision.

This is also where conversation helps. Sometimes the best decomposition output is not immediate retrieval, but a clarifying question. The assistant should ask when an omitted variable materially changes the recommendation, as discussed in clarifying questions for B2B product AI.

---

Evaluation: How to Know Decomposition Is Helping

Because decomposition adds complexity, you need to prove it is worth it.

The right evaluation framework goes beyond top-line answer rate.

Measure decomposition quality itself

Track whether the system extracted the right entities, constraints, and task relationships. If this layer is weak, later retrieval improvements will be capped.

Useful checks include:

• entity extraction precision and recall
• hard-constraint capture rate
• task-type classification accuracy
• dependency graph correctness

Measure downstream retrieval gains

Compare decomposed retrieval against baseline one-shot retrieval on:

• coverage of all required constraints
• citation support for final claims
• reduction in irrelevant top-k context
• candidate recall for substitution or comparison tasks

Measure business-grade answer outcomes

What you actually care about is whether the answer became more usable.

Look for lifts in:

• correct first-pass recommendations
• reduced follow-up turns for missing constraints
• lower human correction rates
• lower bad-fit product suggestions
• higher quote-start or contact-sales quality

If you already maintain a golden dataset for product AI evaluation, composite queries should be a dedicated slice of it rather than a side case.

---

Common Failure Modes

Teams usually run into the same problems.

Over-decomposing simple queries

If the system decomposes everything, latency rises and users feel it. Reserve the complex path for questions that justify it.

Treating soft preferences as hard filters

"Ideally available this week" is not the same as "must ship this week." If you collapse those into one hard constraint, you narrow candidate sets too aggressively.

Ignoring unknowns

A decomposition pipeline should be able to say "constraint not yet verified." Too many systems silently convert unknown into true.

Recombining without ranking logic

If sub-tasks return five candidates each, you need a principled way to reconcile them. Otherwise the final prompt becomes a dumping ground and the model makes unstable choices.

Skipping orderability and operational constraints

A technically valid recommendation that cannot be bought, installed, or serviced is still a bad answer. This is why orderability-aware and workflow-aware checks matter just as much as semantic relevance.

---

Where This Matters Most for Axoverna-Style Product AI

For B2B product knowledge systems, query decomposition is especially valuable in high-friction journeys such as:

• replacement part lookup in installed-base environments
• complex compatibility questions across assemblies
• guided product selection with multiple operational constraints
• accessory and bundle recommendation
• quote-line enrichment and cross-sell suggestions
• regional or account-specific buying conditions

These are exactly the workflows where conversational AI can outperform static search, but only if the system understands that the buyer is really solving a structured decision problem.

A chat widget alone does not create that advantage. Better orchestration does.

---

The Strategic Point

A lot of teams think product AI quality is mostly about picking a better model.

I do not buy that.

For complex B2B commerce, the bigger differentiator is whether your system can turn a messy, high-intent buyer request into a sequence of grounded retrieval and validation steps.

That is what decomposition gives you.

It narrows the gap between how buyers naturally ask and how product knowledge actually needs to be resolved underneath. It lets you connect search, compatibility, structured attributes, live business data, and answer generation into one coherent flow.

And as catalogs get more complex, that orchestration layer becomes more important, not less.

The teams that get this right will not just have more conversational interfaces. They will have more dependable buying systems.

---

Final Takeaway

If your product AI struggles with high-value B2B questions, do not assume the answer is a larger model or a longer prompt.

Look at the query shape.

If the request contains multiple entities, hidden dependencies, and mixed evidence needs, one-shot retrieval is probably the bottleneck. Query decomposition lets you break the problem into solvable parts, route each part to the right source, and reassemble an answer that is both more accurate and more operationally useful.

That is not just a retrieval optimization. It is a product knowledge capability.

Want to see what this looks like in practice?

Axoverna helps B2B teams turn complex catalogs, technical documents, and commercial data into product AI that can answer real buyer questions, not just keyword lookups. If you want to build a system that handles composite product queries with more accuracy and less hand-holding, get in touch to see how Axoverna works.