打造可持续追问的个人知识库：PDF/Markdown与RAG实践

PDF、Markdown 和项目资料到底能不能用一个 AI 工具沉淀成个人知识库？这个问题我琢磨了挺久，市面上号称能做知识库的产品不少，但真到自己手里的文档格式、项目笔记、散落各处的资料时，大多只能做到“能问，但问不深”。后来我干脆自己搭了一套可持续追问的知识工作台，把文档解析、向量检索、多轮对话串起来，才算是真正解决了问题。这篇文章就把整套搭建思路、关键步骤和踩过的坑完整记录下来，供想折腾同样东西的朋友参考。

1. 先把问题拆开：为什么需要一套“知识工作台”而不是笔记软件

1.1 资料很多，但“找”和“用”是两回事

做技术、做研究、做项目的人，手头最多的就是 PDF 论文、Markdown 笔记、项目文档、需求说明。这些东西散在不同文件夹里，平时想用的时候只能靠文件名回忆。更麻烦的是，同一个主题的知识往往分布在好几份资料里，比如一份 PDF 里讲了原理，另一份 Markdown 记录了我当时的实践结论，项目资料里还有一堆相关代码注释。靠 Ctrl+F 和“我记得好像在哪见过”，根本串不起线。

我一开始也试过普通笔记软件，把 PDF 转成文本，把 Markdown 按标签整理，最后发现只是把“找不到”变成了“找到文件但还得自己翻”。整理本身变成了第二份负担。真正的诉求不是“管理文件”，而是“让我用大白话直接问，并且它能回答到点子上”。这就需要知识库具备理解、检索和归纳的能力，也就是 AI 工具的活儿了。

1.2 “可持续追问”为什么是核心需求

很多 AI 问答工具能做到“单轮对话”：你问 PDF 里某个指标是多少，它给你一段原文。但实际使用中，人的思维方式是连续的，比如我读一份 PDF，会先问“这个项目用的什么方法”，得到答案后自然要问“那这个方法有什么前提条件”，再往下还会问“第 4 章里是不是有个实验跟这个前提矛盾”。这才是真正的工作场景。

如果知识库答完第一个问题就“失忆”，第二问必须重新说清楚背景，那这工具就只能当个高级搜索引擎用，帮不了思考。所谓“可持续追问”，就是要让 AI 带着前一轮的答案和上下文去进行下一轮检索，它像你身边一个读过全部资料、还愿意陪你捋思路的同事。这个能力不是靠某个大模型 API 开箱即得的，它依赖整套对话层设计、检索策略和知识库的架构配合。

1.3 直接买现成工具还是自己搭流水线

市面上现成的“文档问答”工具不少，轻量的像豆包知识库，导入文件后能直接基于文件问答，适合临时处理小体量资料，但自定义空间有限。开源阵营里有 Dify、FastGPT，它们提供可视化知识库流水线，支持自己控制文档解析、切分、检索和模型配置。还有一个方向是 Obsidian 这类本地笔记工具，配合 AI 插件或 Trae 这类集成环境，把 Markdown Vault 变成可检索的知识库。

我最终选了“Dify + 向量库 + 本地文件留底”的组合。原因很直接：PDF 的解析策略、切分粒度、检索方式，我都需要能调；项目资料经常涉及代码和内部文档，放第三方平台不安心；更重要的是，只有自己搭，才能做出“多轮追问不断档”的体验。这套方案以 Dify 为工作台，Qdrant 做向量存储，模型层用开源 Embedding 加商用大模型推理，整体可控性很高。

2. 资料接入层：让 PDF、Markdown 和项目资料“可读、可切、可检索”

2.1 PDF 解析的几种方式和取舍

PDF 是所有资料里最麻烦的格式，因为它本质是“排版格式”而不是“文本格式”。解析时首先要判断是文本型 PDF 还是扫描版 PDF。文本型 PDF 可以直接用 PyMuPDF 或 pdfplumber 抽文字，速度快，能保留段落顺序；扫描版就得走 OCR，我用的 PaddleOCR，识别中文效果比较稳定，还能输出相对坐标，方便后面重建结构。

表格是另一个大坑。很多 PDF 里的表格一旦解析成纯文本，行列关系全乱，AI 读起来就会“看图猜谜”。我的做法是偏向保留 Markdown 风格的表格结构，把表头、分隔符、数据行处理成规范文本。实操中发现，如果 PDF 本身是论文或书稿，先转成 Markdown 再入库，明显比直接把原始解析文本丢给知识库更干净。Dify 内置的文档解析能力对付简单文本还可以，复杂排版我不太放心，一般会预先处理一遍。

