算法研发工程师的痛苦与迷茫

01

作为在一家公司中从事算法，数据挖掘，机器学习的小伙伴们，似乎会有一些感觉，我现在做到的东西感觉好土啊，一点也不高大上，明明有那么多吊炸天的算法，为啥我们现在还要用这么土的方法呢？不行我要尝试这些吊炸天的算法，而有的时候却往往是吃力不讨好。

02

就个人感觉而言，工业算法工程师其实是要求蛮高的一个岗位，虽然从业七年多了，但是是否已经入门还真的不敢说。因为它涉及的领域太多，经典的已经被反复证明有成熟套路的应用场景就包括了，搜索效果优化，个性化推荐，计算广告，智能风控等等。而每一个场景背后虽然有着比较共同的基础算法理论支持，但真要把某一个领域做好，却真的不是那么容易的事情。

拿推荐的场景举例吧。

常见的推荐手法有几种，那么拿基于标签画像的方法来做个引子。

设计一套标签体系；对待推荐的目标实体，通过运营打标，用户ugc打标，实体本身附属的文本内容，图像内容进行标签抽取；对用户通过浏览、购买、加购物车，评论等行为将实体标签关联到用户身上。这样，当用户有新的行为的时候，就可以通过标签和权重集合作为特征向量，计算消费者和推荐实体的相似度，离线或实时的生成推荐列表了。

这样似乎没有啥问题，其实是有问题的。

如果我们的应用的展示位很丰富，推荐展示位只是其中一小部分，那么问题可能还不会那么明显。但是如果我们的应用是高度依赖算法智能推荐的的话，那就好玩了，因为马太效应，越推越窄，很快一些标签的权重就高的没法看了。

这该怎么办呢？

可以有一些不同的路子去尝试，可以通过标签扩展（其实效果不容易控制，粒度太粗）；或者引入其它的推荐算法作为推荐源（svd，itmbase，userbase，contentbase等等）。这个时候，就要想办法去合理安排这些算法了。

后面会有越来越多的问题接踵而来：哪些算法适合放在基础层面去负责初试粒度的召回呢，哪些算法适合把各个基础找回算法结果进行精排序呢，用户主动搜索了一个东西我如何快速反馈到其它展示位的推荐结果中呢，我该如何设计日志打点，以方便后续的效果跟踪呢，如何可以更自动化的去测试不同的算法组合，算法参数而不应总是人手动abtest呢，如何能够给运营以合理的干预权限以增加业务逻辑而又不会影响算法本身的效果呢，我如果请求失败了有没有降级方案呢，集群job似乎越跑越慢了是不是要单独申请个queue防止其他人干扰我呢……

03

哈哈，想做好效果这些全都是要考虑到的事情啊，靠单纯的一个算法，很难去最好一个场景。我更喜欢称算法工程师为效果优化工程师，因为在企业当中，你第一核心要务不是把某个算法研究的特别透彻，而是要让你的整套效果优化的流程跑顺，在此基础上，用实际业务指标去说话。

回归前面的算法同学们的苦恼，其实算法也是技术的一种，而技术的本质，按科学技术哲学中的理论是：技术是一种解蔽的过程，解蔽嘛，就是实打实的做出实际效果。所以经过大家无数次实际使用并证明行之有效的方法就特别受欢迎，新奇的算法，注定是在回去效果达到一定瓶颈的时候去做突破而用的了。