RAG、LLM Wiki、本体（Ontology）到底是个啥？

背景

最近同样在做知识库的升级，告一段落后，把涉及到的概念整理下，仅作为笔记整理，有合理的地方可以参考。

如果你最近在做 AI 应用，大概率听过这三个词：RAG 、LLM Wiki 、本体（Ontology） 。但很多人跟我一样，听名字一头雾水：什么检索增强？什么本体？Wiki 不是个网站吗？

0. 先说背景：为什么需要这三样东西？

先搞清楚它们为什么会出现。大模型（LLM，也就是 GPT、ds、Claude 这类）有个天生的大毛病：

不知道你的私有知识：模型训练时没见过你公司的文档、你的项目、你的数据，问它等于 "考一个没复习过的人"。
容易一本正经胡说八道：没学过的东西它敢编，这就是所谓的 "幻觉（Hallucination）"。
不懂你业务里的逻辑关系：它能看懂 "苹果"，但不一定知道 "苹果属于水果，水果属于食品" 这种概念层级。

这三个毛病，分别对应我们今天要讲的三个工具。换句话说：

RAG、LLM Wiki、本体，都是给大模型 "补课、立规矩、搭框架" 的三件套。

1. 先来一个贯穿全文的场景

为了好懂，举个例子 ------给一个公司做 "AI 客服问答助手" （比如你的公司想做一个机器人，回答客户关于自家产品的各种问题）。

假设公司有一堆资料：

散落的原始文档：产品说明书 PDF、售后工单、聊天记录、FAQ 列表...... 堆得像山一样。
公司内部的制度规范：比如《售后处理流程》《退款政策》这类 "规则手册"。
一堆业务概念：客户、订单、退款、优惠券...... 它们之间有明确关系（一个订单只能退一次款，退款必须关联订单）。

你希望这个 AI 客服能回答： "我的订单还能退吗？能退多少？"

好，带着这个场景，我们来看这三样东西分别干嘛。

2. RAG：能翻遍资料库、把原文贴给你的 "检索员"

2.1 一句话定义

RAG（Retrieval-Augmented Generation，检索增强生成） ：回答问题时，先从资料库（你的那一堆原始文档）里检索出相关片段，再把 "问题 + 片段" 一起丢给大模型，让它基于这些原文来回答。

2.2 简单理解

你可以把 RAG 想象成：

一个极其熟练的资料检索员。客户问问题，他先冲到文件堆里把相关段落翻出来，贴在纸条上，连同问题一起交给写答案的大模型："看，就按这些原文来写，别乱编。"

它有点像：一个动态的、能按语义匹配的 "数据加载器" ，只不过加载的不是接口数据，而是文档片段。

2.3 工作原理（四个步骤）

css 复制代码

① 文档切块（Chunk）
   产品说明书.pdf  →  切成一段段小文字
② 向量化（Embedding）
   每段文字 → 转成一串数字向量
③ 存入向量库（Vector DB）
   [向量 + 原文 + 元数据] 一起存起来
④ 召回（Retrieval）+ 拼 Prompt
   用户问题 → 转向量 → 在向量库找最相近的几段 → 拼进 Prompt → 丢给大模型

每一步展开讲一下：

① 文档切块 原始 PDF 太长了，模型一次读不完，得切成小块。切的时候要注意别把一个完整意思切断了，所以常常会 "重叠" 一点。

② 向量化 一段文字没法直接算 "像不像"，于是用 Embedding 模型把它转成几百上千维的数字数组。语义越像，向量越近。

arduino 复制代码

"我的订单能退款吗"  →  [0.12, 0.45, -0.78, ...]（查询向量）
"退款政策：7天内可退" →  [0.11, 0.47, -0.75, ...]（文档向量）  ← 靠得很近，很像！

③ 存入向量库 向量库就是专门存这些向量 + 原文的数据库，最厉害的地方是能极快找到 "语义最接近" 的向量。

