第三章 五分钟看懂 RAG 工作原理（图书馆比喻全程贯穿）

3.1 一个统一的故事

在开始之前，先把整个故事讲完一遍。

你别在意细节，先记住整个画面感：

你有一座超大的私人图书馆。

里面有你所有的合同、笔记、病例、邮件、聊天记录，几万本书。

你雇了一个永远不睡觉的图书管理员。他非常勤快，但也是个"普通人"——没有过目不忘的本事，得靠索引才能找东西。

所以入职第一周，他做了 5 件事：

1. 拆书——把每本书拆成一段一段（切片 / Chunking）；
2. 建索引——给每段写一个"理解摘要"贴在卡片上（嵌入 / Embedding）；
3. 建索引柜——把卡片按"含义相近"摆在一起（向量数据库 / Vector DB）。

准备工作做完之后，每次你向他提问，他就：

4. 找最相关的几张卡片（召回 / Retrieval / Top-K）；
5. 重新精挑细选最相关的几张（重排序 / Reranker）；
6. 把对应的原文摊开摆在桌子上；
7. 请一位"会写报告的助理"（大模型）基于这些原文写答案（生成 / Generation）。

整个 RAG 系统，就是这 7 步。

我们把它叫做 "RAG 七步法"。一旦你看懂这 7 步，你看任何 RAG 工具——NotebookLM、Coze、Dify、Cherry Studio、RAGFlow——都能立刻知道"它在第几步，它做得怎么样"。

3.2 第一步：拆书（切片 / Chunking）

3.2.1 为什么要拆书

想象一本《红楼梦》，120 万字。

你问图书管理员："贾宝玉第一次见林黛玉是在哪？"

如果他给你的方法是：

• "你自己去翻这本 120 万字的书"——那等于他没干活；
• "我把整本书的文字一字不漏念给你听"——那也等于没干活；
• "我整本书的核心思想是关于宝黛爱情……"——这是高度概括，但答不了具体问题。

正确的做法应该是：

• 把 120 万字拆成一段一段；
• 比如以"一回（chapter）"为单位，每回再拆成几段；
• 答你问题时，只把"贾宝玉第一次见林黛玉"那一段抽出来。

这就是"拆书"——把大文档拆成小段，每一段都能独立检索、独立引用。

英文里这一步叫 Chunking（分块），每一段叫 Chunk（块 / 分片）。

3.2.2 怎么拆才合适

拆得太大或太小，都会出问题。

经验值：

• 以"语义段落"为单位：500-1000 字最常见；
• 保留 10-20% 重叠（Overlap）：相邻 chunk 之间留一点重复，避免句子被硬切断；
• 特殊文档特殊处理：PDF 表格按行切，代码按函数切，PPT 按页切。

99% 的工具都自带"默认拆法"，普通人不需要自己设——但懂这个原理你就知道，为什么有时候 RAG 答得很烂——可能就是 chunk 大小不对。

3.2.3 高级版：父子分块 / 语义分块

2026 年最新的 RAG 工具（如 RAGFlow、Dify、Cherry Studio Pro）都开始支持几种"高级切片"：

• 父子分块（Parent-Child Chunking）：搜索时用"小段"找精准位置，回答时用"大段（包含小段的整段）"提供完整上下文。
• 语义分块（Semantic Chunking）：用 AI 判断"哪里该断"——遇到话题转换才断，避免硬切断完整意思。
• 结构化分块（Structured Chunking）：根据 Markdown/HTML 的标题层级自动切——比如 H2 一个 chunk，H3 一个 chunk。

你不用记住这些。**你只要知道"拆书是 RAG 第一步、拆得好不好直接决定后面所有效果"**就够了。

一句话：不是把书丢给 AI，是把"切好的书页"丢给 AI。切得好，效果就好。

3.3 第二步：建索引（嵌入 / Embedding）

3.3.1 为什么要"建索引"

切完书之后，你的图书馆里有几百万段。

你问"贾宝玉第一次见林黛玉"——管理员怎么找到那一段？

最笨的方法：关键词搜索——他去找包含"贾宝玉""林黛玉"的所有段。

