系列第二篇接着说知识库。上一篇我们完成了本地私有化机器人的第一步把大模型放到本地用 Ollama 跑通了基础对话。今天这一步更关键也更容易踩坑——给这台机器人接上知识库 RAG 能力。对于大多数人来说所谓“知识库”本质上是想让机器人能回答你自己文档里的内容而不是只会泛泛聊天。整篇文章围绕一个目标让文档以结构化方式进入本地索引查询时能精准捡回最终由本地模型结合上下文生成有依据的回答。适合已经跑通本地模型、想给机器人喂自己资料的人也适合被各种 RAG 教程绕晕、想找一个能直接抄作业的方案的人。我不打算一开始就讲高级重排和混合检索因为本地部署场景下最影响效果的永远是文档清洗和分段。先把这两件事做扎实后面所有环节都会顺很多。这篇文章会把从文档进来、清洗、切分、向量化、检索、问答到评测的完整链路过一遍并把我实际配置时用的参数、踩过的坑和排查思路写清楚。1. 整体设计思路先想清楚机器人的“记忆”放在哪一层1.1 私有化的边界模型、数据、索引分别藏在哪里很多人一听到“本地私有化”第一反应就是“模型跑在我电脑里”。但真要搭建知识库光模型在本地还不够。你要想清楚私有的边界到底画在哪一层模型权重是否在本机原始文档是否只在本机流转向量索引存放在哪里以及每次提问和回答时有没有偷偷把数据拼进外部请求。我见过一个尴尬的情况模型用的是本地 Ollama但知识库的 embedding 接口配成了云服务结果每次文档入库都要把整篇文档发到外部去算向量。这等于把最核心的资料送出了门私有化就名存实亡了。所以我的原则是本地私有化机器人方案的每一环从加载、切分、embedding 到向量存储和生成尽量都落在本机。“机器人”这个词在本地部署场景里指的其实是一个能持续学习你资料的对话代理。它可以把产品手册、接口文档、项目笔记、会议纪要这类零散素材吃进去然后在你问“这个配置对应哪个字段”“之前那个故障是怎么解决的”时给出来源明确的答案。对个人开发者或小团队来说这比各种云端的在线问答工具省心得多至少不用担心资料被拿去训练模型。1.2 RAG 最小闭环加载、切分、embedding、检索、生成先理清知识库 RAG 的最小闭环。它的流程可以压缩成一句话把文档切成一段段、转成向量存起来提问时把问题也转成向量找出最相似的几段塞进提示词让模型基于这几段内容做回答。这么设计的原因很直接。大模型的知识在训练时就已经固定了你没法让本地模型重新训练一遍去学你的私有资料那样既慢又贵。RAG 的思路是绕开训练把“知识”外挂到模型外面不是让模型记住你的文档而是让模型在回答前临时“查资料”。这个方式天然适合知识库因为文档可以随时增删改只要你重新索引一遍机器人的知识就同步更新了不需要重新训练模型。在这个闭环里加载和切分最不受重视但恰恰最决定上限。嵌入模型负责把文本变成向量它只负责“相似度匹配”并不负责理解文档结构。如果原始文本很脏切分得很乱后面检索到的东西自然也不会准。所以我会把更多篇幅放在这两个环节上。整个链路跑通之后你才能进入下一步调 hit rate、加引用来源、做多轮问答优化。2. 工具选型Dify、Ollama、向量库怎么组合最省心2.1 底层模型继续用 Ollama中间编排器选 Dify 的理由本地部署方案里我最常用的组合是 Ollama Dify。Ollama 负责把模型拉起来Dify 负责把知识库流水线和机器人应用串起来。上一篇文章已经聊过 Ollama 的模型管理这里重点说为什么中间编排层我选了 Dify而不是自己写一套 Python 脚本去调 API。自己写代码搭建 RAG 不是不行用 LangChain 或者 LlamaIndex 也能做得很好但对很多人来说调试成本太高。你得自己处理文件解析、分段规则、向量库连接、提示词构造、召回结果展示每一步都可能出问题。Dify 的好处是它把这些环节以可视化流水线的形式摆在你面前知识库的建立、分段模式、索引状态、召回测试都有明确入口出了问题你能直观看到是卡在入库还是卡在检索。更重要的是Dify 社区版是开源的可以本地部署关闭遥测之后整个流程都留在你的内网环境。它天然支持配置 Ollama 作为模型供应商而且可以单独指定对话模型和 embedding 模型。这意味着我可以在 Ollama 里用 Qwen 系列做回答生成同时用 bge-m3 这类中文友好的模型做向量化两套模型互不干扰。有朋友问过我用豆包这类在线工具搭知识库行不行。如果你装的是那些云端对话应用它们确实有知识库功能但文件要传到对方的服务器这不是严格意义上的本地私有化。Dify 这类开源工具的价值就在于你拥有整个系统本身而不是在别人平台上开个知识库会员。2.2 向量库的选择内置还是独立部署向量库是用来存文本向量和做相似度检索的引擎。Dify 部署时会提供向量数据库的选项不同版本默认配置不一样。我个人的建议是先别纠结初期测试阶段用默认内置就能跑通数据量大了再迁移到独立的向量数据库。内置方案最大的优点就是省事Docker 启动时直接初始化好你不用额外维护一个数据库服务。对于个人知识库或者几个 G 的文档量内置完全够用。但如果你打算长期使用或者文档量会持续增长我建议早点换到独立向量库比如 Qdrant、Milvus 或者 Weaviate。独立部署的好处有三个一是索引和查询可以分开调度不容易让知识库入库任务和问答请求抢资源二是可以更精细地配置 embedding 维度、索引参数方便后续做过滤和分片三是后续如果要把同一个向量库同时接给多个机器人或服务独立部署更灵活。迁移时有几个参数需要你同步确认向量维度必须和嵌入模型输出一致比如 bge-m3 是 1024 维nomic-embed-text 是 768 维。如果迁移后维度对不上检索肯定会报错。再一个是相似度计算方式常见的有余弦相似度和内积Dify 里配置向量库时会让你选改成独立库之后要保持一致。2.3 图片入库到底行不行多模态 RAG 的现实与替代方案很多人问 rag 知识库能存储图片吗知识库图片怎么处理。这个问题我在项目里也遇到过这里说点实际结论。传统的 RAG 流程是纯文本的加载、切分、向量化都只针对文本内容。图片不能直接丢进去算文本向量除非你用的是多模态 embedding 模型把图像和文本映射到同一个向量空间。但在本地部署环境里多模态 embedding 模型体积大、资源占用高而且对接 Dify 这类平台时支持程度有限不算是一个随手可用的选项。实际项目中更稳的做法是把图片转成“文本描述文件引用”再入库。比如产品截图你可以用 OCR 把图里的文字提取出来架构图或者流程图可以手动或者借助视觉模型写一段图内包含什么层级关系、包含什么模块的描述。然后把这段描述作为知识库的一个 chunk 存进去同时保留原始图片路径。用户问到时机器人检索到这段描述可以在答案里引用图片路径让你能打开原图核对。这个方法虽然听起来笨但非常可靠而且不挑模型不用为了一张图去专门跑一个大体积视觉模型。如果你确实想实现“看图问答”也不是不行方案是把视觉模型的图片输入能力接到机器人的对话入口让用户直接上传图片提问同时配合知识库文本检索。这一步属于多模态机器人 AI 的方向可以放到后续版本再做。第一版知识库 RAG 搭建先把文本链路做稳图片就用“文字化”的方式处理。3. 知识库实操从文档清洗到流水线配置的完整过程3.1 文档加载与清洗废话越少效果越好现在就进入实操。先把市面上各种概念放一边回到 Dify 的知识库创建界面。你会上传一批文档常见的有 PDF、Word、Markdown、TXT。上传之后Dify 会走一遍它的流水线包括文档解析、分段、嵌入索引。但默认解析只是帮你把文本提出来不会帮你判断哪些内容是有效的。我强烈建议在上传前先做一次清洗。清洗不是让你重写文档而是把明显影响检索的内容处理掉。最常见的是页眉页脚PDF 导出后几乎每页都带页码和公司名这些内容切进 chunk 里全是噪音。其次是目录页有的 PDF 目录占了十几页索引进去之后你问什么它都可能被目录里的标题分散注意力。还有大量空行、表格拼接产生的乱码、Tab 键带来的缩进符号这些都会污染向量。清洗这一步我用的是脚本加人工抽查结合。Python 写个脚本把 PDF 转成纯文本先删掉页码和固定页眉再按章节标题把大文件拆成若干小文件最后把明显乱掉的段落删掉。对 Markdown 文件我一般只保留正文内容把 front matter 和无关标签去掉。完成清洗之后再上传到知识库后续检索质量会有肉眼可见的提升。有朋友问过有没有本地的 rag 文本拆解工具其实你不用专门找工具本地跑一个 Python 环境用 pdfplumber 或者 PyMuPDF 做解析再用正则做清洗完全够了。关键是清洗规则要贴合你自己的文档特点。比如我处理的是技术手册我就会保留代码黑体和表头字段它们对回答“参数是什么”“默认值是多少”这种问题非常重要。3.2 分块策略中文文档怎么切不伤语义文档清洗完核心环节就是分块。分块做不好检索就先天残缺。我调试时最常调的两个参数一个是 chunk size分段长度一个是 chunk overlap分段重叠长度。这两个参数看起来简单实际对结果影响很大。先说分块长度。对中文文档我一般把 chunk size 控制在 400 到 800 个字符。为什么不是越大越好因为检索粒度要够细。你问“这个模块怎么配置”如果一整页文档被塞成一个大 chunk向量会包含太多主题检索时虽然可能命中但模型看到的内容一半都是无关的回答自然发散。反过来如果 chunk 太短比如只有几十个字又会把连续的语义切断检索到的是一个残缺片段模型拼不出完整答案。重叠长度我通常设置为分块长度的八分之一到十分之一。比如 chunk size 600overlap 就设 60 到 80。重叠的作用是防止句子刚好被切在中间导致语义断裂。比如一个长段落里有一句关键结论如果被切成了两个 chunk哪个 chunk 都只有半个结论命中效果就会差。加上重叠之后关键句子至少会完整出现在某一段里。还有一个细节是分隔符。Dify 的分段模式里你可以自定义分隔符我的习惯是优先按 Markdown 标题和段落切其次按句号、问号、感叹号再其次按逗号。不要简单按字符数硬切这样最容易切碎语义。如果你导入的是结构比较规整的 Markdown 或者带标题的多级文档也可以考虑按标题层级来分段让一个章节成为一个完整 chunk。这里要结合文档实际情况反复试第一版先用通用分段后续再用标题分段对比 hit rate。3.3 嵌入模型选择与参数设置bge-m3 还是 nomic-embed-text分段确定之后要选嵌入模型。这是知识库 RAG 搭建里容易被忽视的一步。很多人觉得随便用个 embedding 就行但本地私有化场景下模型的中文能力差别很大。我在 Ollama 里常用的是 nomic-embed-text 和 bge-m3。如果文档以中文为主我建议优先选 bge-m3。它专门针对多语言做了优化对中文句子的语义理解明显好于通用英文嵌入模型尤其在长文本和相似词上表现更稳定。配置这一步在 Dify 里添加 Ollama 作为模型供应商之后选择你要用的嵌入模型填上对应的向量维度。bge-m3 的输出向量维度是 1024nomic-embed-text 是 768。维度填错会导致索引数据不一致检索报错。还有一点bge 系列在做检索时比较推荐给查询语句加一个指令前缀类似“为这个句子生成表示以用于检索相关文章”这样能提升查询向量和文档向量之间的匹配度。这个细节很多教程不会提但在本地 RAG 里实测有差异。嵌入模型的质量决定了检索的上限。如果你的文档是纯英文技术文档那 nomic-embed-text 也够用。如果文档中英混杂bge-m3 会更稳。反正 Ollama 里切换嵌入模型成本很低换完之后重新生成一次索引就能对比效果。嵌入模型不需要很大它不是用来生成答案的它只需要把文本映射到向量空间。在保证效果的前提下模型越小入库速度越快知识库排队的情况也越少。3.4 在 Dify 里创建知识库与配置索引流水线工具选好、参数定了接下来就是落地创建。第一次建知识库我建议按这个步骤来。第一步在 Dify 知识库里新建一个空白知识库给它起个能一眼看懂的名字比如“售后手册 2025”。第二步把清洗后的文档批量上传选好你要用的分段模式填入刚才说的分块大小和重叠长度。第三步在嵌入模型配置里选择 Ollama 和对应的 bge-m3。第四步触发索引等待状态从“排队中”变成“可用”。这里单独说一下“排队中”这个状态。很多人一看到知识库排队就以为卡死了其实这是 Dify 在处理索引任务文档多、嵌入模型加载慢都会导致排队时间变长。如果你用内置向量库同时并发的索引任务有限几十篇大文档进去自然会排队。遇到这种情况不要反复重新创建先等它跑完。如果长时间卡住不结束再检查 Ollama 的嵌入模型有没有正确加载或者有没有多任务挤占了模型资源。索引完成之后建议先做一次召回测试。在知识库界面里输入一个你事先准备的标准问题看返回了哪些 chunk相似度分数是多少。这一步能帮你确认流水线有没有真的跑通。我第一次跑的时候召回测试返回的内容跟问题完全不相关后来排查发现是嵌入模型选择错了踩的就是维度不匹配的坑。召回测试看到的结果才是一切调优的开始。4. 机器人问答实测从“有问必答”到“引经据典”4.1 检索命中的评估hit rate 自己怎么测知识库建好了机器人能不能用好检索结果直接看 hit rate。所谓 hit rate简单说就是在测试集里检索返回的前几个 chunk 中包含正确答案的比例。这是衡量 RAG 检索质量的重要指标。云端产品会帮你自动化评测本地部署就得自己动手。我的做法是准备一组标准问答对。从文档里挑出几十个关键知识点为每个知识点设计一个用户可能会问的问题同时记下这个知识点所在的 chunk。然后用召回测试接口对每个问题去检索知识库看返回的 top 3 或者 top 5 里有没有包含目标 chunk。命中数除以总数就是最简单的 hit rate。测试时要注意一个问题这里说的“正确 chunk”应该是人工确认过的答案来源不能看相似度分数高不高就算命中因为模型有时候返回了看似相关但实际没答到点的内容。我实际测过分块质量差的时候hit rate 可能只有四五成而清洗和分块调优之后能到八成以上。这个提升不是模型换出来的完全是检索环节调出来的。有时你会发现检索返回的内容和问题相关但答案是错的。这就涉及另一个层面不光是 hit rate还有生成的准确性。先记录这个现象后面调提示词和上下文时再解决。第一优先级永远是让正确的 chunk 被召回到。4.2 本地模型生成瓶颈上下文塞多少合适检索命中之后生成环节也要把握分寸。本地部署的大模型和云端大模型不一样它的上下文长度有限生成能力也相对弱。你不能把所有检索结果都往提示词里塞那样上下文很快会被撑爆模型反而不知道该看哪段。我常用的做法是限制检索的 top_k 在 3 到 6 之间也就是最多取回 6 个最相似的 chunk。同时设置相似度阈值低于某个分数就直接丢弃。比如阈值设在 0.35 到 0.5 之间太低容易混入无关内容太高又可能漏掉正确内容。这个值要根据你自己的嵌入模型和数据分布来调可以先从 0.4 试起。本地模型如果上下文只有 8K 或 16K讲道理 6 个 chunk 加提示词加历史对话可能已经吃掉大半。这时候我倾向于减少历史对话轮数只保留最近两轮而不是全部留在上下文中。因为对只回答文档内容的知识库机器人来说最重要的始终是当前问题和检索到的 chunk历史聊太久反而会干扰模型注意力。还有一个很常见的错误是检索到的多个 chunk 里可能内容互相矛盾。不同版本的文档、不同日期的手册同一件事可能有不同说法。模型会把几段话混在一起给出一个两头堵的答案。我的解决办法是在提示词里明确要求如果上下文存在冲突以最近更新时间和更具体的描述为准。这个小改动对实际体验的提升非常明显。4.3 把知识库接进机器人Dify 应用编排与引用输出现在终于进入“机器人”环节。在 Dify 里创建一个聊天助手应用选择 Ollama 里的对话模型作为生成模型然后把刚才建好的知识库加进应用关联。这一步之后机器人提问时就会自动走 RAG 链路先检索知识库再把检索结果拼到提示词里最后生成答案。我强烈建议打开 Dify 的引用输出功能。它的作用是把答案和对应来源 chunk 关联起来在界面上展示“这个回答引用了哪几段内容”。对知识库机器人来说带引用的答案和空口回答完全是两个体验。用户看到引用后能自己判断答案靠不靠谱出了问题也方便追溯是哪份文档造成的误导。这里还有一个容易被忽略的点提示词里要给模型框定边界。如果只写“你是知识库助手”模型很容易在检索结果不足时强行编一个答案。我实际测试下来提示词里强调“如果知识库中没有足够信息请明确说当前资料无法回答”能明显减少幻觉输出。这一步不需要多么复杂的提示词工程简单明确就好。机器人问答调优到这里基本上已经从一个“会聊天的模型”变成了“能用资料干活的助手”。剩下的问题基本都会落在检索质量和模型能力这两个维度上后面我们再说怎么继续摸参数。5. 常见问题排查知识库排队、命中率低、图片乱码这些坑5.1 知识库建好后高频问题速查表实践过程中我整理了一个高频问题速查表每一条都是实际踩过的。症状可能原因实操处理知识库一直排队中文档过多或嵌入模型加载慢内置向量库并发索引受限别反复重建等待索引完成检查 Ollama 嵌入模型是否正常加载回答完全没用知识库内容提示词没把知识库检索结果拼进上下文或应用没关联知识库确认应用配置里关联了正确知识库并检查引用输出是否开启检索到了但答非所问分块太长一个 chunk 里混了多个主题模型抓不住重点调小 chunk size按标题优先分段增加重叠长度中文问题检索效果差嵌入选了通用英文嵌入模型换 bge-m3 等多语言模型重新生成索引PDF 导入后表格内容全乱表格被解析成连续文本行列关系丢失上传前把关键表格手工转成 Markdown 表格或结构化描述图片上传后检索不到图片本身没有文本向量知识库没有可检索内容先用 OCR 或人工把图片内容转成文本描述连同原始路径一起入库这张表不算完备但覆盖了绝大多数初次搭建时的“劝退”问题。解决每一个问题的过程其实都是往更懂自己的知识库方向迈进。如果你在排查之后仍然遇到问题不要急着删库重来先看一下是哪个环节出的错加载、分块、嵌入还是检索。RAG 的问题几乎都能归到这四类里。5.2 命中率低的典型原因与我的调参顺序命中率低是知识库 RAG 搭建里最常见的困扰但很少有人告诉你调参顺序。我不知道你习惯怎么排查反正我的顺序是固定的从重到轻来排。第一清洗文档。我会先检查文档源里有没有大量页眉页脚、目录、乱码和无关段落。这些噪声混进 chunk 后向量空间会变得很乱许多时候不是参数不对而是数据本身不行。第二调分块参数。我按“先缩 chunk size再加 overlap再换标题分段”的顺序试。每次只动一个变量做一轮 hit rate 对比不凭感觉同时改好几个参数。第三换嵌入模型。如果中英文混杂我会把 bge-m3 作为默认项再对比换模型前后的召回结果。第四做检索测试。用若干标准问题跑召回观察返回的内容和相关度分数分布找到相似的“甜点区间”。第五再考虑混合检索和重排。很多人一上来就装重排模型调一堆高级参数但基础分块都没做扎实效果还是上不去。我个人的实际体会是本地部署环境里七成的问题出在前面三步。把清洗、分块、嵌入做对hit rate 就能拉到可用水平后面那些“高级优化”才谈得上。最后再分享一个小技巧提问改写。很多用户不会直接问到点子上而是带着聊天语气说“那个东西怎么弄来着”。这种问题直接去检索命中率会很低。你可以在 Dify 的机器人应用前加一步先用一次轻量模型调用把用户问题改写为独立的、包含关键词的检索语句再拿改写结果去知识库检索。这一步对命中率的提升非常明显也是我在这套本地私有化机器人里最后加上去的功能。知识库 RAG 搭建到这一步基本已经是一个能持续积累、持续回答你个人资料的可靠助手了。