从"把文档直接扔给 AI"到"建一张 AI 能理解的世界地图"——本文带你看懂 2025–2026 年学术界和工业界探索出的五条路。
Ontology（本体）是一张"知识地图"——它不只存储信息，还定义信息之间的关系和规则。用一个场景感受它的价值：
"供应商 A 的评分是多少？"
LLM 今天说 85，明天说 92，后天说 78。每次都在猜——因为它没有真正理解"供应商""评分""日期"之间的关系。
你定义好：供应商有名称、评分、地区；材料有库存量、安全阈值；供应商和材料是"供应"关系。
LLM 直接从图里查，不再猜。还能推理出"这个材料缺货会影响哪条产线"。
在 LLM 出现之前，建 Ontology 基本是：知识工程师 + 领域专家坐在一起，花几个月画白板、争论、修改。有三个根本矛盾：
手工建模太慢，跟不上业务变化。等建完了，业务已经变了。
既懂 OWL/SHACL 又懂具体业务的人极少。
建完就没人维护，慢慢变成"死模型"，无法跟随业务演化。
手工方式无法处理大量文档，文档规模一上去就崩溃。
LLM 恰好具备三项能力：从非结构化文本提取结构化信息、理解领域语义、生成 JSON/OWL 等标准格式。但用 LLM 建 Ontology 绕不开四道坎：
建一个领域的 Ontology 前，你根本不知道里面有多少种"东西"——10 种还是 1000 种？
LLM 可能创造出原文没有的概念或关系，把幻想当成事实输出。
"有关系"太笼统，"在左边/右边"又太细——什么粒度才合适？
Ontology 没有"标准答案"，怎么知道 LLM 建得好不好？
好比做一道复杂的菜：先洗菜、再切菜、再炒菜、最后装盘。每一步清晰可控，出了问题知道在哪里修。
① 从文档中找出名词实体 ② 判断名词间的关系 ③ 将"供应商 A"和"Supplier A"合为同一实体 ④ 检查结构合规性 + 逻辑一致性
每个新事实先通过双重检查，才能进入可信图谱：
验证分两层：SHACL（结构验证） + OWL Reasoner（逻辑验证）。两层都通过才算可信。
从法语技术文档半自动构建 Ontology。亮点是版本管理：每个 Ontology 版本有 5 种状态（已填充 → 已丰富 → 已评估 → 已使用 → 已归档），变更全程追踪。FAIR 评分从 V1.1 的 22.5% 提升到 V1.3 的 36.11%。
用 Wikidata 作为"骨架"约束 LLM 输出，Token 消耗仅为 GraphRAG 的二十分之一。MuSiQue 基准上 96% 三元组包含正确答案实体。
适合：对质量要求高的生产系统。
好比整理一堆混杂的乐高积木：先把颜色相近的放一起（聚类），再给每组贴标签（"这些是红色的轮子""这些是蓝色的窗户"）。不用事先知道有多少种积木，让数据自己说话。
关系提取是 Ontology 建设中最难的部分。LLM4Onto 把它拆成三步，每步基于原文，幻觉逐步降低：
实验结果：网络安全领域自动发现 483 种实体类型 + 72 种关系类型（传统 NER 模型只能识别 13–40 种）。
适合：探索新领域、不知道有什么类型的场景。
好比写论文：先列出一堆想写的点（素材收集），再把这些点组织成章节结构（层次整理）。两步分开，中间产物可以检查和修改。
阶段一负责"发现"——从企业文档中找出核心类和属性；阶段二负责"组织"——把扁平的概念列表整理成有上下级关系的层次树。中间产物可以人工审查。
在"Data"领域评测中，Fuzzy-match F1 值达到 0.724。局限在于层次推理能力有限——当概念层级很复杂时，模型倾向于把东西铺平而非做好层次归类。
适合：快速构建初版 Ontology 做验证、需要看清楚中间状态的场景。
好比做选择题而不是问答题——不让 LLM 自由发挥"这是什么关系"，而是让它从给定列表中选："这个关系是'属于''位于''导致'中的哪一个？" 选择空间被压缩，幻觉空间自然变小。
把 Wikidata 的 3.46 亿实体组织成 94 个模块（8 大类）。每条属性自动路由到「固有属性」（颜色、大小）或「关系属性」（位于、属于）两类中。结果：93.3% 类别覆盖率、98.0% 模块分配准确率。
适合：已有行业标准或数据规范的场景（医疗、法律、电力行业等）。
好比让一个人同时做采购、厨师、服务员——一个 Prompt 包圆了所有工作。实现最简单，半小时出结果，但因为没有任何中间检查，幻觉风险最高。
没有单一模型在所有子任务上都表现最好。
精心设计的 Prompt 有时能让小模型接近大模型表现。
措辞稍微一变，生成出来的 Ontology 结构可能完全不同。
半小时能出第一版结果，适合快速验证想法。
适合：快速 POC 原型验证，不适合生产系统。
| 流派 | 幻觉风险 | 工程复杂度 | 验证机制 | 版本管理 | Token 消耗 | 工业实战 |
|---|---|---|---|---|---|---|
| A 拆解派 Salovsky, IRT SystemX |
低 | SHACL + OWL | ✅ 有 | 高 | ✅ EDF/RTE | |
| B 聚类派 LLM4Onto |
低 | 无在线验证 | ❌ 无 | 中 | ❌ 学术 | |
| C 两步走派 OntoEKG, NeOn-GPT |
中 | 无在线验证 | ❌ 无 | 中 | 部分验证 | |
| D 框架派 OntoKG, Wikontic |
低 | 框架约束 | ❌ 无 | 极低* | ✅ Wikidata | |
| E 直给派 LLMs4OL |
高 | 无 | ❌ 无 | 中 | ❌ 学术 |
* Wikontic 使用 <1000 Token，为 GraphRAG 的 1/20。复杂度格数越多表示越高。
Salovsky 明确指出："大部分未来错误源于 NER 阶段"。类型标错、别名混淆、类型不完备是三大元凶。宁可在第一步多花功夫，也不要后期返工。
发现"有哪些东西"相对容易，搞清楚"这些东西之间是什么关系"才是真正挑战。建议先提取粗粒度关系，再用 LLM 细化和标准化。
没有验证措施就是"让 LLM 随便写写"。生产系统至少需要 SHACL 结构验证，有条件再加 OWL Reasoner 逻辑验证。
同个 LLM，Prompt 稍微换几个词，生成出来的 Ontology 结构可能完全不同。使用结构化模板 + 规则 + 示例，而非纯自然语言描述，能大幅减少波动。
Wikontic 用不到 1000 个 Token 建出了有效知识图谱，是 GraphRAG 的二十分之一。关键不是数据量，而是数据质量和约束的合理性。
先让 LLM 自由探索发现新概念，再自动将新概念纳入标准框架——"从无序到有序"的闭环正在成为主流设计模式。
Ontology 不只是用来查的静态知识库，还可以作为 AI Agent 的"世界模型"——Agent 用它理解当前状态、规划下一步行动、记录执行结果。
不只是从文字中提取，还要从图表、图片、传感器数据中提取 Ontology。这个方向刚刚起步，是下一个值得关注的增长点。
LLMs4OL 挑战赛、UPM 综述等正在推动建立统一评估标准——让不同方法可以在同一个标尺上比较，这对整个领域的进步至关重要。
所有带蓝色下划线的词均可悬停查看解释。以下是完整的术语对照表：