关于“RAG会不会过时”的争论，这几年我反复听人提起。每次有大模型发布新的长上下文能力，总有人说检索增强生成该退休了。可前几天我在一次技术交流的间隙，和一位做了多年开源RAG框架的创始人深聊了两个多小时，他一句话就把话题拉回到原点：“讨论过不过时之前，先问一句，你现在做的还是RAG吗？”

这句话我越想越有味道。过去两年，我见过太多自称“RAG项目”的实现，其实只是把文档切块、向量化、塞进Prompt，效果不稳定就怪模型不行。这次对谈梳理下来，我最大的收获是：RAG并非一个固定模板，而是一套围绕“检索—知识—生成”的系统设计。这篇文章不打算复刻一场问答实录，而是把对话里最值得琢磨的观点，和我自己落地RAG系统时踩过的坑放在一起，整理成一份能直接用的经验记录。不管你是刚接触RAG的新手，还是已经在做大模型应用的人，应该都能从中找到点东西。

1. 一筐做滥的“RAG”：被误解的检索增强生成本质

1.1 把RAG做成了“向量库+提示词拼接”的项目，我见过太多

最近一年我参与了几个大模型应用项目的评审，一上来就听到“我们用了RAG”，打开代码发现实现逻辑非常统一：文档全部灌进向量库，查询先做向量召回Top K，然后把召回片段拼进提示词，让模型照着回答。这种实现在Demo里很唬人，两三个问题都能答得头头是道；可一旦放到真实业务里，问题就立刻暴露出来——召回内容牛头不对马嘴、答案引用的材料对不上、换一个数据源效果马上崩掉。

为什么大家都喜欢这么做？因为这样最容易跑通，也最容易演示。但“最容易跑通”恰恰是陷阱。那位创始人交流时直接点了这个现象：如果检索增强只是一个拼接技巧，那它确实早该过时了；真正让RAG活着的，是那些被大多数项目忽略的环节——分块策略、索引结构、混合检索、重排、引用溯源。他打了个比方，大家只看到厨师端菜上桌，没人研究后厨是怎么备菜的；可菜好不好吃，恰恰取决于备菜。

这段讨论让我想起某次评审一个文档问答项目时的情景：对方说“模型回答不准确”，我让他们把命中片段打印出来看一眼，结果Top 5里只有两条相关，剩下三条是某份完全不相关的合同模板。这样的效果波动，问题根本不在生成模型，而在检索。

1.2 从朴素到模块化：RAG的演进逻辑

如果只盯着“向量库+Prompt拼接”，很容易低估RAG的发展脉络。早期的朴素RAG确实就是三段管道：切块索引、向量检索、拼接生成。那时候大家觉得问题已经解决了，可真实业务很快给出反例：用户提问是口语化的，企业内部文档是书面甚至带格式的，两者之间隔着一条很宽的语义鸿沟。

于是RAG开始往模块化演进。查询进来先做改写，把一句模糊的话拆成多个更明确的检索子问题；检索不再只用向量，而是向量加关键词混合召回；召回结果不直接给模型，先过一层重排；生成的答案必须能溯源，每句话都要对应到某份原文片段。这些模块不是概念堆砌，每一个都是在真实场景里被逼出来的。

举个典型场景：员工问“上次发的那版合同预算上限是多少？”直接拿这句原话去向量检索，很可能匹配不到完整段落，因为文档里写的是“本项目年度预算不得超过…”。正确的做法是把问题改写成“合同版本”“预算上限”“条款约束”三个检索目标，并行去查，再合并结果。这就是从朴素RAG走到模块化RAG的驱动力——不是追逐概念，而是“怎么找对资料”必须从一种手感变成一套工程方法。

1.3 检索决定上限，生成只是“读稿”

交流中有句话被那位创始人反复强调：检索决定系统的上限，生成只是把检索结果念出来。第一次听觉得有点绝对，后来自己做评估才发现，这话太实在了。

