最近大模型发展的一个方向是长上下文窗口，比如谷歌gemini 1.5 pro的上下文窗口是200万Tokens，Kimi号称也有200万上下文窗口（不知道真假？反正Kimi回答是20万，anyway扯远了）。
很多训练之后模型的上下文窗口一般也只有4k：8k，但为了满足长上下文窗口的需求，一般会使用LongRoPE的方法扩展上下文窗口，比如最近特别热门的Phi-3只有4k上下文窗口，但通过LongRoPE扩展到了128k。
那么长上下文任务是否非得长上下文大语言模型来？
答案是否。最近人民大学人工智能研究院和北京人工智能研究院联合发表一篇关于上下文任务的论文《Are Long-LLMs A Necessity For Long-Context Tasks?》（《长上下文大语言模型是否是长上下文任务的必需品》）。
摘要
这篇论文的核心内容是探讨长上下文任务(Long-Context Tasks)是否一定需要长上下文模型(Long-LLMs)来解决。作者提出，
大多数长上下文任务实际上是可以通过短上下文(Short-Context)来解决的，即通过策略性地处理长上下文输入中的短上下文片段
。
基于这一观点，论文提出了一个名为
LC-Boost
（Long-Context Bootstrapper）的框架，
使短 LLM 能够通过根据所呈现的任务自适应地访问和利用上下文来解决长上下文任务
。换句话说，它将长上下文分解为短上下文，并使用决策过程对其进行处理。这也是
将复杂任务分解为简单步骤的好处的另一个很好的例子
。在这种情况下，访问上下文（即计划访问上下文）和利用上下文（即有效利用访问的上下文）的任务是根据任务的性质自适应地执行的。
大多数人都试图将 LLM 用作“万能”技术。如果您能先了解其基本功能，然后利用这些优势解决子任务并找到合理的解决方案，那么 LLM 会更有用。
方法
LC-Boost框架的核心方法包括两个关键的推理步骤——访问（Access）和利用（Utilize）。具体来说：
1. 访问（Access）：短上下文模型自我提示，决定如何访问输入中适当的上下文部分。
2. 利用（Utilize）：模型决定如何有效利用访问到的上下文。由于上述设计，LC-Boost能够根据其独特的性质自适应地处理多样化的长上下文任务。例如，给定一个基于知识的问答问题，LLM可以通过检索直接访问知识上下文，并以RAG的形式生成答案。此外，如果任务需要从整个输入中聚合特定信息，它可以逐块扫描长上下文。
下图为LC-Boost方法和传统方法的示意图：
LLM 被提示如何访问适当的上下文以及如何利用访问到的上下文来解决任务。
（A） 蛮力解决方案。尽管正确，但由于同时处理整个上下文而造成不必要的昂贵。
（B） 天真的 RAG。它很难处理像信息聚合这样的问题，这会导致答案不完整。
（C） LC-Boost 利用 RAG 来解决这个问题，以较小的成本产生正确的答案。
（D） LC-Boost 通过顺序扫描处理长上下文，根据全面收集的信息正确解决问题。
结果
实验表明，LC-Boost能够适应性地处理多样化的长上下文处理问题，通过自适应地访问和利用上下文，基于所呈现的任务。这种方法避免了直接处理整个长上下文，从而
显著减少了资源消耗，并且在多个长上下文基准测试中实现了大幅提升的性能
。
