2 - RAG - 搭建企业私有&个人知识库

本章是全书里第一篇把 RAG 与知识库 落到产品和平台上的章节。前面的 1-3 RAG、微调、续训与智能体选型更偏“为什么选 RAG、什么时候该选 RAG”；本章更偏“如果已经决定用 RAG，该怎样把知识库搭起来”；后面的 19-RAG检索增强生成会继续从 LangChain 代码侧，把文档加载、切块、Embedding、向量库、检索与生成串成完整工程链路。

本章课程目标：

理解 RAG 是什么、为什么需要，以及它与知识库、向量库、Embedding、提示词增强之间的关系。
建立对 RAG 两阶段流程的完整认识：知识库构建（离线） 与 检索生成（在线）。
知道什么是“个人/企业知识库”，哪些人适合先从知识库入手，而不是一上来就考虑微调。
能使用 Cherry Studio、ima、Dify 三种方式搭建知识库，保留直观的产品体验与操作路径。

学习建议： 这篇适合一边看平台，一边画出 RAG 链路：文档从哪里来、如何切分和索引、用户提问时怎么召回、召回内容又怎么交给模型。按钮不用一次记全，但每做一步都要问自己：这一步是在“准备知识”，还是在“查询知识”。能分清这两段，后面换 Cherry Studio、ima 或 Dify 都不容易迷路。

官方文档与资源：详见工具导航与参考资料索引 - RAG与向量检索。

1、RAG 的理解

1.1 什么是 RAG

RAG（Retrieval-Augmented Generation，检索增强生成）是一种把 信息检索 与 大模型生成 结合起来的应用架构。

它的核心思路并不复杂：

用户先提问。
系统先去外部知识源里找相关资料。
把“问题 + 资料”一起发给大模型。
由大模型基于这些资料生成答案。

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%！

RAG 通过外部知识提示模型答题并提升正确率的示意图

举例 2：

RAG 结合外部资料回答领域问题的示意图

放到真实项目里，大致是：

公司有制度、产品说明、FAQ、接口文档；
模型自己并不知道这些资料；
但当用户提问时，系统先去资料里找最相关的部分；
然后让模型基于这些资料回答。

这样回答会更像“有依据地作答”，而不是“靠模型印象发挥”。

1.3 执行流程

理解 RAG，最重要的是把它看成两个阶段，而不是一句“先检索再生成”。

第一阶段是 知识库构建，面向的是原始资料；第二阶段是 检索与答案生成，面向的是用户提问。

flowchart LR
    subgraph Offline["阶段一：知识库构建（离线）"]
        D["原始资料<br/>PDF / Word / Markdown / 网页"] --> Parse["文档解析与清洗"]
        Parse --> Split["文本切分<br/>Chunk"]
        Split --> EmbedDoc["Embedding<br/>文本转向量"]
        EmbedDoc --> Store["向量库 / 知识库<br/>保存文本块、向量、元数据"]
    end

    subgraph Online["阶段二：检索与生成（在线）"]
        Q["用户问题"] --> EmbedQuery["问题向量化"]
        EmbedQuery --> Retrieve["检索相关文本块"]
        Store --> Retrieve
        Retrieve --> Augment["Prompt 增强<br/>问题 + 检索结果"]
        Augment --> LLM["大模型生成"]
        LLM --> Answer["带依据的回答"]
    end

LangChain 与 ChatGLM 构建知识库及问答流程的整体示意图

流程说明：

整张图分为两个阶段：上方是知识库构建，下方是查询与答案生成。它做的事情是：先把本地文档变成一个可检索的知识库，再在用户提问时动态查资料，并把资料增强进模型输入。

步骤	英文名	中文名	在做什么
阶段一：知识库构建
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	答案	模型基于检索到的资料给出的最终回答。

RAG 从知识库构建到检索增强生成的完整架构图

检索-增强-生成过程：检索对应第 9 ～ 11 步（查询嵌入 → 查询向量 → 向量相似度搜索）；增强对应第 13 步（把检索结果注入到提示词 / 消息上下文）；生成对应第 15 步（LLM 输出答案）。

