Obsidian+Dify搭建个人RAG知识库：从零到能聊天的AI助手

先说结论：我并没有搭出一套能拿去发论文或者上生产环境的RAG系统，也没有上K8s、搞高可用。我用大概两个周末的时间，用 Obsidian 整理知识源，用 Dify 做知识库流水线，再把一个 Embedding 模型和一个对话模型接进去，把电脑里散落了几年的几百份文档、表格和网页剪藏，变成了一个能聊天的“AI知识库”。整个过程很粗糙，但确实解决了我的实际问题：资料找得到、问题问得出、答案还能附出处。这篇文章就把我踩过的坑、选型的逻辑、参数调优的过程完整记录下来，给同样想低成本搭建知识库的朋友一个参考。

如果你和我一样，手头有大量 PDF、Excel、网页剪藏、会议纪要，又不想一上来就部署一套复杂框架，这篇文章应该能帮你少走不少弯路。我会尽量把“为什么这么选”“为什么这么配”讲清楚，而不是只给一套照抄的配置。

1. 为什么我要搭一个“粗糙版”AI知识库

1.1 资料多到找不到，才是真正的痛点

先说个很现实的场景。我的电脑里长期散落着几类东西：项目验收文档、产品需求说明、大量PDF论文、行业报告、Excel统计表、网页剪藏，还有各种在聊天工具里被反复转发的资料。以前找资料基本靠记忆，我记得“某个文件大概叫这个”，然后去文件夹里翻，翻不到就整个磁盘搜索，再不行就去网盘里捞，最后经常无功而返。时间一长，资料越攒越多，能真正被用起来的却很少。资料躺在硬盘里不叫知识，能被检索和调用的才算。

后来我试过很多“传统”工具，比如给文件夹做编号、用笔记软件打标签、用表格做索引。问题在于，我下班后根本没有精力维护一套严格的分类体系。我真正需要的是：把东西丢进去，以后用自然语言就能问出来。这正是我决定搭“AI知识库”的原因。它不是替代笔记软件，而是给所有散乱材料加一层“自然语言检索层”。

1.2 直接问大模型不行，必须依赖外部知识库

有的人会问，现在大模型这么强，直接把所有资料喂给它不就行了？这里有两个现实问题。第一，大模型有上下文窗口限制，就算窗口再大，几百个文档也不可能一次性塞进去，而且塞进去之后注意力会分散，回答问题反而变差。第二，通用大模型训练的时候根本没见过我的私人资料，比如某个项目的内部术语、某个Excel表格里的具体报价，它不可能凭空知道。即使它有很强的推理能力，面对陌生概念也只能瞎猜，产生“一本正经地胡说八道”。

所以要搭一个AI知识库，本质思路是：先把文档切块、向量化，把语义信息存进向量数据库；用户提问时，先把问题转成向量，和库里所有片段做相似度匹配，找回最相关的几个片段；最后把这些片段作为参考资料，连同原始问题一起交给大模型，让它“基于资料回答”。这个流程在业内叫RAG，检索增强生成。RAG知识库是目前落地最广、性价比最高的知识库方案，也是我这套“粗糙版”方案的核心。它不需要重新训练模型，只需要做好检索和拼接，就能让大模型“临时学会”我的资料内容。

1.3 为什么定位是“粗糙版”

我见过很多人的知识库工程，一开始就规划要上 LangChain、Milvus、Kafka、K8s，还要设计复杂的权限体系，结果搞了两个月，连一个能对话的Demo都没有跑通。我的思路刚好相反：尽量用成熟的现成工具，先把一个最小闭环跑起来，再去补工程化能力。所以“粗糙版”不是一个谦虚的说法，而是一种刻意的取舍。

