让大模型支持更长的上下文的方法哪个更好？训练支持更长上下文的模型还是基于检索增强？
在大语言模型中，上下文长度是指模型可以考虑的输入数据的数量。更长的上下文在大语言模型的实际应用中有非常重要的价值。当前，让大语言模型支持更长的上下文有两种常用的方法，一种是训练支持更长上下文长度的模型，扩展模型的输入，另外一种是检索增强生成的方法（Retrieval Augmentation Generation，RAG）。但二者应该如何选择，这是一个很少能直接比较的问题。为此，英伟达（Nvidia）的研究人员做了一个详细的比较。
大模型的上下文长度简介
通常，大语言模型都只有一个固定的上下文长度，这是因为这些模型在训练时使用了特定大小的窗口来查看数据。如果输入数据超过这个长度，那么可能会被截断。这可能会导致一些信息被忽略，尤其是当处理长文档或对话时。
对于大型语言模型来说，更长的上下文长度具有以下几个主要的价值：
-
更好的理解和生成长文本：如果一个模型的上下文长度更长，那么它就能够处理更长的文本。这对于理解和生成长篇文章、报告或书籍等长文本非常有用。
-
更准确的长期依赖关系学习：在许多情况下，文本中的信息需要跨越很长的距离才能理解。例如，在一篇文章的开始部分提到的信息可能会影响到结尾部分的理解。如果模型的上下文长度足够长，那么它就能够捕捉到这些长期依赖关系。
-
更丰富的对话管理：在对话系统中，更长的上下文长度可以帮助模型更好地理解和生成连贯、相关和有深度的对话。模型可以记住更早之前的对话内容，并在后续的回复中使用这些信息。
-
提高模型的泛化能力：通过处理更长的上下文，模型可以学习到更复杂、更丰富的语言模式，从而提高其泛化能力，使其能够更好地处理未见过的数据。
总的来说，更长的上下文长度可以极大地提高大型语言模型在各种任务中的性能和效果。然而，处理更长的上下文也会带来一些挑战，如计算资源需求增加、训练难度增大等。因此，如何有效地处理长上下文是当前自然语言处理研究中的一个重要问题。
当前，解决大模型的上下文长度限制的主要思路有2类，一种是训练新的模型，让模型天然地支持更长的上下文，另一种是检索增强生成方法。
训练支持更长上下文的大语言模型
训练支持更长上下文的大语言模型主要分为2类，一种是在预训练阶段，就设计新的大模型架构（如MetaAI的MetaByte：解决大语言模型的长输入限制：MetaAI发布MegaByte最高支持几百万上下文输入！），让输入的长度更长。另一种是微调阶段通过引入一些新方法，如Focused Transformer（FoT）。
不过，这类方式也有一些问题。例如，需要更多的计算资源来训练，消耗更大的成本。其次，具有长上下文关联的数据集也比普通数据集更难获取。没有关联关系的长文档可能训练效果也不好。
检索增强生成方法（Retrieval-Augmented Generation，RAG）
检索增强生成（Retrieval-Augmented Generation，RAG）是一种新的大语言模型使用方法，它可以有效地将大语言模型与外部知识结合。简单来说，RAG有2个主要部分：retriever用来检索用户输入相关的内容，generator（通常是大语言模型）根据检索到的内容回答问题。这种方法可以有效拓展大语言模型的上下文长度限制。原因是不需要在输入时候带上大量的知识，只需要将这些知识作为外部数据，等用户搜索匹配上再给大模型即可。
大模型支持更长上下文？训练（微调）新模型还是使用RAG？
从上面的分析可以看到，微调训练一个原生支持更长上下文长度的大模型，或者基于检索增强的生成是当前两种最主流的拓宽大模型上下文长度的方法。但是，在实际场景中应该如何选择？二者哪个更好？这个问题目前并没有确认。
英伟达的研究人员最近做了一组测试，使用了2个大语言模型，它们原生支持不同长度上下文，再配合检索增强的方法来测试不同方法在不同任务的水平。这里的任务都是针对长上下文设计的，需要模型更好地处理长上下文才能解决。
总体实验方案
研究人员主要从以下几个方面设计了实验，来对比检索增强和扩大LLM上下文窗口这两类方法的优缺点：
- 选择不同规模的LLM进行比较实验，包括43亿参数的GPT和70亿参数的LLaMA。
- 分别测试无检索和有检索两种设置下，LLM上下文窗口为4k、16k、32k的不同模型。
- 使用位置插值法扩大LLM的上下文窗口，而不是从零开始预训练一个更长上下文的LLM。
- 使用多个不同的检索器（Dragon、Contriever、OpenAI Embedding）进行检索实验。
- 在7个不同类型的问答和摘要任务上评估模型性能，覆盖单文档、多文档问答以及基于查询的摘要任务。
- 与较大的GPT-3.5以及Ddavinci等模型进行比较。
- 比较绝对的性能指标，而不仅仅是与baseline的相对提升。
通过上述丰富的模型设置、任务设置、结果分析和比较，作者全面地验证和对比了仅依赖LLM自注意力机制理解长文本 vs 检索增强辅助LLM进行推理两种范式的性能和计算成本。
实验的下游任务
下游的任务主要包括如下：
从上表可以看出，这7个任务覆盖了:
-
文档长度从5k到85k不等的长短文本。
-
不同类型的任务，包括问答、摘要、多选等。
-
单文档、多文档以及需要多跳推理的复杂问答。
-
不同的评价指标，如EM、F1、ROUGE。
通过在这些不同属性的下游任务上评估，可以很好地对比检索与窗口扩展两种方式处理长文本的区别。
大模型原生支持更长上下文和检索增强生成支持上下文测试结果对比
最终作者对比的测试结果如下：
该表格总结了基于GPT-43B和LLaMA2-70B的不同模型在7个数据集上的评测结果，包括平均分和每个数据集的具体指标，覆盖了序列长度从4k到32k，以及有无检索增强两种设置。
根据上面的测试结果，我们可以看到下面几个结论：
- 单纯扩展4k LLM到16k，其表现可以和简单的检索增强4k LLM相当，但更耗计算。
- 检索对任何长度的LLM都有帮助，尤其是大模型。最好的检索增强LLaMA 70B-32k超过GPT-3.5-turbo-16k和Davinci-003。
- 检索增强可以明显提升大LLM的性能，即使已扩展context window。检索增强的LLaMA 70B-32k大幅优于非检索增强的LLaMA 70B-32k。
- 公开的检索器可以优于OpenAI Embedding。检索topk chunks不等于提取最多信息。
- 大模型有更强的零样本组合检索文档的能力。
为什么检索增强生成时候检索topk chunks不等于提取最多信息？
这篇论文还有一个非常有意思的结论，就是检索增强生成的时候，我们通常检索最相关的k个chunks，然后给大模型回答。但是论文作者认为检索增强生成时候检索top k chunks不等于提取最多信息。
检索获取的top k chunks不等于从文档中提取到最多的相关信息，主要原因有:
-
检索获得的topk chunks是连续的段落，而相关信息在文档中可能是分散分布的。
-
很多数据集的文档较短，top 10 chunks已经包含了大部分文档，继续增加chunks数目不会带来更多信息。
-
不同的检索器质量不同，获取的top k chunks的相关性也存在差异。
-
LLMs处理长文本的能力具有“U形”特性，更偏向利用前后位置的上下文，中间位置的信息利用效果较差。
-
仅看Chunks数目过多可能引入无关信息，影响LLM的推理。
上面的第四点是来自之前的研究结论，具体参考：大模型如何使用长上下文信息？斯坦福大学最新论文证明，你需要将重要的信息放在输入的开始或者结尾处！
所以检索的top k chunks数目不是“越多越好”，需要针对具体的任务和模型大小进行优化。论文中实验也显示，topk=5或10的效果不一定比topk=20差。
这说明我们不能简单地以为给LLM提供越多文本作为上下文一定是最优的，还需要考虑信息的相关性及LLM处理长文本的特点。检索与LLM的结合需要进行更深入的研究来取得最优的平衡。
与LongBench结论差异总结
这篇论文名称是《Long Context LMs for Retrieval and Understanding》，是英伟达研究人员发布的。这只是一种角度，在此前八月份，清华大学的研究人员也有一篇对比论文《LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding》对比了这两种方法的差异。但是这篇论文的结论和本文完全不同。
在本文的实验测试中，作者认为检索增强生成可以明显提升大LLM的性能，即便是LLM本身已经支持了更长的context length。而清华大学的论文中认为检索增强生成对上下文理解能力弱的模型有提升，但仍落后于本身具备强大长文本理解能力的模型。
关于这一结论差异的原因作者认为在于LongBench论文主要基于较小的语言模型(6B到7B参数量级)。这类相对较小的模型，自身组合上下文的能力有限。而本论文使用了70B参数的LLaMA等更大模型。大模型具有更强的零样本学习能力，可以更好地消化检索结果。
