把三份自己的笔记放进知识库，界面都显示"处理完成"，很容易让人产生一个错觉：它已经会回答了。
可真正应该先问的，不是"它说得像不像人"，而是两件更朴素的事：它能不能找到笔记里那段原文？给出的结论能不能顺着引用回去？
这两个问题，也能帮助我们看清三种工具的差别。Cherry Studio 更接近桌面端个人知识库，ima 更偏向资料收集、阅读和多端使用，Dify 则会把知识库继续接入聊天应用或工作流。界面虽然不同，底层都绕不开同一条 RAG 链路。
图 1：真正的验收点不在"上传成功"，而在能否检索到正确原文、引用能否回查。
本文按课件的三条实操路线展开，不使用课件截图，也不复刻账号、API 密钥或他人资料。图表均为重新绘制的原理图；本文没有对不同产品做同环境性能实测。
一、先理解 RAG：它不是重新训练一个大模型
RAG 的全称是 Retrieval-Augmented Generation，通常翻译为"检索增强生成"。
大模型回答问题时，主要受三个边界影响：
- 训练数据存在时间范围，不能自动知道后来更新的资料；
- 企业内部文档、个人笔记和私有知识通常不在公开训练数据中；
- 缺少依据时，模型仍可能生成一段听起来合理的内容。
RAG 的做法不是拿几份文件重新训练模型，而是在模型回答之前先查资料。
一次完整过程可以拆成两段：
- 建库阶段：提取文件正文和结构，切成多个 Chunk，再用 Embedding 建立索引，同时保存原文与来源；
- 问答阶段：先根据问题寻找候选 Chunk，必要时重新排序，再把问题和资料一起交给 LLM，最后返回回答与引用。
如果上游在"解析"或"分块"时已经丢掉关键条件，后面再换聊天模型，也补不回那段没有进入上下文的原文。
这里涉及的三个模型并不是一回事：
| 模型 | 作用 | 是否必选 |
|---|---|---|
| Embedding 模型 | 把文档块和用户问题变成可比较的向量 | 做语义检索时需要 |
| Rerank 模型 | 对初次检索到的候选内容重新评分和排序 | 可选 |
| LLM | 根据用户问题和最终资料生成回答 | 生成式问答需要 |
Reranker 不是 RAG 的必选组件。候选结果很多、相似内容容易混淆时，它可能改善排序；知识库很小或对延迟敏感时，可以先不用。
向量数据库也不是唯一的外部知识源。全文检索、关系数据库、搜索引擎和业务 API 都可以参与检索。很多系统会把向量检索与关键词检索组合成混合检索。
二、什么情况下适合搭知识库
个人知识库适合处理这些资料：
- 学习笔记、课程材料和技术文档；
- 项目说明、接口文档和排障记录；
- 写作素材、研究资料和自己有权使用的网页；
- 需要反复查找、总结和引用的长文档。
团队或企业知识库还可以用于内部制度、产品说明、客服资料和培训文档，但必须额外处理账号、权限、日志、更新和删除。
如果问题要求查询实时库存、订单状态、精确数值或执行业务操作，不能只依赖 RAG。此时应该调用数据库、业务 API 或专门工具，再让模型负责解释结果。
三、课件中的平台应该怎么选
课件对比的平台可以按能力分成四类，而不是简单排一个名次。
| 类型 | 代表工具 | 适合做什么 | 选择时要确认什么 |
|---|---|---|---|
| 桌面端个人知识库 | Cherry Studio、AnythingLLM | 快速导入个人文件并进行检索问答 | 模型接入、数据存储位置、文件解析、引用来源 |
| 资料收集与多端使用 | ima | 收集文件、网页等资料，并在不同终端查询 | 同步范围、分享权限、来源和导出能力 |
| AI 应用与工作流平台 | Dify、FastGPT | 将知识库接入聊天助手、工作流或业务应用 | 部署、API、应用编排、权限和日志 |
| 复杂文档 RAG 引擎 | RAGFlow | 处理长 PDF、表格、扫描件和复杂版式 | 解析质量、Chunk 预览、人工干预和部署资源 |
先别急着问"哪个更强"，把第一阶段真正要解决的任务放进下面这张决策图。
图 2：它表达的是优先评估方向，不是产品排名。
同一个人也不必一次把路线锁死。例如，可以先用桌面工具验证少量资料能否稳定检索，再决定是否迁入 Dify 做应用编排。涉及敏感数据时，四条路线都要先确认整条数据链路。
产品界面、支持格式、模型和价格会持续变化。下面保留的是知识库搭建中的关键动作，不把某一个版本的按钮位置当成固定规则。
四、用 Cherry Studio 搭个人知识库
Cherry Studio 这条路线适合先完成一个个人知识库闭环：配置模型、创建知识库、导入资料、直接检索、再进入对话。
课件还把它的产品特点概括为：桌面端上手门槛较低、同一问题可以交给多个模型对比回答、提供助手市场，并能聚合不同模型服务商。具体助手数量、可接入的服务商和本地能力会随版本变化，因此这里只保留能力类型，不沿用课件里的数量宣传。即使客户端运行在本地，也要继续确认模型调用、文档解析和同步是否经过云端。
第一次尝试不需要塞进几十份资料。准备 3 份主题单一的 Markdown 或 TXT，再准备 3 个问题就够了：一个答案明确存在、一个换了说法、一个资料中根本没有。后面的七步，都围绕这组小样本完成。
第一步：安装客户端并配置模型服务
安装完成后，需要先连接模型服务。配置时通常会用到服务商地址、API 密钥和模型名称。
这里不要照抄别人的密钥，也不要把密钥写进文章、截图或公开配置文件。使用哪个模型服务商并不是 RAG 原理的一部分，可以根据预算、数据要求和当前可用模型选择。
至少需要区分两类模型：
- 聊天模型：负责生成回答；
- Embedding 模型：负责知识库向量化和语义检索。
先分别测试它们是否能正常调用，再开始创建知识库。聊天模型能回复，不代表 Embedding 模型已经配置成功。
第二步：添加 Embedding 模型
在模型管理中选择一个支持文本 Embedding 的模型并加入可用模型列表。
创建知识库时会绑定这个模型。文档导入以后，系统会用它处理文本块；用户提问时，也需要在同一套向量语义下进行查询。
如果后续更换 Embedding 模型，已有资料通常需要重新向量化，不能把不同模型生成的向量直接混在一起比较。
第三步：创建知识库
知识库名称应该体现资料边界，例如：
- 前端开发笔记；
- Java 接口与排障记录；
- Python 与 FastAPI 学习资料；
- RAG 与 AI Agent 笔记。
不建议第一天就创建一个"我的全部资料"，然后把所有文件塞进去。技术领域越混杂，错误召回越难排查。
第四步：导入资料并等待向量化
Cherry Studio 官方知识库流程支持从本地文件、文件夹、网页地址、Sitemap 或纯文本添加资料。实际支持格式要以当前客户端为准。
第一批可以只放少量结构清晰、来源明确的 Markdown 和 TXT 文件。导入后确认处理状态完成，再随机检查几篇资料：
- 标题和正文是否完整；
- 段落顺序是否正确；
- 代码与解释是否被拆乱；
- 文档名称和来源是否仍然可见。
网页导入可能受登录、反爬或动态加载影响，因此"添加成功"之后仍要做检索测试。
这里是最容易被聊天效果掩盖的问题：模型可以把一句不准确的回答说得很顺，但它无法替你证明原文是否真的被找到。
图 3：文件显示已处理之后，依次检查解析、直接检索、回答依据和引用回查。
第五步：先进行直接检索
不要上传完成后马上进入聊天。
先使用知识库检索功能输入一个资料中明确有答案的问题，观察返回了哪些原文片段以及匹配信息。
这一步可以直接暴露几个问题：
- 文档根本没有被正确解析；
- 关键内容被切断；
- 用户换一种说法后无法命中；
- 召回内容主题相近，但没有真正回答问题。
只有检索能找到正确原文，后面的生成式问答才有可靠上下文。
第六步：在对话中引用知识库
创建新对话或助手，在对话配置中选中刚才的知识库，再发送相同问题。
检查的不只是回答是否通顺，还包括：
- 回答中的主要结论能否在引用资料中找到；
- 引用能否回到正确文件；
- 资料没有答案时，模型是否会承认信息不足。
第七步：复杂文档先做预处理
手写内容、扫描件、公式、复杂表格和图文混排 PDF 的解析效果通常更不稳定。
可以先使用 OCR 或文档解析工具把它们转换成结构更清晰的文本，再导入知识库。课件以 Doc2X 为例，实际也可以选择其他解析方案。涉及内部资料时，要先确认第三方解析服务的数据保存和隐私政策。
五、用 ima 搭个人知识库
ima 的搭建步骤比完整 RAG 平台更短，适合先把分散资料收集到一个知识库里，再进行检索、阅读和问答。
课件强调了 ima 的多端形态：客户端、小程序和网页端可以围绕同一知识库使用，也可以通过微信侧入口提问。至于当前开放哪些终端、模型和同步能力，应以实际账号与版本为准；这里关注的是"收集资料---建立知识库---基于资料生成"的主流程。
可以把资料先分成两篮：自己的本地笔记、文章进入个人知识库；有权使用的网页和共享知识库作为外部参考。提问以后再看来源归属，避免把外部资料误当成自己的结论。
第一步：安装、登录并创建知识库
在当前可用的客户端或网页端登录账号，新建一个个人知识库，先写清楚知识库主题和资料范围。
如果计划跨设备使用，需要同时确认哪些内容会同步、谁能看到、知识库是否允许分享。
第二步：导入本地文件
选择自己有权使用的本地资料，等待平台完成解析。
第一轮仍然建议使用文字结构清晰的文件。导入完成后，不要只看文件数量，还要用几个明确问题验证原文是否可被找到。
第三步：基于知识库提问
提问时要观察回答是否真的引用了库内资料。如果平台提供来源入口，应打开原文核对，而不是只阅读生成结果。
对于资料中不存在的问题，可以主动测试一次，确认系统是明确表示没有依据，还是继续使用模型常识作答。
第四步：加入网页和公众号资料
课件演示了把网页或公众号文章加入知识库的方式。这个能力适合整理专题资料，但公开可见不等于可以任意复制和再发布。
更稳妥的做法是：
- 优先使用自己发布的文章或已经获得授权的内容；
- 保留作者、原始链接和更新时间；
- 不把他人的完整文章改写成自己的内容；
- 网页更新或删除后，检查知识库里的旧版本是否仍然有效。
第五步：使用共享或第三方知识库
如果平台允许添加别人公开分享的知识库，可以把它当作外部参考源，但不要与自己的资料混为一谈。
提问后仍要区分回答来自个人资料、共享知识库还是模型自身知识。第三方知识库发生更新时，也不能默认自己的历史答案仍然有效。
ima 这条路线的优势在于资料收集和使用门槛较低；如果需要精细控制分块、索引和 Rerank，则要查看当前版本是否开放相应设置，或者转向 Dify、RAGFlow 等更偏工程配置的平台。
六、用 Dify 搭知识库并接入聊天助手
Dify 的知识库流程比个人桌面工具更完整：导入资料之后，还需要设置 Chunk、索引和检索方式，最后把知识库接入应用。
第一步：配置模型
在模型提供商配置中准备：
- LLM：生成最终回答；
- Embedding：建立语义索引；
- Rerank：可选，用于候选内容重排。
Embedding 和 Rerank 是不同模型类型。没有明确观察到"正确内容已召回但排序不理想"之前，不必为了配置完整而强行启用 Rerank。
第二步：创建知识库并导入数据
创建知识库时可以上传本地文件，也可以按照当前版本支持的数据源导入网页或其他内容。
课件列出的源数据既包括 TXT、Markdown、DOCX、HTML、JSON、PDF 等长文本，也包括 CSV、Excel 等结构化数据。能上传不等于能正确理解，尤其是复杂 PDF 和表格；实际支持格式、大小限制与解析效果仍要以当前版本和导入预览为准。
导入前先处理重复文件、过期版本、无上下文摘录和来源不明的资料。知识库中同时存在多个相互冲突的版本时，模型很难判断哪一份才有效。
第三步：设置文本分块
分块决定检索时能拿到多完整的上下文。
假设一篇排障笔记同时写了"现象、出现条件、处理方法和结果"。如果 Chunk 只留下处理方法，却把适用条件切到另一块，检索即使命中，回答也可能把一个有条件的结论说成通用结论。分块参数要解决的正是这个问题。
Dify 当前文档中的核心配置包括分隔符、最大 Chunk 长度和 Chunk 重叠。例如：
\n：按换行切分；\n\n：按段落切分；- 最大长度：超过长度时继续拆分；
- 重叠：让相邻 Chunk 保留部分相同内容，减少边界信息丢失。
分隔符会因文档结构不同而变化：
- Markdown、技术手册：优先保留标题和自然段；
- FAQ 或问答资料：尽量让一个问题与答案留在同一块；
- 规则和条款：条件、正文和例外不能被拆开；
- 表格：表头与行列关系需要一起保留。
课件把重叠比例写成最大分段长度的 10%～20%，这个数字只能作为尝试起点，不能当作所有资料的最佳参数。配置后一定要使用预览功能检查实际 Chunk。
如果原文里存在大量无助于问答的 URL、邮箱或模板噪声，也可以按平台当前提供的清理能力过滤；但不要误删来源链接、联系人语义或回答问题所需的字段。
第四步：选择索引方式
不同版本的命名可能变化，但核心取舍可以分成两类：
- 语义索引：使用 Embedding 把文本转成向量，可以召回措辞不同但含义接近的内容；
- 关键词索引：使用全文或倒排索引，适合错误码、接口名、编号和明确术语。
Dify 当前知识库还可以在高质量与经济型索引之间选择，并提供向量检索、全文检索和混合检索等方式。不要只根据"高质量"三个字做决定，应结合文档类型、模型成本和测试结果。
如果原始文档本身就是整理好的问题---答案对，可以优先选择 Dify 的 Q&A 索引方式；普通长文则先保持原文结构，避免自动生成的问题覆盖了真实内容。
第五步：设置检索方式
这里需要理解四个开关：
| 配置 | 控制什么 | 常见问题 |
|---|---|---|
| Top K | 最多取回多少个文本块 | 太少可能漏条件，太多会增加噪声 |
| Score Threshold | 低于多少相关性分数就过滤 | 太高会漏召回，太低会带入无关内容 |
| 混合检索 | 同时使用语义与关键词信号 | 需要根据资料特点调整两者权重 |
| Rerank | 对初步候选结果重新排序 | 会增加模型调用、成本和延迟 |
把这些开关放回一条链路里，就能看清它们各自控制哪一层。
图 4：测试失败后，只回到出问题的那一层，不要同时乱改所有参数。
不同 Embedding、Rerank 和平台的分数不能直接照抄。Top K 和阈值没有通用最佳值，应该用同一批问题反复测试。
第六步：等待处理完成并测试检索
知识库处理完成后，进入检索测试，输入资料中明确有答案的问题。
先检查正确 Chunk 有没有出现、排在什么位置，再测试不同措辞、相似概念和资料中没有答案的问题。
检索测试中临时调整的参数不一定会自动同步到应用配置。确认效果后，要在知识库或应用的正式检索设置中保存同样的参数。
第七步：创建聊天助手并关联知识库
创建聊天应用，在上下文或知识库配置中选择刚才的知识库，开启引用和来源展示，然后进入调试预览。
提示词可以先保持简单：
markdown
请优先依据知识库资料回答。
要求：
1. 资料不足时，明确说明"当前知识库没有足够资料"。
2. 不要编造资料中不存在的事实、版本或结果。
3. 在主要结论后保留引用来源。
4. 如果资料存在冲突，列出不同说法及其来源。这段提示词只能约束生成阶段。如果检索没有找到正确资料，继续堆叠 Prompt 也无法补回缺失的原文。
七、三条路线都要做同一轮测试
无论使用 Cherry Studio、ima 还是 Dify，都不要只问一个"看起来一定能答对"的问题。
可以准备一组小型测试集：
- 直接答案题：例如"这份笔记里，某个模块负责什么？"；
- 上下文题：例如"在什么条件下，这个处理方式才成立？"；
- 易混淆题：例如"资料里的方案 A 与方案 B 有什么区别？"；
- 精确词题：使用资料中的接口名、错误码、编号或日期提问；
- 库外题：故意询问资料没有覆盖的主题。
每次记录：
| 项目 | 检查内容 |
|---|---|
| 预期来源 | 哪个文件、哪一段包含依据 |
| 检索结果 | 正确原文是否出现、排在第几位 |
| 最终回答 | 结论是否由检索结果支持 |
| 引用 | 能否回到正确资料 |
| 越界 | 是否添加了资料中不存在的信息 |
回答不正确时，按链路排查：
图 5：先查资料与检索，再动 Prompt。
这样才能区分是资料问题、检索问题，还是生成问题。
八、把课件案例换成自己的资料
课件在 Dify 中使用了法律文本和法律助手作为示例。实际整理个人知识库时，不需要照搬这个案例，也不要把别人的专业资料直接当作自己的内容。
更适合当前情况的第一批资料可以是：
- 自己的前端学习笔记；
- 已经脱敏的 Java 接口和排障总结；
- Python、FastAPI 学习记录；
- RAG、Embedding、Agent 相关笔记；
- 有权使用的官方文档摘要和原始链接。
第一轮只选少量 Markdown 或 TXT 文件，分别在 Cherry Studio、ima 或 Dify 中走完"导入---检索---问答---引用"即可。这里的调整只发生在资料内容上，不改变课件原本的 RAG 搭建步骤。
九、"私有知识库"不只是安装在本地
个人资料和企业资料进入知识库前，都要确认整条数据链路：
- 原始文件、Chunk 和向量保存在哪里；
- Embedding、Rerank、LLM 是否调用云端服务；
- 同步、备份和日志是否包含原文或问题；
- 谁可以访问、分享和导出知识库；
- 删除原文后，Chunk、向量和备份是否同步删除；
- 网页、公众号文章和第三方知识库是否有使用权限。
客户端安装在本地，只能说明软件运行位置。若模型和解析服务仍通过外部 API 调用，资料片段仍可能离开本机。
企业使用时还要增加成员权限、部门或租户隔离、审计、版本更新、敏感信息处理和恢复机制。权限过滤必须发生在检索阶段，不能等模型看到资料以后再隐藏答案。
结语
真正开始时，不需要先建一个庞大的"全部资料库"。可以只拿 3 份结构清楚的小资料，准备直接答案、换一种说法和库外问题各 1 道，走完一次"导入---检索---回答---引用回查"。
这轮小实验能跑顺，再扩大资料量；桌面问答满足不了需求，再进入 Dify 的分块和应用编排；复杂文档解析成为主要问题，再单独评估 RAGFlow。工具可以以后再换，先把正确原文送到回答面前，才是三条路线共同的起点。