万字长文梳理如何扩展大语言模型的上下文长度:算法原理、实现方法与适用场景(RoPE、YaRN、优化Attention、RAG等)
2026/5/31 16:03:13 网站建设 项目流程

万字长文梳理如何扩展大语言模型的上下文长度:算法原理、实现方法与适用场景(RoPE、YaRN、优化Attention、RAG等)

原创 功夫熊猫 熊猫AI自习室2025年12月15日 14:01

在大模型应用或者智能体应用开发中(比如智能客服、办公助手、基于deep research的PPT生成助手等),都离不开基座大模型本身的各类能力或者说边界。

其中有一项就是大模型本身能够承载的上下文长度,如果大模型的上下文长度十分有限,那么就意味着它手上能处理的信息量较少,随着多轮对话或者智能体不断的交互过程,上下文的信息其实是越来越多的,如果你的上下文只有三五千个token,那么一定要对信息进行压缩或者选择性的丢失,这其实也就是今年特别火的上下文工程技术。

如果对大模型或者智能体的上下文工程感兴趣,可以参考这篇文章:一文看懂AI智能体系统背后的重要技术——上下文工程(Context Engineering)

那么,有什么技术手段可以增加大模型的上下文长度呢?比如将大模型的上下文长度从32k扩充到64k、128k甚至更多?这样可以让大模型获取和处理更多的信息,从而让我们在和大模型或者Agent复杂的多轮交互中可以容纳下更多的信息和数据。

本文主要内容:

大模型的上下文长度扩展技术

我在这篇文章中将进行大语言模型(主要是基于解码器架构的大模型,即Decoder-Only架构的大模型)的上下文长度扩展技术进行综述类分享。

本文主要内容如下:

针对以GPT为代表的纯解码器(Decoder-only)模型的上下文长度扩展方法。包括每种方法的算法原理、实现方案、开源框架、优缺点,并写了通俗易懂的案例解释。在评估优缺点时,考虑了技术实现难度、对模型性能的影响、计算资源消耗以及实际应用中的部署成本。

当然,由于个人水平有限,如果我哪里写的不对,还请及时给我提出,个人觉得,大模型中的上下文扩展技术(比如各种扩展方法、多模态大模型的扩展等)值得探索的地方还非常多。

扩展GPT、Qwen、DeepSeek类解码器模型的上下文长度是当前大语言模型研究的核心挑战之一。主要方法包括:

1) 改进位置编码,如使用旋转位置编码(RoPE)及其扩展技术(位置插值PI、YaRN),通过调整位置信息的表示方式来适应更长的序列;

2) 优化注意力机制,采用稀疏注意力(如滑动窗口、全局+局部注意力)来降低计算的二次方复杂度;

3) 引入外部记忆,通过检索增强生成(RAG)等技术,将长文本信息存储在外部数据库中,按需检索;

4) 分割与滑动窗口,将长文本分块处理,并结合滑动窗口来保持块间信息的流通;

5) 并行编码(CEPE),引入一个辅助编码器来处理长上下文,并通过交叉注意力与主解码器协同工作;

6) 提示压缩,在输入模型前对冗长的提示进行精简。这些方法在实现难度、性能、资源消耗和部署成本上各有权衡,适用于不同的应用场景。

图:大语言模型(LLM)上下文长度扩展技术的分类体系。该图将这些技术区分为插值和外推两类,每一类又进一步划分为零样本和微调。在这一上下文长度扩展领域中,研究最多的技术包括位置编码(Positional Encoding)、检索(Retrieval)、注意力机制(Attention)以及基于RoPE(旋转位置编码)的方法。

图片来源于论文,https://arxiv.org/pdf/2401.07872

太长不看版

(把总结放在最前面了)

扩展类GPT纯解码器模型的上下文长度是当前大语言模型领域一个活跃且至关重要的研究方向。从改进位置编码到引入外部记忆,再到优化注意力机制和并行处理,各种方法百花齐放,共同推动了模型处理长文本能力的边界。每种方法都有其独特的优势和适用场景,也伴随着不同的技术挑战和成本。

综合对比一下

技术实现难度对比

方法

技术实现难度

核心要求

改进位置编码 (RoPE, PI, YaRN)

中等

修改模型代码,理解RoPE原理,准备长文本数据进行微调。

优化注意力机制 (稀疏注意力)

较高

设计复杂的稀疏模式,可能需要编写自定义CUDA内核。

引入外部知识 (RAG)

较高

构建和维护外部向量数据库,训练或集成检索器。

分割与滑动窗口

中等

修改模型架构,实现注意力掩码和层间连接。

并行编码 (CEPE)

较高

修改模型架构,插入编码器和交叉注意力模块,训练新模块。

提示压缩

中等

训练压缩模型或使用现有工具,设计压缩策略。

性能与资源消耗权衡

方法

对模型性能的影响

计算资源消耗

部署成本

改进位置编码

短文本性能稳定,长文本性能提升显著。

较低(主要在微调阶段)。

低(直接部署微调后的模型)。

优化注意力机制

可能丢失长距离依赖,但效率极高。

显著降低(尤其在长序列上)。

中等(需优化稀疏计算内核)。

引入外部记忆

能有效处理超长文本,但受限于检索质量。

较高(需额外的存储和检索开销)。

高(需部署复杂系统)。

分割与滑动窗口

在效率和性能间取得平衡,但可能丢失跨块依赖。

较低(与窗口大小相关)。

中等(需优化推理逻辑)。

并行编码 (CEPE)

在检索增强任务上表现优异,效率高。

中等(编码器较小,计算高效)

中等(需部署两个模型)。

提示压缩

可能丢失细节信息,影响精确理解任务。

较低(主要在压缩阶段)。

低(可直接使用压缩提示)。

适用场景分析

  • 改进位置编码:适用于希望在不大幅增加系统复杂性的前提下,将现有模型的上下文长度扩展到数万级别的场景。这是目前最经济、最高效的扩展方法之一,尤其适合资源有限的研究者和开发者。

  • 优化注意力机制:适用于对计算效率要求极高,且任务本身对长距离依赖关系不那么敏感的场景,如长文档的初步筛选、大规模语料的分析等。

  • 引入外部记忆 (RAG):适用于需要处理海量、动态变化的外部知识(如企业知识库、实时新闻)的场景。RAG是目前实现“无限”上下文和知识实时更新的最成熟方案。

  • 分割与滑动窗口:适用于需要处理远超模型上下文窗口的连续文本,且对局部上下文依赖较强的任务,如长篇文章的摘要、分段翻译等。

  • 并行编码 (CEPE):适用于对长文本处理性能和效率都有较高要求的场景,尤其是在检索增强生成和上下文学习等任务中,CEPE展现出了巨大的潜力。

  • 提示压缩:适用于输入提示非常冗长,且任务核心信息相对集中的场景。它可以作为一种通用的“预处理”步骤,与其他方法结合使用,以进一步提高效率。

下面是详细的分析和介绍,主要是偏技术综述类的详细说明。

核心挑战:为什么类GPT模型有上下文长度限制?

以GPT为代表的纯解码器(Decoder-only)模型在自然语言处理领域取得了巨大成功,但其能够处理的文本长度(即上下文长度)却受到严格限制。

这一限制并不是凭空而来,而是源于其底层架构——Transformer的两个核心机制:自注意力机制(Self-Attention)和位置编码(Positional Encoding)。理解这两个瓶颈是探索上下文长度扩展技术的前提。

注意力机制的“二次方”瓶颈

Transformer模型的核心是自注意力机制,它允许模型在处理一个序列时,计算序列中每个单词与其他所有单词之间的相关性权重。这种“全局视野”是其强大能力的关键,但也带来了巨大的计算和内存开销。

具体来说,对于一个长度为 L 的输入序列,自注意力机制的计算复杂度和内存占用都与 L 的平方成正比,即 O(L²) 。

