AI Agent 数据口径为什么总对不上？

周一早上，运营看板上的本月 GMV 是 128 万，分析师用 SQL 跑出来 119 万，AI Agent 给出的答案是 124 万。三个人都觉得自己没算错，会议却开成了对数会。

这样的场景，在过去两年的 AI 数据分析 项目里并不少见。三个数字都可能是对的，它们只是用了三套口径。

AI Agent 没有凭空制造差异。它只是把原本藏在报表、SQL 和文档里的口径裂缝，放到了每一次自然语言提问里。

2024 年发表的 Spider 2.0 基准测试很能说明问题。这项基准包含 632 个真实企业问题，数据库常有上千列，模型需要理解元数据、方言文档和项目代码。结果显示，基于 o1-preview 的代码代理只解决了 21.3% 的任务，而在 Spider 1.0 上是 91.2%，在 BIRD 上是 73.0%。实验室里的 SQL 题和真实企业查询，难度完全不是一回事。

IBM 在数据质量专题中引用 Gartner 的估算，差的数据质量每年给企业带来平均 1290 万美元损失。口径不一致就是其中一种隐蔽但昂贵的质量问题，它不一定让数据变少，却会让决策变慢、让团队互不信任。

一、三个数字，为什么谁都觉得自己对

先看一个更具体的例子。

运营说的 GMV 是下单金额，包含未支付订单。分析师说的 GMV 是支付金额，剔除了退款。Agent 读到的是数仓宽表，按支付时间归属，但没有排除测试账号。三个口径都合理，只是回答的不是同一个问题。

AI Agent 的特殊之处在于，它把这种歧义放大了。传统 BI 报表把口径写死在 SQL 和前端里，虽然不透明，但至少稳定。Agent 每次都要理解问题、选择数据源、生成查询、解释结果，中间任何一步有歧义，都会得到一个看起来合理、实际上不同的数字。

所以，AI Agent 数据口径对不上，首先是一个数据工程和治理问题，不是单纯的模型问题。 如果只盯着模型换版本，最多是把错误从一种形式换成另一种形式。

二、数据口径差异，通常来自五层

把差异拆开看，通常会落在五层。先看一张全景图。

1、定义层，同名指标不是同一个东西

GMV、收入、活跃用户、留存率，这些词在每家公司都有人用，但很少有人能在一分钟内说清它的完整定义。

GMV 可能指下单金额、支付金额或结算金额。收入可能含税或不含税，可能扣退款或不扣退款。活跃用户可能按登录算，也可能按任意有效行为算，还可能按设备去重或按账号去重。只要定义里少一个条件，两个团队就会算出两个数。

定义层的问题最容易被忽略，因为大家用的是同一个词。同名不同义，是对数会上最常见的冲突源。

2、语义层，Agent 不知道表该怎么连

即使指标定义一致，Agent 还要决定订单表怎么关联用户表、支付表怎么关联退款表、多对多关系会不会放大行数。

举个常见的坑。订单表和退款表是一对多关系，直接 Join 再求和，退款金额会被重复计算。比例型指标和去重指标更危险，转化率、人均收入、去重用户数在换一个维度后，不能把已经算好的结果再聚合，必须在当前粒度重新计算。

没有语义层，模型只能靠字段名和历史 SQL 猜。它猜的不是业务，而是概率。

3、上下文层，知识库版本在打架

Agent 做分析时，往往会检索指标说明、业务规则和历史报告。如果检索到的是旧版文档，或者两份文档对同一个指标有不同解释，它就无法判断该信哪一个。

版本没有生效日期、没有负责人、没有废弃标记，是知识库最常见的问题。文档负责人调岗后，旧口径没人维护，新口径又没同步，Agent 只能在一堆互相矛盾的材料里做选择。

4、执行层，数据快照、时区和权限在变

看板是 T+1，Agent 查的是实时表。一个按自然月统计，一个按滚动 30 天。一个按 UTC 切日，一个按北京时间。一个能看全量，一个受行级权限限制。

