算法工程师如何拿结果:走过低谷,先立信念

阿里妹导读

作者结合自己在推荐算法领域的工作经验讨论“如何拿结果”这个问题。

引言

到了绩效季前整理收益和工作的时候,有时候会遇到明明好像干了很多事情,但是收益一言难尽的情况。毕竟“为过程鼓掌,为结果买单”,老写鼓掌的事情也没人买单。而到了新财年开始,我们刷刷写完OKR后,心里会给自己打气,“这次一定!“,但同时心里也会悄悄打鼓“到底怎么样才能拿到结果呢?”。

如果把个人在职场的成长想象成一座大厦的构建的话,拿结果的能力就是最下面的地基,楼能有多高,能屹立多久不倒就看地基牢不牢了。我见过一些一毕业因为机缘就带很大团队的同学,在老板力挺下属给力的时候还能顺风顺水,一旦人员和环境发生变化,没有真正拿结果能力的人就成了沙滩边裸泳的人了。

我们自然都不想成为那个裸泳的人,笔者在这里结合自己在推荐算法领域的工作经验讨论下“如何拿结果”这个问题。

一、复杂性和不确定性

为什么算法工程师遇到拿不到结果或收益的情况看起来有点多,也更让人焦虑呢?主要原因在于我们是在面对一个复杂系统做不确定性的工作,结果并不是一个即时的反馈。

首先来看复杂系统,复杂系统第一个显著的特点是它是由多个模块有机组合形成的,即使每两个模块之间的交互关系很清楚,放在一起就往往呈现一种混沌之态。从时间轴来观察,我们能看到复杂系统的另一面,时延性。即我们对这个系统作出了一些改动,要滞后一段时间才能看到效果。

还有一个不确定本身是在建模的目标上,例如推荐系统本质上建模的用户侧的工作就是建模一群简化的大脑或者大脑的一部分,即人对于内容的偏好。正如乔布斯曾经提到的那样,人们并不是那么擅长表达自己喜欢什么。而不同人对于内容的偏好也不尽相同,即使有两个人都完整地看完了一部相同的剧集,他们所喜爱的明星也可能不同。经常会遇到的一个问题是:“为什么我不喜欢这个你给我推荐”,或者镜像问题“为什么我喜欢那个你没给我推”。具体到每次优化迭代,我们可以看到点击率等指标显著地上涨了,但是还是无法明确地解释为什么现在这个内容对某个用户相比之前排得更靠前了。

时间延迟是另外一个复杂性的问题,如果我们对系统的操作要隔很久才会得到反馈的话,在这个时间过程中所产生的新的变量并不能很好地被我们所感知和处理,导致我们不能准确地把握我们之前的操作,对于这个系统的影响到底是正向还是负向,影响程度是大还是小也就无法进一步操作了。

忽视时延问题有时会让我们盲目快节奏迭代,根据实时监控和小时级数据在一些假阳性结果里happy地走上一条不归路。我有看到过这种情况,策略或模型里有几个超参数是可以调的,发现负向了,赶紧调调某个参数;过几个小时觉得微正了,又想再调调能不能正更多;结果另外一个指标负了,我又再调调另外一个超参。结果折腾了一个礼拜,结果一直在AA-Diff内,周报都没法写。

二、信念

在这种不确定系统下工作,我们有时候会出现一段时间拿不到结果的情况,也不太清楚接下来该往哪里走,会特别迷茫,甚至会怀疑自己。

这种时候信念是能帮助我们走过上面这一段段黑暗的光,一个可以燎原的小小的火种。

而所谓的信念,指的是相信自己能做出东西。支撑这个信念的一方面是乐观的心态,另外一方面更重要的是过去成功的经验路径。

乐观的心态还是可以有理论支撑的,也就是机器学习中的 "No Free Lunch Theory (NFLT)"。这个定理告诉我们,没有一种机器学习算法可以在所有情况下都比另一种更好。每个公司的用户都会有一些差异,同一个产品的不同页面和模块用户行为分布也会有差异,产品随着新老用户变迁分布也会发生变化。此外产品上总是忍不住做一些改版或者心智调整的工作,会带来分布的骤变。总之,以前的模型,别人的模型肯定都没有那么适用了,我们肯定是有空间可以做事情的。

失败不是成功之母,成功才是。那么对于校招/刚进入职场的同学如何建立起自己成功的路径呢?简而言之有两条可行的大道。

第一条是从自己的技术/学术积累入手,在初步了解业务问题和逻辑框架后,结合自己的学术/技术积累,找到问题的切入点。比如自己对图模型的相关工作比较了解,目前系统里的召回大部分是行为base的I2I,U2I等,我是否能基于图模型做一些工作。