第一版我只求三件事：能导入文档、能检索到相关内容、能基于内容生成答案。界面丑一点没关系，检索偶尔不准也没关系，只要整体链路是通的，后面就有持续优化空间。事实证明这个策略是对的，因为知识库的效果优化是一个持续迭代的过程，只有先把链路跑通，你才知道问题出在解析、分块、向量化还是提示词上。如果一开始就追求完美架构，反而会因为变量太多而找不到问题根源。我的建议是：个人用、小团队用，或者做技术验证，先上“粗糙版”，等跑通了再考虑要不要上重架构。

2. 整体方案与工具选型：Obsidian + Dify + Embedding

2.1 “粗糙版”的整体架构怎么分层

先看整体分层，我用一句话来描述我的知识库：Obsidian做内容层，Dify做流水线层，向量数据库做检索层，大模型做问答层。

内容层解决的是“知识源怎么管理”。我用Obsidian管理Markdown文档，同时会把PDF、Excel等文件转换成Markdown或其他可解析格式再入库。选择Obsidian是因为它基于本地纯文本，没有锁定效应，所有文件都是Markdown，迁移方便，后续还能利用它的双向链接和标签辅助人工整理。

流水线层解决的是“文档怎么变成可检索的知识”。这里我用的是Dify。Dify是一个开源的大模型应用开发平台，内置了知识库管理、文档解析、分段清洗、向量化、检索测试这些功能，并且提供可视化编排界面，不需要写太多代码就能搭建一个RAG应用。

检索层解决的是“怎么从知识库里捞相关片段”。Dify默认集成了向量数据库的能力，你只需要选好Embedding模型，它就会自动完成文本向量化和相似度检索。没有单独的向量库组件，这对“粗糙版”来说反而省事。如果后面数据量真的大到几十万条，再拆出单独的向量库也不迟。

问答层解决的是“怎么生成最终答案”。Dify可以把检索到的知识片段注入提示词，再调用一个大模型生成回答。这个模型可以是在线API，也可以是本地部署的开源模型。我选了性价比高的在线模型，同时把私密数据控制在本地场景，后面会详细说安全考虑。

2.2 知识源管理：为什么最终选了Obsidian

我以前用过很多笔记工具。印象笔记比较臃肿，Notion在国内访问不稳定，纯文件夹管理又缺少知识关联。Obsidian赢在三点：一是本地文件管理，所有笔记就是Markdown文件，不存在哪天工具停止服务数据就没了的问题；二是它的插件生态能补足知识库的内容准备环节，比如网页剪藏、PDF标注、表格转换；三是它对Markdown的解析非常标准，导出的内容可以被其他工具无缝消费。

当然，有人会问，既然已经做了RAG知识库，还要不要保留Obsidian？我的答案是：要。RAG知识库解决的是“找到”和“生成”，但人类还需要一个地方做“沉淀”和“整理”。Obsidian承担了“沉淀”的角色，我会在读完资料后用几句自己的话写一条笔记，标注好来源和标签，再把它同步进知识库。这样知识库里不只有原始素材，还有我的解读，检索质量会明显更高。

2.3 RAG流水线：为什么选Dify而不是LangChain

市面上做RAG流水线的工具很多，我自己对比过LangChain、Dify、FastGPT、MaxKB、Quivr。LangChain是代码库，灵活度最高，但需要从头写连接逻辑，调试链路对新手并不友好；FastGPT和MaxKB也是不错的开源项目，FastGPT偏向问答场景，MaxKB偏向运维文档问答，但它们的自定义能力和社区生态在我测试时不如Dify全面；Quivr上手简单，但对中文文档的处理和分段控制比较弱。

最终我选了Dify，核心原因是三个：一是可视化程度高，创建知识库、上传文档、配置分段规则、选择Embedding模型，全都有界面操作，改配置不用改代码就能生效；二是它同时支持知识库和Agent，将来我想给知识库加工具调用、加联网搜索，不用换平台；三是社区很活跃，遇到的问题基本都能搜到案例，尤其是“Dify知识库”、“Dify本地知识库搭建”、“Dify知识库检索效果差”这些话题，网上讨论量都很大，踩坑经验很足。

