优雅地实现实时“看过不再推荐”

​ 在阿里云推荐引擎的系统设置里，在线api获取推荐结果（以下简称api）和实时算法是相互并列而又可以交互的两条线。

​ 就“并列”而言，是因为api是由后端系统在用户进入一个需要展现推荐列表的前端页面时进行调用，而实时算法是由客户定义的用户所有有意义行为（包括进入推荐页面）、也即日志触发，一般来说用户的行为日志量会远大于api请求量。从系统设置上来说，可以看到在线api的组成算法和实时算法处于两个不同的配置页。

​ 而之所以说“可以交互”，是由于用户的实时行为日志可以有效地指导api进行调整，从系统设置上来说，就是通过在线数据共享读写完成。这里举两个小例子：

​ 1）一个在线购物网站，假设推荐引擎通过离线建模，已了解到用户的兴趣集中在男装、电子产品、运动用品三个类目，而这时候实时行为告诉我们当前用户正在大量浏览运动器械，那么推荐系统就可以有导向性地将推荐结果中隶属于运动用品的项目在展现位中适当提前。

​ 2）一个在线短视频app，业务规则告诉我们客户基本不会看相同的视频两次及以上，而实时行为告诉我们该用户当前已经看过视频a，那么推荐系统就需要及时地在推荐结果中把视频a去掉，以免造成重要资源位的闲置和浪费。

​ 本文将通过一个例子指导您“优雅地”实现“看过不再推荐”的业务逻辑。

​ 请注意以上两段代码中getkey和str2arr方法的一致性。

​ 之所以本文标题修饰以“优雅”二字，作者私认为是由于上面的做法实现了api请求和实时日志两条线的解耦，二者分工更加明确，实时日志为api提供资源，api一端读取资源并决定最终的推荐逻辑，业务逻辑更加清晰。

​ 作者在分析一些已有客户提交的代码时发现，有一些做法是简单地从用户的个性化推荐结果中进行实时过滤，实现上来说就是在实时修正算法中直接修改用户的个性化结果。这个做法的一个比较明显的缺陷在于，实际应用中决定最终给用户展现哪些推荐结果的逻辑可能是非常复杂的，除了个性化结果外，可能还会有一些半个性化结果（如针对用户标签的推荐）、运营规则（如人工强制置顶）、各种抄底策略（即用户无个性化推荐结果的情况下展现一些非个性化推荐，比如topn规则），那么按照以上做法势必会导致过滤不完全的情况存在。