时间: 2021-08-03 08:30:07 人气: 10 评论: 0
编辑导读：为什么短视频如此让人上瘾？其中很大一部分原因是实时推荐的功劳。通过消费用户在最近的几分钟内或者一段时间内浏览的内容偏好，形成对该用户的一个短暂的认知，再通过这个认知赶紧去内容池中找到对应的内容推荐给用户。然而，这个功能在长视频领域中却屡屡碰壁，这是为什么呢？
高实时推荐一般在短视频领域使用比较广泛，指的是算法模型通过消费用户在最近的几分钟内或者一段时间内浏览的内容偏好，形成对该用户的一个短暂的认知，再通过这个认知赶紧去内容池中找到对应的内容推荐给用户。这个系统反馈的时间也许是我上面提到的几分钟，或者是几十秒。
而与之对应的就是T+1的更新，T+1更新其实就是前一天推荐系统根据用户历史行为为每一个用户计算好了一个推荐队列放着，当用户开机后，客户端主动去请求这部分数据，将内容推给用户。这部分数据一天内都是不**更新的。
在项目实现过程中，我们发现高实时推荐的CTR较T+1推荐CTR提升很多，于是大家开始庆祝，这个项目有效果，CTR提升很多！
但是，当我们深入去想的话，在很高的CTR背后，是用户在干什么呢？试想一下，假如他找到了自己的喜欢的电影，安安静静坐那儿看了，用户还需要不断地**新页面，让客户端不断去请求算法，算法再去执行召回-排序-去重-打散等等策略，占用服务器性能去为用户推送内容，然后用户不厌其烦点击，返回，点击，返回。
高实时只不过将这一历程从原来T+1更新的N天变成了N分钟。
高CTR在这里，就似乎成了一个应试指标。成了像是一种政治正确的产物，是推荐系统对结果的不自信产生的一个额外的替补策略，但他又是必要的—为了项目最终数据效果好看，我们编制了一个美丽的谎言。为什么说是美丽的谎言呢？
和短视频不一样的是，用户决定是否看一部电影和决定是不是看一个短视频的路径是不一样的。短视频中，用户决定看或者不看，根据抖音短视频的一份报告，决策点通常在第5秒，用户通过判断前5秒的信息而决定手指是不是要向上滑动，对于推荐系统来说，去尝试实验的成本是低廉的，用户决策的成本也十分低廉，于是，推荐算法完全可以指定feed流的**新机制设置在用户决定了看了几部视频、 跳过了几部视频之后，甚至，我们可以设定给不同的模型的用户以不同的**新机制–有的用户兴趣较多且随时间、环境、热点事件变动，有的用户兴趣单一受时间影响较少，这就对推荐模型和策略产品经理有了更高的要求了。
而用户要看一部长视频，不论是电视剧，还是电影，还是综艺，他们的决策路径可能是这样的，要先了解，再查看，有可能再试看，或者搜索一下。用户总面对自己即将付出可预见时间代价的事情的决策路径，一般呈现线性函数递增关系，即预期支付成本越高、决策周期越长。以我自己为例，我通常选**的路径-先看看热门影**top榜单有没有自己喜欢的，在看看新**电影有没有喜欢的，最后实在没有再去看看分类入口找找有没有。
这样来看的话，高实时推荐的CTR的提升似乎是必然的结果，为什么这么说？
CTR的计算方式是点击/曝光，T+1频次的曝光和高实时的曝光场景下每个内容平均曝光次数为N1和N2，而T+1时间内某个页面的内容曝光总次数为M，曝光总内容数为X，我们假设用户对某一个内容点击每次曝光时概率不变，为Z，这大概率也是不**变的。
CTR=N*X*Z/M，有了这些变量之后因素影响之后，我们再去看看用户看每个页面的停留时间。假设用户在页面停留时间一致，这大概率也是一致的，即整个页面内容曝光的总次数M不变，平均每个内容每次曝光被点击的概率Z不变，变动的只有N和X。
这样看来，用户在原有推荐逻辑较低的CTR可能只是被强行浏览了自己不想要看到的内容而且不能**新只能反复上下操作遥控器找**，单影**曝光次数N值增加了，这样的无效曝光被系统抓取，而高CTR可能是用户发现了内容可以**新之后，就在这样的一个页面开始了找**之旅，曝光的内容基数变大了，但内容平均曝光次数降为了1。
原来推荐20个内容可能只能有2个内容是用户愿意点击的，但这20个内容确因为**新机制同样获取M次数的曝光，确只获取了2个点击；而高实时推荐确在M次数的曝光前提下，为用户推荐了60个内容，其中确有6个内容是用户愿意点击的。
堆内容数量？这是推荐系统最擅长的事情，推荐系统利用高实时的优势，在单位时间内为用户推荐了多倍于X1场景的内容数，其实每次**新召回的内容用户感兴趣的还是那么多，这么来看的话，CTR自然而然**升高了。
简而言之，就是我们在有限的曝光次数里，推了更多的内容给用户，将那些无效的曝光分给了更多的内容，这才使得CTR提高了。但其实我们推送单位数量内容的有效内容率都是一样的。当然，这也只是我基于计算公式假设得出来的结果，其中设置M不变多少也是不十分科学的，但这样的公式却可以大体说明高实时推荐所带来CTR提升的背后原因是什么。
长视频和短视频最核心的其中一个区别在于内容池数量的问题，短视频领域因为UGC的属性，可以不断生产内容，而长视频没有这个优势，一个大型厂商电影电视剧的内容数量一定是有限的，而且有长尾效应的限制，用户所消费的内容更加少之又少。
高实时推荐更加适用于短视频领域的原因也有其中，场景变化更多的、内容量更多，他保证了一个给一个用推荐的内容永远不**高度重复，可以为他们在公车上看跑车、厕所里看段子、家里看小姐姐、公司摸鱼时看学习小课堂的适配更多场景。
而长视频，更多的观影场景比较单一，要么在家和家人看剧，要么假期自己一个人好好看部电影，如果在单位时间为用户消耗了太多的内容，用户选得**花缭乱，那推荐系统可用的内容资产将**逐渐变少，快速实现了遍历，到山穷水尽之时，用户**说，你怎么每天给我推同样的内容？我不需要。当这个情况发生，我们又如何去做呢？
所以，或许我们在长视频推荐实现时，也得去考量一下我们有多少东西可以推给用户，让决策变得更加审慎、更加精细一点，而不是粗暴堆砌性能，满足用户一时的选**之欢，而消耗了自己未来的将要给用户的资产吧。
高实时推荐只不过是我们将用户选**的场景从分类tab搬到了首页推荐上，把本属于分类TAB的点击给了首页推荐，把本该属于单个内容的重复曝光均摊给了推荐队列里的每个内容，从而夹带私活。推荐系统干了自己擅长的事情获得了CTR的替身，皆大欢喜。但似乎，推荐系统尝试去解决的在准确性的问题，也许始终没有解决吧。
假如要我去衡量推荐算法在长视频领域的优劣程度，可能**说：每个用户的终端曝光多少部电影后，用户做了进入观影的决定。推荐算法或者人工运营，需要去解决的可能更多的是去帮助用户缩短决策路径，是让用户在有限的开机几分钟内的时间里、或者某个周末找**的过程中，更快更好地找到自己想看的**，然后舒舒服服的看一部电影，顺便提高****的付费比例。
影响内容CTR的因素有很多，但内容的基本面永远是核心要素 ，在长视频推荐领域，无限制的实时动态**新，或者单纯千篇一律的一天硬推一部分内容，或许都是不可行的。前者只不过是用算法的优势帮助了用户获得了本不该属于他的CTR，而后者确需要很精准的策略才能替身CTR，同时，我们还要去考量诸如内容遍历、内容召回率等等问题，综合看，我们要去做什么呢，能做什么呢，或者不该做什么呢？
这其中的中和之道，也只能由策略产品经理和算法工程师一步步去探索了。
本文由 @汪仔0741 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
