2025年RAG已死2026年做上下文工程这话我从2024年下半年开始几乎每隔几周就能在各种技术群和公众号里刷到一次。起初我当标题党处理直到我在真实生产环境里看了不少所谓“RAG系统”翻车才意识到这个说法虽然夸张但指向的问题非常真实RAG不会死死的是“把文档切一切、丢进向量库、取出top k拼进提示词”这种偷懒写法。而2026年真正拉开差距的不再是“谁塞进上下文的知识更多”而是“谁更懂如何在模型中组织和控制上下文”。这篇文章就是写给刚入行的程序员看的我会用实际项目里的踩坑过程把这个话题彻底讲透。在动手之前先说我看到一个普遍现象很多人把RAG的效果不佳归咎为“模型推理能力不行”或“向量检索不准”但真正跑一遍日志就会发现绝大多数问题出在上下文这一层——喂进去的内容顺序错了、信息冗余、互相冲突甚至把真正关键的一句话放在模型最容易忽略的位置。这才是上下文工程被推到台前的原因。1. “RAG已死”这个说法是怎么来的真实变化是什么1.1 先回顾2024到2025年的RAG热潮RAG的大规模落地是从“给大模型外挂一个知识库”这个朴素需求开始的。最初大家做事方式高度统一把PDF、Word、网页内容全部切割成几百到上千字符的块做向量化存进向量数据库用户提问时把问题也向量化检索出相似度最高的几个块连同用户原始问题一起拼进提示词。项目跑通很快demo演示效果也好但只要放到真实业务里就会开始出问题。我在某个模拟项目X里做客服问答系统的时候遇到过特别典型的案例。客户提供的知识库里面有操作手册、售后政策、维修日志还有大量表格形式的物料清单。我按统一大小切块做向量检索前两周本地测试效果还算正常等接入线上真实用户提问后召回质量直线下滑。最夸张的一次用户问“保修期内进水了能不能免费换”系统检索出来的块是“清洗滤网时注意不要让水流进机身”从语义上讲这两个内容是相关的但知识等级完全不同。模型把这两个信息拼在一起回答给出的结论既不符合售后政策也没有任何法律效力。产品经理当场质疑“你这RAG是不是选错模型了”这个场景其实代表了绝大多数RAG失败的共性不是检索不到而是检索回来之后模型分不清哪些内容是当前问题的核心哪些是干扰项。传统做法把所有检索结果一视同仁塞进上下文就等于把一堆证据和一堆噪音同时交给法官然后指望法官自动分辨——模型确实有一定分辨能力但当准确率要求达到99%以上时这种粗放方式必然崩。1.2 RAG失效的真正变量是上下文不是检索我后来把所有线上失败样本拉出来做了统计发现真正导致回答错误的原因按占比排序大概是这样的上下文信息冲突或过期占了大概四成关键信息被埋在长文本中间占了差不多三成检索结果相关但不够直接缺少推理链条占了两成检索本身就没召回相关内容只占一成左右。也就是说大部分情况下向量库确实把相关材料找回来了问题出在“材料怎么被组织成上下文”。模型接收到的上下文就像人写文章一样开头和结尾最容易被记住中间一大段内容容易被忽略——这是大模型注意力机制天然的特性。很多人不知道这个现象还有一个专门的提法叫“中间信息迷失”英文圈里叫lost in the middle。这也是“RAG已死”这个段子背后真正的产业变化当所有团队都发现向量检索只是一个起点真正决定效果的是如何构建、压缩、排序和更新上下文时大家就自然而然地把注意力从“检索”转移到“上下文”。所以与其说RAG死了不如说它把那把接力棒交给了上下文工程。2026年被反复讨论的上下文工程不是某个具体开源库也不是新模型而是一整套围绕上下文的设计方法论包括怎么选择信息、怎么压缩信息、怎么放置信息、怎么让信息之间形成逻辑关联。2. 上下文工程到底在做什么先把机制讲透2.1 中间信息迷失与大模型的注意力偏向理解上下文工程首先要理解大模型读“长上下文”时的注意力分布。大量实验已经验证过模型对一段长文本最前部和最后部的信息权重最高中间部分容易被“平均化”或者说被压扁。这在很多超长上下文模型里同样存在不是改改API参数就能解决的。举个例子我之前修过另一个问题系统给模型塞了十几份技术文档用户问题在提示词中部模型直接忽略了用户的提问风格要求用英文回答问题。排查最后发现就是因为代码生成提示词时把“请用中文回答”写在了所有文档和中间逻辑的正中间模型阅读到那里时注意力权重已经降得很低。把这一句话挪到提示词最末尾之后问题立刻消失。这个现象也解释了为什么有些工程师觉得“上下文加到200K一定更准”实际却是“加到200K之后反而变差”。不是模型不理解长文本而是信息位置会极大影响模型的利用效率。上下文工程的第一课就是不要迷信长度要管理位置和权重。2.2 上下文工程的核心操作压缩、筛选、排序、结构化我把上下文工程按实操拆一拆新手最容易上手的四件事是这样的。第一件事是上下文压缩。把大段文档先做一轮摘要或者重点提取只保留跟当前问题有直接关联的信息。压缩可以在调用大模型之前用规则做也可以用一个小的模型做“先总结再拼接”核心目的是降低无关token对注意力分布的稀释。我在一个合同审核项目里把每份合同的原文从几万token压缩成两百字的“条款风险点清单”审核准确率明显提升调用成本反而降了。第二件事是上下文筛选。这里说的筛选跟传统向量检索中“选出top k”还不太一样它更强调的是多路召回后的重排和校验。也就是先用关键词、向量、知识图谱等多种方式召回候选内容再综合判断每一条和当前问题的相关程度甚至可以把互相矛盾的几条内容留出来交给人审。筛选之后留下来的每条上下文都必须是有明确用途的而不是“检索到了就先塞进去”。第三件事是上下文排序。排序不是随便排它要遵循“最关键的信息放开头或结尾辅助信息放中间”的原则。在一个问答系统里我会把用户明确表达的指令放在提示词开头把检索到的核心证据放在指令之后把一些补充背景信息放在中段最后再在结尾处重复一遍最关键的限制条件比如“根据以上条款判断是否支持退款”这种强约束。这样模型在生成时能同时利用开头和结尾的高注意力区输出质量最稳。第四件事是上下文结构化。不要把所有内容拼成一大段纯文本而是用小标题、标签、分隔符把上下文切成清晰的区块。比如用类似“【业务规则】”“【用户案例】”“【输出要求】”这样的结构标记。模型在预训练阶段就接触过大量Markdown、JSON、XML这类标记型文本对结构化的理解能力比对自由文本更强。结构化之后还能方便你在代码里按模块增删上下文不必每次重新拼接一大坨。2.3 从“捡回来”到“留得住”上下文与记忆层级除了单次请求内的上下文组织2026年更受关注的是跨请求的长期上下文管理。RAG最初解决的是“外部知识怎么接入模型”但实际业务里很多信息是动态变化的比如用户画像、对话历史、业务状态。如果每次请求都重新检索一遍所有历史信息上下文会越来越乱费用也越来越高。更好的做法是引入记忆层级分三级管理短期工作记忆保存最近几轮对话中的关键状态比如用户说“我不要红色款”就单独存一条结构化记录中期会话摘要每N轮对话后让模型自动生成一份结构化摘要把已经聊过的内容压缩成要点长期知识库只有当问题确实需要外部文档时才去检索检索结果进入当前上下文后也要先压缩再使用。这个三层结构的本质就是让每一次模型请求所真正面对的上下文都足够精炼、足够相关。很多团队把“长期记忆”单纯理解成“把所有历史消息都塞回去”这恰恰是上下文工程最反对的做法。历史消息里大量重复、客套、跑题的内容是注意力资源最大的浪费源。3. 小白程序员怎么开始做上下文工程给一套直接能抄的思路3.1 先用最轻量方式搭一个可对比的基线很多刚入行的朋友一看到“上下文工程”就以为要上复杂的Agent框架或者要用多模态大模型。其实不然最有效的入门方式是在现有RAG项目上做一次“前后对比实验”。我先给出一套可直接执行的方案。第一步是选一个你已经调不好的真实业务场景把用户问题固定成10到20个标准测试用例覆盖简单问答、复杂推理、边界拒绝这几类。第二步是跑基线用你原来的切块、向量检索、top k拼接方式把推理录制成日志。第三步是关键我建议你在日志里记录每个用例对应配发给模型的上下文内容不只是模型输出结果。这样才能看到是什么塞进去才导致失败。以我个人的实战流程来说我会把上下文组装代码抽象成函数入参是“检索到的候选块列表”和“当前用户问题”输出是一段最终进入模型的文本。函数内部流程是先对候选块做一次规则过滤比如按元数据过滤来源、时间再做一次语义重排让与问题最直接相关的块排到最前然后按固定模板做结构拼接最后把“输出要求”这段强约束放在最末尾。代码结构大概是这样的def build_context(question, retrieved_chunks): # 1. 规则过滤只保留指定来源和有效时间内的内容 filtered [c for c in retrieved_chunks if is_valid(c)] # 2. 语义重排用轻量模型或基于关键词覆盖度的打分函数排序 reranked rerank_by_relevance(question, filtered) # 3. 压缩裁剪超出长度上限时调用摘要模型做压缩 compressed [compress_if_needed(c) for c in reranked[:6]] # 4. 结构化拼接关键结论在开头补充材料在中间输出约束在结尾 blocks [【核心依据】, *compressed[:2], 【补充参考】, *compressed[2:], 【输出要求】, 请严格基于以上依据进行回答] return \n.join(blocks)这套代码看着简单但每一步都是在调整上下文的结构和位置。改完之后同一个测试集跑一遍基本就能看到明显差异。我在多个项目里做过同样操作平均能解决的错误比例在30%到50%之间尤其是那些“答案东拉西扯”的错误大幅减少。3.2 处理多个知识场景时的“双检索”策略如果你的系统不只有一个知识库而是混合了产品文档、制度文件、技术支持帖等多种来源我建议使用双检索策略。第一路是快速召回用关键词或向量召回候选块扩大范围第二路是对候选块做“来源类型识别”把不同的块归类到不同场景然后按场景配置不同的上下文模板。举个例子在一个设备故障排查系统里我用双检索把召回结果分成了三组产品规格组、操作手册组、常见问题组。操作手册组进入提示词时我会额外加一句“该部分为操作步骤回答时必须按序号输出”产品规格组进入时我会要求模型“引用规格时必须写明参数名不要自行推断”。这种按场景配置上下文的做法本质上是给模型提供了一套“该怎么读这些材料”的元指令。元指令放在上下文的最前面模型遵守的概率会显著提高。对这个策略我建议新手重点看排序和元指令带来的变化而不是急着在检索模型上做大量调优。双检索的价值在于它让你把不同知识类型分流并分区避免把技术帖子、客服记录、官方文档混在一起互相污染上下文语义。3.3 上下文工程里的预算思维时间、token、质量如何平衡做上下文工程不能只盯着质量还要盯成本和响应时间。在真实生产系统里高耗时往往来自长上下文再一次挤压模型。不要盲目把“压缩模型”接入长流程计算完再上策略。我一般用一套简单的预算表来决策上下文方案延迟增量token成本增量质量提升原始top k直接拼接最低最低基线加规则过滤和重排几乎可忽略几乎可忽略明显改善加摘要压缩中等增加约200ms降低最终token量长文档场景改善较大加多路召回和场景分流中等中等复杂场景改善最明显这个表指向一个结论质量不一定来自复杂的链路很多情况下先做规则过滤和重排性价比最高。压缩服务往往需要调用一个小模型看起来多了一次请求但它能省下最终大模型读取海量原始文档的token总体费用反而更低。我建议新手从表里第一行开始逐步添加上下文策略每次只加一个变量连续记录数据这样你能清楚每个策略贡献了多大的提升比一上来就搭全套Agent框架靠谱得多。4. 常见问题与排查技巧实录4.1 上下文太长导致模型“答非所问”或“中英混杂”我碰到过很多中级工程师跑来问我已经做了检索也把文档放进去了为什么输出还是乱来。这类问题八成是长上下文里信息位置不当。排查时先不要换模型把最终进入模型的上下文原样打印出来看限制条件或者核心指令是在第几段。只要这个关键指令出现在整段上下文的中间位置调整到开头或结尾基本就能解决。我自己还遇到过极端情况系统提示词本身就写了一千多字里面包含大量规则用户问题被放在很长的一段系统提示之后再后面才跟着几十段检索文档。模型读到用户问题时已经是“长文本中段”注意力早已涣散。这时候最优解不是删检索内容而是精简系统提示词把跟当前请求无关的历史规则挪出上下文。4.2 检索出来相关内容但模型仍坚持编造信息这个现象比较隐蔽。模型不是在“编”而是它在阅读上下文中发现信息不足或互相矛盾时会倾向用自己的预训练知识补全。一个典型场景文档里只写了部分参数的默认值用户问的是未明确列出的值。模型可能推测出一个看似合理但完全错误的值。排查办法是给上下文增加“知识边界描述”比如在末尾加一句“如果以上材料未提供相关信息直接回答不清楚禁止推测”。这种显式指令能显著降低幻觉比例。另一个思路是给上下文中的每个块加“可信度”标签——这是上下文工程的一个小技巧。把来源为官方文档的块标记为高置信把来源为论坛讨论的块标记为低置信。在生成要求里写明“回答时优先采用高置信信息低置信信息仅作参考”。减少互相矛盾的块对模型生成的干扰。4.3 多轮对话中历史信息把当前问题淹没这是对话类产品最容易踩的坑。很多团队为了记住用户说过的话把整个对话历史反复发送给模型几轮之后上下文挤满了“你好”“谢谢”“稍等”。最后用户问了一个新问题模型已经开始看“房型预订”却完全忘了用户之前提出的“必须无烟房”约束。上下文工程给出的解法是把历史对话转成结构化的“槽位状态”比如在一个演示项目里我维护了这样一个状态字典current_state { city: 杭州, hotel_budget: 500-800元, smoking: 否, breakfast: 需要包含早餐 }每一轮新的对话进入系统时先把上一轮结构化状态和当前用户问题合并再与外部知识库检索结果一起做上下文。整个会话历史信息被压缩成几十个token模型每次受到的干扰就很小。这套思路比把所有历史都丢给模型要稳得多。你自己动手时核心逻辑就是“状态增量更新”每一轮只抽取变化信息覆盖之前的状态不做无限附加。5. 2026年再往后上下文工程会到哪里去5.1 我的真实体会工具会变上下文管理的心智模型不变我在实际干活中体会最深的是不能用“某一年就该用某个技术”来框定工作方法。RAG当时被追捧是因为它解决了知识外挂问题今天上下文工程被热议是因为大家发现“外挂”之后还有一个“如何伺候模型注意力”的问题。再过两年可能会有一个更优雅的新概念把这个事情包装起来但核心还是那几件事信息如何过滤、如何压缩、如何排序、如何组织、如何更新。这些能力是通用的不受具体模型品牌更新的影响。我甚至建议新入行的朋友直接把手里的RAG项目改造成一个“上下文可观测系统”。不要只关注生成内容的质量还要为每一次请求记录上下文的组装过程哪个检索块进入了、哪个块排在第一位、哪段内容被压缩过、哪条指令放在末尾。有了这些观测数据你才能持续迭代上下文策略而不是每次靠运气调提示词。这个思维方式比学会任何一个特定框架都值钱。5.2 给新手程序员的下一步行动建议如果看到这里还是有点抽象我建议你本周就能做一个练习。选一个你手头正在做的AI应用把它的提示词和检索结果打印出来人工扮演“上下文工程师”肉眼找出上下文里的三条问题第一是否有关键指令处在中间位置第二是否存在互相冲突的内容第三是否存在明显冗余、可以压缩掉的长段落。找到之后分别修复再用同一批数据回归测试。这十五分钟的练习你得到的体感会比读十篇“RAG已死”的讨论都多。工具方面不要执着于某一家的向量数据库或者某种检索框架多关注怎么给检索结果做重排、怎么做上下文摘要、怎么监控注意力分布。哪怕用最简单的字符串拼接和调用小模型做摘要也能完成很多事。等这些基础功稳了再上更复杂的编排框架你会发现自己看框架的角度都会不同。最后再分享一个我长期实践的小技巧上下文工程不是一次性工程不是模型发布上线之后就不管了。用户提问分布会变知识库内容会迭代所以一定要给上下文模块留出独立的调试入口。我在自己代码里都会加一个“上下文预览模式”开启之后系统会返回最终进入模型的完整文本并且高亮显示每个区块的边界和位置。排查问题时先开这个模式比加几百行日志有用得多。这也算是我在无数个失败案例里趟出来的一条实用经验希望你直接用起来。