TL;DR
直觉： 不要指望一个天才在一小时内读完一座图书馆。让十个实习生每人读一本书。
我们的研究《分治策略何时适用于长上下文大语言模型？》（ICLR 2026）引入了一个框架来研究这一问题。我们发现，使用战略性“分治”设计的较小模型可以在长上下文任务上匹配或超越 GPT-4o 的单次推理。
[论文，ICLR 2026] [代码]
现代大语言模型越来越支持巨大的上下文窗口，如 128K、200K，甚至 100 万以上的 token。这理论上解锁了强大的用例，例如在单个提示中分析整个代码库或总结整本书。
然而，“将所有内容放入一个提示”的承诺在实践中经常失败。随着上下文长度增长，性能以意想不到的方式下降。事实证明，“分治”是长上下文任务的一个有吸引力的解决方案，如下图所示。
“分治”框架。规划器重写任务描述。每个工作者处理长文档的一个子集，而管理者汇总信息并提供最终答案。
在我们的论文中，我们发现使用精心设计的“分治”框架的较弱模型可以在长上下文任务上匹配或超越 GPT-4o 的单次推理。
核心问题：长度的“迷雾”
我们如何充分利用这种“分治”方法在长上下文任务中的力量？我们将挑战分解为三个不同的噪声来源：
模型噪声（“脑雾”）： 模型不仅仅是线性遗忘；它们会变得不堪重负。我们的研究表明，模型困惑度随输入长度超线性增长。从数学上讲，拆分任务更好，因为每次处理较短的新块时，困惑度计数器都会重置。
任务噪声（“孤岛效应”）： 有时，一个块本身没有意义（例如，一个代词指代前一章）。这种“跨块依赖”在文本被拆分时会产生噪声。
聚合器噪声（“糟糕的总结”）： 即使工作者完成了工作，最终的管理者模型也可能无法正确拼接部分答案。
天真的“MapReduce”方法常常因为聚合器噪声而失败，即最终答案混乱或不一致，因为管理者缺乏上下文。我们的框架预测，如果通过更清晰的指令减少这种噪声，就可以释放较弱模型的力量。
“第二小的数字”示例： 考虑一个任务，工作者必须帮助在一个巨大的列表中找到第二小的数字。如果你天真地要求工作者在其特定块中“找到第二小的数字”，最终的管理者将失败，因为全局第二小的数字可能是某个特定块中最小的数字。
- 天真的提示：“找到第二小的数字。”（失败）
- 规划后的提示：“识别并返回两个最小的数字。”
通过简单地调整提示以考虑这种聚合噪声，我们确保管理者拥有正确的数据来计算全局答案。
通过实验验证理论
我们在多种任务（检索、问答、摘要等）上测试了这一框架实现。如下所示，使用该框架的较弱模型（例如 Llama-3-70B 或 Qwen-72B）优于一次性阅读全文的 GPT-4o。虽然单次模型（红色虚线）随着上下文长度增加而性能下降，但分治模型保持了高性能。
工程优势
从工程角度来看，该框架提供了三个巨大的实际好处：
更便宜： 将繁重的工作转移到更小、更便宜的模型（工作节点），而不是为旗舰模型的 token 付费。更快： 工作节点并行运行。避免了单次串行处理大量 128k token 上下文的高延迟。易于调优： 我们发现，由于噪声曲线的可预测性，仅测试 5 个随机样本就足以找到最佳分块大小。无需对整个数据集进行穷举搜索。该框架提供的另一个灵活性是通过分配不同的 LLM 后端来解耦工作节点和管理节点。
缺点：何时使用单次而非分治
这种方法并非万能。它最适合跨块依赖性适中的任务，如问答、检索和摘要。当任务噪声占主导时，优势消失。如果您的任务需要追踪从第 1 页到第 100 页的细微线索（如我们论文中的“对话角色推理”任务），则“分治”步骤会破坏必要的上下文。在这些高协同的情况下，阅读整个库的“天才”模型仍然是唯一的方法。更多详情请参阅我们的论文。