Context Window 上下文窗口:捕捉信息的范围
上下文窗口指的是 AI 模型在生成回答时考虑的 Token 数量。它决定了模型能够捕捉信息的范围。上下文窗口越大,模型能够考虑的信息就越多,生成的回答也就越相关和连贯。
在语言模型中,上下文窗口对于理解和生成与特定上下文相关的文本至关重要。较大的上下文窗口可以提供更丰富的语义信息、消除歧义、处理上下文依赖性,并帮助模型生成连贯、准确的文本,还能更好地捕捉语言的上下文相关性,使得模型能够根据前文来做出更准确的预测或生成。
大型语言模型(LLM)往往会追求更长的「上下文窗口」,但由于微调成本高、长文本稀缺以及新token位置引入的灾难值(catastrophic values)等问题,目前模型的上下文窗口大多不超过128k个token
GPT-4 Turbo 拥有 128k 个 Token 的上下文窗口,相当于超过 300 页的文本。这使得 GPT-4 能够生成更具上下文相关性和微妙差别的回复。
再举个栗子:
比如一个 LLM 模型的 Context Window 为 5,那么在处理句子 “今天天气很好” 中的「天气」这个 Token 时,模型会同时考虑 “今天” 和 “很好” 这两个 Token 的信息,以此来更好地理解「天气」的含义。
扩展阅读:
最近有几个新的语言大模型(LLM)发布,这些模型可以使用非常大的上下文窗口,例如65K词元(MosaicML的MPT-7B-StoryWriter-65k+)和100K词元的上下文窗口(Antropic)。在Palm-2技术报告中,谷歌并没有透露具体上下文大小,但表示他们“显著增加了模型的上下文长度”。
相比之下,当前GPT-4模型可以使用32K输入词元的上下文长度,而大多数开源LLM的上下文长度为2K词元。
如此大的上下文长度意味着提示(prompt)可以达到一本书的大小。《了不起的盖茨比》有72K词元,210页,按1.7分钟/页的阅读速度计算,需要6小时的阅读时间。因此,模型可以扫描并保留此数量的“自定义”信息来处理查询!
注意思考以下几个问题:
-
为何上下文长度如此重要,且能在LLM中起到举足轻重的作用?
-
处理大型上下文长度时,原始Transformer架构的主要局限性是什么?
-
Transformer架构的计算复杂度
-
目前有哪些可以加速Transformer并将上下文长度增加到100K的优化技术?
注意: 在很多文章或者著作中,上下文长度”、“上下文窗口”和“输入词元数量”可以互相替换使用,并用n来表示。
我们先总结三个要点,来简单认识下上下文窗口的相关问题:
1)注意力层(attention layer)计算的二次方时间(Quadratic time)和空间复杂度,即输入词元数量n。
2)嵌入大小d的线性层的二次方时间复杂度。
3)原始架构中使用的位置正弦嵌入(Positional Sinusoidal Embedding )。
带着这三个问题我们来阅读下面的内容会更能理解其中的原理。
在Transformer架构中,可学习(learnable)矩阵权重的形状与输入词元n的数量无关。
因此,在2K上下文长度中训练的Transformer可以使用任意长度的词元,甚至是100K词元。但如果不是在100K词元上训练出来的,那么该模型在100K词元的推理过程中不会产生有意义的推理结果。
由于n、d相关的二次复杂度,在巨型语料库上训练Vanilla Transformer,并且只在较大的上下文长度上训练是不可行的。据估计,在2K上下文长度上训练LLaMA的费用约为300万美元,因此,100K的花费约为1.5亿美元。
一种选择是,可以在2K词元上下文中训练模型,然后在更长的上下文词元(例如65K)中微调。但由于位置正弦编码(Positional Sinusoidal Encoding)的存在,这不适用于原始Transformer模型。
为了能解决上述的这些问题,我们可以采用一些小技巧进行处理:
-
[技巧 1 ]
-
为解决此问题,可删除位置正弦编码并使用ALiBi,这一简单位置嵌入不会影响准确性。然后可以在2K词元上训练,在100K词元上微调。
-
[技巧 2 ]
-
无需计算所有词元间的注意力分数(attenti