这些差异不一定表现为随机错误，更常见的是稳定偏移。比如 Agent 和报表每天都差 3%，很可能不是模型乱答，而是某一类订单被一边算进去、另一边没算。

5、模型与治理层，生成路径和变更都没被管住

大模型按概率生成。同一个问题换个问法、换次重试，可能选到不同的字段、Join 或过滤条件。温度、上下文长度、工具选择、SQL 方言，都会影响最终结果。

更隐蔽的是治理问题。指标改了，报表改了，Agent 的知识库和语义层没改。文档负责人离职，旧口径变成孤儿。没有变更记录，没有影响分析，也没有回滚方案。

三、三个信号，快速判断问题在哪一层

不是所有差异都需要大动干戈。先做分流，再决定修哪一层。AI Agent 数据不一致，通常不是单一故障，而是一组口径问题的组合。

1、换个问法结果就变

同一个指标，换一种说法、加一个维度、重新问一次，结果就变。优先查语义层和模型层。

验证动作是固定指标、维度和时间范围，连续问 10 次，记录每次生成的 SQL、选择的表和过滤条件。如果 SQL 结构每次都不同，问题多半在语义约束不够，而不是数据本身。

2、同一问法不同人结果不同

同一个问题，运营问和财务问，答案不一样。优先查权限和上下文层。

验证动作是对比两个账号的权限、检索到的文档版本和数据快照时间。如果一个人能看到全量数据，另一个人只能看部分渠道，数字本来就不该一样。

3、Agent 与固定报表差一个稳定比例

Agent 每天都比认证报表低几个点，或者高几个点，差异方向稳定。优先查定义层和执行层。

验证动作是把差异拆到订单、退款、测试账号、时区和币种五个维度，逐项对账。能找到稳定解释的差异，通常比随机波动更好修。

如果三个信号同时出现，不要一次改五层。先修定义，再修语义，最后才调模型。

四、换模型、改提示词，为什么还是对不上

我见过不少团队把这件事归因于模型不够强，于是不断换模型、加提示词，结果数字还是对不上。

很多团队的第一反应是换更强的模型，或者把提示词写得更长。

前面提到的 21.3% 与 91.2% 的差距，说明真实企业查询的难点不只是 SQL 语法。模型要理解元数据、方言文档、项目代码和多个查询之间的关系，还要在很长的上下文里保持口径一致。换一个更强的模型，能改善语言理解和代码生成，但不会自动知道你们公司的退款算不算收入、测试账号要不要排除、按哪个时区切日。

提示词可以补几条规则，但补不齐几百个指标的口径。写得太长，还会挤占上下文，让模型更容易漏掉关键约束。

换模型是换发动机，不是修路。 发动机再好，路是断的，车也到不了。

五、先把指标定义成一份可执行合同

如果只能先做一件事，建议先做核心指标定义。注意，不是写一份放在知识库里的说明文档，而是做一份能被执行、能被审计的合同。

统一指标口径，首先要统一指标的定义、粒度和过滤规则。一份合格的指标定义，至少要有这些字段。

• 唯一 ID，每个指标一个稳定标识，改名不影响引用。
• 业务名称，业务人员日常使用的叫法。
• 业务释义，一句话说清这个指标回答什么业务问题。
• 计算表达式，分子、分母、聚合方式和去重逻辑。
• 粒度，按订单、按用户、按天还是按月。
• 可切维度，渠道、地区、品类、用户分层等允许的组合。
• 内建过滤，测试账号、取消订单、退款、内部订单等排除规则。
• 时间语义，按哪个时间字段归属，用自然月还是滚动窗口，按哪个时区切日。
• 数据来源，来自哪张事实表、哪些维表，数据更新频率是什么。
• 负责人和版本，谁对定义负责，当前是第几版。
• 生效日期和认证状态，从哪天开始生效，是认证指标还是实验指标。
• 同义词和示例问法，帮助 Agent 把业务语言映射到正确指标。

