Data Agent 查不准数的根因不在大模型：从 DWD/DWS/ADS 分层看 AI 数据架构的结构性矛盾

Data Agent 查不准数的根因不在大模型，在于企业数仓 ADS/DWS 层为 BI 固定查询设计，天然不适配 AI 动态推理。本文从 DWD/DWS/ADS 分层架构出发，分析 BI 范式与 AI 范式在粒度、口径、可解释性上的结构性冲突，给出基于 DWD + 语义层 + 指标配置的四条实操适配方案。

亿问 Data Agent 是一款面向企业经营分析场景的私有化数据分析 Agent，通过自研的NL2LF2SQL引擎（Alisa）杜绝幻觉，帮助业务分析师高效产出可信结论，让管理层随时获得经营洞察并支撑决策。

你可能更熟悉"ChatBI"这个词。但我们想用一个更准确的说法：Data Agent。

它不是传统的"问数工具"——回答问题只是它的基本功。真正的 Data Agent 能理解业务意图、拆解复杂任务、执行分析路径、给出可操作的洞察。只是今天，大多数产品还卡在第一步：连"查个数"都查不准。

瓶颈不在模型，在数据。AI 的能力很强，但你给它的表，还是十年前为 BI 设计的那一套。

十年建成的数据仓库，是为 BI 准备的，不是为 AI 准备的。是时候换一个思路了。

那些年，我们为 BI 打下的"江山"

回顾企业数据建设过去十年的"BI 时代"，设计逻辑非常清晰：

• 目标：让报表"跑得快"，让仪表盘"秒开"
• 手段：预计算、预聚合、宽表、Cube、多层汇总
• 产物：DWD → DWS → ADS，层层收拢，层层聚合
• 成功标准：查询响应小于 3 秒，IT 人写 SQL，业务人看报表

在这个范式下，一张典型的 ADS 层报表表长什么样？

• 一行代表一个实体、一个期间
• 几十个指标列排开：收入、成本、毛利、利润率……
• 时间口径提前算好：本月数、累计数、同比、环比
• 派生指标固化：毛利 = 收入 − 成本，直接存成一个字段

BI 说：完美。 业务说：够快。 数据团队说：终于上线了。

没有人觉得有问题。因为那时候，所有问题都是"已知"的——报表是固定的，指标是确定的，查询是写好的。

AI 来了，它"看不懂"我们的表

Data Agent 之所以能干活，底层靠的是 AI 的理解和推理能力。但 AI 面对我们精心设计的汇总表，常常一脸茫然。

这不是 AI 笨，是表的设计逻辑和数据的使用逻辑反了。

维度	BI 的设计意图	AI 的实际需求
数据粒度	越汇总越好（性能）	越细越好（灵活计算）
时间口径	预存 MTD/YTD/YoY	需要原始 date 字段，自行聚合
指标定义	隐式写在 ETL 代码里	需要显式、可读、可配置的元数据
口径变更	改 ETL → 重跑 → 上线	改配置 → SQL 自动适应
可解释性	不需要（人信就行）	必须（AI 要解释计算过程）

核心矛盾浮出水面：BI 时代的表是为"查询已知问题"设计的，而 AI 要解决的是"探索未知问题"。

你让一个分析师只看最终报表，不给他看明细账，他能分析出什么？

ADS 的"原罪"：为呈现而生，而非为探索而生

这里要特别提一下 ADS 层——应用数据服务层。

ADS 是 BI 时代最极致的产物。它的设计目标非常纯粹：给固定的报表或仪表盘直接喂数据。 所以 ADS 层的表通常长这样：

• 宽：几十列甚至上百列，每列是一个指标
• 平：一行就是一个完整的"答案"
• 快：不需要 JOIN，不需要聚合，直接 SELECT 就能出数

这种表对于 BI 仪表盘来说，是完美的。但对于 AI 来说，几乎是"不可用"的：

• AI 不知道这些指标之间的计算关系，因为它只看到了结果，没看到过程
• 业务问"为什么这个月毛利低了"，AI 无法下钻，因为明细不在这张表里
• 业务问"能不能换个口径重新算一下"，AI 做不到，因为口径已经固化在 ETL 里了

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 的体验	迷茫、不信任、只能答固定问题	可解释、可验证、可执行复杂任务

为 AI 设计表，Data Agent 才能真正干活

不是说要把现有的数仓推倒重来。而是需要在现有基础上，做一次"认知升级"和"架构调整"。

四条实操原则：

第一，回到 DWD，别怕数据量大。

一张设计良好的 DWD 明细表，远比十张 DWS 汇总表对 AI 更友好。AI 需要的是"可以自由计算的原材料"，而不是"已经做好的菜"。现代计算引擎已经能够支持明细层的秒级查询，性能不再是借口。

第二，把"口径"从代码里"拎"出来。

不要这样做：SUM(CASE WHEN 科目 IN (...) THEN 金额 END) AS 收入，把逻辑埋在 SQL 里，AI 看不到、读不懂。

