从RAG到上下文工程：解决大模型“Lost in the Middle“问题，看这一篇就够了！建议收藏！

本文深入探讨AI大模型Lost in the Middle问题即模型难以处理长上下文中间信息。这一问题源于Transformer架构的Attention机制、训练数据分布偏差及RoPE编码衰减。文章提出上下文工程解决方案包括五大实践上下文卸载、压缩、任务隔离、分层动作空间和精细化Prompt帮助开发者优化注意力分配提高Agent在复杂任务中的表现。2023年刚开始搞AI业务落地时写了篇RAG的文章https://www.zhihu.com/question/625481187/answer/3313715960当年我们刚开始探索AI落地时最大的焦虑是模型“不知道”那会的痛点集中在怎么通过外挂知识库来解决幻觉问题模型的上下文窗口有限怎么在这最宝贵的窗口中塞入最有效的信息尽管当时还没有“上下文工程”这一概念但是上下文的重要性在那时候已经体现。只不过对于当时的模型来说“上下文”是稀缺的。或者说那时候大家的认知还停留在只要上下文足够充足模型就能解决一切。短短两三年过去随着 Agent 浪潮的爆发我们面临的挑战发生了一百八十度的逆转现在的焦虑不再是模型“不知道”而是它“知道得太多了”。主流先进模型的上下文窗口从当时的8K提升到128K再到目前甚至可以支持1M这样庞大的上下文窗口。另外模型的推理成本也越来越低。还有就是模型支持的模态也从纯文本到现在的多模态图片、视频等内容的理解也可以直接端到端的进行。仿佛我们只要做的就是把能够获取的信息一股脑的塞满给模型就行了。这样做的问题是什么Agent落地难的根本原因从现在Agent的落地情况看幻觉仍然还是个避不开的问题。传统的Agent开发中当我们将数十个工具描述、上百页文档塞进那看似无限的 Context Window 时模型并没有变得更聪明反而开始迷失。模型的上下文窗口成为过剩资源后那什么变成稀缺资源了答案是模型的“注意力”没错就是Attention is all you need中最本质的概念注意力。当上下文无限膨胀模型的注意力却也被稀释的很严重。早在2023年业界就已经提出了模型的Lost in the Middle问题即当给大语言模型提供长上下文Long Context时模型往往能很好地利用位于开头和结尾的信息但对于位于中间部分的信息检索和利用能力会显著下降呈现出一条显著的 “U型” 性能曲线。这个问题在当下主流的大模型仍然存在。这对在开发长流程 Agent比如目前最流行的Deep Research功能基于搜索到的上百篇网络文档进行深度研究和梳理。Coding目前的Vibe Coding工具对整个代码库进行重构造成了很大的阻碍。开发时会经常遇到这个诡异现象模型能清晰记得 System Prompt 中的指令开头也能完美响应用户的最新追问结尾但对于中间检索到的文档或执行过的步骤往往视而不见。这个问题导致了目前的Agent在解决实际问题时往往不尽如人意。面对这种资源过剩但效率低下的窘境我们必须承认大模型的上下文窗口不再是廉价的硬盘而是昂贵的、需要精细管理的显存。简单的填鸭式投喂Prompting已经失效。为了在长流程任务中维持模型的清醒与专注一个新的技术范式应运而生上下文工程。上下文工程的核心目标就是对抗模型的遗忘与迷失。让模型在每个步骤能够获取最有价值的信息是一种“取舍”的艺术。我们首先从技术底层来看看“Lost in the middle”的成因。病理剖析为什么模型会“视而不见”Lost in the Middle 并非玄学而是 Transformer 架构中数学原理与训练数据分布共同作用的必然结果。训练数据分布模型是数据的镜像。所谓“压缩即智能”模型实际上学到的是人类所有数据的总和然后用一种精妙的模式预测下一个词。在模型的学习阶段或者说预训练和微调阶段模型接受到的数据往往呈现一种结构化的偏差大模型学习的是即从现有的文本输出下一个词的概率。在人类自然语言文本论文、新闻、小说中信息分布通常是不均匀的开头通常是摘要、定义、背景介绍高信息密度。结尾通常是结论、总结、最新进展高信息密度。而中间通常是论证过程、细节描写或罗列数据。模型在预训练阶段就习得了“关键信息往往在开头或结尾”的先验概率分布。当它处理长文本时它会倾向于认为中间部分是“过程量”而非“结论量”。在指令微调阶段Prompt 的结构通常是[System Instruction][Context / Documents][User Query]模型被强化去响应 System Instruction位于最前和User Query位于最后。夹在中间的 Context 往往是被动参考。如果微调数据中缺乏针对“中间段落检索”的强监督信号即 “大海捞针” 类的针对性训练模型就会偷懒只看头尾。Attention机制的“稀释”从Attention的公式出发罪魁祸首其实就是这个softmax函数。Softmax 是一个归一化函数它的铁律是输出的所有概率之和必须等于 1。无论上下文窗口是 4k 还是 128k这个“1”的总预算是不变的。在针对流式推理Streaming LLM的研究中发现了一个有趣的现象Attention Sink。研究者发现如果强制把开头几个 Token 的 KV Cache 丢掉模型的 Perplexity (困惑度) 会瞬间爆炸。原因是Softmax 需要所有分数加起来为 1。如果当前 Token 对之前的任何内容都不太感兴趣它需要一个“垃圾回收站”来安放这些剩余的概率。结果导致模型往往将大量的注意力分数分配给序列的起始 Token通常是start token 或 System Prompt。这意味着序列开头的 Token 在 KV Cache 中占据了统治地位进一步压缩了中间 Token 能够获得的注意力预算。当序列长度 极度增加时例如从 4k 到 128k分母上的项数变多。如果没有极其强烈的信号中间大量的 Token 会产生很多微小的 Attention Score。这些Attention Score在运用于fp8甚至int4推理量化降低成本时在量化截断后这些微弱的信号很容易变成数值噪声或者直接被量化为 0。这种累积误差导致中间的内容更加不受关注。RoPE编码带来的长期衰减RoPE 的设计初衷之一是让 Attention Score 随着相对距离的增加而自然衰减。远距离衰减指的是随着q和k的相对距离的增大加入位置编码之后的内积应该随着距离增大而减小这样相当于离得远的token分配到的attention会比较小而离得近的token会得到更多的注意力。这导致了Attention Score又有两头占优的情况。结尾Query距离自身最近相对位置编码带来的衰减最小Attention 权重天然较高。开头System Prompt虽然距离 Query 最远但因为它是整个文本序列的“锚点”且在训练中始终存在模型学会在特定 Attention Head 中对绝对位置靠前的 Token 保持高权重。上文提到的Attention Sink现象就是这种情况。中间既没有近距离带来的小幅度衰减的加持又没有“起始锚点”的特殊地位加上距离 Query 较远在 RoPE 的高频分量旋转下其特征容易变得模糊。总之“Lost in the Middle” 并非单一原因造成而是从算法底层到数据分布的系统性结果模型机制Softmax 的归一化导致中间信息的注意力被稀释且位置编码对长距离非首尾信号支持较弱。训练数据自然语言“头尾重要”的分布偏差以及 SFT 中对首尾指令的过度强化。当然了目前业界也使用了很多方法来缓解这个问题。但是我们在应用落地的一线不能坐以待毙更不能把业务的稳定性寄托在黑盒模型偶尔的“超常发挥”上。上下文工程既然我们无法目前暂时没法打破模型层面的瓶颈来创造无限的注意力那么解决问题的唯一路径就是改变注意力的分配方式。这就是上下文工程诞生的意义。其实上下文工程和目前的计算机体系架构已经特别像了类比一下解决的是以下几个问题什么是必须留在内存上下文里的什么是可以存进硬盘外部存储的什么时候该清理内存冗余上下文什么时候该并行处理基于 Manus、Anthropic 等顶尖团队的实战经验为了让 Agent 在处理复杂长流程任务时不再“迷失”我梳理出了以下 五大上下文工程最佳实践。这套方法论的核心就是要在有限的注意力预算下实现模型效能的最大化。上下文卸载Offloading原则不要将所有信息都堆在消息历史中。对于网页抓取的结果、文档、CSV 数据等可能带来超长上下文的内容应该存储到文件系统或沙箱环境中模型接受的信息应该只是文件路径或极简引用。这个信息通常只包含文件路径、执行状态、以及一小段核心摘要例如{status: success, file_path: /sandbox/data/search_results.csv, preview: 已找到50家公司的财务数据}这样模型可以意识到完整数据已安全存储在外部它可以根据预览信息决定下一步是继续搜索还是深入读取该文件。当模型需要获取文件中的具体信息时它不应直接读取所有的内容而是做一些精细化的检索机制进行精确打击。比如使用Sandbox原生的能力可以通过 shell 命令调用 grep、cat、head 或 tail 来处理结果如果文件极大模型会执行 grep “关键词” /path/to/file 来只获取文件中相关的行。对于极其复杂的分析如分析 1GB 的日志主 Agent 可以指定一个专门的Subagent在独立的上下文空间里读完文件总结出符合规范的结果后再将精简的结论返回给主Agent。我们可以看到目前很多主流的Coding Agent产品其实都是这么做的比如Claude Code在重构你的代码时会大量使用grep来搜索跟你关心的模块的代码内容而不是去读取整个代码库。上下文压缩Reduction当必须保留在上下文中的信息接近“预腐败阈值”实践中通常为 128k-200k tokens时我们需要进行压缩。这里的压缩和我们平时理解的自由文本摘要并不同。而是要仔细规范一个具体的Schema让另外的LLM根据这个Schema来填充真正的关键信息。from pydantic import BaseModel, Fieldfrom typing import List, Optional# 定义摘要的Schemaclass ContextSummary(BaseModel): current_goal: str Field(..., description当前阶段的主要目标) completed_tasks: List[str] Field(..., description已完成的关键任务列表) next_immediate_step: str Field(..., description下一步的具体行动) key_files_modified: List[str] Field(..., description重要且相关的文件路径列表) open_questions: Optional[str] Field(None, description尚未解决的问题或障碍)# 假设我们有一个函数调用 LLM 进行摘要def summarize_history(message_history: list) - ContextSummary: summary llm.chat_with_structure( messagesmessage_history, response_modelContextSummary, prompt请根据当前对话历史总结关键进展。必须严格遵守输出格式。 ) return summary# 压缩后的新上下文可能只包含一个系统提示和这个结构化的摘要new_context [ { role: system, content: ..., summary: summary.model_dump_json(indent4) }]除了这个方式Manus建议在需要执行压缩时进行一个“可逆压缩”的步骤遍历消息历史将所有已写入文件或已转储沙箱的大段内容如 file_content直接剔除只保留其引用的 file_path。因为文件已经在文件系统里了模型随时可以通过路径重新读取。这种压缩是完全可逆的不会丢失任何推理依据。任务隔离Isolation—— 从单线程到并行处理这是解决Agent长流程任务的最有效方法。放弃顺序处理模式将复杂任务分解为 个独立的子任务部署 个并行子代理。比如Deep Research这种Agent并不需要一篇一篇文档这么顺序研究而是直接并行研究每个子Agent的上下文仅有需要研究的这篇文档这彻底消除了上下文污染确保处理第 50 个文档时的质量与第 1 个完全一致。这种方式类似大数据处理的Map Reduce模式没有顺序依赖的任务不妨这么做。分层动作空间这是解决过多工具塞入同一个上下文导致的“上下文混淆”问题模型在各种场景下不知道该用哪个。Level 1 原子能力保留 10-20 个核心 API 调用如读写文件、执行 Shell。Level 2 沙箱工具将复杂能力如 PDF OCR、视频转码封装在沙箱的 CLI 接口中。Agent 通过 Shell 调用利用 --help 自行学习用法。这大大减少了 Prompt 中的工具定义部分。相比于在 Prompt 中定义一个复杂的 ocr_pdf(file, pages, language, output_format…) 函数不如提供一个通用的 Shell 工具tools [ { name: run_shell_command, description: 在沙箱环境中执行 Shell 命令。用于调用 CLI 工具或操作文件。, parameters: {type: object, properties: {command: {type: string}}} }]# Agent 的实际调用过程# 1. Agent 发现需要处理 PDF尝试探索# Agent: run_shell_command(commandocr-tool --help)# 2. 系统返回 CLI 的帮助文档# System: Usage: ocr-tool [OPTIONS] INPUT_FILE\nOptions:\n --lang TEXT ...\n --output TEXT ...# 3. Agent 自行构建复杂的命令# Agent: run_shell_command(commandocr-tool /mnt/data/report.pdf --lang chi_sim --output result.txt)Level 3Agent as Tool将复杂的子工作流Workflow封装为一个“工具”。主 Agent 只需调用该工具并接收符合 Schema 的最终结果而不必关心子流程的几十步操作。精细化Prompt让Agent尽量多输出思维过程要求 Agent 在调用工具前先输出它对当前情况的评估、计划尝试的工具以及预期的结果。这增加了模型推理的计算量但有助于提高准确性。由广入深通过提示词强制 Agent 模拟人类专家。然后先进行广度搜索了解全局如先 ls -R 看清目录结构再逐步缩小范围深入细节避免一开始就钻入牛角尖。总结做一个好用的 Agent底层依赖的往往不是什么惊天动地的“屠龙之术”而是这些看似不起眼的、点点滴滴的细节。在这波大模型落地的早期我们总是期待有一个“全知全能”的模型横空出世通过无限大的上下文窗口解决所有问题。我们迷信参数的规模迷信窗口的长度仿佛只要模型够强工程就不再重要。但大模型到目前为止不是魔法它只是一个新的计算组件。就像 CPU 需要缓存机制数据库需要索引策略一样大模型也需要精密的上下文工程来辅助其运转。伟大的产品往往就诞生在对这些细节的极致掌控之中。如何学习AI大模型作为一名热心肠的互联网老兵我决定把宝贵的AI知识分享给大家。 至于能学习到多少就看你的学习毅力和能力了 。我已将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。