Open Semantic Interchange: 为什么本体需要一个开放标准的指标体系

Agent 要稳定回答业务问题，关键不只是模型能力，还要有稳定的业务口径。自然语言直接映射到 SQL 容易受到歧义影响，语义层因此成为 Agent 与业务、数据库之间的“契约语言”：把收入、日活、留存等概念声明为可治理、可追溯、可执行的指标。

数据层统一并不等于指标统一。一个 Snowflake 客户的数据已经集中在同一数仓，业务语义却仍分别沉淀在 Tableau Semantics、LookML、StatSig metrics 和 Snowflake Semantic View 中。AB 实验、BI 看板、数仓开发和 Agent 问数如果使用不同定义，同一个业务指标就可能得到不同结果。

这一问题继续向上延伸：语义层不仅要统一指标，还开始成为 Ontology 的基础底座。

由此落到两个问题：如何在多引擎、多 BI、多方案并存的环境里得到可移植、可治理的语义层；以及在这套语义层之上，Ontology 如何组织实体、关系和业务规则，并被 Agent 消费。

01

先把语义层变成可以交换、执行和治理的工程对象

Semantic Layer、Semantic Model 和 Semantic View 对应不同层次。Semantic Layer 在物理表之上统一声明 measures、dimensions、relationships 和 time grain，让业务逻辑一次定义、多处复用；Semantic Model 用 YAML 等方式把实体、join、维度、度量和指标代码化，便于 review、diff 和版本管理；Semantic View 则把语义定义变成数据库内的一等对象，直接被 Analyst 或 Agent 消费，并继承仓库的 RBAC 权限治理。

各家的抽象非常接近：dbt MetricFlow 定义 entities、dimensions、measures 和 metrics；Snowflake semantic model 声明主键、维度、facts、metrics 和 synonyms；仓内对象侧又分别出现 Semantic View DDL 与 Metric View YAML。两类形态本质上都在声明表、关系、维度和度量，只是一个更偏 Git 中的工程文件，一个更偏数据库里的消费对象。名称和语法不同，但目标一致——让指标定义与 dashboard 解耦，让 Agent 面向稳定业务概念而不是裸 schema。

同一套语义也可以从代码定义转换为仓内对象，差别主要落在存储、权限与引擎绑定方式上。

真正的差异集中在落地层：Git 代码文件还是仓内对象、绑定单一引擎还是支持多引擎，以及 SQL 方言、join 关系和权限模型。共性足以标准化，差异又足以造成锁定，这正是 OSI 要抽取“最大公约数”的原因。

OSI 用厂商中立的 YAML 抽取语义层共性，核心类包括 Model、Datasets、Fields、Metrics、Dimensions 和 Relationships，并通过 converter 与 Snowflake、dbt 等格式转换。2025 年 9 月，Snowflake 联合 Salesforce/Tableau、dbt Labs 等发起这一项目，v1.0 于 2026 年 1 月 finalized。三类发起方分别对应数仓、BI 和第三方指标层。OSI 不替代现有语义层，而是提供一套可交换的中间规范，让每个平台只需与 OSI 对接，把 N×N 的适配关系降为 N。

OSI 的价值也不只是格式互转。不同 YAML 之间的转换脚本并不复杂，真正困难的是转换过程中能否保留语义。最大公约数之外仍有平台扩展，因此规范预留 custom extension；而一个 metric 也不只是文字定义，它可以同时成为 YAML、API、SQL 生成入口和 LLM tool。给出指标名称和可选维度后，语义层应能生成稳定查询结果，这才使跨系统复用成立。

一套稳定指标可以同时服务上卷、下钻、归因、预测和物化加速，也可以被数仓开发、BI 报表、AI 问数、AB 实验和人群圈选复用。稳定的维度定义让同一指标可以按时间、地区等维度上卷下钻，也能进一步做变化归因；带有时间维度的指标还可以进入预测流程，或基于指标定义建立物化结果进行加速。对 Agent 来说，查询从“临时生成 SQL"变成“指定指标与维度，由语义层生成稳定查询”。

