我要投稿

长上下文语言模型实际有效的上下文到底有多长？

发布日期：2024-04-18 17:14:04 浏览次数： 3049

作者：SparksofAGI

微信搜一搜，关注“SparksofAGI”

RULER: What’s the Real Context Size of Your Long-Context Language Models?

长上下文语言模型实际有效的上下文到底有多长？‍‍‍‍‍‍‍‍‍

‍‍‍‍‍

“大海捞针”（NIAH）测试，检验从长干扰文本（“干草堆”）中检索一条信息（“针”）的能力，已被广泛用于评估长上下文语言模型。但该基于检索的简单测试仅指示了一种浅显的长上下文理解能力。为对长上下文LM做更全面的评估，作者构建了新的基准RULER，其具有灵活的配置，用于自定义序列长度和任务复杂度。RULER在原有的NIAH测试基础上扩展，包含了具有多种类型和数量的“针”的变体。且RULER引入了新的任务类别——多跳追踪（multi-hop tracing）和聚合（aggregation），以测试超出上下文搜索的行为。

作者使用RULER中的13个代表性任务评估了十个长上下文LM。尽管它们在原版的NIAH测试中几乎达到了完美的准确率，但所有模型在上下文长度增加时都表现出了大幅度的性能下降。虽然这些模型都声称上下文大小为32K或更长，但只有四个模型（GPT-4、Command-R、Yi-34B和Mixtral）能在32K的长度上保持令人满意的性能。而且他们对Yi-34B（声称支持200K的上下文长度）的进一步分析表明其随着输入长度和任务复杂度的增加，仍有很大的改进空间。另外，论文还显示非Transformer结构如RWKV和Mamba在RULER上仍大幅落后于Transformer结构的模型。

RULER数据集主要有四部分，细分例子可直观地见table1：

1. 检索：基于三个原则（检索能力应该a.对“针”和“干草堆”的类型不敏感，b.足够强大以忽视困难的干扰项，c.当需要检索多个项目时具有高召回率。）拓展NIAH任务到针的多种类多数量：S-NIAH（朴素的NIAH任务），MK-NIAH（多“针”插入“干草堆”，检出一个，其他针是干扰项），MV-NIAH（多个共享同一键的“针”被插入到“干草堆”。检索与同键相关联的所有值。），MQ-NIAH（多个“针”被插入到“干草堆”中。检索所有具有不同键的“针”）

2. 多跳追踪：作者开发了新任务——变量追踪，考察跟踪相关共现模式和在长输入中找到多跳连接。具体而言，一个变量X1初始化为一个值V，接着是一系列变量名绑定声明的线性链，目标是返回所有指向同一值V的变量名。

3. 聚合：从预定义词表抽取单词构建输入序列。再做两种任务：CWE：找常见词，常见词数量固定而不常见词的数量随序列长度增加；FWE：找频繁词，模型需要返回上下文中频率最高的前K个单词。

4. QA：在随机采样的段落中插入含答案的段落，针对其做QA。

主结果见table3，超过4K时Llama2-7B性能（85.6%）的性能作为基线被下划线标出。有效上下文长度是通过此阈值的最大长度。结论类似第一段里的陈述，前三开源模型Command-R、Yi-34B和Mixtral都用了基础频率（base frequency）较大的RoPE且模型参数规模较大；尽管像LWM用1M的上下文训，其在4K时比Llama2-7B还差，但随着上下文变长效果下降仍算缓慢，导致当更长的序列获得更大的权重（wAvg. inc）时，其排名高于Mistral-7B（在短序列上的绝对性能和随上下文大小扩展的相对退化之间存在权衡）。

一些针对Yi-34B-200K的错误分析：

1. 对“针”的类型不鲁棒，“针”在单词-数字对之外模型效果下降

2. 无法忽略干扰项：增加干扰“针”的数量会稳定降低性能，见figure2中左

3. 返回不完整信息：当模型需要检索与同一键关联的多个值时（figure2中右），模型经常输出重复的答案而不返回完整的值的集合，这意味着键与其每个值之间的关联不均匀

4. 倾向于从上下文中复制，这一倾向在变量跟踪（VT）和常见词提取（CWE）任务中最为明显

5. 上下文变量跟踪不可靠：对于变量跟踪任务，增加更多的链条和跳数都会导致Yi性能的大幅退化

6. 无法准确聚合：在聚合任务中观察到两种常见的失败模式：错误使用参数知识和不准确聚合

7. 长上下文QA中的频繁幻觉：退化主要源于幻觉和对上下文信息的依赖减少