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