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，而是模型引用的一个符号。
数据表现非常直观
这不仅仅是理论上的优雅；各家厂商测得的差距巨大且一致。
dbt Labs 在 2026 年针对一个建模后的保险数据集对这两种方法进行了对比测试。Claude Sonnet 编写原始 SQL 的准确率从 90% 提升到了通过语义层查询的 98%。GPT-5.3 Codex 从 84% 提升到了 100%。而隐藏在标题之下的发现更有趣：有了语义层访问权限，模型的选择变得几乎无关紧要。几乎每个模型都达到了近乎完美的准确率，因为最难的部分 —— 语义 —— 已经从模型的工作职责中移除了。
仓库厂商报告了同样的阶梯式增长。Snowflake 的 Cortex Analyst 要求提供将业务概念映射到 Schema 的 YAML 语义模型，其内部 BI 套件的准确率超过 90% —— 约为针对原始表的相同问题得分的两倍。Databricks 为其 Genie 助手记录了更明确的晋升阶梯：仅针对元数据时准确率为 53%，加入丰富描述后为 80%，只有在加入完整的指标定义和验证过的示例查询后才达到 100%。
还有一个结果值得关注，因为它关乎失败的形式，而非准确率。在 dbt 的基准测试中，当问题超出语义层所能回答的范围时，系统会返回明确的错误。而给定同样的超出范围的问题，Text-to-SQL 智能体则返回了一个自信的错误数字。对于任何用于董事会报告或审计的内容，这种差异 —— 响亮的失败 vs 静默的编造 —— 比准确率本身的差异更重要。
语义层优先反转了构建顺序
标准的企业级 AI 路线图通常是这样的：本季度交付一个数据聊天机器人，以后找时间清理指标层。但事实证明，你应该反其道而行之，其原因是架构性的，而非愿景式的。
如果 Agent 直接查询原始表，你所做的每一项改进都只能停留在提示词（Prompt）层面——包括粘贴到上下文中的 Schema 描述、few-shot 示例，以及随着两个团队独立调优而逐渐偏离的各 Agent 指令。提示词层面的修复不具备组合性，也无法迁移。而如果 Agent 查询的是语义层，每一项改进都是对共享定义的一个 Pull Request，每一个 Agent——无论是今天的聊天机器人、下季度的异常检测器，还是 CFO 的预测助手——都会同时继承这一改进。
这一领域的基础设施已迅速标准化。语义层现在都提供 MCP 服务端（MCP server）：dbt 将 list_metrics、get_dimensions 和 query_metrics 暴露为任何 Agent 都可以发现并调用的工具；Cube 和其他工具也在做同样的事情。Agent 会询问存在哪些指标，询问某个指标支持哪些维度，然后发布一个受治理的查询。发现、契约、执行——这是严谨意义上的工具 Schema，只不过被验证的“类型”是业务含义，而非整数或字符串。
这也重构了关于 ROI（投资回报率）的讨论。完成指标层建设过去常因竞争不过功能开发而搁浅，因为它的唯一回报是仪表板的一致性。而现在，它是你在这十年内将交付的每一个数据 Agent 的底座。半成品的语义层不再仅仅是 BI 债务，它是一个虚位以待的 Agent 平台。
在实践中，“语义层优先”并不意味着要对整个数仓大动干戈。从高管报表中出现的 20 个指标开始——即那些回答错误代价昂贵的指标。定义它们，通过支持 MCP 的语义层暴露它们，并将 Agent 约束在这个范围之内。对于那些回答错误也无伤大雅的探索性问题，保留原始的 text-to-SQL 能力，并在两者之间进行路由：当问题匹配已建模的范围时，使用受治理的指标；当不匹配时，使用自由格式的 SQL（并明确标注为未经验证）。这种混合模式正是基准测试作者们自己最终达成的共识。
你跳过它的迹象
要判断你的组织是否存在这个问题，有一个简单的诊断方法，而且大多数组织确实存在。
问两个不同的 Agent——或者同一个 Agent 在两个不同的会话中，或者你的聊天机器人和你的仪表板——同一个问题：“上季度的营收是多少？”如果你能得到两个不同的答案，那么你面临的不是 Agent 准确性问题。你面临的是术语未定义的问题，任何模型升级都无法解决它，因为歧义存在于你的数仓中，而非模型中。
人类也会遇到这个问题——每个数据团队都熟悉那种协调两个结果不一致的仪表板的“仪式”。但人类是以人类的速度、带着人类的怀疑态度遇到这个问题的，并且会向上反馈给指标所有者。而 Agent 是以规模化速度、带着生成的自信感遇到这个问题的，并且不会向任何人反馈。在分析师的吞吐量下，歧义只是偶尔的烦恼；而在 Agent 的吞吐量下，歧义变成了系统性污染：错误的数字流入摘要、流入下游自动化、流入决策，每一处都带有“数据表明”的隐含背书。
一个令人不安的结论是：数据 Agent 从来都不是真正的模型问题。模型在 SQL 方面的表现已经足够好有一阵子了；2026 年的基准测试显示，text-to-SQL 的准确率自 2023 年以来大约翻了一番，但仍然输给了一个连接到多年前定义的定义文件的语义层。Agent 时代真正要求的是数据团队一直以来应该做、却总能推迟的事情：在一个地方精确地决定业务术语的含义。你不能再推迟了。Agent 已经在回答问题了——唯一的问题是，它们是否都在查阅同一本字典。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