选型的时候还要注意一点：Dify是一个平台，不是纯前端工具。部署方式可以很简单，官方提供了docker compose方式，一条命令就能把所有服务拉起来。我的部署环境是一台16G内存的个人电脑，跑Dify本身加上一个Embedding模型并不吃力，整个平台资源消耗也不算高。如果你的机器配置比较低，也可以只部署服务端，模型走在线API，这样对配置要求更宽松。

2.4 模型选型：Embedding和生成模型分开选

很多新手会混为一谈，以为大模型只有一个。实际上在知识库里有两种模型在起作用，它们承担完全不同的任务。

Embedding模型负责把文本转成向量。它决定了“语义匹配”的质量。我推荐选择专为中文优化的向量模型，比如BAAI的bge-m3，或者智源的stella-large-zh-v3-0.5B。如果不想本地部署，还可以用OpenAI的text-embedding-3-small等在线接口，但对中文长文档的支持和成本控制未必比bge系列好。我自己的选择是bge-m3，因为它体积适中、中文效果好、开源可控，还能在本地跑，不涉及数据外传。

生成模型负责“总结和回答”。在线模型我建议用带长上下文和稳定输出能力的型号，比如GPT-4o-mini、Claude的轻量版本，或者国产的智谱GLM、通义千问的API。如果你的数据高度敏感，那就在本地跑一个开源模型，比如Qwen系列、ChatGLM系列。我实测下来，一个70亿到140亿参数级别的模型，用个人电脑的CPU做推理可以接受，但回答速度会比较慢；如果有GPU会舒服很多。

这里有一个很重要的原则：Embedding模型和生成模型可以自由组合，不一定用同一个厂商。Dify允许为知识库单独指定Embedding模型，同时为应用单独指定生成模型，我建议你把二者分开配置，这样后续哪个环节有问题就单独换哪个，互不影响。

3. 核心实操：把“粗糙版”知识库搭起来

3.1 数据准备：先把文档统一成Markdown

知识库效果好不好的第一步不是参数，而是文档解析质量。很多人把Word、PDF直接上传，发现检索效果很差，其实问题很可能出在解析上。我的经验是：尽量把资料统一成干净的Markdown再入库。

先说说各种格式怎么处理。纯文本和Markdown文件是最简单的，本身就能直接入库。Word文档建议另存为Markdown或至少转成纯文本，不要直接把docx扔进去，因为docx里有很多排版标记，解析出来经常是一堆乱码。PDF是最麻烦的，如果是文字版PDF，可以通过工具转成Markdown或纯文本；如果是扫描件，需要先OCR识别，否则文档进到库里也是“图像”，检索效果会非常差。Excel表格则需要重点处理，直接把整个表喂进去容易丢失结构，我一般是把每个Sheet单独导出成CSV或Markdown表格，再补上Sheet名作为上下文。

我自己踩过一个坑：有一批专利相关文档是PDF格式，直接上传后，检索的时候经常匹配不到关键内容。后来发现是PDF里的中文被复制出来后多了很多空格和换行，导致语义碎片化。解决的办法是用脚本做一次清洗，把不自然的换行和空格合并掉，再重新入库。如果你不想写脚本，也可以在Dify的“分段清洗”环节手动调整清洗规则，比如合并连续换行、去掉多余空格。

3.2 分段大小与重叠：知识库的“切菜”参数

RAG里一个核心概念叫分段，英文叫Chunk，就是把长文本切成一小块一小块再向量化。切多大合适？切大了，一个片段包含太多主题，检索出来不够精准；切小了，单个片段信息量太零碎，大模型拿到之后看不出前因后果。

Dify的知识库创建页面里有三个关键参数：分段标识、分段长度、分段重叠。分段标识是切分点的依据，一般用“\n\n”表示按换行分段；分段长度是指每段最多包含多少字符，我用的是500字符；分段重叠是指相邻两段之间重叠多少个字符，我用的是100字符。这个组合不是随手填的，而是经过测试后保留的：中文文本一句话平均几十个字符，500字符大概够10句话，能完整表达一个主题；100字符重叠可以让跨段的上下文连续起来，避免句子在切分时被拦腰截断。

