1. 为什么编排智能体时知识获取比推理能力更难1.1 大模型的知识边界决定了智能体的能力天花板先说一个我这段时间反复体会到的点很多人搭智能体一上来就盯着模型选型、提示词打磨、工具调用流程设计觉得只要推理链路顺了智能体就聪明了。但真正把智能体推到业务场景里才发现卡住它的往往不是想不想得到而是知不知道。模型在训练时学到的那点世界知识是固定的训练截止日期之后发生的事情它一概不知。你自己的业务文档、私有数据库、内部流程规范它更是从来没看过。这种情况下你问它任何一个稍微具体的问题它要么一本正经地编要么客客气气地说不知道。编出来的东西在演示环境里还能糊弄过去一旦放进真实业务一个错误引用就可能引发连锁问题。我在前几篇里聊过 Agent 的规划、工具使用、记忆设计但一直没详细展开知识这一层。这一篇专门补上AI Agent 的知识获取管道也就是 RAG 基础。RAG 全称是 Retrieval-Augmented Generation检索增强生成通俗讲就是先让模型去一个外部知识库里捞相关片段再把这些片段连同问题一起交给模型去组织回答。这样模型既不需要记住你的全部文档也能在你指定的资料范围内做事实性回答。1.2 为什么说是管道而不是插件很多第一次接触 RAG 的人直觉上把它理解成一个把文档塞给模型的过程。实际上它是一条完整的处理链路原始文档清洗 → 文本切分 → 向量化 → 索引存储 → 查询召回 → 上下文组装 → 生成回答。任何一个环节做得粗糙最终效果都会打折而且越靠前的环节出了问题越难在后面找补。打个比方RAG 管道就像给一个外聘专家配一个实习助理。专家本人能力很强但对你公司的内部情况一无所知。助理的工作就是提前把档案室里的资料整理成带编号的卡片按主题分好类专家提问的时候助理先跑过去把相关的几张卡片翻出来放在专家面前。专家对着卡片作答而不是凭自己脑子里那点行业常识瞎猜。这个助理干得好不好直接决定了专家答得准不准——哪怕专家本身是顶级的。1.3 先把RAG 能干什么、不能干什么想清楚在动手搭管道之前我建议你花十分钟想清楚预期。RAG 解决的是模型不知道但知识库里有的问题。它不能解决知识库里压根没有的问题也不能凭知识库生成超出资料范围的结论。它还怕一种情况检索到的内容本身就彼此矛盾。这时模型依然可能挑一条看起来更像那么回事的然后以非常自信的语气说出来。所以这一篇的所有内容都建立在同一个认识上RAG 的目标是提高知识获取的成功率而不是保证 100% 正确。我们后面聊的所有优化手段都是围绕这个目标来的——尽量在检索环节把命中的概率推高把噪声压下去。2. 从零搭一条最简知识管道文档切分与向量化才是重灾区2.1 源文档清洗脏数据没人帮你兜底先把最无聊但最重要的一件事说了文档清洗。我见过不少团队兴致勃勃地把几百份 PDF、Word、Markdown 一股脑扔进向量数据库跑通 demo 之后兴奋得不行结果一测真实问题返回的片段乱七八糟格式残缺、目录页混进来、表格被切得七零八落。问题不在检索而在源头的解析质量。你用的解析工具要针对文档类型做选择。PDF 建议先用 PyMuPDF 或 pdfplumber 提取文本遇到扫描件再上 OCRWord 文档用 docx 库按段落读取Markdown 或 HTML 反而要小心因为里面的标记符号如果没清理干净会被一起切进块里污染向量。还有一类文档很容易踩坑——很多 PDF 的页眉页脚、页码、目录页在提取时都会变成一段段孤立的文本。这些文本向量化之后几乎没有任何语义信息但照样占据索引位置检索时偶尔还会被莫名其妙地捞上来。我现在的做法是解析之后先跑一轮规则清洗去页眉页脚、去目录页、去重复空行、把中英文标点统一。业务文档多的情况下这个步骤不能省它虽然枯燥但能直接影响后面的命中率。2.2 分块策略块大小、重叠和分隔符要一起调接下来是 RAG 管道里变量最多的一步分块chunking。分块的核心矛盾在于块太小语义上下文不完整块太大噪声多向量化时特征会被稀释召回精度下降。常见的做法是按固定字符数切分比如 500 字符一块。但固定切分有个明显的毛病句子或段落会被拦腰截断语义完整性被破坏。更稳妥的方式是按语义边界切分。先用 Obsidian 或者 LangChain 里的 RecursiveCharacterTextSplitter 这类按分隔符递归切分的工具它会优先从段落边界切其次是句号、换行、长空格最后才兜底按字符数硬切。我建议开发阶段把块大小设在 300 到 800 字之间块与块之间留 50 到 100 字的重叠这样切在文档中间时上一块的结尾能在下一块开头出现避免关键句被分隔符一分为二。但记住一点不同领域的文档最适合的分块参数完全不同。代码类文档要按函数切法律合同要尽量保持条款完整纯叙述的技术博客按段落切就很自然。你最好把分块逻辑做成可配置的然后建一个测试集逐个参数组合跑一遍看哪组的效果稳定。这不是一份努力一分收获的问题是九分调整一分收获。2.3 Embedding 选型模型、维度与部署方式的取舍分块完成后每一块文本要变成向量。选 Embedding 模型本质上是在找一个能把语义相近映射成向量距离相近的映射。这里有个很容易忽视的点Embedding 模型的分词器和语义理解能力直接决定你对中文长文本的支持效果。现在国内可用的大语言模型生态里有不少国产 Embedding 模型做得相当不错比如 BGE 系列对中文支持很好而且开源可商用。如果你的文本是英文为主OpenAI 的 text-embedding-3 之类也够用。但无论选哪个我都建议设统一维度比如 1024 或 1536方便后面切换模型时不用重构整个向量库。部署方式上小规模项目直接调 API 就行省心数据量大了或者有私密性要求就本地部署一个 Embedding 服务。实测下来本地部署 bge-large-zh 在一台普通 GPU 机器上处理几百份文档基本无压力。别着急在 Embedding 模型上追求最强能力先把管道跑通再看检索质量决定要不要换。3. 检索端才是决定 RAG 上限的地方3.1 向量数据库选型从轻量到重型先别过度设计很多人一听到向量数据库第一反应就上 Milvus 或者 Elasticsearch 的向量插件觉得这才叫专业。但对一个刚开始搭建的 Agent 项目来说这属于过度设计。你的起步阶段数据量可能就几千个块一个 FAISS 本地索引就够用了甚至用 Chroma 或者轻量级的向量文件都能跑得很顺。我给你的建议是分阶段选型阶段推荐方案理由原型验证Chroma / FAISS 本地索引零运维几分钟跑通迭代快小规模上线pgvector在 PostgreSQL 里开向量字段复用已有数据库事务、权限一套带走大规模生产Milvus / Qdrant / Elasticsearch分布式、高并发、可扩展这里有个亲测有效的经验在数据量没到百万级块之前向量数据库选型对效果的影响远小于你对分块和检索策略的调优。别让基建问题分散了你的注意力先把管道逻辑跑对。3.2 相似度计算与 top-k别把召回做成猜谜检索的核心就是一句话找到与问题语义最接近的若干块。常见相似度度量有三种——余弦相似度Cosine、欧式距离L2、内积Inner Product。对文本来说用余弦相似度最直观它只关注方向、不受向量模长影响语义特征能在归一化后趋于稳定。很多向量数据库默认也是用余弦。top-k 的选择也是门道。k 太小比如只取 1那相当于把宝全压在一段文本上一旦这个块切得不够好整轮回答就废了。k 太大比如取 10模型要消化大量噪声生成质量反而下滑。我起步时通常用 top_k4 到 6然后在测试集上回调。另一个容易被忽略的参数是返回的分数阈值——低于某个相似度阈值的片段干脆不返回。这样可以避免用户问一个知识库完全没有的问题时模型矮子里拔将军硬答。3.3 混合检索与重排序提升精度的两板斧纯向量检索的问题在于它理解的相似更多是语义层面的对精确关键词匹配不敏感。举个例子用户问的是服务器的保修截止日期知识库原文写的是3 年质保服务到期时间。向量检索大概率能命中因为语义相近但如果用户问一个非常具体的型号代码R740-XD3而原文恰好只出现过这个型号且没有任何上下文修饰向量检索就可能把它淹没在语义噪声里。实际生产中我建议在向量检索之外再加一个 BM25 关键词检索两边结果合并后再过一轮重排序rerank。BM25 负责把字面命中的文档捞回来向量负责意思相近的文档重排序模型再综合信号把最准确的结果往前提。三者配合命中率提升非常明显。重排序模型的接入很简单向量库端返回候选集之后把候选集文档和用户问题一起送入 rerank 模型比如 BGE-reranker它会给每个候选打一个相关度分数你再按这个分数截断到最终 top-k。这一步对 RAG 质量的提升往往比换一个更大的生成模型还要显著。这个发现是我自己踩了不少坑之后才确认的——之前一直以为模型够聪明就能自己分辨相关片段结果发现模型面对 6 段候选文本时经常被不相关的段落带偏。加了重排序之后问题基本消失。4. 知识管道的出口上下文组装与生成层的细节4.1 检索到什么和模型看到什么是两回事检索环节找到了相关块不代表你就可以把这些块一股脑拼进提示词里。组装上下文是一个独立的细节层做得不好前面再好的检索也可能白费。首先块与块之间的顺序会影响模型的注意力。通常与问题最相关的块要放最前面。这里有个心理学的道理模型跟人很像对序列开头内容的注意力最强。如果不排序直接随机丢进去模型容易被中间夹着的次要内容带偏。其次每段上下文前面最好加一个来源标记比如来源文档[设备运维手册]章节4.2。这样做有两个作用一是让模型知道这些片段来自哪里回答时更倾向引用原文二是方便你在生成结果后面挂引用链接这在很多企业场景里是刚需——用户看到了答案还得能点开原文确认。4.2 Token 预算一个常常被低估的约束条件每组块的 token 长度、模型上下文窗口、最终回答需要占用的输出空间这三者的平衡要认真算一算。假设模型上下文是 8K token输出留 2K那输入侧就只有 6K。如果每块约 300 字大概占 500 token那 top_k 就不能超过 10否则上下文直接溢出。很多框架会自动截断超长的上下文但截断策略很粗暴——从尾部直接砍。如果恰好把最相关的块放在尾部那这轮回答基本就废了。所以我的习惯是先决定输出预算再从后往前排上下文。核心块放最前面越是辅助性的块越靠后宁可牺牲一些辅助块也要保证核心块完整进上下文。如果你是按相关度倒序排列那其实天然就符合这个策略只需要再确认一下总的 token 消耗不要超限。4.3 提示词里的知识段约束怎么写生成层的提示词和普通 ChatGPT 对话的提示词有本质区别。普通对话的提示词目标是规定角色和风格RAG 场景的提示词目标是规约信息的用法。我在提示词里固定加入这样几类约束清晰说明检索片段是唯一的回答来源暂用外挂背景时要不明确承认规定回答要引用原文不得掺入模型自己的预训练知识给出当检索片段不足以回答时的处理方式——可以是你说得对知识库里没有这个信息这种姿态的引导让模型直接说明知识缺失而不是强行拼接要求输出格式上提供来源引用。这几个约束看起来简单但对回答质量的稳定性影响很大。尤其是当信息不足时如何回应这一点很多小白会忽略结果就是知识库明明资料不全模型却在用自己脑补的内容和检索到的片混合编造答案。用了约束之后模型更倾向于诚实地说资料中没有直接提到这个信息这在真实业务里比假装知道要重要得多。5. 从命中率到忠实度把 RAG 性能量出来再优化5.1 盲调是不行的先定义你的评估集RAG 管道有太多环节可以调如果没有一套固定的评估方法你根本不知道改动是变好了还是变差了。我在实际项目中养成的习惯是维护一个 50 到 100 条问答的测试集覆盖各种常见问题、模糊问题、带否定词的问题、找不到对应资料的问题等等。这个测试集不追求数据量追求的是问题的代表性。然后每改一次分块参数、检索策略、提示词就用同一套测试集跑一遍把结果记下来对比。长期对比下来你对哪个环节最敏感就会形成手感而不是抓瞎。5.2 三个关键指标命中率、相关性与忠实度多数人评估 RAG 只看一个指标最后回答对不对。这其实把概念揉成一团了。我更建议拆成三层来看检索命中率Hit Rate知识库中包含答案的文档是否被检索端成功召回。这是检索环节的指标和生成无关。相关性MRR / NDCG命中的结果是否排在候选列表的前列。如果答案排到第 10 位即使被召回了生成环节也可能被前面的噪声带偏。忠实度Faithfulness最终回答是否严格基于检索到的片段有没有引入模型自己的臆测。这三个指标对应管道上不同的环节。命中率低去调分块和检索策略相关性低去调重排序和 top-k 截断忠实度低去调提示词约束和上下文排序。用指标定位问题比拍脑袋改参数高效得多。我强烈建议每个 RAG 项目至少跑一轮这样的评估。很多团队上线了 RAG 却一直觉得效果怪怪的说不出哪里不对其实就是指标没拆开看所有问题都混在一起了。5.3 带反馈的知识管道迭代周期怎么设计单次优化是远远不够的。知识库里会不断补充新文档用户问的问题也会越来越刁钻RAG 管道必须能持续迭代。我的迭代节奏是每周从真实对话日志里抽出那些用户不满意或模型回答明显错误的 case人工标注一次判断问题出在检索还是生成然后针对性地小步调整。这里我特别想强调一个点用户满意度是一个粗糙但是极其有效的信号。如果用户在 Agent 回答后点了踩或者继续追问不对吧这些样本的价值比任何漂亮的离线指标都大。把这些 case 不断反哺评估集你的测试集就会越来越贴合真实使用场景优化方向自然也越来越准。6. 从基础 RAG 到 Agentic RAG知识管道演进的下一站6.1 固定管道 vs 动态决策聊完基础 RAG我觉得有必要提一嘴它和 Agentic RAG 的差别因为这是这两年的热点方向也是我在实践中最看好的演进路径。基础 RAG 是一条固定管道问题来了检索拼上下文生成回答。整个过程是单向的、一次性的。它的局限也很明显——遇到复杂问题一锤子买卖往往捞不全信息。比如用户问帮我对比一下 A 产品和 B 产品在运维成本上的差异这个问题至少需要两轮检索先查 A 的成本构成再查 B 的成本构成可能还需要再查一下两者的共同计价规则。固定管道一次只能捞一组片段很容易丢信息。Agentic RAG 的思路是让模型自己决定检索策略。它可以先根据初步检索结果判断信息够不够不够就二次检索可以拆解问题分别检索再汇总甚至可以在检索过程中发现新关键词用它追搜下一批文档。基础 RAG 像一个只管执行查询的检索员Agentic RAG 像是一个能自己判断还要什么资料、去哪找的研究助理。6.2 我的实践建议先把基础管道打磨透再谈自适应虽然 Agentic RAG 听起来美好但我还是建议你把基础管道打磨透再上。原因很简单Agentic RAG 的每次自适应决策都是基于基础检索质量做的判断。如果基础管道召回质量差Agent 反复检索也捞不回对的文档只会让延迟变高、token 消耗变大用户体感反而更差。我自己目前的实践路线是先把固定管道的命中率调到 80% 以上再在检索模块外面加一层简单路由——先从问题里抽取关键词和问题类型判断是单轮检索可以直接回答还是需要拆成子问题多次检索。这一步不需要很复杂的思路用一个大模型做路由器就行但对复杂问题的覆盖率提升明显。6.3 知识获取几乎是所有智能体的必经之路回顾整个系列前面几篇讲的规划、工具、记忆本质上都是在优化 Agent 的思考方式。但一个智能体要想在真实业务里办成事思考方式之外还必须有一条可靠的知识获取管道。没有这条管道Agent 就是一位能力很强但完全不了解你公司现状的外部顾问聊得热闹落不了地。这一篇里我只聊了 RAG 基础也就是检索一段、拼一段、答一段的骨架。接下来我打算再深入写一篇关于质检与知识保鲜的内容也就是当文档更新、过时、出现矛盾时管道怎么动态调整。反正做成一个能跑起来的智能体知识侧的路还很长。希望这篇基础篇能帮你把第一段路铺稳。