这意味着,当输入序列长度增加时,所需的计算资源和显存会呈指数级增长。

例如,将上下文长度从4K扩展到128K,计算量理论上会增加超过约1000倍 。这种二次方增长的复杂性使得在超长序列上直接训练和推理变得极其昂贵,甚至不可行。

以LLaMA模型为例,训练一个4K上下文长度的模型大约需要3G显存来缓存KV Cache,而扩展到128K则需要高达100G的显存,这对GPU资源提出了严峻的挑战 。

位置编码的“视野”局限

为了让模型理解单词在句子中的顺序,Transformer引入了位置编码。

传统的绝对位置编码为每个位置分配一个固定的向量,这使得模型能够区分“猫追老鼠”和“老鼠追猫”的不同。

然而,这种编码方式通常在模型训练时就被固定在一个有限的范围内(例如,最多支持2048或4096个位置)。

当模型在推理时遇到一个比训练时更长的序列时,它就无法为这些“超出视野”的新位置生成有效的位置编码,导致模型性能急剧下降,甚至完全失效 。这种现象被称为“外推”能力差。

虽然像旋转位置编码(RoPE)这样的相对位置编码在一定程度上缓解了这个问题,但它们在处理远超训练长度的序列时,仍然会遇到困难,因为相对位置的差异会超出模型已学习的范围,导致注意力分数变得不稳定 。

大白话案例:小明的阅读困境——书太厚,一次只能看一页

你可以想象一下,小明正在阅读一本非常厚的书。

他的记忆力(相当于模型的计算和内存资源)有限,每次只能记住一页的内容。当他读到第二页时,他必须完全忘记第一页的内容,才能为新内容腾出空间。这就是模型上下文长度限制的本质。

即使书的内容非常精彩,情节前后关联,小明也只能“断章取义”,无法将整本书的情节联系起来。

如果他试图强行记住两页的内容,他的大脑就会“过载”(计算资源耗尽),导致阅读效率极低,甚至无法理解任何内容。

这个例子生动地说明了,上下文长度限制使得模型在处理长文档时,无法有效利用全文信息,导致“健忘”和理解偏差。

所以,到底有哪些方法可以从模型的内部和外部增加上下文长度?

方法一:改进位置编码

——为模型提供更广阔的“视野”

为了解决位置编码的“视野”局限,研究者们提出了一系列改进方法,核心思想是让模型能够“理解”并处理超出其原始训练范围的位置信息。其中,旋转位置编码(RoPE)及其扩展技术是目前最主流和有效的方案之一。

关于大模型位置编码的详细文章可以参考,【一文读懂】Transformer架构核心技术之一:位置编码算法原理、实现和应用

旋转位置编码(RoPE)及其扩展的算法原理

旋转位置编码(RoPE)是一种相对位置编码方法,它不直接为每个位置分配一个固定的向量,而是通过旋转向量来表示位置信息。

核心思想是,将词嵌入向量看作复数,并通过旋转矩阵对其进行变换,旋转的角度与位置索引相关。这样,两个位置之间的相对距离就体现在它们对应向量的旋转角度差上。

这种方法天然地具有处理相对位置的能力,并且可以通过数学上的插值或外推来扩展到更长的序列。

RoPE的核心思想:用旋转表示位置

RoPE的核心在于将查询(Query)和键(Key)向量通过旋转矩阵进行变换。

具体来说,对于一个位置为m的查询向量q_m和一个位置为n的键向量k_n,它们的注意力分数可以通过计算旋转后的向量的内积得到。

这个内积的值仅取决于它们的相对位置m-n,而与绝对位置m和n无关。

这种设计使得模型能够更好地泛化到不同长度的序列。然而,原始的RoPE在处理远超训练长度的序列时,仍然会遇到问题,因为当相对位置差|m-n|过大时,旋转角度会超出模型已学习的范围,导致注意力分数变得不稳定,模型性能下降 。

位置插值(PI)的核心思想:压缩位置索引

为了解决RoPE的外推问题,Meta的研究者提出了位置插值方法。

核心思想非常直观:既然模型只能“看懂”训练范围内的位置,那么我们就把超出的位置“压缩”到这个范围内。