你可能会问： 为什么“建知识库”和“用户提问时”都要用同一套嵌入模型？因为嵌入模型本质上是在定义一套“语义坐标系”。建库用模型 A、提问时用模型 B，就像拿两种完全不同的尺子去量距离，算出来的相似度会乱掉，检索效果就会明显变差。

理解这张图时，还建议先记住四个最容易混的词：

知识库：承载外部知识的整体容器，可能包含文档、分块、向量、元数据、检索配置等。
向量库：知识库内部用于做相似度检索的存储组件，不等于整个知识库。
Embedding：把文本变成向量的模型或过程。
Prompt 增强：把检索结果交给模型的那一步。

如果你后面继续看 19-RAG检索增强生成，会发现这四个词会分别落到更具体的代码对象上，例如：

文档 -> Document
文本分割 -> TextSplitter
向量化 -> Embeddings
检索 -> Retriever
增强输入 -> PromptTemplate / ChatPromptTemplate

强调一下难点的步骤（蓝色部分）：

RAG 中最容易影响效果的关键步骤示意图

这张图提醒的是：RAG 最难的地方通常不在“上传文件”本身，而在这些环节是否做得合理：

文档有没有被正确解析
文本是不是切得太碎或太大
Embedding 模型是否合适
检索出来的内容是否真的相关
拼给模型的上下文里有没有太多噪音

RAG 不是“有知识库就一定答得好”，而是“知识库链路质量越高，回答越稳”。

1.4 RAG 工程质量框架

理解流程之后，再看一个更贴近真实项目的问题：为什么同样叫知识库，有的回答很稳，有的却经常胡说？

可以用这个公式做排查：RAG 效果 = 文档质量 x 解析质量 x 切分质量 x 检索质量 x 重排质量 x Prompt 组织质量 x 生成模型质量 x 评测闭环

这里的乘号表示：只要某个环节特别差，整体效果就会被明显拉低。

知识库答不准时，不要一上来就怪模型。可以先看现象，再往回查：

flowchart TD
    Start["RAG 效果不好"] --> A{"完全找不到资料？"}
    A -- "是" --> A1["查入库链路<br/>文档是否上传、解析是否成功、Embedding 是否一致"]
    A -- "否" --> B{"召回内容答非所问？"}
    B -- "是" --> B1["查检索策略<br/>关键词检索、向量检索、Top K、阈值、Rerank"]
    B -- "否" --> C{"资料找到了但模型乱答？"}
    C -- "是" --> C1["查 Prompt 约束<br/>仅基于资料回答、允许不知道、要求引用来源"]
    C -- "否" --> D{"答案不完整或漏重点？"}
    D -- "是" --> D1["查上下文组织<br/>Chunk 大小、Overlap、Top K、上下文窗口"]
    D -- "否" --> E{"无法追溯来源？"}
    E -- "是" --> E1["查元数据与引用<br/>文件名、页码、标题、段落 ID"]
    E -- "否" --> F["整理一组测试问题<br/>记录召回片段、引用和最终答案"]

2、知识库的概述

这一节从“产品使用者”的角度来理解知识库。可以把知识库理解成：把你的资料做成可检索、可引用、可被大模型调用的一套外部知识层。

它不只是一个“文件夹”，也不只是一个“向量库”：

从用户视角看，知识库像是“把很多资料整理成一个能问答的仓库”。
从工程视角看，知识库背后通常包含文档、切块、Embedding、向量检索、元数据、召回策略等多个环节。

2.1 什么是知识库

先给一个简短定义：

知识库 = 让模型能访问你自己的资料，并在提问时按需调用这些资料。

它特别适合下面这些人群：

小型企业主或创业者：
经常要查阅和分享制度文档、产品说明、客户反馈、市场分析。把这些资料整理成知识库后，问答和复用效率会明显提高。

职场打工人或自由职业者：
无论是写作、设计、开发，还是视频制作，你都会积累大量素材、需求、规范和项目资料。知识库的价值不是“存起来”，而是“下次还能快速找到并继续用”。

