Article body
Full article
Abstract: When natural-language data questions produce unexpected answers, changing the wording alone often does not resolve the problem. Teams also need to check metric definitions, question scope, data freshness and execution status. HENGSHI SENSE connects metric management, dataset knowledge, analytics pages and Data Agent, giving teams analytics objects they can revisit. Using retail operations as an example, this article explains how to locate discrepancies, restore useful analysis, and turn corrections into business assets that future questions can reuse.
1 One “wrong answer” can involve several different problems
An operations employee asks, “Why have East China sales declined this month?” Finance, however, believes sales have not declined. Do not immediately ask the model to choose between the two accounts. Operations may be looking at order amounts by payment date, while finance uses recognized revenue by revenue-recognition date. They may also apply different return rules, regional organizations or data-update times. Different numbers may reflect legitimate statistical differences, or reveal modeling, data or software problems. Troubleshooting needs to distinguish these cases.
First retain the original question, the account used, the current page, the time of the question and the actual answer. Then write down the metric, period and scope the business expects. For a multi-turn conversation, also retain the preceding context that affects this question. An unchanged record is more valuable than a later reconstruction from memory: rephrasing “this number is wrong” as a different question may already remove the conditions that caused the discrepancy.
| Symptom | Check first | Next action |
|---|---|---|
| Different values for metrics with the same name | Definitions and date conventions for revenue, sales, refunds and related metrics | Return to metric definitions and verify against a report under the same conditions |
| The wrong data object is selected | Current page, dataset descriptions, business terms and question scope | Make the scope explicit and organize synonyms and descriptions |
| Results lag behind business records | Data path, latest successful update time and update status | Inspect update records, repair the issue and reconcile again |
| Requests fail or take too long | Connections, equivalent queries, model calls and the runtime environment | Retain errors and timestamps, then inspect querying and generation separately |
| Data differs for some accounts | Application data-permission mode, row and column rules, and organizational attributes | Verify the authorized scope using the target role |
2 Use metric and knowledge management to clarify business meaning
HENGSHI metric management can extract business calculations from individual charts and organize reusable metric logic through HQL. For “net sales,” for example, the data owner first clarifies the included order statuses, tax treatment, refund attribution and date field, then establishes a shared definition. Operational dashboards, business questions and subsequent analysis can work from the same definition, giving the team a common starting point for checking problems.
Dataset knowledge management serves another purpose: explaining which questions the data can answer and how enterprise terms map to fields and metrics. Does “East China” refer to the sales region or the warehouse region? Does “this month” mean the calendar month or the fiscal month? Such distinctions should appear in model descriptions, knowledge or explicit question conditions. Store important calculations in metrics and use knowledge to explain their business meaning and conditions of use. Maintaining the two together is easier than explaining everything again in every conversation.
Data Agent can also use the current data package, dataset or dashboard page to understand a question. Teams can start with a clearly bounded operational topic and gradually add analytics objects. If questions repeatedly select the wrong data, inspect asset names, descriptions and synonyms, rather than repeatedly adjusting the same prompt. After updating knowledge, retest the original question to confirm that both the retrieved object and the definition actually used have improved.
3 Reproduce the same business question before choosing a remedy
3.1 Separate data calculation from analysis generation
First reproduce the same metric in a chart or dataset analysis, fixing the period, granularity, filters and role. If the number is also unexpected there, inspect metric calculations, join keys, duplicate rows or data updates. If the chart is correct but the answer uses a different metric or period, continue checking the question context, knowledge descriptions and returned results. A query that executes successfully can still use the wrong definition, so “query succeeded” is only one step in the investigation.
For explanations of causes, also separate changes observed in the data from business inferences. Increased refunds in a category may be a lead for further investigation; determining whether a promotion caused them requires promotion rules, order details and business facts together. Data Agent can help query, break down results and organize explanations. Business staff should review important interpretations before using confirmed conclusions to guide operational action.
3.2 Give questions that cannot proceed a concrete handoff
For an ambiguous request such as “profit,” the business user can first specify gross profit or net profit, the period and the organizational scope. If no definition has been confirmed, the data owner should establish the metric. If data is stale, an administrator should inspect update tasks. If the available data scope is insufficient, follow the established authorization process. Identifying the gap, owner and retest question is more helpful than repeatedly asking users to “phrase it differently.”
When embedding data Q&A in an enterprise application, the integration team should also define interface behavior for waiting, timeouts, asking again and human handoff. HENGSHI provides settings such as model-call timeouts and failure retries, but configuring retries does not guarantee automatic recovery. Service failures, missing definitions and insufficient permissions require different handling. After a query fails, the interface should not continue displaying business judgments without supporting data.
4 Retain an analysis entry point and preserve the same data scope
The value of HENGSHI SENSE extends beyond generating a paragraph of text. Teams can continue self-service analysis around the same dataset and retain verified charts in dashboards, allowing business users to move from Q&A to analytics assets they can view and edit. People with the appropriate permissions should confirm and maintain metrics and charts intended for long-term use; complex questions can be handed to analysts for further work.
This handoff requires checking the actual usage paths again. Applications can use different data-permission modes, and row and column rules have their own configuration conditions. Administrators should use real business roles to inspect Q&A, charts, details and permitted export paths, rather than validating only with an administrator account. After adding related datasets, verify authorization rules again so that the analysis scope remains consistent with each business role.
5 Example: correcting an East China retail sales discrepancy
The following is a fictional business example. During a weekly meeting, a retail chain finds that Data Agent’s “East China net sales this month” differs from the finance dashboard. Operations initially suspects a model-understanding error. Reproduction shows that Q&A selected a store-payment topic while finance used a settlement topic; the topics also differ in refund dates and store attribution. The team separates the issue into two questions: “Are the metrics the same?” and “Has all the data arrived?”
First, business and data owners confirm the net-sales definition used in operational meetings, align tax treatment, refund-attribution dates and the list of East China stores, and maintain those definitions in metrics and dataset knowledge. Second, they compare the chart using the same account, period and store scope. They find that the latest settlement-data update failed, leaving yesterday’s refunds out of analytics. An administrator repairs the update task and refreshes the data, after which the team samples the relevant orders for verification.
Third, the team asks the original question again and follows up with breakdowns by store, category and promotion. Data Agent helps organize the analysis; finance checks key details; and operations reviews the relevant promotions after confirming the explanation. What remains is more than one answer: a shared metric, terminology notes, an update-checking method and a set of sample questions. When another region goes live, the team can reuse this approach to prepare data and validate results.
6 Turn failure samples into maintainable analytics assets
Each correction should map to a specific object: update a metric for a definition problem, knowledge for a terminology problem, model references for field changes, update schedules for data delays, and model configuration or context for generation problems. A team can keep a lightweight issue log recording the main cause, owner, change and retest result. This is a project-operating arrangement; continued follow-up questions or an absence of complaints alone cannot establish that an answer is correct.
For frequent operational questions, business staff should confirm expected results, data staff should maintain definitions, and technical staff should handle runtime and integration problems. After fixing one sample, check neighboring periods, other regions and boundary roles to avoid merely tuning a single answer. Reusable metrics and knowledge extend improvements to more phrasings and make regressions easier to detect when models or data change.
HENGSHI brings metrics, datasets, visualization and Data Agent into the same analytics workflow, allowing teams to investigate problems through real data objects. A data question may end with a trusted answer, or with a concrete action item and a usable entry point for further analysis. By establishing the cause and retaining the correction, AI analytics can mature through everyday business use.