具体来说,如果模型在训练时的最大上下文长度是L,而我们希望扩展到L'L' > L),PI方法会将所有位置索引i线性缩放为i * (L / L')。

例如,要将一个4K上下文长度的模型扩展到8K,PI会将位置索引0到8192线性映射到0到4096的范围内,换种方式说,PI就是对RoPE 中的频率基底(base)进行缩放,使得最大位置对应的旋转角度不超过原训练范围。

这样,所有位置编码都落在了模型已知的区间内,避免了因外推导致的灾难性性能下降。实验证明,通过PI方法,可以将LLaMA模型的上下文窗口从2K扩展到32K,仅需少量微调(1000步)即可达到很好的效果 。随着研究的进展,现在已经有了更高效的扩展方法,可以扩展到更大的上下文长度,而且效果要比PI方法好一些。

YaRN的核心思想:更精细的插值策略

虽然PI方法简单有效,但它对所有位置维度都进行了同等的缩放,这可能会丢失一些重要的细节信息。

YaRN(Yet another RoPE extensioN method)在此基础上提出了更精细的插值策略。

YaRN的核心思想是“高频外推,低频内插”。

在RoPE中,不同的维度对应着不同频率的旋转,高频维度(旋转速度快)对局部细节更敏感,而低频维度(旋转速度慢)对全局结构更敏感。

YaRN认为,高频信息在插值过程中容易被“挤在一起”而丢失,因此应该进行外推;而低频信息则适合进行插值。

YaRN通过引入一个基于波长的阈值,对不同频率的维度采用不同的处理方式:YaRN 对 RoPE 的不同频率分量采用不同的缩放策略,以保留局部细节。

这种策略更好地保留了模型的局部感知能力,从而在扩展上下文长度的同时,尽可能保持了模型的性能。

实现方案与开源框架

改进位置编码的方法通常需要对现有模型的代码进行修改,并在长文本数据上进行微调。

在现有模型(如LLaMA)上进行微调

对于像LLaMA这样使用RoPE的模型,实现位置插值或YaRN相对直接。

开发者需要修改模型中计算位置编码的部分,引入相应的缩放因子和插值逻辑。

然后,使用包含长文本的数据集对模型进行微调。微调的目的是让模型适应新的位置编码分布,并学习如何在更长的上下文中保持连贯性。

由于大部分模型参数保持不变,微调所需的计算资源相对较少。例如,LongQLoRA方法结合了位置插值和QLoRA,可以在单个32GB V100 GPU上将LLaMA2的上下文长度从4096扩展到8192甚至12000 。

目前,许多开源社区和框架都提供了对RoPE扩展技术的支持。

例如,Hugging Face的Transformers库已经集成了对RoPE和ALiBi等位置编码的支持,并提供了相关的配置参数。此外,还有一些专门用于扩展上下文长度的开源项目,如longrope和yarn等,它们提供了现成的实现和微调脚本,方便开发者快速应用这些技术。微软的LongRoPE项目甚至成功将Phi-3模型的上下文窗口扩展到了128K,并在多个基准测试中取得了优异的性能。

优缺点评估

改进位置编码是一种相对成熟和高效的上下文扩展方法,但它也有自己的优缺点。

评估维度

优点

缺点

技术实现难度

中等。需要修改模型代码,但改动相对较小,主要集中在位置编码的计算逻辑上。

需要对RoPE的原理有深入理解,并正确实现插值或外推公式。

对模型性能的影响

在短文本任务上,性能通常能保持在原有水平;在长文本任务上,性能有显著提升。

在极端长度下,性能仍可能下降。插值方法可能会损失一些精度。

计算资源消耗

较低。主要在微调阶段消耗资源,但远低于从头训练一个长上下文模型。

仍然需要一定的GPU资源进行微调,并且需要准备长文本数据集。

部署成本

低。微调后的模型可以直接部署,无需额外的系统或复杂的推理逻辑。

模型体积可能会略微增加,但通常影响不大。

通俗案例:音乐节的节拍器

原始节拍器:只能播放固定的节奏

想象一个音乐节上,有一个原始的节拍器。这个节拍器在出厂时就被设定好了,只能播放固定的节奏,比如每分钟120拍(BPM)。如果乐队想演奏一首节奏更快或更慢的歌曲,这个节拍器就无能为力了。这就像原始的绝对位置编码,只能处理训练时固定的上下文长度。

改进的节拍器:通过调整节拍速度,适应更长的乐曲((PI)或YaRN)

现在,音乐节升级了设备,换成了一个智能节拍器。

这个节拍器可以通过一个旋钮来调整节拍速度。当乐队演奏一首节奏更快的歌曲时,调音师可以将节拍器的速度调高;当演奏一首节奏更慢的歌曲时,则可以调低。

这个旋钮就类似于位置插值(PI)或YaRN中的缩放因子。通过调整这个因子,模型可以“适应”不同长度的文本,就像节拍器可以适应不同节奏的乐曲一样。

YaRN方法则更进一步,它不仅仅是简单地调整整体速度,而是对不同音高的音符(对应RoPE的不同维度)进行精细的调整,确保整首乐曲(长文本)听起来既和谐又富有细节。

优化注意力机制

——让模型“聪明地”忽略无关信息

在Transformer架构中,自注意力机制(Self-Attention)是模型理解上下文关系的核心。
然而,传统的全注意力机制要求序列中的每一个词元(token)都必须关注所有其他词元,这导致了计算复杂度和内存消耗随着序列长度的增加而呈二次方增长(O(n²)),从而限制了模型的上下文窗口。
关于注意力机制的详细解析文章可参考,大模型中的注意力机制技术原理、算法优缺点和适用场景解读(MHA、MQA、GQA、MLA、NSA、SSA、MoBA)
稀疏注意力通俗易懂解读可以参考,DeepSeek V3.2正式版来了!大白话解读稀疏注意力(DSA)、思考推理和Agent能力
为了解决这一瓶颈,研究人员们提出了一系列稀疏注意力机制。核心思想是,让模型在处理长序列时,不必关注所有信息,而是“聪明地”只关注最重要、最相关的部分,从而在保持性能的同时,大幅降低计算和内存开销。
这种方法类似于人类在阅读长篇文章时,会自然地将注意力集中在关键词、段落主题句以及与当前理解任务最相关的部分,而不是对每一个字都给予同等的关注度。

算法原理:稀疏注意力

稀疏注意力的本质是通过引入特定的稀疏模式或掩码来限制注意力矩阵中的非零元素数量,从而将计算复杂度从二次方降低到接近线性(O(n))或次二次方(如O(n√n))。

这种策略的背后是基于一个观察:在许多自然语言处理任务中,词元之间的依赖关系并非完全密集的,而是呈现出局部性和结构性。

核心思想:只关注最重要的部分

稀疏注意力的核心思想在于打破全注意力机制中“万物互联”的假设,转而采用一种更为高效和结构化的信息交互方式。

在全注意力机制中,每个查询(Query)向量都需要与所有键(Key)向量进行点积运算,以计算注意力权重,这导致了巨大的计算量。稀疏注意力则通过预定义的稀疏模式,让每个查询向量只与一小部分经过筛选的键向量进行计算。

这种筛选可以基于多种策略,例如只关注邻近的词元(局部注意力),或者根据某种规则选择一些可能具有全局信息的词元(全局注意力)。

通过这种方式,注意力矩阵从一个完全填充的密集矩阵变成了一个大部分元素为零的稀疏矩阵,从而可以利用稀疏矩阵运算来加速计算并节省内存。

这种方法的有效性在于,它能够在保留模型捕捉关键依赖关系能力的同时,显著降低计算负担,使得模型能够处理远超传统Transformer上下文窗口的超长序列。

例如,一个句子中的词语主要与其邻近的词语和少数几个关键的远距离词语(如指代词和先行词)相关。因此,通过设计合理的稀疏模式,可以在不显著损失模型性能的前提下,极大地提升其处理长序列的效率和可扩展性。不同的稀疏注意力变体主要通过设计不同的稀疏模式来实现,这些模式决定了每个词元可以关注哪些其他词元。

局部注意力:只关注邻近的词

局部注意力,也称为滑动窗口注意力,是一种简单而有效的稀疏注意力模式。它的核心思想是,序列中的每个词元只关注其周围一个固定大小窗口内的词元,而忽略窗口之外的所有词元。

这种模式基于一个直观的假设:在自然语言中,词语之间的语法和语义关系通常是局部的,即一个词的含义主要受其邻近词语的影响。

例如,在句子“有一只浅黄色的大概1岁的很可爱的毛茸茸的小猫在沙发上打盹”中,“小猫”这个词的含义与“毛茸茸的”和“在沙发上”等邻近词语密切相关,而与句子开头或结尾的词语关系较弱。

通过将注意力范围限制在一个局部窗口内,局部注意力将计算复杂度从O(n²)降低到O(n * w),其中w是窗口大小,通常远小于序列长度n。这使得模型在处理长序列时更加高效。

然而,局部注意力的主要缺点在于它无法捕捉长距离的依赖关系,例如跨句子的指代消解或长程的逻辑推理,因为窗口之外的词元信息被完全忽略了。

随机注意力:随机关注一些词

为了弥补局部注意力无法捕捉长距离依赖的缺陷,随机注意力被提出作为一种补充机制。核心思想是,除了关注邻近的词元外,每个词元还会随机关注序列中其他位置的一些词元。

这种随机连接为信息在序列中的远距离传播提供了一条“捷径”。例如,在BigBird模型中,除了局部窗口和少数几个全局词元外,每个词元还会随机连接到其他一些词元。

这种设计背后的直觉是,虽然随机选择的词元可能不总是最相关的,但只要存在足够多的随机连接,重要信息就有很大概率通过这些连接在序列中传播,从而被模型捕捉到。

随机注意力的引入,使得模型在保持局部信息处理能力的同时,也具备了一定的全局信息感知能力。这种方法的计算开销相对较小,因为它只增加了固定数量的随机连接,其复杂度仍然是线性的。然而,其效果在很大程度上依赖于随机连接的数量和分布,且缺乏对长距离依赖关系的明确建模,是一种相对“盲目”的解决方案。

全局+局部注意力:结合全局视野和局部细节

全局+局部注意力是一种更为精细和强大的稀疏注意力模式,它试图结合局部信息的精确性和全局信息的完整性。

在这种模式下,模型同时维护两种类型的注意力连接:一种是局部注意力,用于捕捉邻近词元之间的短程依赖关系;另一种是全局注意力,用于捕捉序列中少数关键词元与所有其他词元之间的长程依赖关系。

这些被选中的全局词元通常扮演着信息枢纽的角色,它们能够聚合来自整个序列的信息,并将其传播到需要的地方。例如,在Longformer模型中,除了滑动窗口的局部注意力外,还引入了任务相关的全局词元(如文档分类任务中的[CLS]标记),这些全局词元可以关注到整个序列。

在BigBird模型中,则通过随机选择一些词元作为全局词元,并结合局部和随机注意力,形成了一个信息流通能力强大的稀疏图结构。

这种组合策略的优势在于,它既能高效地处理局部信息,又能通过全局词元建立起长距离的信息通路,从而在计算效率和模型性能之间取得了很好的平衡,使其能够胜任文档摘要、问答等需要理解长文本的任务。

实现方案与开源框架

稀疏注意力机制的实现通常需要对Transformer模型的核心架构进行修改,特别是自注意力层的计算逻辑。

这涉及到设计并实现特定的稀疏模式,并将其应用于注意力矩阵的计算过程中。幸运的是,一些研究团队已经开源了他们的模型和代码,为社区提供了宝贵的参考和可直接使用的工具。

(1)Longformer、BigBird等模型的实现

Longformer和BigBird是两个在稀疏注意力领域具有代表性的开源模型,它们分别实现了不同的稀疏注意力模式,并取得了显著的成功。

  • Longformer:该模型主要采用滑动窗口注意力和扩张滑动窗口注意力来处理局部信息,同时通过引入全局注意力来捕捉长距离依赖。在实现上,Longformer通过自定义的CUDA内核来高效地计算稀疏注意力矩阵,避免了生成完整的n×n注意力矩阵,从而大大节省了内存和计算资源。其开源代码和预训练模型可以在Hugging Face等平台上找到,为处理长文档任务(如文档摘要和问答)提供了强大的基础。

  • BigBird:BigBird的设计更为精巧,它结合了三种注意力机制:局部注意力、随机注意力和全局注意力。这种组合被证明在理论上可以近似全注意力机制的性能,同时保持线性计算复杂度。BigBird的实现同样依赖于优化的计算内核,以处理其复杂的稀疏模式。它在多个长文本基准测试中取得了当时的最优性能,证明了其设计的有效性。BigBird的开源实现也为后续研究提供了重要的参考。

这些模型的实现不仅展示了稀疏注意力的具体应用,也为开发者提供了可复现的范例,帮助他们理解如何在实践中设计和优化稀疏注意力机制。

(2)在现有模型中集成稀疏注意力模式

将稀疏注意力集成到现有的模型(如GPT系列)中,通常需要对模型的自注意力层进行修改。这可以通过以下几种方式实现:

  1. 修改注意力计算逻辑:最直接的方法是重写模型中的自注意力函数。开发者需要定义一个稀疏掩码,该掩码是一个与注意力矩阵形状相同的布尔矩阵,其中True表示允许注意力连接,False表示禁止。在计算注意力分数时,将不允许的位置(即掩码中为False的位置)的分数设置为一个极小的负数(如负无穷),这样在经过Softmax归一化后,这些位置的权重就会接近于零,从而实现稀疏化。

  2. 使用稀疏矩阵库:对于某些固定的稀疏模式,可以利用专门的稀疏矩阵计算库(如cuSPARSE)来进行优化。这些库针对稀疏矩阵的乘法等操作进行了高度优化,可以显著提升计算效率。开发者需要将注意力计算转化为稀疏矩阵运算的形式。

  3. 利用现有框架的扩展性:一些深度学习框架(如PyTorch和TensorFlow)提供了自定义算子的机制。开发者可以编写自定义的CUDA或C++算子来实现特定的稀疏注意力计算逻辑,并将其集成到模型中。这种方式虽然技术难度较高,但可以实现最大程度的性能优化。

  4. 采用模块化设计:一些研究工作将稀疏注意力实现为独立的模块或层,可以方便地替换掉标准Transformer中的自注意力层。这种模块化的设计使得在现有模型中尝试不同的稀疏注意力模式变得更加容易。

无论采用哪种方式,集成稀疏注意力都需要对Transformer的内部工作原理有深入的理解,并具备一定的编程和优化能力。

优缺点评估

稀疏注意力机制作为一种有效扩展上下文长度的方法,其优缺点非常鲜明,主要体现在技术实现、模型性能、计算资源消耗和部署成本等多个方面。

技术实现难度:较高,需设计复杂的注意力模式

稀疏注意力的技术实现难度相对较高,与直接微调模型或修改位置编码不同,实现稀疏注意力通常需要深入修改模型的核心计算图,特别是自注意力层。

这不仅仅是简单地调整参数,而是需要设计和实现全新的计算逻辑。开发者需要仔细考虑稀疏模式的设计,例如如何确定局部窗口的大小、如何选择全局词元、如何设置随机连接的数量等,这些设计决策会直接影响模型的性能和效率。

此外,为了获得理想的性能,通常需要编写自定义的CUDA内核或使用专门的稀疏计算库,这对开发者的编程能力和对底层硬件的理解提出了较高的要求。相比之下,一些其他方法(如位置插值)可能只需要在现有模型上进行微调,技术门槛相对较低。

对模型性能的影响:可能丢失长距离依赖信息

稀疏注意力对模型性能的影响是双面的。

一方面,通过引入合理的稀疏模式,模型能够在处理长序列时保持甚至提升性能,因为它能够更专注于相关信息,避免了全注意力中可能出现的噪声和干扰。

许多研究表明,在文档摘要、长文本问答等任务上,采用稀疏注意力的模型(如Longformer, BigBird)能够取得比标准Transformer更好的效果。然而,另一方面,稀疏化本身也意味着信息的丢失。如果稀疏模式设计不当,或者任务本身需要密集的长距离依赖关系,那么稀疏注意力可能会导致模型性能下降。

例如,对于一些需要理解整个文本全局结构或进行复杂逻辑推理的任务,过于激进的稀疏化可能会切断关键的信息通路,导致模型无法捕捉到重要的长程依赖关系,从而影响最终效果。因此,在设计稀疏注意力模式时,需要在计算效率和模型性能之间进行仔细的权衡。

计算资源消耗:显著降低,尤其在长序列上

稀疏注意力最显著的优势之一就是其在计算资源消耗方面的巨大节省。通过将注意力矩阵稀疏化,模型的计算复杂度从O(n²)降低到接近线性或次二次方,这意味着在处理长序列时,其计算时间和内存占用会大幅减少。

例如,对于一个长度为10,000的序列,全注意力机制需要计算和存储一个10,000 x 10,000的密集矩阵,这在大多数硬件上是不可行的。

而采用稀疏注意力,每个词元只关注少数几个词元,计算量和内存需求将降低几个数量级。这使得在消费级GPU上训练和处理超长序列成为可能,极大地降低了长文本模型研究和应用的成本。这种资源消耗的显著降低,是稀疏注意力机制被广泛应用和研究的核心理由之一。

部署成本:中等,需优化稀疏计算内核

稀疏注意力模型的部署成本处于中等水平。虽然模型本身可能不需要像检索增强系统那样复杂的外部组件,但为了充分发挥其效率优势,通常需要对部署环境进行一定的优化。

标准的深度学习推理框架可能无法高效地执行稀疏矩阵运算,因此可能需要使用专门的、针对稀疏计算优化的内核或库。这意味着部署团队需要具备一定的性能优化能力,或者依赖于社区或硬件厂商提供的优化方案。

此外,由于稀疏模式可能比较复杂,模型的调试和分析也可能比标准Transformer更具挑战性。

通俗案例:蜘蛛结网

普通蜘蛛:在每一寸空间都结网,耗时耗力

想象一下,有一只非常勤奋但不太聪明的蜘蛛。它为了捕捉飞虫,决定在房间的每一寸空间都织上密密麻麻的网。从天花板到地板,从墙角到家具背后,它不辞辛劳地编织着一张巨大而密集的网。

这种做法虽然最终可能也能抓到一些虫子,但过程极其耗时耗力,需要消耗大量的蛛丝和能量。而且,这张巨大的网非常难以维护,一旦某个地方破了,修复起来也很麻烦。

这就像传统的全注意力机制,模型在处理一段长文本时,需要计算文本中每一个词与其他所有词之间的关系,计算量巨大,效率低下,尤其是在处理非常长的文本时,会变得非常“吃力”。

聪明蜘蛛:只在关键位置结网,高效捕获猎物

现在,我们再想象另一只非常聪明的蜘蛛。

它观察到,飞虫通常喜欢聚集在窗户边、灯光下或者垃圾桶附近。于是,它不再盲目地在整个房间结网,而是选择性地在这些“关键位置”——也就是飞虫最可能出现的地方——织出几张小而精的网。

它还会在一些连接这些关键位置的“交通要道”上织一些丝线,以便自己能快速地在不同区域之间移动。这样一来,这只聪明的蜘蛛用少得多的蛛丝和精力,就构建了一个高效的捕猎系统。它不仅能捕捉到大部分飞虫,还能节省大量时间和能量,维护起来也方便得多。

这就像稀疏注意力机制,模型不再“傻傻地”关注所有信息,而是学会“聪明地”只关注那些最重要、最相关的部分(比如邻近的词和一些关键的远距离词),从而在保持高性能的同时,大大提升了处理长文本的效率。这只聪明的蜘蛛,就是采用了稀疏注意力策略的AI模型。

方法三:引入外部记忆

——为模型配备一个“外部笔记本”

尽管优化注意力机制可以在一定程度上缓解计算压力,但当上下文长度达到数百万甚至无限时,即使是稀疏注意力也变得难以处理。

为了应对这一挑战,研究人员借鉴了人类记忆的工作方式,提出为模型引入外部记忆(知识)的方法。

这种方法的核心思想是将长文本的信息存储在一个外部的、可动态更新的知识库中,模型在需要时再从记忆库中检索相关信息,从而模拟出“无限”的上下文长度。

技术原理:检索增强生成(RAG)。

在大语言模型应用中,检索增强生成的基本流程是:首先,将长文本分割成多个小块,并使用一个编码器将每个小块转换成一个向量表示;然后,将这些向量存储在一个外部的向量数据库中;当模型需要处理一个新的查询时,它会首先生成一个查询向量,然后在外部知识库中检索与查询向量最相关的几个文本块;最后,将这些检索到的文本块与原始查询一起输入到模型中,生成最终的回答。

核心思想:将长文本信息存储在外部记忆中

这种方法的核心思想是将模型的“工作记忆”(即上下文窗口)和“长期记忆”(即外部知识库)分离开来。模型的工作记忆仍然有限,但它可以通过检索机制,从庞大的长期记忆(知识)中获取所需的信息。这就像人类在阅读一本厚书时,不会试图记住所有内容,而是会在需要时查阅目录或索引,找到相关的章节进行阅读。

4.1.2 可重访知识库:动态更新和检索知识

外部知识库通常是动态的,可以根据新的信息进行更新。例如,在处理一个长对话时,模型可以将新的对话内容不断地添加到知识库中。此外,一些高级的记忆增强方法还引入了类似操作系统的内存管理机制,允许模型自主地管理其上下文,通过“函数调用”来动态地修改和检索记忆,从而更智能地处理长文本 。

检索增强生成(RAG):结合检索器和生成器

RAG是在大型语言模型中最典型的应用。它将一个检索器和一个生成器结合起来。检索器负责从外部知识库中找到与查询相关的信息,生成器则利用这些信息来生成更准确、更相关的回答。这种方法不仅能够处理超长的上下文,还能有效地减少模型的“幻觉”问题,因为它生成的内容是基于检索到的真实信息。

实现方案

实现记忆增强方法需要构建一个包含检索器和生成器的系统,并维护一个外部的向量数据库。

构建外部向量数据库(如FAISS, Milvus)

外部记忆库通常使用向量数据库来实现。向量数据库能够高效地存储和检索高维向量。目前,有许多成熟的向量数据库可供选择,如FAISS、Milvus等。这些数据库提供了高效的相似度搜索算法,能够在大规模向量集合中快速找到与查询向量最相似的向量。

优缺点评估

引入外部记忆是一种功能强大的上下文扩展方法,但它在技术实现、性能影响、资源消耗和部署成本方面也有其独特的权衡。

技术实现难度:较高,需构建和维护外部系统

从技术实现的角度来看,引入外部记忆(知识)的难度较高。它需要构建和维护一个外部的向量数据库系统(实践中基本上都是多路召回)。这涉及到数据预处理、向量编码、索引构建、相似度搜索、重排序等多个环节,对系统设计和工程能力的要求较高。

对模型性能的影响:能有效处理超长文本

在性能方面,RAG能够有效地处理超长文本,在许多长文本理解和问答任务上表现出色。然而,它的性能在很大程度上依赖于检索器的质量。如何提高检索的准确性,是RAG系统面临的一个关键挑战。

计算资源消耗:较高,需额外的存储和检索开销

在计算资源消耗方面,引入外部知识需要额外的存储和计算开销。向量数据库需要占用大量的存储空间来存储文本块的向量表示。此外,每次查询都需要进行向量相似度搜索,这也会带来一定的计算延迟。虽然相比于二次方复杂度的注意力计算,这种开销通常是可以接受的,但仍然需要考虑其对系统整体性能的影响。

部署成本:较高,需部署和维护复杂的系统

在部署成本方面,引入外部记忆是需要部署和维护一个包含模型、向量数据库和检索服务的复杂系统。这不仅增加了部署的复杂性,也增加了运维的成本。

通俗案例:学生的笔记本

小张听课:记忆力有限,容易忘记前面的内容

想象小张在课堂上听老师讲课,老师的讲解内容很多,但小张的记忆力有限,一次只能记住一小部分内容。当她听到后面的内容时,前面的内容可能已经忘记了。这就像GPT模型,其上下文窗口有限,难以处理长文本。

小张做笔记:将关键信息记在笔记本上,随时查阅

为了解决这个问题,小张开始做笔记。她把老师讲解的重点内容记在笔记本上。当需要回顾前面的知识点时,她不需要依赖自己的记忆力,而是可以直接翻阅笔记本。这个笔记本就是模型的“外部记忆”。通过做笔记,小张相当于拥有了一个“无限”的记忆,可以随时查阅任何记录过的信息,从而更好地理解和掌握课程内容。

方法四:分割与滑动窗口

——将长文本“分块”处理

当面对远超模型上下文窗口的文本时,一种直观且有效的策略是“分而治之”。分割与滑动窗口方法正是基于这一思想,将长文本切分成多个小块,让模型在有限的视野内逐步处理和理解整个文本。这种方法不依赖于对模型内部结构的复杂修改,而是通过巧妙的输入组织方式来扩展模型的有效上下文长度。

算法原理:上下文窗口分割

上下文窗口分割的核心思想是将一个长输入序列分割成若干个较短的、可以独立处理的片段或块。模型每次只处理一个或几个片段,而不是一次性处理整个序列。这种方法的关键在于如何处理片段之间的依赖关系,以确保模型能够理解整个文本的连贯性。

核心思想:将长文本分割成多个小块

最基础的分割方法是将长文本简单地切成固定大小的块。例如,一个16K的文本可以被切成4个4K的块。然后,模型可以独立地处理每个块,并对每个块的输出进行汇总或选择。然而,这种方法忽略了块与块之间的上下文联系,可能导致模型对整体内容的理解出现偏差。为了解决这个问题,研究者们提出了更复杂的策略,如滑动窗口和层次化处理。

滑动窗口注意力

滑动窗口注意力是一种在分割基础上进行改进的技术。它允许模型在处理当前片段时,不仅关注片段内部的内容,还可以“看到”邻近的片段。具体来说,模型在处理第i片段时,其注意力机制会覆盖第i个片段以及其前后各k个片段的内容。这种“滑动”的窗口使得信息可以在片段之间传递,从而捕捉局部的长距离依赖关系。例如,Mistral AI的模型结合使用了滑动窗口注意力机制和旋转位置编码,在处理长文本时表现出较高的效率。

SWAN-GPT:结合全局和滑动窗口注意力(目前来看没有流行)

SWAN-GPT是一种更先进的架构,它巧妙地结合了全局注意力和滑动窗口注意力的优点。

SWAN-GPT的架构由两种类型的层交错组成:一种是带有旋转位置编码(RoPE)的滑动窗口注意力层(SWA-RoPE),另一种是没有任何位置编码的全局注意力层(NoPE)。

滑动窗口层负责处理局部信息,确保模型对邻近的上下文有精确的理解;而全局层则负责捕捉长距离的依赖关系,因为它可以不受位置编码的限制,在整个上下文中进行注意力计算。这种混合架构使得SWAN-GPT能够在不增加过多计算负担的情况下,有效地处理远超训练长度的序列。实验表明,SWAN-GPT可以在无需额外长文本训练的情况下,将模型的有效上下文长度扩展到训练长度的16倍以上 。

实现方案与开源框架

实现分割与滑动窗口方法通常需要对模型的架构进行一定的修改,尤其是在注意力机制部分。

在模型架构中实现滑动窗口机制

要在模型中实现滑动窗口注意力,开发者需要修改Transformer的注意力层代码。具体来说,需要创建一个注意力掩码,该掩码限制了每个Token只能关注到其所在窗口内的其他Token。对于SWAN-GPT这样的混合架构,还需要设计层与层之间的连接方式,确保全局信息和局部信息能够有效地融合。例如,SWAN-GPT采用了一种1:3的模式,即一个全局NoPE层后跟三个滑动窗口层,并重复这个模式 。

相关模型(如SWAN-GPT)的开源实现

目前,已经有一些采用滑动窗口或类似机制的模型被开源。例如,SWAN-GPT的论文中提到了其架构的详细信息,并展示了如何将现有的预训练模型(如RoPE GPT)转换为SWAN架构,只需进行极少的持续预训练(约2%的原始计算量)即可实现长上下文能力 。此外,像Longformer和BigBird这样的早期模型也提供了稀疏注意力的实现,可以作为参考。

优缺点评估

分割与滑动窗口方法在效率和性能之间提供了一个很好的平衡点,但也有其固有的局限性。

评估维度

优点

缺点

技术实现难度

中等。需要修改模型架构,但逻辑相对清晰,主要是实现注意力掩码和层间连接。

对于复杂的混合架构(如SWAN-GPT),设计和调优可能更具挑战性。

对模型性能的影响

在保持较低计算复杂度的同时,显著提升了长文本处理能力。SWAN-GPT在多个长文本基准测试中表现出色。

滑动窗口的大小是一个超参数,选择不当可能会影响性能。模型可能仍然难以捕捉超出窗口范围的远距离依赖。

计算资源消耗

较低。计算复杂度与窗口大小相关,而不是整个序列长度,因此可以高效处理超长文本。

相比于稀疏注意力,其计算量仍然与窗口大小成二次方关系,但窗口大小通常远小于序列长度。

部署成本

中等。需要优化窗口滑动的推理逻辑,但不需要额外的外部系统。

模型架构的特殊性可能需要特定的推理优化,以充分利用其效率优势。

通俗案例:拼图游戏

直接看整幅画:视野有限,看不清细节

想象你正在看一幅巨大的拼图,但你只能站在一个固定的位置,视野有限,无法一次性看到整幅画的全部细节。这就像原始Transformer模型,其上下文窗口有限,无法处理长文本的全部信息。

用放大镜看:每次只看一小块,然后移动放大镜

现在,你拿了一个放大镜。你可以通过放大镜每次只看拼图的一小块,仔细地观察细节。

然后,你移动放大镜,去看下一块。这个放大镜的视野就相当于模型的上下文窗口,而你的移动过程就是“滑动窗口”。通过这种方式,你可以逐步地、仔细地检查整个拼图。

SWAN-GPT的混合架构则像是,你不仅用放大镜看局部,还会不时地退后几步,用肉眼观察整幅画的整体布局(全局注意力),以确保你拼出来的图案在全局上是正确的。这种方法让你既能看清细节,又能把握整体,高效地完成拼图。

方法五:并行编码(CEPE)

——让两个模型“协同作战”

在探索如何有效扩展纯解码器模型上下文长度的众多路径中,Context Expansion with Parallel Encoding (CEPE) 提供了一种独特且高效的解决方案。
该方法并非直接在原有模型架构上进行修补,而是通过引入一个协同工作的“助手”模型,从根本上改变了长文本信息的处理方式。
CEPE的核心思想是将处理长上下文的繁重任务从主模型(解码器)中分离出来,交由一个轻量级的小型编码器来并行处理。
这种“双模型协同”的架构,不仅显著提升了模型处理长文本的能力,还在计算效率和资源消耗上实现了重大突破。通过巧妙地利用交叉注意力机制,主解码器可以在需要时“查阅”由编码器处理好的长文本摘要,从而在有限的计算资源下,实现对超长上下文的有效利用 。

算法原理:并行编码上下文扩展(CEPE)(目前来看这个方法没有火起来)

CEPE的算法原理可以概括为“分工协作,高效查阅”。它通过在现有的纯解码器模型(如GPT系列)的基础上,增加一个小的、双向的预训练编码器,并在解码器的每一层中插入交叉注意力模块,从而构建一个全新的、能够处理超长上下文的模型架构。

这种方法的精妙之处在于,它保留了原有大语言模型(作为解码器)的强大生成能力和知识储备,同时通过外部编码器为其提供了前所未有的“视野”广度。

核心思想:用一个小型编码器处理长上下文

CEPE框架的第一个核心组件是一个小型的编码器模型(M_enc)。与庞大的解码器模型(M_dec)相比,这个编码器在参数规模和计算复杂度上都小得多 。其主要职责是处理输入的超长上下文。

具体来说,当模型接收到一个包含T个token的输入序列时,CEPE会将其分割成两部分:一部分是前m个token组成的“额外上下文”(C),另一部分是后n个token组成的“主输入”(X)。这个额外的长上下文C会被进一步分割成k个较小的块(C1, C2, ..., Ck)。

然后,小型编码器M_enc会对这些分块进行并行编码。由于编码器是双向的,它能够生成比单向解码器更丰富的、包含前后文信息的token表示。这种并行处理的方式,避免了在解码器中处理整个长序列时所需的全注意力机制所带来的二次方计算复杂度,极大地提升了处理效率 。

也可以参考这边文章的解读:陈丹琦团队新作:Llama-2上下文扩展至128k,10倍吞吐量仅需1/6内存

6.1.2 交叉注意力机制:让解码器关注编码器的输出

CEPE框架的第二个关键创新是在解码器的每一个Transformer层中,在自注意力层和前馈网络之间,插入一个交叉注意力模块 。这个模块是连接编码器和解码器的桥梁。在解码器处理主输入X的过程中,每一层的交叉注意力模块都会以该层解码器的隐藏状态作为查询(Query),而以编码器处理完所有上下文块后输出的最终隐藏表示(Φ)作为键(Key)和值(Value)。

通过这种方式,解码器可以在生成每一个新token时,动态地“查询”和“关注”由编码器提炼出的长上下文信息。这相当于为解码器配备了一个可以随时查阅的、关于超长背景知识的“外部记忆库”。值得注意的是,由于交叉注意力只关注编码器最后一层的输出,CEPE避免了缓存解码器中每个token在每层的键值对,从而大幅降低了内存消耗 。

分块处理与并行计算

CEPE之所以能够实现高效的长上下文处理,其分块处理和并行计算的策略至关重要。如前所述,长上下文被分割成多个小块,每个块由小型编码器独立且并行地进行处理 。这种设计带来了几个显著优势。

首先,它使得模型的计算复杂度与上下文长度呈线性关系,而非二次方关系,极大地降低了计算成本。

其次,由于每个分块都使用独立的位置编码,CEPE巧妙地规避了传统位置编码(如RoPE)在处理超出训练长度的序列时泛化能力不佳的问题。模型在训练时只需要处理一定长度的序列(例如8K token),但在推理时却可以利用这种分块机制处理远超训练长度的上下文(例如128K token),展现出强大的长度泛化能力。

这种设计使得CEPE在保持高性能的同时,具备了极高的计算效率和资源利用率。

实现方案与开源框架

CEPE的实现方案主要围绕如何将一个预训练的小型编码器与一个冻结的、纯解码器的大语言模型进行有效整合。这个过程不仅涉及模型架构的修改,还包括针对新架构的训练和微调策略。普林斯顿大学的研究团队已经发布了相关的开源代码和模型,为研究者和开发者提供了实践CEPE方法的完整路径 。

6.2.1 在现有解码器模型中插入编码器和交叉注意力模块

实现CEPE的第一步是选择一个合适的预训练纯解码器模型作为基础,然后,需要选择一个或训练一个小型的双向编码器。在原始论文的实验中,研究者使用了一个参数量约为4.35亿的RoBERTa-large风格的编码器,并将其与一个70亿参数的LLaMA-2解码器相结合。

接下来,需要在解码器的每一个Transformer层中插入交叉注意力模块。这些新插入的模块,连同小型编码器本身,是模型中唯一需要训练的参数。原有的、庞大的解码器模型参数则被冻结,这大大降低了训练的计算成本和数据需求。

CEPE的开源实现与微调指南

有研究团队已经在GitHub上开源了CEPE的完整实现代码,包括数据预处理、模型训练和评估脚本 。这为希望复现和应用该技术的开发者提供了极大的便利。开源项目提供了详细的指南,涵盖了从环境配置到模型运行的全过程。

项目地址:https://github.com/princeton-nlp/CEPE

论文地址:https://arxiv.org/abs/2402.16617

例如,项目提供modeling_llama_flash.py文件,其中包含了修改后的、支持交叉注意力的LLaMA模型实现。训练过程分为两个阶段:预热阶段和标准训练阶段。在预热阶段,模型使用相同的输入来训练编码器和解码器,以初始化参数。在标准训练阶段,则采用标准的交叉熵损失来训练编码器和交叉注意力模块,同时保持解码器冻结。对于指令微调模型,还引入了KL散度损失来蒸馏原始模型的行为,确保新模型在扩展上下文的同时,不损失其原有的指令遵循能力 。

优缺点评估

CEPE作为一种创新的上下文扩展方法,在多个维度上展现出其独特的优势和一定的局限性。对其优缺点进行全面评估,有助于理解其适用场景和潜在挑战。

技术实现难度:较高,需修改模型架构并训练新模块

从技术实现的角度来看,CEPE的难度相对较高。它不仅仅是调整模型参数或修改位置编码,而是需要对现有的Transformer模型架构进行较为深入的改造。这包括在解码器的每一层中插入新的交叉注意力模块,并引入一个完全独立的编码器模型。

这种架构上的修改要求开发者对Transformer的内部工作原理有深入的理解,并能够熟练地进行模型代码的编写和调试。此外,训练CEPE模型也需要一个两阶段的流程,包括预热和标准训练,这增加了训练过程的复杂性。尽管原始论文和开源代码提供了详细的实现指南,但对于没有深厚模型开发经验的团队来说,从零开始复现或将其应用于新的基础模型仍然是一个不小的挑战。

对模型性能的影响:在检索增强任务上表现优异

在模型性能方面,CEPE展现出了令人瞩目的优势,尤其是在处理长文本和检索增强任务上。

实验结果表明,仅在8K token长度的数据上进行训练的CEPE-LLaMA-2模型,能够有效地将上下文窗口扩展到128K token,并且在长文本语言建模的困惑度指标上,持续优于或与那些经过全量微调的长上下文模型(如LLaMA-2-32K和YARN-64K)相当。

更重要的是,CEPE在检索增强的应用场景中表现尤为突出。当模型需要利用大量检索到的文档来回答问题或生成文本时,CEPE能够有效地整合这些信息,而现有的许多长上下文模型在面对大量检索结果时性能会急剧下降 。此外,CEPE还能有效利用更多的示例来提升上下文学习)的能力,这进一步证明了其处理和理解长上下文的强大能力。

