算法工程师的「天地之间」

Posted 2022-12-13 Datawhale

 Datawhale干货 

作者：王喆，字节跳动

作者简介

王喆老师目前是字节跳动的技术经理，Ads Ranking方向负责人。

• 毕业于清华大学计算机系，清华KEG实验室 学术搜索引擎AMiner 早期贡献者。

• 曾任Roku Tech Lead，推荐系统架构负责人，Hulu 高级研究员，品友互动 广告效果算法组负责人。

• 主要研究方向为推荐系统、计算广告，发表相关领域学术论文和专利20余项，曾担任DLP-KDD联合主席，KDD、CIKM等国际会议审稿人。

• SparrowRecSys，SparkCTR等开源项目发起人和主要贡献者，6k stars+。

• 著有《深度学习推荐系统》，《百面机器学习》等技术书籍，读者6万+。

正文

工作太忙，已经半年不写文章啦，这周末得空写一篇，也算是最近一段时间的工作总结。

四五年前开始写专栏的时候，技术文章还不是很多，现在不管是各大顶会的搜广推paper，还是知乎上的解读文章，都如汗牛充栋。到了这个时候，死扣模型的细节反而不那么重要了。在整个行业的low hanging fruit都快被摘完的时候，再去纠结能不能通过加一个新提出的结构提升0.1%的AUC，去遍历业界可搜寻到的所有新idea去提升0.1%的CTR，逐渐变成了一件非常boring，也非常容易让人产生挫败感的事情。

所以，越到这个时候，我们反而应该放下你手里的paper，放下你不知所措的心情，坐下来想一想，难道算法工程师们提升效果之路真的走到了一个死局里吗？是不是哪里出了问题？

你是算法工程师，不是深度学习工程师

正面回答这个问题之前，我想谈的是一个误区。不少同行常常感叹，深度学习的时代红利挖尽，算法方向瓶颈尽显。其实是默认了一个状态，算法工程师=深度学习工程师。这个等式成立吗？当然不是。在遭遇广告系统、推荐系统问题的时候，没有一个人规定你只能用深度学习的方法去解决。真实的情况是，搜广推领域的大量问题，深度学习都不是最好的解决办法。当我们面对推荐系统的冷启动、探索与利用，广告系统的出价、预算分配等等问题的时候，沿着深度学习的路子去深挖，往往是会误入歧途的。

只有逃开了这个误区，我们才可以谈一谈，作为一个算法工程师，如何去破局，如何从深度学习的限制中逃开，回到解决问题这条正道上来。像这篇文章略显玄幻的题目一样，也许是时候想一想在算法工程师的能力框架中，哪里是“天”，哪里是“地”，在这天地之间，我们可以做些什么。

算法工程师的天——系统架构

在写《深度学习推荐系统》那本书的时候，我一直努力让自己始终把推荐系统的框架印在脑海中，每写一节，都希望它能嵌回原来的系统架构中。任何脱离了系统单独存在的东西，都不会是理想的状态。我想一个算法工程师的天，应该就是这样一个印在脑海中的系统架构。而任何一个成功的改进，都应该是与这个系统自洽的。

脱离了系统架构谈算法模型的改进有时候会产生很滑稽的效果。很多年前我还在做垂直领域的广告模型，有些广告主的转化事件非常难，于是转化数量就非常稀少，一天可能就几个。在这样的场景下，因为当时业界转深度学习是大势所趋，所以很多同事就希望用深度学习的模型解决这个问题。但关键问题是深度学习模型恰恰不善于处理小样本学习的问题。我们不能说就因为当时这个技术fancy，就认为它能解决一切效果问题。在这个问题框架下，深度学习显然不是那个自洽的解决方案。

再举一个例子，我工作的第二年负责的是广告系统的pacing模块，就是要去优化一个广告计划的预算，让它的投放速度尽量平滑，不要短时间内把预算都投完了。我设计了一个PID控制的算法去控制单个计划的投放速度，控制效果是很好。但由于每一条广告计划都要独立进行大量的流量价值判断和自身剩余预算的判断，我居然把系统打崩了，工程负责的同学强行下线了这个策略。这个教训是什么？就是心中没有全局，没有算法和工程的整体架构，理不清各模块之间的关系，你单点做的再好，也不利于整体目标的达成。

其他例子我估计你身边也发生过不少，比如上了一个新模型，效果提升了0.1%，结果模型体积扩大了10倍，模型收入还cover不住资源的消耗。遇到一个问题就打补丁，还没搞清楚全局的问题在哪就着急解决问题，到处加规则最后谁都不敢动代码。解决问题本末倒置，精排的问题在粗排解决，粗排的问题在召回解决，从来不看看这几个模块能不能联合优化，从而各自为战。如果你遇到过这几个问题，那么毫无疑问，你的“天”不够高。

三四年前，我们还经常吐槽算法工程师的面试是“面试造航母，工作拧螺丝”，现在随着各家公司的系统复杂度都越来越高，对算法工程师的要求也确实水涨船高，作为一个合格的算法工程师，你还真得知道怎么造航母，才敢在一艘大船上拧螺丝。否则结果就是要么这艘船上到处都是螺丝钉，要么直接把船修沉了。