OSI 也有明确边界。基础规范主要统一原子指标；多表 fan-out、粒度对齐、复杂 join，以及窗口、留存、漏斗等衍生语义仍由各引擎扩展。跨表时，直接 join 可能带来结果放大，需要通过 distinct、先聚合再 join，或先对齐粒度再关联等方式保证正确性。基础规范可以打通约 80% 的基础原子指标互通，剩余的跨表语义、衍生表达和加速能力属于引擎实现层。也就是说，跨系统真正需要共享的是核心口径；只在 AB 实验或某类引擎中使用的高级参数，可以继续留在各自扩展里。

因此，语义层还需要执行引擎，而不只是转换脚本。Datus OSI Engine 用 Rust 将 OSI YAML 依次转换为 Semantic IR、Logical Plan、SQL AST，再生成 Dialect SQL。这个过程本质上类似编译：先处理统一语义，再在物理执行层适配不同时间函数、join 能力和 SQL 方言，同时保证 fan-out 与跨数据源结果一致。其 parser 性能为 MetricFlow 的 10–20 倍，并支持 DuckDB、StarRocks、ClickHouse、Doris、TiDB、Trino、Postgres、MySQL、Snowflake、BigQuery、Databricks 等数据源。

02

Ontology 不是另起一套系统，而是从可信语义层上继续生长

在这套路径中，本体不是先于指标存在的一张大图。RDFS / OWL 更偏用 classes、properties、relationships 描述世界；面向 Agent 的 Ontology 则进一步组织 Object Types、Properties、Links，并可绑定 Actions、Functions 和安全机制。

以 Snowflake Ontology 为例，语义层先提供实体、指标和 join，本体再增加层级、同义和领域关系。图可以直接落在 KG_NODE 与 KG_EDGE 两张表中：前者保存实体 id、type 和属性，后者保存 src、dst、type 与元数据；多跳关系则通过 Recursive CTE 在仓内动态遍历。这样，本体并不一定要求额外挂一套图数据库，已有数仓也可以承担部分图遍历能力。

第一条路线是 Knowledge Graph + Semantic Model：Agent 在运行时调用图遍历工具，对 KG_NODE、KG_EDGE 做动态多跳探索，再把叶子节点落到 Semantic Model 生成 SQL。这一流程共编排 7 个工具，包括图遍历相关存储过程、语义视图等；运行时可动态展开层级，示例可覆盖 693 个后代、跨 10 层以上。它覆盖深、探索灵活，但工具更多，也更依赖 Agent 正确选择工具和概念名。

第二条是 Flattened GraphRAG + Semantic View：先用 Recursive CTE 聚合后代属性、名称、定义、同义词和邻居，形成概念画像，再建立关键词与向量索引；查询时只保留 Cortex Search 与 Cortex Analyst 两类核心工具，先检索概念画像，再基于 Semantic View 生成 SQL。在 22 道生物医学题的首答成功率对比中，Semantic View 基线为 50.0%，Knowledge Graph 为 60.0%，GraphRAG 为 70.0%，GraphRAG 加术语映射达到 78.2%。与运行时遍历相比，这条路线把一部分图探索提前预计算，以减少工具选择带来的方差。

足球示例展示了具体层与抽象层的关系。具体图包含 15 个俱乐部、41 名球员、11 名教练和 20 场比赛，以及 PLAYS_FOR、COACHES、PLAYED_IN、HOME/AWAY 等关系；上层再把球员和教练归并为 Person，把俱乐部抽象为 Org，把比赛抽象为 Event，并把关系合并成 WORKS_FOR、PARTICIPATES_IN。这样，同一批 KG_NODE / KG_EDGE 既能回答具体关系，也能支持跨类型的上层查询。

示例为 Agent 配置了 8 个工具：3 个 Cortex Analyst text-to-SQL 工具分别绑定不同 Semantic Model YAML；3 个图分析工具处理中心性、社区发现和最短路径；2 个 pandas 程序工具补充时序演化和转会网络分析。查询时，Agent 先在图中定位相关实体或关系，再调用一个或多个语义模型查询，必要时用程序工具汇总结果。本体被 Agent 消费，最终仍落在 context、工具选择和稳定语义模型执行上。