但这样有问题：

• 如果原文写的是"宝玉初见黛玉"——关键词搜不到（没"贾"也没"林"）；
• 如果原文写的是"二人相见"——关键词更搜不到（人名都没出现）；
• 如果你问的是"宝玉第一次见到表妹的场景"——表妹也没出现；
• 如果你用英文问 "When did Baoyu first meet Daiyu?"——更没法搜。

这就是"关键词搜索"的局限——它只认"字"，不认"意思"。

要让管理员真正"按意思找"，他得给每段写一张"理解卡片"——卡片上不是原文的字，而是这段的"意思"。

这张"理解卡片"的形式，是一串数字——叫 向量（Vector），也叫 嵌入（Embedding）。

3.3.2 嵌入到底是什么

我们用一个简化的例子。

假设我们的"嵌入"只有 3 个维度：

• 维度 1：和"人物"有多相关（0-1）
• 维度 2：和"事件"有多相关（0-1）
• 维度 3：和"情感"有多相关（0-1）

那么：

你看——

• "宝玉初见黛玉"和"宝黛初会"，虽然字不同，但向量很接近（都是 0.9+, 0.8+, 0.7+）；
• "宝玉初见黛玉"和"贾府日常吃饭"，字也不同，向量也差很远。

这就是嵌入的魔力——字面不同但意思相近的两段话，向量会很接近。

真实的嵌入向量不是 3 维，是 768 维 / 1024 维 / 3072 维——每个维度都代表某个"语义特征"。但原理是一样的——意思相近的内容，向量接近。

3.3.3 谁来"算"这个向量

负责把"文字 → 向量"的程序，叫 嵌入模型（Embedding Model）。

2026 年常用的嵌入模型：

普通人不用自己挑——你用的工具会自动选。但你要知道：

• 中文项目→优先选国内开源的 BGE-M3 或 Qwen-Embed；
• 英文+多语言→优先选 OpenAI 或 Cohere；
• 要"图文一起检索"→选 Jina-Embed v3。

3.3.4 为什么"嵌入模型"很重要

很多人忽略嵌入模型——觉得"反正有就行"。

错了。嵌入模型决定了"管理员能不能听懂你的问题"。

• 嵌入模型差→你问"宝玉第一次见黛玉"，它去找包含这几个字的段落；
• 嵌入模型好→你问"宝玉第一次见黛玉"，它能找到"二人相见""宝黛初会"等所有"意思相同但字不同"的段落。

差一个嵌入模型，召回率可能差 30%。

一句话：嵌入是"给每段写一张意思卡片"。意思卡片相近，就能找到字面不同但语义相近的内容。

3.4 第三步：建索引柜（向量数据库 / Vector DB）

3.4.1 为什么需要专门的数据库

你切完书、写完卡片之后，假设有 10 万张卡片。

你问一个问题，要从 10 万张卡片里找出 "和你的问题向量最接近的 5 张"——怎么找？

最笨：一张一张比对——10 万次计算。慢，但准。

最常用的"向量数据库"提供了"近似最近邻搜索（ANN, Approximate Nearest Neighbor）"——用聪明的索引算法，几毫秒之内从 10 万张里找出最相近的 5 张，准确率 95%+。

3.4.2 常见向量数据库

普通人用 NotebookLM、Cherry Studio、Coze 这些工具，根本不需要自己挑向量数据库——工具内置了。

但你要知道："所有 RAG 工具都内置了一个向量数据库"，它就是那个"索引柜"。

3.4.3 不只是"向量"——元数据也很重要

每张"卡片"上除了向量，还会带一堆 元数据（Metadata）：

• 来自哪个文件
• 第几页
• 创建时间
• 作者
• 标签
• 章节标题
• ……

这些元数据让你能做"带过滤的检索"——比如"只搜 2024 年之后的合同""只搜 张三 写的笔记"。

好的 RAG 系统会自动给每张卡片打很多元数据标签——这是 2026 年提升 RAG 准确率的最大改进点之一。

一句话：向量数据库 = 一个能在毫秒内"按意思找最相近"的超级索引柜。它越聪明，管理员越快。

