知识图谱与领域本体工程

您的 AI 无法对它不知道的事情进行推理

向量检索找到的是听起来相似的内容,知识图谱找到的是真实为真的内容。这一区别,正是一个只会猜测的 AI 系统与一个能够推理的系统之间的差异。

临床基准测试将这一点具体化:以本体结构化知识图谱为基础的大语言模型,将幻觉率从 63% 降至 1.7%,而在复杂知识任务上,纯向量检索的准确率停滞在约 70%,相比之下,向量加图谱的混合方法可达 85% 以上(参见 我们关于医疗健康领域中有据可依的 AI 的研究)。

大多数尝试构建知识图谱的团队,最终做出来的却完全是另一回事:一个建在 Neo4j 中、没有形式化语义、没有推理能力、也没有溯源追踪的带标签属性图。那是一个数据库,而不是知识图谱。它能用,直到你需要回答架构设计者未曾预料到的问题、把某个 AI 输出追溯回其来源事实,或者在不破坏每一个下游消费方的前提下演进你的领域模型。

我们的做法是构建真正的东西:具备推理能力的形式化本体、在三元组层面带有溯源的生产级图谱基础设施,以及旨在让知识在你的领域不可避免地变化时保持最新的维护框架。

属性图、RDF 三元组存储,还是两者兼用:选择正确的架构

关于 Neo4j 与 RDF 之争,所耗费的工程周期远超其应有的程度,通常是因为决策在需求被理解之前就已经做出。

RDF 的回报在于自动推理:声明每一种与 MAO 抑制剂相互作用的药物对 SSRI 患者都是禁忌,推理机便无需人工逐一列举即可推断出每一项具体的禁忌。

我们的做法倾向于混合系统:形式化本体存放于 RDF 存储中用于推理与合规,同时由属性图处理遍历查询,并以一个同步层保持两者一致。再加上向量嵌入(TransE、CompGCN 或图神经网络)以实现语义相似度,你就得到了一个能在单一流水线中处理精确匹配、逻辑推断与模糊相似度的检索系统。

本体工程:人人都低估的那一部分

购买一个图数据库很容易。构建让它真正有用的本体,才是项目停滞之处。领域本体是对你的领域中存在什么、事物之间如何关联,以及这些关系受哪些约束支配的一种形式化规范。

把这件事做对,需要两种鲜少同时具备的专长:深厚的领域知识(一位制药法规专家对 IDMP 物质分类的了解)与形式化知识表示技能(如何用 OWL 2 DL 表达这些知识而不制造推理瓶颈),详见 我们关于受监管临床领域中神经符号 AI 的白皮书。

从能力问题入手

我们的本体工程流程从能力问题入手:即知识图谱必须能够回答的那些具体查询。不是像“支持药物安全性分析”这样含糊的需求,而是像“给定某位患者的用药清单和一张新处方,在 200 毫秒内识别出经由代谢通路相互作用产生的所有传递性禁忌”这样精确的需求。这些能力问题驱动着每一个建模决策,并成为本体演进的回归测试套件。

选择正确的形式体系

我们为具体任务选择正确的形式体系:

• OWL 2 DL ——适用于需要完整描述逻辑推理的领域(制药、法律、法规)。
• OWL 2 EL ——适用于对可处理性分类有要求的大型本体(SNOMED CT 拥有 350,000 多个概念,在 EL 中运行良好)。
• SKOS ——适用于分类法与受控词表,你需要层级和标签,但不需要逻辑推断。
• SHACL ——适用于与本体并存的数据校验规则约束。

大多数生产系统会组合使用多种形式体系,而知道该在何处应用哪一种,正是一次合作交付价值中相当重要的一部分。

实体解析:无人为之做规划的 3 倍预算乘数

在知识图谱能够对你的数据进行推理之前,这些数据需要经过清洗、去重和链接。实体解析——判定“JPMorgan Chase”、“JP Morgan”、“JPMC”和“J.P. Morgan Chase & Co.”是同一个实体——听起来简单,但在企业规模下确实很难。

难度会随着异构数据源而成倍增加。合并来自 10-15 个不同源系统的知识,意味着要应对相互冲突的模式、不同的标识符约定、参差不齐的数据质量,以及时间上的不一致(一个系统说这家公司在第三季度被收购,另一个说是第四季度)。团队常常把实体解析的成本低估了 3-5 倍。

