介绍产品整体链路时提到过，文档上传后会被抽取成结构化的IR文档，本体构建就是基于IR进行的。但这里有一个关键问题此前没有展开：本体真正的数据来源，往往不只是文档，还包括直接对接的数据库表。这两类来源各自生成的IR，结构和粒度完全不同，怎么把它们统一对齐、构建成一个连贯的本体，是本体构建这一步真正的技术核心。这一篇专门把这条链路讲清楚。

两种IR，两种粒度

先要正视一个容易被忽略的前提：数据库抽取出来的IR和文档抽取出来的IR，本质上不是同一类东西。

数据库IR是实例级的。一张交易表里的一行记录，对应的是一个具体、真实发生过的实体——某笔具体交易、某个具体客户。这类IR的特点是数量大、结构规整（毕竟来自结构化数据库），但缺少语义解释——表字段叫"amt"还是"trans_amount"，数据库本身不会告诉你这个字段在业务上到底代表什么、和监管规则里的哪个概念对应。

文档IR往往是概念级、规则级的。监管文件里"什么构成关联方""交易金额超过什么比例需要触发审批"这类表述，抽取出来的IR描述的是抽象定义和判断条件，本身不直接对应任何一条具体记录。

如果对齐的时候不区分这两种粒度，直接尝试做字段对字段的映射，很容易出现语义错位——把一个抽象定义错误地映射成某个数据库字段的别名，或者反过来，把一条具体记录的取值误当成了某个业务概念的定义本身。所以构建本体的第一步，不是急着做对齐，而是先把这两类IR分别放进两条处理路径：数据库IR走向Object Type的实例数据，文档IR走向Object Type、Link Type的概念定义与属性语义。

两层对齐：Schema层与实例层

区分清楚粒度之后，对齐工作可以拆成两个层次分别处理，这也是这套方法论里最关键的设计。

Schema层对齐，解决的是"结构对结构"的问题：数据库里的哪张表、哪个字段，对应文档里定义的哪个Object Type、哪个属性。比如数据库里的"counterparty_type"字段，需要被识别出对应文档里"交易对手方类型"这个概念，进而映射到本体"交易"这个Object Type下的一个属性。这一层的产出，是本体的骨架——Object Type有哪些、每个Object Type有哪些属性、Link Type连接的是哪两类对象，这些结构性的定义。

实例层对齐，解决的是"记录对记录"的问题，本质上是实体消歧（entity resolution）：数据库里具体的某一行记录，和文档里提到的某个具体主体（比如某份合同里点名的某家公司），是不是指向现实世界里同一个实体。这一层的产出，是把Schema层定义好的Object Type，用具体、去重后的实例真正填充起来，同时建立起Link Type对应的具体关系实例。

这两层要分开设计、分开校验，是因为它们容易出错的方式完全不同——Schema层出错，是"结构性"的，一旦错了会系统性地影响所有基于这个Object Type的下游规则和推理；实例层出错，通常是局部的，比如把两个同名但实际不同的公司误判成了同一个实体，影响范围相对可控，但出现频率会更高，需要不同的校验策略应对。

图形化对齐的具体做法：结构信号 + 语义信号

前面提到的"图形化对齐"，指的是把两类IR都先转化成图结构（节点代表实体/概念，边代表关系），再在图上寻找结构相似、可能对应同一语义的节点对。这个思路本身是合理的——图结构天然能表达实体间的关联模式，比单纯比较字段名称更能捕捉深层的语义关联。

但这里有一个必须正视的风险：单纯依赖图结构相似度做对齐，容易出现"结构像但语义不等价"的误匹配。举个例子，数据库IR里的"供应商"节点和文档IR里的"合作方"节点，在图上的邻接关系可能高度相似（都关联着"合同""交易"这类节点），但业务语义上，"合作方"可能是一个更宽泛的概念，供应商只是其中一种类型，两者不能简单画等号。

比较可靠的做法，是把图结构相似度只当作候选筛选的第一道筛子，而不是最终结论，在此基础上叠加至少两层独立的语义校验：一是属性语义相似度，通过计算字段名称、文档表述之间的语义相似度（可以借助embedding模型），进一步验证候选对齐关系在语义层面是否真的成立；二是取值分布一致性检验，如果两个节点被判定为对齐，理论上它们背后对应的实际数据取值分布应该有合理的一致性（比如枚举值范围是否吻合），如果取值分布明显对不上，即便结构和语义相似度都不错，也应该被标记为存疑，而不是直接采信。

这个多信号叠加的思路，和规则抽取准确性时的逻辑是一致的：不依赖单一信号源的判断，用多个相互独立的校验维度去交叉验证，才能把"看起来对了"和"真的对了"这两件事区分开来。

冲突处理：数据库和文档"打架"时怎么办

对齐过程中一定会遇到数据库和文档描述不一致的情况——文档里定义的某个阈值和数据库里实际记录的参数对不上，或者文档信息更新不及时、滞后于数据库的实时状态。这种冲突不能等实际遇到了再临时处理，需要在设计阶段就明确优先级规则。

一个相对合理的默认原则是：结构化数据库更适合作为"事实"的权威来源，比如交易金额、发生时间这类客观、实时的记录，数据库的数据通常更可信；文档更适合作为"定义和规则"的权威来源，比如什么构成关联方、什么情形需要触发审批，这类判断标准往往只在监管文件里有权威表述，数据库里不会存在这类抽象定义。但这只是默认原则，具体到不同的监管场景，可能还存在需要单独处理的例外情况（比如某些参数文档明确要求以最新文件为准，即便和历史数据库记录不一致），这部分例外需要在实际项目里和合规专家一起梳理清楚，写成明确的优先级规则，而不是留给系统自己隐式判断。

对齐关系也需要版本管理

本体本身需要版本管理，这个原则同样适用于对齐关系。数据库表结构会变，监管文件会更新换版，一旦源头发生变化，已经建立的对齐关系可能随之失效或者需要调整。如果对齐关系没有被纳入版本管理，源头一变化，很容易出现本体和真实数据、真实规则逐渐脱节的情况——这正是"本体悄无声息地衰退"在构建环节的一个具体成因。把IR对齐关系作为本体版本管理的一部分统一纳管,才能保证本体持续跟着数据源头和文档源头的变化保持同步,而不是建完就成了一份很快过时的静态快照。

小结

基于IR构建本体，核心不是一次性的"数据搬运"，而是要正视数据库IR和文档IR在粒度、语义结构上的根本差异，分Schema层和实例层做两层对齐，并且在图形化对齐的基础上叠加语义相似度、取值分布一致性这类独立校验信号，避免被"结构相似但语义不等价"的误匹配误导。同时，冲突处理需要有明确的优先级规则，对齐关系本身也要纳入版本管理，跟着数据源和文档源头持续演进。这几点想清楚、做扎实，才能让本体真正成为一个准确反映业务现实、并且能够持续维护下去的语义底座。