科学空间|Scientific Spaces

在文章《生成扩散模型漫谈（六）：一般框架之ODE篇》中，我们推导了SDE的Fokker-Planck方程；而在《生成扩散模型漫谈（十二）：“硬刚”扩散ODE》中，我们单独推导了ODE的连续性方程。它们都是描述随机变量沿着SDE/ODE演化的分布变化方程，连续性方程是Fokker-Planck方程的特例。在推导Fokker-Planck方程时，我们将泰勒展开硬套到了狄拉克函数上，虽然结果是对的，但未免有点不伦不类；在推导连续性方程时，我们结合了雅可比行列式和泰勒展开，方法本身比较常规，但没法用来推广到Fokker-Planck方程。

这篇文章我们介绍“测试函数法”，它是推导连续性方程和Fokker-Planck方程的标准方法之一，其分析过程比较正规，并且适用场景也比较广。

点击阅读全文...

昨天在Arixv上发现了Google新发的一篇论文《Symbolic Discovery of Optimization Algorithms》，主要是讲自动搜索优化器的，咋看上去没啥意思，因为类似的工作也有不少，大多数结果都索然无味。然而，细读之下才发现别有洞天，原来作者们通过数千TPU小时的算力搜索并结合人工干预，得到了一个速度更快、显存更省的优化器Lion（EvoLved Sign Momentum，不得不吐槽这名字起得真勉强），并在图像分类、图文匹配、扩散模型、语言模型预训练和微调等诸多任务上做了充分的实验，多数任务都显示Lion比目前主流的AdamW等优化器有着更好的效果。

更省显存还更好效果，真可谓是鱼与熊掌都兼得了，什么样的优化器能有这么强悍的性能？本文一起来欣赏一下论文的成果。

先说结果

本文主要关心搜索出来的优化器本身，所以关于搜索过程的细节就不讨论了，对此有兴趣读者自行看原论文就好。Lion优化器的更新过程为
\begin{equation}\text{Lion}:=\left\{\begin{aligned}
&\boldsymbol{u}_t = \text{sign}\big(\beta_1 \boldsymbol{m}_{t-1} + \left(1 - \beta_1\right) \boldsymbol{g}_t\big) \\
&\boldsymbol{\theta}_t = \boldsymbol{\theta}_{t-1} - \eta_t (\boldsymbol{u}_t \color{skyblue}{ + \lambda_t \boldsymbol{\theta}_{t-1}}) \\
&\boldsymbol{m}_t = \beta_2 \boldsymbol{m}_{t-1} + \left(1 - \beta_2\right) \boldsymbol{g}_t
\end{aligned}\right.\end{equation}

点击阅读全文...

上周在《NBCE：使用朴素贝叶斯扩展LLM的Context处理长度》中，我们介绍了一种基于朴素贝叶斯来扩展LLM的Context长度的方案NBCE（Naive Bayes-based Context Extension）。由于它有着即插即用、模型无关、不用微调等优点，也获得了一些读者的认可，总的来说目前大家反馈的测试效果还算可以。

当然，部分读者在使用的时候也提出了一些问题。本文就结合读者的疑问和笔者的后续思考，对NBCE方法做一些补充说明和分析。

方法回顾

假设$T$为要生成的token序列，$S_1,S_2,\cdots,S_n$是给定的若干个Context，我们需要根据$S_1,S_2,\cdots,S_n$生成$T$，那么就需要估计$p(T|S_1, S_2,\cdots,S_n)$。根据朴素贝叶斯思想，我们得到
\begin{equation}\log p(T|S_1, S_2,\cdots,S_n) = \color{red}{(\beta + 1)\overline{\log p(T|S)}} - \color{green}{\beta\log p(T)} + \color{skyblue}{\text{常数}}\label{eq:nbce-2}\end{equation}

点击阅读全文...

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的一般概念来看是没资格回答这个问题的，下面的内容只是笔者根据一些研究经验，从偏理论的角度强行回答一波。文章多数推论以自己的实验结果为引，某些地方可能会跟某些文献的结果冲突，请读者自行取舍。

点击阅读全文...

在LLM时代还玩朴素贝叶斯（Naive Bayes）？

这可能是许多读者在看到标题后的首个想法。确实如此，当古老的朴素贝叶斯与前沿的LLM相遇时，产生了令人惊讶的效果——我们可以直接扩展现有LLM模型的Context处理长度，无需对模型进行微调，也不依赖于模型架构，具有线性效率，而且效果看起来还不错——这就是本文所提出的NBCE（Naive Bayes-based Context Extension）方法。

摸石过河

假设$T$为要生成的token序列，$S_1,S_2,\cdots,S_n$是给定的若干个相对独立的Context集合（比如$n$个不同的段落，至少不是一个句子被分割为两个片段那种），假设它们的总长度已经超过了训练长度，而单个$S_k$加$T$还在训练长度内。我们需要根据$S_1,S_2,\cdots,S_n$生成$T$，即估计$p(T|S_1, S_2,\cdots,S_n)$。

点击阅读全文...

自从在《Transformer升级之路：11、将β进制位置进行到底》中引入混合进制的思路进一步推广了NTK-aware Scaled RoPE后，笔者感觉类似思路的效果已经达到了上限，想要更大幅度的提升就必须另辟蹊径了。这时候笔者想起了此前构思过的一个思路，该思路由于复杂度较高所以被搁置下了，既然现在已经遇到了瓶颈，那么“唯一的办法就是最好的办法”，于是便将它重拾起来。

万万没想到的是，尽管该方法增加了一些推理复杂度，但它的实验效果却惊人地好——甚至隐约有无限的长度外推能力！因此，笔者迫不及待地撰写了本文来分享该方法。由于形式上跟ReLU激活函数的相似性，所以笔者将该方法命名为“ReRoPE (Rectified Rotary Position Embeddings)”。

重温

我们知道，RoPE形式上是一种绝对位置编码，但实际上给Attention带来的是相对位置信息，即如下的Toeplitz矩阵：

点击阅读全文...

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

回顾

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

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

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

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

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

点击阅读全文...

当前，像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能否再次辉煌？

点击阅读全文...