Article body
Full article
Introduction
Single-turn question answering is only the entry point for ChatBI. Product maturity is tested by multi-turn dialogue. A user may ask for "top 5 products by sales in East China last month" and then continue with "what about North China," "change the time to this year," or "rank by revenue instead."
These follow-up questions are full of ellipsis and references. "That" refers to the previous analysis object. "North China" inherits the region dimension. "This year" replaces the previous time window. If every turn is treated as an isolated question, the system cannot understand the conversation.
HENGSHI ChatBI uses a Dialogue State Management engine to remember context across turns, resolve references, and incrementally modify query plans. This allows data exploration to feel like a natural conversation rather than a sequence of disconnected commands.
1. Why Multi-Turn Dialogue Is Hard for ChatBI
1.1 Single-Turn vs. Multi-Turn
A single-turn question can be modeled as question, query, and answer. Multi-turn dialogue is stateful. The current turn depends on information accumulated in previous turns.
A realistic exploration path may look like this:
"Top 5 products by sales in East China last month."
"Add North China as well."
"Only look at digital products."
"Rank by revenue instead."
"Export this for me."
Most of these sentences are incomplete by themselves. Their meaning comes from the previous state.
1.2 Three Cross-Turn Dependencies
Reference resolution maps words like "that," "it," and "this" back to historical objects.
Incremental edit recognizes that a new sentence modifies part of the previous query plan instead of creating a new one from scratch.
Context inheritance keeps previously confirmed constraints active when the user omits them in later turns.
2. Dialogue State: Working Memory for Multi-Turn Understanding
2.1 What Dialogue State Contains
After each interaction, HENGSHI ChatBI maintains a structured dialogue state. It includes the current query plan, metrics, dimensions, filters, sort order, time window, confirmed definitions, disambiguation results, user permission context, and a compact conversation summary.
This state is the system's working memory.
2.2 How State Is Updated
When a new utterance arrives, the engine performs a state delta update:
extract the incremental intent;
decide whether it adds, modifies, or explains;
merge the delta into the current state;
regenerate the semantic plan and query from the updated state.
The result is one consistent and current query definition for the whole conversation.
3. Reference Resolution: Keeping "That" and "It" Grounded
3.1 Pronoun References
Pronouns must be mapped to previous analysis objects. "Show that by month" may refer to a metric, a chart, a ranking, or a filtered dataset. HENGSHI resolves this by looking at the dialogue state, the current focus, and the candidate objects in recent turns.
3.2 Completing Omitted Information
Business users often omit information that is already obvious in context. The system fills in omitted metrics, dimensions, filters, and time windows from the active state, while keeping the completion traceable.
3.3 Cross-Turn Entity Binding
Entity references must remain stable across turns. If "East China" has already been bound to a specific region member in the semantic layer, later references inherit the same binding unless the user changes it.
4. Incremental Edit: Modify Instead of Rebuild
4.1 Recognizing Edit Intent
Follow-up questions often contain verbs such as "change," "add," "exclude," "compare," or "drill down." HENGSHI detects these edit intents and maps them to operations on the query plan.
4.2 Safety Boundaries
Not every modification should be applied silently. If an edit conflicts with prior constraints, affects permissions, or changes the meaning of a metric, the system asks for confirmation.
4.3 Traceable Modifications
Every state change is recorded. Users and developers can see which condition was inherited, which one was changed, and why the final query differs from the previous turn.
5. Context Compression: Long Conversations Without Forgetting
5.1 Why Compression Is Needed
Long conversations can exceed context limits and introduce noise. Keeping the full text of every turn is inefficient and can even confuse the model.
5.2 HENGSHI's Compression Strategy
HENGSHI separates durable analytical state from temporary dialogue text. The system preserves structured elements that affect the query, while compressing conversational details into a concise summary. This reduces token pressure while retaining business meaning.
6. Engineering Challenges
6.1 State Drift
If small edits accumulate without verification, the current state may drift away from the user's real intent. HENGSHI counters this with explicit state comparison, confidence checks, and clarification prompts.
6.2 Multi-User Concurrency
Enterprise analysis often happens in shared sessions or embedded business systems. Dialogue state must be isolated by user, tenant, permission scope, and session. This prevents one user's context from leaking into another user's analysis.
7. Technical Comparison
| Capability | Single-Turn ChatBI | Basic Memory-Based ChatBI | HENGSHI ChatBI |
|---|---|---|---|
| Context handling | None or weak | Stores chat history | Structured dialogue state |
| Reference resolution | Limited | Prompt-dependent | State-aware entity binding |
| Incremental edits | Often rebuilds query | Partially supported | Plan-level delta update |
| Long dialogue | Easy to forget | Token-heavy | State plus compression |
| Traceability | Low | Medium | Full state-change trace |
8. FAQ
Does the system remember everything the user said? It remembers what matters for analysis: confirmed metrics, filters, time ranges, entities, permissions, and the current task state. Irrelevant chat text can be compressed.
Can users correct the context? Yes. Users can override an inherited condition or clarify a reference, and the new state becomes the basis for later turns.
Why not simply send the whole chat history to the model? Because long raw history is costly, noisy, and unreliable. Structured state is more stable for BI execution.
9. Conclusion
Multi-turn ChatBI is not just chat history plus a large model. It requires an explicit state engine, reference resolution, incremental editing, context compression, and permission isolation. HENGSHI ChatBI turns follow-up questions into governed query-plan updates, making conversational analysis usable in enterprise scenarios.