还有一个小细节：PDF 转文本后经常残留页眉页脚、页码、目录占位符，这些噪音会污染向量召回。我在预处理时写脚本按“页眉/页脚位置 + 重复内容特征”清洗掉。刚开始觉得没必要，后来发现这些重复文本被大量切进块里，导致检索时经常命中废话片段，清洗之后效果立竿见影。

2.2 Markdown 文件的处理细节

Markdown 是我知识库的“主力格式”，因为它结构语义清晰，标题天然是章节的边界。处理 Markdown 时最重要的原则是：标题层级就是切分锚点。我的笔记里通常有#、##、###层级，Dify 支持自定义分段标识符，我会让它优先在标题处切分，保证每一个块都是相对完整的语义单元。

这里要特意提醒一下 Markdown 换行的问题。很多人在 Markdown 里用“两个空格 + 回车”做软换行，这在使用时没问题，但程序按行做切分时，会把同一段落硬掰成两截，造成语义断裂。我后来统一改成空行分段，切分效果好了很多。代码块也要单独处理，如果一段代码被切成两半，检索出来就是残废。

我还会刻意在 Markdown 文件开头写清楚“文件主题：XXX”和“适用场景”，相当于给知识库一个起搏器。因为向量检索本质上靠语义匹配，如果文件本身逻辑清晰，检索命中率会高很多。

2.3 项目资料到底怎么“喂”给知识库

项目资料跟 PDF、笔记类资料不同，通常包括 README、接口文档、需求说明、代码文件、数据库字典、会议纪要等。一开始我图省事，把整个仓库丢进去索引，结果召回结果一塌糊涂。因为代码里的变量名、函数名对向量检索来说噪音极大，它不像人一样能“看代码理解业务”。

后来我调整策略：只提炼每个模块的 README、核心接口说明、关键的代码注释、变更记录、架构图说明，统一整理成合适的 Markdown 后再进知识库。代码本身不整体入库，而是把“代码做了什么、怎么调、边界条件是什么”提炼成文本。这样既保留了项目的关键知识，又不会让一堆无关代码淹没检索结果。

这个理念可以类比成“给知识库做压缩而非拷贝”。项目资料的价值在决策逻辑和调用关系，不在代码字符本身。如果你需要 AI 读完整代码库，那更适合用专门的代码检索工具，而不是塞进通用知识库。

3. 检索增强生成（RAG）的核心：切分、向量化与召回优化

3.1 RAG 流水线到底做了什么

RAG，也就是检索增强生成，是这套知识工作台的地基。它的流程很多人听过：把文档切成块，用 Embedding 模型转成向量，存进向量库；用户提问时把问题也变成向量，在库里检索最相似的块，拼起来交给大模型生成答案。但实际跑起来，每个环节都有调优空间。

用生活类比：向量库就像一个图书馆，所有书都被拆成段落，每段都贴了编号和借书卡；用户提问就像拿着描述来找书，图书管理员先用“和描述最像的段落”筛一遍，再把候选段落原文递给一位学者，让他结合段落来回答。所以，段切得好不好，借书卡编得合不合理，直接影响学者的回答质量。

3.2 切分参数：别照搬默认值

切分（chunking）是整个 RAG 里最容易被忽略的环节。默认切分参数通常是固定长度加重叠，比如每 512 个字符切一块，块与块之间重叠 64 个字符。这个参数在通用场景下能用，但对专业资料来说太粗糙。

我的经验是切分长度要看资料类型：论文类 PDF 偏长段落，我会把 chunk_size 调到 700 到 900，overlap 设为 100；Markdown 笔记则按标题切，不固定长度；代码密集的项目文档，chunk 反而要短一些，300 到 500，避免一个块里塞进多个函数说明。切分的目标是：一个块内部只围绕一个主题。宁可块多，也不要一块多义。

如果用的是 Dify，可以自定义分段符，比如把##、#、空行都作为切分锚点。我实际比较过，按标题切分后的召回准确率明显高于固定长度切分，因为 AI 拿到的“上下文”是完整的章节。

3.3 Embedding 模型怎么选：中文场景优先考虑 BGE

Embedding 模型决定了文档和问题能否被映射到同一个语义空间，选错了，后面所有检索都是空转。如果资料以中文为主，我推荐 BAAI 开源的 bge-m3 系列，它在中文语义理解、长文本处理上表现稳，对长尾术语也比较友好。如果是混合中英文，可以考虑商用的 text-embedding-v3，维度更高，召回更细腻。