检索为什么难？我总结了三个原因。第一是语义鸿沟，用户脑子里的问题和企业文档里的表达从来不是一一对应；第二是粒度错配，一个复杂问题可能对应多个分散片段，一个片段也可能同时覆盖两个子问题；第三是噪声干扰，很多企业内部文档质量堪忧，扫描件、嵌套表格、失效版本混在一起，索引做不好就是垃圾进垃圾出。

我自己在项目里也踩过同样的跟头。某设备维修问答项目中，一开始把所有精力都花在提示词上，反复调模型输出格式，但准确率始终上不去。后来把精力挪回检索侧，重做分块、加关键词召回、引入重排，同一个大模型准确率提升了一截。所以后面的项目里，我默认把七成资源投在检索链路，生成侧反而简单。很多人不肯承认这一点，总觉得模型不够聪明才答错，实际上中大型企业场景里，检索质量对效果的影响往往远超模型选择。

2. 面对“长上下文会取代RAG”的质疑，我得到的三个回答

每次有大模型发布超长上下文版本，社区里就会上演一次“RAG已死”的讨论。那位创始人的回应不是简单说“不会”，而是给了三个非常工程化的理由，我觉得比情绪化的站队有价值得多。

2.1 先算一笔成本账，再谈“全塞进去”

只说几百字的短问答，全量塞进上下文确实没问题，可企业知识库动辄几十万字、上百万字，把整个知识库塞进每一次请求，成本直接高到没法规模化。举个例子：某中型客服知识库内容大概一百万字，折算成Token再乘以单次请求价格，跑一次就是不小的开销；如果一天有几千次调用，这个数字会让预算负责人当场沉默。

全量上下文方案真正的敌人不是实现难度，而是工程经济学。哪怕用缓存、用关键词过滤、用分段加载等优化手段，也无非是把成本和延迟延后，并没有解决“每次都要处理海量资料”这个根源。RAG的逻辑完全不同：每次只检索出最关键的三五段命中内容，喂给模型的只是和这个问题相关的“一小撮证据”，成本稳定、可预估。我在实际项目里做过对比，同样的问答量，RAG方案的Token消耗通常只有全量方式的几十分之一，这个差距已经不需要再争论什么。

2.2 长上下文能记住更多字，却解决不了“该信谁”

长上下文解决的只是“能不能容纳更多内容”，但企业问答真正的难点是“该用哪一段内容”。窗口再大，模型也无法自己判断这份文档已经作废、那份是未审定的草稿、第三份只能对特定角色开放。没有这个判断机制，给模型一千页参考资料，它依然可能挑中一段过期的制度来回答今天的员工提问。

我经手过某公司的制度问答项目：同样问“年假怎么算”，高管的答案和普通员工的答案必须不一样，因为涉及不同层级的审批权限与补充条款。RAG可以在检索阶段就把权限过滤做掉，只把该角色可见的文档放进候选集合；全量上下文方案则很难做到这种动态隔离，要么一视同仁，要么把权限逻辑写进提示词去碰运气。

还要提一个容易被忽略的点：过时知识。企业业务变动频繁，旧版制度、旧版产品说明经常需要立即失效。RAG只要把旧文档从索引里下线，新查询就不会再被旧知识污染；全量上下文方案则需要重新生成一遍上下文包，运维负担完全不是一个量级。

2.3 主动检索和被动等待，本质上是两条路

我用一个比喻来理解长上下文和RAG的差别：长上下文像让一个人通读整座图书馆，然后答题；RAG是派一个专业检索员，先去目录查到相关书架，抽出最有用的几页递给答题人。前者适合“博览群书型”的开放任务，后者适合“必须基于指定材料回答”的生产任务。

