关于Scaling Law、合成数据、MOE及长文本的看法及未来

作者：张俊林，新浪微博新技术研发负责人
整理：青稞A
原文：https://zhuanlan.zhihu.com/p/700622253

以下内容是5月15日甲子光年圆桌论坛讨论内容，涉及Scaling Law、合成数据与“半合成数据”、与Transformer不同的新模型结构、MOE及Long Context等问题。

一、是否相信Scaling Law？

王艺 ：围绕Scaling Law有很多的争议，有些人是坚定的信仰者，觉得只要堆数据、堆算力就能带领我们达到AGI；但是也有人认为你无限堆数据和算力并不能无限提升模型的性能，它其实会慢慢趋向于一个固定的值。那你是Scaling Law的坚定信仰者吗？

张俊林：Scaling Law其实是个经验公式，最初是OpenAI在2020年提出来的，现在大家遵循的应该是DeepMind在22年提出的Chinchilla Scaling Laws（Chinchilla Scaling Laws：为了使模型达到最佳性能，模型参数量应与训练集的大小成等比例扩张。），尽管它被称为Law，但它是通过大量的实验来得出的关于模型规模、训练数据增长和对应模型效果增长的关系公式。我觉得从现阶段来看，如果你承认DeepMind的实验是靠得住的，那么Scaling Law毫无疑问就是成立的，就是你继续提供更多高质量的数据、扩大模型参数，模型效果的确是在不断提升。

但是我觉得Scaling Law曲线的增长陡峭程度可能在放缓，我们可以用最近两天的例子来推断这个结论：前天OpenAI发布了GPT-4o，包括谷歌今天的I/O大会也发布了更强的模型。其实相比GPT-4o，我个人更期待GPT-5的出现，因为从GPT-5的能力能够评估我们目前阶段大模型的Scaling Law能达到什么状态。但是，ChatGPT发布已经一年半了，GPT-4在22年就训练好了，目前已经经过了一年半到两年时间，GPT-5还迟迟没有出来，只是发布了更偏向多模态产品形态的GPT-4o，这多少是有点不太正常的，我猜测这可能是因为GPT-5在OpenAI内部的测试结果不满意，还需要想办法进一步提升能力后才发出来。而如果这个推论成立，那么很可能意味着Scaling law增长速度在放缓。

那问题在哪里呢？我个人觉得可能还是出在数据上，可能还是数据不够用，原则上，根据Scaling Law，只要你数据量足够多，那他会沿着增长曲线继续往前走，现在Llama3已经用了14T的数据，几乎达到了现在所有能用的数据，所以很可能是数据不足导致Scaling law增长变缓慢。

归纳一下，Scaling Law在目前阶段是成立的，但是可能有放缓的趋势。

二、合成数据能解决当前的数据瓶颈吗？

王艺：我们会发现合成数据现在其实是很多厂商解决数据瓶颈问题的主要方法，包括Llama3，它也在训练数据集里加入了合成数据。你包括 Sora 模型，它的生成其实也是一个合成的思路，那就是说合成数据它是一个我们解决数据问题的方向吗？

张俊林：如果数据就是决定文本大模型未来能力天花板的最关键的因素，未来我们可能面临数据短缺问题，那么将来只有两条路能够驱动文本大模型继续往前走：

一条路像刚才罗总提到的，提高大模型对数据的学习效率，就是说喂给模型的数据量大小是一样的，但是好的模型能够从同样的数据中学到更多的知识，这是一条非常好的发展路线，这意味着我们在不扩充数据量的前提下就能继续提升模型效果，对数据量的需求就会降低，但是目前这条路上我个人并没有看到特别好的解决方案。

第二条路是，你继续喂给大模型新数据，但是你已经没有更多可利用的人产生的数据了，那就无路可走，只能依靠合成数据了。所以我觉得未来合成数据还是很重要的。

至于合成数据的可用性，我觉得目前合成数据在有些地方还是用的比较成功的。举个例子，我们做大语言模型很多时候会做instruct-tuning，会人工制造“问题-答案”的数据对去调整模型，让模型理解人的命令。去年上半年其实很多厂商就开始拿到问题之后，让GPT-4给答案，然后用这些“问题-答案”数据去训自己的模型，这其实就是典型的一种合成数据的做法，应该说在这个场景还是比较成功的。

另外一个比较成功的例子是DALLE 3和Sora的做法，我觉得它们之所以成功，跟他怎么有效制作合成数据是有一定关系的。但我觉得可以把DALLE和Sora的做法看作“半合成数据”，而不是完全自动化的合成数据，这样更贴切一些，为什么呢？因为你要训练多模态模型，DALLE 3得有文本对应的图片，Sora得有文本对应的视频，必须得是成对数据。DALLE 3和Sora做了这么个事儿——它们把已经有的、人标好的“文本-图片”或“文本-视频”数据对里的文本部分用AI模型扩写，改得更详细、更丰富一些，然后再用扩写后的“文本-图片”／“文本-视频”合成数据去训练模型。所以你看到了，它们用的合成数据其实不是靠机器完全自由生成的，而是在已有人工数据的基础上进行了进一步的改造。所以这算是一种“半合成数据”的做法。目前看这种“半合成数据”的做法是可行并能产生好的效果的。

