关于“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消耗通常只有全量方式的几十分之一这个差距已经不需要再争论什么。对比维度全量上下文方案RAG方案单次请求成本跟随上下文长度线性上涨由召回数量决定可控知识更新要重建提示词或缓存内容更新索引即可生效细粒度权限控制很难做到按文档、按角色隔离可在检索阶段直接过滤答案可追溯不好定位依据哪一句可强制引用来源片段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我的建议是别急着追新架构先把手里的检索准确率和引用可靠率做扎实。你会发现关于“过时”的争论其实离你的项目远得很。 
长河君 · 2026/10/17 16:57:14 · 阅读 1.2k RAG不会过时：从朴素检索到模块化Agent架构的工程实践
关于“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消耗通常只有全量方式的几十分之一这个差距已经不需要再争论什么。对比维度全量上下文方案RAG方案单次请求成本跟随上下文长度线性上涨由召回数量决定可控知识更新要重建提示词或缓存内容更新索引即可生效细粒度权限控制很难做到按文档、按角色隔离可在检索阶段直接过滤答案可追溯不好定位依据哪一句可强制引用来源片段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我的建议是别急着追新架构先把手里的检索准确率和引用可靠率做扎实。你会发现关于“过时”的争论其实离你的项目远得很。