从传统 BI 到 Agentic BI：AI 问数不准？先搞懂“统一指标平台”

过去很长一段时间，企业 BI 的基本工作方式并没有发生根本变化。

数据团队完成数据建模、指标加工和报表开发，业务人员再通过看板、筛选、钻取和联动分析理解经营情况。这套模式至今仍然有效，但随着大模型进入数据分析场景，人与数据之间的交互方式正在发生变化。

用户不再需要先找到正确的报表，也不一定需要理解数据库中的字段和表结构，而是可以直接询问“华东区域本季度销售额完成多少”“哪些渠道导致客户流失率上升”“按照当前趋势，年度目标是否存在风险”。

自然语言正在成为新一代 BI 的重要交互入口。与此同时，行业关注的问题也开始从“模型能否生成 SQL”转向另一个更加基础的问题：AI 是否真正理解企业数据背后的业务含义。

这也是从传统 BI 向 Agentic BI 演进过程中一个容易被忽略的问题。大模型降低了查询数据的门槛，但**如果企业内部并没有形成稳定、统一的业务语义，仅仅让模型能够访问数据库，并不会自然带来可信的数据分析。**

为什么大模型搞不定你的业务数据？

从技术实现上看，让大模型生成 SQL 已经不是特别困难的问题。

典型的 NL2SQL 会将用户问题、数据库 Schema 和部分示例提供给模型，由模型判断应该查询哪些表、使用哪些字段以及如何关联数据。在数据结构简单、业务规则明确的场景中，这种方式已经能够完成大量数据查询任务。

数据结构不等于业务语义

但企业数据库主要描述数据如何存储，并不天然描述数据在业务中意味着什么。

例如用户询问“今年销售额是多少”，数据库中可能同时存在订单金额、支付金额、含税金额、未税金额、退款金额和财务确认收入。即使模型准确识别了所有字段，也无法仅根据 sales_amount、pay_amount 这样的技术名称判断企业正式使用的“销售额”究竟对应哪一种计算口径。

真正的企业指标通常还包含更复杂的约束。销售额可能只统计已支付订单，需要排除测试订单和特定业务类型，以支付时间而不是下单时间作为统计日期，并按照既定规则处理退款。此时，一个指标实际上已经包含数据来源、计算逻辑、业务限定、统计周期和可分析维度等多层业务知识。

如果这些知识没有被显式定义，NL2SQL 实际上是在要求模型每次查询时重新推断一次企业业务规则。同一个问题换一种表达方式、增加一个分析维度或者改变统计范围，都可能得到另一套 SQL。SQL 在语法上可以完全正确，但最终数字仍然可能与企业正式口径存在偏差。

AI 会进一步放大既有的指标问题

Databricks 在其 Genie Agent 的官方实践建议指出，企业中的指标计算往往包含复杂业务细节，而 Agent 并不会天然理解这些规则，因此需要通过 Metric Views、SQL expressions、示例查询和明确的数据描述向 Agent 提供业务语义。

企业长期存在的指标治理问题，也会在 AI 问数中被进一步放大。同名不同义、同义不同名、重复开发和计算逻辑分散，在传统 BI 中通常表现为不同部门的报表数据“对不上”；当 AI 成为统一的数据查询入口之后，这些差异将直接影响模型对于用户问题的判断。

因此，AI 问数的准确率并不能单纯依靠更强的模型或者更多的 Prompt Example 解决。在模型生成查询之前，企业首先需要明确销售额、客户数、转化率、库存周转率这些概念究竟意味着什么。

从数据库 Schema 到统一语义层

语义层并不是大模型时代产生的新概念。

在传统 BI 架构中，它已经长期承担着连接底层数据结构和上层业务分析的作用。数据库面向技术系统保存事实表、维度表和字段，业务人员真正关心的则是销售额、利润率、订单数、客户转化率等业务对象。语义层的作用，就是将这些技术结构转换成稳定的业务语言。

进入 AI 时代之后，这一层的价值开始发生变化。

过去，Semantic Layer 主要解决不同 BI 工具和分析人员如何复用统一指标的问题；现在，它还需要为 Agent 提供理解企业数据所需的上下文。

这种变化已经体现在一些主流数据产品中。例如 Power BI Copilot 并不是只读取原始表结构，而是建立在 Semantic Model 之上，并进一步通过 AI Data Schema 等机制减少模型面对的数据歧义；Google Cloud 的 Conversational Analytics 同样明确建立在 Looker 的 Semantic Modeling Layer 之上。不同产品的实现并不相同，但方向是一致的：在自然语言与底层数据之间增加一层经过定义和治理的业务语义。