以 GMV 为例，一份可执行的定义会写成这样。GMV 等于已支付订单金额之和，剔除测试账号、取消订单和全额退款，按支付时间归属，币种统一折算，粒度为订单，允许按渠道、地区和品类切片，负责人为交易数据组，当前版本为 v3，生效日期为 2026 年 7 月 1 日，认证状态为生产可用。

这份定义同时服务 BI、数据科学和 Agent。指标定义不是文档，而是可以执行的资产。

SSOT，即单一事实来源，说的不是只存一份数据，而是同一个业务概念在全系统只有一处定义。定义改了，所有消费方跟着改，而不是每个团队各自维护一份 SQL。

六、语义层，才是 Agent 和数据库之间的口径接口

有了定义，还需要一个让 Agent 按定义查询的入口。这个入口就是语义层。

语义层把指标、维度、实体关系、过滤规则、权限和元数据组织成可查询的语义模型。Agent 不再直接面对几百张表，而是先选指标、选维度、选过滤条件，再由语义层生成查询。这也是 Agent 语义层 要解决的核心问题。

这条链路可以概括为 Text-to-Semantics-to-SQL。传统方式是模型直接面对表结构和字段名，自己拼 SQL。语义层方式是把生成空间收敛到指标、维度和过滤条件的组合，Join 路径、口径规则和权限由语义层兜底。

它主要解决三类高频错误。

第一类是字段含义不确定。收入、销售额、GMV 到底哪个是财务口径，模型不该靠猜。

第二类是 Join 路径不确定。订单关联用户，还是订单关联支付，还是订单关联合同，不同路径会得到不同结果。

第三类是过滤条件容易漏。测试账号、退款、内部订单、跨期规则，只要少一个，数字就会偏。

对去重指标和比率指标，语义层会在当前粒度重新计算，而不是对已经聚合的结果再做聚合。这一点直接决定多维度分析时数字能不能对上。

落地时不要一上来做全域。更稳的做法是下面五步。

第一步，选 5 到 20 个公司级核心指标，覆盖财务、增长、留存和转化。

第二步，每个指标配 5 到 10 个核心维度，先跑通最常用的切片方式。

第三步，让 BI、数据 API 和 Agent 使用同一套语义定义，而不是各建一套。

第四步，把指标分成 Core 和 Edge 两层。Core 是认证指标，变更要走评审和影响分析。Edge 是实验指标，可以快速试错，成熟后再晋升。

第五步，把语义定义当代码管。走版本控制、代码评审、自动化测试和发布流程。

语义层不是多一层报表，而是把口径从人脑里的默契，变成系统里的约束。 这也是 数据分析 Agent 能稳定回答业务问题的前提。

七、知识库、可观测和对账，决定口径能不能稳住

语义层解决了查询入口，但还不能保证长期稳定。指标会变，业务会变，数据源也会变。

1、知识库要能回答该信哪一版

企业知识库不是文档堆叠。一份可用的知识，至少要有结构、版本、负责人、生效日期、权限和引用来源。

Agent 需要知道，同一个概念在不同文档里出现时，哪一份是当前有效版本。还需要知道，某条规则从哪天开始生效，影响哪些指标和报表。

ThinkingAI 企业级知识库采用 Schema-first 的思路，把非结构化文档加工成实体和关系，并用 SSOT 保证同一概念只有一处定义。每次更新通过 ChangeSet 机制保证可追溯、可对比、可回滚。这套知识库作为 ThinkingAI Agentic Engine 的基础设施层，可以同时服务客服问答、SQL 生成和数据分析等场景。ThinkingAI 已服务全球 1500 家企业，接入产品超过 8000 款，跨场景的口径治理正是这类实践里最难也最值钱的部分。

2、可观测性要能还原一次回答

Agent 给出一个数字，团队要能回答五个问题。用了哪个指标？查了哪张表？带了什么过滤条件？数据快照是什么时间？中间调用了哪些工具？

没有这些信息，对数就只能靠猜。有了 Trace，才能把一次回答拆成可检查的步骤。

