企业语义层：从指标口径到业务世界 · 第 1 篇
作者：亿问 Data Agent 技术团队·发布于 2026-05-15
很多团队上了 ChatBI、Data Agent 后发现 AI"查不准数"，第一反应是模型不行。但瓶颈往往不在模型，在数据架构——十年建成的数仓是为 BI 设计的，AI 用不了。这篇写给数仓架构师和数据负责人：为什么 AI 时代的数据建设要从"表驱动"转向"问驱动"，以及四条可落地的改造路径。
企业数据建设过去十年的主线是"BI 时代"。Data Agent 能理解业务意图、拆解复杂任务、执行分析路径、给出可操作的洞察——但今天大多数产品还卡在第一步：连"查个数"都查不准。
AI 的能力很强，但你给它的表，还是十年前为 BI 设计的那一套。
十年建成的数据仓库，是为 BI 准备的，不是为 AI 准备的。是时候换一个思路了。
回顾企业数据建设过去十年的"BI 时代"，设计逻辑非常清晰：
让报表"跑得快"，让仪表盘"秒开"
预计算、预聚合、宽表、Cube、多层汇总
DWD → DWS → ADS，层层收拢，层层聚合
查询响应 < 3 秒，IT 人写 SQL，业务人看报表
在这个范式下，一张典型的 ADS 层报表表长这样：
BI 说完美，业务说够快，数据团队说终于上线了。没有人觉得有问题——因为那时候，所有问题都是"已知"的：报表是固定的，指标是确定的，查询是写好的。
Data Agent 之所以能干活，底层靠的是 AI 的理解和推理能力。但 AI 面对精心设计的汇总表，常常一脸茫然。
这不是 AI 笨，是表的设计逻辑和数据的使用逻辑反了。
| 维度 | BI 的视角 | AI 的视角 |
|---|---|---|
| 数据粒度 | 越汇总越好——快 | 越细越好——灵活 |
| 时间口径 | 预存本月数、累计数 | 需要原始时间字段，自己算 |
| 指标定义 | 写在 ETL 代码里，隐式存在 | 需要显式、可读、可配置 |
| 口径变更 | 改 ETL，重跑数仓，等上线 | 改配置，SQL 自动适应 |
| 可解释性 | "数据就是这样的，你信就行" | "你要告诉我怎么算出来的" |
核心矛盾浮出水面：BI 时代的表是为"查询已知问题"设计的，而 AI 要解决的是"探索未知问题"。
举个例子。你给 AI 一张已经算好"本月收入"和"累计收入"的报表表，业务用户对 Data Agent 说："帮我看看今年每个月的收入趋势，但剔除 3 月份那一笔大额调整单。"
AI 能怎么办？它看不到每个月的明细，只看到"本月数"和"累计数"。它无法告诉你 2 月是多少、3 月是多少，更没法"剔除某一笔"。它只能尴尬地说：我没有这个数据。
这不是 AI 不够先进，是表结构剥夺了它的"计算能力"和"解释能力"。
你让一个分析师只看最终报表，不给他看明细账，他能分析出什么？
ADS 是应用数据服务层，是 BI 时代最极致的产物。它的设计目标非常纯粹：给固定的报表或仪表盘直接喂数据。所以 ADS 层的表通常长这样：
几十列甚至上百列，每列是一个指标
一行就是一个完整的"答案"
不需要 JOIN，不需要聚合，直接 SELECT 出数
这种表对于 BI 仪表盘来说是完美的，但对于 AI 来说几乎"不可用"：
ADS 的设计逻辑是"把答案提前写好"，而 AI 需要的逻辑是"理解问题，然后自己找答案"。这两种逻辑，从根本上就是冲突的。Data Agent 的底层是 AI，AI 用不了的表，Data Agent 自然也用不了。
这里需要一个根本性的转变。
ETL 工程师定义好所有指标 → 数据层层汇总 → 表结构固化 → 业务问题被"翻译"成查询这张表 → AI 只能回答表里"有"的问题 → Data Agent 的能力被严重束缚
业务人员定义好"业务上会问哪些类型的任务" → 反推需要哪些最细粒度的数据 → DWD 层作为底座 → 指标配置层显式定义口径 → AI 根据问题和配置，动态计算答案 → Data Agent 真正"能干"
| 旧范式（BI 时代） | 新范式（AI / Data Agent 时代） | |
|---|---|---|
| 设计起点 | "我们要出哪些报表？" | "业务会问哪些类型的任务？" |
| 核心数据层 | DWS / ADS 汇总层 | DWD 明细层 |
| 指标定义 | 写在 ETL / SQL 代码里 | 写在指标配置中心，显式可读 |
| 时间口径 | 预存本月数、累计数、同比 | 存原始时间字段，动态聚合 |
| 派生指标 | 预计算并存储 | 公式配置 + 实时计算 |
| 口径变更 | 改代码 → 重跑任务 → 等上线 | 改配置 → 即时生效 |
| 下钻能力 | 有限，取决于有没有预先把明细准备好 | 无限，因为明细层一直在 |
| AI 的体验 | 迷茫、不信任、只能答固定问题 | 可解释、可验证、可执行复杂任务 |
不是把现有的数仓推倒重来，而是在现有基础上做一次"认知升级"和"架构调整"。
一张设计良好的 DWD 明细表，远比十张 DWS 汇总表对 AI 更友好。AI 需要的是"可以自由计算的原材料"，而不是"已经做好的菜"。现代计算引擎已经能够支持明细层的秒级查询，性能不再是借口。
不要把逻辑埋在 SUM(CASE WHEN 科目 IN (...) THEN 金额 END) AS 收入 这样的 SQL 里，AI 看不到、读不懂。要建一个指标配置表，写清楚"收入 = 科目A + 科目B + 科目C"，让 AI 读配置、动态生成 SQL。口径从"潜规则"变成"显式知识"。
存原始时间字段，不要只存"本月数"和"累计数"。让 AI 自己决定要不要累加、要不要按时间范围过滤、要不要做同比环比。你把计算权还给 AI，Data Agent 才能真正"智能"。
AI 不应该直接面对混乱的物理表名和晦涩的字段名。在物理表之上建一个统一的语义层，Data Agent 问数的对象是实体、时间、指标、维度。物理表只是实现细节，可以随时优化和替换。
必须澄清一点：不是说 BI 时代的设计全是错的，也不是让企业把现有的数仓全部删掉。
DWD、DWS、ADS 每一层都有它的价值。ADS 对于固定报表、监管报送、高管驾驶舱这些场景，依然是最优解。
问题在于：如果你希望 Data Agent 能干活，能回答"任意问题"、能做复杂分析，就不能只给 AI"固定答案"。
所以务实的路径是：
这样既保护了已有的数仓投资，又为下一代智能分析铺好了路。
十年建成的数据仓库，是一笔宝贵的资产，不是包袱。
BI 时代，我们用表结构回答了"收入是多少""毛利是多少"。AI 时代，业务需要的不仅是"是多少"，更是"为什么低了""哪个环节出了问题""如果换个口径会怎样"。这些问题的答案，不在 ADS 的某一行里，而在明细数据被重新组织、重新计算的过程中。
以前是人看报表，现在是 AI 看数据。人和 AI 看数据的方式，本来就不一样。
先有业务任务，后有表结构。这是 AI 时代数据建设的第一性原理，也是 Data Agent 真正能"干活"的前提。在亿问 Data Agent 的工程实践里，正是用 DWD 明细层 + 指标配置 + 语义层这套组合，让模型负责理解问题、让语义基础设施负责稳定执行，从机制上抑制幻觉、产出可复核的结论。
不是模型不行，是数据架构不适配。企业数仓的 ADS/DWS 层是为 BI 的固定查询设计的，预聚合、预计算的表结构剥夺了 AI 的计算自由度和可解释性。AI 只看到"本月收入"的结果，看不到明细，无法下钻、无法换口径、无法剔除异常。
不需要。务实的路径是保留 ADS 服务现有 BI 报表，同时强化 DWD 明细层、引入指标配置层让口径显式化，让 Data Agent 跑在 DWD + 指标配置上。这样既保护已有投资，又为 AI 分析铺路。
ADS 的设计逻辑是"把答案提前写好"——宽表、一行一答案、零 JOIN。AI 需要的是"理解问题，自己找答案"——需要明细、需要知道口径怎么算、需要能下钻。两种逻辑从根本上冲突。
现代 OLAP 引擎（如 ClickHouse、StarRocks、Doris）已经能支持明细层的秒级查询。性能不再是回避 DWD 的理由，关键是把明细层做规范、字段命名清晰、语义层做好隔离。
语义层是在物理表之上的一层业务语义抽象。Data Agent 问数时面对的不是混乱的物理表名和晦涩字段名，而是统一的实体、时间、指标、维度。物理表只是实现细节，可以随时优化替换而不影响 AI 的理解。更完整的语义层能力模型，见《语义层不能只剩指标和维度：Data Agent 时代，企业到底该建什么》。
★ 为亿问自有技术术语。词条详见「技术词典」栏目。