指标是业务语义的重要载体

对于结构化经营数据而言，统一指标体系正是企业业务语义最重要的承载方式之一。

一个完整的指标不仅包含名称和计算公式，还需要描述业务定义、支持维度、统计周期、业务限定、数据来源、负责人、版本、权限以及上下游关系。这样，“销售额”才不再是一段分散在某张报表或者某个 SQL 脚本中的计算逻辑，而成为可以被 BI、业务应用以及 AI 持续复用的标准业务对象。

袋鼠云 AIMetrics 的指标市场已经将指标业务属性与技术属性放在同一套体系中管理。业务属性包括名称、编码、负责人、口径和更新时间，技术属性包括支持维度、计算口径和指标落表，并进一步维护指标版本以及上下游血缘。

在指标开发侧，平台则基于事实表和维表建立数据模型，并通过原子指标、派生指标、复合指标等方式组织企业指标体系。

严格来说，统一指标平台并不等同于完整的 Semantic Layer，但在以指标分析为核心的 BI 场景中，它承担了其中最重要的一部分工作：把分散的数据结构转化为具有统一业务含义、计算规则和分析关系的指标资产。

数据库 Schema 告诉模型“数据长什么样”，语义层则进一步告诉模型“这些数据在企业里意味着什么”。

AI 问数的技术演进：从 NL2SQL 到 Semantic Query

统一语义层的出现，也在改变自然语言问数的技术实现。

传统 NL2SQL 通常由模型直接读取数据库 Schema，根据用户问题选择表、字段和 Join Path，再生成最终 SQL。这意味着业务语义理解和物理查询生成集中在同一次模型推理中。

先理解业务问题，再生成物理查询

当语义层存在之后，两者可以被拆开。

用户提出“今年华东区域各渠道销售额是多少”，系统首先需要识别的不是 fact_order 应该和哪张表 Join，而是一个更加稳定的业务查询：

latex指标：销售额
统计周期：今年
分析维度：渠道
过滤条件：区域 = 华东

随后，语义层再根据“销售额”已经定义的数据来源、计算逻辑、维度关系和业务限定寻找实际数据路径，并最终生成 SQL。

整个过程可以抽象为：

latexNatural Language
        ↓
指标 / 维度 / 时间 / Filter 识别
        ↓
Semantic Query
        ↓
Metric / Semantic Layer
        ↓
数据模型与计算路径
        ↓
SQL
        ↓
Database / Data Warehouse

如果将中间的结构化指标查询定义为 Metric Query，也可以将这一模式理解为 NL → Metric Query → SQL。但目前行业并不存在一个统一的“MQL”标准，因此更准确的描述仍然是 Natural Language → Semantic Query → SQL。

这一思路也开始直接进入商业产品的查询架构。例如 Snowflake Cortex Analyst 的 Routing Mode 会优先利用 Semantic View 中已经治理的 Metrics、Dimensions、Joins 和 Filters 生成 Semantic SQL，在无法覆盖问题时再回退到普通 SQL；Tableau Semantics 则直接使用 Natural Language to Semantic Query 描述自然语言分析过程。两者的具体实现不同，但都试图将“用户需要什么数据”和“底层数据应该如何关联计算”进一步分离。

袋鼠云 AIMetrics 当前的智能问数链路已经也有类似的架构，在 AIMetrics 中，自然语言问题首先经过语义映射进入指标语义层，系统进一步解析业务日期、查询指标、统计维度、过滤条件和衍生条件，再根据指标与底层数据之间的路径关系完成 SQL 生成和数据查询。

把概率理解与确定性计算分开

这种架构的关键并不在于“多转换了一次查询”，而是在模型与数据系统之间建立了职责边界。

大模型负责理解自然语言和分析意图，指标语义层负责维护稳定的业务定义和数据关系，查询引擎负责完成确定性计算。

指标口径不再需要模型在每次问数时重新推理，而可以作为企业长期维护的数据资产。当底层数据表或者计算逻辑发生调整时，只要指标对外表达的业务语义保持稳定，上层查询也不需要同步理解所有底层变化。

同样的逻辑还适用于权限。自然语言降低了查询门槛，但并不意味着可以绕过企业原有的数据治理体系，AIMetrics 支持指标级和行级权限，使不同用户只能访问授权范围内的指标结果。

对于企业 AI 问数而言，能够生成答案只是第一步，答案是否遵循统一业务定义、能否追溯计算来源以及是否符合用户数据权限，同样决定这套系统能否进入真实业务。

从统一指标到 Agentic BI

如果系统只能回答“本月销售额是多少”，自然语言更多只是替代了传统 BI 中的筛选和查询操作。