算法工程师的地——数据细节

如果说对系统架构的理解是算法工程师的天，那对数据细节的观察就是我们的地。魔鬼藏在细节中，一切宏大的故事能够讲成，首要条件是有一个好的故事框架，其次就是对所有细节的把握。在推荐系统，广告系统中更是如此。

我经常在知乎上受到类似这样的咨询，说王老师，我们公司最近刚上了DIEN模型，但是效果不好，原因是什么呢？

这个问题本身就是非常荒谬的。这就类似于一个高中学生问老师，老师，我最近上了你的物理补习课，但是成绩还是不好，原因是什么呢？

任何一个模型的提出，都有它的动机，背景和适用的数据集。在一个模型那些上的了台面的创新点背后，也会有无数的tricks在支撑着那个特性环境下的模型效果。我们往往浅尝辄止地去适配一个模型，遭遇挫折之后就把锅甩给这个模型，看似跟自己一点关系都没有，其实不过是懒得进行哪怕一点主动思考罢了。

好几年前我带过一位实习生，当时的任务是打通一个新的pipeline，收集一组新的特征加入模型。事情做的很快，一两天时间就得出结论说，这个特征加进去了，没效果，有没有其他任务给他做。当我回头把这个特征的数值分布打出来之后，看到几个关键问题，一是特征覆盖率有问题，大概只有20%，二是特征值的尺度有问题，outlier的位置偏离非常远，三是特征值的分布极不均衡。这几个问题发现不了，没有做相应处理，就是把特征加进去了，这不是应付公事是什么呢？在“加特征”这样一个小的不能再小的原子操作上，都不舍得把细节搞清楚，把数据拿出来看一看。难道还可以指望他在换模型，搭架构上有所建树吗？

如果说你对系统架构的理解决定了你工作的方向不会发生偏差，那么你对细节的把控能力就直接决定了你的工作是否会成功。

不可否认我们所有人都对“宏大叙事”有偏爱。但其实宏大叙事能够成功，往往都是从最重要的一两个点来突破的，而这一两个点，必须有人从头到尾，从始至终的关注细节，否则就是一堆处处漏风的空中楼阁。

算法工程师的天地之间

系统架构是天，数据细节是地。在这天地之间，才是最爱被算法工程师们津津乐道的建模能力和技术能力。你从系统架构中找到了最合理的思考方向，从数据细节中发现了问题的真正之所在，剩下的事情，就是用你的技术能力，你的建模能力去解决它。其实，如果你真正能够通过数据分析找到问题的所在，这一步反而是最简单的了。这里面需要注意的是，不要再次把自己的视野局限在所谓的“深度模型架构迭代”上，它重要，但仅仅是搜广推等互联网核心系统中的一个环节。

对于一个以机器学习为核心的大系统来说，要从三个方向找到你解决问题的方案：

1.样本与特征。你的特征是否干净，有无噪声，特征质量是否高，覆盖率怎样，样本相关的数据流实时性如何，样本是否有丢失等等问题。数据才是你系统效果的上限，模型只能决定接近这个上限的程度。

2.Label。对于Label的理解其实本质上就是你对问题的理解。到底什么才是你这个问题真正的label，如果没有明确的正label，如何处理处于中间阶段的label，要多目标还是多阶段，还是独立拆解成两个问题。在海外隐私合规日益严格的情况下，拿不到label怎么办？如何用一些替代信号当作label，如何在合规框架下拿到label。

3.模型。你对模型的理解是否还仅限于套用别人的框架？能否从你的业务特点来改造模型？哪些特征该交叉？哪些该做成wide，哪些该做成deep，哪些结构inference特别慢，如何优化，模型的改造会不会造成工程上吃不消，不同模型之间如何配合等等。总之模型的改造记住一句话，一切不经思考纯靠蒙，靠原封不动移植模型架构的尝试都不会有太好的结果。

这些都是天地之间的内容，远远不限于模型的改进。在真实的搜广推系统中，甚至不限于机器学习，还涉及到大量传统算法，控制论，博弈论的知识，把眼光仅仅放在深度学习完全是作茧自缚的行为。

几乎所有的算法工程师同行都是从学校的实验室走出来，我们喜爱那些干净的结论，清晰的创新点，但那不是真实的世界。真实的世界永远是混乱和秩序并存的，我们要做的就是从这个混乱的世界中精准的找到那根解决问题的线头，把它扯到秩序的这边来。

写在最后

既然谈到了天地之间这么宏大的主题，我们的文章也不能没有一个主题架构图啊，最后给大家补上。

算法工程师的“天地之间”

最近国内外互联网行业的形势都不轻松，不如趁这个机会练练内功，行业再怎么变化，真正能够主动思考，解决问题的同行，机会仍不会少，祝大家一切顺利。

讨论

你认为算法工程师的核心能力是什么？欢迎在评论区交流讨论~

整理不易，点赞鼓励↓