6.3.3 计算资源消耗:中等,编码器较小,计算效率高

在计算资源消耗方面,CEPE实现了高效的平衡。虽然它引入了一个额外的编码器,但这个编码器相对较小,其计算开销远低于使用庞大的解码器来处理整个长序列。

CEPE通过并行编码和分块处理,将计算复杂度从二次方降低到了近似线性的水平 。在内存消耗方面,CEPE的优势更为明显。由于它只需要缓存编码器的最终输出和解码器中主输入的键值对,而不是缓存整个长序列在每个解码器层的键值对,其内存占用显著降低。

具体来说,对于一个额外的token,CEPE所需的内存仅为在解码器中直接编码所需内存的1/256 。这种高效的资源利用使得CEPE在训练和推理时都能提供更高的吞吐量,例如,其吞吐量可以达到传统方法的10倍 。

6.3.4 部署成本:中等,需部署编码器和解码器两个模型

从实际应用部署的角度来看,CEPE的成本属于中等水平。与那些只需要部署单个模型的方法相比,CEPE需要同时部署编码器和解码器两个模型。这意味着需要维护两个模型的服务,并处理它们之间的通信和协同工作。这增加了系统架构的复杂性,并可能需要更多的服务器资源。

然而,由于编码器模型较小,其部署和维护的成本相对可控。相比于需要构建和维护复杂外部向量数据库的检索增强生成(RAG)系统,CEPE的部署流程相对更为直接,因为它将长上下文处理的核心逻辑都集成在了模型内部。

