https://www.youtube.com/watch?v=Ooan6cErKCM
演讲者 Taja（Snowflake 首席 AI 架构师）在 Snowflake Summit 2026 上以 《Ontology on Snowflake: How to Make AI Actually Understand Your Data》 为题进行了分享 [01:17]。
核心主题是：Enterprise AI 构建的难点不在于模型或算力，而在于 AI 无法真正理解业务语义 [00:13]。通过在 Snowflake 上原生构建本体（Ontology），可以为 AI Agent 提供结构化的业务语义层，使其从“对原始数据做 Join 查询”跨越到“对业务概念进行推理” [03:15]。
演讲的详细内容可分为以下核心部分：
1. 核心痛点与基本概念区分
- 为什么 AI 会瞎编？ 数据库里只有表、外键和加密列名，而现实世界运行的是对象（人、团队、合同等）及其相互关系 [02:26]。直接把原始表喂给 AI，会导致编写出极其复杂的 SQL、逻辑重复，以及 AI 极其自信地给出错误答案 [03:03]。
- 本体（Ontology） vs 知识图谱（Knowledge Graph）：
- Ontology 是蓝图（Blueprint）： 规定允许存在哪些类和关系（例如：“人”可以为“组织”工作，“球员”是一种“人”） [03:44]。定义一次，极少变动 [04:04]。
- Knowledge Graph 是建筑（Building）： 根据蓝图构建的具体事实（例如：“姆巴佩”是“球员”，效力于“皇家马德里”） [04:13]。事实会随转会窗口频繁变化 [04:24]。
- 核心原则： 本体定义关系规范，知识图谱实例化具体事实 [05:03]。两者解耦存储与查询 [05:03]。
2. Snowflake 上的五层原生架构
演讲者提出了“事实只存一次，语义定义为配置，智能通过协同调度”的五层设计 [05:28]：
-
Layer 1: 基础物理存储 (Nodes & Edges Table)
仅用两张基本表：
Nodes表存储所有存在的事物，Edges表存储事物间的连接，均采用 Variant 列设计 [08:04]。新增实体类型（如裁判）时无须修改 Schema，直接插入即可 [08:35]。 - Layer 2: 本体元数据配置 (Ontology Metadata) 纯声明式配置（无须写代码），定义继承树（如“球员”和“教练”继承自“人”）和约束关系 [09:02]。业务逻辑发生变化时，仅需新增一行元数据 [09:45]。
- Layer 3: 自动编译器与视图生成 (Compiler & Generated Views) 通过存储过程自动读取 Layer 2 的元数据，编译生成多态统一视图（如自动将球员和教练合并为抽象概念“人”） [10:04]。下游零代码修改 [10:42]。
- Layer 4: 三向专用语义模型 (3 Purpose-Built Models)
- 知识图谱模型（Concrete）： 适用于极速、具体的具体属性查询（如“谁效力于皇马”） [11:22]。
- 本体模型（Abstract / Polymorphic）： 适用于跨类型的多态抽象推理（如“谁在皇马工作”，可同时返回球员和教练） [11:44]。
治理模型（Governance）： 用于系统自述，控制权限与模型范围 [11:53]。
Layer 5: Cortex Agent 协调调度层
作为脑部大脑（Conductor），对自然语言问题进行意图识别，调度最合适的语义工具或图遍历引擎，合并结果返回 [13:06]。
3. 自动化部署工具：Ontology Stack Builder
为了解决搭建 5 层架构的复杂性，Snowflake 推出了 Ontology Stack Builder（Koko Skills 工具） [14:29]：
- 交互式工作流： 自动分析数据表 Schema，推荐类与关系 [14:38]。
- 可视化编辑： 提供可视化图编辑器，支持拖拽节点、绘制关系并检查覆盖率 [14:56]。
- 一键生成部署： 确认设计后自动生成 SQL、部署 Layer 1-3 视图，并配置 Cortex Agent [15:05]。
- 人机协同（Human-in-the-loop）： 7 个校验关卡（Gates），将以往需要数周/数月的搭建过程缩短至 1 小时内完成 [15:24]。
Top comments (0)