上一篇讲 RAG 接知识图谱，发完收到一个留言：我们那个 entity_types 列表，算不算本体？
这个问题比我见过的大多数问题都好。因为它说明你已经在做了，只是不知道它叫什么。
没读过上一篇的，先补一句背景：RAG 是让系统从你自己的文档里找答案；知识图谱是把”什么东西和什么东西什么关系”整理成一张网。这篇讲的是：这张网怎么画才不会乱。
一、本体是什么？你大概率已经建过一个
做 RAG 的时候，从文档里抽知识之前，你得先告诉系统：我要从文档里找哪几类东西。客户、订单、合同、规则、修订。用微软 GraphRAG 的话，这个列表写在配置里，叫 entity_types，中文就是”实体类型”——你要抽取的那些”东西”分别叫什么。
这个列表，就是本体。最轻量的形态，几行字，说清楚”这个世界里有哪几类东西”。
但完整的本体不止”有哪几类东西”。它有三样：
规则：哪些关系允许存在。客户可以”下”订单，合同不能”下”订单。
约束：数据必须长什么样。交付周期得是个整数，不能是”大概二十天”。
校验：图错了怎么知道。要有自动检查，不能靠人肉看。
entity_types 列表只有第一样的一半，后面三样全缺。缺了这几样的图，是 LLM「尽力拼凑」出来的——关系看着挺合理，对不对，没人说得清。
有篇合规问答的实践我印象很深：纯向量检索把一条不存在的规则「编织」进了答案，模型自己编的，说得还特别顺。换成类型化关系之后，答案能沿着边一步步查回去：哪条条款、哪次修订、影响了哪条规则，每一步都有出处。
这不是技术差距，是担责差距。
二、2025，LLM 正式坐了本体工程师的工位
本体研究圈去年做了个受控实验：让 LLM 从需求问题出发建本体，跟人的水平做对比评估。
结论：最好的模型在模块级达到「满足本体工程师需求，明显超过新手本体工程师」。
这句话的含金量全在限定词：模块级，初稿水平。不是完整领域本体，不是能直接发布的。
流程也定型了：写需求问题，LLM 出初稿，推理机查矛盾，业务约束查一遍，人审，版本化存档。
推理机是什么？一个查逻辑矛盾的工具，相当于拼写检查器，只不过查的是逻辑——“A 是 B、B 是 C，所以 A 是 C”这种链条，它能自动验证，哪里图打矛盾了它会指出来。
人审的位置定死了：生成之后，发布之前。LLM 干 80% 的体力活，人守最后 20%。这 20% 砍不掉，它就是「能用的图」和「看起来像的图」的差别。
三、你公司到底站在哪一档
别上来就建重型本体。先对三档，对的是档，不是工具。
第一档，数据对外。 场景：你的网站商品页，想让搜索引擎、让爬虫读得懂。用 Schema.org——2011 年 Google 联合 Yahoo、微软、Yandex 定的一套网页标注标准，可以理解为一张”通用标签表”：商品是商品，有价格、有品牌、有评分，都给了标准叫法。你在页面上按这套叫法贴标签，搜索引擎和 LLM 就都读得懂。零建模成本，一天能上线。
第二档，RAG 自动建图。 上一篇那个场景：从内部文档抽实体和关系，建图，做问答。entity_types 列表就够；规模再大一点，用 Neo4j——现在最主流的图数据库，专门存”谁和谁什么关系”这种数据的，它有自己的表结构定义（schema），顶得上本体的活儿。不用碰任何重型东西。
第三档，强语义域。 合规、金融、医疗，或者错了要担责的多步推理。这里才需要 OWL——一种让计算机”推理”的语言。普通图只能说”谁和谁有关系”，OWL 能写”如果 A 是 B、B 是 C，那么 A 自动就是 C”，机器自己推。SHACL 是配 OWL 用的校验规则语言：“交付周期必须是整数”“一份合同只能有一个当前生效值”，都能写成机器可查的格式。Ontop 是这一档企业里最实用的工具：数据不搬家，在你现有的数据库上叠一层语义，别人用图的问法提问，引擎自动翻译成 SQL 到你的库里跑，结果再按图的形式还回来。
这一档，推理、约束、人审，三道门一道不能少。
大多数公司的诚实答案是第二档。
第二档真正的成本不在技术，在实体对齐：一份材料里叫「客户」，另一份叫「customer」，是不是同一个东西？谁说了算？人审审的就是这个。
出路
先把你的需求问题写出来，10 到 30 条。「这条规则适用于哪些商户？」「这条是上一版的哪条的修订？」
问题写完，你在哪一档自己就清楚了，工具也就定了。别从「先学 OWL」开始。
评论区聊聊：你公司在做 RAG 吗？抽取的时候声明过实体类型吗？实体对齐踩过最疼的坑是什么？
下一篇把工具链拆细：五个层二十多个工具，每个是什么、解决什么，文末一张选型速查表。
判断讲完了（01 那篇），接下来是评论区最多人问的：工具到底怎么选？
五个层，二十多个工具，不逐个念名单，每个只讲一件事：它解决什么问题。文末有选型速查表，可以直接抄。
先记住一条：生产环境不跑完整 OWL 推理
上一篇说过，OWL 是让计算机”推理”的语言。它有个工程上的老问题：推理很贵。
OWL 按”能推理到什么程度”分了几档，最完整的档（DL 版）推理复杂度极高——图越大，耗时不是线性涨，是指数涨。牛津 2012 年那篇 HermiT 论文拿三台推理机实测过：
7 万类医学本体（NCI Thesaurus，美国国家癌症研究所的词表），通用推理要 58 秒。
大型解剖本体（FMA），27 分钟。
临床本体 GALEN-full，三台全灭：一台内存爆掉，两台超时。
反过来，用简化档（EL/QL/RL，推理能力弱一点但快得多），专用算法比通用路径快好几个数量级。
所以工业界的规矩很朴素：要么用简化档，要么推理结果提前算好存起来，在线的时候直接查。这条规矩决定了下面怎么选存储层。
第一层，建模：本体在哪画出来
Protégé：斯坦福出的免费建模工具，本体圈用了二十多年，你搜”本体教程”跳出来的多半是它。它值得学的是一处设计：核心只有一层编程接口，编辑器、推理机、校验器、导入器全是插件，想接什么工具就写什么插件。能活二十多年，靠的就是谁都插得进来。
Open Ontologies：2025 年出来的新对手，Rust 写的，装起来就是一个可执行文件，没有一堆依赖。它内置了推理机和 SHACL 校验（上一篇讲过，OWL 配的校验规则语言），还自带 70 多个 MCP 工具接口——MCP 就是给 LLM 挂工具的那套标准，你之前接搜索、接数据库看到的那个。标准循环：LLM 直接写本体，推理机查矛盾，SHACL 查业务约束，需求问题当测试用例逐条验证。
这是「LLM 当本体工程师」第一个完整的开源实现。想试 LLM 建本体，它比 Protégé 门槛低。
第二层，存储推理：图存在哪、谁来查
两条路线在打。
物化路线：把图复制进专门的图数据库。代表四个：Jena，Apache 出的开源库，十分钟能起一个可查询的 RDF 端点；GraphDB，商业的，把推理做成开关，打开就行；Stardog，商业的，虚拟图是标配；Virtuoso，SQL 和 RDF 双栈，DBpedia（那个全网最大的开放知识库）的公共查询端点在上面跑了二十多年。
查询快，代价是 ETL：图是复制进去的，源数据变了，图要重新灌，中间有时间差。
虚拟化路线：上一篇说过的 Ontop 是代表，也是企业最该看一眼的。思路反过来：数据不动。在你现有的数据库上叠一层本体，写好”语义和表怎么对应”的映射，查询进来，引擎改写成 SQL 直接在原库上跑，结果按图的形式还回去。
数据不出库，合规友好；没有 ETL，实时；业务方按语义提问，引擎管 SQL。这几条正好是数据团队喊了很多年的诉求。
第三层，Web 轻量层：不用建图，贴标签
Schema.org：上一篇讲过，Google 联合几家定的网页标注标准。它是”轻量本体”的极端形态：没有推理，没有约束，就是带类型的实体加命名属性，写点 JSON 就行。2011 年定下来，口号是”有总比没有强”。
Wikidata：另一个极端。几十亿条目，没有中央编辑，全是志愿者填的。质量靠什么？constraint schema：每个属性上可以声明约束（单值、格式、允许怎么修饰），bot 全天候扫全库报违规。
你可以把它理解成”网友众包版”的 SHACL——SHACL 是给人工体系用的校验语言，Wikidata 证明了大规模数据上”约束 + 自动扫描”这条路走得通。做领域库的值得抄。
第四层，LLM 层：从文档自动建图，现在的主战场
三个代表。
微软 GraphRAG：LLM 从文档里自动抽实体、抽关系建图。它的”本体”就是上一篇那个 entity_types 列表——几行 YAML，你声明要抽哪些实体类型，剩下的交给模型。官方文档对 claim（断言）抽取的态度很直白：提示词真的需要你自己反复调，所以默认关着。
Neo4j 加 LlamaIndex：LLM 建出来的图存哪？很多团队选 Neo4j。为什么是图数据库赢了语义网社区的老牌 triplestore（专门的三元组库）？三个原因：内建向量索引（RAG 和图一个库里互相查）、Cypher（它的查询语言）门槛比 SPARQL 低、LLM 的教程和示例默认都是它。LlamaIndex 是 Python 的 RAG 框架，和 Neo4j 的集成最成熟。
Open Ontologies：第一层说过，这里它是”LLM 建完、推理闭环、还能被 Agent 调用”的完整链路。
第五层，消费层：本体怎么喂给 Agent
2026 年 6 月，Palantir 把 Ontology MCP 全量发布了。
规则很有意思：读的工具做”宽”——12 种对象类型坍缩成一个读工具，一次读所有类型，靠行级权限控制谁能看哪些行；写的工具做”窄”——30 种动作类型展开成 30 个写工具，因为每个写操作都是一次独立的治理决策，要单独审批。加上 6 个查询函数，一共 37 个工具，一行工具定义都不用手写。
读坍缩、写展开。这个设计逻辑值得抄，不管你用什么。
开源路线上已经有了：Open Ontologies（70 多个工具）和 ObjectStack（声明对象、动作、权限，自动生成带审批和审计的工具面）。
另外说个边角：本体对齐这个跑了 14 年的老比赛 OAEI（比谁把两张图的实体对应得准），去年第一次有 LLM 匹配工具参赛，一进场就进了”合并后保持一致”的少数名单。老赛道也进”逻辑 + LLM”阶段了。
选型速查表（抄这里）
- 想试建模：Protégé；想试 LLM 生成：Open Ontologies
- 数据要贴标签给搜索引擎：Schema.org
- 生产 RDF 图，中小规模：Jena Fuseki
- 生产 RDF 图，企业集群：GraphDB 或 Stardog
- SQL 双栈：Virtuoso
- 数据不动、上面叠语义层：Ontop
- 文档自动建图问答，文档为中心：GraphRAG
- 文档自动建图问答，实体为中心：Neo4j 加 LlamaIndex
- 暴露给 Agent：Open Ontologies 或 ObjectStack（开源），Palantir（商业）
最后一句：形式本体（OWL 可推理）≫ 图 schema（Neo4j）≫ 类型列表（entity_types），成本跨数量级。LLM 降本主要发生在中间两层。形式本体里”专家审”那一环，没被降掉。
三档定位回顾：
第一档（数据对外）→ Schema.org。
第二档（RAG 自动建图）→ entity_types 列表或 Neo4j 的 schema。
第三档（强语义域、要担责）→ Ontop 加 OWL 简化档加 SHACL，三道门一道不少。
评论区聊聊：你现在用的哪一层？踩过的坑是实体对齐、查询改写，还是别的？