第二条路是从业务入手,在浅层地了解业务后,找到一个或多个点,不停地dig in,深挖,发现数据和分布的异常。对于推荐系统来说,常用的方法就是对人群和物料进行切片,找到一个用户-物料对的子集,这块推荐有异常便是一个机会点。异常的表现一般是数据指标不合常理的低,但真正要把Ta做高,对于一些成熟场景来说也绝非易事。如何进行数据分析挖掘提效点,后文将会具体展开。

三、原则

最后我们来聊聊拿结果的原则,即要事第一。当我们复盘为什么没有拿到结果时,要么是不懂判断什么是要事,要么是不懂什么叫做第一。

那么如何来判断什么是重要的事情。我们可以有三个视角:老板视角,业务视角,技术视角。首先最简单的是老板视角,你多和Leader/老板沟通,大致上就能知道他最关注的事情是什么。如果有一些变化你觉得可能会导致重要性发生调整,可以及时沟通确认。

其次是业务视角,基于你对产品和业务的理解。举个栗子,商业化一般是公司的核心目标,但是不同的阶段商业化的重要程度不一样。有的时候愿意多牺牲一些商业化的利益,甚至承受一些亏损,来追求规模上的增长。规模的增长往往与用户的留存和活跃相关,这里月活和日活也有一些细微的差别。以在线视频网站来说,用户的停留时长与用户的留存乃至会员转化都有比较强的正相关关系,那么这个时候,系统的目标就不能单单追求点击率,还得考虑时长这种目标来建模了。

业务上我们还需要看到的一个点是,产品形态上app是由很多个页面组成,业务也会分属很多个团队负责,各个页面和各个团队追求的目标也不尽相同。比如典型的双列Feed 一般分为外流和内流,对于用户播放转化这一目标来说,内流毫无增量的贡献,更适合以时长以及下滑深度等而不是点击率类指标作为其目标。

技术视角对重要判断也有自身的三个角度。

一是for PR(Public Relation,这里指对外展示公司或者团队的技术先进性),主要关注的是创新性和如何蹭热点。对应的产出一般是Paper,或者是大会上的专题分享等。如果一个技术点在当前SOTA(state of Art)基础上有明确的创新,值得整理发表论文或者分享,那么Ta的重要性可以提升一些。

二是我们通常说的技术包装,有一些工作往往从创新度上还没有达到直接可以整理发表的水平,但是我们也付出了很多精力去做,也拿到了一些结果,但是在总结通晒的时候常常让人感觉平平无奇。但是有些同学明明线上收益和我们差不多,但是PPT/Doc却很有深度的样子,图『琳琅满目』,逻辑一套一套的。是不是人家会『包装』而我不会?

其实我个人更愿意把技术包装叫做技术规划或者技术远见。就像是一棵树,它结果的时候一般在年度或者半年度的绩效总结或者晋升场合上,但是种子在大半年前甚至更早就已经种下了。我们往往喜欢用拥抱变化作为没有长期或者成体系技术规划的借口,但是很少检讨自己是否能更好地抓住一些不变和本质的东西。亚马逊创始人贝索斯曾说过:我经常被问到一个问题:“未来十年,会有什么样的变化?”但我很少被问到:“未来十年,什么是不变的?”。我认为第二个问题比第一个问题更重要,因为你需要将你的战略建立在不变的事物上。回到算法的工作中,不变的业务中的一些具体问题,比如:新的物料来了如何高效地冷启,同时能快速发现其中优质内容放大;父母和小孩共用设备如何做更好地推荐等等。如果两份任务同时摆在我们面前,一份任务更能解决业务或者系统的本质问题,那么Ta的优先级就更高。

三是技术债的角度,往往我们为了完成一些短期的任务,代码和系统会逐渐演化成一座shit mountain,那么在初期就需要尽可能好的框架设计,维护中做好防止劣化。这个东西短期不需要考虑,拉长到半年或者一年还是会有一些影响,比如资源是模型复杂度的约束,如果复杂度的增长远快于收益的增长,后期模型就迭代不动了。此外如果为了满足短期的需求,拆分了巨多不按照通常的『召回-粗排-精排-重排』路径的链路去强插和配比例透出,后期就很难去融合,这也变相降低了模型迭代的影响面。

知道什么是要事,那接下来的事情就是做到“第一”了。第一简而言之就是集中优势兵力去打歼灭战。另外一个相关但是没那么重要的事情是如果减少给不重要的事情投入兵力。我们需要把80%以上的精力和时间都放到这件要事上,从各个角度去揣摩它,试探它,分析它。

10