Data Agent 如何真正读懂“客单价”

Mon, 28 Sep 2026 00:00:00 +0000

“近 30 天各品类的客单价是多少？”模型很容易写出语法正确的 SQL，也很容易在业务上完全错掉。客单价可能是支付金额除以支付订单数，也可能排除退款、按买家数计算，或者只看签收订单。

这不是 SQL 技巧问题，而是业务术语尚未绑定到可执行语义。

一个指标至少有五组约束

实体与人群定义谁被统计；分子和分母规定公式；时间说明事件时间、窗口和时区；粒度决定按订单、用户还是商品聚合；有效期和版本说明这套口径何时生效。

指标名只是入口，指标契约才是可执行对象。契约还应包含允许关联、默认过滤、空值处理、Owner、验证查询和已知例外。

为什么需要读取代码和元数据

数据开发代码包含真实的派生、过滤和关联逻辑，表元数据描述字段、分区和血缘。二者结合可以生成语义模型草稿，再由业务和数据 Owner 编辑确认。只读 Schema 很难发现“已支付但未取消”这样的隐含条件。

阿里云 DataWorks 的相关路线值得关注，正因为它把语义生成放在数据开发与分析工作流之间：语义不是旁边的一份说明文档，而是 Agent 查询时要加载的约束。

生成语义模型后还要验证

可编辑 YAML 或其他语义定义只是载体。上线前应使用已知问句与可信查询做双向测试：同义表达是否绑定同一指标；边界日期是否一致；跨表 Join 是否改变粒度；新版本是否破坏历史结果。

一个可落地的最小闭环

先从十个高频指标开始，提取代码与元数据，生成草稿，由 Owner 确认后写入版本化语义仓库；查询时记录命中的指标版本；结果异常时，把修正回写为新的测试，而不是临时提示词。

Data Agent 真正理解“客单价”，不是因为模型见过这个词，而是因为词被绑定到了有版本、有 Owner、可验证的计算契约。

语义层还需要运行时观测

上线后应统计每个指标契约被哪些问题命中、哪些同义词频繁无法解析、哪些查询在 Join 后产生异常膨胀，以及用户在哪些答案上反复追问。它们能揭示语义定义缺口，比单纯统计问答满意度更接近根因。

契约变更也要区分兼容更新与破坏性更新。增加一个同义词通常可以直接发布；改变分母、默认过滤或时间窗口，则需要新版本、影响分析和历史回放。语义层不是一张静态指标表，而是一套面向 Agent 执行的变更管理系统。

对跨部门指标，还应显式声明适用组织与展示名称，避免销售口径覆盖财务口径。若用户问题没有足够信息选择版本，Agent 应展示候选定义并请求确认，而不是依赖语料中的多数用法替用户决定。

语义命中记录也可以反哺治理：高频歧义进入术语清单，反复失败的 Join 进入禁止规则，常用且稳定的问句沉淀为验证样例。每次失败都应改善契约，而不是只修补当次回答。

参考：阿里云 DataWorks 产品文档

Agent 越强，为什么越需要语义层

Tue, 08 Sep 2026 00:00:00 +0000

把订单表、支付表和客户表的 Schema 交给模型，它很快就能写出一条可运行的 SQL。可当用户问“上个月收入是多少”，真正的问题才开始：收入是下单金额、实收、净收款还是财务确认收入？按下单时间还是确认时间？退款归属哪个月？

这些不是模型应该自由推断的常识，而是企业自己的业务合同。Agent 能力越强、执行链越长，一个错误定义被传播到报告和动作中的代价就越大。

Schema 描述数据的形状；语义层规定数据在什么条件下代表什么事实、允许怎样聚合。模型可以帮助发现冲突、起草定义，却不能替指标负责人决定口径。

语义层、本体和目录各管什么

资产目录回答“有什么、在哪里、谁负责”；语义层回答“怎么算、能按哪些维度分析”；业务本体回答客户、账户、订单等概念如何识别和关联。执行与治理系统则强制实施权限、预算和审计。

本体不一定要从复杂知识图谱起步。一个受治理的实体关系模型，能明确主键、基数、有效期和身份映射，就已经解决很多 Join 放大和概念混用问题。重要的是定义可引用、可版本化、可被查询编译或验证，而不是图画得多复杂。

六类语义资产缺一不可

资产	至少要明确	缺失后的典型错误
指标	公式、单位、时间口径、粒度、聚合、版本、负责人	把支付金额当确认收入；比率直接平均
实体	主键、唯一性、关系方向、基数、有效期	一对多 Join 放大金额；账户与客户混用
维度	层级、合法取值、适用指标、历史归属	用当前地区解释历史业绩
同义词	业务域、语言、候选概念与不可等同项	把营收、销售额和回款无条件合并
业务规则	状态过滤、币种、财务周期、用途、生效区间	测试订单进入正式报表
验证样例	问题、口径、查询、快照、预期结果、验证人	旧 SQL 被当成永久正确答案

这些资产可以分布在词汇表、指标服务、目录和样例库中，但必须通过稳定 ID 与版本关联。复制多份自然语言说明，通常只会制造新的漂移。

“收入”案例：先绑定定义，再写 SQL

假设团队同时维护交易总额、实收金额和财务确认收入。用户只说“收入”时，可靠流程是：

检查当前报表或会话是否已绑定某个指标；没有明确上下文就澄清。
将“上个月”转换为指定时区的具体区间，确定支付时间还是确认时间。
读取退款、税费、币种和内部账户排除规则。
先形成指标、维度、过滤与版本组成的语义计划，再编译查询。

一个最小指标契约可以长这样：

{
 "metric_id": "commerce.period_net_receipts",
 "version": "1.0",
 "definition": "期间成功收款减期间成功退款",
 "expression": "sum(receipt_cny) - sum(refund_cny)",
 "time_fields": {"receipts": "paid_at", "refunds": "refunded_at"},
 "timezone": "Asia/Shanghai",
 "grain": "calendar_day",
 "unit": "CNY",
 "allowed_dimensions": ["channel"],
 "missing_input_policy": "unknown_not_zero",
 "effective_from": "2026-08-01",
 "test_suite_ref": "tests/net-receipts-v1"
}

缺失输入记为未知，而不是零；退款与收款应先按兼容粒度聚合，再对齐计算，不能直接连接两张明细表造成乘积。最终答案还应带出采用的指标版本、时间字段、数据水位和限制。

语义如何进入运行链路

语义资产只有进入执行与验证，才不只是文档：

指标管理 on DataAgentX