在跟朋友闲聊的时候,有朋友会有一个这样的观点:算法工程师就是一个做技术的,只要做好模型做出好的指标效果就是自己最大的产出。对业务的理解那是产品运营的事情,某种程度上是靠产品定位,那是靠天吃饭的。
我当然反对这个观点。我的观点就是,算法工程师,虽然主业是做算法模型相关的,但是有时候甚至要比产品运营还要懂业务。
为什么这么说呢?
我们首先来看一张图:
这是一张层层镶嵌的矩形图,矩形的大小代表了这个模块的上限。每一个矩形的右上角都有一个标识,代表这个这个矩形块的具体含义。而从外层向内层,分别是业务场景、数据、特征、和模型。
怎么理解呢?
**一、决定一个算法问题上限的,是对业务场景的理解。**比如我是一个做推荐系统的算法工程师,我现在想通过推荐系统去优化一个App的留存。如果直接以留存为目标去做建模,可能是一件非常困难,甚至是一个机器学习不可解的问题。但如果把这个业务目标再做一次理解和转化,怎么建模用户留存的问题,转化成为“给用户推荐他可能感兴趣的视频”这个问题,那么就可以建模用户某一个视频的喜爱程度,那么就有很多方法可以做了。这其实就是对业务场景的理解。
**二、在对业务场景有理解之后,数据接下来非常重要的一环。**还拿推荐算法来举例子,我们的目标是建模用户对某一个视频的喜爱程度,这时候我们要决定收集什么样的数据:比如如果用户喜欢这个视频,我们预期他会看这个视频时间长一点,可能会看完这个视频,可能会给这个视频点赞。这些收集到的这些数据,都会成为我们接下来算法建模的目标。
但这里数据的上限是大不过业务场景的,怎么理解呢?**一方面,数据可能会有各种各样的不符合预期的情况。**比如数据记录错误了,记录显示用户没有播完这个视频,但是实际上用户播完了;数据在传递的过程中出现了异常,比如出现了整数溢出等等问题。这种问题我们虽然可能可以通过提高系统稳定性来解决,但实际上还是难免会出现。一般维持一个系统的准确率在99.9%已经是比较困难的事情了。**另一方面,可能还有很多数据,就是收集不到的。**我们都说,推荐系统的目标是为了建模用户的偏好,我们这里有一个假设就是用户的行为就反应了他自己的偏好,所以我们才能根据用户是否点击,来判断用户的喜好程度。但是加入用户被一个标题党的视频欺骗了,他的行为和自己的偏好出现了不符,这时候就会出现,数据记录是用户喜欢这个视频,但实际上用户并不喜欢。这两个问题都决定了,我们的数据收集能达到的上限是很难达到业务场景的上限的。
**三、在有了数据,有了正负例之后,特征是接下来的一环。**在一个具体的业务问题上,一方面,可能受制于自己的智力水平,想不到所有的特征;另一方面,想要的特征也不一定100%能够收集到。那么在特征这一环,模型的最终效果实际上也有所损失。
**四、最后一环才是模型。**我们用什么样的模型,比如是一个GBDT模型,还是一个深度学习模型;用什么样的模型结构,效果怎么评估,所取得的上限构成了这里的模型部分。
可能大家日常对算法工程师的理解,主要是在三、四两个场景,觉得就是在做特征的挖掘和建模。但实际上,一二两点做好了,也就是对业务更深入的理解、以及更好的定义正负例,才是天花板更大的场景。
所以算法工程师想要突破自己的上限,对业务场景的理解和培养是不可缺少的。
其实我们日常生活中也用到了不少对于业务场景的理解和培养的知识。
比如我们在找工作的时候,一直试图想找一个大厂、核心岗位。那么怎么判断自己做的事情在公司算不算核心岗位呢?这里其实也是需要对业务的理解。
在商言商,核心与否其实并不是看这份工作和自己的简历是否契合,而是看这份工作的产出能给公司带来多少的收入。
能够对公司收入产生核心影响的,就是公司的核心岗位。
那么接下来的问题就是,什么样的岗位才对公司的收入产生比较核心的影响。
这个问题,建议大家两点:
-
对于一个信息流分发为主要场景的App来说,推荐和广告仍然是最主要的两个环节。前者承担了让用户留存和消费更长时间的任务、后者在广告变现效率上不断优化提升。
-
一些研究性质的岗位,因为很难直接对公司收入产生价值,无论有多么光鲜的履历,在商业竞争到来的时候,都称不上是“核心”岗位。
建议大家在找工作的时候,也可以从这个角度去思考一下。除了这个公司的规模大小之外,也多问问自己所在的岗位能够未来为公司创造多少收入。毕竟,如果公司收入规模上不去,给你发的工资的价格也自然上不去。
=====
你对算法工程师解决是否需要理解业务这个问题怎么看呢?欢迎给我留言,我们一起讨论。也欢迎关注我的微信公众号: 峰池 (fengchitalk),我们一起讨论