Agent查数总用错表、算错口径，怎么解决？

-- 给表打上“Agent 可用”的认证标记，只有认证表进入 Agent 的检索范围
CREATE TABLE meta_table_certification (
  table_name      STRING,     -- 库名.表名
  layer           STRING,     -- ods/dwd/dws/ads
  cert_level      STRING,     -- gold(认证) / silver(可用) / hidden(不可见)
  grain           STRING,     -- 粒度：一行代表什么，如"一个订单一行"
  primary_keys    STRING,     -- 主键，帮助 Agent 判断能否直接 COUNT
  partition_col   STRING,     -- 分区字段，必须过滤
  owner           STRING,     -- 负责人
  description     STRING,     -- 面向 Agent 的用途说明
  not_for         STRING,     -- 不适用场景，如"不要用于财务对账"
  updated_at      TIMESTAMP
);
-- 原则：Agent 默认只能看到 gold 表；silver 表仅在长尾查询时作为候选

注意 grain（粒度）和 not_for（不适用场景） 这两个字段。粒度是 Agent 正确做聚合和关联的前提；“不适用场景”这种负向信息，往往比正向描述更能防止误用。

展开三：语义层——给 Agent 一本口径字典

语义层的本质是：把散落在各个报表 SQL 里的业务逻辑抽出来，统一定义一次。它对人和对 Agent 都有价值，但对 Agent 尤其关键，因为 Agent 没法靠“问同事”来消除歧义。

# 语义层定义示例：实体、指标、维度
entities:
  - name: order
    table: dws.dws_trade_order_d
    grain: 一个订单一行
    primary_key: order_id
    joins:
      - entity: user
        on: order.user_id = user.user_id   # 多对一，不会放大行数
metrics:
  - name: gmv
    synonyms: [成交额, 交易额, 流水]       # 帮助召回
    expression: SUM(pay_amount)
    default_filters: [pay_status = 'SUCCESS', is_test_user = 0]
    description: 支付成功订单金额，含运费，不扣退款；已排除测试账号
    certified: true
dimensions:
  - name: region
    values_source: dim.dim_region           # 维度取值从维表同步，用于枚举匹配

这里有三个细节是数据开发特有的经验：

• synonyms 同义词：业务说“流水”“交易额”“成交额”，指的都是 GMV。没有同义词，检索就召回不到。

• default_filters 默认过滤：测试账号、内部账号、作废订单这类“隐性规则”必须写死，不能指望 Agent 每次都记得。

• joins 关联关系和基数：明确是多对一还是一对多，Agent 才不会 Join 出翻倍的数据。

展开四：隐性知识——few-shot 和踩坑说明

语义层覆盖的是“结构化的口径”，还有一部分知识是非结构化的：某张表 2024 年之前的数据口径不一样、某个字段在某个渠道是空的、某类问题的标准写法。这些知识我会整理成两类上下文资产：

资产	内容	怎么用
Few-shot 问答库	真实问题 + 标准结构化意图/SQL + 结果	按问题相似度检索 3-5 条放进上下文
数据注意事项	字段陷阱、历史口径变更、已知数据问题	和相关表/指标绑定，召回时一起带出
业务术语表	业务黑话和标准概念的映射	问题理解阶段做术语归一

实战经验：埋点治理就是在为 Agent 做准备

我在某出海硬件品牌做过一次埋点治理，把 1000 多个事件精简到 100 多个标准化事件，数据质量问题减少了 60%。当时的问题和今天 Agent 查数的问题几乎一模一样：同一个行为有好几个事件名，不同版本 App 的字段含义不一样，分析师查数前要先问一圈“这个事件到底什么意思”。

那次治理我们做了三件事：统一事件命名规范、为每个事件和属性写清楚定义和触发时机、废弃重复事件并做映射。这三件事放到今天，正好对应收敛可见范围、建设语义定义、沉淀映射关系。所以面试时我会说：给 Agent 用的数据治理并不是全新的东西，它是数据治理的延续，只是标准更高了——人能容忍的模糊，Agent 不能容忍。

追问链

追问一：语义层要覆盖多少指标才够？一开始全量建吗？

不要一开始全量建，那样会变成一个永远做不完的项目。我会按需求频率排序：先从历史取数工单和看板访问记录里统计最常被问的指标和维度，优先覆盖头部。通常头部一小部分指标就覆盖了大部分提问。先把这部分做到认证级别，上线跑起来，再根据未命中的问题逐步扩展。

追问二：语义层和指标平台是什么关系？

可以理解为同一件事的不同侧面。指标平台更偏管理：指标的申请、审批、负责人、上下线；语义层更偏使用：指标怎么计算、能和哪些维度组合、怎么编译成 SQL。很多公司是一套系统同时承担两个角色。对 Agent 来说，重要的是它能通过 API 或 MCP 实时读到最新、已认证的定义。

追问三：怎么证明你的治理有效？

用同一份评测集做前后对比：治理前准确率多少，收敛可见范围后多少，加了语义层后多少，加了 few-shot 后多少。每一步的增量都能看到，既证明了效果，也能指导下一步该投入在哪里。线上还要看用户纠错率和人工兜底率的趋势。

加分说法 vs 减分说法

✔ 加分说法	✘ 减分说法
先做错误归因，大部分问题在数据侧	优化一下提示词就好了
收敛可见范围，表分级认证	换更强的模型
语义层：同义词、默认过滤、关联基数	把所有表结构都给 Agent
沉淀 few-shot 和数据注意事项	语义层一次性全量建完
用评测集量化每一步治理的增量	没有度量，说不清治理效果

怎么挂到你的项目上

话术模板：“我会先把答错的案例做归因，通常大部分问题出在数据侧，比如选错表、口径不一致、隐性过滤规则遗漏。然后分三步：收敛 Agent 的可见范围，只开放认证表；建设语义层，统一口径、同义词和默认过滤；沉淀 few-shot 和数据注意事项。我之前做埋点治理时，把上千个事件收敛成一百多个标准事件，思路是一样的。”

总结

这道题的核心观点是：Agent 用错数据，大多是数据没有为 Agent 准备好。解法是收敛范围、统一口径、沉淀隐性知识，并用评测集证明效果。这道题是数据开发在 Agent 面试里最能体现专业壁垒的一题，一定要用你真实做过的治理经历来回答。

下一篇聊安全：让 Agent 直接连数仓，怎么防止它跑出全表扫描、误删数据、越权查询？

你们数仓里有多少表是“只有写它的人才知道怎么用”的？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长