还有一个小模型能否做知识库的问题。完全可以。知识库的检索质量主要取决于 Embedding 模型和小块切分的配合，真正生成答案时才用大模型。所以哪怕用一个参数量不大的 Embedding 模型，只要向量质量够，问答体验不会差到哪里去；反而是嵌入仓库文件质量差，用再大的模型也救不回来。

用 Embedding 模型时留意向量维度和向量库的兼容性问题。例如 bge-m3 默认输出 1024 维，Qdrant、Milvus、Chroma 都支持，但如果前期用了别的模型生成了一批向量，中间切换模型会导致旧向量无法检索，要么全量重建，要么用一个升级工具平滑迁移。这个坑我踩过一次，之后所有资料入库前都会先确认“整套流水线用同一个 Embedding 版本”。

3.4 召回优化：混合检索 + 重排序是性价比最高的两步

向量检索擅长找“语义相近”，但它在处理精确匹配时容易翻车，比如搜“QPS 5000”这种数值，向量空间里可能被匹配到“性能测试 500 并发”这类相近但不准确的片段。解决办法是加混合检索：同时跑向量召回和关键词召回，再把两路结果合并去重。

合并完后还有一个关键动作：重排序。用 bge-reranker 这类模型对候选片段逐一打分，从中选出与问题最相关的前几条。我试过不加重排和加重排两种模式，对比非常明显：不重排时偶尔能答对，但经常答非所问；重排后大部分回答都能锁定到正确章节。重排相当于从图书馆“可能相关的 30 本书”里精挑出“真正回答问题的 3 段”，这一步对体验提升巨大。

具体到 Dify，可以在知识检索节点里配置召回模式为“混合检索”，然后挂一个 Rerank 模型。很多人做知识库时跳过重排，其实代价就是答案泛泛而谈。建议只要资料量超过一百份，就一定要把这个环节补上。

4. 可持续追问：对话层设计与知识 Agent 化

4.1 多轮追问为什么常常“断片”

先说说大多数人遇到的现象：第一问“这个方法是什么”，AI 答得很好；第二问“那它跟上一章的传统方法有什么区别”，AI 就答不到点子上了。原因在于，很多知识库问答系统每次都是独立检索，第二问里的“它”“上一章”指向的是上一轮的上下文，但系统已经把上一轮答案忘了。

解决思路是让对话系统把历史信息重新表达成检索语句。比如用户问“那它跟传统方法的区别是什么”，系统内部先把问题重写为“C 项目采用的方法与第四章传统方法的区别”，然后带着这个新问题去检索。这个过程叫 Query Rewrite，在 Dify 的 Chatflow 中可以用一个节点实现：把历史对话记录和当前问题一起传给大模型，让它生成一个规范化检索问题，再丢给知识检索节点。

4.2 在 Dify 里设计一个能“追问下去”的对话流

搭建时我用的是 Dify 的 Chatflow 模式，而不是简单的助手模式。Chatflow 里把“意图判断、问题重写、知识检索、答案生成”拆成独立节点。意图判断节点先识别用户问题是否涉及知识库，如果用户只是在闲聊或者请求写代码，就不必走检索流程。如果涉及知识库，就进入问题重写，再进入检索，最后把所有检索片段和对话历史一起交给大模型组织答案。

关键是给大模型的 Prompt 里明确要求“优先引用知识库原文片段，并在回答结尾列出资料来源”。这看起来只是细节，但对持续追问很重要：用户看到来源，可以选择“继续展开第几条”，追问就在有据可查的前提下深入下去。

我还加了一个“追问建议”节点：在 AI 答完主体内容后，根据检索到的片段，主动生成两个相关追问提示。比如答完“延迟数字是多少”后，它会问“这个数字是实测还是估算？要查看测试条件吗？”效果就像有人在引导你继续读资料，知识工作台的体验一下子就立体了。

4.3 知识 Agent 化：把知识库当成一个工具，而不是另一种聊天框

单纯做一个“问知识库”的聊天框，本质上还是被动应答。我后来把知识库包装成一个 Agent，给它定义工具能力：除了检索知识库，还可以调用日期、访问特定统计脚本、查询本地资料目录。这么一来，用户可以说“总结一下最近一周我 Markdown 笔记里新增的主题”，Agent 会先列目录、看文件修改时间，再进入知识库检索。这就是 Agent 化的价值，知识库不再是孤岛，而是能被调度、能主动处理复杂任务的工作台组件。

在实际操作里，很多人的误区是把 Agent 等同于“更聪明的问答”，其实 Agent 的核心是“工具使用 + 自主决策”。你的知识库可以是一个工具，你的文件更新检测脚本也可以是另一个工具，Agent 会自己决定先用哪个、怎么组合。

