大家好，我是刘聪NLP。
毫无疑问，全栈型的算法工程师将更为抢手，如果你精通大模型从训练到应用的整个流程，你走到哪里都不怕。
但往往人的精力有限，如果从数据、预训练、微调、对齐、推理、应用几个方面来看的话，个人觉得现在重要性排序是“预训练>应用>数据>对齐>推理>微调”。
先说一下各个方向的特点，再说我为啥这么排序吧。纯个人看法，不喜勿喷，交流欢迎讨论。
数据方面
不可否认的一点，现在很多算法工程师，都可以称为数据工程师，在模型调优的绝大时间里，其实90%甚至更多的时间，都在做数据相关的工作，无论是数据爬取、数据构造，还是数据清洗、数据混合。
“garbage in, garbage out”也是业界公认，数据的质量和数据量决定着模型的效果。这也是为什么都是基于llama的模型，都用lora方法训练，用的都是llama-factory的代码，但你的模型效果不行的原因，很多时候是数据层面的因素，可能是你的数据并没有很好的激发出模型本身的性能，也可能是给模型灌入的知识质量很差。
对于数据方面，已经有很多工作，但哪些有效，哪些适合你自己的场景，对于你自己的场景是否有更好地数据构造、清洗方法，都是算法工程师要考虑的事情。
现在合成数据也变成了大模型可以走更远的基础，无论是Llama3.1，还是Qwen2系列模型，都用了很多合成数据，并且各细分领域的合成数据也可以更好的激发模型效果（Qwen2-Math）。
数据合成方法-让模型自己说出用了哪些指令对齐数据 浅谈Llama3、大模型开源与闭源以及合成数据 大模型微调技巧 | 高质量指令数据筛选方法-MoDS DEITA-大模型指令微调的数据高效筛选方法 RegMix-用回归任务解决大模型数据混合问题
预训练方面
大模型时代可以做真正做预训练的企业非常少，做该部分工作的算法工程师也就更少。（当然用20B Token数据，对1B参数模型预训练，咱不算哈，别杠~）
真正对千万级别参数大模型进行几甚至十几T tokens进行预训练的，对机器要求很高。在多机之间通信过程中，会存在很多问题，训练过程中也会出现很多问题，那么如何解决这些问题，是十分宝贵的经验。毕竟Llama3.1 450B预训练阶段54天也是断了466次。
由于真正有机会做这些的人少之又少，所有该部分算法工程师很宝贵，毕竟物以稀为贵。如果有了这些人，也许可以少走很多坑，或者说可以更快的训练出大模型。
当然除了从头预训练还有一些增量预训练，虽然资源消耗没用那么明显，但超大模型的全量参数训练，依然需要考虑性能、成本的因素。
说白了，就是你最多用过多少张卡，训练优没优化相关性能。
微调方面
现在网上开源项目很多，微调基本上已经成为了有手就行。把数据准备好，环境准备好，甚至可以web-ui一键训练。全参、lora、qlora等等方法已经成为了很多项目的标配。
可能当你任务有特殊要求时，会简单修改一些dataloader部分，trainer、deepspeed基本就是config参数配置，改改学习率，改改轮数，然后bash train.sh。
现在基本上在面试实习生的时候，人手标配，微调过xxxx模型，然后细节一概不知，反正就是跑起来了，一问效果就是感觉好了一些。
但模型调的好不好，还是看人。
对齐方面
无论是人类偏好对齐，还是安全性对齐，对于ToC端大模型是必要的，这样可以大幅度提高模型的友好性。对齐过程也是坑比较多，有时模型对着对着，就炸了，开始不说人话了。
llama2是根据多种reward模型进行rlhf对齐，现在也有很多简单高效的对齐方法，比如DPO、ORPO等，但实际训练过程中也是一言难尽，需要深入研究。反正我对齐不好，就是怪数据不行。
但对于ToB端来说，貌似对齐的意义不大，因为很大程度上，大模型已经被限制了仅在固定场景中使用，或者即使内部出现不安全问题，也不会引发公众影响，ToB更关心的是效果。
那么就看你司业务主攻方向了。
推理方面
大模型参数太大了，对于推理资源的消耗是巨大的，因此加速大模型推理速度、减少大模型推理资源是十分重要的。
随着时代的发展，相信以后端侧大模型会越来越多，直接把大模型部署在手机上，有效解决推理资源的问题；并且现在很多模型都支持100K以上的Token，如何提升用户体验、减少自己的硬件资源消耗，是至关重要的。
现在推理加速框架也是很多，例如：vllm、fastllm、llamacpp等等，但很多大厂有自己更好的一套，比较轮子不能白造。
对于99%的公司来说，vllm、llamacpp真就够了。当然只是我个人片面的想法，很多时候研究半天，不如等vllm更新一波。
不过前一阵子月之暗面的大模型推理论文确实值得一读，《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》。
应用方面
大模型最简单的形态是以Chat形式展现，但可以有更好的产品形态，让用户在某些场景可以更好地利用大模型的能力，来解决核心问题。那么就需要将大模型包装成一个好的产品，需要更好地激发大模型能力。
当然真正做应用的，并不是说调调prompt、few-shot一下就完事儿了，这里是只需要考虑如何将复杂问题进行拆分，当一些模型能力不足时如何利用其他手段进行兜底。
当然很多做应用的还需要少量的模型微调，甚至要灵活运用之前的小模型，以满足产品对应的要求。
写在最后
上面在说各个方面特点的时候，你应该就可能知道我为啥觉得“预训练>>应用数据>对齐>推理>微调”了。
因为掌握预训练的人才较少，毕竟物以稀为贵；而数据由是大模型的重点，毕竟有多少数据就有多少智能嘛；对齐主要是很多场景真没必要，毕竟我是做ToB较多，认知也许比较狭隘了；推理其实主要是很多开源框架已经支持的很好了，感觉对于很多厂商来说也许开源就够用了；微调到现在这个阶段，真快成为了有手就行；各大公司已经不在无脑砸钱做底层训练，大模型应用落地、变现是现在的重点。
当然，将技术这么区分是很极端的，很多时候技术也确实是交叉的。大模型时代技术更新也是十分迅速，2023年初的时候，真不敢想象各大公司追赶CloseAI的速度会这么快。
每天读不完的论文，看不完的爆炸消息，以至于很多人对很多LLM的内容已经脱敏了。
但学就完事儿了~
PS：给公众号添加【星标⭐️】不迷路！您的点赞、在看、关注是我坚持的最大动力！
欢迎多多关注公众号「NLP工作站」，加入交流群，交个朋友吧，一起学习，一起进步！
我们的口号是“生命不止，学习不停”！
往期推荐：
一大堆Chinese Llama3正在袭来 LLM2LLM：迭代数据增强策略提升大模型微调效果 如何快速提高大模型的向量表征效果？ RAG系统中答案无关片段对LLMs生成答案有何影响？ InternLM2技术报告 Qwen1.5-MoE模型：2.7B的激活参数量达到7B模型的性能 RAG与Long-Context之争—没必要争 角色扮演大模型的碎碎念 自我蒸馏方法-减轻大模型微调过程中的灾难性遗忘 Yi技术报告细节分享 大模型增量预训练新技巧-解决灾难性遗忘 如何提高LLMs的文本表征(Text Embedding)能力? DEITA-大模型指令微调的数据高效筛选方法 大模型微调技巧 | 高质量指令数据筛选方法-MoDS 辟谣！微软撤回声称ChatGPT为20B参数的论文，并给出解释。 如何看待微软论文声称 ChatGPT 是 20B (200亿) 参数量的模型？ 大模型微调技巧-在Embeeding上加入噪音提高指令微调效果 如何从数据集中自动识别高质量的指令数据 BaiChuan2技术报告细节分享&个人想法 大模型LLM微调经验总结&项目更新 打造LLM界的Web UI 是我们在训练大模型，还是大模型在训练我们？ Llama2技术细节&开源影响 大模型时代-行业落地再思考 垂直领域大模型的一些思考及开源模型汇总 如何评估大模型-LLMs的好坏？