因此,虽然部署成本高于单模型方案,但考虑到其在性能和效率上的巨大优势,这种额外的部署复杂性在许多应用场景中是可以接受的。

通俗案例:两个厨师合作

我用一个“两个厨师合作做菜”的生动比喻来解释其核心原理。

主厨(解码器):负责烹饪,但视野有限

想象一下,有一位非常厉害的主厨(他就是我们的“解码器”模型),他厨艺高超,能够根据客人的要求做出各种美味的菜肴。但是,这位主厨有一个小小的限制:他的工作台(也就是他的“上下文窗口”)一次只能放下有限的食材和配料。

如果客人点了一道需要很多种食材的复杂菜肴,比如一道汇集了世界各地风味的“环球沙拉”,主厨的工作台就放不下所有的食材了。他只能看到和处理一部分,这可能会影响最终菜肴的丰富性和口感。

这就像GPT模型在处理非常长的文本时,由于上下文窗口的限制,无法看到全部信息,从而影响其理解和生成内容的质量。

6.4.2 助手(编码器):负责处理额外的食材

为了解决这个问题,主厨找来了一位聪明的助手(这就是我们的“编码器”模型)。这位助手虽然厨艺不如主厨,但他非常擅长处理食材。当需要用到大量额外的食材时,比如那些来自世界各地的特色蔬菜、水果和酱料,助手就会接手这些食材。

