Text-to-SQL 不是难点，Text-to-正确的-SQL 才是

一个开放标准正在试图解决 AI Agent 时代最被忽视的问题：你的数据到底是什么意思。

每个做数据的人都经历过这个场景。

周一例会。市场部说月活涨了 12%，产品部说持平，财务部说跌了 3%。三个团队都没有编数据——市场部统计打开过 App 的人，产品部只统计做过关键操作的用户还要排除测试账号，财务部算的是付费席位而且管道滞后一周。

同一个"月活"，三个定义，三种结果。接下来的 40 分钟不是在讨论怎么应对 12% 的增长还是 3% 的下跌，而是在争论到底哪个数字是真的。

这个问题叫语义漂移（Semantic Drift），数据行业已经忍了几十年。

然后 AI Agent 来了。

● ● ●

人类分析师会去问同事，Agent 只会自信地选一个

一个 Agent 被问到"计算这个季度的客户流失率"。

它在仓库里看到了三张表——churn_events、subscription_cancel、account_status_changes——每张表描述的都是"流失"，但口径不同。它找到了几个看起来合理的公式，选了其中一个，自信地返回了一个数字。

人类分析师碰到这种情况会去隔壁问同事——"哪张表是对的？" "这个要排除试用期用户吗？" "退款算不算流失？"

Agent 不问。它直接给你一个答案。这个答案看起来完全正确——计算过程清晰，格式漂亮——只是基于一个没人背书的公式。

Text-to-SQL 从来不是难点。Text-to-正确的-SQL 才是。

这是语义问题，不是技术问题。

dbt Labs 内部测试过这个：自然语言查询在背后有治理过的语义层支撑时，准确率大约 83%。LLM 直接对着数据库 Schema 写 SQL——40%。

这 43 个百分点的差距，就是 AI 时代语义漂移的真实成本。它不再是"报表对不上"的烦恼，而是 Agent 在给 CFO 编数字的风险。

● ● ●

每个工具都在说自己的方言

语义层不是新概念。

BI 厂商已经做了几十年——Looker 有 LookML，Tableau 有计算字段，Power BI 有度量值。dbt 让指标定义成了代码仓库里的一等公民。Cube 把语义层做成了一个 API 服务。

问题是：每个工具说自己的方言。

你在 BI 工具里定义的"收入"，你的 dbt 项目里定义的"收入"，你的 CRM 里定义的"收入"——它们不是同一份文件，不在同一个仓库里，不受同一个变更流程约束。一个工具的语义定义，另一个工具读不了。它们悄悄漂移。然后你周一例会争论谁的数字是真的。

更糟的是，业务逻辑被锁在每个工具的专属格式里。离开任何工具等于重写公司的"大脑"——这是比任何数据格式都更深的锁定。

● ● ●

一个叫 Apache Ossie 的项目想做 Parquet 对数据做的事情，但对含义

Parquet 做了什么？它是一个共识：列式数据应该这样排列。任何工具——Spark、DuckDB、Pandas——都能读写同一个 Parquet 文件，不需要翻译。

Ossie 想做同样的事，对象是语义模型。

它是一个 JSON/YAML 格式的规格。你定义：

• 数据集：有哪些表、字段从哪里来
• 关系：Customer_Code 和 Account_UID 是同一个人，订单属于客户
• 指标：月活的公式是什么，排除哪些账号，时间窗口多大
• AI 上下文：给 Agent 的额外信息——"这个指标的同义词有 MAU、月活跃用户""注意：试用期用户不计入"

写好的 YAML 文件放在 Git 里。任何工具——BI 工具、数据目录、AI Agent——只要理解 Ossie 格式，就能直接读出这些定义。不需要翻译，不需要猜，不需要去隔壁问同事。

Ossie 不替代你的 BI 工具或 dbt 项目。它是它们能互相理解的翻译层。

● ● ●

这个规格凭什么不是另一个没人用的标准？

历史上有大量设计精美的语义标准死于无人问津——OWL、RDF、SPARQL，在学术和政府之外几乎零采用。

但 Ossie 有两个不同。

第一，AI Agent 是真正的推动力。 语义 Web 当年要求企业投入大量精力，只是为了搜索引擎能稍微好一点——ROI 不成立。Ossie 要求企业做类似的投入，但回报不同：你的 Agent 返回的财务数据是不是 CFO 认可的那个数字？从 40% 到 83% 的准确率差距，不是抽象的。

第二，治理结构。 Ossie 的前身是 Snowflake 2025 年发起的 Open Semantic Interchange。Snowflake 召集的、Snowflake 开源的——但一个"厂商中立"的交换格式由一个厂商控制，这在结构上就无法被信任。不是说 Snowflake 会做什么，而是其他厂商必须预防那种可能性。

2026 年 6 月，项目正式进入 Apache 软件基金会，改名 Apache Ossie。商标归基金会，发布需要社区投票，提交者资格靠贡献获得而非雇主分配。dbt Labs、Dremio、Databricks、Salesforce、ThoughtSpot 等 50 多家组织已经参与——包括彼此直接竞争的对手。

一个标准是否真实，最准的信号是：竞争对手是否在里面？ 在 Ossie 这里，是的。

● ● ●

问题不在规格，在组织

Ossie 当前还只是一个 v0.1 规格，处在 Apache 孵育阶段。生产工具链还没就绪，最难的技术问题——跨方言的可移植表达式、时间语义、概念级别的本体对齐——都在工作组里设计中。

但更根本的问题不是技术。

规格解决不了所有权问题。 在你能写出 Ossie 格式的 YAML 之前，你需要先回答一个更简单也更困难的问题：公司前 20 个业务指标，谁负责定义？上次正式审查是什么时候？"收入"在多少个系统里有多少个版本？

对大多数企业，答案是"不知道"。

正确的顺序是：先搞清楚你有什么、统一它们、再用 Ossie 表达、然后建立持续的变更治理流程。 跳过前三步直接到第三步——你用新格式编码了现有的混淆，这比现状更糟，因为它看起来像在进步。

● ● ●

什么时候可以用

2026 年的正确姿态：跟着看、动手试、贡献代码，不是搞迁移。

如果你负责数据或分析团队，现在可以做三件事：

1. 01盘点你的指标定义在哪里——不是"大概在 BI 工具里"，是精确到文件路径
2. 02把最重要的 20 个指标精确写下来，放进版本控制
3. 03如果已用 dbt，可以试合并的 Ossie 转换器，今天就体验中立语义模型

语义债务按日复利。在 Agent 需要它的那天到来之前，每还一点都更值。

语义漂移是数据团队信誉上最安静的税。

每份报告、每个仪表板、每次你告诉业务方"这个数字和上次不一样是因为定义改了"——都在付这个税。几十年来我们付了，因为够便宜。

AI Agent 让这个税开始变贵了。

Apache Ossie 可能不会成为"统一业务语言"——真正的统一需要人和组织的共识而非纯技术规格。但它极有可能成为 AI Agent 的"统一交换格式"，而这已经是整个行业等了十年的事。

Apache Ossie：github.com/apache/ossie | 官网：ossie.apache.org

你经历过"同一个指标三个部门三个数字"的场景吗？当时是怎么解决的？评论区聊。