人这一整年有一个体会越来越深做AI Agent真正拉开差距的不是模型选得多强、不是Agent框架用得有多花而是它能不能在关键时刻拿到它该知道的那些知识。模型自带的知识是死的有截止日期、有偏见、还会一本正经地胡编Agent要落地到具体业务里必须有一套自己的“知识获取管道”把外部资料变成它随时能查、能引用、能作为决策依据的东西。这条管道最基础、也是最成熟的做法就是RAGRetrieval-Augmented Generation检索增强生成。这篇是这个系列的第四篇前面几篇我们把Agent的“思考”和“行动”都聊过了这篇专门补上“记忆”和“知识”的短板。无论你是刚从零开始搭Agent还是已经在写业务代码这篇的定位都是把RAG这条路讲透——它不是让你跑通一个Demo就行而是帮你理解为什么RAG能解决Agent的知识问题、它在工程上到底怎么落地、以及哪些环节最容易被忽视。1. 为什么Agent必须有自己的“知识获取管道”1.1 模型脑子里的知识本质上是一份“压缩过且过期了”的百科先从一个反直觉的事实讲起你问任何一个大模型“今天天气怎么样”它如果没接工具它就答不上来你问它“我们公司上季度的销售数据是多少”它大概率会顺口编一个。原因很简单——模型训练好之后它的知识就冻结了。它的知识来自训练语料是那批语料经过数千亿参数压缩后的结果。它知道“唐朝建立于618年”这种通识但不知道你昨天新加的文档里写了什么。这个“冻结”特性带出两个致命问题时效性差训练截止时间之后的事它一概不知道。就算模型厂商每月更新也追不上业务里每天都在变的数据。可靠性差它不是“查”知识而是“猜”知识。你问一个冷门问题它可能把相似问题的答案混在一起说出来而你根本分辨不出来。所以想让Agent处理真实业务你不可能指望它脑子里那点“百科知识”。你需要一条管道把外部资料在需要的时刻取回来喂给模型让它“看着资料说话”。这就是知识获取管道存在的根本原因。1.2 RAG在整个Agent体系里到底扮演什么角色前面几篇聊过Agent的核心能力是“思考”和“行动”。但请大家扪心自问一套系统里如果思考没有可靠的信息输入思考质量能有多高这就像一个分析师脑子再快如果手上的报表全是假的、过期的他分析出来的结论你敢信吗RAG解决的问题恰恰就是“让Agent的判断建立在真实、新鲜的资料之上”。在Agent体系里RAG通常被归入记忆模块下的外部知识这一层。它与Agent内部记忆的区别在于维度Agent内部记忆对话上下文RAG外部知识来源用户跟Agent的对话历史文档、数据库、API、知识库生命周期短对话会话内有效独立于对话长期有效存储形式消息列表、token序列向量库、倒排索引、关系库获取方式直接取最近N轮按需从大规模资料中检索放在一个具体例子里就更清楚了。你做一个客服Agent用户问“订单退款的截止时间是多久”。如果Agent只靠内部记忆它只能根据刚才聊的几句猜如果配上RAG它会去公司的退款政策文档里检索相关条款然后基于条款原文回答。同样一个Agent前者是“蒙”后者是“有据可查”业务方要哪一个不言而喻。1.3 搞懂RAG是通往Agentic RAG和更复杂架构的必经之路最近“Agentic RAG”这个词很热很多人一上来就研究怎么让Agent自主决定查哪个库、怎么拆解复杂问题、怎么迭代检索。但我个人的观点是没把基础RAG的每个环节吃透之前谈Agentic RAG就是空中楼阁。这一类进阶架构本质上是在基础RAG的管道上增加了“决策层”——Agent来决定检索哪些源、检索几轮、如何评估检索结果够不够。所以这一篇把最基础的那条管道讲扎实。下一篇再谈怎么再把“管道”升级成“Agent自主检索”。2. 一次性看懂RAG核心流程索引、检索、生成三段拆解2.1 整条管道的全景图先刻在脑子里RAG听起来玄乎但骨架极其简单就三步先把你有的资料准备好索引→ 用户问问题时把相关片段捞出来检索→ 让模型看着片段回答生成。用一个比喻帮助记忆RAG就像你去图书馆借书。你先把全馆的书按科目编好号放上书架索引有人来咨询问题时你根据问题去书架查找到几本最相关的书检索然后把书翻到对应章节摘出关键段落给咨询者组织成答案生成。这一整套下来就是一套完整的知识获取管道。需要提前说清楚的是索引是离线的检索和生成是在线的。索引阶段你跑一次批量任务把几万份文档切块、编码、存入向量库这个流程不要求实时检索和生成则必须发生在用户提问那一刻对性能要求极高。我在实际项目里见过不少新手把这两个阶段混在一起结果每次新增文档都实时处理一遍导致系统慢得不堪忍受——这个问题下文还会细说。2.2 索引阶段从一堆原始文档到“可检索的库”索引阶段做的事情是把无结构的原始文档PDF、Word、Markdown、数据库记录等变成结构化的、可被快速检索的条目。典型流程包括四个步骤文档加载Load用解析器把不同格式的文件读进来变成纯文本或结构化文本。PDF要处理排版错乱表格要单独抽取这一步的坑在各大格式之间都不小。切块Chunking把长文档切成若干小片段。为什么必须切因为向量检索的语义匹配是看“片段级相似度”一整本几十万字的书直接做Embedding不仅消耗惊人而且没有任何语义区分度。具体切多大下文会专门展开。嵌入Embedding用Embedding模型把每个片段变成向量。可以理解成给每本书贴了一个“索书号”只不过这个索书号是几百维的浮点数数组语义相近的文本向量也相近。入库Store把向量和其他元数据来源文档、页码、章节标题等存进向量数据库并建立好索引。2.3 检索阶段拿到用户问题快速召回“高度相关”的片段用户提问的那一刻系统要做的就是把问题变成向量去向量库里找一批“离它最近”的片段。这个阶段看似简单实则是最容易被低估的。很多初学者以为“做了Embedding扔进向量库查一下距离完事”但实际应用里有几个绕不开的问题用户问题通常很口语化例如“那个退款怎么弄啊”而文档里的表述是“退款申请需在签收后七日内提交”。语义相近但字面完全不同仅靠向量语义匹配可以解决一部分但不完全够。向量检索召回的结果可能多而杂前20个里可能只有两三个真的有价值剩下都是“沾边但不相关”的噪声。不同来源的文档可能包含互相冲突的内容检索出来了生成时模型不知道该信谁。所以检索阶段实际工程里往往不是“一次向量查询”这么简单而是“向量召回 关键词召回 重排”的一个组合拳。这个我在第4节会展开讲。2.4 生成阶段模型拿到“证据”后组织回答生成阶段就是把你召回的片段、对话历史、原问题一拼塞进Prompt里让模型回答。关键要点在于你要在Prompt里明确告诉模型“优先使用参考资料里的内容”还得告诉它“如果参考资料里没有就明说不知道不许编”。这里有个容易被忽视的细节RAG不是让模型“参考”资料而是让模型“紧紧盯住”资料。很多时候生成效果差不是检索没召回到正确答案而是Prompt压根没约束住模型模型自己“发挥”了一段。至于Prompt具体怎么设计第5节我会给出一个可复用的模板。3. 切块与嵌入决定检索质量的两个工程细节3.1 切块大小怎么选这是一个需要反复试出来的参数切块这个环节看起来就是个“按长度切文本”但它在RAG系统里的影响力几乎和选哪个大模型一样大。切太小单个片段缺乏上下文语义不完整切太大一个片段里塞了太多无关信息向量被稀释检索精度会急剧下滑。我在实际项目里的经验是没有万能值只有适合你的文档结构和业务场景的区间。给个参考范围场景推荐切块大小字符重叠字符理由问答型FAQ碎片300-50050每个问答本身就是独立单元切太大会混入其他条目技术文档、操作手册800-1200100-200需要保留完整步骤的语境长文、论文、报告1500-2000200语境依赖强太碎会丢失论证链条重叠Overlap的作用是防止某个关键句子正好落在两块的边界上被切碎。重叠这块没有标准答案但有一条原则重叠量建议是切块大小的10%-20%。我自己通常从800字切块、100字重叠起步先跑通再看检索命中率调。还需要观察一个现象切块策略和Embedding模型的上下文窗口是联动的。早期的Embedding模型如text-embedding-ada-002最大输入长度有限切块大小超过上限就直接报错现在很多开源模型窗口长了很多项目就把切块往大了调但检索效果不一定更好——因为长句子的语义向量会被肚子里那些无关紧要的词干扰。我最近在做一个运维文档问答项目把切块从1500降到1000检索命中率反而提升了。3.2 结构化切块按标题、章节、语义边界来切按固定字数切是最简单的做法但它在处理有结构的长文档时经常犯蠢。比如一份技术文档第一章讲“安装”第二章讲“配置”固定切块很容易把两个章节的内容混到一个块里。更稳的做法是优先利用文档本身的结构先解析标题层级H1/H2/H3按章节边界切每个章节太长再按段落切段落还太长再按句群切。这种“层级切块法”能保证每个片段内部在语义上是相对完整的检索回来的内容也更自然尤其是带Markdown或HTML结构的文档特别适合这么干。说到结构顺便提一个很常见的需求表格怎么存RAG知识库。热搜里有人问“系列产品表格怎么存入RAG知识库”这里给个经验表格不要直接作为大块文本切进去而是先转成每行一条的方式用“表头行内容”作为一条切块单元。比如一张产品参数表把表头“型号, 尺寸, 重量, 功率”拼上每行数据形成若干条“产品事实”再入库。这样用户问“型号A的尺寸是多少”时检索到的就是整行完整信息而不是一个残缺的表格碎片。3.3 Embedding模型选型不同模型对中文、专业领域的支持差距很大切块切完之后每个块都要过一遍Embedding模型。这里有一个很多人踩过坑的地方Embedding模型对语言的敏感度特别高。有些在英文上表现很好的模型放到中文上效果直接对半砍反过来也一样。选Embedding模型时我的建议是从三个维度评估中文支持度务必拿你自己的中文测试集跑一遍相似度检索看看同义句能不能被召回。网上找几个通用中文测试集也行但不能不看中文效果就选。维度与存储开销向量维度越高单条占用的存储和检索成本越大。常见的有768维、1024维、1536维这些对效果有影响但决策权不必优先放在这里。本地部署 vs API调用API的Embedding模型一般效果好、不用管运维但涉及敏感数据时不能用。本地部署开源模型如bge-m3、text2vec这一类是很多政企和本地知识库项目的选择。效果上bge-m3在中文检索里口碑不错个人体感比更早的text2vec-large-chinese要强一截。另外别忽略一个重要事实RAG系统里对Embedding模型的选择应当和检索质量的评估绑定在一起看。我们公司有个项目由于没有做任何Embedding模型的评测对比直接用了默认的通用模型上线后检索召回率只有60%出头后来换了针对中文优化的模型召回率提升了近20个百分点。这一换比调任何Prompt都立竿见影。4. 检索不止相似度元数据过滤、混合检索与重排4.1 向量检索的天然短板它不“识字”它只看“语义距离”大多数人对向量检索的理解是把问题和文档都转成向量然后算余弦相似度取Top-K。这个理解没错但它的局限性常常被忽略向量检索没有绝对的筛选能力它只有“近似度排序”能力。什么意思举个例子你的知识库里有一份《员工手册》和一份《产品退换货政策》用户问的是“退换货时间”纯粹用向量检索可能把员工手册里“试用期多久”这种句子也召回来因为它们都说到了“时间”这个概念。你真正需要的是“只从退换货政策文档里找答案”。这个问题的解法很简单很暴力在索引阶段给每个片段打好元数据标签在检索阶段先按元数据过滤再做向量相似度计算。元数据可以包括来源文档类型、部门、日期、版本、角色适用于管理员还是普通员工等。比如你在知识库里给所有文档标注了category: 退换货那检索时就先加一个filter: category 退换货直接砍掉其他噪声。我见过太多项目把这种过滤直接扔掉不用所有文档混在一个库检索结果五花八门。哪怕你的向量库再强也扛不住“什么都有”的库。元数据过滤是基础RAG里最能立竿见影提升精度的工程手段是RAG基础中很重要的一环。4.2 混合检索为什么要把“精确匹配”救回来另一个被很多人忽视的问题是纯向量检索对“精确关键词”是无能为力的。比如用户问“如何取消订阅”而文档里写的偏偏是“退订”——“取消订阅”和“退订”在向量上可能有一定关联但靠那点模糊关联不如关键词检索直接命中的“退订”可靠。成熟的RAG框架如LangChain、LlamaIndex里通常都有混合检索Hybrid Search的概念向量检索负责语义关键词检索负责字面命中。常见的做法是BM25加向量检索并行跑两边各取一批结果再做合并去重。有个细节混合检索不是简单地“把两个结果加在一起交出去”而是要处理好分数归一化问题。因为Vectorscore和BM25的分数量纲完全不同直接相加某一方会吞掉另一方。实操上通常先用Min-Max归一化把两边分数压到0-1区间再按权重融合比如向量0.7、关键词0.3也可以先各取Top-N再合并后交给重排模型统一打分。4.3 重排Rerank从“差不多相关”里挑“真正对口”的Top-K召回回来的片段质量是参差不齐的。很多工程方案会再加一个重排环节用一个小而精的Cross-Encoder模型把用户问题分别和每个候选片段拼接成一对输入重新计算“问题-片段”的相关性分数然后去掉那些虚高的向量邻居。讲一个我实际遇过的案例。某个项目向量检索Top-5里其实已经含有正确答案但正确答案排在第4位前三个都是“语义沾边但不对题”的内容。没加重排时模型拿到的上下文里有太多干扰回答了错误的内容加了重排之后正确答案被提到第1位回答立刻对了。从那以后我在任何一个稍大一点的RAG项目里都不会跳过重排环节。重排模型的成本不高但对答案质量的提升非常显著。4.4 检索环节的代码视角一个不复杂的伪代码为了让整个流程更直观我用伪代码把检索阶段串起来。这里用Python风格的写法def retrieve(question, top_k8): # 1. 向量召回问题过Embedding得到向量查询向量库 question_vec embedding_model.encode(question) vector_hits vector_db.query(question_vec, top_ktop_k) # 2. 关键词召回BM25精确匹配 keyword_hits bm25_index.search(question, top_ktop_k) # 3. 合并与去重 candidates merge_and_deduplicate(vector_hits, keyword_hits) # 4. 元数据过滤按业务维度裁剪 candidates filter_by_metadata(candidates, category_filter) # 5. 重排用cross-encoder重新精排 reranked reranker.rerank(question, candidates) # 6. 截断返回最相关的片段 return reranked[:5]很多框架把这些步骤封装成了现成的检索器但懂了底层逻辑之后出了问题才知道去哪排查——是向量库没召回到是关键词没命中还是重排把正确答案压下去了。这些环节从日志里一步步看很快能定位到症结。5. 生成段的设计把“证据”变成“答案”5.1 上下文组装不是把检索片段“堆”进Prompt就完事检索到片段之后下一个关键动作是把它们组织成Prompt里的上下文。这里最容易犯的错有两个一是把五六个片段不加区分地全部拼接导致模型被冗余信息干扰二是不告诉模型这些片段里谁优先模型只能自己“看着办”。正确的组装方式我的做法是按相关性排序最相关的放最前面。大模型对上下文前部的注意力普遍更强这个顺序直接影响答案质量。给每个片段标注来源格式可以简单如[1] 来源《用户手册》第三章这段在生成时常被用来做引用溯源。用分隔符把片段和系统指令、用户问题分开。常见的做法是 参考资料 和 用户问题 这种明确边界让模型知道“什么是给它参考的、什么是需要回答的”。5.2 Prompt模板一个实战里我反复用的写法下文给出一个经过多个项目验证的Prompt骨架你是一个基于参考资料回答问题的助理。 请优先使用参考资料回答用户的问题如果参考资料不足以回答请直接回答“资料中未找到相关信息”不要编造。 要求 - 回答尽量精简关键信息不遗漏。 - 如引用了参考资料的内容请在句末标注来源编号如[1]。 - 禁止把资料中没有出现的信息当作事实陈述。 参考资料 [1] {chunk_1_content} (来源{doc_title}, 第{x}页) [2] {chunk_2_content} (来源{doc_title}, 第{x}页) ... 用户问题{question}看到没有这个模板的核心不是花哨的“角色扮演”而是三件事限定使用范围、强制标注来源、禁止无中生有。很多生成效果差的项目上一查Prompt压根没做这三层约束模型当然自由发挥。5.3 多轮对话里的RAG怎么让追问不丢上下文热搜词里有“RAG多轮对话怎么设计”这题确实值得单独讲一下。RAG最理想的形态是你问我答、一次结束。但在客服、医疗、法律咨询等场景里用户会追问“那如果超期了呢”“再比如我是在京东买的怎么办”——这些追问本身没有完整上下文直接拿去检索效果惨不忍睹。业界常见的处理方式叫查询改写Query Rewrite在检索动作之前先让大模型把“当前用户问题 最近几轮对话”压缩成一个独立可检索的问题。举个例子用户订单退款要多久到账 助手一般3-5个工作日。 用户那如果遇到节假日呢 改写后检索问题节假日期间订单退款到账时间是否有变化这个改写后的查询再送去检索而不是把原始追问送去检索。我在项目里实测加了这层改写之后追问场景的检索命中率能提升不少。LangChain的MultiQueryRetriever也是类似思路把原始问题从不同角度生成多个查询再合并检索结果降低“一次查询表达不准确”的风险。5.4 兜底策略检索不到答案时宁可沉默也别硬编最后再强调一下兜底。RAG系统的检索结果不可能永远完美总有召回不到正确答案的时候。这时候系统该怎么表现直接决定了产品可靠性。我最推荐的兜底策略是设定一个相关性分数阈值检索结果低于阈值时不让模型硬答而是让它回答“资料库中没有找到相关答案”。给Agent设计一个“换一种方式问”的建议比如反问用户“你能提供更多上下文吗”。或者触发下一步动作比如转人工客服场景、重新检索另一个知识源进阶Agentic RAG。总之不能设计成“检索什么就答什么、检索不到也硬凑”这是RAG产品被用户骂“胡说八道”的最大源头。6. RAG和MCP是两件事别混着聊6.1 为什么这两个词总被拿到一起说最近RAG和MCPModel Context Protocol模型上下文协议经常被放在同一个话题里讨论。原因也好理解它们都出现在大模型应用开发的热门时间窗口而且都是“让模型拿到外部信息”的手段。于是很多初学者产生困惑我有了RAG是不是就不需要MCPMCP会不会取代RAG我的回答是它们解决的问题压根不在一个平面上谈不上谁取代谁。6.2 用一张表说清两者的分工维度RAGMCP本质一种组织并检索知识的方法一种连接模型与外部工具的通信协议解决什么模型缺乏特定知识时如何从知识库取回资料模型需要调用外部系统能力时如何标准化对接输入输出输入问题输出文档片段输入工具调用请求输出工具执行结果典型场景问答、客服、文档分析调用数据库、浏览器、办公软件接口生命周期离线建索引 在线检索生成每次调用实时协商和执行举个例子一个客服Agent用户问“我的订单到哪了”——这个场景如果走RAG它去FAQ文档里找“查物流”的说明如果走MCP它可以直接调用订单系统的查询接口传入订单号拿回真实物流数据。所以两者的关系其实是互补的。你在一个Agent系统里完全可同时拥有两边遇到静态知识类问题走RAG查知识库遇到需要操作实时系统的动作走MCP调接口。说“MCP会杀死RAG”的人多半还没有把业务场景拆到这一层。6.3 两者在Agent搭建中的实操选择我一般跟团队的建议是你的知识藏在文档里且不需要操作外部系统RAG就够别画蛇添足上MCP。你的Agent需要“做事”比如查订单、发消息、改配置上MCP让Agent具备工具调用能力。你的Agent既要知道“规则”又要执行“操作”两个一起上有条不紊地配合起来。这些判断是在你动手搭Agent之前就要想清楚的否则做完架构再改成本会翻好几倍。这也是为什么我觉得在学MCP之前先把RAG这块地基打牢比追新概念重要得多。7. 从基础RAG到Agentic RAG这一步是很多人的“进阶必答题”7.1 基础RAG的三个天花板基础RAGNaive RAG在真实场景中会遇到三个绕不开的瓶颈检索一次定生死问题复杂时一次查询往往找不到全部必要信息。不做判断系统不评估“当前检索到的资料够不够回答”反正拿回来就生成。拆解能力缺失用户问一个复合问题如“新员工的社保流程和请假流程分别是什么”基础RAG可能只找到其中一段。这就是为什么有了Agentic RAG——它把“决定搜什么、搜几次、够不够、要不要换方向”这些判断能力交给Agent自己来做。7.2 Agentic RAG做对了什么Agentic RAG不再是一条单向管道而是一个循环Agent规划检索策略 → 执行检索 → 评估结果 → 不够就重新组织查询 → 直到满足条件或放弃。比如用户问一个跨文档的问题“第一季度各地区的销售额总和是多少”基础RAG可能只掏出某个地区的销售文档回答一办就算完事。Agentic RAG的做法是先判断需要哪些地区的数据然后逐一查询各地区文档把结果汇总后再回答。这个过程中还有“自我反思”的痕迹——某次检索的结果明显不全Agent会自己意识到并补查。像LangChain里可以搭建的的create_history_aware_retriever、以及各种基于RunnableBranch的检索决策逻辑都在帮你实现这类“检索智能”。更深一层的还有多Agent架构——一个Agent负责查询规划一个Agent负责检索执行一个Agent负责结果验证。这个方向在下几篇里我会专门展开这里先给个方向感。7.3 实操建议先把基础RAG的基线跑出来再谈智能化我见过一个典型的团队项目还没上线就开始纠结“要不要用Agentic RAG”。我的意见是不建议这么干。你在基础RAG没有跑出可靠基线之前你根本不知道你的问题到底出在检索还是生成贸然上Agentic会让排查问题变得极其复杂——到底是谁决策错了是规划Agent还是检索器还是生成模型所以实操上的稳妥路径是先把基础RAG跑通量化当前准确率如何评估见下一节。找到最明显的瓶颈是检索召回率低还是生成时被噪声干扰还是多轮上下文搞不定。针对瓶颈做定向升级这一步再决定是否引入Agentic RAG或查询改写而不是为了追热点而上。8. 落地时最容易翻车的几个环节与排查思路8.1 坑一知识库本身是脏的RAG再强也白搭这是我认为RAG项目里最要命的一个问题索引阶段的文档质量决定了整个系统的上限而检索和生成只是在逼近这个上限。常见脏数据包括同一产品有多个历史版本的文档旧版本没有下线新旧说法冲突。PDF解析之后乱码、表格错位、多栏排版读串行。文档里有大量无意义的修饰语、免责声明、重复模板文字切出来的块大半是废词把向量带偏。我印象很深的一次给一个内部知识库做RAG检索出来的内容总是“看起来相关但关键参数对不上”排查了很久最后发现索引里混进去三份不同年份的旧产品规格书其中两份已废弃但没有从索引中删除。花了两个晚上清理元数据和下线旧版本检索准确率直接上来一个档次。所以在做RAG之前先做数据治理建立文档来源清单、标注版本和有效状态、清洗解析错误、统一模板。这些脏活累活比调任何一个模型参数都更值得投入。8.2 坑二没有评估体系优化全靠“感觉”另一个大坑是很多团队上线RAG后凭“感觉”判断效果好坏——某几个测试问题回答得好就觉得成功回答得不好就随便调切块大小。这种搞法极难沉淀经验。我建议至少搭建一个最小的离线评估集50-100对“问题-标准答案”标注每道题的正确答案在知识库里的哪个文档、哪个片段。然后跑两个指标检索命中率RecallK正确答案片段是否出现在召回的Top-K里。生成正确率Answer Accuracy模型最终回答是否与标准答案一致。有了这套评估集你再谈“调参”就有的放矢了。我自己每次调切块或换Embedding模型都会先在评估集上跑一遍用数据说话而不是靠抽查几个例子拍脑袋。8.3 坑三知识更新了但线上还在用旧索引RAG系统上线后知识库不会静止。产品文档更新、FAQ变化、部门边界调整都会让索引里的内容过时。要命的是很多团队在更新文档后忘了同步重建索引导致用户查到的是过时内容。解决这个问题需要定一个“知识更新策略”定时重建每天凌晨跑一次索引适合文档量不大且更新不频繁的场景。增量更新文档有增删时只更新变化的部分适合数据量大、更新频繁的场景需要文档系统有明确的变更记录。双版本切换新旧索引并行验证新索引检索质量达标后再切流量适合对检索质量要求极高的场景。无论用哪种都建议在向量库里给每条数据记录updated_at字段线上出问题时可以反查“用户搜到的内容对应哪个版本”。这个细节在排查线上问题时会救你一命。8.4 坑四把全部希望押在“更大更强的模型”上还有一个常见的心理误区答案生成错了第一反应是换更牛的模型而实际上问题多半出在检索环节。答案错了可能是相关片段根本没被召回也可能是被噪声片段干扰了也可能只是Prompt约束不够。我的建议是遇到“回答质量不行”先做归因打印检索回来的Top-K片段人工判断正确片段在不在里面不在问题出在索引或检索排查切块、Embedding、召回策略。在里面但答案还错问题出在生成调Prompt或换生成模型。如果Top-K里混合了太多噪声加强过滤、加重排、压缩上下文。这套归因方法能省掉你不计其数的“盲目调参”时间。这也是为什么我在这篇里反复强调RAG的基础不只是“会调库”而是能把一条管道的每一个环节都拆开来看。最后如果你正在从零搭建自己的AI Agent我的建议是别一上来就追各种花哨的Agent框架。先从一份真实、干净的文档库开始把索引、检索、生成这条管道亲手走通然后安安静静地做一套评估集测出自己系统的真实水平。这一篇虽然只是基础但这块地基扎实了后面谈Agent自主决策、谈多Agent协作你才真的有底气。下一篇我会接着写RAG落地以后的进阶从“检索增强生成”走到“检索增强思考”看看Agent怎么把知识管道从“查一遍”升级成“反复推理”。