教育工作者或学生：
老师可以整理课程资料、讲义、案例、答疑文档；学生可以把课堂笔记、论文资料、考试重点、知识点总结做成自己的复习型知识库。

生活中的普通人：
旅行计划、阅读笔记、兴趣资料、学习记录、求职资料，全部都可以做成个人知识库。知识库不是企业专属工具，它同样适合个人成长与日常信息管理。

从“为什么值得做”这个角度看，知识库至少有三层价值：

管理资料：资料不再散落在聊天记录、网盘、文件夹里。
快速检索：不必每次手动翻 PDF 或翻网页。
增强生成：检索结果还能继续交给模型做总结、改写、问答和二次创作。

2.2 知识库各个搭建平台对比

本仓库里会分别从平台搭建和代码实现两个方向讲 RAG。站在平台视角，你可以先把常见工具按能力定位分成三类。这里列举的是学习和选型时常见的代表工具，不是固定排名；具体功能、价格和部署方式会随版本变化，以各平台官方说明为准。

个人轻量型：上手快、图形化强、适合个人或小团队先做 Demo。
平台协作型：不仅能做知识库，还能接工作流、应用发布、团队协作。
复杂文档解析型：重点是文档理解质量，尤其适合长 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 效果”当成核心竞争力的场景

Cherry Studio、AnythingLLM、Dify、FastGPT 与 RAGFlow 等知识库平台对比图

3、Cherry Studio 搭建个人知识库

后续我们会重点拿 Coze 和 Dify 讲工作流和智能体，所以知识库这里，先选更适合个人快速上手的 Cherry Studio 和腾讯出品的 ima。

3.1 Cherry Studio 特点

Cherry Studio 更适合被理解成一个“个人向、桌面化、模型聚合型 AI 工作台”。它的优势不是企业平台能力，而是：上手快；图形化强；适合个人快速搭知识库和多模型对比。

小白友好：Cherry Studio 致力于降低技术门槛，零基础用户也能快速上手，让用户更专注于工作、学习或创作本身。

一问多答：支持同一问题通过多个模型同时生成回复，方便对比不同模型的表现。

Cherry Studio 一问多答功能界面示意图

助手市场：内置千余个行业专用助手，涵盖翻译、编程、写作等场景，同时支持自定义助手。

Cherry Studio 助手市场界面示意图

服务商模型聚合：支持 OpenAI、Gemini、Anthropic、Azure 等规范的三方服务商接入，兼容性较强。

Cherry Studio 服务商模型聚合配置界面

数据安全：支持全本地场景使用，结合本地大模型时，更适合对数据安全较敏感的用户。

3.2 LLM 的使用

在 Cherry Studio 里，知识库问答并不是“只要上传文件就行”。你至少要先把聊天模型和Embedding 模型两个角色理解清楚：

聊天模型（LLM）：负责最后生成回答。
Embedding 模型：负责把文档和问题变成向量，用于检索。

所以要先完成模型接入。

步骤 1：下载与安装客户端工具

下载地址：https://www.cherry-ai.com/download

步骤 2：硅基流动注册账号

这里的大模型服务，以硅基流动平台为例说明。

网址：https://siliconflow.cn/zh-cn/models

步骤 3：创建 API 密钥

在硅基流动平台创建 API 密钥的界面

步骤 4：复制 API 密钥

步骤 5：配置 API 密钥

在 Cherry Studio 中配置 API 密钥的界面一

步骤 6：选择大语言模型

在 Cherry Studio 中选择大语言模型的界面一

在 Cherry Studio 中选择大语言模型的界面二

到这里完成的是“生成模型”接入，也就是后面负责回答问题的那部分能力。

3.3 知识库的使用

这一部分是从“普通聊天”进入“知识库问答”的关键。建议你一边做，一边记住：上传文档不是终点，能不能检索对、能不能基于知识库生成，才是效果关键。

步骤 1：添加嵌入模型

根据下图确认名称：

确认嵌入模型名称的界面示意图

回到 Cherry Studio 添加：

在 Cherry Studio 中添加嵌入模型的界面

这一步对应的是 RAG 里的“Embedding”环节。后续上传文档建库、用户提问检索，都会依赖这一模型。