他会把这些食材提前进行清洗、切块、分类,并装进一个个小盘子里(这个过程就是“并行编码”和“分块处理”)。助手的工作台可以容纳很多这样的小盘子,而且他处理食材的速度非常快。这样,主厨就不需要亲自处理这些繁杂的准备工作,可以专注于核心的烹饪任务。

6.4.3 传菜员(交叉注意力):将处理好的食材传递给主厨

现在,主厨和助手之间还需要一个沟通的桥梁,那就是“传菜员”(这代表了“交叉注意力”机制)。当主厨在烹饪过程中需要某种特定的食材时,比如需要一点“秘制的芒果酱”,他只需要告诉传菜员。

传菜员就会立刻跑到助手那边,从那些已经处理好的小盘子里,准确地找到芒果酱,并迅速地递给主厨。主厨拿到酱料后,就可以将其完美地融入到菜肴中。

通过这种方式,主厨虽然自己的工作台有限,但他可以随时通过传菜员,获取到助手那边准备好的、几乎无限种类的食材。这使得他能够突破工作台的限制,做出一道真正汇集了世界各地风味的、无比丰富的“环球沙拉”。

这就是CEPE方法的核心思想:通过主厨(解码器)和助手(编码器)的协同作战,以及传菜员(交叉注意力)的高效沟通,共同完成了一个原本无法完成的任务。

