大家久等了。这个系列写到第四篇前几篇我们把 Agent 的主干聊完了从核心的 Planning规划、Memory记忆、Tool Use工具调用到 Agent 的骨架和运行机制。今天这篇专门补上 Agent 的“知识获取管道”也就是 RAGRetrieval-Augmented Generation检索增强生成。先给不熟悉的朋友一句话定位RAG 就是把“外部知识”接进大模型的管道。你不可能把公司内部文档、个人知识库、实时更新的行业资讯全部塞进模型参数里但你又想让 Agent 回答这些问题时不再是“一本正经地胡说八道”RAG 就是当前最主流、最务实的解法。这篇内容会从设计思路讲到核心流程再到一份可以直接抄作业的落地实现最后把我在实战里踩过的坑一起交代清楚。适合正在学 AI Agent、准备上手 RAG 项目或者已经跑通 demo 但觉得效果不理想的开发者参考。1. 为什么 AI Agent 需要 RAG知识获取的三个硬伤1.1 大模型的知识天花板堵死了 Agent 的路先看一个最根本的问题预训练语言模型的知识来源是它的训练语料。这个语料库有明确的截止时间也有明确的立场偏差——它只包含公开的、批量抓取的文本。当你让一个 Agent 直接回答“上季度我们公司华东区的销售额是多少”它大概率会编一个数字出来。这不是模型“坏掉了”而是它的参数里根本不包含这份数据。类似的问题还有企业内部维基、飞书文档、Notion 库里的私有知识模型完全没见过。法律条文修订、行业新规、产品说明书改版这类时效性极强的内容模型的快照落后于现实。涉及多个文档交叉验证的问题模型无法保证答案引用了正确的来源。在没有外部知识获取管道的情况下Agent 的“知识”就是模型脑中那套静态的、过时的、可能出错的记忆。这就是第一个硬伤知识天花板是硬的你用提示词再怎么绕也绕不过参数边界。1.2 幻觉问题Agent 亲自编造比模型编造更危险第二个硬伤才是压死骆驼的最后一根稻草。普通的聊天机器人产生幻觉用户可能只是觉得“这 AI 不太聪明”。但当 AI Agent 开始自动执行任务时幻觉会产生连锁反应。举一个我实际遇到过的例子当时做了一个客服工单分类 Agent让它根据历史工单库判断新工单应该流转给哪个部门。最初的版本没接 RAGAgent 凭“记忆”判断一个涉及发票税率的问题应该给财务部但公司上月的税务指引改过了新规明确这类问题要先进合规部。Agent 给出的理由看似完整但引用的是过时规则。这就是幻觉的可怕之处——它不是简单回答错了而是以一种“自信的、逻辑自洽的、难以察觉的”方式出错。在 Agent 场景里这种错误会直接导致下游操作跑偏且你很难在事后追查。反过来说RAG 解决幻觉问题的核心手段不是让模型“更小心”而是给模型一张可以翻开的“开卷考试材料”。材料上明明白白写着出处和原文生成时只需忠实引用和归纳即可。1.3 知识更新的需求Retraining 性价比太低你可能想那模型知识过时了直接重新训练微调不就完了问题在于一次全量微调的成本以十万到百万级美元计算周期以周和月计算。而企业的知识库每天都在更新任何一个敏捷型团队都不可能为了新增 20 份产品文档就去重新训练一次模型。RAG 的聪明之处在于把“知识”和“推理”解耦。知识放在可随时增删改查的外部数据库中模型只负责理解和生成。知识变了更新数据库即可不需要动模型的参数。这就像给一个专家配了一个实时更新的书架专家本人不需要把每本书背下来需要时抽出来看就行。1.4 这一篇在整个系列里的位置前几篇里我们搭建的 Agent 主干其实已经能完成“思考-行动-观察”的循环。但如果这个循环没有接入外部知识那它就像一个记忆力超群但没有资料库的实习生所有结论都只能依赖自己的臆断。这篇文章补上的“知识获取管道”就是让 Agent 从“瞎猜专家”变成“查证型助手”的关键一步。另外提一句现在很多人聊 Agentic RAG这个概念看起来很玄实际上就是 RAG 逐步和 Agent 的决策能力融合RAG 不再是一个固定流程固定检索、固定生成而是由 Agent 自行决定何时检索、检索几次、用不用工具验证答案。这一篇先把基础打牢最后一篇我会专门展开 Agentic RAG 的高级玩法。2. RAG 管道核心设计拆解索引、检索、生成三步走2.1 索引管线Indexing Pipeline先把资料整理成模型能用的格式所有 RAG 系统的第一站都是把杂乱无章的原始文档变成可供检索的结构化数据。这一步业内叫 Indexing Pipeline我通常把它拆成四个动作加载Load、切分Split、嵌入Embed、存储Store。加载没什么高深的无非是 PDF、Word、Markdown、HTML、数据库导出文件等格式的解析。但这里有一个我踩过无数次的坑PDF 的解析质量直接决定你 RAG 效果的上限。很多 PDF 是扫描件根本没有文本图层你用普通的 PyPDF2 提取出来的是乱码或空白。我现在的做法是优先转成纯文本再入库扫描件必须先用 OCR 处理。加载之后是切分Chunking这一步是最容易翻车的环节也是最值得花时间的环节。切分的目标是把长文档切成大小适中的“知识片段”既不能太大否则检索不精准喂给模型的上下文也容易爆也不能太小否则语义不完整检索出来也读不懂。我比较常用的切分策略是固定长度叠加重叠窗口。比如设置 chunk_size512、chunk_overlap50中文环境下大概就是每 400~500 字一个片段相邻片段有 50 字左右的交集。重叠的作用是防止一句话正好被从中间截断导致语义丢失。切分策略适用场景优点缺点固定长度切分技术文档、新闻、通用文本实现简单检索稳定可能切断段落语义不完整段落/标题切分Markdown、结构化文档保留语义边界检索质量高片长度差异大需额外处理语义切分Embedding 聚类书籍、长文、话题跳跃的文档按语义边界切分效果最好计算开销大实现复杂**嵌入Embedding**就一句话把文本片段变成一串向量数字让模型能计算“相似度”。这一步的选型直接决定了检索的上限。如果 Embedding 模型本身不擅长中文语义或者对专业领域的术语理解很弱那后面检索不管怎么调都是白搭。存储阶段则需要选一个向量数据库把文本片段和对应的向量一起持久化。可选方案很多我会在下一节单独对比。2.2 检索管线Retrieval Pipeline别让大海捞针真的去捞针索引建好后Agent 的实际请求会走另一条路检索管线。它的目标是拿到用户问题从知识库里找出一批最相关的文本片段作为上下文送给大模型。这里最朴素的做法是“向量相似度检索”把用户问题也转换成向量然后在向量数据库里找余弦相似度最高的 Top-K 个片段。这本质上是在高维空间里做“最近邻搜索”。这个方案能解决 80% 的需求但它有几个天然的弱点关键词/专有名词不敏感。Embedding 模型对拼写、缩写和高频专有名词的理解经常不够比如公司内部系统代号“FIDO”向量相似度检索很难把它和“财务发票验真系统”关联起来。意图复杂时效果差。用户的真实问题往往包含多层意图比如“老王上个月发给老李的那份关于预算调整的合同现在什么状态”这种问题如果只做一次向量检索结果往往不理想。无法感知文档结构和全局信息。单纯按相似度找片段容易忽略文档之间的关联关系和层级结构比如一份合同的条款和它的附件清单。所以实战中我很少只用“裸向量检索”。我会采用**混合检索Hybrid Search**策略向量检索 关键词检索BM25同时执行然后把两路结果用 RRFReciprocal Rank Fusion倒数排名融合合并。公式很简单就是把每个文档在两路结果中的排名倒数相加再按总分排序。这种方式能同时兼顾语义相似和字面匹配实测下来对专有名词多的合同、医疗、法务类知识库提升尤其明显。把检索结果喂给大模型之前还有一个容易被忽略的步骤重排序Reranking。向量检索和目标问题都转成了向量它们的相似度排序并不完全等于“真正的相关性”。用一个专门训练的 Reranker 模型对 Top-K 结果重新打分能够明显提升最终答案的准确性。目前主流方案是 cross-encoder 类的 Reranker中文可以用 bge-reranker-base/v2-m3效果比直接按向量相似度排序好上一截。2.3 生成管线Generation Pipeline把材料和问题一起端给模型最后一步反而最简单把用户问题、从知识库检索到的片段、以及一条明确的指令拼接成 Prompt送给大模型生成最终答案。这套 Prompt 的关键是让模型分清“事实”和“推断”。我个人常用的模板核心思想是先让模型基于给定的参考资料作答如果参考资料中找不到答案必须明确说“根据现有资料无法回答”绝对不允许自行编造。这就是 RAG 能大幅降低幻觉的原因——它给了模型一个“边界约束”让它清楚“我知道的边界在哪”。如果你的 Agent 需要快速响应、又对准确性有要求可以引入“引用溯源”机制要求模型在答案后面附上参考片段的 ID 或来源文档标题。这样一旦答案出错你可以快速定位是哪一份资料的问题而不是像以前一样面对一个黑盒答案无从下手。一条比较典型的 RAG Prompt 长这样你是一个严谨的 AI 助手。请仔细阅读以下来自企业内部知识库的资料并回答用户问题。 参考资料 {retrieved_chunks} 用户问题{question} 要求 1. 只能基于参考资料回答不得编造。 2. 如果参考资料不足以回答请明确回复根据现有资料无法回答该问题。 3. 回答末尾标注引用的资料编号格式为 [来源N]。2.4 一个直观类比RAG 就像一个查资料写报告的研究员说了这么多流程用一个大家都懂的例子收束一下RAG 的本质就是给一个“记忆力没那么好的专家”配一个“可以随时翻阅的图书馆”。专家接到一个问题先想“这问题需要在哪本书里查”然后去图书馆的书架向量数据库上按主题相关度找几本书检索翻到相关章节Chunk最后把章节内容和问题一起摆在桌面上基于这些材料写一份报告生成。没有 RAG 之前专家只能凭脑子里的记忆回答有了 RAG专家至少知道“这话是从哪本书的哪一页说的”错了也能追溯。这个类比能帮我们理解很多取舍。比如书架整理得好不好索引质量决定了专家找书快不快书摘做得细不细切分和 Embedding决定了专家能不能准确找到具体段落报告要不要标注出处引用溯源决定了这份报告可不可信。这是理解 RAG 全流程最高效的一个思维模型。3. 从 0 到 1 落地一个 RAG 管道实操笔记3.1 技术选型先别急着上框架想清楚自己需要什么RAG 的技术栈选择很多从全家桶到自组装都有。我根据自己的实践经历给你几个参考组合。如果你只是快速验证想法、以学习为主LangChain Chroma OpenAI 兼容接口是最顺滑的组合。LangChain 把加载、切分、向量化、检索、生成都封装成了标准组件你不需要关心太多底层细节。但注意LangChain 最大的坑就是版本升级快、接口经常变更网上很多教程已经失效了以官方文档为准。如果你在企业里做正式项目我现在的首选是LangChain4j 或 Spring AI 这类 Java 生态方案如果你的团队是 Java 背景这个生态这两年发展特别快RAG 几乎是开箱即用。如果是 Python 背景LlamaIndex 在做索引和知识库管理方面比 LangChain 更顺手对复杂的文档层级关系支持更好文档也更有章法。向量数据库的选型要看你的数据规模、部署环境和延迟要求向量库最适合的场景说明Chroma / FAISS本地开发、快速原型轻量Python 直接可用Chroma 带持久化Milvus / Qdrant生产环境、百万级向量支持分布式Milvus 功能全面Qdrant 更轻量pgvector已有 PostgreSQL 业务库不需要额外维护一套数据库简单够用Elasticsearch已有 ES 基础设施天然支持混合检索向量BM25用户成本低我自己的生产项目大多数选了pgvector 或 Qdrant。pgvector 的好处是团队不用学新东西业务数据已经在 PostgreSQL 里加个向量字段就行数据量到百万以上再迁到 Qdrant 或 Milvus。Embedding 模型这一块国内环境首选BGE 系列bge-large-zh-v1.5 或 bge-m3对中文语义理解扎实开源且商用友好。如果你想用 OpenAI 的 text-embedding-3-small效果也很好就是数据出境的问题要考虑清楚。我一般在本地/私有化部署场景无脑 BGE在云上且对英文能力有要求时再用 OpenAI。3.2 环境准备与依赖安装我们直接以 Python LangChain Chroma 为例跑通一个最小可用系统。保险起见 Python 建议 3.10 以上。# 创建虚拟环境 python -m venv rag_env source rag_env/bin/activate # 安装核心依赖 pip install langchain langchain-community langchain-openai chromadb pypdf # 如果用 BGE 模型做本地嵌入再加这两个 pip install sentence-transformers这里提醒一句langchain 的版本是大型“坑区”我写这篇时 0.3 系列的 API 是最稳定的。安装后建议立刻跑python -c import langchain; print(langchain.__version__)确认版本。否则你照着博客抄代码时会发现很多类被移动了位置会浪费大量时间在排查 ImportError 上。3.3 索引管线代码实战从一份 PDF 到向量库我们以一份本地的《员工差旅报销制度.pdf》为例演示完整流程。from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载 PDF loader PyPDFLoader(employee_expense_policy.pdf) documents loader.load() print(f加载了 {len(documents)} 页文档) # 2. 切分文档 text_splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) chunks text_splitter.split_documents(documents) print(f切分得到 {len(chunks)} 个文本块) # 3. 生成 Embedding embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True} ) # 4. 存入 Chroma 向量库 vectorstore Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db )几个细节展开说一下第一切分器的separators参数决定了优先按什么边界切。我建议中文场景下优先用“换行、句号、分号”这种自然语义边界而不是纯按字符硬切。RecursiveCharacterTextSplitter会按照你提供的分隔符优先级递归尝试直到找到合适大小的块这是目前中文兼容性最好的方案。第二normalize_embeddingsTrue一定要加。bge 系列模型官方建议在计算相似度前做向量归一化否则余弦相似度的结果会不准确。这个细节很多人不知道导致检索效果莫名变差。第三persist_directory./chroma_db指定了向量库的持久化目录。下次运行直接从磁盘加载不用重新灌一遍数据。3.4 检索与生成代码实战让你的 Agent 学会“查资料再回答”索引建好之后接下来的检索和生成代码非常简洁。# 1. 加载已有向量库 vectorstore Chroma( persist_directory./chroma_db, embedding_functionembedding_model ) # 2. 构造检索器Top-K 4 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 3. 组装 RAG Prompt使用 LangChain 的 ChatPromptTemplate from langchain_core.prompts import ChatPromptTemplate prompt_template ChatPromptTemplate.from_template( 你是一个严谨的 AI 助手。请仔细阅读以下来自企业内部知识库的资料并回答用户问题。 参考资料 {context} 用户问题{question} 要求 1. 只能基于参考资料回答不得编造。 2. 如果参考资料不足以回答请明确回复根据现有资料无法回答该问题。 3. 回答末尾标注引用的资料编号格式为 [来源N]。 ) # 4. 调 LLM 生成答案 from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini, temperature0) def rag_query(question: str) - str: # 检索相关片段 docs retriever.invoke(question) context \n\n.join([f[来源{i1}] {doc.page_content} for i, doc in enumerate(docs)]) # 交给大模型 chain prompt_template | llm response chain.invoke({context: context, question: question}) return response.content # 测试 print(rag_query(员工出差每天的餐补标准是多少))这段代码就是一个最小可用的 RAG 闭环。retriever.invoke(question)会完成向量化、相似度检索、Top-K 排序的全部过程返回最相关的 4 个文本块。prompt_template里的 {context} 和 {question} 就是 2.3 节里说的“把材料和问题一起端给模型”的落地实现。3.5 一个更进一步的实践用混合检索把命中率拉高 20%纯向量检索在真实场景下尤其在专有名词、人名、型号、内部编码遍布的知识库里经常会出现“找是找着了但不是最想要的那几段”的尴尬。解决方式就是上混合检索。LangChain 生态里融合向量检索和 BM25 的典型写法如下from langchain.retrievers import BM25Retriever, EnsembleRetriever # 假设你已经有了 chunks 原始切片 bm25_retriever BM25Retriever.from_documents(chunks, k4) vector_retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 混合检索两路结果用 RRF 融合 hybrid_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.3, 0.7] # BM25 权重略低但参与排名融合 ) # 用这个混合检索器替换原来的 retriever docs hybrid_retriever.invoke(question)注意weights这个参数向量语义检索通常是主导但关键字精确匹配在专有名词场景下有奇效所以给 BM25 留 0.2~0.3 的权重是比较合理的配置。我自己的经验是加了混合检索之后内部编码类查询的命中率能提升 20% 以上这个优化几乎零成本强烈建议在生产环境直接默认开启。如果你有条件上 Reranker强烈推荐在混合检索之后再加一层。最常见的做法是取两路融合后的 Top-10 或 Top-20 候选然后交给 bge-reranker 重新打分最后取 Top-4 喂给大模型。成本会高一些但答案质量能再上一个台阶特别是处理“答案藏在文档深处”的问题时优势很明显。4. RAG 实战中最常见的坑与排查思路4.1 命中率低、检索不到相关内容怎么办这是所有 RAG 使用者第一个遇到的头疼问题。明明知识库里就有答案模型却说“根据现有资料无法回答”。其根因往往是检索环节没起作用而不是生成环节出了问题。第一个排查方向是切分粒度。如果 chunk_size 设得太大比如超过 1000 字每个片段都是一个大杂烩向量被平均化检索时很难精准命中答案所在的小段落。反过来如果 chunk_size 太小语义又不完整检索器可能根本理解不了这个片段在说什么。建议先用 512 ± 100 的区间做几轮实验观察“人工标注的正确片段”是否出现在 Top-5 结果里。第二个排查方向是Embedding 模型的领域适配性。通用 Embedding 模型在专有领域法律、医疗、企业内部黑话经常表现不佳。建议直接对比测试找几对“问题-正确片段”分别计算向量相似度看分数是否明显高于不相关片段。如果相似度普遍偏低或差异化不明显果断换领域微调过的模型。bge-m3 是 bge 系列里一个不错的选择多语言和长文本支持都很好。第三个排查方向是查询词和文档用语不匹配。用户常会说“报了多少钱”文档里写的是“报销金额”字面差距大导致向量相似度低。除了混合检索兜底还可以加一个轻量的“查询改写”步骤在检索之前用一个便宜的 LLM 把用户问题改写为更正式、更适合检索的表述。4.2 答案引用了错误资料、胡编乱造如何规避如果你的 RAG 已经能回答出一段内容但内容和正确文档对不上那问题往往出在“上下文污染”。最简单的情况是检索 Top-K 里混入了几条不相关片段模型被带偏了。解决办法是适当调低 K 值从 5 降到 3或者加入相关性阈值只保留相似度高于某个值的片段。还有一种隐蔽的情况是Prompt 约束失效。有些模型面对参考资料时会“自由发挥”尤其是当你用的 LLM 指令跟随能力一般时。我建议在 Prompt 中明文写清答案必须能从给定的参考片段中直接找到依据。参考资料相互冲突时优先选择最近的文档内容并在答案中说明冲突。如果所有参考片段都不相关直接回复“无法回答”不要尝试强行使用参考材料。最后一条更保险的建议永远保留引用溯源。让模型在生成时返回每个句子的证据来源这样一旦出错了你能立刻定位是检索环节“没搜到”、还是生成环节“用错了”而不是对着黑盒输出猜原因。4.3 多轮对话场景下上下文丢失如何处理Agent 的核心就是多轮对话。但 RAG 如果只处理单轮问题用户说“那如果出差天数超过 7 天呢”这种追问题时模型就懵了——它不知道“那”指代的是什么。目前主流做法是“对话历史压缩 查询重写”。具体来说在进入检索之前先把“对话历史 当前用户问题”一起送给一个轻量 LLM让它改写成一个独立的、包含完整上下文的检索查询。比如用户问“那如果超过 7 天呢”改写结果是“员工出差超过 7 天的情况下差旅补贴标准是什么”。用这个改写后的查询去做 RAG命中率会显著提升。另一个经验是把 RAG 检索和对话记忆分开管理。对话历史放进独立的短期记忆里RAG 知识库只管静态文档。不要让历史对话污染向量检索的上下文不然会出现“上轮聊的技术方案关键词拉低了这轮财务问题的命中率”这种诡异效果。4.4 RAG 评估别凭感觉调参先量化再决策最后一个我想重点呼吁的任何 RAG 项目先建立评估集再谈优化。不要靠“我觉得效果好多了”来调参数。我的做法是从知识库里抽样 30~50 个问题每个问题标注出对应的正确答案所在文档 ID建成一个简单的黄金评估集。每次改切分参数、换 Embedding 模型、调 K 值都用这同一套评估集跑一遍记录 Hit Rate正确答案是否出现在检索到的 Top-K 片段中和最终答案的准确性。Hit Rate 是检索环节最核心的指标在 Top-K 结果中有多少比例的问题成功召回了标注的正确片段。这个指标至少能帮你客观判断“检索到底行不行”。再配合最终答案质量的人工评估就能把“优化”从玄学变成可量化的工程迭代。4.5 一个常见问题速查表为了方便你排查我把上面提到的问题汇总成一张速查表常见问题可能原因解决方案检索不到正确答案切分粒度太大/太小调整 chunk_size 与 overlap做网格搜索检索结果杂乱文档格式解析失败检查 PDF 是否有文本图层必要时上 OCR专有名词/编码找不到向量检索字面匹配弱启用 BM25 向量的混合检索回答与资料矛盾K 值过大、上下文污染降低 K 值引入相似度阈值过滤多轮追问答非所问未做查询改写用 LLM 将对话历史改写为独立查询无法判断优化效果没有评估集建立黄金评估集统计 Hit Rate5. Agent 与 RAG 结合的进阶思考从基础管道到 Agentic RAG5.1 基础 RAG 只是第一步Agent 化才是目标前面讲的所有内容本质上是“单轮查询”的 RAG用户问一个问题系统检索一次生成一次回答。但在真正的 Agent 场景里问题要复杂得多。比如用户问“帮我对比一下今年和去年差旅政策的主要变化并告诉我哪些调整影响了我的报销金额”这种问题如果只做一次检索很难一步到位。Agent 化 RAG 的做法是Agent 先判断“这个问题需要读两份文档可能需要多轮检索”于是第一步检索今年的政策第二步把“去年政策”作为关键词再检索一次文档库第三步用工具对比两个文档的差异最后组织答案。这个过程中Agent 自主决定检索次数和检索策略而不是遵循固定的“检索一次完事”模式。这就是前面提到的 Agentic RAG 的核心。“Agentic”不是指“更高级的 RAG”而是指“RAG 从固定管道演变成 Agent 的一项能力”。Agent 手里原本只有 planning、memory、tool use现在多了一个新工具知识检索与引用。5.2 Skill 和 RAG 怎么结合最近不少人问我“skill 怎么和 RAG 结合起来”。Skill 本质上是一个封装好的指令和工具集RAG 本质上是一种知识获取机制。结合方式其实很自然把 RAG 做成 Agent 的一个 Skill 或工具比如 retrieve_from_knowledge_base同时让它作为其他技能执行的“前置条件”。举个例子一个“合同审查 Agent”的 Skill 是“审查合同中的风险条款”。执行这个 Skill 前它会先调用 RAG 检索企业自己的合同模板库和历史合规案例把检索结果作为审查的依据。另一个“日报生成 Agent”则会在生成日报时如果检测到用户问到了不熟悉的数据自动调用 RAG 从项目数据库中检索相关进度记录。RAG 从“整个系统的外挂”变成“Agent 工具箱里的一个趁手工具”是 Agentic 架构下 RAG 的必然走向。5.3 一个我常用的 Agentic RAG 微模式先路由再检索在不需要引入复杂 Agent 框架的情况下我最常用的 Agentic RAG 微模式是“路由 分治”。先让 Agent 判断用户问题属于哪个子知识库比如“差旅制度”还是“报销流程”还是“绩效规则”然后只去对应的子库做向量检索。这样有几个明显的好处子库内的文档更聚焦向量相似度噪声更小检索时不需要大量混入无关领域的候选片段用户问题本身给出了范围限定命中率反而上升。这个路由既可以靠 LLM 判断也可以靠简单关键词规则。如果你只有一个几十万规模的向量库用 LLM 做智能路由的性价比极高如果知识库规模很小甚至可以跳过路由直接全局检索。同样Agent 可以自行判断“要不要检索”。如果用户的问题是纯开放式的闲聊或头脑风暴就没有必要强行走 RAG 管道直接让模型自由发挥即可。这也是 Agentic RAG 和固定 RAG 的一个显著区别检索不再是必然发生的动作而是根据情形动态调用的工具。5.4 展望RAG 已死RAG 永生业内最近有声音说“RAG 已死”因为长上下文模型的出现让“把所有文档塞进 Prompt”变成了可能。但我不太认同这个判断。长上下文确实解决了部分问题但它的代价是成本高、上下文一长模型注意力会分散、而且每次都要重新传输全部上下文。我觉得更准确的表述是“朴素 RAG 进入平台期RAG 以 Agent 化的形态继续进化”。不管未来模型上下文能到多大知识库和生成模型的解耦这个架构思路都不会过时。文档还是要管、知识还是要更新、引用还是要追溯这些恰恰都是 RAG 管道在承担的工作。对开发者来说与其追逐“RAG 会不会死”的话题不如先把管道本身夯实把检索质量、评估方法、工程化能力练扎实这些基本功在任何一代架构里都不会浪费。6. 从一个“学员踩坑”到“管线心态”写在最后的实操心得这几年带过不少朋友入门 RAG也做过不少咨询项目一个非常明显的现象是很多人跑通一个 LangChain demo 就以为“RAG 学会了”遇到生产问题后立刻陷入“为什么效果这么差”的迷茫。如果你要问我有什么最核心的建议我会说一句——把 RAG 当管线来研究而不是当脚本调试。管线意味着系统性看待每一个环节文档解析的完整度、切分粒度的合理性、Embedding 的领域适配性、检索策略的多样性、Reranker 是否需要、生成时的指令约束、评估集的建立。任何一个环节掉链子最终答案都会失真而且往往是“看起来没问题、实际错得离谱”。我自己做项目时甚至会单独为每个环节写一个评测脚本确保每一步的输出质量是可控的。另外我在实际落地中还有一个非常强烈的心得先建评估集再动任何参数。没有评估集就盲目调参就像没有仪表盘的汽车在夜里狂踩油门——你感觉自己在飞速优化实际上可能一直在原地打转。哪怕你的评估集只有 20 条真实问题也足以支撑你在“切分粒度”、“K 值大小”、“是否加 Reranker”这些关键决策上做出理性判断。最后再分享一个小技巧当你看到检索质量一直上不去时先别急着换模型。把知识库里真实命中的那几条片段拉出来逐条问自己“为什么这条片段会被错误地排到前面”——十次里有七八次你会发现问题出在切分策略或文档本身的结构上而不是向量检索不够聪明。先修数据再调算法这条路永远不会错。RAG 这一篇就写到这。下一篇我会接着聊 Agent 的工具系统怎么设计函数调用、怎么把外部 API 包装成 Agent 的“手脚”以及工具调用的错误恢复机制。那个话题排在这个系列里正好和今天这篇形成互补——知识进得来动作出得去Agent 才真正完整。