步骤 2：创建知识库

在 Cherry Studio 中创建知识库的界面

提供知识库内容：

在 Cherry Studio 中向知识库导入文件、网页或文本内容的界面

这里支持不同格式文件、文件夹、网页地址、大段文本内容等多种方式添加到知识库。

注意：上传文件如果包含大量手写内容、复杂表格、扫描件、公式或复杂版式，解析效果通常会明显下降。很多人以为“RAG 效果差”是模型问题，实际上常常是文档解析阶段已经出了问题。

步骤 3：支持直接检索

检索：

Cherry Studio 知识库直接检索结果界面

这里展示的是“先搜知识库”的能力。此时系统还没有让大模型长篇生成，而是在数据库中基于 RAG 思路做召回。相关片段和匹配得分都能看到，很适合用来排查效果。

步骤 4：基于知识库生成

选中后，提问：

Cherry Studio 基于知识库生成回答的界面一

Cherry Studio 基于知识库生成回答的界面二

这一步对应的才是“完整 RAG”：先检索，再增强上下文，再由模型生成答案。

补充：增强文档解析能力

如果上传文件中有手写内容、复杂表格、扫描件或复杂公式，解析效果会较差。此时可以先用专门的文档解析工具做预处理，再把处理后的内容上传到知识库。

使用工具：Doc2X

网址：https://doc2x.noedgeai.com/

Doc2X 文档解析工具官网界面

这里你要建立一个很实用的工程意识：

RAG 效果不是只由大模型决定，还会受到文档质量、解析质量、切分质量、检索质量、重排质量和 Prompt 组织质量影响。
不是所有问题都该怪模型，很多问题发生在前面的数据链路里。

3.4 流程分析

个人知识库从导入资料到检索生成的整体流程图

Cherry Studio 这整套流程可以拆成：

接好聊天模型
接好 Embedding 模型
上传文档并建知识库
先检索相关内容
再基于知识库生成回答

这条链路和前面第 1 节讲的 RAG 标准流程是一一对应的。也正因为如此，后面你切换到 Dify、LangChain、RAGFlow 时，虽然界面不同，但底层思路并没有变。

4、ima 搭建个人知识库

4.1 ima 特点

如果说 Cherry Studio 更像“桌面化模型工作台”，那么 ima 更像“更偏 C 端、更轻量、上手成本更低的知识助手”。它特别适合初学者快速体验“把资料接进模型”这件事。

操作简单、零上手成本：界面和流程都很直观，更偏普通用户使用。
多端同步：支持客户端、小程序、网页等多端访问与同步。
共享知识库：支持将知识库分享给他人，方便协作与传递。
模型与入口：通常会接入平台方提供或合作的大模型能力，并支持通过客户端、微信等入口提问，模型基于知识库生成答案。具体模型名称和入口形态会随产品版本变化。

在入门阶段，ima 的价值主要是：很容易先建立“知识库问答”的使用直觉。它的可定制化不如 Dify，但上手门槛更低。

4.2 搭建知识库过程

步骤 1：下载与安装

网址：https://ima.qq.com/

ima 登录界面

步骤 2：新建知识库

在 ima 中新建知识库的界面

步骤 3：导入本地文件

在 ima 中导入本地文件的界面三

步骤 4：基于知识库「生成」

ima 基于知识库生成回答的界面一

ima 基于知识库生成回答的界面二

这部分最值得你体会的是：即使平台界面和 Cherry Studio 不同，但底层做的事情仍然是同一套逻辑：

把文件导入
变成可检索内容
用户提问
检索知识
基于知识回答

4.3 组合互联网网页构成知识库

知识库不一定只来自本地文件，也可以来自网页内容。这个能力在做个人学习型知识库时很常用。

步骤 1：在微信公众号中搜索相关主题的文章，并将它们加入到 ima。

步骤 2：在 ima 中新建个人知识库，将相关文章加入到此知识库。

在微信公众号中查找可加入知识库的文章界面一

步骤 3：文章导入完成后，即可生成知识库，并基于大模型进行检索与问答。