那位创始人原话大意是：模型可以记住全世界的知识，但记不住你公司上个月刚改的版本号；RAG不负责记忆，只负责在需要的时刻精准地找到。这话听起来朴素，却是做To B大模型应用的核心心法。生产系统需要可追溯、可验证、可更新，这三件事恰好都是检索层的看家本领。

所以把“长上下文会取代RAG”当作技术演进的方向，是对两者的双重误解。长上下文更像是RAG的放大器，让同一轮对话里能容纳更多检索证据，也让人机交互更自然；RAG则是知识接入层，把外部知识稳定地接到生成链条上。只要企业知识仍然是动态的、多源的、带权限的，RAG就有充分的立身理由。

3. 那次对谈里让我印象最深的三个判断

那天的对谈没有固定的提纲，但有几句话值得单独挑出来，因为它们反映了这个常年做开源框架的人如何看待整个行业的水位和方向。

3.1 先把问题定义清楚，再谈架构

创始人说他接到过很多类似的咨询：“我们要做智能问答。”但只要追问几句，就发现大家的需求完全不是一回事——有的是内部制度问答，有的是客服自动回复，有的是数据分析结论生成，还有的是招投标文书起草。这些场景听起来都叫“问答”，但检索方式、评估指标、对错误答案的容忍度差得太远。

他的建议很直接：先回答两个问题再去选架构。第一，最终交付形态是什么，是一个单轮问答框，还是带多轮追问的助手，还是嵌入到业务系统里的能力组件？第二，你用哪些指标判断它做得好不好，是回答正确率，是引用准确率，还是“拒绝回答率”控制在什么水平？这两件事一旦定义清楚，架构方案会自动收敛，不会有人在向量数据库和知识图谱之间反复纠结。

这点我自己深有体会。某合同审查项目，团队一开始铆着劲优化模型生成效果，后来发现业务方最重要的诉求，其实是“把相关条款快速找出来”“不要漏条款”。于是架构重心从提示词工程转移到分块策略和条款级检索，项目的价值感立刻不一样了。先定义问题，再谈技术，这句话看着像正确的废话，却是大部分项目跑偏的源头。

3.2 企业不缺模型，缺的是把私有知识用起来的能力

谈到行业趋势时，创始人给了一个很冷静的判断：模型能力的进步是肉眼可见的，但企业把自家文档拿过来就能直接用的比例，并没有同步上升。大量知识还躺在PPT、邮件、会议纪要、旧版文件、多维表格和关系数据库里，既没有统一的格式，也没有明确的语义结构。

RAG在To B场景里真正的价值，不是让模型更像人，而是把私有知识变成可安全、可控、可追溯地接入生成链路。以数据问答为例，老板问“上个月销售数据为什么下滑”，系统需要先连接数据库取数，再检索关联的销售策略文档，才能给出有论据的回答。这些动作里没有一个只靠模型本身完成，关键全在知识接入层。

他的结论是，接下来比拼的未必是谁的模型更大，而是谁能把企业知识整理得更密、索引得更准。做RAG项目的人，有一大半时间要花在数据清洗、文档结构规范化和存量知识梳理上。那些觉得“RAG就是调接口”的人，大约低估了数据治理工作量，也高估了模型的“通灵”能力。

3.3 Agent会放大RAG的价值，而不是取代它

我问创始人，会不会出现一种形态：Agent足够聪明，自己就能推理出一切，不需要先做一轮检索？他很干脆地否掉了，并且给出了理由：Agent越普及，对外部知识的需求越旺盛。

原因也不难理解。Agent需要记忆外部知识来做规划，需要理解工具调用后返回的数据含义，需要把组织里的策略文档和项目历史纳入决策。这些能力每一个背后都要有一个可靠的知识检索层，否则Agent就像一个没有工作记忆的实习生，态度积极但容易一本正经地给出错误方案。