这里有一个比较关键的补充：不同文档类型应该用不同的分段参数。如果是论文、报告这类长段落文本，可以把分段长度提到800甚至1000，因为它们的每个段落本身就比较完整；如果是问答、FAQ这类短文本，分段长度可以降到300，保证一条问答不会被硬拆成两段。Dify支持为每个知识库单独设置分段规则，所以建议把不同来源的文档放到不同知识库里，分别调参。

3.3 索引方式与Embedding配置

分段设置完之后，Dify会要求选择索引方式。我建议选“高质量”模式，这个模式下文档会真正进行向量化，检索准确率有保障。经济模式本质上只做关键词匹配，省了向量计算资源，但检索效果会差一个量级。个人电脑如果配置不太差，完全没必要省这些资源。

接着配置Embedding模型。这一步是在Dify的“模型供应商”里先填好模型API，然后在创建知识库的时候选择它。如果用本地模型，需要先把模型接入Dify支持的推理服务，或使用兼容OpenAI接口的方式接入。Dify的官方文档写得很清楚，照着配置就行，注意区分“系统推理模型”和“Embedding模型”两个入口，很多人第一步就填错位置。

索引完成后，Dify会展示文档的分段预览，一定要花时间检查。我每次导入新文档后都会先翻几页分段预览，看看有没有明显的切分错误。比如一个表格被拆成几段、一个标题和正文被拆开，这些问题在预览阶段就能发现，比之后检索出错再排查要省事得多。

3.4 应用编排：把知识库接到聊天助手

知识库建好之后，要到“应用”里创建一个聊天助手应用。Dify的编排页面是可视化的，你只需要在“上下文”里加入刚才建好的知识库，然后设置提示词就可以。这个过程和前几年大家用提示词模板不一样，这里的核心是“给模型指定信息来源和回答边界”。

我先说我用的提示词思路，它不需要很复杂，但必须包括四点：第一，你是知识库助手；第二，回答时优先参考上下文中的资料；第三，如果资料里找不到答案，要直接说“没有找到相关内容”，不能编造；第四，回答尽量列出引用的来源文件或片段，方便验证。实际提示词我会写得更细一点，但核心就是这四条。

应用侧还有一个“召回设置”，这里有两个参数很重要。TopK代表每次检索最多召回多少个片段，我默认设成5，回答内容会比较充实。如果答案经常偏离主题，可以降成3，减少无关片段干扰。还有一个是Score阈值，也就是相似度阈值，低于这个值的片段会被过滤掉，我习惯设成0.5左右。如果你的知识库内容比较创新、术语多，阈值可以适当下调，否则容易什么都召回不到。

3.5 元数据过滤：很多人都栽在这里

这里单独讲一下“元数据过滤”，因为相关热词里出现了“dify知识库元数据无法过滤”，说明这个问题很普遍。元数据可以理解为给文档加的“标签”或“属性”，比如文档类型、来源部门、日期、作者、专利号、项目编号等。有了元数据，检索的时候可以按条件过滤，比如“只查2024年的文档”“只查技术方案类文档”，这在企业知识库场景里非常重要。

Dify知识库是支持元数据属性和过滤的，但很多人用不好，原因往往是建知识库的时候没有提前设计好“属性”。你得在建库之前想好，哪些字段是固定维度，比如来源类型、所属项目、日期，然后在创建知识库或上传文档时设置好。如果文档已经入库之后再补元数据，编辑量会很大，而且在Dify的免费版本里元数据编辑入口藏得比较深，容易找不到。所以我的经验是：在批量上传文档之前，先整理一个Excel表格，把每个文件的标题、来源、类型、日期、项目字段填好，导入的时候按字段填到元数据里，后面过滤时就非常灵活了。

