Feed推荐引擎动态融合、规划、编排是怎样的

Feed推荐引擎动态融合、规划、编排是怎样的，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

目前市面上看到的Feed流推荐引擎，应用到了的场景比较单一，除了资讯、内容的推荐，也就差不多就是好友推荐了。

虽然，实现的方式不尽相同，总体上可以分为3类模型：

1.推模式

不同于常规意义的推送，这里侧重于 “推到一个地方”，存储或缓存。比如给每个人维护一个推荐列表，以增加写扩散的复杂度，降低读扩散的成本，读取feed流的性能很突出。存在的问题就是，在写入推荐列表时的性能、存储压力，以及信息的及时性。

2.拉模式

需要数据的时候，主动去拉取数据。近线查询的方式，保证了数据的及时性，降低了存储压力。按需加载，使用的时候才去拉取，服务性价比高。换来的代价就是，服务端进行复杂场景数据的召回、聚合、编排的压力。没有很好的缓存场景，尤其是在海量请求下，服务的响应能力简直亚历山大。

3.推拉混合

等同于结合推、拉模式各自的优点，对业务场景进行最优的场景化适配，以控制的复杂度来换取服务性能的一个平衡。

自从头条系的产品矩阵，加速了Feed流的算法推荐进程以后。不管是今日头条的资讯类产品，还是诸如Echo这样的社交产品，在面对极度的信息大爆炸和用户时间碎片化问题上，偏向于算法驱动的推荐引擎。

既然是推荐系统，那么作为 “饲料、饲养” 的feed都有哪些呢？

1.日常短语

日常短语，泛指那些少量文字，混合资源内容的形式。如微博、朋友圈、Twitter、说说等形式。

2.文章、资讯

这个最常见的，如文章、新闻资讯等。一般形式由标题、内容构成，内容是一个富文本的，混合着图、文、资源的大量内容主体。

3.短视频

想了想还是把短视频单独抽取出来了，短视频赛道随着抖音、快手的覆盖，独当一面。作为一种轻流媒体形式，越来越重要。

4.泛资源内容

可以说除了文字以外，都属于资源内容范畴，如动图、音频、视频、文件等。这个分类并不是独立存在的，经常是混合着前几类大量存在。独立这个分类的最主要原因是，很多时候如果只有资源内容，对于推荐系统就是一个巨大的挑战。牵扯到了另一领域，对于资源文件的内容识别。

由于feed流没有固定的分页概念，但是可以采用弱化的分页方式。
简化版可以进行两段式分隔：首页、其它页。

第1页：固定位置、或重要的数据、或banner位、热门榜单等（如某要闻始终占第一位）。

第2页（及以后所有页）：可以根据用户相关性进行推荐、以及随机性的页数内容推荐、更加丰富的多样性尝试。这样处理过度也比较自然，兼容冷启动。

由于信息流推荐的结果，不同于一般的分页查询，具有数据多样性。并不能保证看到结果的一致性，比较抽象（由于朋友圈的惯性思维，你总需要不断解释为什么看不到xx数据）。

尤其是，对于丰富的feed内容进行编排序，同类型数据的打散、首页特殊处理、数据穿插等等，头疼的事情总是不厌其烦。

这个时候，就需要一个可视化模型，来验证和调试推荐的结果展示。

#召回候选数据集的编排序：

• 第一段：用于强制的优先级，如业务或特殊要求；

• 第二段：用于真正意义上的进行动态规划、动态编排序；

• 第三段：主要用于数据后补，防止召回数据不足时进行试错带来的内耗。

建议采用这种三段式的编排结构，来满足复杂场景的编排诉求。

#基于业务场景的数据融合方案

根据具体的场景化数据形态，进行最优的数据库选型，实现多数据源融合方案。

#推荐系统的可解释性：

• 每一页的推荐模型数据形态分布图，代表了每次推荐的解释形态；

• 左侧类别，属于召回的数据集分类（因子库），每页保证不少于3个因子；

• 右侧色块，表示召回的数据编排序（编排、穿插、离散）后的，子类型的时序。

看完上述内容，你们掌握Feed推荐引擎动态融合、规划、编排是怎样的的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！