本体论在数仓 Data Agent 中的应用

一、本体论是什么

本体论（Ontology）源自哲学，在计算机领域指对某个领域知识的形式化、结构化表示。它回答的问题是：这个领域里存在哪些东西、它们之间有什么关系、有哪些规则约束。

一个本体由四类要素构成：

概念（Class）：领域中存在哪些实体，例如"订单"、"用户"、"商品"、"GMV"
关系（Relation）：概念之间如何关联，例如"用户下单订单"、"订单包含商品"
属性（Property）：每个概念有哪些属性，例如"订单"有"金额"、"状态"、"下单时间"
规则（Rule）：业务约束和推理规则，例如"GMV = 成交金额，不含退款"

本质：把人脑里的业务知识变成机器可以理解和推理的结构。

二、本体论解决什么问题

在数仓 Data Agent 场景中，用户用自然语言提问，AI 需要生成 SQL 去查数据库。这中间存在一道"语义鸿沟"------用户说的话和数据库里的字段名之间，隔着大量隐性的业务知识。本体论就是用来填平这道鸿沟的。

七类具体问题

问题类型	没有本体论时	有了本体论后
同义词	用户说"销售额"，找不到对应字段	自动映射到 `paid_amount`
歧义	用户说"用户数"，随机猜一种定义	明确是 DAU / MAU / 注册用户数
隐性过滤规则	忘记过滤测试订单、退款订单	自动加上 `order_status = 'paid'` 等条件
表关联路径	JOIN 条件写错，或不知道该 JOIN 哪张表	从关系图中查找正确的关联路径
指标口径	留存率、转化率的算法自己发明	直接调用标准定义和 SQL 模板
意图理解	只返回原始数字	自动附带趋势对比、同比环比
知识传承	业务知识在人脑里，人走知识走	知识在系统里，持续积累，不随人员流动丢失

本体论解决不了什么

数据质量问题（数据本身有错，本体论管不了）
极度开放的探索性分析（没有明确意图的问题）
本体本身的维护成本（业务变化时需要同步更新，这是持续投入）
LLM 本身的推理局限（本体论是知识底座，不是万能药）

三、四个应用层次

第一层：数据字典本体（解决语义鸿沟）

把每个业务术语和数据库字段之间的映射关系显式化。

yaml 复制代码

概念：GMV（成交总额）
  同义词：trade_value, order_amount, paid_gmv, 成交额, 销售额
  业务定义：用户实际支付金额，不含退款，含运费
  对应字段：dw.fact_order.paid_amount
  计算口径：SUM(paid_amount) WHERE order_status = 'paid'
  注意事项：需过滤测试账号（is_test = 0）

这一层是最基础的，也是 ROI 最高的。即使只做这一层，也能显著提升 Schema Linking 的准确率。

第二层：指标本体（解决业务规则盲区）

把核心指标的完整定义、计算口径、注意事项都结构化存储。

yaml 复制代码

指标：DAU（日活跃用户数）
  定义：当日有登录行为的去重用户数
  去重维度：user_id（账号维度，非设备维度）
  时间口径：自然日 00:00:00 - 23:59:59
  注意事项：不包含机器人账号（is_robot = 0）
  SQL模板：
    SELECT dt, COUNT(DISTINCT user_id) as dau
    FROM dw.fact_user_login
    WHERE dt = '${date}' AND is_robot = 0
    GROUP BY dt

第三层：关系本体（解决跨表关联困难）

把表与表之间的关联关系、JOIN 路径显式化。

yaml 复制代码

实体：订单（fact_order）
  关联用户（dim_user）via user_id
  关联商品（dim_product）via product_id
  关联商家（dim_merchant）via merchant_id
  上游来源：ods_order（通过 ETL 任务 job_order_etl）
  下游依赖：dws_gmv_daily, dws_order_summary

第四层：推理规则本体（实现智能意图理解）

把分析模式和业务推理规则编码进去，让 Agent 能理解更复杂的意图。

复制代码

规则：如果用户问"同比"，则自动计算去年同期数据并做对比
规则：如果用户问"为什么下降"，则触发归因分析流程（拆维度、找异常）
规则：如果用户问"漏斗"，则按标准转化步骤生成多步 SQL
规则：如果问题涉及"留存"，则使用留存率标准计算模板

四、成熟实践案例

案例一：Palantir Foundry（商业产品级）

Palantir 的核心产品理念就是本体论驱动。他们把企业所有数字资产映射为业务对象（Object），形成企业数字孪生。