④ 召回 + 拼 Prompt 用户提问 → 转成查询向量 → 向量库返回 Top-K 个最相近的文档片段 → 把这些片段塞进 Prompt → 交给大模型。

2.4 一个具体的 Prompt 长这样

csharp 复制代码

【系统指令】
你是客服助手。只能使用下面【参考材料】中的内容回答。
材料里没有的信息，直接说"不知道"，禁止编造。

【参考材料】
[1] 《退款政策》：签收后7天内可申请退款，退款金额为实付金额。
[2] 《订单记录》：订单2026001，实付88元，签收时间3天前。

【用户问题】
我的订单2026001还能退款吗？

大模型就会回答： "可以，您的订单在 7 天退款期内，可退实付金额 88 元。" ------ 而且有据可查。

2.5 优点 / 缺点 / 场景

表格

	说明
✅ 优点	不需要重新训练模型；能引用原文、减少幻觉；资料更新快，改文档就行；落地成本低、见效快
❌ 缺点	不懂业务逻辑，只做 "语义像不像" 的匹配；容易被近义词 / 别名坑到；切块切不好召回质量差；无法做推理和规则校验
🎯 场景	文档问答、智能客服、知识库检索、代码库问答...... 凡是 "从一堆文档里找答案" 的都适合

⚠️ RAG 的致命短板：它只找 "长得像" 的文本，不懂 "客户" 和 "用户" 是不是同一个概念、退款必须关联订单这类业务逻辑。这正是下面本体要解决的。

3. 向量库：RAG 的地基

3.1 向量库是什么？

向量库 = 一种专门存 "向量 + 原文 + 元数据"、并支持按语义相似度快速检索的数据库。

普通数据库存的是结构化字段（姓名、金额），搜索靠关键词匹配；
向量库存的是高维数字向量 ，搜索靠语义相似度。

3.2 文档怎么切、怎么存？

流程：

scss 复制代码

原始文档 → 清洗（去掉页眉页脚乱码） → 切块(Chunk)
每块 → Embedding模型 → 向量
存库：[向量, 原文文本, 元数据(文档名/页码/章节)]

切块两种主流方式：

固定长度切：按 token 数硬切，简单但容易切断一句话。适合纯文本。
语义 / 章节切 ：按标题、段落、条款号（1.1、3.2）切，保证每块是完整语义单元。适合合同、说明书这种有结构的文档。

3.3 怎么召回？

css 复制代码

用户问题 → 同一个Embedding模型 → 查询向量
向量库按余弦相似度 → 返回Top-K最像的片段
（可选）再经Rerank精排 → 剔除不相关的 → 压缩到Top-3

一句话：向量库负责 "语义粗筛"，Rerank 模型负责 "精排去噪"，两者搭配幻觉更少。

4. 本体（Ontology）：懂概念、懂关系、能校验的 "业务字典"

4.1 简单理解

本体（Ontology） ：一套规范化定义某个领域里有哪些概念、每个概念有什么属性、概念之间是什么关系 的规则框架。中文标准译名就是本体。

4.2 类比理解

用前后端接口定义和联调理解：

本体 ≈ 数据库的表结构 + TypeScript 的类型定义 + 组件之间的关系树。

定义 "有哪些表" → 就是定义业务里有哪些实体（客户、订单、退款）；
定义 "每个表有什么字段" → 就是定义实体的属性（订单有金额、状态）；
定义 "表之间怎么关联" → 就是定义关系（订单属于客户，退款关联订单）；
还能加约束 → 比如 "一个订单只能退一次款"。

4.3 本体里到底装了什么？

类（Class） ：客户、订单、退款、优惠券（业务实体类型）
属性（Property） ：订单号、金额、状态、时间
关系（Relationship） ：订单属于客户；退款关联订单
约束 / 规则（公理） ：退款金额 ≤ 订单实付金额