我们设计的实体解析流水线结合了基于规则的匹配、习得的相似度模型,以及针对边缘情形的人工介入(human-in-the-loop)核验。该流水线的架构会输出一张规范实体图,并带有回溯到每一条源记录的溯源链接,因此你随时都能追溯两条记录为何被合并或保持分离。

在诸如 《欧盟人工智能法案》这样的框架下,这条溯源链对于监管可追溯性变得至关重要,其中第 12-13 条要求你证明喂给高风险 AI 系统的数据的血缘。

知识图谱项目为何失败(以及如何避免)

行业的失败模式已被充分记录: 95% 的企业级 GenAI 试点项目失败,而知识图谱项目还有其自身特有的失败模式。

1. 概念验证陷阱。 一个小型概念验证凭借经过筛选的数据集和简单的模式取得成功,于是领导层批准了完整的构建。随后团队发现,真实数据要杂乱 10 倍,本体所需的概念要多 50 倍,而他们为之优化的查询模式只覆盖了实际用例的 30%。我们的做法从第一天起就围绕生产数据样本和真实查询工作负载来界定合作范围。
2. 过度公理化。 拥有学术背景的本体工程师会加入每一条可能的公理和限制,于是推理机在规模不大的知识库上就从数秒变慢到数小时。我们尽早且持续地对推理机性能进行剖析,应用最小公理化原则:只有当约束服务于某个具体的能力问题时才添加它。
3. 本体漂移。 知识图谱上线,运行良好,随后随着领域的演变而缓慢劣化——SNOMED CT 每季度发布更新,监管分类法发生变动,新的产品类别不断出现,却无人负责维护。一次合作的范围界定为交付带有变更检测、影响分析和回归测试的本体维护框架,在部署前将每一个新概念或新关系都对照完整的能力问题套件进行校验。
4. 缺乏高管层的责任归属。 知识图谱属于基础设施——它们赋能下游的 AI 能力,但自身并不产生可见的功能。若没有把图谱质量与业务成果(减少幻觉、加快合规、更好地检测药物相互作用)联系起来的高管层支持,项目会在第二年失去资金。我们帮助团队用与其具体用例挂钩的具体指标来构建业务论证。

将知识图谱连接到大语言模型、RAG 与智能体 AI

微软的 GraphRAG(及其成本更低的 LazyGraphRAG 变体,将抽取成本削减至原来的 0.1%)证明,在复杂的多跳查询上,图结构化检索的表现优于纯向量检索。但生产环境中的 GraphRAG 比论文所暗示的更难:社区检测会产生检索伪影,抽取流水线需要针对特定领域进行调优,而且没有内置的溯源追踪。

我们设计的是以知识图谱为基础的检索,其中每一条被检索到的事实都携带其来源三元组、置信度分数和时间有效性。当大语言模型生成一个论断时,系统会对照图谱进行核验,并引用支持或反驳它的具体三元组(参见一个 对照图谱进行引用核验的可运行演示)。而在向量 RAG 中,“模型找到了一段相似的文本”就是你能得到的最强归因。

作为智能体可访问工具的知识图谱

对于智能体 AI 架构,知识图谱充当可作为工具访问的知识来源。2026 年 4 月,Neo4j 在 Google Cloud 上推出了面向智能体系统的知识层,而随着模型上下文协议(MCP)成为智能体与知识之间的连接器标准,其采用正在加速。

我们的做法是构建从第一天起就可被智能体查询的知识图谱:SPARQL 端点、结构化 API 或兼容 MCP 的接口,让 AI 智能体能够以一次工具调用的方式访问领域知识,而不是以提示注入的方式,这一做法详见 我们关于企业 AI 智能体责任防火墙的研究。

我们交付什么

每一次合作都会依据你的领域、数据格局和下游 AI 需求来界定范围。交付物包括:

• 一份经自动推理机校验、带有完整注释的形式化领域本体(OWL)。
• 已填充数据的知识图谱,配有面向结构化与非结构化数据源的摄取流水线。
• 带有完整溯源的实体解析服务。
• 用于数据校验的 SHACL 约束定义。
• 作为本体演进回归测试的能力问题测试套件(SPARQL 或 Cypher 模式)。
• 面向 RAG、大语言模型接地或智能体 AI 工具访问的集成接口。
• 带有变更检测和版本化部署的本体维护框架。

我们还会坦诚地评估在哪些情形下,一种更简单的方案同样能很好地满足你的需求。