核心设计：

每个业务实体（飞机、患者、订单）都是一个 Object，有属性和关系
Object 之间的关系构成企业级知识图谱
AI 在这个图谱上工作，而不是直接面对原始数据库

Palantir CEO 公开表示"本体工程是 AI 落地的关键"。在军方、制造业、金融机构有大量落地案例，是目前商业化最成功的本体论 + AI 实践。

案例二：B站数仓智能化（国内大厂实践）

B站用 Neo4j 图数据库 存储数仓知识图谱，通过 MCP 协议 让 LLM 按需动态查询，在 1.1 万个任务、10 万个字段的数仓上实现了 80% SQL 生成准确率。

核心设计亮点：

子图挂载（Sub-graph Mounting）：不把整个图谱塞进 Prompt（万级表规模下会导致语义漂移），而是以"锚点表"为中心，按需拼凑局部上下文。Agent 先查图谱找到相关的 3-5 张表，再把这个局部子图作为上下文传给 LLM。

历史 SQL 基线：不让 AI 从零生成 SQL，而是拉取历史生产 SQL 作为基线，让 AI 做增量修改。这一个策略能继承所有沉淀在历史代码里的隐性业务规则，是提升准确率最有效的单一手段。

MCP 协议接入：图数据库通过 MCP（Model Context Protocol）暴露为工具，LLM 可以像调用函数一样查询图谱，实现"按需取用"而非"全量注入"。

五、如何在数仓 Data Agent 中落地

判断是否需要引入本体论

复制代码

数仓规模 < 100 张表    → 暂时不需要，Prompt + 元数据描述够用
数仓规模 100-1000 张表 → 建核心指标本体，ROI 合理
数仓规模 > 1000 张表   → 本体论是必选项，否则 Agent 准确率很难上去

渐进式建设路径

第一步（1-2周）：整理核心指标定义

从最高频的 20-30 个指标开始，把每个指标的同义词、计算口径、注意事项写清楚，存入结构化文件（YAML/JSON）。这是成本最低、收益最快的起点。

第二步（1个月）：搭建数据字典本体

把核心业务表的字段做语义标注，建立"业务术语 → 数据库字段"的映射关系。可以先用简单的 JSON 文件存储，不一定要上图数据库。

第三步（2-3个月）：引入图数据库

当本体规模增大（表间关系复杂、需要多跳查询），引入 Neo4j 存储关系本体和血缘关系。通过 MCP 协议接入 Agent。

第四步（持续迭代）：从错误中完善本体

每一次 Agent 答错 = 本体需要补充的地方。建立错误日志分析机制，把高频错误转化为本体规则。

技术选型建议

组件	推荐	说明
本体存储（小规模）	YAML / JSON 文件	简单直接，易于维护
本体存储（大规模）	Neo4j	最成熟的图数据库，有可视化界面
LLM 接入协议	MCP	标准化工具调用接口
语义检索	向量数据库（Milvus/Chroma）	用于同义词和相似字段的模糊匹配

六、本体论 vs 其他方案的对比

方案	优点	缺点	适用场景
纯 Prompt 描述	零成本，快速上手	规模大时 Prompt 过长，维护困难	小规模验证
向量检索（RAG）	自动化程度高，易扩展	只能做语义相似，无法表达关系和规则	字段同义词匹配
本体论 + 图数据库	能表达复杂关系和规则，支持推理	建设成本高，需要持续维护	大规模数仓，追求高准确率
Fine-tuning	推理成本低，私有化	需要训练数据，Schema 变化需重训	稳定业务场景

最佳实践 ：本体论不是替代其他方案，而是作为知识底座，与向量检索、Fine-tuning 结合使用。本体论提供结构化的精确知识，向量检索提供模糊匹配能力，两者互补。

附：关键术语

术语	含义
Ontology（本体论）	领域知识的形式化结构化表示，包含概念、关系、属性、规则
Schema Linking	将自然语言中的实体映射到数据库表/列，本体论是其知识来源
Knowledge Graph（知识图谱）	以图结构存储的知识网络，本体论的一种实现形式
Neo4j	最主流的图数据库，使用 Cypher 查询语言
MCP	Model Context Protocol，LLM 访问外部工具/知识库的标准协议
Sub-graph Mounting	子图挂载，按需拼凑局部上下文，避免全量图谱导致的语义漂移
Object（Palantir 概念）	Palantir Foundry 中的业务实体，本体论的具体实现

整理时间：2026-04-25