4.4 一个容易混淆的问题：本体是结构化数据吗？

本体本身不是业务数据，它是 "数据的元模型 / Schema"（模板），不是具体的一条条数据。

用数据库类比最清楚：

本体 = CREATE TABLE 建表语句（定义表长什么样）；
结构化业务数据 = INSERT INTO 插入的一条条记录（具体内容）；
知识图谱实例 = 用本体这个 Schema 填充出来的实体和关系（属于结构化数据）。

所以：本体是 "定义规则的框架"，不是 "存具体合同、订单明细的数据"。

4.5 本体的价值在哪？

本体最大的价值是让机器 "懂业务逻辑" ：

让 AI 知道 "客户" 和 "用户" 是同一个东西（实体归一）；
让 AI 能推理和校验：既然 "退款必须关联有效订单"，那看到一笔没有订单的退款，就能自动判定 "异常"；
相当于给 AI 建了一套业务规矩。

4.6 优点 / 缺点 / 场景

表格

	说明
✅ 优点	让 AI 真正理解业务概念和关系；能做逻辑推理、规则校验；语义精确，不怕别名
❌ 缺点	要人工梳理业务、定义类 / 关系 / 规则，建设成本高；不会直接读文档，需要配合 NLP/LLM 提取实体
🎯 场景	业务规则强、关系复杂、需要精确校验的场景：金融风控、医疗诊断、合同比对、供应链

5. LLM Wiki：AI 自动维护的 "领域百科手册"

5.1 先说清楚：LLM Wiki 不是 "大模型"！

LLM（大模型） ：那个能生成文字的模型本体；
LLM Wiki ：一个 Wiki 形态的知识库，由 LLM 来辅助构建、维护和查询。这是行业俗称，不是标准学术术语，但大家这么叫。

5.2 一句话定义

LLM Wiki = 用大模型自动整理、归纳、维护的领域 "维基百科" ，把散落的资料整理成一条条结构化、可跳转的百科条目。

5.3 简单理解

LLM Wiki ≈ 一份由 AI 自动维护、带目录和互相链接的文档站（类似你项目里的 README + 组件文档 + 知识库）。

传统 Wiki（比如 Wikipedia）：人一条条手动写、手动维护；
LLM Wiki：把原始资料丢给大模型，它自动提取、归纳，生成条目，自动更新，自动建内部链接。

5.4 它是怎么工作的？

markdown 复制代码

原始资料（产品说明书、售后规范、政策）
    ↓ LLM自动归纳整理
生成条目：《退款流程》《优惠券规则》《订单状态说明》...
    ↓ 自动维护
新增文档 → 自动更新相关条目 + 建立条目间链接
查询时 → 用自然语言提问 → LLM检索Wiki条目回答

在我们客服例子里，LLM Wiki 里会有类似条目：

条目《退款政策》：7 天内可退，金额为实付金额
条目《售后处理流程》：先核订单，再走退款审批

5.5 LLM Wiki 和 RAG 的区别

	RAG	LLM Wiki
面向什么	实例文档（一份份具体的说明书、工单、订单）	领域知识、制度规范、概念定义（归纳好的百科条目）
形态	原始碎片，未整理	结构化、条理化、带链接的条目
作用	找 "某份具体文档里的原文"	解释 "业务规则、流程、概念"

举例最直观：

RAG：检索《订单 2026001》这一份具体单据的原文片段；
LLM Wiki：查询《退款政策》这条整理好的通用规则。

补充一句：LLM Wiki 底层也经常套着 RAG------ 它把 Wiki 条目也切块、向量化，查询时用 RAG 来检索条目。所以两者不是互斥，而是 "Wiki 提供整理好的知识，RAG 负责检索"。

5.6 优点 / 缺点 / 场景

表格

	说明