ThinkingAI 的 Agent 观测平台通过 Trace 采集调用关系、执行状态、耗时和 Token 使用，把 Agent 的运行过程和用户操作关联到同一会话。团队可以从失败、长耗时、异常 Trace 和 Token 波动等信号中发现问题，再下钻到单次调用，核对模型、工具和技能的执行证据。这类能力需要和权限、审计、版本管理一起设计，Agent 治理 不是上线后再补的文档，而是运行时的约束。

当 Agent 需要连接多个数据源和业务系统时，工具调用链路也要可追踪。MCP 服务 这类标准化连接方式，能减少每个系统单独适配带来的口径漂移，但前提是每个工具都明确自己返回什么数据、按什么口径返回。

3、对账要自动化，不能靠开会

每天或每周自动对比 Agent 与认证报表的核心指标。差异超过阈值就告警，并要求给出差异原因。

对账不能只看总数。还要看分渠道、分地区、分用户分层的数字，以及订单量、退款率、去重用户数这些支撑指标。总数对得上、结构对不上，往往说明口径还有问题。

口径治理的目标不是永远没有差异，而是每个差异都能解释、能定位、能回滚。

八、修复之后，怎么验证和回滚

改完定义、语义层或知识库，不要直接全量上线。先验证，再放量。

• 建立黄金问题集，准备 50 到 100 个问题，覆盖核心指标、边界条件、歧义问法和权限差异。
• 做影子运行，让新版本和旧版本并行 2 到 4 周，逐日对比结果。
• 设置容差，核心指标可以要求零差异，非核心指标可以设一个合理区间，超过区间必须解释。
• 固定版本，模型、提示词、语义层和知识库都要有版本号，出了问题能定位到具体变更。
• 准备回滚，保留旧版本、开关和备份。高风险变更先在测试环境验证，再灰度放量。
• 复盘变更，每次差异都记录原因、影响范围和修复动作，形成可复用的检查清单。

验证通过的标志，不是 Agent 说得更像人，而是下面四件事同时成立。

同一个问题连续问 10 次，结果稳定。与认证报表的差异在容差内。每个数字都能追溯到指标、SQL、数据快照和权限。指标变更后，影响范围可查，旧版本可回滚。

口径治理没有终点。业务在变，指标就会变。把口径问题当成产品问题，而不是模型问题，才算真正开始解决。

九、常见问题

1、为什么同一个问题问两次，AI Agent 的答案不一样？

常见原因有三个。模型生成路径不稳定，换次重试可能选到不同字段或 Join。检索到的知识版本不同，两次回答引用了不同口径。数据快照不同，实时表和 T+1 表本来就会有差异。先记录每次生成的 SQL、引用的文档和数据时间，再判断是哪一类。

2、上了语义层，数据口径就不会错了吗？

不能这样理解。语义层能统一查询入口，减少字段含义、Join 路径和过滤条件上的分歧，但它依赖底层数据质量和指标定义本身。如果源数据有重复、缺失或延迟，语义层也会把问题带出来。语义层是必要条件，不是充分条件。

3、小团队没有语义层，怎么低成本统一口径？

先从 10 个核心指标开始，每个指标写清业务释义、计算表达式、过滤规则、时间语义和负责人。把这些定义放在一个所有团队都能访问、能版本管理的地方，再让 BI、分析和 Agent 共用。等指标数量和协作复杂度上来，再考虑语义层产品化。

4、AI Agent 能自己发现口径冲突吗？

可以发现一部分。比如 Agent 在检索时发现两份文档对同一指标定义不同，或者在执行时发现同一问题得到不同结果，可以提示冲突。但它不能替代治理。谁对定义负责、哪个版本有效、变更影响哪些报表，仍然需要人来决定。

5、统一口径应该由谁负责？

业务负责人定含义，数据团队定实现，Agent 团队定调用和验证。三方缺一不可。只让数据团队推口径，业务不认。只让业务定口径，落不了地。只让 Agent 团队调模型，解决不了源头问题。

6、换更强的模型能解决口径问题吗？

能改善语言理解、SQL 生成和部分推理错误，但解决不了定义冲突、权限差异、数据快照不一致和版本失控。模型升级值得做，但它应该排在口径治理之后，而不是之前。