# 2 - RAG - 搭建企业私有&个人知识库
本章是全书里第一篇把 **RAG 与知识库** 落到产品和平台上的章节。前面的 [1-3 RAG、微调、续训与智能体选型](1-3-RAG、微调、续训与智能体选型.md) 更偏“为什么选 RAG、什么时候该选 RAG”；本章更偏“如果已经决定用 RAG，该怎样把知识库搭起来”；后面的 [19-RAG检索增强生成](19-RAG检索增强生成.md) 会继续从 LangChain 代码侧，把文档加载、切块、Embedding、向量库、检索与生成串成完整工程链路。
---
**本章课程目标：**
- 理解 RAG 是什么、为什么需要，以及它与知识库、向量库、Embedding、提示词增强之间的关系。
- 建立对 RAG 两阶段流程的完整认识：**知识库构建（离线）** 与 **检索生成（在线）**。
- 知道什么是“个人/企业知识库”，哪些人适合先从知识库入手，而不是一上来就考虑微调。
- 能使用 **Cherry Studio**、**ima**、**Dify** 三种方式搭建知识库，保留直观的产品体验与操作路径。
**学习建议：** 这篇适合一边看平台，一边画出 RAG 链路：文档从哪里来、如何切分和索引、用户提问时怎么召回、召回内容又怎么交给模型。按钮不用一次记全，但每做一步都要问自己：这一步是在“准备知识”，还是在“查询知识”。能分清这两段，后面换 Cherry Studio、ima 或 Dify 都不容易迷路。
**官方文档与资源**：详见 [工具导航与参考资料索引 - RAG与向量检索](工具导航与参考资料索引.md#RAG与向量检索)。
---
## 1、RAG 的理解
### 1.1 什么是 RAG
RAG（Retrieval-Augmented Generation，检索增强生成）是一种把 **信息检索** 与 **大模型生成** 结合起来的应用架构。
它的核心思路并不复杂：
1. 用户先提问。
2. 系统先去外部知识源里找相关资料。
3. 把“问题 + 资料”一起发给大模型。
4. 由大模型基于这些资料生成答案。
RAG 的重点不是“重新训练模型”，而是**在运行时给模型补充它当前需要的上下文**。入门阶段先记住：
> **RAG = 先查资料，再回答问题。**
再说得更工程化一点：
- **Retrieval（检索）**：先找到和问题最相关的资料片段。
- **Augmented（增强）**：把检索到的资料拼进当前 Prompt 或消息上下文。
- **Generation（生成）**：让大模型基于这些资料生成最终答案。
所以，RAG 常被形容成“让模型开卷答题”，而不是“再学一遍新知识”。它不改模型参数，不改变模型的“大脑”；它做的是给模型外挂一个可检索的资料层。
### 1.2 为什么需要 RAG
第一次接触知识库时，很多人会把 RAG 当成更高级的聊天技巧。这个理解不准确。RAG 出现的根本原因，是大模型单独使用时天然有几类限制，而这些限制在真实项目里很常见。
常见问题有三类：
- **知识冻结**：模型训练完成后，知识并不会自动随现实世界更新。
- **私有知识缺失**：企业制度、内部文档、项目资料、课程讲义这类内容，模型训练时通常没见过。
- **幻觉与不可追溯**：模型没把握时容易“猜一个像样答案”，而且很难告诉你依据来自哪里。
可以从两个角度理解这件事。
**第一，时间维度。**
随着模型规模增大，训练成本和周期也更高，因此大模型不可能天天重新训练。于是“最新信息、刚变更的信息、实时更新的信息”天然不是它的强项。
**第二，数据来源维度。**
大模型主要学到的是公开语料，而企业内部资料、个人笔记、项目规范、客户材料、课程总结，往往根本不在训练范围内。你直接问模型，它要么不知道，要么半猜半答。
**举例 1：**
随着 LLM 规模扩大，训练成本与周期相应增加。因此，包含最新信息的数据难以融入模型训练过程，无法及时反映最新的信息或动态变化，导致 LLM 难以应对诸如“请推荐当前热门影片”等时间敏感性问题。
**举例 2：**
大型语言模型（LLM）的训练依赖于网络上`海量公开的静态数据`，而某些`特定领域`（如企业内部资料、专有技术文档等）的数据通常不会作为公开的训练数据，导致模型在面对这些领域的查询时，可能因缺乏足够的信息而生成不准确甚至虚构的回复。
RAG 的价值就在这里：它不要求模型“自己就知道”，而是让系统在回答前先去你的资料里找证据。
**解决方案：**
为了解决这一问题，RAG 技术通过引入`向量数据库（Vector Database）`等外部知识源，把模型缺失的知识以结构化、可检索的方式提供出来。完整的 RAG 不只是“向量数据库”四个字，它背后还包括文档加载、清洗、切块、Embedding、检索、Prompt 组装和最终生成等一整条链路。
**举例 1：**
LLM 在考试的时候面对陌生的领域，答复能力有限，然后就准备放飞自我了，而此时 RAG 给了一些提示和思路，让 LLM 懂了开始往这个提示的方向做，最终考试的正确率从 60%到了 90%！
**举例 2：**
放到真实项目里，大致是：
- 公司有制度、产品说明、FAQ、接口文档；
- 模型自己并不知道这些资料；
- 但当用户提问时，系统先去资料里找最相关的部分；
- 然后让模型基于这些资料回答。
这样回答会更像“有依据地作答”，而不是“靠模型印象发挥”。
### 1.3 执行流程
理解 RAG，最重要的是把它看成**两个阶段**，而不是一句“先检索再生成”。
第一阶段是 **知识库构建**，面向的是原始资料；第二阶段是 **检索与答案生成**，面向的是用户提问。
```mermaid
flowchart LR
subgraph Offline["阶段一：知识库构建（离线）"]
D["原始资料
PDF / Word / Markdown / 网页"] --> Parse["文档解析与清洗"]
Parse --> Split["文本切分
Chunk"]
Split --> EmbedDoc["Embedding
文本转向量"]
EmbedDoc --> Store["向量库 / 知识库
保存文本块、向量、元数据"]
end
subgraph Online["阶段二：检索与生成（在线）"]
Q["用户问题"] --> EmbedQuery["问题向量化"]
EmbedQuery --> Retrieve["检索相关文本块"]
Store --> Retrieve
Retrieve --> Augment["Prompt 增强
问题 + 检索结果"]
Augment --> LLM["大模型生成"]
LLM --> Answer["带依据的回答"]
end
```
**流程说明：**
整张图分为**两个阶段**：上方是**知识库构建**，下方是**查询与答案生成**。它做的事情是：先把本地文档变成一个可检索的知识库，再在用户提问时动态查资料，并把资料增强进模型输入。
| 步骤 | 英文名 | 中文名 | 在做什么 |
| -------------------------- | ------------------- | -------------- | ---------------------------------------------------------------------------- |
| **阶段一：知识库构建** |
| 1 | Local Documents | 本地文档 | 流程起点：你的 PDF、Word、Markdown、TXT 等原始文件，是私有知识库的数据来源。 |
| 2 | Unstructured Loader | 非结构化加载器 | 读取并解析各种格式的本地文档，从中抽出纯文本，统一成后续可处理的格式。 |
| 3 | Text | 文本 | 加载器产出的纯文本内容。 |
| 4 | Text Splitter | 文本分割器 | 把长文本按规则切成小块，便于嵌入和放入 LLM 上下文。 |
| 5 | Text Chunks | 文本块 | 分割后得到的一段段文本，是后续嵌入和检索的基本单位。 |
| 6 | Embedding | 嵌入 | 用嵌入模型把每个文本块转成向量。语义相近的块，向量距离也更近。 |
| 7 | VectorStore | 向量存储 | 把文本块的向量、原文和元数据存入向量数据库，支持后续按相似度检索。 |
| **阶段二：查询与答案生成** |
| 8 | Query | 查询 | 用户用自然语言提出的问题或请求。 |
| 9 | Embedding | 嵌入 | 用**同一套**嵌入模型把用户查询也转成向量，保证和知识库在同一向量空间里。 |
| 10 | Query Vector | 查询向量 | 用户查询的向量表示。用它去向量库里找最相关的文档块。 |
| 11 | Vector Similarity | 向量相似度 | 在向量存储中做相似度搜索，找出与问题最接近的文本块。 |
| 12 | Related Text Chunks | 相关文本块 | 检索得到的文本片段，是回答问题时最关键的依据。 |
| 13 | Prompt Template | 提示模板 | 把“用户问题 + 检索结果”组装成一段结构化输入。这里对应 RAG 里的“增强”。 |
| 14 | Prompt | 提示 | 最终送入大模型的内容。 |
| 15 | LLM | 大语言模型 | 基于检索结果和用户问题生成答案。这里对应 RAG 里的“生成”。 |
| 16 | Answer | 答案 | 模型基于检索到的资料给出的最终回答。 |
> 检索-增强-生成过程：**检索**对应第 9 ～ 11 步（查询嵌入 → 查询向量 → 向量相似度搜索）；**增强**对应第 13 步（把检索结果注入到提示词 / 消息上下文）；**生成**对应第 15 步（LLM 输出答案）。
> **你可能会问：** 为什么“建知识库”和“用户提问时”都要用**同一套**嵌入模型？因为嵌入模型本质上是在定义一套“语义坐标系”。建库用模型 A、提问时用模型 B，就像拿两种完全不同的尺子去量距离，算出来的相似度会乱掉，检索效果就会明显变差。
理解这张图时，还建议先记住四个最容易混的词：
- **知识库**：承载外部知识的整体容器，可能包含文档、分块、向量、元数据、检索配置等。
- **向量库**：知识库内部用于做相似度检索的存储组件，不等于整个知识库。
- **Embedding**：把文本变成向量的模型或过程。
- **Prompt 增强**：把检索结果交给模型的那一步。
如果你后面继续看 [19-RAG检索增强生成](19-RAG检索增强生成.md)，会发现这四个词会分别落到更具体的代码对象上，例如：
- 文档 -> `Document`
- 文本分割 -> `TextSplitter`
- 向量化 -> `Embeddings`
- 检索 -> `Retriever`
- 增强输入 -> `PromptTemplate / ChatPromptTemplate`
**强调一下难点的步骤（蓝色部分）：**
这张图提醒的是：RAG 最难的地方通常不在“上传文件”本身，而在这些环节是否做得合理：
- 文档有没有被正确解析
- 文本是不是切得太碎或太大
- Embedding 模型是否合适
- 检索出来的内容是否真的相关
- 拼给模型的上下文里有没有太多噪音
RAG 不是“有知识库就一定答得好”，而是“知识库链路质量越高，回答越稳”。
### 1.4 RAG 工程质量框架
理解流程之后，再看一个更贴近真实项目的问题：**为什么同样叫知识库，有的回答很稳，有的却经常胡说？**
可以用这个公式做排查：**RAG 效果 = 文档质量 x 解析质量 x 切分质量 x 检索质量 x 重排质量 x Prompt 组织质量 x 生成模型质量 x 评测闭环**
这里的乘号表示：只要某个环节特别差，整体效果就会被明显拉低。
知识库答不准时，不要一上来就怪模型。可以先看现象，再往回查：
```mermaid
flowchart TD
Start["RAG 效果不好"] --> A{"完全找不到资料？"}
A -- "是" --> A1["查入库链路
文档是否上传、解析是否成功、Embedding 是否一致"]
A -- "否" --> B{"召回内容答非所问？"}
B -- "是" --> B1["查检索策略
关键词检索、向量检索、Top K、阈值、Rerank"]
B -- "否" --> C{"资料找到了但模型乱答？"}
C -- "是" --> C1["查 Prompt 约束
仅基于资料回答、允许不知道、要求引用来源"]
C -- "否" --> D{"答案不完整或漏重点？"}
D -- "是" --> D1["查上下文组织
Chunk 大小、Overlap、Top K、上下文窗口"]
D -- "否" --> E{"无法追溯来源？"}
E -- "是" --> E1["查元数据与引用
文件名、页码、标题、段落 ID"]
E -- "否" --> F["整理一组测试问题
记录召回片段、引用和最终答案"]
```
---
## 2、知识库的概述
这一节从“产品使用者”的角度来理解知识库。可以把知识库理解成：**把你的资料做成可检索、可引用、可被大模型调用的一套外部知识层。**
它不只是一个“文件夹”，也不只是一个“向量库”：
- 从用户视角看，知识库像是“把很多资料整理成一个能问答的仓库”。
- 从工程视角看，知识库背后通常包含文档、切块、Embedding、向量检索、元数据、召回策略等多个环节。
### 2.1 什么是知识库
先给一个简短定义：
> **知识库 = 让模型能访问你自己的资料，并在提问时按需调用这些资料。**
它特别适合下面这些人群：
**小型企业主或创业者：**
经常要查阅和分享制度文档、产品说明、客户反馈、市场分析。把这些资料整理成知识库后，问答和复用效率会明显提高。
**职场打工人或自由职业者：**
无论是写作、设计、开发，还是视频制作，你都会积累大量素材、需求、规范和项目资料。知识库的价值不是“存起来”，而是“下次还能快速找到并继续用”。
**教育工作者或学生：**
老师可以整理课程资料、讲义、案例、答疑文档；学生可以把课堂笔记、论文资料、考试重点、知识点总结做成自己的复习型知识库。
**生活中的普通人：**
旅行计划、阅读笔记、兴趣资料、学习记录、求职资料，全部都可以做成个人知识库。知识库不是企业专属工具，它同样适合个人成长与日常信息管理。
从“为什么值得做”这个角度看，知识库至少有三层价值：
- **管理资料**：资料不再散落在聊天记录、网盘、文件夹里。
- **快速检索**：不必每次手动翻 PDF 或翻网页。
- **增强生成**：检索结果还能继续交给模型做总结、改写、问答和二次创作。
### 2.2 知识库各个搭建平台对比
本仓库里会分别从**平台搭建**和**代码实现**两个方向讲 RAG。站在平台视角，你可以先把常见工具按能力定位分成三类。这里列举的是学习和选型时常见的代表工具，不是固定排名；具体功能、价格和部署方式会随版本变化，以各平台官方说明为准。
1. **个人轻量型**：上手快、图形化强、适合个人或小团队先做 Demo。
2. **平台协作型**：不仅能做知识库，还能接工作流、应用发布、团队协作。
3. **复杂文档解析型**：重点是文档理解质量，尤其适合长 PDF、复杂表格、扫描件。
**2.2.1 核心定位和技术特点**
**AnythingLLM、Cherry Studio**：`桌面/图形化 AI 助手 + 知识库（RAG）`，支持对接云模型与本地模型，适合`个人/小团队`快速验证。在“多租户治理、复杂系统集成、生产化观测”等方面通常不如平台型产品。
**Dify、FastGPT**：`LLM 应用与工作流编排平台`，支持创建知识库，并把知识库接到对话应用、工作流、Agent 中，更适合“从 Demo 走向团队协作和应用交付”的场景。
**RAGFlow**：强调`复杂文档解析`、`高精度混合检索`、`重排`、`可视化干预`，适合把“文档解析质量”和“召回质量”看得很重的场景。这类工具的重点不是“能不能上传文件”，而是能不能把复杂文档解析成更适合检索和引用的知识片段。
**2.2.2 典型场景与选型建议**
**1. 个人知识管理（轻量级）**
- 需求：快速验证、低预算、个人/小团队使用，以“先跑起来”为主。
- 推荐工具：Cherry Studio / AnythingLLM / ima
- 理由：
- 部署和操作简单，上手快
- 适合接在线模型 API，也可接本地模型
- 更适合做“个人知识助手”而不是复杂业务平台
**2. 应用化交付与团队协作（平台型场景）**
- 需求：将知识库能力封装成可复用 AI 应用、支持多人协作、工作流编排、权限与版本管理。
- 推荐工具：Dify / FastGPT
- 理由：
- 知识库只是整个平台的一部分，后续还能接工作流、工具调用、Agent
- 更适合与业务系统集成
- 更贴近“内部产品交付”而不是单机个人使用
**3. 企业级文档解析（高精度需求）**
- 需求：处理复杂版式、长 PDF、扫描件、图文混排、表格等，强调解析质量与引用可追溯。
- 推荐工具：RAGFlow
- 理由：
- 更强调文档理解与检索精度
- 支持混合检索、重排与更强的文档处理链路
- 适合把“RAG 效果”当成核心竞争力的场景
---
## 3、Cherry Studio 搭建个人知识库
> 后续我们会重点拿 Coze 和 Dify 讲工作流和智能体，所以知识库这里，先选更适合个人快速上手的 **Cherry Studio** 和腾讯出品的 **ima**。
### 3.1 Cherry Studio 特点
Cherry Studio 更适合被理解成一个“**个人向、桌面化、模型聚合型 AI 工作台**”。它的优势不是企业平台能力，而是：上手快；图形化强；适合个人快速搭知识库和多模型对比。
**小白友好**：Cherry Studio 致力于降低技术门槛，零基础用户也能快速上手，让用户更专注于工作、学习或创作本身。
**一问多答**：支持同一问题通过多个模型同时生成回复，方便对比不同模型的表现。
**助手市场**：内置千余个行业专用助手，涵盖翻译、编程、写作等场景，同时支持自定义助手。
**服务商模型聚合**：支持 OpenAI、Gemini、Anthropic、Azure 等规范的三方服务商接入，兼容性较强。
**数据安全**：支持全本地场景使用，结合本地大模型时，更适合对数据安全较敏感的用户。
### 3.2 LLM 的使用
在 Cherry Studio 里，知识库问答并不是“只要上传文件就行”。你至少要先把**聊天模型**和**Embedding 模型**两个角色理解清楚：
- **聊天模型（LLM）**：负责最后生成回答。
- **Embedding 模型**：负责把文档和问题变成向量，用于检索。
所以要先完成模型接入。
**步骤 1：下载与安装客户端工具**
下载地址：https://www.cherry-ai.com/download
**步骤 2：硅基流动注册账号**
这里的大模型服务，以硅基流动平台为例说明。
网址：https://siliconflow.cn/zh-cn/models
**步骤 3：创建 API 密钥**
**步骤 4：复制 API 密钥**
**步骤 5：配置 API 密钥**
**步骤 6：选择大语言模型**
到这里完成的是“生成模型”接入，也就是后面负责回答问题的那部分能力。
### 3.3 知识库的使用
这一部分是从“普通聊天”进入“知识库问答”的关键。建议你一边做，一边记住：**上传文档不是终点，能不能检索对、能不能基于知识库生成，才是效果关键。**
**步骤 1：添加嵌入模型**
根据下图确认名称：
回到 Cherry Studio 添加：
这一步对应的是 RAG 里的“Embedding”环节。后续上传文档建库、用户提问检索，都会依赖这一模型。
**步骤 2：创建知识库**
提供知识库内容：
这里支持不同格式文件、文件夹、网页地址、大段文本内容等多种方式添加到知识库。
> 注意：上传文件如果包含大量手写内容、复杂表格、扫描件、公式或复杂版式，解析效果通常会明显下降。很多人以为“RAG 效果差”是模型问题，实际上常常是文档解析阶段已经出了问题。
**步骤 3：支持直接检索**
检索：
这里展示的是“先搜知识库”的能力。此时系统还没有让大模型长篇生成，而是在数据库中基于 RAG 思路做召回。相关片段和匹配得分都能看到，很适合用来排查效果。
**步骤 4：基于知识库生成**
选中后，提问：
这一步对应的才是“完整 RAG”：先检索，再增强上下文，再由模型生成答案。
**补充：增强文档解析能力**
如果上传文件中有手写内容、复杂表格、扫描件或复杂公式，解析效果会较差。此时可以先用专门的文档解析工具做预处理，再把处理后的内容上传到知识库。
使用工具：Doc2X
网址：https://doc2x.noedgeai.com/
这里你要建立一个很实用的工程意识：
- **RAG 效果不是只由大模型决定**，还会受到文档质量、解析质量、切分质量、检索质量、重排质量和 Prompt 组织质量影响。
- 不是所有问题都该怪模型，很多问题发生在前面的数据链路里。
### 3.4 流程分析
Cherry Studio 这整套流程可以拆成：
1. 接好聊天模型
2. 接好 Embedding 模型
3. 上传文档并建知识库
4. 先检索相关内容
5. 再基于知识库生成回答
这条链路和前面第 1 节讲的 RAG 标准流程是一一对应的。也正因为如此，后面你切换到 Dify、LangChain、RAGFlow 时，虽然界面不同，但底层思路并没有变。
---
## 4、ima 搭建个人知识库
### 4.1 ima 特点
如果说 Cherry Studio 更像“桌面化模型工作台”，那么 **ima** 更像“更偏 C 端、更轻量、上手成本更低的知识助手”。它特别适合初学者快速体验“把资料接进模型”这件事。
- **操作简单、零上手成本**：界面和流程都很直观，更偏普通用户使用。
- **多端同步**：支持客户端、小程序、网页等多端访问与同步。
- **共享知识库**：支持将知识库分享给他人，方便协作与传递。
- **模型与入口**：通常会接入平台方提供或合作的大模型能力，并支持通过客户端、微信等入口提问，模型基于知识库生成答案。具体模型名称和入口形态会随产品版本变化。
在入门阶段，ima 的价值主要是：**很容易先建立“知识库问答”的使用直觉**。它的可定制化不如 Dify，但上手门槛更低。
### 4.2 搭建知识库过程
**步骤 1：下载与安装**
网址：https://ima.qq.com/
**步骤 2：新建知识库**
**步骤 3：导入本地文件**
**步骤 4：基于知识库「生成」**
这部分最值得你体会的是：即使平台界面和 Cherry Studio 不同，但底层做的事情仍然是同一套逻辑：
- 把文件导入
- 变成可检索内容
- 用户提问
- 检索知识
- 基于知识回答
### 4.3 组合互联网网页构成知识库
知识库不一定只来自本地文件，也可以来自网页内容。这个能力在做个人学习型知识库时很常用。
步骤 1：在微信公众号中搜索相关主题的文章，并将它们加入到 ima。
步骤 2：在 ima 中新建个人知识库，将相关文章加入到此知识库。
步骤 3：文章导入完成后，即可生成知识库，并基于大模型进行检索与问答。
这个案例很有代表性，因为它说明了一个重要认知：
> **知识库不等于“上传 PDF”**。只要资料能整理成可用文本，它就有机会成为知识库的一部分。
### 4.4 添加第三方知识库
这一点对应的是“知识库协作和复用”的能力。对于企业或团队来说，知识库的价值不只是你自己能查，而是它能成为多人共享的知识入口。
---
## 5、使用 Dify 搭建知识库
### 5.1 Dify 介绍
Dify 是一个开源的大语言模型（LLM）应用开发平台。和 Cherry Studio、ima 相比，它更偏向“**应用平台 + 工作流平台 + 知识库平台**”的综合形态。
这意味着 Dify 里的知识库不只是“让你自己问答”的工具，还可以继续被接到：
- 聊天应用
- 工作流
- Agent
- API 对外服务
结合官方文档，Dify 知识库可以理解为：
- 知识库是你自有数据的集合
- 每个知识库可以包含多个文档
- 每个文档最终会被切成多个分段（chunks）
- 应用在运行时会从这些分段中检索相关内容，再交给模型生成回答
所以，如果 Cherry Studio / ima 更像“个人先用起来”，Dify 更像“知识库要进入产品和工作流体系”。
### 5.2 源数据格式
通过 Dify，可以方便快捷地构建私有知识库，并进一步把知识库放到工作流和应用中协同使用。Dify 提供了相对完整的可视化界面来管理文档、分段、检索策略和应用接入。
目前 Dify 支持多种源数据格式，包括：
- **长文本内容**：TXT、Markdown、DOCX、HTML、JSON、PDF
- **结构化数据**：CSV、Excel
从 Dify 官方知识库文档的表述看，知识库里最关键的对象关系是：
- **Knowledge Base（知识库）**：整体容器
- **Document（文档）**：导入的文件或数据源
- **Chunk（分段）**：文档切分后的可检索片段
**注：** 私有知识库要达到较好效果，通常需要配合 **Embedding 模型**与 **Rerank 模型**使用。Embedding 决定“怎么找相关文本”，Rerank 决定“候选结果怎么重新排序”。在要求更高的场景下，Rerank 往往值得开启。
### 5.3 构建私有知识库
这一部分的重点不只是“按步骤点完”，更重要的是理解：**为什么这些参数会直接影响最终知识库问答质量。**
**步骤 1：首先创建一个新的知识库**
**步骤 2：上传知识库文件**
这里准备的是一份《刑法》的 TXT 格式文本，按自然段划分了每一条法条。
这个案例适合作为入门演示，因为法律条文天然分段清晰、知识边界明确，也更容易观察检索是否准确。
**步骤 3：分段设置**
大语言模型存在有限的上下文窗口，因此通常需要先把长文本进行分段，再从中召回与问题关联度最高的几个段落。分段太粗会带来噪音，分段太细又会把语义切碎，所以“怎么切块”是 RAG 里最关键的调参点之一。
分段标识符如果是 `\n`，则是以换行为一个分段；如果是 `\n\n`，则是以一个段落为一个分段。点击“预览块”可以查看目前块划分的情况。
分段重叠长度一般是分段最大长度的 `10%-20%`。
知识库文档中若有 URL、邮箱等，也可以在预处理时过滤掉。
**分段设置说明（这些项是干嘛的、对知识库有什么影响）**
| 配置项 | 作用 | 对知识库的影响 |
| ---------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **分段标识符** | 决定“按什么边界”把长文切成小块。`\n` = 按换行切，`\n\n` = 按空行切。 | 选得合适，切出来的块语义更完整；选得不合适，可能把一整段话切碎，后面检索就容易只命中半句。 |
| **分段最大长度** | 单块文本的字数 / 字符上限，超过就再切一刀。 | 设太大，单块里无关内容太多，容易把噪音带进 Prompt；设太小，语义被拆散，召回容易漏关键信息。一般可从 200～800 字（或约 100～500 token）起步，再按文档类型调。 |
| **分段重叠长度** | 相邻两块之间重复一段文字，避免边界处语义断裂。 | 有一定重叠，边界上的句子不容易被截断；重叠太大则会造成内容重复、存储浪费和检索噪声。 |
**步骤 4：选择索引方式**
这里自动选择高质量。高质量的准确性更高，但 token 消耗也会增加；如果用的是本地部署模型，成本敏感度会低一些。
还有 **Q&A 方式**：如果文档本身就是问答对形式，这种方式通常更契合。
**步骤 5：检索设置**
在这里可选择 **Embedding 模型**与 **Rerank 模型**，也可以设置 Top K，也就是选出最相似的前 n 条。还可以设置 Score 阈值，即筛选文本的相似度下限。
混合检索：既包括向量检索（可选用 Rerank 模型做精排），也包含全文检索。
**检索设置说明（这些项是干嘛的、对知识库有什么影响）**
| 配置项 | 作用 | 对知识库的影响 |
| ------------------ | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Embedding 模型** | 把“文档块”和“用户问题”都变成向量，用来算语义相似度。 | 建库和检索必须用**同一个** Embedding 模型，否则向量不在同一个空间里，检索效果会明显变差。 |
| **向量检索** | 用问题向量在向量库里找“最像”的文档块。 | 是 RAG 的核心检索步骤，没有它就无法按语义从知识库中召回内容。 |
| **Rerank 模型** | 在向量检索拿到一批候选块后，再用专门模型对“问题 + 每条候选”打更精细的相关性分。 | 不开 Rerank 时，只靠向量相似度，有时会混进“看起来相关但答非所问”的片段；开启后通常能显著提升最终送给模型的上下文质量，但也会增加延迟与成本。 |
| **Top K** | 检索时最多取几条文档块交给后续步骤。 | K 太小，可能漏掉关键信息；K 太大，又容易把无关内容塞进上下文，增加噪音与 token 开销。一般可先试 5，再根据效果微调。 |
| **Score 阈值** | 相似度下限，只有达到阈值的块才会被保留。 | 阈值高，结果更干净但可能漏召回；阈值低，信息更全但噪音变多。排查效果时，可以根据“找不到内容”还是“召回太杂”来升降阈值。 |
| **混合检索** | 同时做向量检索和全文检索，再合并、去重、排序。 | 当文档里既有自然语言段落，又有条目编号、专有名词、法条编号时，混合检索通常比纯向量检索更稳。 |
设置完成后，保存并处理即可。
这一节最值得你带走的工程结论是：
> **RAG 的效果，不是“上传完文件”那一刻决定的，而是由文档质量、切块策略、Embedding 质量、检索策略和重排策略共同决定的。**
如果你想继续把这些平台里的配置项和代码实现一一对上，可以把这一节和 [19-RAG检索增强生成](19-RAG检索增强生成.md) 的“文档加载器、文本分割器、检索器”几节对照着看，理解会更快。
### 5.4 测试
接下来进行测试。创建一个聊天助手，将提示词设置为：
```text
你是一个法律小助手，请只根据知识库中的信息，简要回答用户提问的案件触犯了哪些法律
```
知识库选择刚才添加的 `刑法.txt`，然后可以开始提问。
可以观察到，聊天助手会自动引用知识库中的内容进行回答。
这个案例和前面 Cherry Studio、ima 的案例一起看，会更容易形成完整理解：
- Cherry Studio：更适合个人快速搭一个知识库试试效果
- ima：更适合普通用户低门槛体验知识库问答
- Dify：更适合把知识库放进应用、工作流和团队协作环境里
---
**章节思考题：**
1. 如果一个知识库问答效果不好，你会先检查文档、切块、Embedding、检索参数还是提示词？为什么？
**参考思路：** 先看问题表现。完全找不到资料，优先查文档是否入库、切块是否合理、Embedding 是否一致；召回很多杂内容，再调 Top K、阈值、Rerank；召回对了但回答乱，再看提示词和引用约束。
2. 为什么“上传了文件”不等于“知识库已经可用”？
**参考思路：** 文件还要被解析、清洗、切块、向量化、写入索引，并且查询时能被正确召回。任何一环出问题，用户看到的都是“答不准”。知识库质量不是上传动作决定的，而是整条处理链路决定的。
3. Cherry Studio、ima、Dify 这类平台适合分别用来验证什么？
**参考思路：** Cherry Studio 适合个人快速试效果，ima 适合低门槛体验知识库问答，Dify 更适合把知识库接进应用、工作流和团队协作。选择平台时看目标是个人验证、普通使用，还是工程交付。
4. 给一个新人解释 Top K、阈值、Rerank 时，你会用什么排查例子？
**参考思路：** 可以用“查资料”类比：Top K 决定拿几段材料，阈值决定太不相关的材料要不要丢掉，Rerank 决定候选材料重新排序。答案漏信息时可能 K 太小或阈值太高，答案跑偏时可能 K 太大或缺少重排。
**本章小结：**
- **RAG 是什么**：检索（从你的文档里找相关段落）→ 增强（把段落塞进当前输入）→ 生成（大模型基于这些内容回答）；它不改模型参数，而是在运行时补上下文。
- **为什么需要 RAG**：它主要解决知识冻结、私有知识缺失、最新信息不可用和幻觉等问题。很多业务问题本质上不是“模型不会”，而是“模型没看到资料”。
- **知识库是什么**：知识库是承载外部知识的整体容器，不等于向量库。知识库背后通常包含文档、分块、Embedding、检索、元数据和检索策略等环节。
- **三类平台怎么理解**：Cherry Studio、ima 适合个人快速上手；Dify 更适合应用化交付和工作流集成；RAGFlow 更适合复杂文档解析和高精度检索场景。
- **真正影响效果的因素**：文档质量、解析质量、分块策略、Embedding 模型、Rerank、Top K、阈值，都会直接影响“查得准不准、答得稳不稳”。
**建议下一步：**
- 如果你想继续往平台化应用和工作流方向走，建议接着看 [3-基于Coze&Dify平台的智能体开发](3-基于Coze&Dify平台的智能体开发.md) 和 [4-Python调用Dify平台工作流](4-Python调用Dify平台工作流.md)。
- 如果你想从代码角度真正把 RAG 跑起来，建议先看 [18-向量数据库与Embedding实战](18-向量数据库与Embedding实战.md)，再继续看 [19-RAG检索增强生成](19-RAG检索增强生成.md)。