Article body
Full article
Abstract: While most ChatBI products still revolve around natural language to SQL, HENGSHI takes a different route: NL2Metrics, or natural language to metrics. It uses a metrics semantic layer instead of generating SQL at runtime. This article examines three structural weaknesses of NL2SQL in enterprise environments, explains how NL2Metrics works, and shows why “model first, then ask” is the foundation of enterprise-grade accuracy.
1 The Mainstream Dilemma: Three Structural Weaknesses of NL2SQL
Most conventional ChatBI solutions use NL2SQL: a user asks a question, a large language model generates SQL, the system executes it, and the result is returned. This can look impressive in a demo, but it presents several problems that are difficult to eliminate in enterprise environments.
1.1 Uncontrollable Accuracy
Model-generated SQL can be syntactically correct and logically wrong. Consider the definition of “monthly active users”: should it be calculated by registration date, first activity, or distinct logins? Each definition produces a very different result. A model may generate perfectly valid SQL while misunderstanding the business definition. For an enterprise, a plausible but incorrect number is more dangerous than no answer at all.
1.2 Security Risk
NL2SQL exposes database execution privileges directly. A natural-language question is converted into SQL and executed, potentially producing unauthorized queries or even unintended operations. That is unacceptable in enterprise environments with strict data and row-level access controls.
1.3 Lack of Reproducibility
Different model versions may generate different SQL for the same natural-language question, producing inconsistent results. If an analytical conclusion cannot be reproduced, it cannot become a trusted business definition.
2 HENGSHI’s Answer: NL2Metrics—Model First, Then Ask
HENGSHI uses NL2Metrics: model first, then ask. The core flow has four steps:
- The enterprise defines metrics through the Modeling Agent or manually, standardizing calculation rules in the metrics platform.
- The metrics semantic layer records complete metadata, including names, calculation logic, data sources, and permission scope.
- When a user asks a question, the Agent matches it to the semantic layer and finds the correct business definition.
- The system runs the predefined query logic instead of generating SQL at runtime.
The key is that the user’s question is no longer translated directly into a database instruction. It is mapped to a metric definition that the enterprise has already established.
NL2Metrics is not a one-off construction project. It supports an iterative “build while using” cycle: HENGSHI’s Modeling Agent can help create the metrics system, and those metrics then improve the accuracy of later questions. The more complete the metrics system becomes, the more accurate AI analytics becomes; the more frequently people ask questions, the more clearly gaps in the metrics system are exposed. The two reinforce each other—enterprises do not need to spend months finishing every metric before launching AI analytics.
3 Four Enterprise Benefits of NL2Metrics
3.1 Governed Accuracy
Because calculation rules are defined in advance, the Agent matches rather than invents. The model’s task changes from creating logic from scratch to locating an established definition, sharply reducing the room for error.
3.2 Controlled Security
Permissions are attached to the metrics layer instead of the database layer. What a user can ask and which data granularity they can see are governed centrally, preventing unauthorized queries by design.
3.3 Reproducible Results
The same metric definition always produces results using the same calculation rules. Stable definitions make conclusions reproducible and allow analytical knowledge to accumulate.
3.4 Governable Business Logic
Metric lineage, version management, and change history remain transparent. Enterprises can trace who defined a metric, when its calculation changed, and which reports are affected.
4 The Right Role for Large Models: Understanding, Not Guessing
NL2Metrics does not reject the capabilities of large language models; it reallocates their work. NL2SQL asks the model to generate and guess—to write SQL from scratch. NL2Metrics asks it to understand and match—to find the metric a user actually means within the semantic layer. The first leaves uncertainty to the machine; the second places certainty in governed business definitions. For enterprise use, this distinction fundamentally improves reliability.
5 What Enterprises Should Look for in an AI Analytics Solution
When evaluating an AI analytics product, treat the metrics semantic layer as a core criterion. Does the solution provide a governable metrics system? Who defines calculation rules, and how are they retained? Does the Agent match established metrics, or does it guess at business meaning?
Teams considering a home-grown ChatBI stack based on LangChain and a large model should also account for three gaps. First, the technical path: self-built systems commonly use NL2SQL, where accuracy and security are hard to guarantee. Second, product maturity: commercial platforms include a metrics platform, permissions, and multi-tenant management that home-grown implementations often lack. Third, maintenance cost: commercial products continue to evolve, while a custom system requires ongoing engineering investment.
From data preparation and metric modeling to visualization delivery, HENGSHI embeds AI across the full BI workflow. Every stage follows the same pattern: people make decisions; Agents execute them. That may be the dividing line between enterprise AI analytics and demo-grade ChatBI.
6 Frequently Asked Questions
Q: Must Data Agent be used with a metrics platform?
A: Yes. The metrics semantic layer is the foundation of Data Agent accuracy. HENGSHI’s Modeling Agent can help build that system, so adoption is iterative: use an Agent to create metrics, then use those metrics to improve the Agent’s answers.
Q: Which large language models are supported?
A: HENGSHI Data Agent supports integration with multiple mainstream model providers. Consult the official documentation for the current compatibility list. Enterprises can select a suitable model or connect a privately deployed model through an API.