前几篇文章我们把 Agent 的“大脑”搭起来了计划、执行、反思的循环都能跑通。但真正把 Agent 丢到业务里用的时候几乎所有人都会撞上一个尴尬场景你问它“咱们内部文档里关于XX模块的配置参数是什么”它要么从训练数据里翻出一个过时的答案要么理直气壮地给你编一个不存在的配置项。这时候你就明白了一个能跑通的 Agent 和一套能用的 Agent 之间隔着一条知识获取管道。所谓 RAGRetrieval-Augmented Generation检索增强生成本质上就是给大模型外挂一个“开卷考试”的资料库让它在回答问题之前先去指定的知识库里检索一番。这篇是这个系列的第四篇我们就把 RAG 的基础链路彻底掰开揉碎从分块、向量化、检索到合成把整条管道的每一个环节、每一处坑都讲清楚。这篇文章适合谁看正在搭 Agent 但不知道怎么把文档知识喂进去的人RAG 刚入门想弄懂全流程的开发者以及已经被“召回不准、答案乱编”折磨过的同学。不整那些炫技的概念堆砌就按实际工程里的干活逻辑把 RAG 这条知识获取管道从零到一走一遍。1. 为什么 Agent 需要一套“知识获取管道”1.1 大模型的三大硬伤先说一个最基本的判断你今天用的任何一个 LLM本质上都是一个“死记硬背的学霸”。它确实读了很多书但你问它某个企业内部文档里的内容时这学霸就露馅了因为它根本没读过你那份文档。问题主要出在三个层面。第一是知识截止。模型的训练数据有一个时间点在这之后的新闻、产品更新、行业动态它一概不知道。你拿 2026 年的车险政策去问一个训练数据只到 2024 年的模型它只能凭着旧知识猜。第二是私有数据隔离。企业内部的制度文档、代码注释、设计规范、客户案例这些内容永远不会进入大模型的训练集。不是模型不想学是出于隐私合规的考量训练环节根本接触不到这类数据。你让一个模型回答“咱们公司报销流程是什么”它只能给你编一个通用版本。第三就是幻觉。这是最阴险的一个问题。当模型被问到一个它不知道答案的问题时它不会像搜索引擎一样诚实地告诉你“没有相关结果”而是会用它强大的语言能力把猜测组织成一段听起来非常可信的答案。而且模型对自己的幻觉几乎没有感知它不知道自己在编。把这三个问题放在一起看结论很清晰模型的能力上限是固定的但我们可以通过外接知识来弥补它的信息盲区。这就是知识获取管道存在的意义——它负责把外部知识转换成模型能读懂、能检索、能引用的格式然后在模型生成答案之前先把相关资料塞进它的视野里。1.2 为什么是 RAG而不是微调聊到给模型补充知识很多人会想到微调Fine-tuning。这条路也确实有它的价值但在大多数知识注入场景下RAG 是更务实的那个选择。我做过一次对比从五个维度看两个方案的差异知识更新成本RAG 更新文档后重新索引即可几分钟完成。微调需要重新训练模型动辄几小时甚至几天还需要训练资源和专业调参能力。数据量需求RAG 对数据量不敏感哪怕只有几十页文档也能立刻用。微调想要效果稳定通常需要大批量的高质量数据几十条训练样本基本无效。可追溯性RAG 可以从检索结果中拿到原文出处回答“为什么这么答”有据可查。微调的知识分布在整个参数空间里很难定位某个答案来源于哪篇具体文档。幻觉风险RAG 通过引用原文约束生成幻觉风险显著下降。微调反而是增强模型“记忆”的概率模式对幻觉没有抑制作用。成本RAG 只需要向量库的存储和检索计算成本极低。微调除了训练算力后期每一次知识更新都要重复投入。用个不太恰当但很传神的类比微调是把新知识装进模型的脑子里代价是脑子要停下来重新“读书”RAG 是给模型配一个书架它需要什么知识就去书架上查书架上的书既便宜又新。对一个需要频繁更新知识库的业务系统来说RAG 的性价比是压倒性的。当然微调也不是没有用武之地。如果你的目标是让模型学会特定的语气风格、输出格式、工具调用的行为模式这些不属于知识注入而是能力改造那微调依然是最合适的方案。两种手段并不互斥成熟的项目里往往是 RAG 注入实时知识微调定义输出风格。1.3 “知识割裂”这关怎么过现在很多企业面临的不是没有知识恰恰是知识太多、太散。产品文档在语雀、设计稿在 Figma、技术方案在 Wiki、售后记录在工单系统数据和数据之间互相孤立。你让 Agent 回答一个跨模块的问题比如“用户反馈 App 登录报错可能跟前端版本和鉴权服务有什么关系”它需要同时检索前端文档、后端文档、历史工单再把多源信息拼起来。这就是标题里强调的“知识获取管道”的含义。RAG 不仅要解决“有没有知识”的问题更要处理“知识碎片如何拼接”的问题。一条设计良好的管道应该让 Agent 像自来水一样拧开龙头就有经过过滤、沉淀、净化的知识流出来。2. RAG 全链路拆解知识获取管道的五段工序2.1 第一段文档加载与清洗很多人以为 RAG 的第一步是写代码调 API其实真正的第一步是把文档变成“能用的文本”。你手上的 PDF、Word、HTML、Markdown格式千差万别里面的排版信息、页眉页脚、表格嵌套对模型来说全是噪音。我在实际项目里踩过一个大坑直接用现成工具库把 PDF 转成文本结果表格里的数据横七竖八数字和单位错位页码混进了正文检索时经常把“第 3 页”当作有效内容返回给模型。后来学乖了清洗管线至少要做三件事剔除页眉页脚和重复导航信息、用专门的表格解析能力还原表格结构、做编码转换保证中文不乱码。如果你处理的是扫描版 PDF还要先走一层 OCR。这一步不做好后面的所有工序都是在垃圾堆里淘金——检索再准索引的内容是错的答案也只有歪的。我的经验是加载阶段宁可多花一倍时间也不要急着往下走。数据质量差导致的检索问题后期排查成本是按小时计的。加载器选型上文件数量少可以直接用现成库文件数量多且格式杂建议引入统一的数据接入层用一套接口管理所有格式的解析逻辑。2.2 第二段分块策略——把文档切成模型能消化的尺寸文档加载完是一大坨文本但向量检索不能拿整篇文档去计算。原因有两个一是模型对输入长度有限制超长文本直接超出窗口二是检索粒度太粗一篇 50 页的产品手册你问“颜色设置在哪里”返回整篇手册没有任何意义。分块Chunking的核心是把语义完整的段落切在一起尽量避免把一个意思从中间截开。实际操作里我推荐一个非常实用的策略优先按照文档结构和语义边界切分。比如标题、段落、列表项天然就是语义单元先按这些边界切再设一个最大长度兜底。如果一段特别长超过上限再往下细分。分块的参数有一个反直觉的点网上很多教程喜欢用固定篇幅比如每 500 字一块每 200 字一块。但实际使用中文本长度和语义完整性是两个维度。固定 500 字在多数情况下可行但是遇到那种一句废话没有的代码文档500 字往往包含了四五层嵌套的上下文一个完整的配置项被切成两半检索时只命中一半。我建议选择“递归字符分割器”它先按段落切再按句子切再按字符数兜底尽量保证语义块完整。分块之间的重叠overlap也不能省。想象一段文字讲到“这个接口的返回值包括 status 和 message其中 status 表示……”如果 200 字的分块恰好把“status 表示什么”切到了下一块上一块就丢失了关键信息。加一段重叠文本可以在一定程度上弥补切分造成的语义撕裂。我常用的配置是块大小 500~800 字重叠 50~100 字具体数值根据文档类型调代码类的可以更小。2.3 第三段Embedding 与向量化——把文字翻译成坐标分好的文本块要能被计算相似度第一步是把它变成向量。这里要澄清一个概念Embedding 不是把文字变成数字那么简单它是把一段文本映射到一个高维空间里的坐标让语义相近的内容在空间里离得近语义无关的内容离得远。选 Embedding 模型时中文场景建议优先看两件事一是对中文的分词和语义理解能力二是向量维度与检索性能的平衡。维度越高表达语义的能力理论上越强但存储和计算开销也越大。我在本地实验时习惯用 bge-m3它同时支持中英文、多粒度语义理解而且对小文本块的检索效果很稳定。如果完全走云端 APIOpenAI 的 text-embedding-3-small 或者 Cohere 的 embed 系列都可以核心是与你用的主模型生态匹配。这里提醒一句所有文本块最好用同一个 Embedding 模型不然向量空间不一致相似度计算就是鸡同鸭讲。还有查询的问题也要经过同一个模型向量化这一点经常被人忽略——你文档用了 bge-m3查询时却换了别的模型召回效果会直接崩掉。2.4 第四段检索与召回——从向量库里挑出最相关的候选向量化是给知识块编码检索就是在这个编码空间里找邻居。把查询向量带入向量库系统会返回距离最近的一批文本块这就是召回Recall。基础形态的检索是向量相似度检索它擅长捕捉“意思相近但表述不同”的文本。比如你问“公司出差补贴怎么算”文档里写的是“差旅费用报销标准”字面上完全不一样但语义相近向量检索能找到。但它也有明显的短板对精确匹配和专有名词不敏感。你检索一个型号“A100-X2”向量会把“A100”系列都拉出来反而稀释了精确结果。解决这个短板工程上建议直接用混合检索Hybrid Search向量相似度负责召回语义相近的内容BM25 这类传统关键词算法负责召回精确命中的内容两组结果合并后再做一个去重和加权排序。混合检索是 RAG 系统从“能用”到“好用”的一道坎这一点后面讲实战时再细说。召回的数量也要控制。召回太少了漏信息召回太多了噪声多模型反而被不相关内容带偏。我常用的默认值是把 top_k 设为 4 到 8先跑一轮看答案质量再做微调。2.5 第五段Prompt 组装与生成——把检索结果变成一片“开卷考试的参考资料”检索到的文本块不能直接丢给模型了事需要组织成模型能有效利用的结构。这一步关系到 RAG 最终的回答质量也是最容易被低估的环节。一段合格的 RAG Prompt 至少包含三个部分系统指令说明约束、检索到的上下文片段、用户的原始问题。系统指令要明确告诉模型优先依据参考资料回答参考资料中没有的信息要直接说明“文档中没有提到”而不是自行脑补。上下文片段最好按相关度从高到低排列并且给每段标注来源出处方便模型在回答时做引用。真实经验和提示在 Prompt 里显式写一句“If the context does not contain enough information, reply with ‘I cannot find the answer from the provided documents’效果非常好。这句约束对降低幻觉有奇效对生产系统来说宁可让它说不知道也不能让它乱编。这一套流程走下来RAG 的基础管道就是完整的。但实际工程里每一步的细节都能影响最终效果下面我们直接用一个最小可用的项目把整条管道跑起来边写代码边说参数为什么这么调。3. 从零搭建一个最小可用 RAG 管道3.1 技术选型自己搭还是用框架动手之前先解决一个很实际的问题RAG 管道自己徒手写还是用现成的框架。我的看法是学习阶段一定要手写一遍全链路哪怕最后代码很简陋这样你对每个环节发生了什么才有真正的体感。产品阶段再用框架把它工程化。这里我用 LangChain 做示例因为它的文档加载器、文本分割器、向量库封装都比较成熟代码量最少适合讲清楚核心概念。向量库选 FAISS它是单机版的向量索引库不需要单独部署一个数据库本地实验完全没有负担。Embedding 模型可以用本地模型也可以用云端 API示例代码里留好接口。内部来说这个组合是最适合拿来练手的LangChain 负责管线编排FAISS 负责向量存储和检索API 负责最终的生成。等到生产环境数据量超过百万级再迁移到 Milvus、Qdrant 或 Elasticsearch 都不迟。3.2 代码走读一步一步搭建管道第一步加载文档。从本地文件读入文本并做基本的清洗。from langchain_community.document_loaders import TextLoader, PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载文档支持 txt、md、pdf 等格式 loader TextLoader(product_manual.md) documents loader.load() # 清洗去掉多余空行和特殊符号 for doc in documents: doc.page_content \n.join( [line.strip() for line in doc.page_content.split(\n) if line.strip()] ) print(f加载完成共 {len(documents)} 个文档)第二步分块。使用递归字符分割器块大小设为 500 字符重叠 50 字符。text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , ], ) chunks text_splitter.split_documents(documents) print(f分块完成共 {len(chunks)} 个文本块)一个细节值得说明separators 列表里的切分优先级从上到下依次降低。先按段落切段落太长按句子切句子还太长就按字符切。这样做的目的是在块大小限制内尽量保留完整的语义单元。第三步向量化并存入向量库。from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 初始化 Embedding 模型 embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-m3 ) # 将文本块向量化并存入 FAISS 索引 vectorstore FAISS.from_documents( documentschunks, embeddingembedding_model ) # 保存索引到本地 vectorstore.save_local(faiss_index/product_index)这里有两个容易踩的坑。一是首次运行会下载 Embedding 模型网络状况不好时容易超时建议预先手动下载一次。二是 FAISS 索引保存后文档内容和向量是一一对应的后续如果新增文档要用 add_documents 累加进去而不是重新建库重新建库会把之前的检索记录全部覆盖。第四步实现检索函数和回答函数。from langchain_community.vectorstores import FAISS # 加载索引 vectorstore FAISS.load_local( faiss_index/product_index, embedding_model, allow_dangerous_deserializationTrue ) retriever vectorstore.as_retriever(search_kwargs{k: 4}) def ask_with_rag(question: str) - str: # 1. 检索相关内容 docs retriever.invoke(question) # 2. 组装上下文 context \n\n.join([doc.page_content for doc in docs]) # 3. 构造 Prompt prompt f 你是一个基于参考资料回答问题的助手请严格基于以下上下文回答用户的问题。 如果上下文中没有足够信息请直接回复我无法从提供的文档中找到这个问题的答案。 回答时请尽量引用原文中的关键信息。 参考资料 {context} 用户问题 {question} # 4. 调用大模型生成回答此处以 OpenAI 风格的接口为例 response chat_model.invoke(prompt) return response这个函数把整条 RAG 流程串起来了。检索、组装 Prompt、生成三个步骤循环复用就是你 Agent 调用知识库的底层核心。3.3 参数调整经验别照抄默认值代码看着简单但让 RAG 在不同业务上都稳定运行参数调整才是真正的功夫。top_k 的确定建议按问题类型区分。事实型问题“报销上限是多少”建议调大一点到 6~8防止漏掉关键依据综述型问题“介绍一下产品的主要功能”4~6 就够上下文太杂反而答得不聚焦。分块大小的选择简单场景用 500~800 字没问题但遇到强上下文的文档可以试一下父子分块策略。父块存大段原文用于检索子块存细粒度内容用于喂给模型。这样既能保证召回的范围完整又能让模型看到精准的细节。还有一个所有 RAG 项目都无法回避的问题——怎么评估管道的好坏。我在实战中用的指标是 hit rate即“对于 N 个测试问题有多少比例的问题能检索到正确答案”。每次调整参数后用一个固定的测试集跑一遍 hit rate做前后对比。反反复复试下来你会发现RAG 调参不是感觉艺术而是一场数据驱动的实验工程。4. 实战中的翻车现场与排查实录4.1 问题一召回命中率低文档就在库里却搜不到这是 RAG 上线后最高频的问题主要症状是明明把文档传进向量库了但问一个非常具体的问题返回的文本块完全不相干。排查这类问题我习惯按以下顺序逐项排查检查文本清洗是否到位。如果原文档里的关键词是图片格式比如产品截图里的文字直接加载文本会丢失这些信息需要先走 OCR。检查分块参数是否合理。块太大导致语义混杂块太小导致信息片段化都会拉低召回率。检查查询改写是否缺失。用户的自然问题常常包含口语化表达、代词、省略主语的句子。例如文档里写的是“Spark 引擎支持动态资源分配”用户问的是“这个引擎能自己调整内存大小吗”如果不做查询改写向量检索的相似度可能不够高。最后也是最常见的原因没有使用混合检索。纯向量检索对上文提到的精确匹配问题无能为力。针对查询改写我强烈建议加一层轻量逻辑在调用向量库之前先用大模型把用户问题改写成适合检索的形式。比如把代词还原成完整名词、补充术语的别名、把疑问句改写成陈述句。改写后再走向量检索命中率提升非常明显。混合检索的工程化实现也不复杂。BM25 和向量检索各出几个结果用简单的 RRFReciprocal Rank Fusion合并排序公式就是把两个来源的结果排名取倒数然后求和排名越靠前权重越高。代码量大概 30 行效果立竿见影。4.2 问题二检索到了正确答案模型还是答错或胡编撞见这个问题时我的第一反应不是质疑模型而是怀疑 Prompt 写得太“仁慈”了。很多初学者写的 Prompt 是“请根据上下文尽可能回答问题”这句话的潜台词是就算上下文信息不全你也要尽量猜。模型接收到这个信号自然会发挥想象力。正确做法是在 Prompt 里加强约束。我常用的写法是分三层第一层告诉模型它的角色和任务第二层明确“只允许使用参考资料中的信息”第三层给出“信息不足时固定回复格式”。这段约束在小模型上尤为重要7B 级别的本地模型如果没有强约束幻觉概率会高出好几倍。还有一个细节值得考虑对召回结果设置最低相似度阈值。当所有检索结果的相关度都低于某个阈值时直接返回“知识库中没有相关信息”而不是强行从最不相关的片段里编答案。这个阈值需要先跑一批真实查询看相似度分布再在做选择时确定一个相对合理的界限。4.3 问题三长文档与表格内容的切分撕裂产品白皮书和技术文档里通常有大量表格和代码块。表格切分后表头和表体可能被分到两个文本块喂给模型时模型只看到一堆数字完全对应不上字段名。代码也有类似问题一个函数的注释和实现分离语义全丢。我的经验是用“表格感知的切分器”。识别出文档中的表格把它作为独立的语义单元不参与普通文本的切分。代码块类似先提取出来再按其逻辑边界切分。LangChain 的自定义 TextSplitter 可以针对不同内容类型分派不同的分割策略而这种时机的分割效果比大一统的固定切分好很多。关于长文档我还有一个小建议文档主题越分散越应该在切分前先做章节归纳。一个 200 页的产品白皮书涵盖安装、配置、调优、FAQ如果整个塞进同一个向量库检索时容易跨章节拉取不相关内容。按章节拆成多个子文档再给每个子文档打上主题标签问答时先做主题路由再做向量检索效果拔群。4.4 问题四性能瓶颈检索延迟一高就拖垮对话体验RAG 查询一个很常见的问题——每次问答都走一遍“向量化 检索 大模型生成”导致首字节延迟很高。当知识库膨胀到几十万条文本块时这个延迟会进一步放大。我有三个层次的优化手段按投入产出比排序第一层缓存。对高频问题把问题和最终回答做缓存命中缓存直接返回。这一步对成本和服务响应速度的改善最高改动最小。第二层向量索引优化。FAISS 支持 IVF倒排索引和 HNSW图索引HNSW 在千万级数据量下依然能保持毫秒级检索但会牺牲少量精度。可以给索引文件开启持久化把加载索引的时间从启动时移到后台预加载。第三层并发与异步。检索和生成之间没有强依赖可以并行执行多次检索再合并结果。多个知识库之间的检索也完全可以异步并发。等这一套做完RAG 管道才算真正达到了生产级别。4.5 问题排查速查表现象可能原因排查方向解决方案召回结果不相关文档清洗不彻底检查原始文本是否有乱码、噪声加强清洗环节必要时引入 OCR语义相似但匹配不到向量模型不匹配确认 Embedding 模型是否统一统一查询与文档的 Embedding 模型精确匹配失效纯向量检索局限检查专有名词、型号是否有命中加入 BM25 混合检索模型回答胡编Prompt 约束不够审查系统提示词增加强约束提示表格内容答错切分撕裂表格检查分块中表格数据是否完整使用表格感知切分策略响应太慢检索链路过长定位耗时环节缓存 索引优化 并发5. 从 RAG 到 Agentic RAG让知识获取管道长出“手和脚”5.1 把检索变成 Agent 的主动技能前面的 RAG 流程是单轮的用户提问一次系统检索一次生成一次。但在真实的 Agent 场景里知识获取不应该是一次性的动作而应该是一个可被调用的工具。Agentic RAG 的核心理念是把 RAG 管道封装成 Agent 可以自主调用、自主决策的工具。Agent 接到一个复杂问题时不会直接生成最终答案而是先规划这个问题涉及哪些知识领域该查哪些知识库一次检索够不够还是要多轮检索然后像人一样先查资料、评估结果如果信息不足再调整检索策略。举个例子用户问“按 A 方案部署后登录报错该怎么排查”。一个完整的 Agent 行为应该是先检索“A 方案部署说明”拿到部署步骤和注意事项再检索“登录报错”相关排障手册如果两份资料对不上还可能进一步检索“认证服务配置”专题。整个过程涉及多次检索、多源信息融合这才是 RAG 在 Agent 场景下的完全形态。5.2 多知识库路由与 Agent 记忆的协同当你在一个 Agent 里挂了多个知识库时每次都把所有知识库搜一遍显然不明智既慢又容易把不相关的信息混进上下文。工程上通常会增加一个路由层由 Agent 先判断问题属于哪个领域再定向检索对应的知识库。这个路由既可以是一个分类模型也可以直接用大模型做意图识别。这里要注意一个细节Agent 的会话记忆和 RAG 的检索结果不一样。会话记忆负责存储对话过程中的用户意图和 Agent 历史决策RAG 负责提供当前问题所需的事实依据。两者互相补充但不要混在一起。我见过不少人把整个对话历史都塞进 RAG 的上下文结果上下文越来越长模型抓不住重点最后答案质量断崖下跌。正确做法是会话记忆单独管理每次只把必要的对话摘要和最新的检索结果一起组织到 Prompt 里。5.3 给 RAG 接上“行动力”RAG 基础管道解决的是“知道什么”Agentic RAG 在此基础上还要解决“能做什么”。同一个知识库里的内容既然是结构化数据除了拿来做问答还可以提取成 Action 的参数让 Agent 根据文档内容直接触发操作。比如知识库里有运维操作手册描述了“当 CPU 使用率超过 90% 时重启 xx 服务”。RAG 检索到这段内容后Agent 可以在执行环节调用重启服务的 API这就是从“读到知识”到“使用知识”的跨越。这一步在工程上并不复杂——在检索结果的元数据里加上“可执行动作”标记Agent 生成的回复里同时包含解释文本和操作指令。但对业务价值来说意义完全不同前者是一个会聊天的知识库后者才是一个真正的智能体。这套进阶玩法够单独写一篇了我们后面再展开。这篇先把基础管道打牢手里有粮心里才不慌。