你以为的推荐系统，其实只是推荐模型

作者｜Even Oldridge、Karl Byleen-Higley
翻译｜胡燕君

构建推荐系统最大的入门难点之一是理解推荐系统如何在实际中应用。

目前，关于推荐系统的网络资料大部分关注的是推荐模型本身，而且仅限于介绍一些简单的协同过滤（Collaborative Filtering）模型。对新手来说，只了解简单的推荐模型并不足以让他们构建出一个真正能在实际生产中使用的推荐系统。

无论是简单的协同过滤模型，还是DLRM等深度学习模型，推荐模型的作用都是对用户可能感兴趣的内容进行排序（Ranking），更准确地说，是评分（Scoring）。但在现实场景中，光有评分并不足以实现良好的推荐效果。

本文将结合Meta、Netflix和Pinterest等公司的实例介绍一种构建推荐系统的主流模式。NVIDIA Merlin团队认为，这种模式是构建端到端推荐系统的核心，并希望通过介绍这种模式，帮助你理解推荐系统（而不仅仅是推荐模型）如何应用在实际生产中。

两阶段推荐系统：检索和评分

待推荐条目（items）越多，往往就会带来问题。待推荐目录中的内容可达几百万项甚至数十亿项，这时，针对每位用户的喜好对每项内容进行评分并不现实。评分需要消耗巨大的算力。在实际操作中，系统通常只会从所有条目中快速选一个与用户喜好相关的子集，给其中的1000或10,000项条目评分。

因此，推荐系统可分为两个阶段。在我们对条目进行评分之前，我们需要选择一个合理的相关合集，其中包含用户最终将接触到的条目，这个阶段叫候选检索阶段（也叫候选生成），即选出用户有可能感兴趣的条目集。候选检索模型有多种，包括矩阵分解模型（Matrix Factorization）、双塔模型（Two-Tower）、线性模型、近似最近邻模型（Approximate Nearest Neighbor）和图遍历模型（Graph Traversal）。它们的计算效率通常都比评分模型高得多。

2016年，Google发表了一篇关于YouTube推荐系统的论文（https://static.googleusercont...），这是有关候选检索架构最早的公开文献之一，这个方法如今已被行业广泛应用。Eugene Yan对此也写过一篇优秀的文章（https://eugeneyan.com/writing...），他将推荐系统分为两个阶段（即候选检索和评分），我们在此基础上获得启发，并将其细化为四个阶段（下文将详述）。

值得一提的是，在同一推荐系统中使用多种候选来源也是一种常见做法，这样可以确保对用户展现更多样的候选条目，在此先按下不提。

过滤阶段的必要性

虽然候选检索和评分这两个阶段看似足以应付大规模推荐任务，但推荐系统还需支持另外一些限制条件。因为大多数情况下，总有一些你不希望展现给用户的内容，例如缺货的商品、不适合用户年龄层的内容、用户已看过的内容和用户所在国家未许可上线的内容等。

与其让评分或检索模型来推理上述业务逻辑，以避开不能推荐的内容，不如直接为推荐系统增加“过滤”（Filtering）阶段。

过滤阶段通常紧随检索阶段之后，也可以与检索阶段结合（过滤阶段最复杂的问题是确保检索之后有足量的候选条目），有时甚至可以在评分阶段结束后再过滤。通过过滤可以实现模型本身难以执行的业务逻辑规则。有时，实行过滤只需简单的排除查询，有时则更复杂，例如用Bloom Filter筛掉用户接触过的内容。

排序阶段：Ranking or Ordering？

目前我们已介绍了三个阶段：候选检索、过滤和评分。经过这三个阶段，系统已选出相关推荐内容并一一评分。每项条目的分数代表评分系统估计的用户感兴趣程度。

推荐内容通常以列表形式向用户呈现，这就带来一个有趣的难题：最理想的推荐列表不能局限于系统的评分，还要保证一定的多样性，为用户展示一些他们平常不会接触的内容，帮助他们探索未知领域，避免陷入信息茧房。

部分文献会把推荐系统的评分阶段称为“排名（Ranking）”，但给用户的推荐列表中的最终排名（或位置）很少会直接对齐模型输出的结果（译注：比如推荐列表中排在末尾的内容通常不是被模型评分最低的内容）。而通过提供一个显式的“排序（Ordering）”阶段，我们能将推荐模型的评分和其他业务需求的限制条件进行对齐。