论文笔记:Lost in the Middle: How Language Models Use Long Contexts

本文研究了大模型在处理文档问答和键值对索引任务时,发现相关信息处于输入提示开头或结尾时性能较好,而位于中间时性能下降。实验表明,即使使用支持更长上下文的模型,这一现象依然存在。研究还探讨了模型架构、query位置和finetune对性能的影响。
摘要由CSDN通过智能技术生成

Transactions of the Association for Computational Linguistics  2024

1 intro

  • 论文对大模型在长文本情况下的性能做了一系列实验研究,发现了一个有趣的“Lost in the middle”现象:
    • 在处理需要识别相关上下文的信息的任务(文档问答、键值对索引)时,大模型对相关信息的位置很敏感
    • 当相关的信息在输入prompt的开头或者结尾时,能够取得较好的效果
    • 而当相关的信息在prompt中间部分时,性能会显著下降。

2 实验

2.1 多文档问答实验

2.1.1 输入prompt格式

  • 对于每个问题,主要包含1个能回答该问题的相关文档以及其他一些不相关的文档,这个相关文档被插入在不同的位置来测试大模型的稳定性

2.1.2 结果

  • 在总文档数分别为10、20、30,对应token数约为2K、4K、6K时,均发现相关文档位于prompt的开始或者结尾时,能够取得更好的效果,而相关文档位于中间时,性能下降
  • 那么,如果使用支持更长上下文的模型呢?(gpt-3.5-turbo-16K-0613 VS gpt-3.5-turbo-0613)
    • 在这个任务上并未获得显著更优的结果

2.2 键值对查询实验

2.1.1 输入prompt格式

2.1.2 结果

  • 对于比较优秀的模型,如claude-1.3-100k、claude-1.3,它们在4k、8k、16k的上下文长度下,不管目标key在哪个位置,都能取得接近100%的准确率;
  • 对于差一些的模型,仍然有相似的现象,目标key位于中间位置时,取得较差的结果

3 讨论

3.1 模型架构的影响

  • 是否和LLM的模型架构相关?Decoder-only/Encoder-Decoder等架构的LLM是否会有不同的表现?
    • ——>之前的实验用的模型都是Decoder-only的架构,于是论文增加了两种Encoder-Decoder模型(flan-t5-xxl、flan-ul2)
    • 发现还是类似的现象

3.2 query和文档的相对位置

前面的实验都是将query放在文档之后进行的,那么将query放在文档之前,会有什么样的结果呢?

——>将query放在文档之前同样有“Lost in the middle”的现象

3.3 有监督finetune 的影响

  • 之前的模型都是带finetune的,于是论文比较了没有finetune情况下的差异
    • 发现及时没有指令微调,仍然会出现lost in the middle的现象

  • 4
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

UQI-LIUWJ

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值