首页 > 数据库 > 数据库开发技术 > 菜鸡内容推荐算法工程师的一点心得
2021年好像已经过去很久了,一直想写一个21年度的关于工作方面的感想。或者是关于推荐算法的一点个人想法。由于我做的是内容推荐,而且是处于业务部门,因此后续关于推荐的思考都是侧重于一线业务的内容推荐。
1:什么是推荐?
网上最多的就是关于推荐方面的各种算法,他们会和你从协同过滤开始,讲到逻辑回归,再到FM,再到GBDT+LR,然后是DeepFM,再到最近几年的DIN,DIEN,BST等。但是不管它们作用于哪里,终究只是推荐中的一个小模块。
如果你继续了解的话,你就会知道推荐系统中原来是分模块的,一般分为召回,粗排,精排,重排。各个模块好似一个漏斗将用户可能喜欢的东西一层一层过滤,最后将系统觉得最合适的推荐给用户。
在实际的场景中,我们会通过流量正交的方法在召回,粗排,精排,重排层各做实验。负责各个模块的人就在各个层做实验,进行线上的AB实验对比。这也是做推荐的绩效来源,通过线上实验对比,如果你的方法比线上的方法要好的话,就可以将你的方法全量部署到线上。
你以为我是在回答上面的问题?
不是的,上面的流程我可以将其称为推荐算法,但绝不是推荐。
2:流量正交与AB实验 is All Your Need?
答案是错误的,很多时候并不是所有的策略都可以用AB实验直观地衡量,比如item的冷启策略,它是内容推荐的入口,在很多时候我们很难以通过AB实验的方式来证明该策略方法的好坏。有时候我们只能做正确的事情。或者我们可以从别的方面来衡量策略的好坏。
3:流程中的相互依赖与冲突
在实际的推荐中,独立地将各个模块的人分开,或者各个推荐人员局限于自己的模块其实是不明智的。比如对于排序人员来说,召回或者粗排已经决定了你的上限。这时候你或许可以拿出数据给你的上游说给我一些什么内容。或者冷启召回模块,当你发现某类的item比较受欢迎的时候,但是内容库中比较少,这时候可以和运营的同事沟通增加内容库中的内容。通过这种方法可以提高你后续优化的上界。
除了相互依赖之外,有些层级其实是相互冲突的,我在工作中就遇上了这种情况,你这边做实验效果很好,但是有时候却会给别的层级带来重大影响。表面看你的AB实验成果了,把绩效写的满满的,但是最后一看总体指标跌了。团队最终的OKR没有完成。
所以,推荐是一个整体,有时候你不能局限于自己负责的模块,还有关心上下游的一些重大策略。最好的方式就是整个团队可以定期进行有效沟通,重点突出各个层级的瓶颈,大家一起解决。推荐算法只是为了系统服务的,大家都是共同努力没有优劣之分。
4:推荐系统的目标是什么?
我们知道推荐算法的目标是CTR或者时长。但是对于老板来说,目标决不会是这个。这其实是一个很尴尬的情况,我们算法的目标和老板的目标其实并不一致,有时候甚至是冲突的。对于大部分的内容类产品,老板最关心的是总时长和日活,这才是实实在在的东西,比如我们会说头条日活几亿,但是从来不会说头条的CTR多少。
我们推荐天然存在短期目标(CTR,时长)与长期目标(日活,总时长)之间的差异,甚至如果你把日活做的越低你的CTR和时长就越高。当然项目要是做成这样,你人就没了。
5:不同业务不同的思考
内容推荐业务其实也分很多种,除了最常见的信息流,新闻,和短视频之外,还有小说,长视频等。比如对小说来说,你可能要想明白:一个人一年可以看几部小说,这和信息流是完全不一样的。还有新闻类的推荐,这种推荐场景的内容时效性比较高,怎么能加速从文章冷启到正常分发的流程。
总结
以上就是我关于推荐的一些思考和收获,很多内容其实也仅限于与思考,有些内容也是我之后需要思考的。作为一个面向业务的算法工程师,我领导也经常和我们说,做推荐第一步的是认知观,只有当你真的很了解自己需要做什么的时候才会有更多的方法去实现。否则陷入了算法的陷阱疯狂优化,最后对于OKR毫无益处(对个人还是有很大益处的)。欢迎大家各路推荐的大佬萌新添加我微信加入推荐群一起交流学习。


原文作者:ChallengeHub;如有侵权,请联系管理员删除。