Article body
Full article
A user asks for this month’s sales, then follows up on category mix, regional differences, and year-on-year changes. One analysis now spans several conversational turns. HENGSHI SENSE Data Agent can use the current page, data assets, and conversation to process these requests; personal preferences and automatic learning serve different purposes. Configuring and validating them separately reduces repeated explanations while preventing old conditions, incorrect experience, or personal habits from changing business definitions.
1 Which conditions must follow-up questions retain?
After “What are this month’s net sales in East China?”, “Break it down by category” depends at least on region, period, metric definition, and data source. “Compare with the same period last year” also requires deciding whether the comparison uses matching dates or a complete fiscal period. Conversational continuity requires these conditions to remain correct in subsequent queries.
Data Agent’s environmental awareness can use the logged-in account and the page being viewed. Starting a request within a particular data package, dataset, or dashboard can provide context for resource selection. Users should still state changes explicitly, such as “Switch to the nationwide scope” or “Use the previous fiscal year,” and check that the new result has not retained filters that should be removed.
Teams can record the conditions for a multi-turn question set: data source, metric, time, organization, filters, and current requirement. This is a manual acceptance method, not a product interface table with that name. Comparing each follow-up’s query and result distinguishes fluent conversation from correct data conditions.
2 Maintain presentation preferences separately from business definitions
Users may prefer monetary amounts in units of RMB 10,000, a fixed date format, or particular charts where appropriate. HENGSHI SENSE provides personal AI-assistant preferences with individualized instructions written in Markdown. Make them concrete and conditional, for example: “Prefer units of RMB 10,000 and state the unit in the result; include the original amount when exact reconciliation is required.”
Business and data owners must maintain calculation definitions together. Whether net sales deduct refunds, when the fiscal year begins, and how an active customer is defined belong in metrics and dataset knowledge. Personal preferences can influence presentation, but cannot change agreed organizational calculations or expand data permissions.
| Information | Suggested place to maintain it | How to check |
|---|---|---|
| Period and region for the current analysis | Current question and conversational conditions | Compare queries and results at every turn |
| Date format and display units | Personal AI-assistant preferences | Validate new conversations and current-task requirements separately |
| Metric calculations and fiscal-year definition | Metrics, dataset knowledge, and business explanations | Reconcile with reports and detail using identical conditions |
| Accessible data scope | Identity and resource permissions | Verify using actual business roles |
If instructions conflict, inspect the actual result and adjust the relevant configuration. “User preferences have highest priority” is not a universal rule overriding system requirements, permissions, or data definitions.
2.1 Write personal preferences as verifiable Markdown
“Give a professional answer” is hard to test. A default unit, when to change it, and what the answer must disclose can each be checked. The following Markdown is a starting point for personal AI-assistant preferences. Adapt it to your work before saving, then verify behavior through real analytical questions.
# My analysis preferences
## Amounts and dates
- Display amounts in units of RMB 10,000 by default; label the unit in titles or table headers.
- When this turn explicitly requests yuan, use yuan; provide original precision for reconciliation.
- Use YYYY-MM-DD for dates and state both start and end dates of each range.
## Result organization
- Give key results first, then explain metrics, filters, and anomalies.
- Prefer line charts for time trends and bar charts for category comparisons.
- If a question admits multiple reasonable definitions, explain the ambiguity and ask.
- Do not invent missing data; state when something cannot be verified.These instructions describe desired behavior; they do not override permissions or metric definitions. Retest the same metric with “Show the trend” and “Check the exact amount,” observing whether charts, units, and detail suit the task. If preferences are too long or conflict, remove repeated requirements and isolate issues one by one instead of adding more exceptions.
2.2 Write business knowledge as definitions grounded in data
The following belongs to a different category: knowledge maintained in the relevant data asset after business-owner confirmation. Keep it out of personal preferences. Field names and rules are fictional examples, not a net-sales definition every enterprise should adopt or a platform import format.
# Net-sales definition (example; business confirmation required)
- Source: reviewed sales and refund detail.
- Calculation: confirmed sales amount minus confirmed refund amount.
- Period attribution: sales use confirmation date; refunds use refund confirmation date.
- Currency: RMB, excluding tax; do not directly add different currencies.
- Region: sales region assigned at the time of the transaction.
- Prior-year comparison: matching calendar-date ranges, stated in the result.
- Open question: whether historical refunds restate earlier periods; do not infer before confirmation.
- Ownership: finance confirms the definition; the data team maintains metrics and field mappings.Knowledge descriptions must agree with executable metrics. If it is unclear whether a refund belongs to its occurrence date or the original order date, obtain the business decision first. A model cannot choose the “correct” answer between unresolved rules. After a definition changes, check metric calculations, dataset explanations, and retained question samples together so old and new definitions do not remain in different objects.
3 Automatic learning has its own switch
Context, explicit preferences, and background automatic learning have different lifecycles. The current public configuration manual provides SELF_EVOLUTION_ENABLED to control learning from errors, conversation insights, and user-preference extraction. It is off by default: explicitly setting true enables automatic learning, while false disables it. Previously saved explicit configuration remains unchanged after an upgrade, so administrators must inspect the deployed value rather than infer it from the default.
This switch does not disable ordinary analytical questions or conversation summaries. The ability to ask follow-up questions therefore does not prove that the platform is extracting long-term preferences. Conversely, disabling automatic learning does not mean the assistant cannot use the current conversation.
Before enabling it, owners should define what may be learned, who reviews results, and how outdated or incorrect information is handled. Allowing background learning does not guarantee that every correction persists, or that one unified interface exposes or deletes all learning records. Verify management entry points and controllable scope in the actual version.
3.1 Use two sets of comparison questions to assess the switch
First record the actual SELF_EVOLUTION_ENABLED value in the target environment and when it changed. It is an administrator configuration item, not Markdown for personal preferences. This article does not assume it is an environment variable, configuration-file key, or API request field; use the setting entry point for the deployed version.
The first set checks the current conversation: disable automatic learning, ask a clear question, then add a dimension or time comparison and check condition continuity. The second checks across conversations: start a new conversation and separately test explicitly saved preferences and earlier temporary corrections. Record the two sets separately to avoid conflating conversational context, explicit preferences, and background extraction.
If enabling automatic learning, start with verified samples having appropriate permissions. Assign reviewers and identify which object should be maintained when errors are found. “The previous answer looked good” is not evidence of lasting validity. Keep data batches and question sets fixed before and after switching, avoiding attribution of differences from data updates or model configuration to learning.
4 Correct errors in the object that owns them
An analytical failure may come from changed fields, ambiguous metrics, query errors, or insufficient permissions. Engineers should retain the original question, execution time, and logs, then address the relevant stage. Check the data model for missing fields and metric definitions and filters for numerical differences. Investigate authorization for permission failures instead of treating them as obstacles to bypass by rewriting a query.
Even if the assistant retries an error, verify the final result. An executable query establishes completion, not business correctness. Maintain frequent definitions as metrics and business terminology in dataset knowledge. Review learning results too, preventing one temporary explanation from becoming a rule for every analysis.
Ownership is concrete: business users confirm how calculations should work; data staff maintain assets and explanations; technical staff handle connections, model calls, and runtime issues. Retain the original question and neighboring samples for retesting to determine whether changes improve multiple ways of asking rather than only one output.
4.1 Turn a correction into a repeatable acceptance sample
For multi-turn questions, saving only “Break it down by category” cannot reproduce the conditions. Retain earlier questions, current entry point, account role, and expected conditions. The following JSON is a local manual regression record, not Data Agent’s conversation API or fields automatically produced by the platform.
{
"example_only": true,
"case": "East China net sales by category",
"entry": "Sales analytics dashboard",
"role": "Example: East China business analyst",
"turns": [
"Query East China net sales for October 2026",
"Break it down by category"
],
"expected": {
"metric": "Business-confirmed net-sales metric",
"period": [
"2026-10-01",
"2026-11-01"
],
"period_end_exclusive": true,
"region": "East China",
"group_by": "Category",
"display_unit": "RMB 10,000"
},
"comparison": "Reconcile with a chart using the same batch, permissions, and conditions",
"actual_observation": "Fill in after execution",
"retest_status": "Pending retest"
}If the category breakdown unexpectedly becomes nationwide, first check for lost filters. If the region is correct but amounts differ, inspect metrics, relationships, refund attribution, and data batches. After correction, rerun the original sample and ask “Switch to nationwide” and “Keep only one category.” Check both retention of existing conditions and updates when explicitly requested. One success cannot replace neighboring-scenario validation.
5 Validate page context and cross-conversation reuse separately
Questions asked inside a dashboard receive different page information from those asked on a standalone analytics page. When turning analysis results into charts or dashboards, also check selected datasets, relationships, and filters. The ability to read the current page does not imply that all modules automatically share all historical state.
Likewise, conditions continuing within one conversation do not establish inheritance by a new conversation or data reuse after changing accounts. Historical information must not serve as authorization after a user’s permissions change. Implementation teams should test the same conversation, new conversations, different roles, and permission changes separately.
For integration into a customer’s own system, agree on how conversations are created, which page conditions are passed, and how users switch topics. Clear conditions help explain why a native page works while an embedded page loses filters without reducing every problem to a model forgetting.
5.1 Reconfirm the analysis scope during long conversations
Models have finite context capacity, and long conversations may be summarized. A summary may preserve conclusions without retaining every filter, unit, and exception. After several scope changes, ask the assistant to restate the current source, metric, period, and filters before continuing. Compare that restatement with the actual query. This is usage and acceptance guidance, not a claim about a fixed product memory-window length.
When switching business topics or data assets, or conducting an independent review, start a new conversation and restate key conditions. Saved preferences reduce repeated presentation instructions; business knowledge stabilizes definitions; the current conversation carries this analysis. Maintaining them separately makes it easier to identify which layer needs correction.
| Follow-up | Retain | Change or confirm |
|---|---|---|
| Break down by category | Net-sales definition, period, East China scope | Add category grouping; reconcile aggregates with the total |
| Compare with the same period last year | Metric, region, category level | Add the comparison period; clarify matching dates versus full month |
| Switch to nationwide | Metric and time; confirm other conditions individually | Remove the East China restriction while respecting account permissions |
| Give exact values in yuan this time | Metric, scope, period, and grouping | Change only display units and precision, not the calculation definition |
6 Test actual behavior with a series of follow-ups
In an illustrative acceptance process, the team first confirms the metric and permissions for “This month’s net sales in East China,” then asks “Break down by category,” “Compare with the same period last year,” and “Switch to nationwide.” At each step, check which conditions remain and which change, comparing against charts or dataset queries with the same conditions.
Next, start a new conversation to test the preferred monetary unit, explicitly request yuan for the current turn, and check presentation. The administrator records the learning switch’s actual value and verifies behavior when off and when enabled as needed. Check permission boundaries using authorized ordinary acceptance accounts, avoiding conclusions based only on administrators.
Retain successful and failed samples without assuming that more usage must improve accuracy. HENGSHI SENSE provides page context, data semantics, personal preferences, and learning configuration. Turning these into clear conditions, ownership, and retest questions reduces repetition while keeping multi-turn analysis grounded in explainable business definitions.