上下文长度越卷越离谱我们真需要这么多token么？

　　去年，通义舞王在 科目三的火爆出圈中成为了顶流，引发了对通义千问的广泛关注。

　　经常关注大模型的朋友一定听过一个词，叫做“上下文窗口”。比如硅星人Pro的文章《 》就提到了，谷歌Gemini 1.5 Pro的上下文长度达到了100万个token，如果让它来写哈利波特，可以一口气从哈利波特去9又4分之3车站写到小天狼星为了救哈利而牺牲。

　　对于大语言模型来说，上下文窗口是指在训练和应用大语言模型时，模型能够同时考虑并处理的输入序列的最大长度。这个窗口限制了模型对文本中连续标记之间依赖关系的理解范围。对于LLMs而言，大的上下文窗口是极其重要的特征，因为它允许模型在处理长文档、对话历史或复杂语境时保持连贯性和理解力。如果上下文窗口太小，当输入文本超出这一窗口限制时，模型可能无法准确捕捉到远距离词语间的关联，从而导致性能下降。

　　2024年2月26号，微软看到谷歌Gemini 1.5 pro那100万个token以后坐不住了，他们发表了一篇新的论文，提出了一个叫做LongRoPE的方法，能够在保持原始短上下文窗口性能的同时，将预训练LLMs的上下文窗口扩展到令人印象深刻的200万个token。

　　RoPE是Rotary Position Embedding（旋转位置嵌入）的缩写，这是一种在transformer模型中用于编码输入序列中token位置信息的方法，它最大的作用就是让模型能够知道各个token之间的顺序关系。那么LongRoPE的含义呢，就是RoPE for long text，即给长文本准备的旋转位置嵌入。

　　LonRoPE的核心逻辑是通过改进位置插值方法，使得在扩展上下文窗口时仍能有效利用RoPE的特性。LongRoPE本质上来说是一种微调，分为下面下面三个步骤：1.发现并利用了位置插值中的两种非均匀性，通过高效搜索提供了更好的微调初始化条件，并使得在无需微调的情况下能实现上下文窗口8倍的扩展；2.引入了渐进式扩展策略，首先针对25.6万token长度的文本对大语言模型进行微调，然后在已微调的扩展大语言模型上进行第二次位置插值，从而达到204.8万token的上下文窗口；3.对于恢复原始较短上下文窗口的性能，LongRoPE会在8000长度上重新调整参数，确保即使在非常长的上下文窗口设置下，模型也能在较短序列上的表现不下滑。

　　我们可以这样来理解，它的技术原理是通过精巧地处理位置嵌入，依据实际情况灵活调整和优化，既拓宽了模型处理长文本的能力，又保证了模型在应对短文本时同样具备优秀的性能。那么开发LongRoPE的意义在于允许大模型在无需大量的额外训练和计算资源的情况下，能够处理超长文本。

　　所以Longrope最大优势并不只是说能扩大上下文窗口，而是不需要额外训练，不需要多配备硬件，仅仅使用1000步微调以内就能实现这200万个token的扩展。

　　那你可能就要问了，微软研究出这个200万token的上下文窗口技术图啥呢？别说日常对话了，哪怕是拿本小说来，估计也很难满足200万个token。

　　咱们文章开头也讲过了，上下文窗口它就是同时考虑并处理的输入序列的最大长度。而在transformer架构中的自注意力机制中，上下文窗口大小决定了模型可以同时捕捉到多远距离的词语依赖关系。粗暴点来理解，上下文窗口完全可以被当成模型能够容纳多少文本的一种体现。就跟邮箱的油表一样，上下文窗口增大时，意味着它可以理解并基于更长的文本片段进行推理。

　　例如，如果一个大语言模型具有20万token的上下文窗口长度，它可以一次性处理大约35万个汉字的上下文信息。那么200万个tokens的上下文窗口长度，大约就是350万字，要知道一本囊括了保尔柯察金一生的《钢铁是怎样炼成的》才不到40万个字而已。

　　在大模型领域，上下文窗口不应该是“你能炼一吨，咱炼一吨半”，因为增加上下文窗口也意味着模型的计算量和内存需求将大幅增加，因此在实际应用中必须权衡上下文窗口的大小和计算资源的有效利用。

　　如果只是增加计算资源消耗倒还好说，毕竟硬件上下血本就完事了，没有花钱的不是，但过分追求上下文窗口还会导致一个问题，叫做“过拟合（overfitting）”。过拟合是说模型在训练数据上表现很好，但在未见过的测试数据上表现较差的现象。也就意味着模型过度适应了训练数据的特性，将训练数据中的噪声或随机变化也当作了真实的模式，从而导致模型在新数据上泛化能力较差。

　　过拟合通常发生在模型复杂度较高时，例如参数过多或特征过于丰富的情况下。过度复杂的模型可能会在训练数据中学习到过多的噪声或细节，而忽略了数据中的真实规律。而目前来看，LongRoPe还未正式启用，因此我们也没办法清楚它是否发生了过拟合，不过照着200万token大军的势头看，这个概率并不低。

　　还没完，模型在运行过程中，它是需要在内存中发生并行计算的。如果上下文窗口过大，与之对应的内存消耗也就会增加。所以综合考量，无论是大模型的开发者，还是大语言模型的微调者来说，增加上下文窗口是没问题的，然而过分追求超长上下文窗口，并没有特别重大的意义，反倒还会产生未知的结果。

　　说了这么多，其实有一个同样很重要的原因，是各大厂商今天都在卷长度的重要“动机”——因为大语言模型没有特别明确的性能评分标准，只有一个知识库的评分标准，因此透过上下文窗口本身的数学表示，就会给人一种“数字越大，模型越厉害”。也许是时候回归本初，想想最初增加上下文窗口的意义是什么，让大家回到增加模型性能的初心上来了。

　　特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

　　老师与家委狼狈为奸？小学生每年光买东西就要几千块，还必须是“指定链接”

　　马斯克再次猛烈炮轰氢能源：储能领域“最愚蠢选择”，1kg氢气仅续航80KM【附氢燃料电池汽车市场现状分析】

　　亚洲首富之子为结婚，18个月减肥216斤，婚礼还没办，又胖回去了…...

　　今年不举行总理记者会，如无特殊情况，本届全国人大后几年也不再举行总理记者会

　　苹果 M3 MacBook Pro 未来通过更新可外接 2台 5K@60Hz 显示器