Data Agent 反“幻觉”指南：如何减少错口径、错字段、错权限和错结论？

为什么 Data Agent 会出现“数字查到了，但答案仍然是错的”

企业使用 AI 问数时，一个典型困惑是：SQL 明明执行成功，为什么数字还是不对？

原因在于，企业数据分析存在多层正确性。用户问“本月华东收入同比增长多少”，Agent 不仅要理解“本月”和“华东”，还必须知道企业所说的“收入”究竟指订单金额、开票收入还是财务确认收入，“华东”按照销售组织还是客户所在地划分。

任何一个环节映射错误，都可能产生一个来自真实数据库、计算过程也没有报错，但业务含义错误的数字。因此，Data Agent 的可信度不能只用 Text-to-SQL 准确率衡量，更需要关注四类错误：

这四类问题对应的并不是同一种技术缺陷，因此也不能只依靠模型升级统一解决。

常见做法和问题所在

做法一：依靠更强模型提高 Text-to-SQL 准确率

更强模型能够改善自然语言理解、SQL 生成和复杂任务规划，但它无法自行确定企业内部最终认可的业务定义。当数据库同时存在多个收入、利润或客户字段时，模型仍然面临选择。

因此，模型能力决定的是“能不能理解和执行”，而企业语义治理决定的是“应该按照什么规则执行”。

做法二：把 Schema、文档和历史 SQL 全部提供给 Agent

增加上下文可以缓解信息不足，但大量历史信息也会扩大候选空间。尤其当旧表、废弃字段、历史口径和现行规则同时存在时，模型可能找到一个技术上合理、业务上已经失效的计算路径。

更有效的方法是根据当前问题检索相关指标、字段和规则，只把有效上下文送入当前任务。

做法三：答案生成后再用另一个模型检查

二次模型校验适合发现语言逻辑和部分 SQL 问题，却难以修复上游已经发生的语义错误。如果一开始就匹配到了错误收入指标，后续模型可能只是对错误结果进行更合理的解释。

因此，校验应分布在语义匹配、数据定位、查询执行和分析结论等关键节点，而不是集中在答案生成之后。

推荐方法框架

企业可以围绕 Data Agent 的执行链建立五层可信机制：

对应的执行链是：用户提问 → 意图识别 → 语义匹配 → 数据定位 → 权限校验 → 查询执行 → 结果验证 → 分析推理 → 输出结论。

设计原则很简单：确定性问题尽量交给确定性机制，开放性问题再交给模型推理。

指标公式、权限和字段关系有明确规则，就不应每次重新让模型判断；只有用户意图理解、任务拆解、异常分析等需要动态决策的部分，才充分发挥 Agent 的自主能力。

Step-by-Step 落地路径

Step 1：建立真实问题测试集

收集业务人员高频提出的 20～50 个问题，记录正确指标、数据来源、权限范围和标准结果，同时加入同名指标、模糊时间、越权查询等测试。按照口径、字段、权限和结论分类失败案例，形成后续上线评测基线。

Step 2：治理高频业务语义

从收入、利润、订单、客户等核心对象开始，明确指标公式、时间口径、维度、过滤条件和 Owner。对于同名多义指标建立消歧规则，使 Agent 优先匹配已有指标，而不是根据数据库字段临时组合计算逻辑。

Step 3：打通语义与底层数据

补齐核心表、字段、注释、版本和血缘关系，并识别历史表、废弃字段及高风险 Join。建立“业务概念—指标—字段—数据源”的映射，使 Agent 能够解释某个数字具体来自哪里、经过什么计算。

Step 4：把权限嵌入查询执行

查询前验证用户身份、角色、数据范围和行列权限，并设置扫描量、执行时间等资源限制。即使 Agent 生成了越权或高成本 SQL，也应由执行系统阻断，使安全边界不依赖模型自身判断。

Step 5：建立结果校验与回退

查询完成后检查时间范围、指标口径、异常值和关键计算；复杂分析进一步验证结论与数据证据是否一致。校验失败时重新规划、缩小分析范围或要求用户澄清，而不是继续生成未经验证的完整结论。

Step 6：持续评测与优化

记录用户问题、指标匹配、数据来源、权限判断、查询过程和分析结果。分别统计口径命中率、数据路径正确率、权限拦截情况和结论验证情况，并根据失败案例持续修正语义、元数据和分析 Skill。

Aloudata 技术方案

要降低 Data Agent 在企业环境中的错误，需要把指标语义、元数据、数据访问和 Agent 执行组织成连续链路。

