科学空间|Scientific Spaces

随着ChatGPT及其平替的火热，各种参数高效（Parameter-Efficient）的微调方法也“水涨船高”，其中最流行的方案之一就是本文的主角LoRA了，它出自论文《LoRA: Low-Rank Adaptation of Large Language Models》。LoRA方法上比较简单直接，而且也有不少现成实现，不管是理解还是使用都很容易上手，所以本身也没太多值得细写的地方了。

然而，直接实现LoRA需要修改网络结构，这略微麻烦了些，同时LoRA给笔者的感觉是很像之前的优化器AdaFactor，所以笔者的问题是：能否从优化器角度来分析和实现LoRA呢？本文就围绕此主题展开讨论。

方法简介

以往的一些结果（比如《Exploring Universal Intrinsic Task Subspace via Prompt Tuning》）显示，尽管预训练模型的参数量很大，但每个下游任务对应的本征维度（Intrinsic Dimension）并不大，换句话说，理论上我们可以微调非常小的参数量，就能在下游任务取得不错的效果。

LoRA借鉴了上述结果，提出对于预训练的参数矩阵$W_0\in\mathbb{R}^{m\times n}$，我们不去直接微调$W_0$，而是对增量做低秩分解假设：
\begin{equation}W = W_0 + U V,\qquad U\in\mathbb{R}^{m\times r},V\in\mathbb{R}^{r\times n}\end{equation}
其中$U,V$之一用全零初始化，$W_0$固定不变，优化器只优化$U,V$。由于本征维度很小的结论，所以$r$我们可以取得很小，很多时候我们甚至可以直接取$1$。所以说，LoRA是一种参数高效的微调方法，至少被优化的参数量大大降低了。

点击阅读全文...

在《从熵不变性看Attention的Scale操作》、《熵不变性Softmax的一个快速推导》中笔者提出了熵不变性Softmax，简单来说就是往Softmax之前的Attention矩阵多乘上一个$\log n$，理论上有助于增强长度外推性，其中$n$是序列长度。$\log n$这个因子让笔者联系到了JL引理（Johnson-Lindenstrauss引理），因为JL引理告诉我们编码$n$个向量只需要$\mathscr{O}(\log n)$的维度就行了，大家都是$\log n$，这两者有没有什么关联呢？

熵不变性

我们知道，熵是不确定性的度量，用在注意力机制中，我们将它作为“集中注意力的程度”。所谓熵不变性，指的是不管序列长度$n$是多少，我们都要将注意力集中在关键的几个token上，而不要太过分散。为此，我们提出的熵不变性Attention形式为
\begin{equation}Attention(Q,K,V) = softmax\left(\frac{\log_{512} n}{\sqrt{d}}QK^{\top}\right)V\label{eq:core}\end{equation}

点击阅读全文...

【注：后来经过反复测试发现，发现此篇文章的长度外推结果可复现性比较不稳定（可能跟模型结构、超参数等紧密相关），请自行斟酌使用。】

万万没想到，Bias项能跟Transformer的长度外推性联系在一起！

长度外推性是我们希望Transformer具有的一个理想性质，笔者曾在《Transformer升级之路：7、长度外推性与局部注意力》、《Transformer升级之路：8、长度外推性与位置鲁棒性》系统地介绍过这一问题。至于Bias项（偏置项），目前的主流观点是当模型足够大时，Bias项不会有什么特别的作用，所以很多模型选择去掉Bias项，其中代表是Google的T5和PaLM，我们后面做的RoFormerV2和GAU-α也沿用了这个做法。

那么，这两个看上去“风牛马不相及”的东西，究竟是怎么联系起来的呢？Bias项真的可以增强Transformer的长度外推性？且听笔者慢慢道来。

点击阅读全文...

当前，像ChatGPT之类的LLM可谓是“风靡全球”。有读者留意到，几乎所有LLM都还是用最初的Multi-Head Scaled-Dot Attention，近年来大量的Efficient工作如线性Attention、FLASH等均未被采用。是它们版本效果太差，还是根本没有必要考虑效率？其实答案笔者在《线性Transformer应该不是你要等的那个模型》已经分析过了，只有序列长度明显超过hidden size时，标准Attention才呈现出二次复杂度，在此之前它还是接近线性的，它的速度比很多Efficient改进都快，而像GPT3用到了上万的hidden size，这意味着只要你的LLM不是面向数万长度的文本生成，那么用Efficient改进是没有必要的，很多时候速度没提上去，效果还降低了。