另外还要注意，Excel本身是二维数据，直接传进知识库并不能自动理解“这一列是日期、这一列是项目名”，它只会把表格内容当成普通文本。所以涉及“Excel进知识库”的场景，我得提醒你：要么先把Excel转成若干条带上下文的文本记录，要么利用Dify的分段功能把表格的每一行做成一段，再把列名拼进去作为前缀。我亲测下来，后者效果更好，比如原始表头是“项目名称|报价|负责人”，转换成文本后就是“项目名称：XXX，报价：XXX，负责人：XXX”，这样才能保证检索到具体报价时，上下文里的字段含义是完整的。

4. 检索效果差？记录一次完整的调优实录

4.1 第一次测试：看着能用，实际不行

知识库搭好之后，我迫不及待开始测试。第一轮我挑了几个业务相关的问题去问，刚开始感觉还像模像样，但深挖几步就露馅了。比如我问“上季度某个项目合同金额是多少”，它的回答里出现了一个数值，但我翻遍资料都没有对应出处，完全是在“脑补”。这就是典型的检索不到但强行生成。我又测了一个更基础的问题，直接问一个PDF里的专业术语定义，结果它说“根据资料……”，但引用的片段名明显对应错了文件。

第一次测试的这个结果，让我意识到两个问题：一是自己的提问太口语化，知识库检索是相似度匹配，问题里的关键词和文档用词不一致，匹配度就低；二是参数没有调好，TopK太小、相似度阈值太低，导致相关片段被过滤掉，模型只能瞎编。这让我决定系统性地做一轮调优，而不是继续零散试错。

4.2 逐步调整：从分块、召回参数到Rerank

我的调优顺序是从底层到上层，先查数据、再查检索、最后才改提示词。

第一件事是检查分段质量。我发现不少PDF在分段预览里出现了“标题单独一段”“正文段首多出很多空格”的问题，这类脏数据即使检索到了，也很难被模型用好。我重新清洗了文档，把异常换行合并，重新导入。这一步之后，部分简单问题的检索准确率就有明显提升。

第二件事是调整召回参数。原先TopK=3，Score阈值0.8，导致很多相关片段被过滤掉了。我把TopK调成5，Score阈值降到0.4，召回范围变大，模型能看到的参考资料多了，回答就稳了很多。但这个时候我发现一个新的问题：TopK变大之后，无关片段也混进来了，模型有时候会被坏信息带偏，反而答得不如原来。

于是第三步，我引入了Rerank重排序环节。Dify的应用编排里可以加Rerank模型，作用是对召回的候选片段做一次更精细的排序，把最相关的内容排到最前面，同时过滤掉不相关内容。我使用的是bge-reranker-v2-m3，本地跑也很轻松。加了Rerank之后，TopK即使设为5，模型拿到的片段质量也更高，问题基本得到了解决。

4.3 建立属于自己的QA测试集

调优过程中，我最大的体会是：没有测试集，调优就是瞎调。你不能每次改一个参数就去随机问几个问题，那样看不出效果。我的做法是拿出一张Excel表，把平时可能问的问题整理成三类：一是“事实题”，答案应该在文档里有明确出处；二是“归纳题”，需要综合多个片段总结；三是“边界题”，文档里没有相关内容，考验模型会不会拒绝回答。每一类准备10到20个问题，然后把答案记录下来打分。改完参数后，同一套题再跑一遍，对比答案质量和引用正确率。

这个测试集一开始很粗糙，但胜在坚持用。我后来就是不断跑题、打分、对比，才找到最适合自己知识库的参数组合。题目的设计也有讲究，不能只写简单的事实题，因为这类题对检索要求低，容易给你“效果不错”的错觉。至少要有一半问题是需要跨文档归纳的，不然你调的参数永远只能适配简单问答。

4.4 常见问题速查表

把我在调优过程中遇到的问题整理成了一张表，希望后来人能少走弯路。

