给大模型"补课、立规矩、搭框架"的三件套，一篇笔记讲清楚
最近同样在做知识库的升级，告一段落后，把涉及到的概念整理下，仅作为笔记整理，有合理的地方可以参考。
如果你最近在做 AI 应用，大概率听过这三个词：RAG、LLM Wiki、本体（Ontology）。但很多人跟我一样，听名字一头雾水：什么检索增强？什么本体？Wiki 不是个网站吗？
先搞清楚它们为什么会出现。大模型（LLM，也就是 GPT、ds、Claude 这类）有个天生的大毛病：
| 毛病 | 具体表现 | 对应工具 |
|---|---|---|
| 不知道你的私有知识 | 模型训练时没见过你公司的文档、你的项目、你的数据，问它等于"考一个没复习过的人" | RAG |
| 容易一本正经胡说八道 | 没学过的东西它敢编，这就是所谓的"幻觉（Hallucination）" | RAG（给原文证据） |
| 不懂你业务里的逻辑关系 | 它能看懂"苹果"，但不一定知道"苹果属于水果，水果属于食品"这种概念层级 | 本体（Ontology） |
为了好懂，举个例子——给一个公司做"AI 客服问答助手"（比如你的公司想做一个机器人，回答客户关于自家产品的各种问题）。
假设公司有一堆资料：
你希望这个 AI 客服能回答："我的订单还能退吗？能退多少？"
好，带着这个场景，我们来看这三样东西分别干嘛。
RAG（Retrieval-Augmented Generation，检索增强生成）：回答问题时，先从资料库（你的那一堆原始文档）里检索出相关片段，再把"问题 + 片段"一起丢给大模型，让它基于这些原文来回答。
你可以把 RAG 想象成：一个极其熟练的资料检索员。客户问问题，他先冲到文件堆里把相关段落翻出来，贴在纸条上，连同问题一起交给写答案的大模型："看，就按这些原文来写，别乱编。"
它有点像：一个动态的、能按语义匹配的"数据加载器"，只不过加载的不是接口数据，而是文档片段。
① 文档切块（Chunk）
产品说明书.pdf → 切成一段段小文字
② 向量化（Embedding）
每段文字 → 转成一串数字向量
③ 存入向量库（Vector DB）
[向量 + 原文 + 元数据] 一起存起来
④ 召回（Retrieval）+ 拼 Prompt
用户问题 → 转向量 → 在向量库找最相近的几段 → 拼进 Prompt → 丢给大模型每一步展开讲一下：
"我的订单能退款吗" → [0.12, 0.45, -0.78, ...]（查询向量）
"退款政策：7天内可退" → [0.11, 0.47, -0.75, ...]（文档向量） ← 靠得很近，很像！【系统指令】
你是客服助手。只能使用下面【参考材料】中的内容回答。
材料里没有的信息，直接说"不知道"，禁止编造。
【参考材料】
[1] 《退款政策》：签收后7天内可申请退款，退款金额为实付金额。
[2] 《订单记录》：订单2026001，实付88元，签收时间3天前。
【用户问题】
我的订单2026001还能退款吗？大模型就会回答："可以，您的订单在 7 天退款期内，可退实付金额 88 元。"——而且有据可查。
| 说明 | |
|---|---|
| ✅ 优点 | 不需要重新训练模型；能引用原文、减少幻觉；资料更新快，改文档就行；落地成本低、见效快 |
| ❌ 缺点 | 不懂业务逻辑，只做"语义像不像"的匹配；容易被近义词 / 别名坑到；切块切不好召回质量差；无法做推理和规则校验 |
| 🎯 场景 | 文档问答、智能客服、知识库检索、代码库问答……凡是"从一堆文档里找答案"的都适合 |
向量库 = 一种专门存"向量 + 原文 + 元数据"、并支持按语义相似度快速检索的数据库。
原始文档 → 清洗（去掉页眉页脚乱码） → 切块(Chunk)
每块 → Embedding模型 → 向量
存库：[向量, 原文文本, 元数据(文档名/页码/章节)]切块两种主流方式：
| 方式 | 做法 | 适用 |
|---|---|---|
| 固定长度切 | 按 token 数硬切，简单但容易切断一句话 | 纯文本 |
| 语义 / 章节切 | 按标题、段落、条款号（1.1、3.2）切，保证每块是完整语义单元 | 合同、说明书等有结构的文档 |
用户问题 → 同一个Embedding模型 → 查询向量
向量库按余弦相似度 → 返回Top-K最像的片段
（可选）再经Rerank精排 → 剔除不相关的 → 压缩到Top-3本体（Ontology）：一套规范化定义某个领域里有哪些概念、每个概念有什么属性、概念之间是什么关系的规则框架。中文标准译名就是本体。
用前后端接口定义和联调理解：本体 ≈ 数据库的表结构 + TypeScript 的类型定义 + 组件之间的关系树。
本体本身不是业务数据，它是"数据的元模型 / Schema"（模板），不是具体的一条条数据。用数据库类比最清楚：
| 说明 | |
|---|---|
| ✅ 优点 | 让 AI 真正理解业务概念和关系；能做逻辑推理、规则校验；语义精确，不怕别名 |
| ❌ 缺点 | 要人工梳理业务、定义类 / 关系 / 规则，建设成本高；不会直接读文档，需要配合 NLP/LLM 提取实体 |
| 🎯 场景 | 业务规则强、关系复杂、需要精确校验的场景：金融风控、医疗诊断、合同比对、供应链 |
LLM Wiki = 用大模型自动整理、归纳、维护的领域"维基百科"，把散落的资料整理成一条条结构化、可跳转的百科条目。
LLM Wiki ≈ 一份由 AI 自动维护、带目录和互相链接的文档站（类似你项目里的 README + 组件文档 + 知识库）。
原始资料（产品说明书、售后规范、政策）
↓ LLM自动归纳整理
生成条目：《退款流程》《优惠券规则》《订单状态说明》...
↓ 自动维护
新增文档 → 自动更新相关条目 + 建立条目间链接
查询时 → 用自然语言提问 → LLM检索Wiki条目回答在我们客服例子里，LLM Wiki 里会有类似条目：
| RAG | LLM Wiki | |
|---|---|---|
| 面向什么 | 实例文档（一份份具体的说明书、工单、订单） | 领域知识、制度规范、概念定义（归纳好的百科条目） |
| 形态 | 原始碎片，未整理 | 结构化、条理化、带链接的条目 |
| 作用 | 找"某份具体文档里的原文" | 解释"业务规则、流程、概念" |
举例最直观：RAG 检索《订单 2026001》这一份具体单据的原文片段；LLM Wiki 查询《退款政策》这条整理好的通用规则。
| 说明 | |
|---|---|
| ✅ 优点 | 知识被整理得有条理、易维护、易检索；比一堆原始碎片更清晰 |
| ❌ 缺点 | 依赖 LLM 整理质量；知识变化时要及时更新条目；本质上还是"知识查询"，不擅长推理 |
| 🎯 场景 | 企业知识库、制度规范问答、文档站、培训材料问答 |
| 技术 | 俗称 | 核心能力 | 面对的对象 | 会不会推理 / 校验 |
|---|---|---|---|---|
| RAG | 外挂知识库、检索增强生成 | 检索文档原文片段，给 LLM 提供上下文 | 一份份具体业务文档（说明书、订单） | ❌ 不会 |
| LLM Wiki | AI 领域维基、大模型知识库 | 自动归纳、维护领域制度百科条目 | 整理好的制度、流程、概念 | ❌ 基本不会 |
| 本体 Ontology | 本体、领域知识模型、业务字典 | 定义实体、属性、关系、业务规则 | 业务概念 Schema（类和关系） | ✅ 会，能推理校验 |
用户问："我的订单还能退吗？能退多少？"
Q1: 你只是想让 AI 回答"一堆文档里的问题"？
是 → 先用 RAG（性价比最高，最快落地）
否 ↓
Q2: 你的场景业务规则很强、关系复杂、必须精确校验？
（合同比对、风控、医疗、金融）
是 → RAG + 本体（本体负责懂业务逻辑）
否 ↓
Q3: 你有一堆制度规范、需要整理成可维护的知识？
是 → 在RAG基础上，加 LLM Wiki 管知识能，而且经常一起用。三者不是"三选一"，而是"分工协作"：
组合方式：RAG（检索原文 + 检索 Wiki 条目）→ 本体做实体对齐和规则校验 → 三者信息拼成 Prompt → 丢给大模型 → 输出。组合方案比单独用任何一种效果都更稳。
想象一个图书管理员（大模型）在面对海量书籍：
这三件套，让大模型从"会说话"变成"懂业务、有依据、守规矩"。
| 术语 | 定义 |
|---|---|
| RAG（检索增强生成） | 检索资料片段 + 拼进 Prompt 再让大模型回答，减少幻觉、可溯源 |
| Embedding 向量化 | 把文本转成高维数字向量，语义越像向量越近 |
| 向量库（Vector DB） | 存"向量 + 原文 + 元数据"并按语义相似度快速检索的数据库（Milvus / Qdrant / Chroma） |
| Top-K / Rerank | 召回最相近的 K 段 → 精排模型去噪压缩 |
| 本体（Ontology） | 定义领域概念、属性、关系、规则的 Schema（元模型），能推理校验 |
| LLM Wiki | 用大模型自动归纳维护的领域百科条目知识库 |
| 幻觉（Hallucination） | 大模型编造不存在事实的现象 |