那么，真有数万甚至数十万长度的序列处理需求时，我们又该用什么模型呢？近日，Google的一篇论文《Resurrecting Recurrent Neural Networks for Long Sequences》重新优化了RNN模型，特别指出了RNN在处理超长序列场景下的优势。那么，RNN能否再次辉煌？

点击阅读全文...

上周笔者写了《为什么现在的LLM都是Decoder-only的架构？》，总结了一下我在这个问题上的一些实验结论和猜测。果然是热点问题流量大，paperweekly的转发没多久阅读量就破万了，知乎上点赞数也不少。在几个平台上，陆陆续续收到了读者的一些意见或者疑问，总结了其中一些有代表性的问题，做成了本篇FAQ，希望能进一步帮助大家解决疑惑。

回顾

在《为什么现在的LLM都是Decoder-only的架构？》中，笔者对GPT和UniLM两种架构做了对比实验，然后结合以往的研究经历，猜测了如下结论：

1、输入部分的注意力改为双向不会带来收益，Encoder-Decoder架构的优势很可能只是源于参数翻倍；

2、双向注意力没有带来收益，可能是因为双向注意力的低秩问题导致效果下降。

所以，基于这两点推测，我们得到结论：

在同等参数量、同等推理成本下，Decoder-only架构是最优选择。

点击阅读全文...

LLM是“Large Language Model”的简写，目前一般指百亿参数以上的语言模型，主要面向文本生成任务。跟小尺度模型（10亿或以内量级）的“百花齐放”不同，目前LLM的一个现状是Decoder-only架构的研究居多，像OpenAI一直坚持Decoder-only的GPT系列就不说了，即便是Google这样的并非全部押注在Decoder-only的公司，也确实投入了不少的精力去研究Decoder-only的模型，如PaLM就是其中之一。那么，为什么Decoder-only架构会成为LLM的主流选择呢？

知乎上也有同款问题《为什么现在的LLM都是Decoder only的架构？》，上面的回答大多数聚焦于Decoder-only在训练效率和工程实现上的优势，那么它有没有理论上的优势呢？本文试图从这个角度进行简单的分析。

统一视角

需要指出的是，笔者目前训练过的模型，最大也就是10亿级别的，所以从LLM的一般概念来看是没资格回答这个问题的，下面的内容只是笔者根据一些研究经验，从偏理论的角度强行回答一波。文章多数推论以自己的实验结果为引，某些地方可能会跟某些文献的结果冲突，请读者自行取舍。

点击阅读全文...

众所周知，分类问题的常规评估指标是正确率，而标准的损失函数则是交叉熵，交叉熵有着收敛快的优点，但它并非是正确率的光滑近似，这就带来了训练和预测的不一致性问题。另一方面，当训练样本的预测概率很低时，交叉熵会给出一个非常巨大的损失（趋于$-\log 0^{+}=\infty$），这意味着交叉熵会特别关注预测概率低的样本——哪怕这个样本可能是“脏数据”。所以，交叉熵训练出来的模型往往有过度自信现象，即每个样本都给出较高的预测概率，这会带来两个副作用：一是对脏数据的过度拟合带来的效果下降，二是预测的概率值无法作为不确定性的良好指标。

围绕交叉熵的改进，学术界一直都有持续输出，目前这方面的研究仍处于“八仙过海，各显神通”的状态，没有标准答案。在这篇文章中，我们来学习一下论文《Tailoring Language Generation Models under Total Variation Distance》给出的该问题的又一种简明的候选方案。

点击阅读全文...

这段时间笔者一直在实验《Google新搜出的优化器Lion：效率与效果兼得的“训练狮”》所介绍的Lion优化器。之所以对Lion饶有兴致，是因为它跟笔者之前的关于理想优化器的一些想法不谋而合，但当时笔者没有调出好的效果，而Lion则做好了。

相比标准的Lion，笔者更感兴趣的是它在$\beta_1=\beta_2$时的特殊例子，这里称之为“Tiger”。Tiger只用到了动量来构建更新量，根据《隐藏在动量中的梯度累积：少更新几步，效果反而更好？》的结论，此时我们不新增一组参数来“无感”地实现梯度累积！这也意味着在我们有梯度累积需求时，Tiger已经达到了显存占用的最优解，这也是“Tiger”这个名字的来源（Tight-fisted Optimizer，抠门的优化器，不舍得多花一点显存）。

此外，Tiger还加入了我们的一些超参数调节经验，以及提出了一个防止模型出现NaN（尤其是混合精度训练下）的简单策略。我们的初步实验显示，Tiger的这些改动，能够更加友好地完成模型（尤其是大模型）的训练。

点击阅读全文...