方法六:提示压缩——

让输入变得更“精简”

在所有扩展上下文长度的方法中,提示压缩提供了一种独特的“逆向”思路。它并非直接增加模型的上下文窗口,而是通过技术手段,将冗长的输入提示在送入模型之前进行“压缩”,使其变得更短、更精炼,从而在有限的上下文窗口内容纳更多的有效信息。

这种方法的核心在于,许多长文本中包含大量冗余信息,如重复的表述、无关的细节等。通过压缩,可以剔除这些冗余,保留核心语义,让模型更高效地理解和处理。

提示压缩的算法原理

提示压缩的算法原理主要围绕如何识别并去除文本中的冗余信息,同时最大限度地保留对任务至关重要的内容。这通常涉及到对文本进行语义层面的分析和重构。

核心思想:压缩冗长的提示信息

提示压缩的核心思想是,对于一个给定的长提示,找到一个更短的、能够表达相同或相似语义的版本。这个压缩过程可以看作是一种有损压缩,其目标是在压缩率和信息保真度之间找到最佳平衡点。

例如,一段包含多个例子和详细背景说明的提示,可以被压缩成几个关键词或一个简短的摘要,而模型仍然能够理解其意图并给出正确的回答。

7.1.2 软提示与硬提示

根据压缩结果的形式,提示压缩可以分为软提示和硬提示两种。

  • 软提示(Soft Prompt):软提示是指将压缩后的信息表示为模型嵌入空间中的一个连续向量。这个向量不是由真实的词汇组成,而是通过训练学习得到,能够引导模型生成期望的输出。软提示的优点是灵活性高,可以捕捉到比离散词汇更丰富的语义信息,但它通常需要针对特定任务进行训练,且不具备人类可读性。

  • 硬提示(Hard Prompt):硬提示是指将压缩后的信息表示为真实的、离散的词汇序列。例如,将一段长文本压缩成一个简短的摘要或几个关键词。硬提示的优点是直观、易于理解,可以直接用于任何支持文本输入的模型,无需修改模型架构。但其压缩率可能受限于自然语言的表达能力。

