长上下文高效处理：从压缩、加速到主动搜索
面向读者：有基础 LLM 知识的开发者
一、问题：长上下文，长烦恼
Section titled “一、问题：长上下文，长烦恼”过去两年，大语言模型的上下文窗口从 4K 一路扩展到了 1M 甚至更长。听起来很美——把整本书、整个代码库扔进去，模型就能理解一切。但现实骨感得多。
长上下文处理面临三重困境：
1. 记忆衰减——“读了后面忘了前面”
即使模型技术上能接收 100 万 token，也不意味着它真的”理解”了 100 万 token。就像你一口气读完《战争与和平》，读完最后一页时，第一章的细节早已模糊。注意力机制在超长序列上会出现”中间遗忘”现象：位于上下文中部的信息最容易被忽略。
2. 推理成本——“钱和时间都扛不住”
Transformer 的自注意力机制计算量随序列长度二次增长。100 万 token 的推理成本不是 10 万 token 的 10 倍，而是 100 倍。对开发者来说，这意味着每次长上下文调用都在烧钱，延迟也在飙升。
3. 信息稀疏——“大海捞针，95% 都是水”
长文档中与具体任务相关的信息往往极度稀疏。一份 10 万字的财报里，你关心的可能只是三段话。让模型通读全文再回答问题，就好比为了找钥匙把整栋房子拆了。
这三个问题不是孤立的，它们相互加剧：记忆衰减使得必须反复处理信息→成本上升；高成本迫使减少上下文→信息遗漏；信息稀疏意味着大量无效计算→浪费更严重。
2026 年 5 月，三篇论文分别从三个角度给出了破解之道。
二、统一框架：三条路径，一个问题
Section titled “二、统一框架：三条路径，一个问题”在深入每篇论文之前，先用一个统一的类比建立直觉。
想象你要在一座巨大的图书馆中完成一项研究任务。你有三种策略：
- 策略 A：压缩管理 —— 你不可能把所有书都摊在桌上，但你可以在桌上放精心整理的笔记卡，每张卡片指向原始书页。需要细节时随时回去查。这是 LCM 的思路。
- 策略 B：并行加速 —— 你雇佣多个助手同时验证不同章节的内容，而不是一个一个顺序检查。这是 PARSE 的思路。
- 策略 C：主动搜索 —— 你不试图读完整个图书馆。你先看目录，锁定相关区域，然后深入阅读那些区域。这是 SCOUT 的思路。
三条路径瞄准同一个目标：用更少的计算，获取更精准的信息。
三、LCM——给 LLM 一个确定性的外部大脑
Section titled “三、LCM——给 LLM 一个确定性的外部大脑”LCM（Lossless Context Management）的核心洞察是：不要让 LLM 自己管理记忆，给它一个确定性的外部框架。
这个想法来自一个精妙的类比：编程语言中 GOTO 到结构化控制流的转变。1960 年代，Dijkstra 著名的「GOTO 有害论」指出，无限制的跳转让程序不可控。解决方案不是禁止跳转，而是提供 for、while、函数调用等结构化原语——用受限但可控的机制替代自由但混乱的行为。
LCM 把同样的逻辑应用到了 LLM 的记忆管理上。当前的做法（包括所谓的”递归语言模型”）让模型自己决定何时回忆、何时遗忘、何时开始新任务——这就像让程序随意使用 GOTO。LCM 则把递归分解为两个由引擎管理的确定性机制：
- 递归上下文压缩：通过层次化的摘要 DAG（有向无环图）自动压缩旧消息，但保留到所有原始内容的无损指针。就像压缩文件——体积变小了，但随时可以解压还原。
- 递归任务分区：用引擎管理的并行原语替代模型自写的循环。模型不需要自己写 for 循环，引擎帮它分片执行。
为什么”无损”很重要
Section titled “为什么”无损”很重要”以往的上下文压缩方案（如滑动窗口、摘要压缩）都会丢失信息。你压缩了上下文，模型就再也无法访问被丢弃的内容。LCM 的 DAG 结构确保了：虽然工作区是压缩的，但所有原始内容都通过指针可达。需要时，引擎自动展开相关部分。
基于 Opus 4.6 的 LCM 增强编码代理 Volt，在 OOLONG 长上下文评测中，从 32K 到 1M token 的所有长度上都超越了 Claude Code。注意，这不是微弱优势——在 1M token 级别，传统方法的性能已经开始急剧下降，而 LCM 保持了稳定。
把 LCM 想象成一个极其高效的秘书。你（LLM）只需要关注当前桌上的文件（压缩后的工作上下文），但秘书维护着一个完美的索引系统（DAG 指针），你需要任何历史文件时，秘书立刻递给你。你不管理文件系统，你只管思考。
四、PARSE——一次验完，不要排队
Section titled “四、PARSE——一次验完，不要排队”PARSE（Parallel pRefix Speculative Execution）要解决的问题是：如何加速 LLM 的推理？
要理解 PARSE，先要理解投机解码（speculative decoding）。投机解码的思路和 CPU 的投机执行类似：用一个小的”草稿模型”快速生成候选文本，然后让大模型验证这些候选是否正确。如果正确，就直接接受，省去了大模型逐步生成的开销。
传统投机解码的瓶颈在于验证：大模型必须逐个 token 检查草稿是否正确，这个过程是串行的。就像考试批改——一个助教写完了答案，教授得一个一个检查，不能跳着看。
PARSE 的创新在于：把验证从 token 级别提升到语义前缀级别。给定一个完整的草稿，目标模型在单次前向传播中同时评估多个前缀的正确性。不再一个一个检查，而是一次性并行验证。
关键技巧是自定义注意力掩码（attention mask）。在 Transformer 的前向传播中，注意力掩码决定了每个位置能”看到”哪些其他位置。PARSE 设计了特殊的掩码结构，使得模型在一次 forward pass 中可以同时评估多个不同长度的前缀。
这就像教授批改试卷时，不是逐题检查，而是用一种特殊的阅读方法，一眼就能看出”前 N 题是否全对”。找到最长的正确前缀后，直接接受，省去了中间所有正确 token 的逐一验证。
PARSE 在多个模型和基准上实现了 1.25× 到 4.3× 的吞吐量提升。更关键的是，它可以和现有方案叠加——与 EAGLE-3（另一种投机解码方案）组合后，加速比可达 1.6× 到 4.5×。
想象你在玩打字游戏。传统方式是：打一个字母，检查对不对，再打下一个。投机解码是：先盲打一串字母，然后回头检查。PARSE 是：盲打一串字母，然后一眼看出”从开头到哪里是对的”——不需要逐字母检查。这种”一眼”的能力来自 Transformer 架构本身的并行性，只是之前没人这样利用它。
五、SCOUT——不读完，够用就行
Section titled “五、SCOUT——不读完，够用就行”SCOUT（Active Information Foraging）的核心洞察极为简洁：相对于完整文档，查询相关信息通常极其稀疏，因此有效推理应依赖查询充分的子集，而非整个上下文。
传统的长文本理解方法是”先读后答”：把整个文档塞进上下文，然后让模型回答问题。SCOUT 转向了”边找边答”的范式——将文档视为可探索的环境，根据问题主动搜索相关信息。
这种方法被称为”主动信息觅食”（active information foraging），借用了生态学中的觅食理论：动物不会遍历整片森林寻找食物，而是根据线索高效地在食物密集区域觅食。
SCOUT 的关键机制是一个逐步收缩的”认识状态”（epistemic state）：
- 初始状态：从文档的粗粒度信息（如目录、段落标题）开始
- 差距诊断：评估当前认识状态与回答问题所需信息之间的差距
- 粗到细探索：根据差距诊断，选择最可能有用的区域深入阅读
- 锚定更新：将新发现的信息整合到认识状态中
- 循环：重复诊断→探索→更新，直到认识状态足以回答问题
这个过程就像侦探破案：先看现场概貌（目录），锁定可疑区域（差距诊断），深入调查那些区域（粗到细探索），逐步缩小嫌疑范围（认识状态收缩），直到找到答案。
SCOUT 在匹配最先进专有模型性能的同时，token 消耗减少了最多 8 倍。而且这个节省比例在更长文档上保持稳定——这意味着文档越长，节省的绝对 token 数越多。
这篇论文被 ICML 2026 接收，学术质量有保证。
把 SCOUT 想象成一个会读书的学生。普通学生（传统方法）从第一页逐字读到最后一页，然后回答问题。SCOUT 式的学生先看目录，翻到相关章节，快速浏览确定是否需要细读，只在关键段落精读。两种学生可能考一样高的分，但 SCOUT 式的学生用的时间是前者的八分之一。
六、三者的关系与互补
Section titled “六、三者的关系与互补”这三篇论文并非互相竞争，而是高度互补的。它们分别优化了长上下文处理流水线的不同环节：
| 维度 | LCM | PARSE | SCOUT |
|---|---|---|---|
| 优化目标 | 记忆管理 | 推理速度 | 信息选择 |
| 核心策略 | 压缩+无损指针 | 并行前缀验证 | 主动信息觅食 |
| 类比 | 秘书的文件索引系统 | 教授一眼批改试卷 | 侦探的线索追踪 |
| 节省的 | 工作记忆空间 | 计算时间 | 输入 token 数 |
理想的系统可以同时采用三者：用 SCOUT 主动选择需要的信息，用 LCM 管理压缩后的上下文，用 PARSE 加速推理生成。这不是空中楼阁——三者在架构上是正交的，组合部署在工程上完全可行。
它们共同指向一个趋势：从”让模型处理一切”转向”给模型更好的基础设施”。模型的参数量和训练数据不是唯一的 Scaling 轴——推理时的信息管理策略同样是一条重要的 Scaling 路径。
七、给开发者的实践建议
Section titled “七、给开发者的实践建议”理解了这三篇论文的思想后，以下是使用长上下文 LLM 时的实际建议：
1. 不要一股脑塞全文
Section titled “1. 不要一股脑塞全文”SCOUT 的教训：如果任务只用到文档的一小部分，先做信息筛选，而不是把整个文档扔给模型。实践中，可以先用一次轻量调用提取文档结构和关键段落索引，再用第二次调用处理筛选后的内容。两次便宜调用往往比一次天价调用效果更好。
2. 给模型外部记忆，而不是依赖上下文窗口
Section titled “2. 给模型外部记忆，而不是依赖上下文窗口”LCM 的教训：把重要的上下文信息存储在外部（文件、数据库、向量检索系统），按需检索注入，而不是试图全部塞进上下文窗口。这也是 RAG（检索增强生成）的核心思想，但 LCM 进一步强调了”无损指针”的重要性——不仅要检索到内容，还要保持内容的完整可溯源性。
3. 利用推理加速技术降低成本
Section titled “3. 利用推理加速技术降低成本”PARSE 的教训：如果你在批量处理长上下文请求（如文档摘要、代码审查），投机解码 + 并行验证可以显著降低推理成本。关注你使用的模型 API 是否支持投机解码，或者考虑部署支持此类优化的推理引擎。
4. 分层处理，粗到细
Section titled “4. 分层处理，粗到细”综合 SCOUT 和 LCM 的思想：对长文档采用分层处理策略——先看目录/摘要（粗粒度），锁定重点区域，再深入阅读（细粒度）。这既减少了 token 消耗，也缓解了中间遗忘问题。
5. 关注语义级操作而非 token 级操作
Section titled “5. 关注语义级操作而非 token 级操作”三篇论文的共同趋势：效率优化正在从 token 级别提升到语义级别。无论是语义前缀验证（PARSE）、语义压缩摘要（LCM）还是语义信息觅食（SCOUT），都在说同一件事——理解和操作”意义”比操作”符号”更高效。在你的应用设计中，也要优先在语义层面进行信息管理和检索。
长上下文处理是当前 LLM 应用落地最关键的瓶颈之一。2026 年 5 月的这三篇论文展示了三种互补的解决路径：
- LCM 证明了确定性的外部记忆管理可以超越模型自管理——不要让模型既当运动员又当裁判
- PARSE 证明了 Transformer 架构内部还有大量未被挖掘的并行潜力——关键在于换个角度设计注意力模式
- SCOUT 证明了”少即是多”——主动选择比被动处理更高效
它们的共同主题是：更聪明地使用模型，而不是使用更大的模型。这对每个 LLM 应用开发者都有直接的启发意义。
本文基于 arXiv:2605.04050、arXiv:2605.04263、arXiv:2605.04572 撰写。