落到真实场景里会更直观。客服Agent要先通过RAG拿到产品手册、售后政策、用户订单状态，才决定怎么回复；研发Agent要先检索内部代码规范和设计文档，才敢给出重构建议。RAG在这个架构里扮演的是“书桌资料柜”的角色——平时安静待着，Agent一旦要写方案、做判断、答问题，第一件事就是从资料柜里抽材料。因此Agent不仅不会埋葬RAG，反而会把这个底层能力带进更多应用场景。

4. 从对谈到落地：做生产级RAG，这些坑我替你踩过

访谈聊得再宏观，落到工程上全是细节。这个章节把我自己做生产级RAG时反复踩过的坑整理出来，每一段背后都有真实项目经验支撑。

4.1 分块策略：别再迷信固定512字

最早做某文档问答项目时，我也用过固定字数切块，理由很简单：省事。可一测就露馅，合同章节被拦腰切断，原本同一段里的“仲裁条款”和“管辖法院”被拆到两个块里，用户问“这个合同在哪仲裁”，系统检索到了一块只写了半句的内容，答案自然张冠李戴。

后来我把分块改成两层：第一层按文档结构切，标题层级、段落、表格各自成块；第二层对仍然过长的块做二次拆分，同时保留父子关系——父块提供完整上下文，子块负责精确匹配。效果对比下来，同样的查询集合，结构感知分块在命中率上领先固定切块一大截。

分块没有放之四海皆准的参数。现在每做一个项目，我会先准备二三十条典型问题，拿不同分块策略在评估集上跑一遍，让数据告诉我哪种方式更合适，而不是凭感觉定一个字符数。

4.2 混合检索是召回率的转折点

只靠向量检索的项目，召回效果往往在专有名词上翻车。某个制造业知识库项目里，用户经常用“型号加故障代码”的形式提问，比如查询某台设备的某个报警码。向量相似度很容易被语义带偏，召回结果经常跑去解释“报警”概念，而不是命中具体维修条目。

后来我把检索链路改成双通道，向量检索负责语义泛化，关键词检索负责精确匹配专名、编号和短代码，再用融合算法把两份候选集合并排序。改成混合检索之后，这类精确查询的命中率明显提升，而且改动成本并不高，关键技术是在融合分数时给关键词通道一个合理的权重，避免完全不相关的词频带偏结果。

也要提醒一句，混合检索不是万灵药。关键词通道会引入不少噪声，比如把“服务器故障”这种常见短语命中到上万个片段。融合之后的筛选阈值、每通道候选数量，都要拿评估集反复调，否则召回率上去了，精确率又掉下来，效果照样没法看。

4.3 重排、引用与“少给反而更强”

粗召回阶段一次性取Top 50，里面真正和问题相关的往往只有几条，剩下的全是干扰信息。早期项目直接把Top 5丢给生成模型，结果模型在无关片段的“启发”下开始自由发挥，编出了看起来合理但完全没出处的答案。后来加了重排环节，粗召回之后再让重排模型对五十条候选做一次精细化打分，只把真正相关的Top 3到Top 5交给生成侧，幻觉比例立刻降下来。

引用校验同样不能省。生产环境里我很早就把“引用条数”和“引用准确率”放进质量看板。答案里每个关键断言都必须能在检索片段中找到对应依据；宁可让答案内容更紧凑，也不允许模型讲一段没有材料支撑的漂亮话。这一点在To B场景格外重要，客户拿着答案去查原文，查不到就是事故。

我自己的经验是“少给反而更强”。有的团队习惯给模型堆资料，觉得上下文越全，答案越稳。实测下来恰恰相反：半相关片段给多了，模型很容易从里面挑出错误信息当证据。把Top 5缩到Top 3，答案的精确度和可信度反而上升。检索增强的核心应该是“增强”，是给模型喂它真正需要的东西，而不是把不确定性一起塞进去。

4.4 用一套评估集把优化变成流程

