背景
最近同样在做知识库的升级，告一段落后，把涉及到的概念整理下，仅作为笔记整理，有合理的地方可以参考。
如果你最近在做 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 工作原理（四个步骤）
① 文档切块（Chunk）
产品说明书.pdf → 切成一段段小文字
② 向量化（Embedding）
每段文字 → 转成一串数字向量
③ 存入向量库（Vector DB）
[向量 + 原文 + 元数据] 一起存起来
④ 召回（Retrieval）+ 拼 Prompt
用户问题 → 转向量 → 在向量库找最相近的几段 → 拼进 Prompt → 丢给大模型
每一步展开讲一下：
① 文档切块 原始 PDF 太长了，模型一次读不完，得切成小块。切的时候要注意别把一个完整意思切断了，所以常常会 "重叠" 一点。
② 向量化 一段文字没法直接算 "像不像"，于是用 Embedding 模型把它转成几百上千维的数字数组。语义越像，向量越近。
"我的订单能退款吗" → [0.12, 0.45, -0.78, ...]（查询向量）
"退款政策：7天内可退" → [0.11, 0.47, -0.75, ...]（文档向量） ← 靠得很近，很像！
③ 存入向量库 向量库就是专门存这些向量 + 原文的数据库，最厉害的地方是能极快找到 "语义最接近" 的向量。
④ 召回 + 拼 Prompt 用户提问 → 转成查询向量 → 向量库返回 Top-K 个最相近的文档片段 → 把这些片段塞进 Prompt → 交给大模型。
2.4 一个具体的 Prompt 长这样
【系统指令】
你是客服助手。只能使用下面【参考材料】中的内容回答。
材料里没有的信息，直接说"不知道"，禁止编造。
【参考材料】
[1] 《退款政策》：签收后7天内可申请退款，退款金额为实付金额。
[2] 《订单记录》：订单2026001，实付88元，签收时间3天前。
【用户问题】
我的订单2026001还能退款吗？
大模型就会回答： "可以，您的订单在 7 天退款期内，可退实付金额 88 元。" —— 而且有据可查。
2.5 优点 / 缺点 / 场景
表格
| 说明 | |
|---|---|
| ✅ 优点 | 不需要重新训练模型；能引用原文、减少幻觉；资料更新快，改文档就行；落地成本低、见效快 |
| ❌ 缺点 | 不懂业务逻辑，只做 "语义像不像" 的匹配；容易被近义词 / 别名坑到；切块切不好召回质量差；无法做推理和规则校验 |
| 🎯 场景 | 文档问答、智能客服、知识库检索、代码库问答…… 凡是 "从一堆文档里找答案" 的都适合 |
⚠️ RAG 的致命短板：它只找 "长得像" 的文本，不懂 "客户" 和 "用户" 是不是同一个概念、退款必须关联订单这类业务逻辑。这正是下面本体要解决的。
3. 向量库：RAG 的地基
3.1 向量库是什么？
向量库 = 一种专门存 "向量 + 原文 + 元数据"、并支持按语义相似度快速检索的数据库。
- 普通数据库存的是结构化字段（姓名、金额），搜索靠关键词匹配；
- 向量库存的是高维数字向量，搜索靠语义相似度。
3.2 文档怎么切、怎么存？
流程：
原始文档 → 清洗（去掉页眉页脚乱码） → 切块(Chunk)
每块 → Embedding模型 → 向量
存库：[向量, 原文文本, 元数据(文档名/页码/章节)]
切块两种主流方式：
- 固定长度切：按 token 数硬切，简单但容易切断一句话。适合纯文本。
- 语义 / 章节切：按标题、段落、条款号（1.1、3.2）切，保证每块是完整语义单元。适合合同、说明书这种有结构的文档。
3.3 怎么召回？
用户问题 → 同一个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 它是怎么工作的？
原始资料（产品说明书、售后规范、政策）
↓ 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. 该怎么选？
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 自动整理好的 《业务百科手册》 ，写满规则和概念；
- 本体 = 管理员脑子里那套固定的概念关系框架："什么是订单、什么是退款、它们之间什么关系、哪些情况算违规"。
这三件套，让大模型从 "会说话" 变成 "懂业务、有依据、守规矩"。