3.5 第四步：找相关的几张卡片（召回 / Top-K）

3.5.1 召回的基本原理

到这里准备工作就做完了。

现在你向管理员提问：

"贾宝玉第一次见林黛玉时，他说了什么？"

管理员要做的第一件事——把你的问题也变成向量（用同一个嵌入模型）：

"贾宝玉第一次见林黛玉时，他说了什么？" → [0.94, 0.81, 0.69, ...]

然后他拿这个向量，去索引柜里找最接近的 K 张卡片。

K 是你设置的——比如 K=5 表示找 5 张，K=20 表示找 20 张。

这个过程叫 召回（Retrieval），也叫 Top-K 检索——找"最相近的前 K 个"。

3.5.2 K 是越大越好吗

不是。

经验值：K = 5-15 是大多数场景的甜蜜点。

但 K 多大不是万能解——更聪明的做法是先大召回（K=30），再用"重排序"精挑（保留 5）。这就是下一步。

3.5.3 召回不只是"语义召回"——混合检索（Hybrid Search）

只用向量（语义）召回，有时会出问题。

比如你问："请找出所有提到 SKU 编号 'P-2024-1138' 的段落"。

P-2024-1138 这种"专业术语 / 编号 / 人名 / 机构名"，向量搜索可能反而不准——因为它对"字面"的精确匹配没那么在意。

这种时候要加上关键词搜索（BM25 / Full-text Search）——就是传统的 Google 那种"按字面找"。

把 向量搜索 + 关键词搜索 结合起来，叫 混合检索（Hybrid Search）——2026 年所有靠谱的 RAG 系统都默认开启。

一句话：好的 RAG = 语义搜 + 关键词搜 一起上。

3.6 第五步：重排序（Reranker）

3.6.1 为什么要重排序

第四步召回了 30 张卡片。

但 30 张里面，真正最相关的可能只有 3-5 张——其他 25 张是"沾边但不精准"的。

如果直接把 30 张全塞给 AI，AI 看完会被噪音干扰——它可能基于不那么准的几张卡片回答，反而忽略最准的几张。

所以现代 RAG 系统会做一步 "重排序（Reranking）"：

• 第一步：粗召回 30 张（用嵌入向量，快但不准）；
• 第二步：用一个专门的重排序模型对这 30 张精挑——它会逐个评估"这张卡片对这个问题真的相关吗"；
• 第三步：保留最准的 3-5 张，给 AI。

3.6.2 重排序模型为什么准

普通的嵌入模型工作方式是 "独立编码"——卡片向量化和问题向量化是分开的，最后比距离。

重排序模型是 "成对评分"（Cross-Encoder）——把"问题 + 卡片"作为一对输入，让模型直接给出"相关度分数"。

类比：

• 嵌入模型：你看十个相亲对象的照片，凭"感觉"挑 5 个；
• 重排序模型：你和 30 个相亲对象每人聊 5 分钟，挑出最合适的 3 个。

后者更准，但更慢——所以才要"先粗筛 30 个再精挑 3 个"，而不是直接对 10 万张精挑。

3.6.3 常见的重排序模型

2026 年的最佳实践：所有 RAG 都该带 Reranker——它能让答案准确率再提 20-30%。

一句话：召回是"粗筛"，重排序是"精挑"。两者结合，又快又准。

3.7 第六步：把原文摊开（上下文组装）

精挑出 3-5 张卡片之后，管理员做一件事——把每张卡片对应的"原文段落"摊在桌子上。

为什么不直接把"卡片"（向量+摘要）给 AI？

因为 AI 不会读向量。AI 读的是自然语言。

所以这一步叫 "上下文组装（Context Assembly）"——把召回到的几段原文，按某种格式整理好，塞进 AI 的提示词。

比如：

你是一个基于以下资料回答问题的助手。请只基于资料回答。如果资料里没有答案，请说"我在已有资料里没找到答案"。

【资料 1】（来源：红楼梦.pdf 第 3 回）
宝玉看罢，因笑道："这个妹妹我曾见过的。"……

