你的数据 Agent 需要一个统一的营收定义

Text-to-SQL 演示从不会因为语法而失败。模型生成的 SQL 非常流畅 —— 说实话，比大多数初级分析师写得都好 —— 查询可以运行，并且返回了一个数字。演示在三周后的生产环境中宣告失败，因为 CFO 注意到智能体的 “Q2 营收” 与董事会报告不符。这不是因为 SQL 格式错误，而是因为数据仓库中有三种说得通的营收定义 —— 预订额 (bookings)、已确认营收 (recognized) 和扣除退款后的净值 (net-of-refunds) —— 而模型自信地选择了其中一个。恰恰不是财务部门使用的那一个。

这是最关键的失效模式，而且在你见过的每一个基准测试中都是不可见的。解决方案不是更好的模型或更长的提示词。而是一项大多数数据团队已经构建了一半然后放弃的基础设施：语义层 (semantic layer)。你为 BI 仪表板编写的指标定义 —— dbt metrics、LookML、Cube 定义 —— 事实证明是数据智能体缺失的工具契约。交付可靠智能体的团队意识到，构建顺序与大家的假设恰恰相反：语义层优先，智能体随后。

语法从来不是瓶颈

学术数据讲述了一个诱人的故事。在前沿基准测试 Spider 1.0 上，前沿模型得分超过 90%，在 BIRD 上得分约 73%。看着这些排行榜，你会得出结论：问题已基本解决。

接着 Spider 2.0 出现了 —— 它基于真实的商业工作流构建，拥有庞杂的 Schema、多种 SQL 方言，以及现实公司中普遍存在的文档债 (documentation debt)。最强的推理模型得分仅为 21% 左右。纸面上是同样的任务，但在实践中得分下降了 70 分。这两个数字之间的差距，正是 “编写 SQL” 与 “理解数据含义” 之间的差距。

这是因为生产环境的数据仓库不是一个 Schema，而是一个考古遗址。这里有 orders、orders_v2 和 orders_final_DO_NOT_USE。有一个早于退款政策的 revenue 列，还有一个只有部分团队知道其存在的 net_revenue 列。人类分析师通过隐性知识 (tribal knowledge) 在这种环境中生存 —— 他们知道财务团队认可哪张表，他们记得重新协商 “活跃用户” 定义时的 Slack 对话。模型完全没有这些信息。它只有列名和先验知识，并用自信的猜测填补语义空白。

这种失效模式最残酷的特性在于：微小的语义错误不会导致崩溃。错误的连接 (join) 或错误的聚合粒度会返回一个看起来合理的数字，格式精美，并以一种完全不知道自己错了的系统所特有的冷静权威感交付。静默且可扩展的错误是最昂贵的一类，因为你不会在日志中发现它 —— 而是在会议上发现它。

你已经构建了一半的指标层

这里的反转在于：大多数数据团队已经拥有了解决这个问题的产物。在你的 dbt 项目、LookML 文件或 Cube 配置中的某个地方，已经有人写下了 “营收” 的含义 —— 精确的聚合方式、精确的过滤器、精确的连接路径 —— 因为早在智能体出现之前，仪表板就需要统一的答案。

那个指标层通常是在极不情愿的情况下构建的，仅被部分采用，并在仪表板迁移失去动力时停留在 60% 的覆盖率。它被视为 BI 的管道工程。但看看它本质上是什么：一份关于你业务的机器可读的本体 (ontology) —— 指标、维度、实体及其相互关系，由对数据负责的人员进行版本控制和维护。

这就是一个工具契约。它正是智能体所需要的形态。

当你将受治理的指标（而不是原始表）暴露为智能体的查询界面时，分工发生了根本性的变化：

• 模型做它擅长的事：将模糊的自然语言问题分解为结构化请求 —— 某个指标，按某个维度分组，过滤到某个时间段。
• 语义层做编译器擅长的事：确定性地从结构化请求中生成正确的 SQL。连接是预先声明的。聚合粒度是编码好的。模型不需要即兴创作业务逻辑。
• 组织做组织必须做的事：在可评审的文件中，就词汇的含义达成一次性共识。

智能体继承了组织公认的定义，而不是在每次查询时重新推导。“营收” 不再是模型解释的一个 Token，而是模型引用的一个符号。

加载中…