ima 基于网页文章构建知识库后的界面一

这个案例很有代表性，因为它说明了一个重要认知：

知识库不等于“上传 PDF”。只要资料能整理成可用文本，它就有机会成为知识库的一部分。

4.4 添加第三方知识库

ima 查看第三方知识库的界面一

ima 查看第三方知识库的界面二

这一点对应的是“知识库协作和复用”的能力。对于企业或团队来说，知识库的价值不只是你自己能查，而是它能成为多人共享的知识入口。

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：首先创建一个新的知识库

在 Dify 中创建知识库的界面

步骤 2：上传知识库文件

这里准备的是一份《刑法》的 TXT 格式文本，按自然段划分了每一条法条。

在 Dify 中上传知识库文件的界面

这个案例适合作为入门演示，因为法律条文天然分段清晰、知识边界明确，也更容易观察检索是否准确。

步骤 3：分段设置

大语言模型存在有限的上下文窗口，因此通常需要先把长文本进行分段，再从中召回与问题关联度最高的几个段落。分段太粗会带来噪音，分段太细又会把语义切碎，所以“怎么切块”是 RAG 里最关键的调参点之一。

分段标识符如果是 \n，则是以换行为一个分段；如果是 \n\n，则是以一个段落为一个分段。点击“预览块”可以查看目前块划分的情况。

分段重叠长度一般是分段最大长度的 10%-20%。

知识库文档中若有 URL、邮箱等，也可以在预处理时过滤掉。

分段设置说明（这些项是干嘛的、对知识库有什么影响）

配置项	作用	对知识库的影响
分段标识符	决定“按什么边界”把长文切成小块。`\n` = 按换行切，`\n\n` = 按空行切。	选得合适，切出来的块语义更完整；选得不合适，可能把一整段话切碎，后面检索就容易只命中半句。
分段最大长度	单块文本的字数 / 字符上限，超过就再切一刀。	设太大，单块里无关内容太多，容易把噪音带进 Prompt；设太小，语义被拆散，召回容易漏关键信息。一般可从 200～800 字（或约 100～500 token）起步，再按文档类型调。
分段重叠长度	相邻两块之间重复一段文字，避免边界处语义断裂。	有一定重叠，边界上的句子不容易被截断；重叠太大则会造成内容重复、存储浪费和检索噪声。

Dify 知识库分段设置界面

步骤 4：选择索引方式

这里自动选择高质量。高质量的准确性更高，但 token 消耗也会增加；如果用的是本地部署模型，成本敏感度会低一些。

Dify 知识库索引方式选择界面

还有 Q&A 方式：如果文档本身就是问答对形式，这种方式通常更契合。

步骤 5：检索设置

在这里可选择 Embedding 模型与 Rerank 模型，也可以设置 Top K，也就是选出最相似的前 n 条。还可以设置 Score 阈值，即筛选文本的相似度下限。

Dify 知识库检索设置界面

混合检索：既包括向量检索（可选用 Rerank 模型做精排），也包含全文检索。

检索设置说明（这些项是干嘛的、对知识库有什么影响）

配置项	作用	对知识库的影响
Embedding 模型	把“文档块”和“用户问题”都变成向量，用来算语义相似度。	建库和检索必须用同一个 Embedding 模型，否则向量不在同一个空间里，检索效果会明显变差。
向量检索	用问题向量在向量库里找“最像”的文档块。	是 RAG 的核心检索步骤，没有它就无法按语义从知识库中召回内容。
Rerank 模型	在向量检索拿到一批候选块后，再用专门模型对“问题 + 每条候选”打更精细的相关性分。	不开 Rerank 时，只靠向量相似度，有时会混进“看起来相关但答非所问”的片段；开启后通常能显著提升最终送给模型的上下文质量，但也会增加延迟与成本。
Top K	检索时最多取几条文档块交给后续步骤。	K 太小，可能漏掉关键信息；K 太大，又容易把无关内容塞进上下文，增加噪音与 token 开销。一般可先试 5，再根据效果微调。
Score 阈值	相似度下限，只有达到阈值的块才会被保留。	阈值高，结果更干净但可能漏召回；阈值低，信息更全但噪音变多。排查效果时，可以根据“找不到内容”还是“召回太杂”来升降阈值。
混合检索	同时做向量检索和全文检索，再合并、去重、排序。	当文档里既有自然语言段落，又有条目编号、专有名词、法条编号时，混合检索通常比纯向量检索更稳。