【资料 2】（来源：红楼梦.pdf 第 3 回）
黛玉一见，便吃一大惊，心下想道："好生奇怪，倒像在那里见过一般……"

【用户问题】
贾宝玉第一次见林黛玉时，他说了什么？

【你的回答】

把这一整块塞给 AI，AI 才能基于资料作答。

好的 RAG 系统在"上下文组装"上会做很多优化——

• 去重：相似的段落只保留一条；
• 去无关：明显不相关的段落剔除；
• 重新排序：让最相关的放最前面（避免 Lost in the Middle）；
• 加 metadata：把"来源、页码、作者"也放进上下文；
• 格式化：用 Markdown / XML / JSON 等结构化格式让 AI 更容易理解。

3.7.1 为什么"格式化"很重要

经验上，用 XML 标签包裹的资料，AI 的理解准确率比纯文本高 10-20%。

比如这两种写法：

A 写法：

资料 1: 宝玉看罢...
资料 2: 黛玉一见...
问题: 贾宝玉第一次见林黛玉时说了什么？

B 写法：

<context>
  <document id="1" source="红楼梦.pdf" page="3">
    宝玉看罢，因笑道："这个妹妹我曾见过的。"
  </document>
  <document id="2" source="红楼梦.pdf" page="3">
    黛玉一见，便吃一大惊...
  </document>
</context>

<question>贾宝玉第一次见林黛玉时说了什么？</question>

B 写法 AI 处理起来更准——因为它能清晰地"看见"哪部分是资料、哪部分是问题。

一句话：上下文组装是"摆桌面"的艺术——摆得清楚，AI 才能答得清楚。

3.8 第七步：让 AI 写答案（生成）

终于，AI（"会写报告的助理"）登场了。

它做的事很简单：

• 读完上下文（你摆好的资料）；
• 读完用户问题；
• 基于资料生成答案；
• 标明引用。

这一步是大模型的本职工作——它最擅长的就是"基于一堆文本写答案"。

而且因为有了明确的资料：

• 它不会再编（资料里没的它就说"没找到"）；
• 它会准确引用（甚至能给具体的页码、行号）；
• 它能给结构化输出（表格、列表、对比）。

3.8.1 一个完整的 Prompt 长什么样

我们把整个系统组装起来，看一个真实的 Prompt（你不用记，知道大概样子就行）：

你是一个严谨的资料问答助手。请严格按以下要求作答：

1. 只基于【参考资料】回答问题，不要使用资料外的信息；
2. 每条结论必须标注来源：[文件名 P页码]；
3. 如果资料里没有答案，请明确说"我在已有资料中未找到相关信息"，不要猜测；
4. 用中文回答；
5. 回答尽量结构化（列表/表格）。

<参考资料>
<doc1 source="销售合同_HT-2023-0412.pdf" page="11">
甲方与乙方约定，违约金以合同金额的 28% 计算，最高不超过 100 万元。
</doc1>
<doc2 source="销售合同_HT-2024-0117.pdf" page="9">
违约金按合同金额的 30% 封顶，且不得超过 80 万元。
</doc2>
...
</参考资料>

<用户问题>
我们公司过去三年合同里，违约金条款是怎么约定的？
</用户问题>

<回答>

AI 看完这个 Prompt，会输出一个完全基于资料、有明确引用、不会胡编的答案。

一句话：生成是"读材料 + 写报告"——这是大模型最擅长的。前面 6 步都做对了，这一步就水到渠成。

3.9 全流程一图看懂

flowchart TB
    subgraph PreparePhase[准备阶段 - 一次性做]
        Doc[原始资料] --> Chunk[拆书 Chunking]
        Chunk --> Embed[嵌入 Embedding]
        Embed --> VDB[向量数据库 Vector DB]
    end

    subgraph QueryPhase[问答阶段 - 每次提问]
        Q[用户问题] --> QEmbed[问题向量化]
        QEmbed --> Recall[召回 Top-K 30 张]
        Recall --> Rerank[重排序保留 5 张]
        Rerank --> Assemble[上下文组装]
        Assemble --> LLM[大模型生成答案]
        LLM --> Ans[带引用的答案]
    end

    VDB -.提供.-> Recall

