心法利器[98] | 除了训练，大模型还有很多重要工作

心法利器

本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。

2022年新一版的文章合集已经发布，累计已经60w字了，获取方式看这里：CS的陋室60w字原创算法经验分享-2022版。（2023在路上了！）

往期回顾

• 心法利器[88] | 有关大模型幻觉问题的思考

• 心法利器[89] | 实用文本生成中的解码方法

• 心法利器[90-95] | 谈校招：合集

• 心法利器[96] | 写了个向量检索的baseline

• 心法利器[97] | 判断问题是否真的需要大模型来解决

最近挺多人和我说，挺焦虑的，最近大模型的势头很强，很多人都争着去做大模型相关的事，尤其是训练这块，但实际上，能分到类似的活的人少之又少，即使是在大模型的有关分组，运气好点的可能是一些类似向量召回、加速编译等的工作，但大家更多是分到数据、prompt、评测等其他看着比较边缘的工作。没拿到看着比较关键的蛋糕，所以就很焦虑。但其实个人角度完全没必要这么焦虑吧，围绕大模型，肯定不止训练这一个事情是有意义的。

当然了，这里可能有些观点可能比较激进，大家酌情参考吧，友好交流。

先聊训练

训练可以说是很多人梦寐以求的工作了，但实际上，从这份活本身的形态和具体需求来说，本身能分到这份工作的人，本就应该非常少。

• 受限于资源，能做这个实验的人就多不了。众所周知，大模型训练需要的资源很多，能训的起的团队就不多，更别说全量了，能轻量化训练的就很不容易了，而训练需要的资源有很多，一旦训起来就是小几天半个月，资源用起来后，别的人还要训其实难度就很大了，所以人多没啥用。

• 训练这活不好拆解，数据到位后（比较大的团队甚至有专门的人做数据，毕竟数据量大，需要大数据技术栈，训模型的人聚焦后时间变少），剩下的就是开发工作了，除了训练策略，再兼顾一些多机多卡、引擎相关的工作，基本就足够了。

• 再者，因为训练是有周期的，在训练周期期间，一旦分工比较模糊，很可能还需要关注数据、加速等，其实杂货还不少。

所以其实看到，因为不少原因，能分到这个活，其实就已经是低概率事件了。做大模型训练的好处自不必多说，确实是走在风口，大家应该都是闻得到香味的。而且实际上，这个活没想象中那么光鲜，那么炫酷，还要面对很多挺尴尬的事：

• 花很多时间，但是效果出不来，而出不来的这个问题，可能要隔几天甚至几周才会发现，但是时间却没了，KPI压力巨大。

• 本身是成本部门，推广和转化有时间压力，时间长难以出成果，一旦上级失去耐心，很可能会直接干掉。

• 技术栈其实和一般的NLP算法已经有些不同了，找工作反而可能并不见得那么吃香，一些BERT都没用上的团队，很可能会继续掉队，尽管有一些可能已经明确希望能赶上，也不见得能这么快就到位。

• 有关前沿的探索，有关资料不会那么多了，多半靠新的论文，还需要自己探索，要鉴别有效性，实验可能也不一定效果。

第三点可能会有些争议，大家其实看大模型现在这么火，但其实需求虽然有增加，但是不见得都聚焦在训练，或者压根就没有条件训练（能跑得动推理就不容易了，而且还是要满足并发的推理），很多时候新增需求更多是希望能用起来，训练本身，其实远没有实际重要。

另外，可能是因为NLP之前版本习惯的惯性，或者一些技术影响力之类的因素，很多人在拿到大模型的活的时候，首先想到的是微调，找数据，然后开始进行训练，然而实际上，真拿到一个大模型后，直接去进行训练，可能并不是一个很方便的方法，尤其是在当下的NLP版本，之前我有聊过我认为的版本答案可能是这个：前沿重器[34] | Prompt设计——LLMs落地的版本答案，目前看来可能真的依旧是。

除了训练还能做什么

我分成两大类吧，一大类是做非算法的工作，另一类是算法类的工作。尽管不是直接地训大模型，都是非常有价值，而且对个人提升也有很大好处的。

另外还需要强调的事，算法工程师，不做模型训练，是非常正常的，日常一般都是这样的：心法利器[31] | 我的算法工程师日常，这个观点，相信大家都能理解。

非算法类的工作

非算法类，而很有价值的工作，主要是两个，前面都有提到，一个是数据，一个是工程。

数据，是算法之源，由于大模型需要大量的数据来做工作，如果遇到数据比较丰富的部门，那大数据技术，则是非常重要的，做数据清洗，就不是一小段python的脚本就能完成的，hadoop、spark等技术要拿出来溜溜，例如几百个G的数据甚至更多的数据，脚本真不够用，实在太慢了。当然了，这份工作可以是由数据工程师配合完成的，毕竟其实原来他们就做了很多类似的工作。

工程，别以为做算法就不需要管工程，尤其在现在这个大环境，大模型是需要训练的，多机多卡之类的资源调度是肯定需要了解的，而且训完的模型需要部署和落地的，先别说加速，就是正常模型的部署，就需要很多工作了，这段时间加速也随着大模型的兴起进一步被重视（其实bert中后期也开始有很多人开始关注，但是真正兴起，我更倾向把时间点放在大模型上）。而因为原有的工程，其实并不懂算法内部的逻辑，而且有关内容大学并不会培养，是比较新的技术栈，因此这些任务往往是由原来的算法工程师担任，然后逐步独立出来形成新的工种，一般公司可能会有大模型引擎之类的说法。

算法类工作

说完非算法类，然后就是聊算法类的工作。从系统角度思考，大模型很难完成所有工作，而在一个系统中，大模型更多是承担结果润色、内容抽取和梳理之类的作用，其他部分仍有很多重要的工作可以做，下面举几个例子。

拒识和意图识别：这是一个搜索和对话场景很常见的能力，之前我其实花很多笔墨聊过这个东西了：R&S[25] | 搜索中的意图识别。到了大模型时代，为了避免模型接触到我们意料之外的东西，除了直接通过指令的方式约束，更多时候我们是选择在大模型上游增加一个拒识模块，把无关的给拒绝掉，亦或者在面临不同的场景，我们需要有不同的回复策略或者是资源依赖，此时上游就会加一个意图识别的模块加以控制，从而实现手动可控结果生成。

检索：外挂知识库应该是大模型环境下一个很重要的方案了：前沿重器[34] | Prompt设计——LLMs落地的版本答案。然而在项目前期，相比于大模型的抽取和总结的能力，更多时候效果的短板更多是在知识库的检索部分，无论是向量召回还是字面召回，都有很多需要优化的问题（真心建议大家多做case分析：心法利器[40] | bad case治疗术：解决篇，很多时候真不怪大模型，召的都不对模型怎么答都没用），因此把检索这块进行重点优化，收益是非常大的，所以把重心放在这里，可能更加关键。

prompt：prompt可能是现在的大模型版本下看着比较low的工作了，完全不输原来所谓的“规则”以及“词典”之类的方法，但从结果导向，很多时候，可能真的是稍微修改下prompt，最终的结果可能就会有很大的不同（这点记得还有论文论证过，prompt对结果的影响很大）。除了良好的基础大模型，我们还需要良好完善的prompt来引导模型把更好的内容给写出来。甚至，对于一个优秀的prompt，只要大模型没什么关键缺陷，其实效果不会差很远，都没什么调大模型的必要性。