设置完成后，保存并处理即可。

Dify 保存并处理知识库的界面

这一节最值得你带走的工程结论是：

RAG 的效果，不是“上传完文件”那一刻决定的，而是由文档质量、切块策略、Embedding 质量、检索策略和重排策略共同决定的。

如果你想继续把这些平台里的配置项和代码实现一一对上，可以把这一节和 19-RAG检索增强生成的“文档加载器、文本分割器、检索器”几节对照着看，理解会更快。

5.4 测试

接下来进行测试。创建一个聊天助手，将提示词设置为：

1	你是一个法律小助手，请只根据知识库中的信息，简要回答用户提问的案件触犯了哪些法律

知识库选择刚才添加的 刑法.txt，然后可以开始提问。

可以观察到，聊天助手会自动引用知识库中的内容进行回答。

Dify 中基于知识库进行测试问答的界面

这个案例和前面 Cherry Studio、ima 的案例一起看，会更容易形成完整理解：

Cherry Studio：更适合个人快速搭一个知识库试试效果
ima：更适合普通用户低门槛体验知识库问答
Dify：更适合把知识库放进应用、工作流和团队协作环境里

章节思考题：

如果一个知识库问答效果不好，你会先检查文档、切块、Embedding、检索参数还是提示词？为什么？

参考思路： 先看问题表现。完全找不到资料，优先查文档是否入库、切块是否合理、Embedding 是否一致；召回很多杂内容，再调 Top K、阈值、Rerank；召回对了但回答乱，再看提示词和引用约束。
为什么“上传了文件”不等于“知识库已经可用”？

参考思路： 文件还要被解析、清洗、切块、向量化、写入索引，并且查询时能被正确召回。任何一环出问题，用户看到的都是“答不准”。知识库质量不是上传动作决定的，而是整条处理链路决定的。
Cherry Studio、ima、Dify 这类平台适合分别用来验证什么？

参考思路： Cherry Studio 适合个人快速试效果，ima 适合低门槛体验知识库问答，Dify 更适合把知识库接进应用、工作流和团队协作。选择平台时看目标是个人验证、普通使用，还是工程交付。
给一个新人解释 Top K、阈值、Rerank 时，你会用什么排查例子？

参考思路： 可以用“查资料”类比：Top K 决定拿几段材料，阈值决定太不相关的材料要不要丢掉，Rerank 决定候选材料重新排序。答案漏信息时可能 K 太小或阈值太高，答案跑偏时可能 K 太大或缺少重排。

本章小结：

RAG 是什么：检索（从你的文档里找相关段落）→ 增强（把段落塞进当前输入）→ 生成（大模型基于这些内容回答）；它不改模型参数，而是在运行时补上下文。
为什么需要 RAG：它主要解决知识冻结、私有知识缺失、最新信息不可用和幻觉等问题。很多业务问题本质上不是“模型不会”，而是“模型没看到资料”。
知识库是什么：知识库是承载外部知识的整体容器，不等于向量库。知识库背后通常包含文档、分块、Embedding、检索、元数据和检索策略等环节。
三类平台怎么理解：Cherry Studio、ima 适合个人快速上手；Dify 更适合应用化交付和工作流集成；RAGFlow 更适合复杂文档解析和高精度检索场景。
真正影响效果的因素：文档质量、解析质量、分块策略、Embedding 模型、Rerank、Top K、阈值，都会直接影响“查得准不准、答得稳不稳”。

建议下一步：

如果你想继续往平台化应用和工作流方向走，建议接着看 3-基于Coze&Dify平台的智能体开发和 4-Python调用Dify平台工作流。
如果你想从代码角度真正把 RAG 跑起来，建议先看 18-向量数据库与Embedding实战，再继续看 19-RAG检索增强生成。