这张表不能包治百病，但它能帮你把问题定位到正确的环节。最怕的是遇到问题就一股脑调提示词，结果底层分块就有问题，怎么调也救不回来。

5. 从“能用”到“好用”：下一步计划与安全提醒

5.1 下一步：给知识库加上Agent和自动化能力

粗糙版跑通之后，我开始规划让它更“好用”的方向。第一个方向是接入Agent能力。Dify本身支持创建Agent应用，可以让它调用工具。我计划给知识库加上两个工具：一个是联网搜索，用于补充库外最新信息；另一个是数学计算或代码解释器，用于处理需要计算的问题。这样知识库就不只是“查资料问答”，还能真正完成一些任务。

第二个方向是自动化数据同步。目前我的流程还比较手工，新文档要手动上传到Dify。下一步打算写一个监控脚本，把某个文件夹里的新文件自动上传到对应知识库，这样每次写完Obsidian笔记，保存后稍等一会儿知识库就能同步。再往后还可以通过Dify的API，把企业内部的OA系统、项目管理系统数据定期同步到知识库里。企业知识库的搭建，很大一部分工作量就在数据接入和权限控制上，自动化同步能解决“知识更新不及时”这个致命问题。

第三个方向是多人协作与权限。个人知识库基本不需要权限，但企业知识库需要考虑谁能看到哪些内容。Dify的知识库层面虽然已经做了基本的访问控制，但要做到更细粒度的文档级权限，还要结合元数据过滤和多个知识库拆分来实现。建议把高敏感文档和普通文档分库存储，然后用不同的应用来承载不同场景，从应用层隔离会比较清晰。

5.2 安全提醒：私密数据别乱传

提到知识库，必须认真提醒一下安全。现在很多在线大模型接口用起来很方便，但你要意识到，你把文档片段和问题发给它的那一刻，数据已经在第三方服务器过了一遍。个人使用、不涉及机密时问题不大，但如果是公司内部资料、合同报价、个人隐私，就要格外谨慎。

我的做法是分场景处理：不敏感的资料可以走在线模型，方便且效果好；敏感资料全部走本地Embedding模型加本地生成模型，断网也能用。Dify支持全部本地化部署，Embedding模型和生成模型都可以选择本地模型，这样数据只在你的机器内部流转，不会外泄。如果你确实需要使用在线API，建议先做脱敏处理，把文档里的文件名、人名、手机号等敏感信息替换掉再入库。

还有一个容易忽略的问题：不要把知识库的访问链接随意分享出去，尤其当你把Dify部署在公网时，要设置好访问密码或API密钥。我见过有人部署了开源知识库，为了图省事没设访问控制，结果整个库可以被任何人查询，这是非常危险的。如果只是本机使用，最简单的方式就是只监听本地端口，不给外网访问权限。

5.3 最后一点个人体会

整个“粗糙版”知识库搭下来，我最深的体会是：真正难的其实不是技术，而是“你知道自己要解决什么问题”。如果你只是想让自己找资料快一点，完全没必要上复杂框架；如果你想要一个真正能支撑业务的系统，那也要从最简单的闭环开始迭代。

我在搭完之后回头看，最有价值的不是“我会用Dify了”这件事，而是我终于理解了一个知识库从文档到切分、从向量化到召回、从提示词到生成的完整链路。以后不管换什么工具、换什么框架，只要这个链路还在脑子里，我就能快速定位问题。

最后再分享一个小技巧：如果你也在用Obsidian，建议你插件的“Core plugins”里打开“Daily notes”，每天写一条短日志，记录当天遇到的问题和解决方案。这些短日志攒一个月之后丢进知识库，你会发现AI知识库反而成了你的“第二大脑”，很多以前记不得的细节，它能帮你精准捞出来。工具可以迭代，但持续输入高质量内容，才是知识库真正有用的根基。

这就是我的“粗糙版”AI知识库搭建全过程，希望对你有帮助。如果你也准备动手，记住一个原则：先跑通，再调优，最后再考虑花里胡哨的工程化。