做RAG最怕“感觉变好了”或者“感觉变差了”，没有量化手段，整个优化过程就是玄学。我现在养成的习惯是，每个项目从第一周开始建评估集：收集50到200条真实用户问题，每条标注标准答案、可引用来源、是否需要拒绝回答的标记。这份评估集是整个项目的定盘星。

核心指标我会固定看四类：检索命中率、端到端问答正确率、引用准确率、单次请求的成本与延迟。其中引用准确率常被忽略，但它是判断“生成是不是忠实于证据”的关键。没有引用准确率，光看问答正确率，很容易被模型的顺嘴胡诌蒙混过关。

优化节奏上，我的顺序是：先调索引和分块，再改检索融合策略，接着调重排阈值，最后才碰提示词和生成参数。每一步做完都拿同一份评估集做对比，A方案B方案都留记录。这样不管是换了模型、换了数据源，还是改了分块参数，效果波动的来源都能快速定位。评估集本身也要持续扩充，尤其要把那些“容易答错”“应该拒绝回答”的坏问题持续加进去，它反映的是系统的真实边界。

5. RAG不会消失，只会换形态

聊到后面，我们很自然地提到了RAG的未来。那位创始人的看法很符合我对行业演变的预期：所谓“永不过时”，不是说这个名词要永远写在首页，而是它会慢慢融进更复杂的系统，变成一种默认能力。

5.1 多模态RAG：知识文档天生不止是文字

企业内部的知识资产，从来不只是干净的纯文本。大量内容存在于图表、扫描件、PPT、表格、截图和音视频里。如果索引层只处理文字，那等于把一多半知识排除在系统之外。多模态RAG要做的是把这些非文本内容做结构化抽取——表格解析、图说明、扫描件OCR——再统一进检索链路，让生成模型能够引用到图表里的数字和结论。

某财务问答场景可以说明这件事。用户问的不是“利润表定义是什么”，而是“这个季度哪个产品线毛利异常”。这个问题的证据不在某个文字段落里，而在财务表格的数值对比中。如果系统不能处理表格结构，它就无法回答。多模态RAG在这里不是锦上添花，而是能不能回答这个问题的分水岭。

5.2 GraphRAG：适合关系密集型任务，但不必神化

GraphRAG是这两年被讨论很多的方向，核心价值是用知识图谱把实体之间的关联显式表达出来，弥补向量检索在“谁和谁有关”上的短板。比如“某设备用到了哪些零件，这些零件又受哪些标准约束”，这类答案需要跨多个文档推理关系链，纯向量检索很容易断链。

但GraphRAG的成本也不低：实体抽取标注要准确，图谱更新要有时效，存储和查询的复杂度也会上一个台阶。我的观点是只在关系密集型任务中引入图谱，比如物料清单、组织权限、事故溯源，普通文档问答场景用向量加关键词就够了。那位创始人同样冷静，说工具是拼图不是图腾，该用向量检索就用向量检索，该上图谱再上图谱，为了追新把简单系统复杂化，最后只是给自己添负担。

5.3 当RAG融入Agent，检索会成为默认动作

往下走，用户感知到的形态可能不再是一个“提问—检索—回答”的问答框，而是Agent在完成任何需要外部知识的任务前，自动决定要不要检索、检索什么、引用什么。RAG从显式功能变成隐式能力，这才是“永不过时”的真正含义——技术形态一直在变，但“让生成模型对接动态外部知识”这件事，是每个智能系统都绕不开的需求。

离开那次交流之后，我回去做的第一件事，是把手头项目的评估集重新整理了一遍，又临时加了二十条“坏问题”进去，专门测试系统在拿不准时会不会老老实实拒绝回答。后来几次模型升级和数据源调整，效果波动都能很快定位到是检索变了还是生成变了。这个习惯我会一直保留。如果你也在做RAG，我的建议是别急着追新架构，先把手里的检索准确率和引用可靠率做扎实。你会发现，关于“过时”的争论，其实离你的项目远得很。