这个系列写到第四篇前面几篇聊了Agent的基本架构、规划能力和工具调用。后台收到最多的留言是我的Agent手上确实有工具了但回答还是不对因为它的知识还是那一套固定参数里的东西。这其实引出了Agent构建里最容易被低估的一环——知识获取管道。今天这篇就专门聊RAGRetrieval-Augmented Generation检索增强生成聊透它在Agent里扮演的角色以及从零搭一条可用管道会遇到哪些坑。RAG不是新概念2020年前后就有人提但这几年它从“给模型喂点资料”变成了一套系统工程。而且在一个真正的Agent里RAG的价值远比“资料问答”大——它是Agent感知外部世界的核心通道是让模型从“闭卷考试”变成“开卷考试”的那本教材。这篇不追求面面俱到我尽量把索引、检索、生成这三个环节拆开揉碎再把实操里踩过的坑和参数调法一并交代清楚适合所有准备从0到1搭建AI Agent的开发者参考。1. 为什么Agent需要一条“知识获取管道”1.1 大模型的“知识天花板”从哪来先把基础背景讲清楚。大模型的知识本质上存进了网络的权重里训练完成的那一刻它的知识体系基本就定型了。你可以把这种知识理解成“参数记忆”问题在于它有天然的三个短板。第一是时间边界训练语料有截止日期模型不会自动知道今天发生了什么更不会知道昨天你公司刚发布的内部规范。第二是私有边界模型没见过你的企业文档、个人笔记、产品手册这些数据根本不在它的训练集里它再聪明也算不出来。第三是可更新性即使今天发现了知识错了也不可能重新训一遍模型来修正成本和时间都不现实。这也就解释了为什么很多Agent项目做到一半会遇到瓶颈工具调用解决的是“模型能不能做动作”的问题而知识获取解决的是“模型知不知道该基于什么做动作”的问题。两者缺一不可。1.2 RAG在Agent架构里干的是什么活RAG的全称是检索增强生成核心思路非常朴素在模型回答问题之前先从外部知识库里检索出相关片段把这些片段连同问题一起塞给大模型让它基于这些材料来生成答案。落到Agent架构里看这套机制承担的是感知层的职责。Agent的循环本质上是“感知—决策—行动”感知不仅仅是读懂用户输入还包括搞清楚当前情境下需要哪些背景知识。RAG管道就是负责把用户问题转化成检索请求再把外部知识注入到上下文里的那一环。我常用一个生活化的类比微调是让一个学生重新上一遍学去改变思维方式长上下文是让这个学生带一块巨大的写字板去考试而RAG是允许他带一本真实的教材进场。教材不需要背下来只需要知道去哪翻、翻到哪一页。这也解释了为什么RAG如今几乎成了Agent知识接入的默认方案——成本低、更新快、答案还能溯源。1.3 还有哪几条路可选微调、长上下文、RAG怎么选很多人会问既然模型知识不够为什么不上微调或者直接用超长上下文硬吃这三条路确实都能解决一部分问题但适用场景差别很大。微调适合改变模型的风格和固定行为模式比如让模型学会某种输出格式、某种行业术语体系。但微调改变不了实时事实你不可能每次文档更新都重训一次成本和时间都扛不住。长上下文适合单次需要消化大量材料的场景比如一次让模型读一本几百页的PDF但token费用高而且模型对长文本中部的信息容易“看是看见了但没真正用上”。我把三条路的关键维度整理成了对比表方便你按场景做决策维度微调长上下文RAG更新知识成本高需重新训练中需重传文本低改索引即可知识时效性依赖训练时间点依赖输入内容接近实时可溯源性差差好能引用片段成本高高取决于检索规模适合场景风格/行为定制的模型单次大文本理解动态变化的私有知识与Agent协同偏底层偏单任务与规划、工具天然互补今天这篇展开讲的就是第三列。但注意RAG和微调并不是二选一的关系很多成熟项目会先微调一个懂业务术语的底座模型再通过RAG注入实时知识两边配合。2. RAG核心流程逐段拆解索引、检索、生成RAG管道不管用什么框架底层逻辑都是三段式索引阶段把原始文档拆碎并向量化入库检索阶段根据用户问题捞回最相关的片段生成阶段把片段和问题组装成提示词交给大模型。每一段都有不少细节我们逐个来抠。2.1 索引阶段把文档变成模型能查的样子索引阶段决定了一条RAG管道的质量下限。这个阶段做的事情是文档加载、文本分割、向量化、存储入库。文档加载相对简单PDF、Markdown、HTML、Word甚至数据库里的字段都有现成的Loader可以处理。真正值得较劲的是文本分割。这一步很多人会直接给个固定chunk_size512就完事但分割好坏直接决定了后期检索能不能命中。为什么因为检索的最小单位是“片”如果片切得太碎一句话说的上半部分和下半部分分到了两个chunk里检索时经常找不到完整语义如果片切得太大chunk里混入了大量无关内容向量表示会被稀释检索精度也会下降。业内用来形容这个问题的词叫“检索命中率”hit rate分割参数是影响hit rate的第一道关卡。分割的策略要看文档类型。普通文本用RecursiveCharacterTextSplitter足够它按照“段落级分隔符优先、句子级其次、字符级兜底”的顺序递归切分尽量保证语义完整性。代码类文档要按函数或类来切表格文档要考虑按行或按块切不要一刀切。向量化这一步是把切好的文本块通过embedding模型转成高维向量。这里有个选型问题后面实操章节专门展开讲。存储侧可选方案很多轻量的有FAISS、Chroma重一点的有Mivus、pgvector数据量大或需要高并发时还要考虑ES加向量插件。选型的核心依据是数据量、并发量和是否需要带过滤条件的混合查询。2.2 检索阶段怎么把最相关的片段捞回来检索阶段负责从索引里捞数据难点是“相关”两个字怎么定义。最基础的方案是纯向量检索。把用户问题的文本也过一遍embedding模型得到查询向量然后在向量库里做相似度搜索常用的度量方式是余弦相似度。这个方案对语义层面的近义表达很有效比如用户问“怎么退换货”文档里写的是“退款流程”向量检索能识别两者相关。但它对精确术语、编号、型号这类需要字面匹配的信息并不敏感明明文档里写了“型号A300”用户也问了“A300”向量检索反而可能因为语义分布被别的词带偏。解决方案是混合检索。主流做法是BM25稀疏检索和向量稠密检索并行BM25负责精确匹配、术语召回向量负责语义扩展最后通过RRF倒数排名融合或加权求和把两路结果合并。实测下来混合检索对技术文档、产品手册这种大量出现型号和专有名词的场景提升非常明显。检索到候选片段之后还差一道精排。粗排阶段无论是向量还是BM25拿到的都是基于轻量计算的Top-N精度不够。精排时用rerank模型通常是cross-encoder结构对候选片段逐条和问题计算相关性打分重新排序后只取前几名。当然rerank是有代价的几十个候选片段的精排会额外增加几十次小模型的推理好在模型普遍很小延迟可接受。2.3 生成阶段提示词与答案组装检索拿到了高质量片段最后一步就是把片段组装成提示词喂给大模型。这一步的关键设计我总结为三条约束立场、控制长度、强制溯源。约束立场指在提示词里明确告诉模型只允许基于参考片段回答片段里没有的信息要直接说不知道严禁脑补。这一步是压制幻觉的主要手段。控制长度指设置回答上限比如要求回答不超过300字避免模型把整段上下文抄一遍。强制溯源指要求回答里带上引用标记比如编号[1]、[2]对应参考片段的来源这样用户能回查原文错误也能追责。这里有一个Agent场景特有的补充点与普通问答不同Agent的RAG往往不只要生成一段回答还要把检索到的知识传递给后续的规划模块和工具调用。所以生成阶段的输出最好是结构化的——除了答案正文还可以附带citations、confidence、related_questions等字段方便下游模块做判断。3. 从0到1搭建一条最小可用的RAG管道下面进入实操环节。我会按照一个真实项目的最小闭环来搭目标是让你拿到一段代码就能跑起来接着再讲怎么把参数调好。3.1 技术选型框架选型与对比动手之前先选型。当前可选路线大致有三类用LangChain这类通用框架、用LlamaIndex这类检索增强专用框架、或者干脆自己写。Java技术栈还可以关注Spring AI和LangChain4j后面单独提一嘴。LangChain生态最全文档多模型和向量库的适配广适合快速验证和做Agent编排。它的缺点也很明显抽象层级多版本迭代经常破坏接口出了问题排查成本高。LlamaIndex对索引结构、检索策略、文档解析的打磨比LangChain深如果你主攻知识库问答它的体验往往更好。自己写其实没有想象中复杂核心就是前面说的三段式加起来几百行代码好处是完全可控、没有框架包袱适合生产环境里已经有一套成熟的检索体系在内部使用的团队。我自己的建议是分情况看。学习阶段强烈推荐自己写一遍有助于把流程彻底想透着急出原型用LangChain重知识库场景用LlamaIndex。下面是选型对比方案优势劣势推荐场景LangChain生态丰富、组件全、上手快抽象多、版本变动大快速原型、Agent编排LlamaIndex索引与检索策略更强做Agent偏弱知识库深度问答原生自实现可控、透明、易Debug功能要自己造学习、生产定制Spring AI / LangChain4jJava体系内集成方便组件相对少于前者Java后端团队Spring AI这套在Java圈现在关注度很高如果你所在团队是Spring Cloud体系可以考虑直接在里面集成Spring AI的RAG模块省一层跨语言调用。不过核心原理和本篇讲的三段式没有区别只是换了一套API表达。3.2 实操步骤加载、分割、向量化、入库、检索、生成下面给出一段基于LangChain的最小实现。我的示例里embedding用了中文本地模型向量库用ChromaLLM用OpenAI兼容接口的方式接入这样你换成通义、DeepSeek或者本地部署的Qwen都只要改base_url和api_key两个参数。from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI # 1. 加载原始文档 loader TextLoader(product_manual.txt, encodingutf-8) documents loader.load() # 2. 文本分割基础参数先行后续按评测调整 text_splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) chunks text_splitter.split_documents(documents) print(f共切分为 {len(chunks)} 个chunk) # 3. 向量化中文场景推荐BGE系列 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True} ) # 4. 写入向量库并在本地持久化 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) # 5. 构造检索器先简单取Top-5 retriever vectorstore.as_retriever(search_kwargs{k: 5}) # 6. 组装提示词强制基于上下文、禁止编造 prompt ChatPromptTemplate.from_template( 你是一个基于参考材料回答问题的智能助手。 请严格遵循以下要求 1. 只能依据【参考内容】回答问题 2. 如果参考内容中没有答案请直接回复资料库中未找到相关信息 3. 回答末尾用[来源编号]标注依据。 【参考内容】 {context} 【用户问题】 {question} ) # 7. 接入LLM走OpenAI兼容协议 llm ChatOpenAI( modelqwen-plus, base_urlhttps://your-endpoint.example.com/v1, api_keyyour-api-key, temperature0.2 ) # 8. 组装检索-生成链路 rag_chain ( {context: retriever, question: lambda x: x} | prompt | llm ) # 9. 执行一次问答 result rag_chain.invoke(A300型号的保修期是多久) print(result)这段代码在概念上有参考意义足够让你把管道跑通。下面把每个环节的关键点拆开讲一遍。文档加载环节真实项目里很少只加载一个txt文件更多是批量目录加载或者从远端存储拉取。如果加载的是PDF注意先处理扫描件扫描件需要OCR识别不能直接当纯文本抽。表格类内容要小心PDF里表格抽出来经常乱序处理不当会污染语义可以考虑把表格转成结构化文本再入chunk。文本分割环节我的示例用了512作为基础chunk_size但你一定要知道这不是默认最优值。后面3.3单独讲怎么定。向量化环节代码里用HuggingFaceEmbeddings加载本地模型优势是不用额外付费、数据不出内网、延迟稳定。我用的bge-large-zh-v1.5是中文场景里性价比不错的选择。如果对英文文档为主可以考虑bge-large-en-v1.5或者更通用的text-embedding-3-large。存储环节Chroma是轻量级入口适合本地和原型。生产环境如果数据量过百万建议直接上专门的向量数据库或者支持向量检索的ES集群。这里有个容易踩的坑向量维度要和embedding模型输出对齐换embedding模型的时候必须重建索引不能混着存。检索和生成环节上面流程已经够用了但Agent场景里你大概率需要的是把RAG封装成一个工具函数而不是直接调用一条链。也就是说让Agent的规划器来决定“当前这个问题需不需要查资料”查到了再作为上下文交给后续模型。这是从基础RAG走向Agentic RAG的关键一步我在第5章展开。3.3 关键参数怎么定chunk_size、overlap、top-k、embedding模型参数调优是RAG工程里实打实的体力活我逐个讲清楚逻辑。chunk_size是每个片段的字符数。太小则语义断裂太大则噪音增加、向量精度下降。判断依据是语料的句式长度和主题密度产品手册这种短句多的文档可以把chunk_size压到300规章制度这类长段落多的调到800也没问题。最优值一定要靠评测集来定不能拍脑袋。chunk_overlap是相邻片段之间的重叠字符数作用是把被切断的边缘语义保留下来。通常取chunk_size的10%到20%。有个细节overlap并不是越大越好过大会让两个相邻片段高度相似检索结果里前排被同一个大段落的不同切片霸占答案多样性反而变差。top-k决定了最终拼进上下文的片段数量。这个参数的副作用是它直接占用了大模型的上下文长度和注意力资源。给一个典型值范围top-k取4到6比较稳妥超过8之后多出来的片段往往对答案质量没有正向帮助反而把关键信息淹没。如果遇到需要综合多个来源的复杂问题可以让检索器先取Top-20再用rerank模型压到Top-5这样既保证了召回率又控制了注入上下文的量。embedding模型的选择有三个维度看语言覆盖度、检索效果、推理延迟。中文场景我比较推荐BGE系列通用且社区资源多。更激进一点可以看OpenAI embeddings或者Cohere的embed-v3英文效果更稳但成本高。注意embedding模型的效果与你真实的语料类型强相关换模型后必须跑一遍评测集对比hit rate不要凭感觉。4. 常见问题与排查技巧实录这段内容来自我实际做项目时踩过的坑整理成速查表加详细说明便于你遇到同类问题时快速定位。现象根因排查顺序检索结果明显不相关embedding模型不合适 / 文档解析脏先看解析结果再换模型答案幻觉严重提示词约束弱 / 检索回来全是噪声先加提示约束再看检索质量回答冗长无重点top-k过大 / chunk过大调小top-k和chunk_size同一问题结果飘忽temperature过高 / 上下文不稳定降低temperature到0.2以下更新文档后无变化索引未重建 / 缓存未清确认入库逻辑是否执行中文匹配经常漏召回缺少混合检索加BM25并设置RRF融合4.1 检索质量差hit rate上不去怎么办hit rate是RAG项目里我最先看的指标含义是“标准答案对应的知识片段是否出现在了检索返回的Top-N里”。如果这个问题没解决后面生成阶段做得再好也白搭。我的排查顺序是固定的。第一步先检查文档解析把加载后的原始文本打印出来看一遍确定PDF有没有漏页、表格有没有错位、编码有没有乱码。大量翻车案例的根因都在这层。第二步检查分割参数把chunk_size往两端各扫一组值用评测集测hit rate曲线。第三步检查embedding模型在同样的检索器下换模型对比这一步成本低收益高。第四步上混合检索特别是文档里存在大量型号、编号、精确术语时BM25向量的提升立竿见影。最后再考虑上rerank。还有一个容易忽略的点查询改写。用户问法经常很口语化“你们那个能退款的产品怎么弄”直接拿这句话做向量检索效果很差。可以在检索前加一个小模型做查询改写把模糊口语转成标准查询词。这一步在Agent场景里其实可以交给Agent自己完成属于规划能力的一部分效果普遍比固定改写规则好。4.2 上下文过长、幻觉没解决刚才提到生成阶段要约束提示词但如果你已经严格约束了幻觉还是压不住问题大概率出在检索质量上。举个例子模型看到检索回来的五段材料里有三段根本不相关它不会主动忽略这三段而是会强行把它们当作背景知识在生成时“合理”地顺着编。所以压制幻觉的第一道防线永远是检索质量第二道防线才是提示词约束。上下文过长的另一个常见诱因是文档去重没做好。同一个知识在多处被重复表述时检索器很容易返回高度相似的多条结果既浪费token又稀释注意力。入库前做一个基于标题或哈希的初级去重检索环节也可以加一个简单的相似度阈值过滤。另外推荐一个实用技巧在提示词里加入“反幻觉引导”。不要只写“不要编造”可以更直白地写如果参考内容不足以回答用户问题必须直接承认“资料不足”禁止拼凑或推测。你的输出只允许来自【参考内容】中的明确信息。实测这种带有明确失败路径的提示词比单纯说“要准确”效果好得多。4.3 本地知识库场景的特殊坑现在本地知识库是热门需求很多团队希望把RAG完全部署在内网把企业文档变成可检索资产。这个场景有几个独特的坑。第一是资源约束。本地部署embedding模型和rerank模型都很轻量真正吃资源的是生成侧的大模型。如果团队没有高配GPU我的建议是优先选量化版本模型并控制生成token上限。追求检索效果的话还可以把精排模型部署为独立服务保持灵活性。第二是数据格式五花八门。企业里的知识散落在PPT、会议纪要、流程图、Excel里每种格式解析难度都不一样。Excel尤其麻烦一行数据对应一个片段直接转文本会把结构信息丢掉。我一般会先把表格内容转成“键值对文字描述”再入库。举个例子一行“型号A300保修期24个月”我会转成“A300型号的保修期为24个月”这样才能被语义检索正确命中。第三是权限这个老大难问题。RAG只是知识获取管道它天然不懂权限检索出来的内容不会自动区分“这个人能不能看”。生产级落地时一定要在检索层加基于用户身份的元数据过滤如只能在属于该用户所属部门的文档范围内检索。这是个架构问题别留到上线前才处理。5. 从基础RAG走向Agentic RAG5.1 Agentic RAG和基础RAG的差别基础RAG是一个单次流程查询一次、检索一次、生成一次。这在问题简单、知识边界清晰时够用但Agent遇到的问题往往更复杂比如多跳问题“去年Q3退货率最高的产品它的新版定价是多少”这种问题要先去检索报表找到产品名称再拿着产品名去检索定价信息单次RAG做不到。Agentic RAG的核心变化是RAG的执行不再是一次性的而是由Agent根据问题特征动态编排整个检索过程。Agent自己决定是否要拆解问题、是否要用多个不同索引分别检索、是否要结合工具调用把检索结果再当输入去执行下一步。这种模式下RAG从一条管道升级成了Agent的一个能力组件和规划、工具调用协同工作。实现上并不神秘就是把RAG封装成可供Agent调用的工具函数然后依赖Agent的规划能力去决定何时调用、调用几次。LangChain里现在有专门提供agentic rag的模板核心模块包括查询改写、子问题分解、RAG工具封装、综合答案生成本质上是对基础RAG流程做了模块化改造。5.2 几个值得关注的演进方向聊到这块有几个方向经常出现在社区讨论里值得提一嘴。GraphRAG的思路是把文档里的实体和关系抽取出来构建知识图谱检索时不只看文本相似度还通过实体关联往外扩展。它结构信息更强适合全局性问题比如“这几个产品线之间的依赖关系”但成本明显高于普通RAG离线分析贵在线延迟高。Ontology RAG和GraphRAG有点类似但更强调预先定义的概念体系与关系类型。它不是纯靠模型抽实体而是基于一套业务本体建模再让内容对齐到本体上。好处是表达规范、可解释性强适合强领域逻辑的业务坏处是前期建模的人力成本不低。还有一类值得关注的是RAG as a Service把索引、检索、精排整个RAG能力封装成服务化API让上层应用像调用普通接口一样接进来。传统的LangChain4j和Spring AI都在往这个方向靠拢Agent开发只需要专注顶层逻辑不必每次从零搭索引。这条路径尤其适合需要在多个项目中复用同一套知识库的团队。5.3 实测下来的一些体会文章最后分享几个自己攒下来的经验当参考也当避坑指南。最大的一条体会是先建评测集再调RAG。我见过太多人花了一周时间调chunk_size和embedding模型但从来没定义过“什么样叫好”。至少准备三五十个真实问题标注好标准答案对应的文档片段后面所有调整都拿这组问题来衡量。没有评测集的RAG调参基本等于闭着眼睛开车。第二个体会是RAG参数的调整永远不要只动一个变量下结论。chunk_size和overlap是耦合的top-k和rerank也是耦合的单变量对比看起来科学实际上它们的交互效应很强。我习惯的做法是先用对照实验跑一个基线然后每次只调一组相关联的参数记录指标最后再做一轮组合调整。第三个体会是RAG的最终价值永远要放在Agent整体里评价。检索质量再好如果Agent不善于决定“什么时候该查”那也只是个空转的知识库。反之Agent的规划能力再强没有高质量的知识获取管道它的决策也是无源之水。基础RAG是一条具体的技术路径但它背后的知识获取管道设计才是Agent开卷考试能不能拿高分的关键。最后再分享一个很容易被忽略的小技巧上线之后一定要给RAG管道加检索日志。每次查询的实际检索内容和用户最终反馈都存下来定期抽样看一遍。这套日志是优化Agent知识方案最直接的原始素材很多你以为合理的设计翻日志才发现和用户实际问法完全不同修正一次就能显著提升检索命中率。