3.10 把 5 个术语讲到爸妈也懂

记住这一句：

拆书 → 写卡 → 入柜 → 找卡 → 精挑 → 摆桌 → 写答案。

七步走，就这么简单。

3.11 几个常见疑问

Q1：为什么不能直接 Ctrl+F 搜，要这么复杂？

Ctrl+F 只认"字面"——你搜"宝玉初见"找不到"宝黛相会"。

向量搜索认"意思"——所以你"换种说法"也能找到。

复杂程度增加，是为了让"搜得到"的范围更大、更准。

Q2：是不是非得用大模型才能 RAG？

不是。没有大模型，RAG 可以变成"高级搜索引擎"——给你返回"最相关的几段原文"。

加了大模型，RAG 变成"问答助手"——基于原文生成自然语言答案。

两者都有用，但绝大多数人想要的是后者。

Q3：所有 RAG 工具内部都长这样吗？

99% 是。

NotebookLM、ima、Coze、Dify、Cherry Studio、AnythingLLM、RAGFlow……它们都是这"七步法"的不同实现。

它们的差别在于：

• 用什么嵌入模型；
• 用什么向量库；
• 用什么重排序；
• 上下文怎么组装；
• 用户界面怎么设计。

底层流程一样。所以你看懂了这一章，就看懂了所有工具的工作原理。

Q4：第 1-3 步只做一次还是每次都做？

只做一次。

你"建库"的时候做（拆书、嵌入、入柜）。建完之后，所有提问都共用这个库。

只有当你新加文档时，才需要把新文档跑一遍 1-3 步——这个过程叫增量索引（Incremental Indexing）。好的工具会自动做。

Q5：为什么有时候 RAG 答得很烂？

99% 是这 5 个原因之一：

1. 资料质量差——OCR 没识别准、PDF 全是图、内容很乱；
2. 切片不合理——chunk 太大或太小、切断了语义；
3. 嵌入模型不行——用了不适合中文的模型；
4. 没有 Reranker——召回的内容太杂，AI 被噪音干扰；
5. 问题问得不好——问题太模糊，AI 不知道你想要什么。

后续章节会详细讲怎么解决每一个。

3.12 RAG 的"高级版本"（先打个预防针）

为了让你以后看到"奇奇怪怪的 RAG 名词"不慌，我们提前打个预防针——下面这些都是"七步法"的变体：

你现在不需要懂这些细节——第 11、12 章会简单介绍。这里只要知道"它们都是七步法的变体"就够了。

3.13 本章一图回顾

flowchart LR
    A[整本书] -->|拆| B[一段一段]
    B -->|写卡片| C[理解卡片向量]
    C -->|入柜| D[向量索引柜]
    Q[问题] -->|向量化| E[问题向量]
    E -->|找最相似| F[召回 30 张]
    F -->|精挑| G[Top 5 张]
    G -->|摊开原文| H[组装上下文]
    H -->|塞给 AI| I[生成答案]
    I --> J[带引用的回答]

记住这三句话：

1. RAG = 七步法（拆、嵌、入、找、挑、摆、答）；
2. 每一步都有可优化空间——所有差异化的工具，都是在某一步上做了优化；
3. 看懂这七步，你就看懂了所有 RAG 工具的内部。

3.14 下一章预告

下一章我们就开始"看市场"——2026 年 AI 知识库工具全景图。

我们会把市面上 30+ 款工具分成 4 档：

• 云端零门槛（NotebookLM、Google Notebooks、ima、文心、通义、豆包、Kimi+）；
• 低门槛 SaaS（Coze、Dify Cloud、Notion AI、FastGPT）；
• 桌面零代码（Cherry Studio、AnythingLLM Desktop、Chatbox、LobeChat）；
• 私有化部署（Dify 自托管、RAGFlow、MaxKB、QAnything、Open WebUI + Ollama）。

每档都给你详细对比、价格、适合场景、坑点。读完下一章，你就能选出"最适合你"的那一款，5 分钟内开始动手。