Lesson 07 · 直击使命
本体驱动的 RAG
本体怎么治检索增强生成(RAG)的三痛,并把它接进大语言模型应用
这是全课最贴你使命的一节。前面的类、三元组、推理、SPARQL,到这里汇成一个答案:本体 + 知识图谱,正好治住大语言模型检索应用那三个老毛病——不懂领域词、检索到碎块、回答不一致。
01RAG 的三痛,本体各给一味药
检索增强生成(Retrieval-Augmented Generation, 简称 RAG)靠"检索 + 生成"缓解幻觉,但有三个挥之不去的痛点:
| 痛点 | 具体表现 | 本体给什么 |
|---|---|---|
| ① 领域词不一致 | 系统里叫 SKU、业务叫"物料"、ERP 叫"产品" | 统一词汇——本体的共享概念化 |
| ② 检索到碎块 | 只会抓孤立文本片段,抓不到"事实与关系" | 结构化知识图——沿关系取回事实 |
| ③ 回答不一致 | 同一个问题几次答案打架 | 约束 + 推理——校验事实、补全隐含 |
02三条配合模式
具体怎么配合?三条,从轻到重:
模式一 · 词汇层:本体 = 统一词表
把你的本体词汇注入提示词/上下文,让大语言模型用对词:LeadTime、hasCapacity、FinishedGood ⊑ Product。它不再"商品/备货期"乱叫。
模式二 · 检索层:沿关系取回"事实"
不做纯文本分块,而是用 SPARQL 沿本体关系跳,取回具体的事实三元组给大语言模型做 grounding。多跳、有因果关系,而非孤立片段。
模式三 · 约束层:用公理约束/校验
用本体的公理(dataset/domain-range/基数)对注入的事实和生成的输出做一致性与合法性校验——提前拦下矛盾、非法值,而不是让大模型硬编。
03端到端,长什么样
图 1 · 本体驱动检索增强生成:先经本体把问题变成结构化查询,取回事实,再和文本一起交给大语言模型,最后用本体校验。
04一个供应链实例
用户问:"7 号线这个月能满足订单 1042 吗?" 走一遍:
- 映射:把"7 号线""订单 1042"映射到本体的
:line-7、:order-1042。 - 查询:沿本体跳——
:order-1042 :requiresProduct :sku-447、:sku-447 :isProducedOn :line-7、:line-7 :hasCapacity ?v(:CapacityAllocation)。 - 推理:推理器补齐(如产能分配、资源类型),得到可靠事实。
- 生成:大语言模型基于这些事实三元组 + 少量文本,算出"产能 vs 需求",给出有依据的结论。
- 校验:用公理检查答案与注入事实无矛盾。
没有本体,大语言模型只能"看几段文本猜";有了本体,它能沿确定的关系拿到确定的事实、再推理——回答有据可查,也更一致。
近两年的研究(OG-RAG、OntoRAG)正是这个思路:本体接地的检索增强生成,显著降低幻觉、提升领域一致性。
05检查你的理解
本体给 RAG 补的"词汇层",核心作用是什么?
知识图谱检索相比纯文本分块,强在哪?
用本体公理去约束/校验,作用是什么?
想直接看实现,可参考开源框架 OntoRAG;想动手,回看 从领域到本体 与 SPARQL。
[1] OG-RAG: Ontology-grounded Retrieval-Augmented Generation(2025;收录于 EMNLP 自然语言处理实证方法会议)。
[2] OntoRAG: Ontology-Driven RAG(开源框架)。
这一课是你使命的正解。想把你的供应链计划接成"本体驱动的检索增强生成",可以直接和我聊聊从哪里切(词汇层/检索层/约束层)、先做哪一步。有任何概念卡壳,尽管问。