业务型算法岗与中台算法岗应该如何选择?
付鹏(熟知NLP领域各名词所写)回答:
假如你是算法中台,你问自己几个问题:
你怎么说服其他业务用自己的算法?
业务使用了你的算法,没有出成果,你要如何证明,是业务方使用的问题,而不是你的工作不够 solid 呢?
如果你想方设法让人相信了你的工作足够 solid,是业务方使用不对,让你来指导和 own 这个模型的调试和上线,你能保证做出成果吗?
假如业务方使用模型成功上线,指标有提升,功劳大头属于业务方还是属于你呢?
当面对业务使用 domain knowledge 不足质疑你的时候,你怎么回答?
你想要做一个算法,需要和业务方要数据权限,业务方会很乐意与你共享数据权限吗?
如果你是CTO,假设有一天你需要降本增效。需要裁掉中台算法团队与业务算法团队中的一个,少了哪个团队会导致线上指标受更大影响呢?
技术中台是阿里巴巴首先提出来的,阿里巴巴最终选择了拆掉中台。目前的大趋势是去中台化。
算法中台的兴起落后于工程技术,可能衰败也会有一些延后。因此,我更倾向业务算法。
当然中台也不是一无是处,中台整合资源能力强,shit work 比较少,可将精力集中于更“纯粹”的算法上。
但善于吃屎也是一种能力。我仍更倾向业务算法。
MLRush(信息流推荐工程师)回答:
业务型算法:好坏受业务影响,好业务压力大,回报高,竞争激烈;差业务,算法价值不好讲,被调整风险大,回报低,竞争压力稍微低;总体技术含量都不如研究型算法岗位
中台型算法:落地难,手不握业务,话语权低,盈利困难时期容易被调整;中台算法里属于研究型算法的,团队学历普遍高,竞争也不简单,但搞的东西相对高大上,以后想转业务型算法也有机会;中台算法里也有不是研究型算法的,脏活还没业务,属于最惨的。
叫我张十四(字节跳动 R&D)回答:
新人入行一年,有些感悟。随便说说,请轻拍。
这里姑且理解,业务型算法为专门在某一业务线的岗位,中台算法岗为是给不同业务线提供某一能力的岗位。二者各有优劣之处。
先说结论:因人而异,不存在绝对正确的选择。
接下来,从不同角度进行分析,供参考。
工作内容
业务型算法,能够更全面了解、理解全业务线场景和其技术架构。比如:产品的用户增长是如何做的,产品推荐的排序和召回的架构等等。概括来说,对某一类型产品拥有更全局视角,能够好培养全局sense,产品不同场景如何落地算法。
中台型算法,则更加垂直,从某一能力触发,赋能不同业务线。比如:提供预训练能力给不同业务方,协助业务方提升效果。这种的好处,就是能在垂直方向做的更深,有利于技术深度的积累。不同业务线需求不同,水平不同,也要求能力更加通用和易用。
工作压力
业务型算法往往面临更大业务指标压力,工作评价往往和业务指标成强正相关,线上效果不好时,压力很大。同时,不确定性也更强,业务整体方向和战略的改变,容易造成之前的工作全部被推翻,需要从头来过。但是,风险与机遇并存,业务收益明显时,也更容易拿到不菲的回报。
中台型算法,相对来说更加稳定,旱涝保收。研究的方向更加稳定,不断完善相关能力,压力没有那么大。
希望这些不成熟的分析,能给答主选择offer提供些思路。
以上回答转载自知乎,著作权归属原作者
分享
收藏
点赞
在看