LongLoRA技能的中心就在于将长文本划分红不同的组，在每个组里进行核算

但与之带来的价值是，自注意力机制的核算量会随着上下文长度的添加呈平方级增长，比如上下文添加32倍时，核算量实际会增长1000倍。

一些宣布的论文给予了佐证：过长的上下文会使得相关信息的占比明显下降，加剧注意力涣散好像成为了不可避免的命运。

这就构成了“不可能三角”中的第一组对立——文本长短与注意力，也从根本上解释了大模型长文本技能难以突破的原因。

从“卷”大模型参数到现在，算力一向都是稀缺的资源。OpenAI创始人Altman曾表示，ChatGPT-4 32K的服务无法立马彻底向一切用户开放，最大的约束就在于GPU缺少。

对此，杨植麟也称：“GPU是一个重要的根底，但还不光是GPU的问题。这里面是不同因素的结合，一方面是GPU，一方面是动力转换成智能的功率。功率进一步拆解可能包含算法的优化、工程的优化、模态的优化以及上下文的优化等等”。

更为重要的是，在大模型实际部署环节，企业端根本无法提供很大的算力支撑，这也就倒逼厂商不管是扩大模型参数仍是文本长度，都要紧守算力一关。但现阶段要想突破更长的文本技能，就不得不耗费更多的算力，于是就形成了文本长短与算力之间的第二组对立。

腾讯NLP工程师杨雨（化名）表示：“大模型长文本建模现在还没有一个一致的解决计划，形成困扰的原因正是源于Transformer自身的结构，而全新的架构已经在路上了”。

当时不管从软件仍是硬件设计，大部分都是环绕Transformer架构来打造，短时间内新架构很难彻底颠覆，但环绕Transformer架构产生了几种优化计划。

杨雨对光锥智能说：“现在首要有三种不同的解决计划，分别为借助模型外部工具辅助处理长文本，优化自注意力机制核算和使用模型优化的一般办法”。

三种不同的解决计划:

1. 第一种解决计划的中心思路便是给大模型开“外挂”

首要办法是将长文本切分为多个短文本处理，模型在处理长文本时，会在数据库中对短文本进行检索，以此来获得多个短文本答复构成的长文本。每次只加载所需求的短文本片段，然后避开了模型无法一次读入整个长文本的问题。

2. 解决计划是现在使用最多的办法，首要中心在于从头构建自注意力核算方法

比如LongLoRA技能的中心就在于将长文本划分红不同的组，在每个组里进行核算，而不用核算每个词之间的关系，以此来下降核算量，进步速度。

前两种形式也被杨植麟称之为“蜜蜂”模型，即经过对检索增强的生成或上下文的降采样，保留对部分输入的注意力机制，来实现长文本处理的作用。

据杨植麟介绍，在优化自注意力机制核算还存在一种方法，也被其称之为 “金鱼”模型。即经过滑动窗口等方法主动扔掉上文，以此来专注对用户最新输入信息的答复。这样做的优点显而易见，可是却无法跨文档、跨对话比较和总结剖析。

3. 解决计划是专注于对模型的优化

如LongLLaMA以OpenLLaMA-3B和OpenLLaMA-7B 模型为起点，在其根底上进行微调，产生了LONGLLAMAs新模型。该模型很简单外推到更长的序列，例如在8K token上练习的模型，可以很简单外推到256K窗口巨细。

对模型的优化还有一种较为遍及的方法，便是经过经过减少参数量（例如减少到百亿参数）来提升上下文长度，这被杨植麟称之为 “蝌蚪”模型。这种办法会下降模型自身的能力，虽然能支撑更长上下文，可是任务难度变大后就会出现问题。

长文本的“不可能三角”困境或许暂时还无解，但这也清晰了大模型厂商在长文本的探索途径：在文本长短、注意力和算力三者之中做取舍，找到最佳的平衡点，既能够处理满足的信息，又能兼顾注意力核算与算力本钱约束。