Agentic BI 所带来的变化，是系统开始参与完整的分析过程。

从一次查询走向连续分析

当管理者询问“为什么这个月华东区域销售额下降，并判断季度目标是否存在风险”时，这已经无法通过一次数据库查询完成。系统需要先获取销售额及同比、环比数据，确认变化之后进一步分析渠道、产品和客户结构，选择其他相关指标验证原因，再结合历史趋势判断目标完成风险，并最终组织分析结论。

过去，这套过程主要由分析人员完成。人会根据已有报表发现异常，再根据业务经验提出假设、寻找相关数据并逐步验证。Agentic BI 则试图让 Agent 根据任务主动选择指标、规划查询并持续分析。

这也意味着，分析过程越自动化，对底层业务语义的要求越高。

一次普通问数如果选择了错误指标，只会产生一个错误数字；一个能够自动继续归因、预测并提出建议的 Agent，如果第一步对指标口径的理解就存在偏差，错误会沿着整个分析链路继续传递。

生成式 BI 的建设正在从单纯强化 Text-to-SQL，逐渐转向同时建设 Semantic Model、Metrics 和 Business Context，使 AI 尽可能基于已经治理的业务语义开展分析，而不是直接面对未经解释的数据结构。

统一指标平台的角色也因此发生变化。

过去建设指标平台，更多是为了减少指标重复开发、统一业务口径，让不同部门在报表中看到一致的数字。进入 Agentic BI 之后，同一套指标定义、维度关系、数据血缘和权限体系，还可以成为 Agent 理解企业经营数据的确定性上下文。

袋鼠云 AIMetrics 的产品架构正沿着这一方向延伸。

袋鼠云 AIMetrics 如何支撑 Agentic BI

袋鼠云 AIMetrics 将自身定位为以指标为核心的智能经营体系，在开发侧统一指标口径和沉淀指标资产，在应用侧引入智能查数、波动诊断和报告生成，并通过目标管理进一步连接企业经营过程。

从 Agentic BI 的角度看，这套体系首先提供的是统一的指标资产基础。

统一指标资产，建立稳定的业务语义

首先是统一的指标资产基础。

平台覆盖指标定义、开发、调度、落地、发布和应用全过程，并通过原子指标、派生指标、复合指标和自定义指标等方式建立标准指标体系。 指标完成定义之后，可以继续通过指标市场进行统一查询和复用，而不是长期分散在报表、SQL 和不同部门的数据系统中。

连接指标语义与自然语言问数

在此基础之上，AIMetrics 将自然语言查询与指标语义层连接。

业务人员可以直接表达数据需求，由系统识别指标、维度、时间范围和过滤条件，再根据指标与底层数据之间的关系完成查询。模型面对的不再只是底层数据库中的表和字段，而可以优先围绕已经定义的业务指标理解用户意图，再由数据模型承担实际的计算和查询过程。

从智能问数延伸到归因与预测

进一步地，平台的 AI 能力已经从查询单个指标向连续分析延伸。

智能分析模块覆盖智能问数、异常监测、智能归因、趋势预测和分析报告生成，并结合企业知识形成分析建议。

在指标发生异常后，系统可以结合时间序列和关联指标扩大分析范围，而不是只返回指标当前值；趋势预测则可以利用指标血缘、维度分层和业务语义关系分析指标特征，并进一步进行多粒度预测。

让数据治理继续作用于 Agent

这些能力所对应的并不是简单地“在指标平台中接入一个大模型”。

它们反映的是 BI 架构中正在形成的一种新的分工：底层数据库和数仓继续负责数据存储与计算，统一指标平台负责沉淀业务语义和治理规则，Agent 则在此基础上完成自然语言理解、任务规划和分析过程。

传统 BI 更多解决“如何把数据展示给人”，AI 问数进一步解决“如何让人通过自然语言获取数据”，而 Agentic BI 开始尝试解决“如何让系统围绕业务问题自主完成一段分析过程”。

三者之间并不是简单的替代关系。

随着分析方式不断向 Agent 演进，指标定义、计算口径、维度关系、数据路径和权限反而需要变得更加明确。只有先将这些具有确定性的业务规则沉淀下来，大模型的自然语言理解和任务规划能力才有稳定的数据基础。

从 NL2SQL 到 Semantic Query，真正变化的不是 SQL 本身，而是企业开始把业务语义的确定性从大模型的概率推理中分离出来。

这也让统一指标平台在 Agentic BI 时代具备了新的价值：它不再只是传统 BI 上游的指标管理工具，也开始成为 Agent 理解和使用企业经营数据的语义基础。