Action 可以继续作为另一类 tool 接入，例如操作 CRM、执行投放、触发审批或推动流程。本体负责组织业务对象及其关系，语义层负责给出可信指标，图工具负责关系探索，真正修改业务系统的动作仍通过独立、受控的工具完成。

OSI 0.2.0 Ontology Preview 将本体继续纳入规范。Apache Ossie v0.2.0.dev0（2026-05）包括 Concepts、Relationships、Business rules 和 Ontology mappings：Concepts 定义 EntityType、ValueType 及 extends 继承；Relationships 用 roles 与 multiplicity 描述关系，并通过 verbalizes 给出自然语言模板；Business rules 用 derived_by、requires 表达派生和约束；Ontology mappings 再把逻辑字段映射到 object、link、referent。指标统一“怎么算”，本体进一步统一“是什么、怎么连、怎么说”。

指标与本体叠加后，链路从数据开发、数据质量、指标开发，进入指标问数、Dashboard / Report 与指标归因，再继续延伸到更高层的洞察。区别在于，Agent 不再只针对单个指标取数，而是先沿业务实体和关系理解问题，再回到可信指标执行查询，由此形成跨指标、跨关系的分析结果；真正的动作仍通过受控工具完成。

03

真正难的不是画本体，而是让指标从工程过程中长出来

如果还没有成熟指标体系，冷启动可以从三类工程产物入手。第一，从历史 SQL 和调度任务中抽取贴近业务的表与 SQL，例如 ADS 层附近的业务表，识别事实表、维度表、关联关系和候选原子指标；第二，从历史 Dashboard 反解分析师已经长期使用的指标定义和下钻维度；第三，在新的数据开发过程中直接生成 Semantic Model 与 Metrics，让指标随开发持续沉淀。它们分别对应“已有 SQL"“已有消费结果”和“新增开发”三类入口。

关键不是 AI 能否写出 YAML，而是产物能否被验证：格式可 validate、定义可 query、结果可与原始 SQL 对比，也可以检查指标生成的图是否符合预期。只要定义能够被执行并与已有结果校验，Agent 就可以参与生成和维护；反过来，如果指标只是文本描述，无法转成 SQL、无法执行、归因和下钻，就很难形成稳定工程闭环。

纯 Top-down 的问题集中在两道坎：一是口径归属、优先级和责任边界容易在产生价值前陷入拉锯；二是生产端与消费端如果没有打通，指标目录与真实 SQL、Job 各行其是。结果可能只是一个定义完整、却没有进入真实使用流程的静态目录。

对应的治理方式是“像管代码一样管 SQL / Job / Metrics"：纳入 Version、PR、Review、Merge 和 Lineage，使修改可追溯、可回滚、可审计。个人 Workspace 可以先生成和使用项目级指标，这些指标可以快速变成报表、问数工具或 API；经过验证后，再经 PR 合并到公司级 Semantic Hub。生命周期从 Unverified、Verified、Certified 延伸到 Deprecated、Archived。只有 Certified 的指标才进一步进入监控告警，乃至预测等流程。

当指标进入工程治理流程后，下一步就是把个人或项目级产物逐步晋升为组织级资产。

Bottom-up 并不是拒绝统一，而是改变顺序：先允许指标在 Project / Workspace 级落地和使用，让它被真实查询反复验证，再通过 PR、Review、Merge 逐步收敛为 Enterprise 指标资产。这样，统一发生在价值已经被验证之后，而不是在使用之前。Ontology 也不是顶层一次性手工画完，而是由这些已经被业务使用、被工程验证的 Metrics 逐步“长”出来。

最终可以收束为三点：语义层是 Agent 的契约语言；OSI 用厂商中立的最大公约数降低跨平台语义适配；落地上先交付、再统一，让 Metrics 先成为可执行、可验证、可治理的工程资产，再从中生长 Ontology。

点个在看你最好看

SPRING HAS ARRIVED