（论文速读）Funnel-Transformer: 过滤掉顺序冗余的高效语言处理

论文题目Funnel-Transformer: Filtering out Sequential Redundancy for Efficient Language Processing过滤掉顺序冗余的高效语言处理会议NeurIPS 2020摘要随着语言预训练的成功人们迫切希望开发出更高效、具有良好可扩展性的体系结构以更低的成本利用大量的未标记数据。为了提高效率我们研究了在维护全长令牌级表示时经常被忽视的冗余特别是对于只需要序列的单向量表示的任务。基于这种直觉我们提出了Funnel-Transformer它将隐藏状态序列逐渐压缩为更短的序列从而降低了计算成本。更重要的是通过将从长度减少中节省的FLOPs重新投资于构建更深或更宽的模型我们进一步提高了模型的容量。此外为了按照通用预训练目标的要求执行令牌级预测漏斗转换器能够通过解码器从减少的隐藏序列中恢复每个令牌的深度表示。从经验上看在具有相当或更少的FLOPs的情况下Funnel-Transformer在各种序列级预测任务(包括文本分类、语言理解和阅读理解)上优于标准Transformer。代码和预训练模型https://github.com/laiguokun/Funnel-TransformerFunnel-Transformer详解——通过序列压缩实现高效语言处理引言在NLP领域Transformer模型通过大规模预训练取得了巨大成功。然而预训练和微调这些模型的计算成本极其高昂这极大地限制了它们的应用范围。今天要介绍的这篇论文提出了Funnel-TransformerF-TFM一种通过逐层压缩序列长度来提高效率的创新架构。一、为什么需要Funnel-Transformer1.1 标准Transformer的冗余问题标准Transformer有一个被忽视的特点它在所有层都维持完整长度的token-level表示。让我们思考一个问题对于文本分类任务我们最终只需要一个向量来表示整个句子为什么要在每一层都维持512个token的完整表示呢论文指出这就像在图像识别中我们不会在网络的每一层都保持原始图像的分辨率。CNN通过逐层降低空间分辨率来提取更高级的特征。同样的思路也应该适用于序列处理。1.2 计算复杂度分析对于一个处理长度为T、隐藏维度为D的序列的Transformer层其复杂度为Self-Attention: O(T²D)Feed-Forward: O(TD²)当序列长度减半时计算复杂度会超线性下降因为T²项。这意味着用1个全长layer的FLOPs可以换来第m个block中的2^(m-1)个压缩层例如B6-6-618层的FLOPs仅相当于6 6/2 6/4 10.5个全长层二、Funnel-Transformer的核心设计2.1 整体架构Funnel-Transformer由两部分组成编码器Encoder逐渐压缩序列长度由多个block组成如B6-6-6有3个block每个6层Block之间通过pooling将序列长度减半形成一个漏斗形状因此得名解码器Decoder恢复token-level表示仅在需要时使用通过up-sampling恢复全长序列与低层特征建立skip connection用于预训练或序列标注等token-level任务2.2 关键创新Pool-Query-Only设计这是论文最重要的技术创新之一。标准做法对隐藏状态h进行pooling得到h然后在attention中使用S-Attn(Qh, KVh) # 简单但压缩能力有限Funnel-Transformer的做法S-Attn(Qh, KVh) # 只有query被poolkey和value保持未压缩为什么这样更好压缩不仅由pooling操作决定还由attention的加权求和决定Attention相当于一个线性压缩层将T个基向量组合成T个压缩基计算开销最小但表达能力大大增强具体实现使用stride2, window2的mean pooling每次将序列长度减半。2.3 解码器设计对于需要token-level预测的任务如MLM预训练解码器的工作流程Up-sampling将编码器输出h^M直接重复2^(M-1)次h^up_i h^M_{i//2^(M-1)}Skip Connection与第一个block的输出h^1相加g h^1 h^up深度融合再堆叠2层Transformer进行特征融合这个设计的优点简单高效单次大倍率up-sampling而非多次小倍率保留了低层的细粒度信息便于优化残差连接2.4 实现细节分离[cls] token预训练中通常用[cls]的hidden state表示整个序列Pooling时单独处理[cls]不参与pooling操作避免破坏这个特殊结构相对位置编码使用Transformer-XL的relative positional attention论文发现这对F-TFM至关重要见消融实验因为pooling可能破坏绝对位置信息三、实验结果详解3.1 Base规模对比与标准Transformer公平比较论文在相同数据集Wikipedia BookCorpus上预训练100万步batch size 256。GLUE Benchmark结果的关键观察B6-6-6用更少FLOPs达到更好性能平均提升0.9分FLOPs减少12%B6-3x2-3x2通过参数共享保持了相同参数量性能与baseline相当在大多数任务上都有提升尤其是RTE2.9文本分类结果错误率越低越好模型IMDBYelp-2Yelp-5Amazon-5L12H7685.3282.01329.3533.14B6-6-64.9081.93929.0332.91在所有文本分类任务上都有明显提升使用ELECTRA目标的结果趋势类似证明了方法的通用性。3.2 Large规模结果与SOTA对比在更大规模上5个数据集batch size 819250万步F-TFM的优势更加明显。Dev Set单模型结果模型CoLASST-2MNLIQNLIRTE平均ELECTRA-Large69.196.990.995.088.089.5B10-10-10H102472.496.891.195.189.590.0RoBERTa-Base63.694.887.692.878.786.4B6-6-6H76870.196.389.793.783.488.3惊人的发现B10-10-10超越ELECTRA-Large 0.5分B6-6-6base模型超越RoBERTa-Base 1.9分CoLA任务提升尤其显著6.5和6.5Test Set排行榜结果单任务单模型模型平均分ELECTRA-Large85.2B10-10-10H102485.4ELECTRA-Base82.7B6-6-6H76884.0F-TFM在官方排行榜上也取得了最佳结果RACE测试集性能模型TotalHighMiddleXLNet-Large85.484.088.6B10-10-1085.784.488.8MPNet-Base72.076.370.3B6-6-679.778.283.4在需要复杂推理的长文本任务上F-TFM依然表现出色B6-6-6比MPNet-Base提升了7.7分SQuAD 2.0 Dev Set模型EMF1ELECTRA-Large88.090.6B10-10-1087.690.4RoBERTa-Base80.583.7B6-6-685.187.7虽然在token-level任务上F-TFM的优势略小因为需要详细的token信息但base模型依然大幅超越baseline4.6 EM4.0 F1。3.3 实际运行速度理论FLOPs的减少能转化为实际加速吗论文在GPU和TPU上都做了测试。GPU (V100) 上的加速序列长度512模型运行时间内存占用GLUE分数L12H7681.00x14.3G84.40B6-6-60.94x12.5G85.37B4-4-40.64x9.0G83.99TPU (v2-8) 上的加速模型序列128序列256序列512L12H7681.00x1.00x1.00xB6-6-60.99x0.88x0.81xB4-4-40.69x0.62x0.55x观察序列越长加速效果越明显符合超线性复杂度减少TPU上的加速比GPU更显著序列512时B6-6-6快19%内存占用全面降低B6-6-6同时实现了加速和性能提升即使加上解码器预训练阶段依然有明显加速B10-10-10快17%。3.4 消融实验论文做了详尽的消融研究来验证各个设计的重要性。关键设计的贡献GLUE平均分ID配置Pool操作Pool-query-only分离[cls]相对AttnGLUE(1)B6-6-6 (完整)Mean✓✓✓83.5(2)去掉Pool-query-onlyMean✗✓✓82.9 (-0.6)(3)去掉分离[cls]Mean✓✗✓83.0 (-0.5)(4)去掉相对AttnMean✓✓✗81.4 (-2.1)(5)Max poolingMax✓✓✓83.4 (-0.1)(6)Attention-basedTop-Attn✓✓✓75.8 (-7.7)重要发现相对位置编码最关键-2.1分Pooling会破坏绝对位置信息Pool-query-only很重要-0.6分使压缩更具表达力Mean和Max pooling性能相近都远优于attention-based选择分离[cls]也有帮助-0.5分Block布局设计配置FLOPs参数GLUEB8-8 (2-block)1.14x0.91x83.4B6-6-6 (3-block)1.00x1.00x83.5B5-5-5-5 (4-block)0.89x1.08x82.93-block设计是最优选择在FLOPs/性能权衡上最好。四、深入理解4.1 为什么Funnel-Transformer有效消除序列冗余序列级任务不需要维持完整token信息类似CNN的分层特征提取思想符合语言学中词→短语→句子的层次结构深度换长度的策略节省的FLOPs投入到更深的网络更深的网络有更强的表达能力在压缩块中每个token都能看到更多全局信息Pool-query-only的妙用让attention参与压缩过程比固定的pooling策略更灵活最小开销获得最大收益4.2 适用场景最适合的任务✅ 文本分类✅ 句子对匹配NLI✅ 阅读理解选择题形式✅ 语义相似度次优但仍可用⚠️ 抽取式问答SQuAD⚠️ 序列标注不太适合❌ 生成任务需要详细token信息4.3 与其他方法的对比方法核心思想优势劣势Funnel-TFM压缩序列长度直接减少计算可训练性强Token-level任务稍弱Sparse Attention稀疏化attention保持全长表示实现复杂硬件不友好Knowledge Distillation蒸馏到小模型模型小需要大模型teacherPruning/Quantization压缩权重推理快训练阶段无益Funnel-Transformer的独特优势在于训练和推理都高效且无需依赖其他大模型。五、实现建议如果你想使用Funnel-Transformer这里有一些实践建议5.1 模型配置选择对于序列级任务Base规模推荐B6-6-6H768性能最佳Large规模推荐B10-10-10H1024如果内存受限使用B6-3x2-3x2H768参数共享版本如果需要极致速度使用B4-4-4H768对于token-level任务使用带decoder的版本可能需要调整decoder层数默认2层5.2 超参数论文提供的关键超参数Pooling: Stride2, Window2的mean poolingDecoder layers: 2层Position encoding: Transformer-XL的relative attention必须[cls] token: 要单独处理5.3 训练技巧预训练可以使用MLM或ELECTRA目标ELECTRA通常效果稍好超大模型(24层)可能需要降低学习率避免不稳定微调序列级任务直接去掉decoder学习率搜索范围{1e-5, 2e-5, 3e-5}使用layer-wise learning rate decay如0.75六、总结与展望主要贡献识别了被忽视的冗余全长序列表示在序列级任务中存在冗余提出了高效架构通过压缩序列长度并再投资节省的FLOPs验证了有效性在多个benchmark上取得SOTA或接近SOTA的结果实现了真正的加速不仅是理论FLOPs实际运行时间也明显减少适用性分析优势场景序列分类、匹配、排序等任务资源受限的环境需要处理大量数据的应用长序列处理压缩效果更明显局限性Token-level任务性能略有下降需要相对位置编码对已有模型的迁移有要求Block布局设计仍需探索未来方向论文提出了几个值得探索的方向更好的压缩方案动态决定压缩率任务自适应的pooling策略可学习的压缩函数Block布局优化自动搜索最优布局任务特定的布局设计与其他技术结合知识蒸馏 Funnel-TFM量化 Funnel-TFM可能实现更大的效率提升扩展到其他领域视频理解时间维度压缩多模态模型图结构数据结语Funnel-Transformer提供了一个简单而有效的思路不是所有层都需要维持全长序列。通过借鉴CNN的分层抽象思想它成功地在保持甚至提升性能的同时显著降低了计算成本。这篇论文的启发意义在于在追求更大模型的同时我们也应该思考如何更聪明地使用计算资源。有时候架构层面的创新比单纯堆砌参数更有价值。对于实践者来说Funnel-Transformer提供了一个即插即用的高效替代方案。无论是在学术研究还是工业应用中它都值得一试特别是在处理序列级任务和长序列场景时。希望这篇详细的介绍能帮助你理解Funnel-Transformer的设计思想和实现细节。如果你在实践中有任何问题欢迎交流讨论