作者： 老刘说NLP  来源： [老刘说NLP](https://mp.weixin.qq.com/s/9Bi0mUuJDWweGq4WwFhsOw)

当前基于知识库外挂方式来缓解大模型幻觉问题的方案逐步受到大家关注，关于这一块我们已经有多篇文章进行了论述。

ACL2023也特意设置了《Retrieval-based Language Models and Applications》的讲习班课程。

该课程讲述了如何基于检索来增强大模型的生成能力，其中涉及到架构、训练以及应用、多模态等多个方面的内容，下面给出了个每个section报告的地址，可供查看：‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Section1:Introduction

地址：https://acl2023-retrieval-lm.github.io/slides/1-intro.pdf‍

Section2:Definition Preliminaries

地址：https://acl2023-retrieval-lm.github.io/slides/2-definition.pdf

Section3:Retrieval-basedLMs:Architecture

地址：https://acl2023-retrieval-lm.github.io/slides/3-architecture.pdf

Section4:Retrieval-basedLMs:Training

地址：https://acl2023-retrieval-lm.github.io/slides/4-training.pdf

Section5:Retrieval-basedLMs:Applications

地址：https://acl2023-retrieval-lm.github.io/slides/5-application.pdf

Section6:Extension:Multilingual &Multimodal

地址：https://acl2023-retrieval-lm.github.io/slides/6-extension.pdf‍

Section7:Challenges & Opportunities

地址：https://acl2023-retrieval-lm.github.io/slides/7-conclusion.pdf

而外挂知识库的一个很重要的点就是是否能够提供准确地上下文，通常我们会受限于相似度阈值以及最长上下文地限制，从而影响上下文构造的数据效率。

为了解决这个问题，做尽可能长的上下文，比如从2048增加到16k，或者增加到32k，甚至256k。

例如，由于语言模型通常是用Transformer实现的，对长序列的扩展性很差，由于自我注意的复杂性与输入序列长度成二次方的关系。因此，语言模型通常用相对较小的上下文窗口进行训练，例如硬件（具有更多内存的更快的GPU）和算法如flash attention等改进让语言模型具有更大的上下文。

具体的，可以见到的工作包括：设计具有比Trans-foormer更便宜伸缩性的性能语言模型有很多工作要做。许多工作都在追求具有注意力修正的Transformer变体，如递归、将注意力因子化为计算强度较低的近似或低阶近似。例如，Dao等人（2022）通过精心制作的IO感知CUDA内核提供了更快的准确注意力。又如通过卷积和/或线性RNN来消除注意力整体的二次序列长度复杂性，例如RWKV（Peng，2023）、S4（Gu等人，2022）或Hyena（Poli等人，2023年）的工作。

但这又引来另一个问题，那就是上下文长了，是否就一定意味着有好的表现？语言模型在采用上下文答案时有什么选择机制？

最近的文章**《Lost in the Middle: How Language Models Use Long Contexts》值得关注。**

地址：https://arxiv.org/abs//2307.03172‍‍‍‍

该工作分析了语言模型在两个需要识别输入上下文中相关信息的任务，即多文档问题回答和键值检索上的表现。该工作发现，当相关信息出现在输入上下文的开头或结尾时，性能通常是最高的，而当模型必须在长上下文的中间访问相关信息时，性能会明显下降。此外，随着输入语境的变长，性能也会逐步下降。

如图1所示，改变相关信息的位置 (在这种情况下，回答输入问题的段落的位置）在语言模型的输入语境中会产生一个U型的性能曲线。

例如，GPT-3.5-Turbo在多文档问题任务中，当相关信息被放置在其输入语境的中间时，其开卷性能低于在没有任何文档的情况下进行预测的性能。

为了得到这个结论，该工作对开放式（MPT-30B-Instruct，LongChat-13B（16K））和封闭式（OpenAI的GPT-3.5-Turbo和Anthropic的Claude）语言模型在需要访问和使用输入上下文信息的情况下进行对照实验来进行研究。

首先，第一个任务是多文档问题回答，这需要模型对所提供的文档进行推理，以找到相关的信息，并使用它来回答一个给定的问题，这项任务模仿了许多商业生成性搜索和问题回答应用（如hhBing Chat）背后的检索增强的生成机制。

通过对输入上下文的大小和输入上下文相关信息的位置进行消融实验，并研究了它们对模型性能的影响。

例如，通过在输入上下文中添加更多的文档来增加输入上下文的长度（类似于在检索增强生成中重新获取更多的文档），并通过改变输入上下文中文档的位置来修改相关信息在上下文中的位置，将相关文档放在上下文的开头、中间或结尾。

其次，键值对检索。既然语言模型在多文档问题回答任务中很难检索和使用相关信息，那么语言模型能在多大程度上从其输入的文本中检索出相关信息？

该工作提出了一个合成的键值检索任务来研究这个问题，该任务被设计为一个小型的测试平台，即模型被给定一个JSON格式的键值对集合，并且必须返回与特定键相关的值，用于测试从输入语境中检索匹配标记的基本能力。

在这个任务中，与多文档质量保证任务类似，键值检索任务也允许对输入上下文的长度（增加更多的键值对）和相关信息的位置进行改变。

在这种情况下，也得到了类似的U型性能曲线，许多模型都在努力简单地检索出现在其输入上下文中间的匹配标记。

此外，该工作发现，当从维基百科检索以回答NaturalQuestions-Open的查询时，模型的性能在检索器召回率达到一定水平之前就已经饱和了，这表明模型不能有效地使用额外的检索文件，使用超过20个检索文件只能略微提高性能（GPT-3.5-Turbo为1.5%，claude-1.3为1%）。

关于该工作的代码和数据，可以进一步参考nelsonliu.me/papers/lost-in-the-middle，本文对该工作进行介绍，供大家一起参考，并思考。

一、语言模块如何使用其输入上下文：多文档问答的实验分析

多文档问答的目标是更好地理解语言模块如何使用其输入上下文。任务需要模型在输入上下文中找到相关信息，并使用它来回答问题。

1、实验输入输出

模型输入：要回答的问题和k个文档（例如，维基百科中的段落），其中恰好有一个文档包含问题的答案，而k−1个文档不包含，也就是干扰问答。

模型输出：模型访问在其输入上下文中包含答案的文档，并使用它来回答问题。

如图2表示多文档问题回答任务的例子，有一个输入上下文和期望的模型答案。在输入环境中，正确回答请求的相关文件被加粗。

2、模型实验数据

采用NaturalQuestions基准，该基准包含发布给谷歌搜索引擎的历史查询和从维基百科中提取的人工标注的答案。

具体地，首先从NaturalQuestions Open中获取问题，使用维基百科中的使用段落（最多100个标记的块）作为输入文本中的文档。其中：

为了获得一份回答问题的文档，使用维基百科的段落，其中包含NaturalQuestions注释中的答案。

为了选择不包含答案的k−1个干扰物文档，使用Contriever检索系统来检索与问题最相关的但不包含任何NaturalQuestions答案的k–1维基百科块。

{  
  "question": "who got the first nobel prize in physics",  
  "answers": [  
    "Wilhelm Conrad Röntgen"  
  ],  
  "ctxs": [  
    ...  
    {  
      "id": <string id, e.g., "71445">,  
      "title": <string title of the wikipedia article that this passage comes from>,  
      "text": <string content of the passage>,  
      "score": <string relevance score, e.g. "1.0510446">,  
      "hasanswer": <boolean, whether any of the values in the `answers` key appears in the text>,  
      "original_retrieval_index": <int indicating the original retrieval index. for example, a value of 0 indicates that this was the top retrieved document>,  
      "isgold": <boolean, true or false indicating if this chunk is the gold answer from NaturalQuestions>  
    },  
    ...  
  ],  
  "nq_annotated_gold": {  
    "title": <string title of the wikipedia article containing the answer, as annotated in NaturalQuestions>,  
    "long_answer": "<string content of the paragraph element containing the answer, as annotated in NaturalQuestions>",  
    "chunked_long_answer": "<string content of the paragraph element containing the answer, randomly chunked to approximately 100 words>",  
    "short_answers": [  
      <string short answers, as annootated in NaturalQuestions>  
    ]  
  }

3、实验变量控制

如图3所示，为了调节任务中的输入语境长度，该工作增加或减少不包含答案的检索文件的数量，添加不包含答案的额外文档会增加输入上下文的长度，但不会影响所需的输出。正确回答请求的相关文档对在输入上下文中被加粗。

如图4所示，为了调节相关信息在输入上下文中的位置，调整输入语境中文件的顺序，以改变包含答案的文件的位置。在输入上下文中重新排序的文档不会影响到所需的输出。在输入上下文中，对请求做出正确回答的相关文档被加粗。

4、实验评测指标

对包含10个、20个和30个文档（每个文档2.7K个示例）的输入上下文进行了实验，使用准确性作为主要评价指标，判断是否有任何正确的答出现在预测的输出中。

5、模型选用 ‍‍‍‍

在开放式模型方面，使用MPT-30B-Instruction(8192)、LongChat-13B（16K）。

在封闭式模型方面。使用OpenAI API扩展GPT-3.5-Turbo(4K)和GPT-3.5-Turbo（16K），claude-1.3(8K)，claude-1.3(100k)

6、实验效果

如图6所示，随着上下文长度的增长，模型对应的性能不断下降。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

其中有一些有趣的现象，例如，当包含答案的文档位于20个中的第10位时，GPT-3.5-Turbo在20个文档设置中的最低性能为52.9%

设置30个文档的输入上下文对于GPT-3.5-Turbo来说太长，但使用其扩展上下文对应的GPT-3.5-Turbo（16K）也会导致性能下降当相关文档位于30个中的第10位时，性能下降49.5%。

这也就说明，尽管扩展上下文模型可以处理更长的输入上下文，但它们可能不会更好地对其上下文窗口内的信息进行推理。

二、语言模型从输入上下文中检索的效果如何：键值对检索实验分析‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

考虑到语言模型在多文档问答任务中很难从其输入上下文的中间检索和使用信息，他们可以在多大程度上简单地从输入上下文中检索信息？

该工作用一个综合的键值检索任务来研究这个问题。‍‍

1、实验设置

输入：一个具有k个键值对的字符串序列化JSON对象，其中每个键值都是唯一的、随机生成的UUID，以及上述JSON对象中的一个特殊键。

输出：返回与指定键关联的值。

因此，每个JSON对象都包含一个相关的键值对（其中要检索值），以及k−1个不相关的“distributor”键值对。

具体数据样式如图7所示，提供了一个示例输入上下文及其相应的期望输出。

2、模型选用及实验效果评测指标

对包含75、140和300个键值对（每个500个示例）的输入上下文进行实验，在模型选用上使用与多文档问答实验相同的一组模型，使用准确性作为评估指标，评估预测输出中是否出现了正确的值。

3、实验效果变量控制

如图8所示，为了调整该任务中的输入上下文长度，通过添加或删除随机键来改变输入JSON键值对的数量k，从而改变干扰器键值对的数目。

如图9所示，为了调整输入上下文中相关信息的位置，在序列化的JSON对象中更改要检索的键的位置。

4、实验效果分析 ‍‍‍‍‍‍

如图10所示，其显示了关键值检索性能。

可以看到，有几个有趣的发现：‍‍‍‍‍‍

尽管合成键值检索任务只需要识别输入上下文中的精确匹配，但并不是所有模型都能实现高性能。

键值检索任务的结果与多文档问答任务的结果有很大的相似趋势：当必须在输入上下文的中间访问键值对时，模型性能最低。模型性能通常也会在较长的输入上下文中降低。

特别的，LongChat-13B（16K）在相关信息位于输入上下文的开头时，倾向于生成代码来检索键，而不是输出值本身。

三、为什么语言模型很难使用它们的整个输入上下文？

我们的多文档问答和键值检索结果表明，当语言模型必须在长输入上下文中访问相关信息时，其性能会显著下降。为了更好地理解原因，该工作对模型架构的作用（例如，仅解码器与编码器-解码器）以及指令微调的影响进行了一些初步调查。

1、模型架构的影响‍‍‍‍‍

观察： Flan-UL2在其2048训练时间上下文窗口内的序列上进行评估，其性能对输入上下文中相关信息的位置变化相对稳健。当在序列长度超过2048个令牌的设置上进行评估时，当相关信息位于中间时，Flan-UL2性能开始下降。Flan-T5-XXL显示出类似的趋势，当将相关信息放在输入上下文的中间时，输入上下文越长，性能下降越大。

机理推测： 编码器-解码器模型可能会更好地利用其上下文窗口，因为它们的双向编码器允许在未来文档的上下文中处理每个文档，从而可能增强文档之间的相对重要性估计。

2、指令调整的影响

在这种监督指令调优数据中，任务指定和/或指令通常被放置在输入上下文的开头，这可能导致指令调优语言模型对输入上下文的开始给予更多的重视 。

为了更好地理解指令调整对语言模型如何使用长输入上下文的潜在影响，将MPT-30B-instruction 的多文档问答性能与其在指令微调之前的基本型MPT-30B 进行了比较，图13比较了MPT-30B和MPT-30B-Instruction的多文档QA性能。

观察： MPT-30B和MPT-30B-Instruction都显示出U型性能曲线，当相关信息出现在上下文的最开始或最结束时，性能最高。尽管MPT-30B-Instruction的绝对性能一致高于MPT-30B，但它们的总体性能趋势非常相似。 这些观察结果补充了先前的工作，先前的工作发现语言模型偏向于最近的标记。这种近因偏倚通常表现在连续文本的下一个单词预测中，其中语言模型从长程信息中获益最小。

四、思考：更多的背景总是更好吗？

在实际环境中，通常需要权衡输入上下文长度的增加，为指令调整语言模型提供更多信息，这可能有助于提高下游任务性能 ，但也会增加模型必须推理的内容量。

那么？即使一个语言模型可以接受16K个标记，提供16K个上下文标记实际上有益么？ 这个问题的答案是特定于下游任务的，因为它取决于添加上下文的边际值和模型有效使用长输入上下文的能力。

为了研究这个问题，该工作在NaturalQuestions-open上使用开放域问答进行案例研究。

图14显示了开放域QA结果，可以看到，在检索器检索文档逐步提升后，模型性能的提升趋缓，这表明模型很难利用额外检索到的文档。使用20多个检索到的文档只能略微提高读取器性能，其中GPT-3.5-Turbo为～1.5%，Claude为～1%，同时显著增加了输入上下文长度，从而增加了延迟和成本。

这些结果，再加上观察到模型在输入上下文的开始或结束时更善于检索和使用信息，对检索到的文档进行有效的重新排序，将相关信息推向输入上下文的开头或排序列表截断，必要时返回更少的文档，这个是值得深入的方向 。

总结

本文主要针对**《Lost in the Middle: How Language Models Use Long Contexts》** 这一文章进行了介绍。

该工作通过使用多文档问答和键值检索两个任务进行验证，实证研究了语言模型如何使用长输入上下文。

研究的最终结论为：语言模型在长输入上下文的中间使用信息时会带来性能下降，并且随着输入上下文的增长，性能会进一步恶化，其更偏向于头尾两个位置。

这个工作对我们可以有个较好的建议，即对检索到的文档进行有效的重新排序，将相关信息推向输入上下文的开头或排序列表截断，必要时返回更少的文档，这个是值得深入的方向。

最后，关于ACL2023的材料，也可以多看看，相信会有更多发现。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

参考文献

1、https://arxiv.org/abs//2307.03172

2、https://acl2023-retrieval-lm.github.io/

关于我们

老刘，刘焕勇，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。

老刘说NLP，将定期发布语言资源、工程实践、技术总结等内容，欢迎关注。

对于想加入更优质的知识图谱、事件图谱实践、相关分享的，可关注公众号，在后台菜单栏中点击会员社区->会员入群加入。