Aloudata CAN 自动化指标平台可以管理指标定义、计算逻辑、业务维度和维度层级，并通过指标服务向 Agent 提供统一语义。对于收入、利润、订单量等标准指标，Data Agent 可以优先匹配已经治理的指标，而不是每次根据 Schema 重新生成计算逻辑。

Aloudata BIG 主动元数据平台提供表、字段、SQL、任务和血缘等元数据能力，使指标能够进一步关联到底层数据来源。Agent 在选择数据时不仅看到字段名称，也能够结合数据关系判断来源，并为结果追溯提供依据。

面对分布在多个数据库、数仓和数据平台中的数据，Aloudata AIR 可以提供逻辑数据编织与跨源访问能力，减少为了 AI 分析重复搬运和建设新的数据副本。

在此基础上，Aloudata Agent 可信数据分析智能体负责理解用户问题、规划分析任务并调用相应的数据与分析 Skill。标准问数尽量调用确定性指标服务，异常诊断、归因和报告等复杂任务再进入多步分析流程，并保留关键执行过程供校验与追踪。

最终形成的是一套语义确定口径、元数据定位数据、权限控制访问、Agent 执行分析、证据支撑结论的协同体系。

常见误区

误区 1：SQL 能跑通，就说明 AI 问数是正确的

正解：SQL 可执行只是技术正确性。企业还需要验证指标定义、数据范围、维度和过滤条件是否符合用户真正的问题，否则仍可能得到“计算正确、业务错误”的答案。

误区 2：准确率达到 95% 就可以全面上线

正解：平均准确率会掩盖不同错误的风险差异。普通查询失败、核心利润指标错误和敏感数据越权的影响完全不同，因此生产评测需要结合错误类型和业务风险。

误区 3：模型越来越强，语义治理可以弱化

正解：模型越能自主执行复杂分析，越需要明确哪些规则不能由它自由判断。指标定义、数据权限和关键业务规则仍应由企业治理体系提供，模型主要承担理解、规划与推理。

典型场景

场景一：AI 查出的收入为什么和 BI 报表不一致？

某企业同时存在订单金额、开票收入和财务确认收入。业务人员询问“本月华东收入同比多少”时，如果 Agent 直接根据字段名称生成 SQL，很容易得到真实但口径错误的数字。通过 Aloudata CAN 统一管理不同收入指标及适用范围后，Agent 先匹配标准指标，再结合时间、区域和权限条件查询，存在多个合法定义时，则先完成消歧。这样解决的首先不是 SQL 怎么写，而是“这次业务问题应该使用哪个收入”。

场景二：为什么归因结果有数据支撑，却仍不能直接当作根因？

某零售企业发现销售额下降，Agent 进一步计算发现华东地区和某商品品类贡献了主要降幅，但贡献最大并不意味着它就是业务根因。Aloudata Agent 可以继续调用分析 Skill，从订单量、价格、客户和渠道等因素逐层验证，并保留中间数据和分析过程。最终将“数据事实”“主要贡献因素”和“待业务验证的原因”区分开，避免把统计关系直接升级为因果判断。

常见问题（FAQ）

Q1：为什么 AI 问数查出来的数字和 BI 报表不一致？

最常见原因是双方采用了不同指标口径、时间范围、过滤条件或业务维度，而不一定是 SQL 写错。排查时应首先比较 Agent 和 BI 实际使用的指标定义，再检查底层数据。统一指标语义可以减少不同分析工具各自解释业务指标的问题。

Q2：SQL 执行成功，为什么 Data Agent 的答案仍可能错误？

SQL 成功只说明数据库能够执行这条查询。Agent 仍可能选择错误指标、字段、Join 或业务范围，从而得到计算正确但业务含义错误的数字。因此企业不能只把 SQL 执行成功率作为问数准确性的判断标准。

Q3：如何避免 Data Agent 选错指标和字段？

指标公式和维度关系应通过语义层管理，表、字段和数据关系则通过元数据与血缘进行约束。Agent 首先匹配业务对象，再定位实际数据，而不是直接从大量 Schema 中猜测字段。存在多个合法解释时，应主动进行消歧。

Q4：Data Agent 如何避免越权查询？

权限需要在真实查询执行层生效，包括用户身份、角色、数据范围以及行列级访问控制。即使 Agent 生成访问敏感数据的 SQL，也必须由执行系统阻断。Prompt 中的安全要求只能作为辅助约束。

Q5：如何判断 Data Agent 的分析结论是否可信？

首先确认指标口径和数据来源，其次检查关键结论是否能回溯到查询结果和分析过程。对于归因问题，还应区分事实、贡献关系和因果判断。缺少数据证据的推断应明确标识，而不是包装成确定性结论。