Article body
Full article
Introduction
ChatBI lowers the threshold for data analysis, but it also raises a question that every business user will ask sooner or later: is this answer real, and can I trust it?
In traditional BI, users can often inspect a dashboard, a field definition, or a SQL statement. In ChatBI, the answer may appear as a fluent natural-language conclusion. If the system cannot explain where the number came from, which definition was used, and how the analysis was executed, the answer remains a black box.
HENGSHI builds explainability and data lineage into the ChatBI answer chain. The goal is not only to return a result, but to let the result prove itself.
1. Why ChatBI Answers Must Prove Themselves
1.1 Three Risks of a Black Box
Definition risk: users may not know whether "revenue" means contracted revenue, recognized revenue, paid amount, or another metric definition.
Source risk: users may not know which dataset, table, or permission scope produced the result.
Process risk: users may not know which filters, joins, aggregation logic, or intermediate steps led to the conclusion.
1.2 Three Levels of Explainability
A trustworthy ChatBI answer needs definition transparency, source traceability, and process visibility. These three levels map business language back to governed data assets.
2. Definition Transparency: Making Defaults Visible
2.1 Metric Definition Labels
HENGSHI marks key definitions in the answer, such as the metric formula, statistical period, time granularity, dimension, and filter conditions. Users can see what the system assumed instead of guessing.
2.2 Explicit Ambiguity Statements
When a term has multiple possible meanings, the system should not hide the ambiguity. It can state the selected definition and ask for confirmation if the business impact is high.
2.3 Connection with the Semantic Layer
Definition transparency depends on the semantic layer. HENGSHI maps natural language to governed metrics and dimensions, so the answer inherits approved business definitions instead of generating ad-hoc logic.
3. Source Traceability: Giving Data an Origin
3.1 Data Lineage Labels
The answer records the data source, dataset, model, table, and field lineage behind the result. This allows users and data teams to trace a number back to its origin.
3.2 Freshness and Delay
Some decisions depend on data freshness. HENGSHI can show refresh time, update delay, and whether the result is based on real-time or batch data.
3.3 Permission Scope
Enterprise answers are always permission-scoped. The system makes the visible scope explicit so users understand whether the result reflects all data or only data they are authorized to access.
4. Process Visibility: The Reasoning Footprint
4.1 Key Step Replay
For complex analysis, HENGSHI can replay the major steps: intent parsing, metric matching, filter resolution, query generation, execution, and final interpretation.
4.2 Intermediate Results
When an answer depends on intermediate calculations, those intermediate results can be inspected. This helps users distinguish between a wrong conclusion and a correct conclusion drawn from unexpected data.
4.3 Trace Observability
Engineering teams need traces, not just logs. HENGSHI connects answer explanation with execution traces so production issues can be debugged at the plan, query, and data levels.
5. Confidence: Letting ChatBI Score Itself
5.1 Why Confidence Matters
Not every answer should be returned with the same certainty. Ambiguous intent, incomplete metadata, stale data, or low semantic match should lower confidence.
5.2 Confidence Signals
Confidence can be calculated from metric match quality, data freshness, query success, result consistency, permission completeness, and whether the answer has passed verification.
5.3 Refusal and Clarification
When confidence is too low, the responsible behavior is to refuse, clarify, or narrow the scope. A reliable BI system should not invent certainty.
6. Drill-Down and Reverse Verification
6.1 Drill Down to Detail
Users can move from an aggregate answer to row-level or dimension-level detail, subject to permission constraints.
6.2 Drill Up to Source
Users can also trace upward from the answer to the semantic metric, dataset, source system, and lineage path.
6.3 Counterfactual Verification
For important decisions, users may ask what happens if a filter, time window, or metric definition changes. This helps validate whether the conclusion is robust.
7. Engineering Implementation
7.1 Automatic Annotation
Explanatory annotations are generated from structured execution metadata: semantic matches, query plans, lineage graphs, permissions, and runtime observations.
7.2 Structured Storage
Annotations should be stored as structured data rather than only rendered text. This makes them searchable, auditable, and reusable for debugging.
8. Technical Comparison
| Capability | Traditional BI | Basic ChatBI | HENGSHI ChatBI |
|---|---|---|---|
| Metric definition | Visible in model or docs | Often implicit | Shown in answer |
| Data source | Dashboard-level | Often hidden | Lineage-level trace |
| Process visibility | SQL or dashboard config | Weak | Plan and trace replay |
| Confidence | Manual judgment | Rarely explicit | Computed and surfaced |
| Verification | User-driven | Limited | Drill-down and reverse verification |
9. FAQ
Is explainability only for technical users? No. Business users need plain-language definitions and source labels. Engineers need deeper traces. Both views come from the same structured metadata.
Will showing lineage make answers too complex? The default answer can stay concise, while details are available on demand through explanation, drill-down, or trace views.
Can explainability prevent all wrong answers? No. It improves trust and debuggability. It also makes wrong answers easier to detect and correct.
10. Conclusion
ChatBI answers must be accountable. HENGSHI combines semantic definitions, data lineage, process traces, confidence scoring, and drill-down verification so that users can understand not only the answer, but also the path that produced it.