我为什么不看好LLM——记过去一年实习经历有感
共 3876字，需浏览 8分钟
·
2024-07-25 10:00
今天分享一位好朋友过去一年在各个大厂和初创大模型公司实习的经历，现在大模型是风口，他的眼光和思考都值得我们认真体会和学习~
笔者为了寻求科研界的不同体验，试图在工业界寻求一些经验，在大三一整年做过差不多9个月的实习，分别在三家独角兽公司担任算法工程师，参与模型算法和/或一些Infra工程，从中吸取了大量的经验，平均每家公司待了差不多3个月，期间，总共经历了：
公司甲：做出了比较出名的端侧小模型，一半梭哈Agent，一半梭哈端侧模型（LLM/VLM）的新型Scaling Law曲线。
公司乙：做出了国内外都比较出名的大模型，在或许是最权威的LLM评测平台LMSys上挤进世界前十，中国模型第一。
公司丙：比前两个公司规模都大一些，剑走偏锋，眼光独到，原创论文特别多，做出了中国第一个Omni LLM。
总体而言，我感觉我眼光还是不错的，当然本身大佬也特别多，基本上聚集了来自清华NLP、MSRA、MMLab的精锐力量，因此获得了良好的体验，在此分享一下（P：细节保密），深深感觉到LLM前景可能没有想象中那么美好，在未来的某个时间节点或许会成为几家独大、应用场景相对匮乏的局面。
前提：我们如何制作一个成功的LLM产品？
通常，要制作一个大模型，一般的参考范式是OpenAI的InstructGPT（链接）
在此之后，出现了开源的Llama，基本上大多数模型的结构也都是复刻于此（或轻微/中等改动），相比于Transformer（GPT2），特点在于：
（1）Pre-Normalization （2）RMSNorm归一化函数当Normalizing Function使得模型训练过程更加稳定 （3）激活函数换成了SwiGLU （4）使用RoPE代替绝对位置编码实现外推
（有些公司发现了在千亿【100B+】规模上用Post-Normalization和使用ReLU效果更好，这里就按下不表了。）
大模型具有涌现能力，主要受到谜之Scaling Laws的规约，你可以理解为数据越多，模型越大，能力越强，出名的有Chinchilla/Hoffman scaling laws和Kaplan Scaling Laws。
暂且抛开数据和对齐不谈，那么差不多轮到开始制作产品了，成功的LLM产品一定是这样的（只讨论Base Model）：
（1）UI友好，可拖拽文件，支持不同模态，支持Function Calling，例如Kimi。
（2）成本低廉，推理友好（指TTFT、总体推理时间达到一个好的平衡），需要较强的Infra基础，这一块是MLSys的红利，例如DeepSeekv2号称可以盈利、推理开销降低到原来的5%-13%、利润50%的MLA架构。
（3）模型的Base能力足够强，例如OpenAI GPT4/Anthropic Sonnet 3.5、Opus 3.0。
（4）能开发出用户在现实世界中爽到的玩法，迈向真正的AGI，例如GPT4o。
四者如果都做的很好，差不多就是我心目中能称得上比较好的LLM，它也基本上一定会成功，所以你大概可以看出，LLM的工程大概分为：
（1）模型结构本身，偏算法。
（2）Machine Learning System，在上述基础上利用LLM结构特性、硬件特性和一些普遍观测到的性质，在相对固定的资源上实现高效训练、推理、微调，也包括类似Character AI魔改Transformer。
（3）数据 + RLHF：尽可能多，尽可能高质量，尽可能丰富，DPO/PPO/SimPO/SPPO，你可以从Lilian Weng的这篇博客（链接）和 LIMA: Less Is More for Alignment（链接）中窥知一二。
垂类模型在上述的基础上进行一定的SFT & RFT & 小模型筛选，常见的例如Code & Math两个常用场景，当然也有类似心理、教育、金融、法律等，就不再赘述了。可以参考的例子如DeepSeek -> DeepSeek Coder (Code) /DeepSeek Prover (Math)，采用的方法大多数是增强数据，提炼一些High-level Feature，积累足够的DPO数据，多做Alignment工程。
困境1：数据
当你真正入行，你就会发现数据这一块是非常缺少的，无论是数据本身质量、数据多样性还是数据配比，都可能导致loss曲线异常，你也会发现需求的数据特别多，这也导致（1）数据厂商赚麻了，类似Scale AI（2）你的同学大量成为了算法工程师（数据标注也是算法工程），每个厂基本都有自己的数据标注工具（3）合成数据大行其道，例如Llama3 15T的数据和Nvidia Nemotron-4 340B 98%的合成数据，但这真的符合High Quality的标准吗？阿里Qwen2的Report中7T左右的数据就打败了用了15T语料的Llama-3-70B。
如果你尝试做一些多模态，你会发现对齐数据非常难找，并且这是更难生成的；再难一点，对于TabularLLM，Structural Data更加难得；再难一点，两者结合，再加上CodeLLM（通过类似Matplotlib，Seaborn做中介），你会发现简直要逼疯了，而这其实就是你在OpenAI CodeInterpreter所做的事：给一个任务，表格拖进去，执行代码，生成对应的图片，但，图片真的是正确的吗？是否达到了任务？这就需要更多的RLHF数据来进行确认标注了。由此你可以发现，如果是想做成一个真正的Agent，需要的数据将会有多少，这里你可能会说：我用RLAIF是不是就可以避免了，例如多个模型进行投票，然而同样存在这些模型都Fail的场景，而且很多（大概率是因为这些模型都没有这样被训练过）。所以你会发现，在CodeInterpreter中，生成的图片只是以某种贪婪算法让编译器不报错、根本不考虑是否达成了任务本身。
如果你是一名硬件/MLSys工程师，你会发现想用AI制作一个库简直天方夜谭，实现仿真-综合-烧写的自动化流程也做不到，尤其对于一些小众化语言（例如VHDL、Verilog、Chisel），基本上找不到合适的数据集，而我们又知道，在SFT方面，数据一致性很重要，SFT数据大部分（可以有少部分没有）需要与预训练数据具有一致性，否则会影响模型的推理（Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations? ），这告诉我们需要在SFT阶段尽可能使用和Pretrain语料尽可能具有相关性，极少添加少相关性代码。因此你会发现，在Verilog场景下，市面上任何LLM都非常弱（以VerilogEval为测试标准。而如果你想写一个类似CUTLASS的库，那更是几乎不可能的事，所以你回望现在号称无所不能、潜力无限的Agent（即使是可能最好的OpenDevin），基本上也就是写一个页面，或者是一个小游戏而已（参考ChatDev、AutoGen、Camel等），当然，能力会不会更强我也不好说，但一定需要大量的RLHF数据和充足的SFT语料（不单单是单一的文字，同样也需要有reasoning关系，有Planning、Executing等）。
如果你把目光转向具身智能，会发现更是如此，只不过这一块更要求硬件，但同样你会发现需要收集大量真实世界的数据，这种数据相比文字更加复杂，提炼Feature会更加艰难，尤其是在你想要获得足够的物理信息；视频生成领域也是如此，快手Kling在吃面这个任务场景上的成功侧面也说明了需要有足够的吃面数据；你同样需要提炼足够的帧来进行生成、平滑插值等。
综合以上几点，我想表达的是LLM正逐步趋向于某个瓶颈，要想攻破，就需要更加多样化的数据，一个奇怪的认识是，LLM = 99%的数据+1%的算法，尤其是Llama架构。可想而知的是，在日后会发现更多LLM不能的Case，然后就有更多人来进行标注，再进行RLHF，Case by Case，其实很费人力，LLM同样可能在此过程发生灾难性遗忘等，导致未来的某一个节点可能会停滞，同时耗费大量的金钱、人力，以及永远要担心不可避免的幻觉。Lecun也说，或许LWM才是正道，总之，这或许是一个需要一个更大的ImageNet来继续增长爆发的时刻。
未完待续~
END