要这样做：建一个指标配置表，写清楚"收入 = 科目A + 科目B + 科目C"。AI 读配置，动态生成 SQL。口径从"潜规则"变成"显式知识"。

第三，给 AI "能算"的数据，而不是"算好"的数据。

存原始时间字段，不要只存"本月数"和"累计数"。让 AI 自己决定要不要累加、要不要按时间范围过滤、要不要做同比环比。你把计算权还给 AI，Data Agent 才能真正"智能"。

第四，用"语义层"隔离 AI 和物理表。

AI 不应该直接面对混乱的物理表名和晦涩的字段名。在物理表之上建一个统一的语义层，Data Agent 问数的对象是：实体、时间、指标、维度。物理表只是实现细节，可以随时优化和替换。

这不是推倒重来，而是认知升级

写到这里，必须澄清一点：不是说 BI 时代的设计全是错的，也不是让企业把现有的数仓全部删掉。

DWD、DWS、ADS 每一层都有它的价值。ADS 对于固定报表、监管报送、高管驾驶舱这些场景，依然是最优解。

问题在于：如果你希望 Data Agent 能干活，能回答"任意问题"、能做复杂分析，就不能只给 AI "固定答案"。

所以务实的路径是：

• 保留 ADS，服务好现有的 BI 报表和固定看板
• 强化 DWD，把明细层做扎实、做规范
• 引入指标配置层，让口径显式化、可配置
• 让 AI 跑在 DWD + 指标配置上，Data Agent 才能真正发挥作用

这样，既保护了已有的数仓投资，又为下一代智能分析铺好了路。

结语：不是 AI 挑剔，是我们该进步了

十年建成的数据仓库，是一笔宝贵的资产，不是包袱。

BI 时代，我们用表结构回答了"收入是多少""毛利是多少"。

AI 时代，业务需要的不仅是"是多少"，更是"为什么低了""哪个环节出了问题""如果换个口径会怎样"。

这些问题的答案，不在 ADS 的某一行里，而在明细数据被重新组织、重新计算的过程中。

不是 AI 太挑剔，是你的表还活在十年前。

不是你的表不好，是它服务的对象变了。

以前是人看报表，现在是 AI 看数据。

人和 AI，看数据的方式，本来就不一样。

先有业务任务，后有表结构。

这应该是 AI 时代，数据建设的第一性原理。也是你的 Data Agent 真正能"干活"的前提。

FAQ

Data Agent 查不准数，是大模型能力不够吗？

不是。核心瓶颈在数据架构而非模型能力。企业数仓的 ADS/DWS 层为 BI 的固定查询设计，预聚合的表结构剥夺了 AI 的计算自由度——AI 只看到汇总结果，无法下钻到明细、无法换口径重算、无法剔除异常数据。解决方案是让 Data Agent 对接 DWD 明细层 + 显式指标配置，而非 ADS 汇总表。

从 BI 架构适配到 AI 架构，工程上怎么落地？

不需要推倒重来。务实路径是"两套并行"：保留 ADS 服务现有 BI 报表，同时做四件事——强化 DWD 明细层（字段命名规范、粒度统一）、引入指标配置层（口径从 ETL 代码迁移到显式配置）、存原始时间字段替代预聚合的 MTD/YTD、在物理表之上建语义层隔离 AI 和底层表结构。

NL2SQL 方案和 NL2LF2SQL 方案在数据架构要求上有什么区别？

NL2SQL 方案让大模型直接面对物理表生成 SQL，对表结构的命名规范和注释质量要求极高，且口径变更需要重新调优 prompt。NL2LF2SQL 方案（如亿问 Data Agent 采用的 Alisa 引擎）在自然语言和 SQL 之间增加了 Logicform（逻辑形式）中间层，AI 先生成结构化的业务意图表达，再由引擎根据语义模型层（SemanticDB）翻译为 SQL。这种架构对物理表的直接依赖更低，口径变更只需改语义配置，不需要动模型。

DWD 明细层数据量大，查询性能能满足企业级需求吗？

可以。现代列式 OLAP 引擎（ClickHouse、StarRocks、Doris 等）在明细层查询上已经能做到秒级响应，支持亿级行数据的实时聚合。关键工程要点是：合理设计分区键和排序键、按查询模式选择物化视图加速、语义层做好查询路由。性能不再是回避 DWD 的理由。

语义层的建模成本和维护成本怎么控制？

关键是让口径变更的成本足够低。传统做法改 ETL → 重跑 → 上线，周期以天计。基于指标配置层的做法是改配置即时生效，不需要动 ETL pipeline。亿问 Data Agent 的语义模型层（SemanticDB）支持热更新，业务调口径不需要停机重建。建模上，基础算子集合（查询、筛选、聚合、归因、对比等）是通用的，每个企业只需定义自己的语义槽位（对象、指标、维度、约束）。