The hardest business questions aren't about metrics. They're about relationships.
If your BI tool can't explain why something happened, it isn't intelligence — it's reporting.
What multi-hop actually means
"Why did EMEA churn spike after the March pricing change?"
That's not one lookup. It's a traversal: pricing change → affected accounts → support ticket volume → response latency → churn events, each hop joined on a different key, several crossing system boundaries.
Single-hop tools answer what. Multi-hop is required for why, and almost every analytics stack is single-hop underneath.
Why LLMs alone don't close it
| Hop count | What the model must get right |
|---|---|
| 1 | One table, one filter |
| 2 | One join — usually inferable |
| 3+ | Join order, cardinality, grain, and which of several paths is correct |
Errors compound. A 90% chance of a correct hop is a 73% chance of a correct three-hop answer, and the output looks identical either way. There's no error bar on a confident paragraph.
The compiler approach
Treat the question as something to be compiled, not generated:
- Parse intent into a typed representation
- Resolve each concept against the versioned semantic graph
- Enumerate candidate paths, then prove one — cardinality-aware, or fail
- Inject policy predicates for the caller
- Emit dialect-perfect SQL
Step 3 is where multi-hop is won or lost. A generator picks a plausible path. A compiler proves the path exists and is unique for the requested grain, and refuses when it isn't.
That refusal is the feature. An honest "this question is ambiguous — did you mean recognised or booked revenue?" is worth more than a confident wrong causal story.
The full breakdown — the traversal architecture, cardinality handling, and worked multi-hop examples — is here:
👉 Multi-Hop Query Understanding: The Deterministic Compiler Approach
Originally published at colrows.com/blogs/multi-hop-query-understanding-the-new-frontier-of-bi
Top comments (0)