前两天有个做电商的朋友跟我吐槽“我花大几千买的 AI 工具问我们自己店铺的退货规则它居然给我编了一个 30 天无理由退换我们明明是 7 天。”这个场景我估计每个拿大模型干活的人都遇过。多数人第一反应是模型太蠢其实更准确的解释是不是模型不行是你还没给它递资料。模型脑袋里装的是全网公开知识你公司、你业务、你笔记里的私有资料它一个字都没见过。Agent 智能体被大家寄予厚望的“会查、会用、会执行”其中第一步“会查”靠的就是知识库这根拐杖。知识库Knowledge Base在 Agent 体系里说白了就是一本随取随用的参考手册。它把散落在文档、PDF、表格、公众号文章里的信息切成 AI 能理解的片段存成一个可检索的索引等用户提问时再把最相关的片段捞出来喂给模型做“开卷作答”。这篇是“如何用 Agent”系列的第三篇我把知识库的底层逻辑、落地步骤、参数调优经验以及我实际踩过的坑一次讲清楚。不管是想给团队搭一个带私有资料的问询机器人还是把自己 Obsidian / Trae 里的笔记变成一个能对话的知识库甚至只是想让 AI 别再张口胡说这篇都值得看完。1. Agent 为什么离不开“知识库”这个外挂1.1 先承认一个事实大模型本身是个“没装资料的实习生”我在不同场合反复讲过这个比喻大模型像是一个知识面极广、表达极流利的实习员工但你入职第一天没给它任何公司文档。它知道“一般电商平台的退货规则大致是什么”但它不知道“你的公司退货规则具体是什么”。你问它某个政策条文它只能凭概率去猜一个“听上去合理”的答案。这背后是大模型的工作原理决定的。模型在训练时学到的是一套语言的概率分布而不是在脑子里建立了一个可以随时精确调取的公司数据库。它的知识截止到训练数据那一天而且对私有文档完全无感。所以当你问“我们公司 2024 年 Q3 的 KPI 怎么算”的时候它连“我们公司”四个字指代的对象都无法确定更别说给出正确答案。幻觉问题也因此而来。模型在不知道答案的时候并不会像人一样说“不确定”它更倾向于按概率生成一个“语法正确、结构合理但事实错误”的答案。这也是为什么让 AI 直接回答公司制度、产品参数、历史项目记录这类问题时经常出现“一本正经的胡说八道”。你需要的不是一个表达能力更强的实习生而是先给它一套可以查阅的资料库。1.2 知识库不能“治愈”幻觉但能大幅降低幻觉很多人对知识库抱有一个误解只要上传了文档模型就不会再胡说八道。这个期待一定要纠正。知识库不能百分百治好幻觉但能大幅降低它的概率。原因很简单知识库给模型提供了“证据锚点”。当模型生成回答时知识库检索出来的片段会被拼进提示词里相当于给模型递了一沓带着出处的小抄。有了这些小抄模型更倾向于引用其中的内容来组织回答而不是凭空编造。如果你的提示词里再明确要求“仅基于提供的知识库内容回答”那基本可以压制掉一大半无根据的生成。我在实际项目里测过一个很典型的例子同一个 Agent不加知识库时问“公司年假政策”它会编出“工作满一年享 5 天年假”这种通用说法加上知识库后它规规矩矩地回答“工作满一年享受公司额外福利假 3 天随法定年假一并发放”。注意知识库本身并不会改变模型的推理能力它改变的是模型作答时的信息基础。1.3 为什么 Agent 场景里知识库是刚需而不是选配如果你只是拿大模型做闲聊那确实不需要知识库。但 Agent 的核心特征是“多步任务 工具调用 持续性会话”这三个特征都指向同一个需求在每一轮对话中模型都需要相关上下文来做出正确决策。先说多步任务。假设你让 Agent“整理上季度所有客户反馈并生成报告”它需要先检索客户数据、再分析问题分类、然后生成表格。这个过程中知识库负责提供每一步需要的背景信息比如客户分级规则、历史处理记录、报告模板要求。再说持久化。多轮对话里Agent 需要记住刚才聊到哪了。聊到“退货政策”就必须准确知道是“7 天无理由”而不是“30 天”聊到“库存盘点”就必须准确引用仓库编号。知识库在这时扮演的就是“可检索的长期记忆”而不是把每轮对话塞进上下文窗口里硬扛。工具调用就更明显了。Agent 调用 API、查询数据库、操作飞书/钉钉之前必须知道“哪个接口对应什么功能”。这些接口文档、权限说明、字段定义全是知识库的典型内容。可以说没有知识库的 Agent 就是裸奔有了知识库才算真正“武装”起来。2. RAG 原理拆解知识库是怎么做到“AI 真能查”的2.1 切分把一部长篇文档变成一页页“便签”知识库背后的主流技术是 RAG检索增强生成这个词现在已经不新鲜了但很多人用它的时候并不理解它内部的三个关键环节。第一个环节就是切分英文叫 Chunking。为什么要切分因为大模型的上下文窗口有限而且把一整本书丢给模型它反而不容易定位到具体细节。打个比方你让一个助理去库房找“去年 6 月的某条采购记录”如果他面对的是整箱未整理的票据他只能乱翻如果票据已经按月份、按品类分好了他几步就能找到。切分的目的就是给资料建立“结构化的取用单元”。切分方式大致有三种按固定长度硬切、按标题章节切、按语义段落切。固定长度最简单但容易在句子中间断开导致语义破碎按标题结构切适合文档本身层级分明的场景按语义段落切最理想但实现成本也最高。实际项目中Dify 这类平台通常会提供一个可配置的分段长度选项默认值从 500 token 左右起步。我的经验是知识密度高的文档比如规章制度、操作手册用偏小的分段200 到 300 token 比较合适而需要展示连贯逻辑的内容比如企业文化文章、项目复盘可以放大到 500 token同时开启“分段重叠”选项让前后两段保留少量重合信息避免关键内容刚好被切在边界上。2.2 Embedding把文字变成一串“语义坐标”切分只是第一步接下来要做的是向量化也叫 Embedding。简单来说Embedding 就是把一段文字转换成一串数字组成的向量这个向量能在多维空间里表示文字的语义位置。还是用生活类比你给每段文字发一个 GPS 坐标语义相近的文字坐标距离近语义不相关的文字坐标距离远。“苹果可以吃”和“水果能入口”虽然用词完全不一样但它们的向量距离很近“苹果可以吃”和“苹果手机是电子产品”虽然都包含“苹果”但向量距离就远得多。传统的关键词搜索做不到这一点它只能匹配字面相同的词而向量检索可以做到“按意思找”。embedding 模型的质量直接决定知识库的检索效果。我在 Dify 里常用的是 BGE-M3 这类开源模型中文场景表现稳定支持 1W 字长的文本向量化如果用 OpenAI 那边的接口text-embedding-3-small 也够用。如果坚持数据不出内网Ollama 可以本地跑 bge-m3 或 nomic-embed-text效果略逊于 API 版但胜在私密。这里有个很多人不知道的细节同一个知识库的向量化模型一旦选定最好不要随意更换。因为不同模型产生的向量分布不一样换了模型之后原有的索引和新的 query 向量可能不匹配导致召回效果断崖式下降。我在项目里吃过这个亏后面会在排查部分专门说。2.3 检索与注入只把“最相关的几页纸”递给模型切分和向量化做完知识库的构建阶段就完成了接下来是使用阶段。用户提问时系统会先把问题也做一次向量化得到一个查询向量然后去向量数据库里做相似度搜索找出与问题最相近的若干个片段最后把这些片段拼进模型提示词里。这里涉及两个关键参数召回数量和相似度阈值。召回数量通常叫 top_k决定了最多捞多少个片段出来相似度阈值决定了低于多少分的片段直接弃用。这两个值需要配合调优top_k 太大会把不太相关的内容也塞进来干扰模型判断top_k 太小又可能漏掉关键信息。相似度阈值设太高经常召回为空设太低噪声太多。我常用的实践经验是top_k 先设为 3 到 5相似度阈值先设 0.2 到 0.3然后拿一批真实问题去测试。如果答非所问先把阈值调低看召回是否为空如果出现了明显不相关内容再把阈值往上调或者缩小 top_k。要理解这一步的逻辑RAG 的答案质量天花板由“检索到的片段质量”决定模型再聪明喂进去的都是垃圾它也给你产不出花来。3. 实操把散落资料变成 Agent 知识库的完整流程3.1 工具选型Dify、豆包、Ollama 和 Trae 到底怎么选我在聊知识库落地时被问最多的一个问题是“到底用什么工具”。市面上的选择很多但它们解决的不是同一个问题我先把边界划清楚。Dify 是目前最适合“团队级知识库 Agent 编排”的开源平台。它的知识库功能相当成熟支持同步 Notion、网页、本地文件有可视化分段配置还内置了召回测试工具。缺点是要部署服务器配置不能太寒酸至少要有 4G 以上内存跑得才舒服。豆包扣子/Coze更适合快速验证和个人玩票。你不需要部署任何东西上传文件就能建知识库平台还内置了 Agent 工作流、插件、触发器做一个小应用非常快。缺点是平台数据隔离能力弱关键业务数据放上去心里没底而且导出和迁移很不方便。Ollama 本地 RAG 是“零成本 数据不出本地”的代表方案。你可以在本地跑 embedding 模型和向量库比如 Chroma、Milvus配合 LangChain 或者 LlamaIndex 写一套流水线。这个方式的优点是完全可控缺点是一旦出了问题需要自己动手查日志。适合开发者玩不适合业务同学直接上手。Trae 和 Obsidian 属于“个人知识管理”路线。Obsidian 加一个 Copilot 插件可以把你本地笔记当作知识库来对话Trae 则是集合了 IDE 和 AI 能力的工具。如果你只是想让自己积累的笔记可以被 AI 查询这类工具最轻量。我的建议个人用笔记先上 Obsidian想快速验证知识库效果用豆包给团队做正经应用直接上 Dify有严格数据隐私要求再研究 Ollama 本地方案。别一开始就上重武器。3.2 五步落地从上传文档到 Agent 开始回答不管选哪个平台知识库的落地流程高度相似这里以 Dify 为例给一套可以直接抄的流程。第一步准备文档。这是最容易被忽略的环节。上传之前先检查格式优先用 Markdown、Docx、纯文本这类工具友好格式PDF 要看是不是扫描版是扫描版的话必须先 OCR表格尽量转成 CSV 或 Markdown 表格文档里如果夹杂大量广告、页眉页脚、导航文字先手动清掉。这一步做到位后面能少踩 80% 的坑。第二步新建知识库。Dify 里点“知识库”-“创建知识库”选择上传文件或直接同步在线数据源比如 Notion 页面、网页链接。上传后系统会自动识别文本内容。第三步配置分段规则。在 Dify 的分段设置界面里可以选择“自动分段”或“自定义分段”。自动分段通常按段落和标题切适合结构清晰的文档自定义分段则允许你手动设定分段长度和重叠长度。我的常用配置是分段长度 400 token重叠长度 50 token这个组合在大多数文档上表现平衡。第四步选择 Embedding 模型和索引方式。这一页上的选项看起来很专业但不复杂。Embedding 模型选一个中文支持好的即可索引方式选“高质量”走向量索引而不是“经济”走关键词索引。经济模式便宜但搜索质量差很多生产环境不要省这个钱。第五步关联到 Agent 应用。在 Dify 创建 Agent 应用时左侧工具列表或上下文选项中把知识库勾上然后设定触发方式。Dify 的 Agent 默认会在用户提问时需要相关信息时自动检索知识库你也可以在提示词里强制规定“先检索知识库再回答”。保存之后一个能查私有资料的 Agent 就上线了。3.3 关键参数速查表与几个容易忽略的细节我把常用的参数整理成了一张速查表方便你对照调整都是我从项目里总结出来的常见取值。参数含义常见取值备注chunk_size分段长度200-500 token文档知识密度越高取值越小chunk_overlap分段重叠20-80 token防止关键信息断在边界top_k召回片段数3-5太少漏信息太多引噪声similarity_threshold相似度阈值0.2-0.4Dify 里默认较高需按实测调整embedding 模型向量化模型bge-m3 / text-embedding-3选定后不要随意更换索引模式向量索引高质量经济模式仅适合数据量极小场景还有一个细节容易被忽略Dify 默认的相似度阈值可能偏高导致很多真实合法的内容被过滤掉。我碰到过一次明明文档里有对应内容检索结果却经常为空。排查很久发现是分数卡太严了。可以先跑一批真实问题看系统实际返回的相似度分数分布再决定阈值设多少而不是盲信默认值。4. 图片、表格、公众号文章三类“难搞”资料的处理方案4.1 图片到底能不能进知识库能但进的不是图片本身很多人问“RAG 知识库能存储图片吗”这其实是对技术边界的一个常见误解。标准的 RAG 流程处理的是文本不是像素。当你把一个带图片的 PDF 传进知识库时系统通常只能读取其中的文字层图片要么被忽略要么被降级成无法检索的附件。那么图片资料是不是就完全没救了不是有三条路可以走。第一条用多模态模型比如 GPT-4o、Qwen-VL做“图像转描述”把图片内容翻译成文字后入库。比如一张设备故障截图可以让多模态模型生成“界面显示错误码 4023底部按钮灰色不可点击”然后把这句描述入库。第二条用 OCR 提取图中的文字适合截图、扫描件、表格扫描图。第三条如果你只想让用户能“看到”图片而不是让模型“理解”图片可以把图片地址作为元数据放进知识库模型回答时顺带返回图片链接。我实际项目里的做法通常是组合拳先 OCR 提取文字再让多模态模型补充上下文描述最后把文字和图片路径一起入库。这样既保留了可检索的文字又保留了可展示的原图。4.2 PDF 和表格最容易翻车的两类文件PDF 是知识库领域的老大难。你看到一个 PDF得先判断它是“文本型 PDF”还是“扫描型 PDF”。文本型 PDF 可以直接提取文字扫描型 PDF 本质是图片必须先 OCR。判断方法很简单用 PDF 阅读器打开如果可以直接选中文字就是文本型如果选中的是一片区域块就是扫描型。表格比普通文本更棘手。一个带 20 列数据的 Excel 表格如果直接转成纯文本入库模型很难理解哪一列对应什么含义。我建议的做法是把表格转成 Markdown 格式再上传让每一列、每一行保持在结构化状态。转换工具有不少比如 Excel 里另存为 CSV再用脚本转成 Markdown或者直接用 Pandas 处理。Dify 和多数平台都支持 Markdown结构化表格入库后的检索准确率会明显提升。还有一类“重灾区”是双栏排版、带复杂页眉页脚的 PDF。这类文件即使能提取文字顺序也会乱掉。我的经验是先用在线转 Markdown 工具做一次预处理把正文顺序理顺后再入库。预处理这一步虽然花时间但值得因为乱序文本入库后基本等于废数据。4.3 公众号文章和网页内容怎么快捷入库公众号文章是我看到最普遍的“散落资料”形态。公众号后台不提供标准导出接口复制粘贴又常常丢图。我的工作流是这样的先在手机或电脑上打开文章用浏览器剪藏插件比如 Obsidian Web Clipper把正文和图片抓下来存成 Markdown文件命名规则用“日期 公众号名 文章标题”然后统一放进一个待入库文件夹定期批量上传到 Dify 或本地知识库。网页内容有一个更偷懒的技巧很多平台的“网页转 Markdown”接口可以直接把 URL 转换成干净的 Markdown 文本。把转换结果存下来再上传省去了手动清理广告和导航栏的时间。需要注意的是这种方式只适合公开内容涉及版权的资料不要外传存到本地自用即可。批量入库还有一个好处你可以给每篇文章补充自定义字段比如来源、作者、标签。这些元数据之后可以成为检索过滤的条件比如只查“某公众号关于 AI 的文章”效果比全库模糊搜索好得多。5. 常见问题与排查技巧实录5.1 检索不到资料先查阈值再查切分最后查 embedding“知识库里明明有内容但 Agent 就是答不上来”是我被问得最多的问题。排查顺序非常重要我建议按下面的路径走。第一先看相似度阈值是不是太高。在 Dify 的“召回测试”里输入问题直接看系统返回地片段和分数。如果分数普遍在 0.1 到 0.2 之间而阈值设的是 0.4那结果当然是空。把阈值降下来问题立刻解决。第二看切分是否合理。如果你把一份 20 页的产品手册切成 500 个固定 token 的小块检索时可能只召回某一块碎片而真正的答案被切散在两块之间。这时改用按标题结构分段或者在关键文档上手动调整分段边界会显著改善。第三检查 embedding 模型是否前后不一致。我踩过这个坑知识库已经用模型 A 向量化了后来换成了模型 B结果所有检索分数跌到接近 0。这不是数据坏了是两个模型的向量空间不对齐。解决方式只有一个重建知识库索引。所以选模型前一定想清楚别中途乱换。5.2 检索到了但答案不对问题往往出在提示词和上下文有时候召回片段是准的分数也不低但模型回答还是不对。这种“看起来查到了却没用上”的情况常见原因有三个。第一个原因是提示词没有强制模型使用知识库。很多 Agent 默认的提示词是“利用你的知识回答”模型当然优先用自己脑袋里的旧知识。正确的做法是在系统提示词里写明“优先基于提供的知识库内容回答如果知识库中没有对应信息明确告知用户不要自行编造”。这一句话能解决一半的答非所问。第二个原因是上下文被截断。当知识库召回 5 个片段、每个片段 400 token加上历史对话和工具调用结果很容易超出模型的上下文限制。超长之后前面高价值的片段可能被截掉。对策是减小 top_k或者精简提示词给召回片段留出更多空间。第三个原因是多个知识库内容互相冲突。团队里“制度库”和“项目库”里对同一个问题的描述不一致时模型会很为难。我在项目里会建议每个知识库设定范围边界并在提示词里说明“制度问题只查制度库”减少冲突。5.3 知识库更新了Agent 却还在答旧内容这个问题的排查点主要集中在索引和缓存。上传新文档后Dify 等平台需要重新切分和向量化如果文档仍然显示“排队中”或“处理中”说明新内容还没进入可检索状态。此时点击“重新索引”或等任务完成再测试是常规操作。另一个隐蔽原因是应用层缓存。有些 Agent 应用为了提速会把一段时间内相同问题的回答缓存起来。热门问题的答案在更新后可能不会立即变化。这时清一下缓存或者换个问法测试基本能定位。5.4 并发扛不住知识库场景的性能瓶颈在哪里有人问“AI Agent 怎么扛并发”知识库场景里这个问题更具体。实际的瓶颈通常不在知识库本身而在两个地方一是向量检索的速度二是大模型推理的吞吐。知识库检索本身非常快十万级片段的向量库单次检索毫秒级就能完成真正慢的是给模型推理留的时间。要扛并发几个思路可以参考第一给知识库加前置缓存层把高频问题的检索结果缓存住减少重复向量查询第二对 LLM 的生成做异步队列化处理避免请求同时打爆底层模型第三如果业务量真的很大升级向量库比如用 Milvus 这类分布式方案并做分片。多数中小场景其实用不上最后一步前面两个优化足以撑住常规流量。最后说几句经验把这个系列写到第三篇我最大的体会是知识库不是一个“上传完就结束”的功能它是一个需要持续维护的基础设施。我个人的笔记知识库现有 200 多篇文档每隔两周我会做一次内容清理把过时笔记标记归档、把新文章按时入库、把重复内容合并。每次维护完检索质量都会有肉眼可见的提升。资料库和菜园子一样不除草、不浇水再好的种子也长不出好菜。最后再分享一个调试技巧任何 Agent 应用上线前先做一轮“召回测试”。把用户在聊天里可能问的问题列 20 到 30 条逐一检查系统召回出来的片段是不是正确的。这个测试能帮你发现绝大多数问题而且 80% 的问题一眼就能定位——要么是阈值不合理要么是切分太粗要么是提示词没写好。花上一个下午把这个测试跑完抵得上上线后一个月的反复调优。