做AI Agent的都知道一个尴尬模型很聪明但对你自己业务里的知识一无所知。公司内部文档、产品规格、项目沉淀这些信息不在训练数据里模型只会一本正经地胡编。我最早做Agent原型时就撞上这堵墙——模型规划得再好落地时连我们公司的登录流程是什么都答不对。后来才想明白Agent缺的不是聪明是一条把外部知识送进推理过程的管道也就是RAGRetrieval-Augmented Generation检索增强生成。这篇是走进AI Agent系列的第四篇专门聊聊这条知识获取管道怎么搭、参数怎么调、坑在哪里适合正在从0到1搭建AI Agent、打算给Agent接知识库的同学。1. 为什么Agent必须拥有一条知识管道1.1 模型的记忆边界与知识时效性先认清一个事实大模型的知识是封存在参数里的训练截止那一刻它的世界就冻结了。你问它今年新发布的某款产品参数它答不上来很正常因为它的记忆里根本没有这笔数据。更麻烦的是即使模型知道某个概念它也不知道这个概念在你公司内部文档里是怎么定义的、流程是怎么走的。拿我实际踩过的坑举例。我曾给一个团队做内部运维Agent模型本身很能打但一涉及这台服务器的变更记录这个接口的负责人是谁这类问题输出就开始放飞。原因很简单这些信息存在于内部工单、部署文档、数据库表里模型的参数池里压根没有。你问它它只能靠推理硬补补出来的东西看着合理实际上是标准幻觉。所以Agent的知识获取不能指望模型天生就知道必须有一条主动去外部拿知识的通道。RAG就是这条通道。1.2 从提问-回答到获取-理解-回答的架构转变大多数人理解RAG把它当成给LLM开卷考试——先把文档喂进去再让模型回答。这个直觉方向没错但落地时的架构含义要深得多。RAG改变的不仅仅是多塞了几段文字而是把Agent的处理链路从一条直线拆成了三段用户问题进来先做一次检索动作去知识库捞相关的资料片段捞出来的片段和原始问题一起组装成PromptLLM在这个受限上下文里生成答案尽量做到说的话有出处。这个转变的本质是把模型靠记忆答题改成系统靠检索答题。对Agent来说它获得了一个能力边界清晰的模块知识不是被塞进模型的脑子而是放在一个可持续更新的外部仓库里。今天文档更新了明天Agent答的就是新内容不用重新训练、不用微调。我后面所有实战经验都是围绕这个获取-理解-回答的链路展开的。2. 知识管道的三段旅程索引、检索与生成2.1 索引阶段把文档变成可搜索的向量仓库RAG的第一段旅程是离线完成的核心任务就一句话把一堆乱七八糟的文档变成机器可搜索的结构化仓库。这个过程里你至少要过三道工序。第一道是加载与清洗。PDF、Word、Markdown、网页各有各的解析门道。纯文本怎么都好说PDF一旦带扫描图片或复杂表格解析质量就直线下降。我常用的做法是先用文档解析工具把内容抽出来再按页或按区块检查有没有乱码、有没有把表格拆得七零八落。清洗这一步关乎后面所有环节的质量但很多人图省事直接跳过最后检索效果差还找不到原因。第二道是切分。文档太长不能整篇扔给向量化模型需要切成固定大小的块。这里有两个关键参数chunk_size每块多长和chunk_overlap相邻块重叠多少。我后面会单独讲切分策略这里先记住一个大原则块太小语义不完整块太大检索粒度太粗噪音多。第三道是向量化与存储。每一块文本过一遍Embedding模型变成一个几百上千维的向量。向量存在向量数据库里同时把原文和元数据也一起存进去。建好这个仓库索引阶段就算完成。2.2 检索阶段从仓库里捞最相关的片段检索阶段是RAG每一轮问答都会走的路用户问题来了先把它用同一个Embedding模型转成向量然后在向量数据库里做最近邻搜索找出跟问题向量最相似的TopK个片段。这里要展开一个初学者最容易忽略的细节Embedding模型必须保证查询和文档用的是同一套。你建索引时用A模型检索时换成B模型两个模型生成的向量空间语义不兼容检索效果直接归零。我见过不止一个人踩这个坑明明是同一个文本检索结果却是八竿子打不着的段落。另外纯向量的最近邻搜索有它的天然短板——对精确词条不敏感。比如用户搜登录流程这种带明确关键词的表达向量检索不一定能把包含登录流程原文的片段排在前面。所以稍正式一点的生产系统都会做混合检索向量检索负责语义相关性BM25这种传统关键词检索负责字面匹配最后用RRFReciprocal Rank Fusion之类的算法把两路结果合并排序。如果你预算有限至少也得保留纯向量检索但心里要清楚它的上限在哪里。2.3 生成阶段把检索结果变成回答的上下文检索完成后系统把TopK个片段按顺序拼进Prompt再附上用户问题和系统指令交给LLM生成最终回答。这个阶段的核心技术含量在于Prompt组装方式不同的组装策略对答案质量影响很大。我常用的组装规则有三条。第一条检索片段里必须带来源标识方便输出答案时引用出处也方便排查这个答案是从哪段知识里来的。第二条在Prompt里明确告诉模型优先使用提供的资料作答资料不足时直接说不知道不要编造这一句能压掉相当一部分幻觉。第三条如果TopK片段中存在互相矛盾的内容比如文档不同版本描述不一致最好在Prompt里提示模型检测到矛盾信息请如实指出而不是让它自作主张选一边。到这RAG的完整链路就闭环了。你可能会问这链路看起来不复杂嘛为什么实际做起来效果总是差强人意问题往往出在细节上下面专门拆。3. 检索质量的决定性因素切分策略与Embedding选型3.1 切分不是随便切chunk_size、overlap怎么定我见过太多RAG效果不好的同学第一反应是换Embedding模型第二反应是换向量数据库折腾一圈发现没用最后归因于RAG这技术不行。实际上最影响检索命中率的往往是看起来最不起眼的切分参数。先列一组我实测过的直观感受chunk_size设200和设800对同一个问题检索出来的片段完全不一样。设小了一块只覆盖几句话语义往往不完整检索出来可能只命中答案的一半设大了一块覆盖好几页跟问题相关的部分淹没在无关信息里向量相似度的信噪比也下降。比较稳妥的起点是512个token左右chunk_overlap在50到100之间保证相邻块之间语义衔接不断裂。切分除了看数值还要看文档结构。我处理技术文档时优先级是结构切分优于纯长度切分。Markdown按标题层级切HTML按标签切代码按函数切这样出来的块天然带有段落语义比硬数长度科学得多。LangChain里的RecursiveCharacterTextSplitter和MarkdownHeaderTextSplitter都是干这个的前者适合没结构的文本后者适合层级分明的文档。再给一个进阶策略Parent Document Retriever。检索时用小块比如256 token去匹配把命中的小块所属的大块比如2000 token整个返回给LLM。这样既保证了匹配精度又给了模型足够的上下文是目前性价比很高的选择。3.2 Embedding模型怎么选开源vs商用、中文场景Embedding模型是RAG的翻译官它决定了语义相似用什么标准度量。选型时主要看三件事语言支持、向量维度、语义粒度。我以中文场景为例。国内用得比较多的是BGE系列、M3E、text2vec这些开源模型其中BGE-M3支持多语言也能输出稀疏向量做混合检索实用性很强。商用接口里OpenAI的text-embedding-3-small性价比高3-large精度更高但成本和延迟都上去了。如果是纯中文的企业内部知识库我建议先用开源中文模型跑通不满意再换商用的做对比不要一上来就迷信贵的模型。这里要给一个容易忽视的忠告Embedding模型一旦选定并在索引库上跑完数据中途换模型意味着全库向量失效必须重建索引。别小看这件事我有一次图新模型效果更好直接换了Embedding结果检索返回一堆垃圾排查半天才意识到问题是向量空间变了。换模型可以但要在测试环境里完整重建索引、跑一遍评测再上生产。3.3 向量数据库选型从FAISS到Milvus向量数据库的选择取决于你的数据规模和使用场景我整理成一张表方便对照方案部署形态适用规模优缺点FAISS本地内存/文件百万级以内轻量、快、无服务但不带元数据过滤和数据管理适合原型验证Chroma本地/嵌入式万级到十万级上手极快适合练手项目生产稳定性一般pgvectorPostgreSQL扩展百万级以上复用现有PostgreSQL运维支持SQL过滤复杂查询能力一般Qdrant独立服务千万级开箱即用过滤功能强文档体验好Milvus分布式集群亿级以上企业级性能支持混合检索部署和运维成本较高我的建议很简单先跑Demo用FAISS或Chroma时间成本最低产品化后如果公司本来就有PostgreSQL直接上pgvector数据量真到千万级了再考虑Qdrant或Milvus。不要一上手就上分布式向量库复杂度会吃掉你的开发效率。4. 手写一个最小可用的RAG管道4.1 技术栈选择与理由很多人纠结要不要上LangChain、LlamaIndex这类框架。我的观点是练手和快速验证框架能帮你省掉大量样板代码理解原理和排查问题你必须知道框架背后做了什么。我建议的路线是先用LangChain跑通最小闭环同时把每一步对应的组件摸清楚之后再决定哪些环节要换成自研。下面这段代码是我常用的标准起步配方用RecursiveCharacterTextSplitter切分、HuggingFaceEmbeddings做向量化可换成OpenAI接口、FAISS做存储和检索、ChatOpenAI做生成。这个组合能跑通全部流程而且每一步都可替换。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI # 1. 加载本地文档 loader TextLoader(company_manual.md) documents loader.load() # 2. 切分文档512 token一块重叠80 token text_splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks text_splitter.split_documents(documents) # 3. 向量化并写入FAISS索引 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-m3) vectorstore FAISS.from_documents(chunks, embeddings) # 4. 检索 question 公司的请假审批流程是什么 retrieved_docs vectorstore.similarity_search_with_score( question, k5 ) # 5. 组装Prompt并交给LLM prompt ChatPromptTemplate.from_template( 请根据以下资料回答问题。资料不足以回答时请明确说不知道。\n\n 资料\n{context}\n\n 问题{question} ) chain prompt | ChatOpenAI(modelgpt-4o-mini, temperature0) answer chain.invoke({ context: \n\n.join(doc.page_content for doc, _ in retrieved_docs), question: question, }) print(answer.content)这段代码看起来短但每一步都有讲究。切分器的separators列表按优先级排列从粗粒度符号到细粒度符号依次尝试目的是尽量在语义完整的地方切分而不是硬生生截断句子。temperature0保证生成稳定减少自由发挥。k5是常见的起步值数据量大、文档块多时可以适当上调到8或10。4.2 核心参数的选择逻辑很多新手会问这些参数为什么这么设我挑三个最关键的解释一下。第一个是chunk_size512。我测试过的经验是512 token左右能在语义完整性和检索精度之间取得平衡。如果你的文档是FAQ形式、每条问答本来就很短可以降到256如果你的文档是大段大段的描述文字可以提到1024。没有绝对正确的值只有针对你文档的最优值。第二个是chunk_overlap80。这个参数的作用是防止语义在切分边界处断裂。比如上一块结尾讲了请假的前提下一块开头接审批流程如果没有重叠检索时可能只命中后半句模型看不到前半句的语境。80到100的overlap在成本增加几乎可忽略的情况下能明显提升匹配质量。第三个是k5。k小了会漏召回k大了会引入噪声。我建议先固定k5跑一轮评测如果hit rate不达标优先优化切分和检索策略而不是单纯把k往上加。k不是越大越好大k意味着更多不相关片段进入Prompt模型反而容易被带偏。4.3 如何验证管道是否真的有效跑通不等于有效你必须有一套验证方法。我最常用的验证手段是两个指标Hit Rate和MRR。Hit Rate衡量的是正确文档是否出现在检索结果里比如准备10个测试问题每个问题对应一个标准答案片段看检索Top5里有没有命中命中8个就是80%的Hit Rate。MRR更严格一点看正确答案排在结果里的第几位排得越靠前越好。实际操作中我会准备一张评测表每行一条测试问题、对应的标准答案片段、预期来源文档。然后跑一遍完整RAG统计Hit5和MRR。这样调整任何参数都能用数据说话而不是靠肉眼感觉。我见过太多团队凭感觉调参调了一个月不如一张评测表解决得快。5. 检索效果翻车的七个原因与排查思路RAG项目做多了你会发现一个问题效果不好背后往往不是单一原因而是好几个因素叠加。我梳理了七个高频问题按排查优先级排列方便你对照自己的系统排查。第一个是文档清洗不足。PDF里的扫描件、表格、页眉页脚混入正文会让切分器把无意义的碎片当成知识块。我处理过一个真实案例某产品手册的PDF页眉里带着机密两个字切分后大量块都包含机密检索产品的保修政策时返回结果里混了一堆带机密的无关内容。解决办法是加载后先把页眉页脚、特殊字符清洗掉再做切分。第二个是切分粒度与文档特征不匹配。如果你的文档是问答对用固定512 token切分就会把一问一答拆成两块检索这个问题的答案时只能命中问题块答案块反而落选。这种场景应该用结构感知的切分比如按问题答案作为一个计费单元。第三个是TopK与相似度阈值失配。这是一种很常见又很隐蔽的问题similarity_search_with_score返回的score取值范围对不同的Embedding模型是不同的如果你从前一个项目里沿用了一个阈值换模型之后可能所有结果都低于阈值。我后来一律改成先看召回排名再用归一化分数做最后过滤不迷信绝对数值。第四个是忽略元数据过滤。知识库里同时放着市场资料和技术文档用户问某个API的调用方式如果不按文档类型过滤检索结果很可能被市场宣传稿淹没。解决思路是在索引时给每块文档打上元数据标签检索时用filter参数缩小区间。第五个是查询表述与文档用语错位。用户口语化地说这个功能咋开文档里写的是启用该功能向量模型虽然能处理一定程度的语义匹配但字面差异过大时仍然会漏召回。解决手段是查询改写让LLM把口语问题改写成文档风格的关键词组合或者用MultiQuery一次检索多个不同表述的变体。第六个是缺少重排序。向量检索的初排结果里前面几条可能只是看起来相关真正命中的片段落在第6位。这时候如果强行用Top5做生成答案就差了一截。做法是加一个重排序模型比如bge-reranker-base把初排返回的Top20先捞出来再用重排序模型精细打分取Top5进Prompt。这一步对效果的提升非常显著值得投入。第七个是没做评测就上线。没有评测的RAG系统所有参数的合理性都是靠这次答得还行的主观感觉。上线之后用户一多问题就暴露了。我一直要求自己的项目至少准备50条测试问题覆盖常见问答、边缘情况、知识库不存在的问题三类跑完评测再谈发布。我把这七个问题整理成一张速查表方便排查时对照症状可能原因优先排查动作返回片段明显无关Embedding模型不统一确认索引和查询使用同一Embedding答非所问但片段相关知识库混入不同领域文档加入元数据过滤答案缺关键细节chunk_size太小调大chunk_size或改用Parent Retriever同义表达检索不到查询与文档表述差异大加查询改写或MultiQuery正确答案排位靠后向量初排精度不足加重排序模型分数正常但结果很差文档清洗不彻底检查切分后的文本块内容6. 从静态RAG到Agentic RAG知识管道的进化方向6.1 Flow RAG到Agentic RAG的差异前面讲的这套标准RAG链路本质上是一个固定流程来了问题就检索检索完就生成所有问题都走同一条路。这种模式叫Flow RAG优点是稳定、可控、好排查缺点是笨——不管问题多简单都要去检索一遍知识库不管知识库有没有相关内容都要强行生成一段答案。Agentic RAG的思路则是把RAG从一条固定管道降级成Agent手下的一个工具。Agent先分析问题这个问题需要查内部知识库吗需要查哪个库需要多跳检索吗需要结合其他工具吗想清楚之后再决定调用RAG的时机和方式。这意味着RAG不再是一个被动等待调用的大管道而是一个可以被Agent灵活编排的主动模块。我做过一个实践对比。同样是回答新员工的报销额度是多少Flow RAG的做法是老老实实检索报销文档然后回答如果文档里没写它就编一个。Agentic RAG的做法是先判断这是政策类问题去检索政策库如果政策库信息不足再去检索内部论坛如果还查不到它会直接说我只在政策文档里没找到这条建议咨询财务部而不是硬编。6.2 多跳检索与意图路由Agentic RAG里两个最核心的能力是意图路由和多跳检索。意图路由解决的是这个问题该不该检索、去哪个知识库检索的问题。常见实现方式有两种一种是规则路由根据关键词或正则判断问题类型另一种是语义路由把用户问题向量化跟各个知识库的描述做相似度匹配选相似度最高的库。我在企业内部做过三库分离政策库、技术库、FAQ库用语义路由的效果明显好于全库统一检索因为三个库的向量空间差异大混在一起检索会让向量被平均掉相关性被稀释。多跳检索解决的是一个知识依赖另一个知识的问题。举个例子用户问我在国外出差报销流程和国内有什么不同第一跳检索可能命中国内报销流程但流程里提到特殊情况参照差旅规则第二跳就要继续检索差旅规则里关于境外部分的说明。多跳检索需要上下文追踪把上一跳的答案作为下一跳的输入这对Agent的记忆能力有要求也对知识库的关联结构有要求。做多跳RAG的前提是先把单跳RAG的准确率打磨到位否则错误会在每一跳被放大。6.3 RAG与Agent的记忆、工具调用如何融合回到这个系列的视角知识获取管道从来不是一个孤立的模块。Agent的四项核心能力——规划、记忆、工具调用、知识获取——在实际系统中是交织在一起的。RAG负责提供外部显性知识记忆负责提供历史会话上下文工具调用负责提供实时数据访问三者各司其职但必须配合。我的经验判断是RAG在Agent架构里的定位越来越像一个知识服务它应该暴露稳定、可重入的调用接口供Agent在需要时按需取用而不是把所有知识直接塞进Agent的系统提示词里。你可以在系统提示词里告诉Agent有一个知识库工具当你需要查询公司文档时调用它然后让Agent自己判断调用时机。这样设计的好处是解耦知识库换了、RAG逻辑升级了Agent主体不受影响。从这个角度回头看知识获取管道这个词的含义就很清楚了——它管的是知识的流动方式而不是某一套具体技术。你今天用标准RAG搭的管道明天可以在不推翻架构的前提下逐步演进成多路召回、重排序、意图路由、多跳检索的形态。最后分享一个我在实际项目里的体会不要一上来就追Agentic RAG的时髦。先把标准RAG的索引、检索、生成三段链路跑通用评测表把Hit Rate和MRR打磨到稳定水平再逐步引入路由、重排序、多跳这些进阶能力。知识获取管道这东西前面的地基打得越扎实后面的进化越省力。如果你现在已经有一个能跑但效果一般的RAG建议对照第五节的速查表排查一遍大概率能找到拖后腿的那一环。