★ FEATURED ARTICLE 1. 为什么你的 Agent 需要一个真正的知识库做 Agent 开发到第三篇话题终于落到最容易被低估、也最容易翻车的一环知识库。前两篇聊了 Agent 的架构和工具调用很多人搭完一个能跑通 demo 的智能体之后第一反应是“我给它接个知识库吧”然后就把一堆 PDF、Word、网页链接一股脑丢进去结果上线之后发现答非所问、检索不到、引用错乱最后归因成“模型不行”。我踩过这个坑也帮别人排查过不少类似问题结论很明确问题几乎从来不在模型而在知识库这一层没做对。先把概念说清楚。这里说的知识库不是传统意义上那种给人看的 wiki 或者文档站而是给 AI 检索用的结构化资料集合。它的核心使命只有一个当用户问出一个问题时系统能在几百毫秒内从成百上千份资料里精准捞出那几段真正相关的内容喂给大模型作为回答依据。这个“捞”的动作就是 RAG检索增强生成里的 R。捞得准模型就能答得对捞不准再强的模型也只能瞎编。那为什么标题里强调“把散落一地的资料变成 AI 真能查的”因为绝大多数人的资料状态就是“散落一地”微信收藏夹里躺着几十篇公众号文章本地硬盘里堆着项目文档Notion 里有一堆会议纪要还有各种 PDF 报告、Excel 表格、网页剪藏。这些东西对人来说翻一翻还能找到对 AI 来说就是一堆无法直接消化的字节。知识库要做的就是把这堆原始素材经过清洗、切分、向量化、索引之后变成机器可检索的形态。这篇文章适合谁看如果你正在用 Dify、Coze 这类平台搭智能体或者用 Python 自己写 Agent手头有一批资料想让 AI 用起来那这篇就是给你写的。我会从整体设计思路讲到具体实操包括切分策略、向量化选型、检索调优、常见翻车场景尽量把每一步“为什么这么做”讲透。不堆概念只讲能落地的东西。2. 知识库的整体设计与技术选型思路2.1 先搞清楚三种知识库的区别别一上来就选错热词里有个问题问得很好“kg 知识库、rag 知识库和结构知识库区分以及应用场景”。这三个词经常被混着用但它们的底层逻辑完全不同选错了后面全是坑。RAG 知识库是当前 Agent 场景下最主流的方案。它的原理是把文档切成小块每块转成一个向量一串数字存进向量数据库。用户提问时把问题也转成向量然后算相似度找出最接近的几块。优点是搭建快、对资料格式要求低、更新方便缺点是它本质上是“按语义相似度找段落”不理解实体之间的关系遇到需要多跳推理的问题会力不从心。KG 知识库知识图谱走的是另一条路。它把信息抽成“实体—关系—实体”的三元组比如“张三—任职于—某公司”“某产品—属于—某品类”。查询时走的是图遍历能回答“和张三同部门的人都有谁”这种关系型问题。优点是推理能力强、结果可解释缺点是构建成本极高需要做实体抽取、关系抽取、消歧维护起来也麻烦。一般只有对关系推理有强需求的场景才值得上。结构化知识库指的是把资料整理成表格、数据库这种严格结构化的形态查询走 SQL 或精确匹配。它适合数值查询、条件筛选比如“上个月销售额超过十万的产品有哪些”。但它对非结构化文本无能为力。实际项目里我的建议是90% 的场景从 RAG 起步就够了等真的遇到关系推理的瓶颈再考虑引入 KG 做补充。别一上来就追求大而全那是给自己挖坑。下面这张表可以帮你快速判断类型底层原理适合场景搭建成本更新难度RAG 知识库向量相似度检索文档问答、客服、资料查询低低KG 知识库图结构关系推理关系查询、多跳推理高高结构化知识库表格/数据库精确查询数值统计、条件筛选中中2.2 平台方案还是自建方案这是个绕不开的选择热词里还有个高频问题“利用平台构建的智能体与用 Python 构建的智能体有什么不一样”放到知识库这个环节差异特别明显。用 Dify、Coze 这类平台搭知识库好处是开箱即用上传文档、选个切分方式、点一下向量化流水线自动跑完。Dify 的知识库流水线做得相当成熟支持多种分段模式、支持召回测试、支持元数据过滤。对于快速验证想法、中小规模资料平台方案效率极高。但平台方案的天花板也明显切分策略是平台定死的几套模板你没法针对自己的文档类型做深度定制检索参数调整空间有限遇到“dify 知识库排队中”这种问题只能干等数据量大之后成本和性能都受平台限制。自建方案Python 向量库 检索框架灵活度拉满切分逻辑、embedding 模型、检索策略、重排序全部可控但你要自己处理文档解析、并发、增量更新、监控这一整套工程问题。我的实际做法是混合前期用平台快速验证知识库的召回效果确认资料质量和切分策略没问题之后再把核心链路迁到自建方案上做精细调优。这样既不会在验证阶段浪费时间写工程代码也不会在规模化阶段被平台卡脖子。2.3 一条完整的知识库流水线长什么样不管用平台还是自建一条标准的知识库流水线都包含这几个环节顺序不能乱资料采集把散落各处的原始资料收集起来统一格式文档解析从 PDF、Word、网页、图片里抽出纯文本文本清洗去掉页眉页脚、乱码、重复内容文本切分把长文档切成适合检索的小块向量化把每个小块转成向量索引存储存进向量数据库建立索引检索召回用户提问时找出相关块重排序对召回结果做二次精排上下文组装把精选内容拼进 prompt 喂给模型这九步里第 4 步切分和第 8 步重排序是决定成败的关键也是最多人偷懒的地方。后面我会重点展开。先记住一个原则知识库的质量取决于流水线上最弱的那一环而不是最强的那一环。3. 核心细节解析切分、向量化与检索的实操要点3.1 文本切分决定召回质量的第一道关卡切分这件事看起来简单实际上是最考验功力的地方。切得太碎每块信息不完整模型拿到半句话没法回答切得太粗一块里混了好几个主题检索时噪声大。先说切分粒度。业界常见的默认值是 500 到 1000 个 token 一块块之间留 10% 到 20% 的重叠overlap。这个重叠很关键它的作用是防止一个完整的语义被硬生生切断在边界上。比如一句话正好跨在两块之间有了重叠两块里都能看到完整句子。但默认值不是万能药。我处理过一批技术文档按 800 token 切结果每个代码示例都被切得七零八落。后来改成按结构切分优先按标题层级切遇到代码块、表格这种原子性内容就整块保留不强行按字数切。效果立刻不一样。所以切分策略一定要跟着文档结构走而不是无脑按字数。具体来说我常用的切分优先级是这样的第一优先按文档的自然结构标题、章节、段落切第二优先按语义边界句子结束、段落结束切最后才考虑按固定字数硬切对于 Markdown 文档可以直接用标题层级做切分对于 PDF先解析出段落结构再切对于网页文章先去掉导航栏和广告再按正文段落切。注意切分时一定要保留元数据比如这块内容来自哪个文档、哪个章节、第几页。后面检索到内容时这些元数据能帮你做过滤也能在回答里给出引用来源用户信任度会高很多。还有个容易被忽略的点表格和图片怎么处理。热词里有人问“rag 知识库能存储图片嘛”“知识库图片怎么处理”。答案是纯 RAG 存的是文本向量图片本身存不进去但你可以用多模态模型把图片转成文字描述再把描述文本存进知识库。表格同理要么转成 Markdown 表格文本要么用模型总结成自然语言描述。这一步做不做直接决定了你的知识库能不能覆盖图表类资料。3.2 向量化模型选型不是越贵越好向量化就是把文本转成向量的过程用的模型叫 embedding 模型。选型时主要看三个维度语义表达能力、维度、成本。语义表达能力决定了它能不能把意思相近但用词不同的文本映射到相近的向量上。比如“如何退货”和“退款流程是什么”好的 embedding 模型能让这两个向量很接近差的模型就做不到。维度方面常见的有 768 维、1024 维、1536 维。维度越高表达能力通常越强但存储和计算成本也越高。对于大多数中文场景1024 维左右已经够用没必要盲目追求高维。成本这块要算清楚。假设你有 10 万块文本每块 500 token用某个 embedding 模型输入价格是每百万 token 多少钱算下来一次性向量化要花多少后续每次新增资料还要再花。这笔账在选型时就要算明白别等账单出来才后悔。我的经验是中文场景优先选对中文优化过的模型别直接用英文模型硬套。另外embedding 模型一旦选定整个知识库必须统一用同一个模型因为不同模型产出的向量空间不兼容混用会导致检索结果完全错乱。这一点在增量更新时特别容易踩坑换模型就意味着全量重新向量化。3.3 检索策略从“能查到”到“查得准”检索环节是知识库的临门一脚。最基础的检索是向量相似度检索算问题和每块内容的余弦相似度取 top-k。但只用这一招效果往往不够。问题出在向量检索擅长捕捉语义相似但对关键词精确匹配不敏感。比如用户问一个产品型号“X200-Pro”向量检索可能给你返回一堆讲其他型号的内容因为它们语义上都是“产品介绍”。这时候就需要混合检索向量检索 关键词检索BM25两路结果融合。这样既能抓住语义又能命中精确词。再往上一步是重排序。向量检索召回的 top-20 里真正相关的可能只有前 5 个后面的都是噪声。重排序模型rerank会对这 20 个结果做一次精细打分把最相关的排到最前面。这一步能显著提升最终喂给模型的上下文质量代价是增加一点延迟。我的实测是加了重排序之后回答准确率能提升 20% 到 30%非常值得。还有个技巧是元数据过滤。如果你的知识库里有多个来源、多个时间段的资料检索时可以先用元数据缩小范围。比如用户问的是“最新政策”那就只检索最近半年的文档。这样能大幅减少噪声。检索策略优点缺点适用场景纯向量检索语义理解好、搭建简单关键词不敏感通用问答混合检索语义关键词双保险需要调权重含专有名词的场景向量重排序精度最高延迟略高对准确率要求高元数据过滤减少噪声依赖元数据质量多来源多时段资料4. 完整实操流程从零搭一个能用的知识库4.1 资料采集与统一把散落的东西收拢第一步是把资料收集起来。这一步听起来琐碎但决定了后面所有环节的上限。我见过太多人跳过这步直接拿一堆格式混乱的文件去向量化结果检索效果一塌糊涂。采集时要注意几点。微信公众号文章是很多人的痛点热词里也有人问“如何把微信公众号看到文章保存到知识库”。我的做法是看到好文章先存到本地或笔记工具比如 Obsidian统一转成 Markdown 格式。Obsidian 的好处是本地存储、纯文本、方便批量处理配合一些插件还能自动抓取网页内容。热词里提到的“obsidian 和 trae 搭建知识库”就是这个思路用 Obsidian 做资料中转站再批量导入知识库。格式统一是采集阶段的核心目标。理想状态下所有资料最终都转成 Markdown 或纯文本。PDF 用解析工具抽文本Word 转 Markdown网页去广告留正文Excel 表格转成 Markdown 表格或自然语言描述。这一步做完后面的解析和切分会顺畅很多。提示采集阶段就要建立命名规范和目录结构。比如按“来源_主题_日期”命名按业务模块分目录。这些信息后面会变成元数据检索时能派上大用场。4.2 文档解析与清洗把噪声去掉解析环节的坑主要来自 PDF。扫描版 PDF 需要 OCR文字版 PDF 直接抽文本但抽出来的文本经常带着页眉页脚、页码、断行。清洗时要处理这些去掉重复出现的页眉页脚通常每页都一样可以统计词频识别合并被硬换行切断的句子去掉乱码和特殊符号统一全角半角、中英文标点网页内容清洗的重点是正文提取。网页里混着导航、广告、评论区直接抽全文会引入大量噪声。可以用正文提取算法比如基于文本密度的算法把主体内容识别出来。这一步做完你会得到一批干净的纯文本。别小看这个清洗过程它直接决定了后面切分的质量。脏数据进去脏结果出来这是铁律。4.3 切分与向量化的具体参数假设我们用 Python 自建切分这块可以用 LangChain 的文本分割器或者自己写。核心参数就三个chunk_size、chunk_overlap、分隔符。我的常用配置是chunk_size 设 600 到 800 tokenchunk_overlap 设 100 到 150 token分隔符优先用段落分隔\n\n其次句子分隔。、、最后才用字符硬切。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size700, chunk_overlap120, separators[\n\n, \n, 。, , , , , , ], length_functionlen, ) chunks splitter.split_text(document_text)这段代码的逻辑是先尝试用\n\n段落切如果切出来的块还是超过 700就用\n切再不行就用句号切逐级降级保证每块尽量在语义边界上断开。chunk_overlap120保证相邻块有重叠避免语义被切断。向量化时把每个 chunk 送进 embedding 模型拿到向量后连同原文和元数据一起存进向量库。元数据至少包含来源文档、章节标题、chunk 序号、原始位置。4.4 检索与上下文组装的完整链路检索时用户问题先过一遍同样的 embedding 模型拿到问题向量然后在向量库里做相似度搜索取 top-20。接着用重排序模型对这 20 个结果精排取 top-5。最后把这 5 块内容拼成上下文加上系统提示词一起喂给大模型。系统提示词里要明确告诉模型只根据提供的上下文回答上下文里没有的信息就说不知道不要编造。这一句能挡掉大量幻觉。上下文组装时每块内容前面加上来源标注比如“【来源XX文档 第3章】”这样模型回答时能引用来源用户也能追溯。如果知识库内容多还要注意上下文长度限制别把 5 大块内容全塞进去导致超长。一般控制在模型上下文窗口的 60% 以内比较稳妥。5. 常见问题与排查技巧实录5.1 检索不到内容问题出在哪这是最高频的问题。排查顺序我一般是这样先看切分。如果一块内容被切得太碎关键信息散落在多块里检索时可能每块都只匹配到一部分反而不如一块完整的得分高。解决办法是调整 chunk_size 和 overlap。再看 embedding 模型。如果模型对中文支持不好语义相近的文本向量距离可能很远。换个中文优化的模型试试。然后看检索策略。纯向量检索对专有名词不敏感加个关键词检索做混合往往能救回来。最后看数据本身。有时候是资料里根本没有这个信息那检索不到是正常的该补充资料就补充。5.2 回答里出现幻觉怎么压制幻觉的根源通常是检索到的上下文里没有答案但模型还是硬答。压制手段有几个层次第一层提示词约束。明确要求“只根据上下文回答没有就说不知道”。这能挡掉一部分。第二层提高检索质量。如果检索到的内容本身就相关模型编造的概率会低很多。加重排序、调 top-k 都有帮助。第三层设置相似度阈值。如果检索结果里最高相似度都低于某个阈值比如 0.6说明知识库里可能真没有相关内容这时候直接返回“未找到相关信息”而不是硬塞给模型。第四层要求模型标注引用。让模型在回答里标明每句话来自哪块上下文这样你能快速发现哪些是编的。5.3 知识库更新与增量维护知识库不是建完就一劳永逸的。资料会更新旧内容会过时。增量更新时要注意新增资料走一遍完整流水线向量化后追加到库里修改过的资料要先删掉旧的向量再插入新的否则会出现新旧内容同时被检索到定期做一次全量重建清理掉长期没人检索到的死数据注意增量更新时embedding 模型必须和建库时保持一致。如果中途换了模型新旧向量不在同一空间检索会彻底乱套只能全量重建。5.4 常见问题速查表问题现象可能原因排查方向解决手段检索不到相关内容切分过碎/模型不匹配检查 chunk 大小和 embedding 模型调整切分、换模型回答出现幻觉上下文无答案/阈值过低检查检索结果相关性加提示词约束、设阈值检索结果不相关纯向量检索关键词不敏感检查是否含专有名词加混合检索、重排序更新后检索混乱新旧向量混用检查是否换过模型全量重建图片表格内容查不到未做多模态转换检查资料类型转文字描述再入库6. 几个我踩过的坑和独家心得先说一个最容易被忽略的点知识库的效果评估。很多人建完知识库就直接上线从来不测。我的做法是准备一批“问题—标准答案”的测试集每次调整切分或检索参数后跑一遍测试集看召回率和准确率的变化。没有量化评估调优就是盲人摸象。第二个心得是别追求一次到位。知识库是个迭代的东西先跑通最小可用版本上线收集真实用户的提问看看哪些问题答不好再针对性优化。我见过太多人花两周时间精雕细琢切分策略结果上线发现用户根本不问那些问题。第三个坑是元数据的重要性被低估。一开始我觉得元数据可有可无后来发现当知识库有几百份文档时没有元数据过滤检索噪声大到没法用。现在我的每个 chunk 都带来源、章节、日期、类型四个元数据字段检索时能灵活过滤。最后分享一个关于多 AI 协作场景下的知识库设计思路。热词里提到“多 ai 协作”当多个 Agent 共享一个知识库时要注意权限隔离。不同 Agent 能访问的资料范围可能不同这时候元数据里的“权限标签”就派上用场了检索时按标签过滤保证每个 Agent 只看到自己该看的内容。知识库这层做扎实了Agent 的上限才会高。模型能力是天花板知识库质量是地板地板没铺好天花板再高也够不着。
阅读完成 · 觉得有帮助？