基于信息瓶颈的压缩方法

一种先进的提示压缩方法是基于信息瓶颈原理。该方法训练一个压缩模型(通常是一个小型的Transformer),使其学习如何从长提示中提取出最核心的信息,并将其编码成一个紧凑的向量表示(软提示)。这个压缩模型通过一个特殊的损失函数进行训练,该损失函数鼓励压缩后的表示既能保留原始提示的关键信息,又能尽可能地简洁。在推理时,这个压缩模型先将长提示压缩成一个短向量,然后将这个向量作为前缀输入到主模型中。

实现方案与开源框架

实现提示压缩通常需要训练一个专门的压缩模型,或者利用一些启发式规则来手动压缩提示。

训练压缩模型或提示

训练一个提示压缩模型需要大量的(长提示,短提示)配对数据。这些数据可以通过人工标注,或者利用大型语言模型自动生成。例如,可以让GPT-5.2为一个长提示生成多个不同长度的摘要,然后用这些数据来训练一个更小的、更高效的压缩模型。训练完成后,这个压缩模型就可以作为一个独立的工具,用于压缩任何输入提示。

相关开源工具

目前,关于提示压缩的开源工具相对较少,但一些研究项目已经开始提供相关的实现。例如,一些研究论文会开源其压缩模型的代码和预训练权重。此外,一些提示工程的工具库也可能包含一些简单的提示压缩功能,如关键词提取、文本摘要等。

优缺点评估

提示压缩是一种轻量级且灵活的上下文扩展方法,但其在性能和适用性方面也存在一些限制。

评估维度

优点

缺点

技术实现难度

中等。训练压缩模型需要一定的技术,但可以使用现成的摘要或关键词提取工具作为替代。

设计高效的压缩算法和训练数据需要深入的研究。

对模型性能的影响

在压缩率较高时,可能会丢失一些细节信息,影响模型在需要精确理解的任务上的表现。

对于需要理解全文细节的任务,压缩可能会导致性能下降。

计算资源消耗

较低。压缩过程通常很快,且只需在输入模型前执行一次。

训练压缩模型需要一定的计算资源,但推理成本很低。

部署成本

低。压缩后的提示可以直接用于任何标准模型,无需修改模型或部署额外系统。

如果需要部署一个专门的压缩模型服务,则会增加一些部署成本。

通俗案例:写摘要

读完整本书:耗时耗力

想象你需要向一位朋友推荐一本非常厚的书。如果你让他把整本书都读完,那会花费他大量的时间和精力。这就像将一个非常长的提示直接输入给模型,会消耗大量的计算资源和时间。

读摘要:快速了解核心内容

一个更聪明的方法是,你先为这本书写一个简短的摘要,概括了主要情节和核心观点。然后,你把这个摘要给你的朋友看。他只需要花几分钟读完摘要,就能对这本书有一个全面的了解,并决定是否要深入阅读。

这就是提示压缩的核心思想:通过提供一个精简的“摘要”,让模型能够快速、高效地掌握核心信息,从而在有限的“阅读时间”(上下文窗口)内完成更多的任务。

其他扩展上下文的方法

去年,Technology Innovation Institute发表了一篇论文综述The What, Why, and How of Context Length Extension Techniques in Large Language Models – A Detailed Survey,调研了扩展大模型上下文长度的相关技术。

论文链接:https://arxiv.org/pdf/2401.07872.pdf

总体大概分为以下几类方法:

未来发展趋势

未来的研究趋势之一是将多种扩展方法结合起来,形成更强大的综合解决方案。例如,可以将改进位置编码稀疏注意力相结合,让模型在拥有更广阔“视野”的同时,也能高效地处理信息。

或者,将RAG提示压缩结合,先用RAG检索相关文档,再对检索到的文档进行压缩,然后输入给模型,从而在有限的上下文窗口内实现更精准、更高效的问答。

尽管稀疏注意力已经取得了很大进展,但研究人员仍在探索更高效的注意力机制。例如,线性注意力(Linear Attention)试图通过数学上的近似,将注意力的复杂度降低到严格的线性级别。此外,一些研究也在探索基于内容的动态稀疏注意力,即让模型自己学习应该关注哪些位置,而不是依赖于固定的稀疏模式。

最终,研究社区的终极目标是实现真正意义上的“无限”上下文长度。这可能需要从根本上重新思考Transformer架构,或者探索全新的模型架构。

例如,一些研究开始关注循环神经网络(RNN)的变体,如Mamba等状态空间模型,它们在理论上可以处理无限长的序列,且计算复杂度为线性。虽然这些新架构在性能上尚未完全超越Transformer,但它们为解决上下文长度问题提供了全新的思路。未来,我们可能会看到更多融合了不同架构优点的混合模型,它们将共同推动大语言模型向着更全面、更智能的方向发展。

参考资料:

1、https://www.ijcai.org/proceedings/2024/0917.pdf

2、https://aclanthology.org/2024.acl-long.142/

3、https://collaborate.princeton.edu/en/publications/long-context-language-modeling-with-parallel-context-encoding/

4、https://tech.dewu.com/article?id=104

5、https://juejin.cn/post/7390192422715899942

6、https://github.com/microsoft/LongRoPE

7、https://blog.csdn.net/weixin_49892805/article/details/145165221

8、如何扩展大模型的上下文长度|得物技术

9、https://arxiv.org/abs/2307.09288

10、https://arxiv.org/pdf/1706.03762.pdf

12、https://github.com/huggingface/transformers/blob/main/src/transformers/models/llama/modeling_llama.py

1https://arxiv.org/abs/2104.09864

14、https://arxiv.org/abs/2306.15595

15、https://github.com/jquesnelle/yarn)

16、Qwen2.5更新百万超长上下文,推理速度4.3倍加速,网友:RAG要过时了

17、https://arxiv.org/pdf/2401.07872

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询