✅ 优点	知识被整理得有条理、易维护、易检索；比一堆原始碎片更清晰
❌ 缺点	依赖 LLM 整理质量；知识变化时要及时更新条目；本质上还是 "知识查询"，不擅长推理
🎯 场景	企业知识库、制度规范问答、文档站、培训材料问答

6. 三者对比

技术	俗称	核心能力	面对的对象	会不会推理 / 校验
RAG	外挂知识库、检索增强生成	检索文档原文片段，给 LLM 提供上下文	一份份具体业务文档（说明书、订单）	❌ 不会
LLM Wiki	AI 领域维基、大模型知识库	自动归纳、维护领域制度百科条目	整理好的制度、流程、概念	❌ 基本不会
本体 Ontology	本体、领域知识模型、业务字典	定义实体、属性、关系、业务规则	业务概念 Schema（类和关系）	✅ 会，能推理校验

7. 回到客服场景：三者怎么各司其职？

用户问："我的订单还能退吗？能退多少？ "

RAG：去检索《订单 2026001》这份具体单据的原文，拿到 "实付 88 元、签收 3 天前" 这些事实；
LLM Wiki：调取整理好的《退款政策》条目："7 天内可退，退实付金额"；
本体：定义 "订单属于客户、退款必须关联订单、退款金额≤实付金额" 这些业务规则，并做校验推理；
最终大模型综合三者，给出有依据、符合业务规则的答案。

8. 该怎么选？

vbnet 复制代码

Q1: 你只是想让 AI 回答"一堆文档里的问题"？
     是 → 先用 RAG（性价比最高，最快落地）
     否 ↓
Q2: 你的场景业务规则很强、关系复杂、必须精确校验？
     （合同比对、风控、医疗、金融）
     是 → RAG + 本体（本体负责懂业务逻辑）
     否 ↓
Q3: 你有一堆制度规范、需要整理成可维护的知识？
     是 → 在RAG基础上，加 LLM Wiki 管知识

只想快速做出文档问答 → 只上 RAG，最快最省；
业务逻辑复杂、要精确校验 → RAG + 本体；
规则多、需要整理维护的制度知识 → RAG + LLM Wiki；
大型、正式的企业智能平台 → RAG + LLM Wiki + 本体 全上。

9. 它们能同时使用吗？

能，而且经常一起用。 三者不是 "三选一"，而是 "分工协作"：

RAG 负责 "找原文、给证据"；
LLM Wiki 负责 "整理好的领域知识 / 制度"；
本体负责 "懂业务概念、做逻辑校验"。

组合方式是：RAG（检索原文 + 检索 Wiki 条目）→ 本体做实体对齐和规则校验 → 三者信息拼成 Prompt → 丢给大模型 → 输出。 组合方案比单独用任何一种效果都更稳。

10. 落地方案参考

文档切块：文本清洗 + 切块工具（很多开源库）；
Embedding / 向量库：开源向量库如 Milvus、Qdrant、Chroma，或云服务；Embedding 模型选与领域匹配的（通用模型做法律 / 合同效果差，建议微调或选领域模型）；
本体构建：用 RDF/OWL 等标准，或用更轻的 JSON Schema 自己定义 "类、属性、关系"；
大模型调用：你的后端服务拼好 Prompt 调 LLM 接口；
前端：就做一个问答交互界面，接收结果展示即可。

踩坑提醒：切块别太大也别太小；Embedding 模型要跟领域匹配；Prompt 一定要约束 "只能基于材料回答，禁止编造"。

最后

想象一个图书管理员（大模型）在面对海量书籍：

RAG = 管理员随时能从书堆里翻出相关原文段落贴给你；
LLM Wiki = 管理员桌上一本 AI 自动整理好的 《业务百科手册》 ，写满规则和概念；
本体 = 管理员脑子里那套固定的概念关系框架："什么是订单、什么是退款、它们之间什么关系、哪些情况算违规"。

这三件套，让大模型从 "会说话" 变成 "懂业务、有依据、守规矩"。