今天小编分享的互联网经验：Transformer不读《红楼梦》，欢迎阅读。
在 Transformer 的自注意力（self-attention）机制中，每个 token 都与其他所有的 token 有关联。所以，如果我们有 n 个 token，那么自注意力的计算复杂性是 O ( n^2 ) 。随着序列长度 n 的增加，所需的计算量和存储空间会按平方增长，这会导致非常大的计算和存储开销。
这意味着，当你已经不满足喂给大模型一个两百字的段落，想扔给他一篇两万字的论文，它的计算量增加了 1 万倍。
图源：Harm de Vries 博客
那个负责输入和输出的对话框就像人工智能通往现实世界的一个隘口。从 ChatGPT 第一次跃上 4096 个 token，到 GPT-4 将上下文输入长度扩展到 32k，再到 MetaAI 提出的数百万 tokens 的 MegaByte 方法，以及国内大模型厂商月之暗面和百川智能之间，20 万与 35 万汉字的长度竞赛，大模型解决实际问题的进程，输入窗的胃口正在变成一个重要的先决条件。
换句话说，当它读《红楼梦》也能像读一个腦筋急转弯那么认真仔细，事情就好办多了。
突破奇点落在了 token 数上。关于它的研究也从来没有停下。
越长越好？
对于上下文长度的推进是必要的，复旦和香港大学的研究团队在一篇论文中做了论证。他们做了一个 L-Eval 的评价基准，在这个基准的测试下，Claude-100k 在封闭任务上的推理能力仍然弱于 GPT-4-32k，但在开放式任务中，长度更长——也就意味着通常拥有更多输入标记——的 Claude-100k 在表现上超过 GPT-4-32k。
图源：《L-Eval:Instituting Standardized Evaluation for Long Context Language Models》
结论很积极，意味着勤能补拙的故事仍然是成立的，如果腦子不好，你可以多嘱咐几句，笨一点的学生也能成事。
在那之前，Google Brain 也已经做了类似试验，一直参与 Bard 的研发训练的工程师 Li Wei 告诉硅星人，去年 Google 团队已经通过控制训练输入上下文长度的方式来观察模型的输出表现，结果确实上下文长度与模型表现成正相关。这个认识也对后来 Bard 的研发有所帮助。
至少这是个业内非常笃定的方向。那理论上，一直扩展上下文长度不就好了？
问题是扩张不得，而这个障碍仍然落在 Transformer 上。
梯度
基于 transformer 架构的大模型，也就意味着接受了自注意力机制赋予的能力和限制。自注意力机制对理解能力钟情，却天然与长文本输入有所违背。文本越长，训练就越艰难，最坏的结果可能是梯度的爆炸或者消失。
梯度是参数更新的方向和大小。理想的训练下，大模型在生成内容上与人类想要的回答之间的差距应该在每一轮深度学习后都比之前更接近。如果把模型想象成试图在学习一个线性关系 y=wx+b 的话，w 表示模型正在寻找的那个权重。而梯度的概念就是在表达 w 是如何变化的。
一个稳定的学习过程是渐进的，渐进意味着微调有迹可循。就是说权重不能不变化，也不能突变。
不变化或者变化非常微弱——也就是梯度消失——意味着深度学习网络的学习时间无限延长；突变则被叫做梯度爆炸，权重更新过大，导致网络不稳定。这可能会导致权重变得非常大或模型发散，使得训练无法进行。
三角
而最核心的，短文本很多时候无法完整描述复杂问题，而在注意力机制的限制下，处理长文本需要大量算力，又意味着提高成本。上下文长度本身决定了对问题的描述能力，自注意力机制又决定了大模型的理解和拆解能力，而算力则在背后支撑了这一切。
图源：ArXiv
问题仍然在 Transformer 上，由于自注意力机制的计算复杂度问题，上下文长度的扩展被困在一个三角形里。
这个不可能三角就摆在这儿，解决方案也在这里。为了增加上下文长度，如果能够把算力（钱和卡）推向无限显然是最理想的。显然现在这不现实，那就只能动注意力机制的心思，从而让计算复杂度从 n^2 降下来。
对扩展上下文输入的努力很大程度上推动者一场 Transformer 的革新。
Transformer 变形记
谷歌 DeepMind 研究团队在今年 7 月提出了一种新的 Focused Transformer（FoT）框架，它采用了一个受对比学习启发的训练过程，以改善（key, value）空间的结构，并且允许一些注意力层通过 k- 最近邻 ( kNN ) 算法访问外部记忆中的（key, value）对。这种机制有效地扩展了总的上下文长度。
这有点像是谷歌在 2022 年另一个 Memorizing Transformer 的衍生，后者基于 Transformer 的调整逻辑是在编码长文本时，模型一边往下读，边把之前见过的所有 token 保存在一个数据库中；在读当前片段时，会用 kNN 的方式找到数据库中相似的内容。
Focused Transformer 和 LLaMA-3B 开源模型做了结合，变成 LongLLaMA-3B，再和 LLaMA-3B 在上下文输入的长度方面做了横向对比。结果是上下文输入长度到 100k 之后，LongLLaMA-3B 的回答准确率才开始从 94.5％迅速下滑。而 LLaMA-3B 在超过 2k 就瞬间跌倒 0 了。
图源：《Focused Transformer: Contrastive Training for Context Scaling》
从 Transformer-XL 在 2019 年出现，引入了分段循环机制（Segment Recurrent Mechanism）为模型提供了额外的上下文，到一年后 Longformer 和 BigBird 引入了稀疏注意力机制，将长度第一次扩展到 4096 个 tokens，循环注意力和稀疏注意力机制就开始成为 Transformer 的改造方向。
Focused Transformer 通过 kNN 算法也是实现了某种形式的稀疏注意力，更新的架构调整方案则是 Ring Attention。
今年 10 月，伯克利的团队提出了环注意力（Ring Attention），Ring Attention 从内存角度改变 Transformer 框架。通过分块处理自注意力机制和前馈网络计算的方法，上下文序列可以分布在多个设备上，并更有效地进行分析。这也理论上消除了单个设备所施加的内存限制，使得序列的训练和推断能够处理比之前的内存效率更高的 Transformer 长得多的序列。
也就是说，Ring Attention 实现了 " 近乎无限的上下文 "。
当头一棒
但这件事也不是绝对的。斯坦福在 9 月公布了一项研究表明，如果上下文太长，模型会略过中间不看。
他们对多种不同的开源（MPT-30B-Instruct、LongChat-13B ( 16K ) ）和闭源（OpenAI 的 GPT-3.5-Turbo 和 Anthropic 的 Claude）的语言模型进行了对照实验。研究者通过向输入上下文添加更多文档来增大输入上下文的长度（类似于在检索增强式生成任务中检索更多文档）；以及通过修改输入上下文中文档的顺序，将相关信息放置在上下文的开头、中间或结尾，从而修改上下文中相关信息的位置。
图源：《Lost in the Middle: How Language Models Use Long Contexts》
结果是随着相关信息位置的变化，模型性能呈现出明显的 U 型趋势。也就是说，当相关信息出现在输入上下文的开头或末尾时，语言模型的性能最高；而当模型必须获取和使用的信息位于输入上下文中部时，模型性能会显著下降。举个例子，当相关信息被放置在其输入上下文中间时，GPT3.5-Turbo 在多文档问题任务上的性能劣于没有任何文档时的情况（即闭卷設定；56.1%）。此外，研究者还发现，当上下文更长时，模型性能会稳步下降；而且配有上下文扩展的模型并不一定就更善于使用自己的上下文。
当头一棒。
但这或许也是好事，如果文章太长，人们大概也只会记得开头和结尾，大模型与人类大腦何其相似。
交锋
目前全球主流的大模型中，GPT-4 与 LLaMA 2 Long 的上下文长度都已经达到了 32k，Claude 2.1 达到 200k。国内的大模型中，ChatGLM-6B 的上下文长度达到了 32k，最晚亮相的明星公司月之暗面直接拿出了一个 200k 的 Kimi Chat。
月之暗面的思路同样是改造 Transformer，但杨植麟同时也引出一场交锋。
蝌蚪模型和蜜蜂模型。
直白说，凹一个造型让模型看起来可以支持更长的上下文输入有很多途径，最简单的办法是牺牲模型本身的参数。
模型参数的降低，意味着内存消耗的减少以及计算的简单化，内存和计算资源的重新分配能够转变成同样算力资源下上下文输入长度的增加。回过头来看，Focused Transformer 的验证放在一个 3B 的小参数模型上，对于 Ring Attention 的试验也更侧重于所提出方法的有效性验证，而没有经历百亿参数以上的大模型。
图源：《Focused Transformer: Contrastive Training for Context Scaling》
但 10 亿级别的模型参数并不具备太好的智能涌现能力。杨植麟形容其为蝌蚪模型，因为它做不了更多事情。
除此之外，另一种可以增加长度的方式是从外部引入搜索机制。
搜索的原理
这也是目前相当多大模型能快速扩展上下文长度所采取的办法——如果不动自注意力机制，另一种方式就是把长文本变成短文本的集合。
比如常见的 Retrieval-augmented generation ( RAG ) 。它是一个结合了检索 ( retrieval ) 和生成 ( generation ) 两种机制的深度学习框架，目的是将信息检索的能力引入到序列生成任务中，使得模型在生成响应或内容时可以利用一个外部的知识库。
图源：Towhee
模型在处理长文本时，引入的搜索机制会在数据库中对短文本进行检索，以此来获得多个短文本回答构成的长文本。每次只加载所需要的短文本片段，从而避开了模型无法一次读入整个长文本的问题。
杨植麟将这类模型称为蜜蜂模型。
传统的 Transformer 机构，如 GPT，其输入长度有限，通常限于几百到几千的 token。这意味着当需要处理大量的信息或长文档时，模型可能会遇到困难。RAG 通过其检索机制可以在一个大型的外部知识库中检索信息，然后仅将最相关的片段与原始输入一起送入生成模型。这使得模型能够处理比其原始输入长度更大。
这个观点背后的原理很有意思。如果循环注意力和稀疏注意力都是在模型内部对注意力机制进行改进，属于模型结构级的优化，那么通过在外部数据库中检索相关信息片段，然后将最相关的片段与原始输入一起送入生成模型，来避免直接处理完整的长文本，这仅仅属于输入级的优化。
这种方法的主要目的是从大量的文档中快速捕获与当前问题最相关的信息片段，而这些信息片段可能只代表了原始输入的部分上下文或某些特定方面。也就是说，这种方法更重视局部的信息，可能无法把握一个长文本输入的整体含义。
就像蜂巢中互相隔开的一个个模块。
蜜蜂模型的说法有一些戏谑意味的指向了市面上用外挂搜索来拓展視窗容量的大模型厂商，很难让人不想到近几个月发展迅速，一直强调自己 " 搜索基因 " 的百川智能。
10 月 30 日，百川智能发布全新的 Baichuan2-192K 大模型。上下文視窗长度拉长到 192K，折算成汉字约等于 35 万字。月之暗面的 Kimi Chat 才将 Claude-100k 的上下文长度扩充了 2.5 倍，Baichuan2-192K 又几乎把 Kimi Chat 的上限翻了倍。
在长視窗文本理解评测榜单 LongEval 上，Baichuan2-192K 的表现远优于 Claude-100k，在視窗长度超过 100K 后依然能够保持强劲性能，后者在 70k 之后的表现就极速下跌了。
也没这么多长文本
但关于 " 我们为什么不试试更长的上下文 " 这个问题，还有另一个观察角度。
公开可用的互联网抓取数据集 CommonCrawl 是 LLaMA 训练数据集的主要数据来源，包括从 CommonCrawl 中获取的另一个主要的数据集 C4，两者占据了 LLaMA 训练数据集中的 82%，
CommonCrawl 中的语料数据是很短的。ServiceNow 的研究员 Harm de Vries 在一篇分析文章中表示，这个占比庞大的数据集中，95% 以上的语料数据檔案的 token 数少于 2k，并且实际上其中绝大多数的区间在 1k 以下。
图源：Harm de Vries 博客
" 如果要在其中寻找到有明显上下文逻辑的长文本就更少了 "，Li Wei 说。
更长的训练预料被寄希望于书籍或论文甚至者维基百科等来源。Harm de Vries 的研究表明，有 50% 以上的维基百科文章的词元数超过了 4k 个 tokens，75% 以上的图书词元数超过了 16k 个 tokens。但无奈以 LLaMA 训练预料的主要数据来源分布来看，维基百科和书籍的占比都仅仅是 4.5%，论文（ArXiv）的占比只有 2.5%。三者相加只有 270GB 的数据，不到 CommonCrawl 一成。
或许目前也压根没有这么多长文本语料能够用于训练，Transformer 们不读《红楼梦》也没有那么多《红楼梦》可读，是横贯在所有追求上下文长度的人们面前真正的难题。