然后我们再讲“全合成数据”，想要完全用机器、不受限制地生成所需的训练数据，确实非常难。因为人产生的数据其实是有主题和自然风格的分布的，机器还难以做到自由生成并完全符合人类数据的分布，这个难度比较高。“全合成数据”我认为是个方向，但是业界公开的资料里还没有看到很成熟的做法。

三、有没有比Transformer更好的模型架构？

王艺：除了罗总提到的RWKV、Mamba、Retentive Network，还有其他更好的模型架构吗？

张俊林：现在业界无论是提出全新模型，还是在Transformer基础上改进，要解决的根本问题其实是相同的，都是解决Transformer在推理阶段长上下文处理时的内存和时间消耗问题。

如果归纳新架构的一些做法，我认为有两个不同的方向，但可能殊途同归。一种是从RNN入手来改出新模型，另一种是从Transformer入手直接改它的缺点。RNN类新模型的好处是推理效率特别高，内存占用少、计算量低，这是它的优点；它的问题是模型训练效率低、并行度差，尤其当训练数据量变大，这个问题就会很突出。Transformer的优劣势正好和RNN相反，它在训练时候并发度高、训练效率高，它的并行架构导致数据量大的时候，训练效率比RNN类改进模型好很多，效果也比较好。而Transformer的问题在于它的self-attention机制，推理的时候每生成一个token都要遍历所有前序的token，导致模型推理的时候KV Cache消耗的内存高、计算量大，尤其当输入上下文比较长的时候，这个问题就很突出。

与从RNN入手相比，我个人更倾向第二种方案，就是基于Transformer去改造模型来提高它现有的推理效率问题。现在这方面的具体做法有很多，效果也不错，所以我们看到谷歌Gemini已经能在推理的时候支持2百万长度的上下文，而随着技术进步，这个长度应该很快能拓展到5百万、1千万甚至更长，把上下文做长目前看不是很难解决的技术问题。

总之，无论从RNN出发，还是从Transformer出发，这两种思路应该都可以，也存在相互借鉴，最终很可能会经过相互借鉴后形成融合。

怎么看待MOE模型？

王艺：四、怎么看待MOE模型？

张俊林：关于MOE。我觉得MOE（Mixture of Experts）模型在模型规模变大时是不得已或者说不得不做出的选择。Scaling Law代表的趋势是，如果想要做最好的模型，就得增加数据量和模型规模。因为当数据量和参数量增加，训练和推理成本也会增加；MOE相对Dense模型的优势是训练和推理成本非常低，所以当模型规模特别大的时候，出于成本考虑，你不得不选择MOE。我觉得MOE是一种“想得很好但是做得不够好”的一种模型，就其设计初衷来说是非常好的——有多个专家，每个专家处理某个领域的问题，“专业的人做专业的事”；但是，这是理想，在实际训练中很难保证能做到这一点，甚至可以说，目前基本还做不到这一点，目前的MOE更像是一种比较灵活的集成模型（Ensemble Model）。所以说，MOE是一种“想得很好但是做得不够好”的一种模型，当然，在成本和效率方面确实MOE有优势。

王艺：现在各家都在卷长文本，但是长文本确实很耗费显存，除了LoRA，还有没有一些新的架构，解决Transformer对硬件资源的消耗问题？

张俊林：这是一个纯技术问题，随着多模态模型的推广和普及，long context是很有必要的。比如，我希望模型能够理解一个视频，输入的context必然很长，这就面临KV cache特别大的问题。那么怎么解决这个问题呢？现在有很多解决方案，可以归纳为两种大的思路：

第一种思路是直接对KV cache下手，减小其模型的大小。比如，可以用模型量化或压缩的方法。有个工作对KV Cache做3bit量化，可以做到GPU单卡处理1百万Token长度的上下文。DeepSeek v2里引入的对KV 做类似Lora的低秩分解效果也很好，这是模型压缩的路子。很多方法还可以一起用，总之，大部分对大模型参数进行压缩的工作，原则上都可以经过改造迁移到KV Cache上来。

第二种思路是直接对输入的context进行压缩，而不是压缩模型内部的KV cache。这种方法有很多具体做法，但核心思路都差不多。现在RAG（Retrieval-Augmented Generation）是大模型应用的标配，即把很多内容放在外存数据库里，需要时根据prompt取回相关的部分，从而减少输入的长度。第二种方法在概念上可以理解为把RAG放到内存中，在内存中维护一个memory，把长的输入切成块放到memory里，相当于内存版的RAG。谷歌前一阵子推出的支持无限上下文输入的工作基本思路也是类似的，效果也不错。

总结起来，解决long context问题主要有这两种思路：一是减小KV cache的大小，二是压缩输入的context。同样的，这两种方法也可以结合。

——The  End——

分享

收藏

点赞

在看