本体设计

🧬 本体设计 · 本体层

定位:本体(Ontology)是让 AI 理解业务的语义层——把「业务世界长什么样」(概念、关系、口径规则)写下来,让模型不靠通识猜、按业务真相推理。本体 = TBox(概念)+ ABox(事实)。

📎 来源:实践分享第三章 + 好 Skill 与 CLI/CI 设计指南。本页是概览,深入见两篇子文章。

📐 深入 → [设计指南/本体设计/TBox] · [设计指南/本体设计/ABox] · [设计指南/本体设计/本体宽表映射设计]

同一个问题问两次,口径常不一样:

每一次「飘」都是一次口径没对齐——本体就是把这些规则一条条钉死。

来自描述逻辑 K = (TBox, ABox),就这两层,没有第三层:

很容易把「本体」和「宽表」划等号,这是错的。两者是不同的东西、不同的职责:

三条要点:

本体是「理解」,宽表是「查询」。本体回答「这个数是什么口径、和谁有关、能不能这么算」;宽表只回答「这个数存在哪、怎么 SELECT」。把口径规则塞进宽表,换个查询后端就丢了;写进本体,它跟着语义走。
本体可以对接宽表,也可以对接 API。本体是物理无关的语义层——它下面接什么执行底座由场景决定:
- 简单查询(取一条确定数据,端点固定)→ 本体/CLI 对接 API
- 复杂查询(多维组合、下钻归因)→ 本体/CLI 对接宽表
cost-query 演进就是实证:V1 = 本体 + API(OBDA,多步 API 编排),V2 = 本体 + 宽表(DSL→SQL 直查星型宽表)。换的是执行底座,本体作为概念层一直在。
宽表会把关系拍平,本体(尤其 ABox)再把关系显式记回来。归因要沿「共振/替代/父子」关系下钻,这些关系在宽表里是丢失的,得靠设计指南/本体设计/ABox 重新建模。

一句话:本体管「业务真相」,宽表/API 管「怎么把数取出来」。 别让查询手段绑架了语义。

📐 那两者具体怎么对齐? —— 类落到哪张 cube、维度/度量落到哪些列、约束怎么编译成 WHERE、被宽表拍平的关系怎么用 ABox 记回:见设计指南/本体设计/本体宽表映射设计。

能力	建到哪	对接
L1 事实查询 / L2 多维对比	只建 TBox 就够	简单 → CLI 接 API;多维 → CLI 接宽表
L3 归因分析 / L4 决策建议	才需 ABox(沿共振/替代关系下钻)	CLI 接宽表 + ABox 关系图

ABox 装的是「这个项目具体长什么样、和谁有关」。没有它,AI 只会查数,不会归因——像没去过现场的实习生。

把业务铁律写成 defaultFilters,引擎自动注入 WHERE,用户无感(详见设计指南/本体设计/TBox):

🐛 货值三倍累加 bug——同一笔货值在 Level=1/2/3 三层各存一份等额金额:AI 直接 SUM ... WHERE IsBenchmark=1 → 8490 万(语法对、错 3 倍);本体自动补 AND Level=3 → 2830 万(口径对)。

护栏不是枷锁,是默认安全值——业务铁律写在本体里,模型再厉害也绕不过。

本体是「领域知识怎么建模」;SKILL.md 正文是「这些知识怎么按需喂给 AI」——正文只放决策所需的最小信息,大段字典/示例外置 reference(见设计指南/Skill设计三级加载)。两者配合,但不是一回事。