2025年还没过完圈子里就开始给RAG写悼词了。“RAG已死”、“下一步是上下文工程”这类标题我刷到过不止一次每次都能收获大量转发。作为一个实际把检索增强生成接到业务系统里、被检索漂移坑过无数回的一线程序员我的态度很明确RAG不会死真正会被淘汰的是“只会把RAG当万能拼接器”的粗暴用法。2026年真正该补的课是上下文工程——把有限的上下文窗口当成一项预算来管理系统化地决定哪些信息进、哪些信息不进、以什么结构进、如何压缩与缓存。这篇文章不贩卖焦虑只讲清楚两个概念的分工边界并把小白能直接复现的搭建、调优和排错经验一并放出来。1. RAG和上下文工程到底在争什么1.1 先给RAG“验尸”它到底死没死RAG的全称是检索增强生成核心思路非常朴素模型记不住或者不该记住的知识先放到外部存储里用户提问时先检索相关片段再把片段拼进提示词。打个比方你让一个记忆力一般的人去开卷考试他不需要背完整本教材只需要知道去哪一章翻答案然后把关键段落抄进答题卡。这套思路从诞生起就是为解决大模型的知识过期、编造和私有数据无法进入模型参数这三个问题而且直到今天这三个问题依然是应用落地的核心瓶颈。如果“RAG已死”的意思是它要被某种新架构彻底取代那它得先回答一个问题在私有知识库问答、企业级客服工单处理、风控合规审查这类必须给溯源依据的场景里不用RAG你还能用什么答案几乎是一个字都换不了。模型参数不会因为你花钱买了大窗口就自动更新企业客户要的不是“好像知道”而是“你有本事把哪份文档、哪一页、哪个条款列出来”。所以我不但不认为RAG死了反而认为它在落地价值上比前两年更清晰。那为什么会有“RAG已死”这种说法因为很多人用RAG的时候其实是把它理解成了“拼装检索结果”。前端把用户问题丢给一个向量库取回一堆相似片段再用模板一拼完工。结果检索不准、片段互相矛盾、上下文塞过载导致生成质量下降最后把这笔账全部算在RAG头上。实际上这是典型的水管漏水赖水厂——检索出的是证据但证据能不能被模型有效使用取决于你怎么组织、筛选、压缩和路由这些证据这已经属于上下文工程的范畴了。1.2 上下文工程是个什么工程上下文工程英文叫Context Engineering字面上看就是“对上下文做工程化治理”。它不是某一天突然冒出来的新架构而是一个从提示词工程进化出来的系统工程。提示词工程解决的是“单个prompt怎么写更有效”上下文工程解决的是“整个应用每次调用时应该携带哪些信息、不带哪些信息以及这些信息用什么顺序和结构进入模型”。我更喜欢用“厨房配菜”来类比提示词工程像菜谱告诉你糖放几克、盐放几勺上下文工程像后厨的备菜流程决定今天店里来了客人之后哪些食材送进炒锅、哪些进冷藏室、哪些直接丢垃圾桶后厨整体能不能在高峰期把几十个订单稳定出菜。它关注的不只是最后那一勺调味而是从食材采购数据源接入到预处理清洗过滤再到装盘顺序上下文排版的完整链路。所以上下文工程至少包含四件事上下文的获取、筛选、压缩与编排上下文的缓存与版本管理上下文的来源跟踪和预算控制以及上下文质量的可观测和可评测。这东西听起来确实比“写提示词”重得多但只有把它当成一个工程系统来做才能稳定地扛住线上流量和业务复杂度。1.3 两者的顶层关系不是替代是分工我的判断是RAG和上下文工程不是竞争关系而是局部与整体的关系。RAG管的是“知识从外部存储到模型输入”这一段它是上下文工程的一个关键子模块。上下文工程管的是“模型输入层整个生命周期”包括系统提示词、用户历史、工具返回结果、检索片段、模型内部记忆甚至安全指令全都要在被模型看到之前过一遍治理流程。换个角度说RAG产出的检索结果只是“半成品证据”它能不能被有效使用取决于上下文工程里的排序、压缩、去重、格式化和预算分配。很多团队只做RAG不做上下文工程上线后效果像开盲盒换一条query效果不错换一条就幻觉百出。根因往往是检索没问题但上下文拼装环节完全失控。理解了这层关系之后再去定义2026年的技术路线就会清晰很多不会写作能力、不会做路由的RAG确实不够用但把RAG嵌入到一个成熟的上下文工程体系里它依然是当前性价比最高的知识注入方式。2. 为什么2025年突然有人喊“RAG已死”2.1 token窗口狂涨带来的幻觉这两年各家大模型厂商都在疯狂推长上下文一百万字、几百万token的窗口一个个冒出来。于是很多人产生了一个直接联想既然窗口这么大那我可以把整份产品文档、整本规章制度甚至整个知识库的转储都塞进提示词从此再也不需要做检索。这种思路听起来很解脱但实际跑过的人基本都会在成本和效果两方面被打脸。先说成本。长上下文对应的输入价格不会因为塞得多就便宜每次请求都带上几十万token传输耗时、排队耗时、模型首字延迟全部上涨用户感受到的“响应慢”还不是最致命的真正致命的是把几乎不可能稳定复用的长文本反复发送单个用户日活带来的机器成本就能把项目的单位经济模型打穿。再说效果。模型接收超长上下文时注意力在这么多token之间分配得很不均。很多简单的长文本评测能过但只要换成需要跨多个片段做多步推理的复杂任务效果依然会明显退化。这就像开卷考试带了一整车书进去翻找和定位的时间成本暴涨最后答题时真正有效的信息密度反而降低了。超长窗口的真正价值不在于“替代检索”而在于给上下文工程留出更大的缓存空间和更长的对话记忆。窗口再大也不能成为不做信息筛选的借口。2.2 RAG管线复杂之后的口碑滑坡喊“RAG已死”的第二股力量来自真实落地中的一堆败退体验。RAG管线的经典环节包括文档切分、向量化、索引、召回、重排序、提示词拼装每一个环节都有不少“轻松翻车”的死角这几年公开吐槽RAG效果差的声音越来越多我总结了一下常见的翻车集中在下面几类管线环节常见问题直接后果文档切分切块大小和重叠策略一刀切语义被截断召回结果答非所问向量化没有针对特定领域做适配近义词理解差检索召回率偏低索引管理元数据缺失版本升级后旧文档没下线新旧信息混着用输出错得离谱重排序只看语义相关不看时效和权威性模型被错误证据带跑提示词拼装把海量检索片段不加整理全塞进去上下文膨胀模型无法聚焦这些问题本质上不是“RAG方法错了”而是“只做了RAG的壳没做上下文的魂”。但站在旁观者和媒体视角现象就是“RAG项目上线效果差”于是标题越写越惊悚慢慢传成了“RAG已死”。这两年我在几个社区和技术群里看到的现象是那些把RAG稳定跑出业务价值的团队几乎无一例外都花了大量时间在上下文工程相关的脏活累活上比如切块边界分析、元数据设计、检索结果的压缩和排序规则。与其说这些团队靠RAG取胜不如说他们靠的是上下文工程。2.3 真正变化的不是技术是问题定义方式说到底2025年最大的变化不是某个模型突然不行了而是大家终于开始用“问题定义”的角度重新审视大模型应用。以前我们问怎么把知识塞进模型现在开始问一次完整的对话或任务它的上下文应该长什么样哪些信息是可信的哪些信息会引入噪声预算怎么分配来源怎么追溯这几问正好是上下文工程的核心盘面。这个转变不是技术换代而是工程视角的升级。就好比以前做饭关注的是“用什么锅”现在关注的是“整个厨房的出餐流程”。RAG仍然是那把好锅但光有好锅已经不足以撑起一家餐厅。当越来越多团队发现问题定义视角需要升级时“RAG已死”这类话就成了这场升级的粗暴注脚。我看标题从来只看它背后的底层信号大家不是在否定检索增强而是在呼唤更系统的上下文治理能力。3. 从零搭一个上下文工程工作流3.1 先盘清楚你的“上下文资产”我刚接触上下文工程时犯过一个错误一上来就写了很多花哨的提示词模板结果线上效果没有任何提升。后来想明白了提示词只是上下文最后一公里真正要处理的是一整批“上下文资产”。建议先花时间把应用里所有会进入模型输入的信息分门别类我在实际项目里用的是下面这份分类清单资产类型典型内容进入上下文的方式静态系统上下文角色设定、任务目标、安全指令、输出格式每次请求固定拼装动态业务上下文用户画像、权限标签、当前诉求、历史会话摘要按用户和会话动态组装检索上下文知识库片段、工具返回结果、外部接口数据由召回和重排序产出记忆上下文跨会话偏好、长期用户意图、业务常量从缓存或记忆服务读取盘完这四类资产之后还有一个要立刻补上的动作给每个资产块打上来源标记。我这边所有的上下文块统一带上doc_id、version、source_type、timestamp这些字段别嫌麻烦后面一旦出问题没有来源标记你连排查的依据都找不到。3.2 上下文打包与分层策略资产盘清楚了接下来是“怎么组装”。我会把最终交给模型的提示词分成四层系统层、任务层、证据层、示例层。系统层是固定不变的骨架包含角色、任务定义、安全边界和思考规则这一层要精简再精简。我见过不少团队的system prompt写得比论文还长把一堆“你是一个强大的AI”“请认真回答”之类的废话全塞进去除了稀释注意力之外毫无价值。任务层放的是用户当前这一轮的诉求包括通过查询解析拆出来的关键参数、语境补充和明确目标。证据层放的是检索片段和工具结果这是整个组装过程中最需要做预算控制的一层对此我的经验是并不是召回的片段越多越好真正有效的信息密度才是核心指标。示例层放少量few-shot例子好的示例比反复强调“请按JSON格式输出”这类重复指令有用得多但示例务必短小精准否则就是在给上下文增加无谓的开销。组装的顺序有一个朴素原则先放模型该优先看的东西后放补充信息。很多应用把所有内容一股脑按某种固定顺序拼接结果模型更关注中间段落而不是最后的结论这本质上是上下文排版没做好。3.3 用一份最简单的上下文模板跑通Demo说再多理论不如跑一个最小可复现的Demo。下面这个Python伪代码是我在搭建原型时用的基础模板没有依赖任何特定框架纯用标准库的思路演示“先拆资产、后组装、再压缩”的流程def build_context(query, profile, retrieved_chunks, examples, budget3000): blocks [] # 1. 系统层固定但控制长度 system_block render_system_prompt(roleprofile[role], safety_rulesprofile[safety]) blocks.append((system, system_block)) # 2. 证据层按相关度排序逐步分配预算 remaining budget - estimate_tokens(system_block) for chunk in sorted(retrieved_chunks, keylambda x: x[score], reverseTrue): block [证据|doc_id{}|version{}|time{}]\n{}.format( chunk[doc_id], chunk[version], chunk[timestamp], chunk[text] ) if estimate_tokens(block) remaining: blocks.append((evidence, block)) remaining - estimate_tokens(block) else: break # 3. 任务层用户的真实诉求必须完整放在证据之后 task_block [用户诉求]\n query if estimate_tokens(task_block) remaining: blocks.append((task, task_block)) # 4. 示例层最后放预算还有富余才加 for example in examples: ex_block [示例]\n example if estimate_tokens(ex_block) remaining: blocks.append((example, ex_block)) remaining - estimate_tokens(ex_block) return assemble(blocks)注意顺序系统层固定在前证据层紧随其后任务层放到证据层之后示例层放最后。任务层在证据层之后可能让很多人意外但实测下来模型在读证据时已经在建立对问题的理解最后看到任务层时能形成“带着证据看诉求”的效果比把用户问题放最前面更稳定。3.4 衡量上下文质量的三个指标上下文做完之后不能拍脑袋说“感觉效果不错”我强烈建议在项目里先定三条衡量标尺。第一是信息密度指有效token占全部输入token的比例同样一次请求如果10个片段只有2个被模型真正用上那就是密度太低。第二是覆盖率指当前任务真正需要的关键事实是否出现在上下文中漏了必输。第三是辨析率指模型能不能从上下文中正确选出可信证据尤其在存在多版本、多来源数据时辨析率比覆盖率更关键。实际操作里我不太建议只看系统自动生成的指标因为自动打分经常和用户体验脱节。更笨但有效的办法是抽100条线上query人工打开一次完整的请求日志对比“上下文内容”和“答案质量”给每条数据打一个“是否可从上下文推导出正确答案”的标记。这么抽出30分钟左右的时间一定比跑十个评测集更能暴露问题。4. 实战中的RAG该怎么跟上下文工程共存4.1 检索不是目的结构化才是把RAG嵌入上下文工程的第一步是改变对检索结果的心态。很多人把检索结果当成“原文片段”直接用其实应该把检索结果当成“需要再次提炼的证据”。我在业务系统里要求所有进入上下文的知识片段必须携带结构化元数据并且显式地把元数据展现在提示词里。比如{ doc_id: KB-202601-001, version: 2026.01, department: 客户服务部, updated_at: 2026-01-15, trust_level: official, content: 针对订单未按时送达的情况客服应先致歉并补偿10元优惠券。 }在提示词中显式带上doc_id和version这个动作看似只多了几个字段实际效果差异非常大。模型在这些字段的引导下会更倾向于把它当成事实依据而不是自由发挥的语料。相反如果只把原文文本扔进去模型的“知识引用感”会弱很多幻觉概率随之升高。4.2 长文档处理的经典组合预切分重排序压缩处理长文档时我用的组合套路是预切分、重排序、上下文压缩三段式。首先是预切分块大小我一般控制在250到500个token之间重叠量取50到80个token这个参数是多次测试下来的平衡点。块太大语义完整但噪声多块太小语义被切开但定位准。其次是重排序初召回取回来前面30到50条通过重排序模型筛到前10条左右。千万别把所有召回结果都交给模型我给这个上限做的是硬截断。最关键的是第三步上下文压缩。这一步的核心是拿一个专门负责“提炼”的模型对每段证据做压缩压缩率控制在原长度的一半以下同时强制保留所有关键数字、结论以及引用编号。压缩前后的差距我举一个常见案例原本一份1800字的售后政策文档被压到不足300字仅保留退款时限、补偿金额和例外条件模型回答的准确率反而明显提升。压缩Prompt模板我在这里共享一个可用的版本你是上下文压缩器。请把下面的文档压缩到不超过原长度一半 保留与用户可能问题直接相关的结论、数字、规则、例外条件。 输出必须包含原始文档编号和行号不得编造任何原文不存在的信息。4.3 一个更稳健的混合架构一套能上生产的架构在我看来至少要有五个组件配合。查询路由器负责判断用户输入适合走检索、走纯生成还是走工具调用索引层负责知识召回和版本过滤上下文组装层负责分层打包和token预算控制缓存层负责复用静态上下文和语义缓存避免每次请求都从头跑全链路校验链负责在模型输出前检查引用完整性、关键数值格式和越权口径。组件职责边界关键设计点查询路由器判断用户意图类型用轻量分类模型或规则不要为了查一句话去跑大型RAG链路索引层知识召回、元数据过滤强制版本、部门、权限字段的过滤前置上下文组装层分层拼装、预算分配单层预算上限超了就压缩不硬塞缓存层静态模板缓存、语义缓存缓存键必须包含模板版本号和关键业务参数校验链输出前引用与数值校验引用doc_id必须存在于本次证据集否则强制回归或重生成这套架构跑下来RAG并没有消失它只是被压缩成了“索引层”这个角色。整个系统的稳定性从依赖某一个环节的效果变成了依赖多个环节的协同治理这也正是上下文工程想表达的中心思想。5. 线上事故复盘一次“无效上下文”连环翻车5.1 事故链路从检索漂移到输出全错前面讲了不少理论来说一个我印象非常深的线上事故。当时我们运营的是一个内部知识库问答系统就叫模拟项目X知识库里有大量按季度更新的业务报表文档。有一次客服同事在系统里提问“上个季度的退货率是多少”模型给了一个数字客服直接引用了这个数字去答复客户结果客户反馈“这个数据不对吧”一查才知道模型回答的是去年同季度的数字。复盘下来问题链路比我预想的更长。文档预切分时按固定窗口切旧版本文档没有在索引里被标记下架向量召回阶段旧版本文档与用户提问的语义相似度和新版几乎持平重排序模型只按语义相关度打分根本不关心时间新旧上下文压缩阶段在处理两段落时把旧版和新版的关键数字拼到了同一个压缩片段里还丢了版本标记。最终模型看到的上下文里新旧数据是混在一起且无主次的它自然倾向选那个更“顺眼”的数值。这条链路里没有任何一个环节是单独崩溃的但它们串联之后直接形成了一次不可接受的错误回答。5.2 排查过程先看召回还是先看上下文事故发生后团队按直觉先去查检索日志折腾半天也没完全定位问题。后来我调整了排查顺序先看模型最终收到的上下文再倒推是哪个环节输入错了。这个顺序很关键因为输出质量直接取决于最终上下文很多时候召回结果没问题问题出在拼装或压缩过程中。我们重新跑了一遍相同的用户query把模型最终收到的完整上下文打印出来发现里面既有新版文档的结论也有旧版文档的数值两者还被压缩层合成了一段“混合结论”。为了把排查过程写得可复现我整理出了当时的排查链路排查步骤看到的现象初步结论打印模型完整输入上下文中存在两个版本号且压缩片段未标注版本上下文组装层版本标记失效检查重排序结果新旧文档相关度分数相差不到1%重排序时间衰减因子缺失检查索引库文档状态旧版文本文档状态未置为不可检索索引元数据更新流程有漏洞检查压缩prompt未要求保留文档编号和版本压缩模板设计不安全所以排查RAG类问题时我建议把80%的精力放在“最终上下文长什么样”上而不是一开始就怀疑向量库召回率不行。上下文是模型唯一消费的东西它如果没有把准确的证据放在正确的位置再好的召回模型也救不回来。5.3 修复方案与验证结果修复动作从索引层一路做到提示词层从上到下补了四个口子。第一所有文档写入索引之前强制校验版本号和生命周期状态旧版状态的文档禁止进入检索结果这个用索引过滤器就解决了。第二重排序阶段加入时间衰减因子同样语义相关度下新近文档的得分加权更高衰减强度我取了半衰期策略避免一刀切杀死历史文档。第三压缩prompt里强制要求“输出必须保留原文档ID与版本号且禁止将不同版本的数值合并到同一结论”。第四输出端加了一条引用校验规则模型回答里出现的doc_id必须在本次输入上下文的证据集合里存在如果引用了一个不存在的doc_id就触发重新生成或返回兜底话术。修复之后我拉了一批历史query重新验证发现错误引用从几乎每周都有爆发降到了连续四周为零漏答率也从8.1%降到了1.2%左右。复盘结束后我最大的教训是线上RAG系统出问题通常不是单个环节坏了而是上下文在链路里被悄悄污染了。没有来源健壮性再聪明的模型都帮不了你。6. 2026年做上下文工程的三个绕不开的坑6.1 上下文从哪来数据血缘与来源标注第一个必须补的习惯是给每一条上下文记录建立数据血缘。所谓数据血缘就是得能回答“这条结论是从哪个文档、哪个版本、哪个时间点来的”。企业知识库的问题比通用场景严重得多同一套政策可能一年改三次每次改版都会产生“新旧并存”的窗口期。如果不带版本标记模型在这个窗口期里就很容易把旧内容当成当前有效内容。具体落到操作上入库前给每份文档生成唯一document_id对该文档内容做hash存成指纹所有引用片段在拼入上下文时都带上这两个字段。输出阶段再用引用校验规则去核对一旦发生结果与上下文不一致就能顺着doc_id迅速定位到具体来源。这套机制早期投入大约一到两个人日但省下的排查时间可能是一个数量级。6.2 上下文往哪放缓存、路由与版本管理第二个坑是很多人把上下文工程做成了每次请求都现拼现用。再漂亮的组装逻辑只要每次都全量重跑延迟和成本就下不来。正确做法是把上下文分层处理完全静态的系统上下文在产品发布时已经可以预编译好直接走模板缓存用户的基础画像和业务标签按用户维度做短期缓存检索召回结果可以做语义缓存让相同或近似的问题直接命中历史结果这一步在客服类应用里收益尤其明显。但缓存最容易被忽视的是版本管理。指令模板一旦调整旧缓存全部要失效否则用户会继续看到旧说法的答案。我给模板文件加了一个content hash每次发布后缓存键里带上这个hash模板一改缓存自动切新键。这个方法成本低且有效强烈建议直接抄。6.3 成本与延迟token是预算不是无限资源第三个坑也是2026年必然会被越来越多人关注的坑token就是钱也是延迟。我见过不少团队为了追求“信息全面”把证据层塞得满满当当结果响应速度和成本全部爆炸。上下文工程在一定程度上就是预算管理每一层能拿到多少token应当提前定好上限。比如系统层固定200token任务层不超过300token证据层最多1500token超出部分要么压缩要么丢弃。为了能在大流量下做实时控制我写了一个极简的token预算器原理不复杂会在组装前先估算每个块的长度超预算的直接跳过或交给压缩模块处理def estimate_tokens(text: str) - int: # 中文场景下粗略估算汉字约等于1个token英文字符粗略折半 cjk_chars sum(1 for c in text if \u4e00 c \u9fff) return int(cjk_chars (len(text) - cjk_chars) / 2) 16 def enforce_budget(blocks, budget4000): total 0 kept [] for block in blocks: cost estimate_tokens(block[payload]) if total cost budget: continue kept.append(block) total cost return kept这个预算器看似简单但它是整个上下文工程稳定运行的最后一道保险。线上请求每秒进来几十个人工肉眼检查token预算是不现实的必须用代码做截断。我踩过几次坑之后的体会是上下文工程做得好不好取决于你愿不愿意把它当成一份长期维护的预算与信任管理活来做而不是靠一两个花哨模板一劳永逸。2026年如果你还在为RAG的效果发愁不用急着换框架先把自己系统里的上下文资产盘清楚把来源标记、压缩规则、缓存失效这三件事补上大概率比你想象的更有效。