4.4 把网页、公众号文章也纳入知识库

做知识库的人一定遇到过这种情况：好文章在公众号里，网页资料藏在一个页面链接里，直接复制排版乱，保存成 PDF 又麻烦。解决方法是让 Agent 拥有一项技能：把网页正文转成 Markdown。热词里提到的“agent 将网页保存成 markdown 的 skill”就是这个意思。可以借助浏览器扩展，或是一段 Python 脚本，把文章标题、正文、图片路径整理成 Markdown 文件，再放进统一的自建知识目录。

我个人的做法是：在浏览器里看到想收藏的文章，一键保存成 Markdown，文件名按“年份-类别-主题.md”命名，丢进工作台的输入目录，知识库做全量增量同步。这套闭环跑通之后，知识工作台才真正“活”了，每天新鲜内容持续沉淀，AI 也能基于最新语料回答。

5. 常见问题与排查技巧实录

5.1 PDF 表格识别乱、图片版式跨页

PDF 转出来的文本经常出现表格错位，比如“金额 1000 元”被拆成两行，“字段名”和“值”对不上。我遇到这种情况，会先不急着入库，而是用脚本把表格区域单独提取，转成规范的 Markdown 表格，确认关键数字没有错位后再入库。如果 PDF 是扫描版，OCR 时的版面分析也很重要，PaddleOCR 的表格还原能力比我之前用的 Tesseract 好不少，中文图书扫描件基本能还原。

跨页表格的问题，我通过“合并相邻页表格片段”的预处理解决。逻辑是：检测表头重复且结构相同，就把表格拆分后的多个片段合并成一个逻辑块，避免 AI 只看到表头却没看到内容。很多人在这步卡住，其实只要在解析阶段多下功夫，后面检索会非常省心。

5.2 知识库“排队中”、批量导入卡住的排查

用 Dify 自建知识库时，有时批量上传几十个文件后状态一直显示“排队中”。主要原因是并发解析线程和 Embedding 服务吞吐不够。解决方法是：降低导入并发数，把大文件拆成小文件分批处理；如果 Embedding 模型部署在本地，还要检查 GPU 显存是否被占满。我后来把所有超 10MB 的 PDF 先按页拆分再导入，问题基本消失。

另一个经验是不要一次性把几千个文件全塞进去，最好分批、分类、分主题来，比如今天导入全部 PDF，明天导入 Markdown。分批的好处是出了问题容易定位，是解析挂了还是哪一类文件格式不被支持。

5.3 问答答非所问、检索不到文件的三步排查法

第一步看召回片段，在知识库调试页面里检查召回的 3 到 5 个块是否与问题相关。如果召回的全是不相关内容，要考虑切分过大导致块内主题混杂，或者 Embedding 模型不擅长这类术语。

第二步检查问题与资料的用词差异，比如文档里写的是“卷积神经网络”，问题里用“CNN”，向量召回有时匹配不上。此时需要给知识库补充同义词映射，或者在 Query Rewrite 节点里把缩写展开为全称再检索。

第三步看是否命中噪音块，页眉页脚、目录、重复表格即使被召回，也不该作为最终答案来源。我建议在 Prompt 里明确告诉模型“如果召回片段包含页眉、页码等噪音内容，忽略它们，并结合其他片段回答”，这一招对最终效果提升明显。

5.4 常见问题速查表

6. 从这套工作台中得到的真实体会

工具搭完以后，我最深的感受是：个人知识库的价值不在于“存了多少文件”，而在于它是否真正陪你思考。以前我翻 PDF 里的关键段落要花十几分钟，现在直接追问“这个方法的局限性在第几节”，AI 能带着出处回答，我再按需深入。这种工作方式让资料不再是死内容，而是能主动参与讨论的参谋。

如果你也想搭一套，我建议从小处开始。先用豆包知识库或 Dify 的现成模板跑通一个小规模知识库，确认自己真实使用场景是“大量 PDF 论文”还是“项目技术文档”，再决定要不要卷自定义切分、重排、Agent 化这些复杂功能。别一上来就追求全功能。很多朋友问我是不是必须用本地模型，其实初期完全可以用 API，先把流程跑起来，后续再优化隐私和成本。

最后再分享一个小技巧：知识库的目录结构和“文件主题声明”比你想的重要一倍。我后来把每个 Markdown 文件开头都写上主题关键词、适用场景和关联文件，检索效果直接上了一个台阶。资料越规整，AI 越聪明，这话放在知识工作台上再合适不过了。