导言

通过阅读本文你将了解：

1. 如何使用小模型战胜具有长上下问的大模型
   

2. 具体的方法，以及评估结果

3. 下载相关研究论文

关注公众号，后台发送"小模型长文本"获取 相关研究论文

对我来说，上下文是关键 - 从中可以理解一切 - Kenneth Noland

LLMs现在随处可见，并已从实验产品发展为真实世界应用的产品。一旦这些模型投入生产，上下文窗口的长度，就会被作为一个重点进行讨论。

Transformer的挑战

上下文窗口定义了模型可以处理多少tokens。 

模型可以在任何给定时间处理的标记越多，它就可以关联更多的概念和信息。更大的上下文长度允许模型记住与用户的长对话，或者用户可以询问关于长文档的问题。

这听起来很有趣，但代价又非常巨大。

随着上下文长度的增加，计算成本呈平方增长。

避免昂贵的上下文窗口的一种方法是利用检索增强生成（RAG）等方法，其中额外的知识存储在数据库中。这样做的好处是我们可以将知识存储在外部数据库中，并且仅找到我们任务或查询所需的内容。

有人认为RAG无法从模型在上下文长度内进行的推理中受益，因此一些主要公司一直在推动开发具有更长上下文长度的模型  

许多模型最初具有较短的上下文长度（例如，Llama-1的2K，Llama-2的4K，Llama-3的8K），然后通过后续方法进行扩展。尽管这些方法似乎效果良好，但实际上，仍然无法确定模型是否真正使用了上下文长度。

我们真的需要一个长上下文模型吗？

具有1百万Tokens的Context窗口

理论上 Gemini 1.5 Pro 和 1.5 Flash 都具有最多一百万标记的默认上下文窗口，可以解锁了处理长文档、数千行代码、数小时音频、视频等的能力。

从理论上讲，对于某些任务，这显然是有利的。

例如，在摘要任务中，如果我们想要总结一本书，具有长上下文长度的模型具有优势。事实上，模型了解了书中人物之间的一系列关系。

较小的上下文长度意味着我们必须进行一些分块处理，而某个角色可能在不同的分块中被命名（因此模型可能不会意识到与另一个角色的特定关系）。或者用于推理整个文档，使模型能够在提示中包含所有内容。

然而，对于许多其他任务：我们并不需要所有这些计算：

一个小模型（加上可能的RAG）就足够了

然而，有些作者认为，即使对于通常被认为需要长上下文的任务，我们也需要一个具有小上下文窗口的模型。我们甚至可以用一个小模型来解决这些任务，这怎么可能？

如果有一件事是思维链教给我们的，那就是几乎所有任务都可以分解为子任务。思维链具体参见：使用大模型进行Reasoning: Chain-Of-Thought， 以及大模型 细节综述

对于知识也是如此，它可以被分解，只有某些元素是真正重要的。例如，对于摘要任务，只有一些事实对任务真正重要。

上述论点类似于人类和现代计算机的工作模式：任意长的问题总是可以在有限的内存容量上分解和解决。记得很早前看过一本搜索引擎的书， 通篇在讲如何在4M的内存中构建搜索引擎。

然而，这并不是一件简单的事，因为很难制定一个关于如何成功以可分解的方式解决长上下文的经验法则。

最近，有一种新方法是可以自适应地处理长上下文，并选择必要的信息，而无需长上下文的LLM。 

长LLM对长上下文任务是否必要？

这篇文章最有趣的一点之一是，它在理论上（然后是经验上）讨论了一个重要问题：

大多数长上下文任务是否可以用短上下文解决？

根据作者的说法，可以在上下文X中始终找到可以回答用户问题的信息子集（或者至少在理论上是这样）。

实际上，这是比较困难的，特别是如果上下文X相当大。

对他们来说，解决方案在于将X分成几个子集，并分别处理每个子集。完成后，必须找到回答问题所需的最小上下文。为了估计这个最小必要上下文，可以使用压缩函数和替代品。

使用类似的方法或蛮力（长上下文）对GPT4（具有128K上下文长度）几乎产生相同的结果。

作者随后对具有4K上下文长度的模型采用了相同的方法进行了测试。

名为LC-Boost的系统是对文档中获得的各种短上下文的迭代过程。

该系统可以执行多种操作。它从将上下文分解为一系列分块（小上下文）并通过分析查询来理解任务开始[任务理解]。

此时，模型分析所有不同的分块（i到n）。然后，它使用检索找到分块[检索]，然后可以转移到下一个分块[移动]。同时，它会跟踪相关的上下文（分块），并决定是否追加新的分块[追加]或合并信息[合并]。

最后，系统可以直接回答[回答]或对所有相关信息进行聚合并返回[聚合]。模型然后选择必要的操作。    

该系统非常灵活，因为它可以在非固定的轨迹中找到所需的和新的上下文（[检索]和[移动]操作），而无需扫描整个上下文。

此外，该系统可以准确存储信息，因为它可以根据需要决定是追加还是聚合（[追加]和[合并]操作）。该系统还允许动态回答，因为它可以直接回答短问题（[回答]），或者为摘要等任务生成长答案（[聚合]）：

在文章中，作者选择了一些具有小上下文（对作者来说小于32K）和其他具有长上下文（大于32K，包括开源模型如Mistral-7B-Instruct-v0.2–32K和闭源模型如Claude）。

具有4K上下文长度的LC-Boost在所有任务中都优于所有基线模型，除了代码补全任务。实际上，对于编码任务，长上下文可以帮助更好地理解各个组件之间的关系。

在研究中，作者表明：

• 对于每个查询的动态选择是有利的，因为它允许答案适应每个特定的查询。

• 该系统对于单文档问答（QA）和多文档QA任务都很有效。因此，即使上下文在多个文档中，它也能够再次找到。对他们来说，该系统比长上下文更加实用，因为它可以过滤掉无关的信息。

• 在少样本设置中，LC-Boost并没有显著优于固定策略。由于已经有了几个例子，使用自适应策略就不那么有用了，因为已经有了与任务相关的信息。    

作者还展示了来自自建数据集的案例研究示例（这个数据集呈现了特别困难的例子，因为它们需要跨整个长上下文进行推理）。

长上下文的模型在解决问题时往往无法生成正确的响应（尽管整个上下文可以进入提示）。这与先前的结果一致，显示LLMs并不高效地使用上下文：

相反，他们的系统使用短上下文解决了问题。据他们称，因为该系统动态地适应每个问题。特别是对于数字任务，LC-Boost可以聚合信息，这使得模型更容易解决任务。    

LLM的最近爆炸式使用也导致了巨大的能源消耗。这些模型在训练时需要大量的计算和能源成本。然而，如今它们也被普遍使用，这也意味着推理中的能源消耗大幅增加。

所有任务都可以用小上下文解决？

可能有更复杂的任务需要长上下文。例如，在需要编程的任务中，模型似乎表现不如长上下文模型好。尽管该模型很优雅，但在连续空间中预测行动会更有优势（而不是离散的一组行动）。然而，这需要具有强大推理能力的LLM（可能是庞大的，因此在推理中需要更多时间）。

但大多数场景，小魔型足够了。

关注公众号，后台发送"小模型长文本"获取 相关研究论文