推荐系统的美好世界

CDA数据分析师 出品

我们为什么要关心推荐系统?

对于大多数人来说,关注推荐系统的关键原因可能是金钱。对于亚马逊,Netflix和Spotify等公司而言,推荐系统可带来巨大的参与度和收入。但这是对事物更加愤世嫉俗的看法。这些公司收入增加的原因是因为它们为客户提供了实际价值 –推荐系统为具有很多项目的场景中的用户提供了一种可扩展的方式来个性化内容。

数据科学家特别应该关注推荐系统的另一个原因是,这是一个真正的数据科学问题。也就是说,至少按照我最喜欢的数据科学定义,即软件工程,机器学习和统计之间的交集。我们将看到,构建成功的推荐系统需要所有这些技能,以及更多。

定义推荐系统

尝试定义任何内容时,合理的第一步是询问Wikipedia。不幸的是,截至本文发布之日,Wikipedia对推荐系统的定义过于狭窄,即“信息过滤系统的子类,旨在预测用户对某项产品的评价或偏好”。

Wikipedia定义的问题在于,推荐系统要比评级预测多得多。首先,推荐者用词不当–称其为发现助手更好,因为所谓的推荐远非束缚。其次,系统意味着诸如表示之类的元素很重要,这是使推荐成为如此有趣的数据科学问题的一部分。

我的定义很简单:

推荐系统是帮助用户发现他们喜欢的物品的系统。

推荐范式

根据要问的人,有两种到二十种不同的推荐范例。通常的分类是根据用于生成建议的数据类型进行的。方法之间的区别是学术性而非实用性的,因为使用混合/集成来解决每种方法的局限性通常是一个好主意。尽管如此,值得讨论不同的范例。我的看法是,如果您忽略了通常会出乎意料地有效的琐碎方法(例如,受欢迎的商品,然后“再次观看”),则有四个主要范例:协同过滤,基于内容的推荐算法和上下文推荐。

协同过滤可能是最著名的推荐方法,以至于有时它被视为该领域的代名词。主要思想是为用户提供了商品的偏好矩阵,这些矩阵可用于预测缺失的偏好并推荐具有较高预测性的商品。这种方法的主要优点之一是,对于协同过滤已有大量研究,使其易于理解,并且现有的库使实现起来相当简单。另一个重要的优点是协同过滤独立于项目属性。您只需要开始使用用户和项目ID,以及用户对项目的偏好(等级,视图等)的概念即可。

协同过滤的主要局限性在于它对首选项的依赖。在完全没有首选项的冷启动方案中,它无法生成任何建议。但是,当有数百万个可用的首选项时,也可能发生冷启动,因为纯协作推荐不适用于没有评分的项目或用户,并且在只有几个评分的情况下执行效果通常很差。此外,当偏好矩阵稀疏时,基础协作模型可能会产生令人失望的结果。实际上,这是我在几乎所有部署协同过滤的情况下的经验。它总是需要进行调整,并且永远不会简单地开箱即用。

基于内容的推荐为用户提供了项的首选项,并根据项内容的特定于域的概念推荐了类似的项。与协同过滤相比,基于内容的推荐的主要优势在于,不需要太多的用户反馈即可开始。甚至一个已知的用户首选项都可以产生许多良好的推荐(这可以导致收集首选项以实现协作推荐)。在许多情况下,基于内容的推荐是最自然的方法。例如,在推荐新闻文章或博客文章时,比较项目的文本内容是很自然的。这种方法也自然地扩展到项目原数据可用的情况(例如,电影明星,图书作者和音乐流派)。

当项目相似性不太容易定义时,就会出现部署基于内容的建议的一个问题。但是,即使自然而然地衡量相似性,基于内容的建议也可能最终过于统一而无用。这样的建议随着时间的流逝也可能过于静态,从而无法适应单个用户喜好的变化以及基础数据的其他变化。

上下文推荐算法推荐与用户当前上下文匹配的项目。与忽略上下文(实质上赋予所有用户历史记录相同的权重)的方法相比,这使它们可以更灵活地适应当前用户的需求。因此,与仅基于历史数据的方法相比,上下文算法更可能引起响应。

上下文推荐者的关键限制与社会和人口推荐者的相似之处–上下文数据可能并不总是可用,并且存在使用户无所适从的风险。例如,广告重新定向可以看作是上下文建议的一种形式,它遵循网络上和跨设备的用户,而无需用户明确同意以这种方式进行跟踪。

关于推荐系统的常识

准确性神话

准确性度量的脱机优化足以创建成功的推荐者

正如Wikipedia对推荐系统的定义所证明的那样,这也许是最普遍的神话。令人惊讶的是它仍然持续存在,因为距McNee等人关于影响力的论文已经有将近十年了,对准确性测量的关注已经对这一领域造成了影响。

因此,有必要问这个神话来自何方。我的理论是,这是学术界和行业之间的反馈回路。在学术界,发布对脱机数据集上的任意精度度量进行无穷改进的论文非常容易,而在实时系统上进行实验则相对困难。但是,业界对离线预测准确性的高度关注是其中一项举措,该举措来自于行业,以100万美元的Netflix奖的形式,其目的是将Netflix评级预测算法的准确性提高10%。

值得注意的是,三年竞赛中产生的大多数算法从未集成到Netflix中。正如Netflix博客上所讨论的:

您可能想知道两年后赢得100万美元奖金的最终特等奖合奏团发生了什么……我们离线评估了一些新方法,但是我们测得的额外精度增益似乎不足以证明将其投入使用所需的工程努力生产环境。

我们的业务目标是最大程度地提高会员满意度和按月保留订阅人数……现在很明显,Netflix奖目标(准确预测电影的收视率)只是有效优化会员的有效推荐系统的众多组成部分之一’ 享受。

下表说明了一切(摘自上面引用的博客文章的第二部分):

出现的一个重要问题是:如果用户真的不关心预测准确性,那么他们关心什么?答案是预测准确性具有一定重要性(如上图所示),但这并不是唯一的事情。我认为,关键的考虑因素是UI / UX。您可以获得世界上最准确的建议,但是如果没有通过友好的界面及时提供建议,那么没人会知道(或关心)这些建议。

当然,即使拥有出色的用户界面和准确的预测,在设计推荐系统时也需要注意其他问题。示例包括多样性(显示各种类型的项目),偶然性/新颖性(显示用户尚未了解的非显而易见的建议)和覆盖范围(能够为所有用户和项目生成建议)。Guy Shani和Asela Gunawardana的出色调查涵盖了许多其他考虑因素。

还要注意的是,通用精度度量存在一个固有的问题。具体而言,当使用均方根误差之类的度量时,可以通过减少低评级的误差来使评级预测算法更好地执行。这是毫无意义的,因为在任何情况下都不会向用户显示低评分的项目。

最后,脱机评估出现的一个关键问题是,脱机数据集中存在一些偏差,这些偏差不一定会延续到联机方案中。例如,在许多情况下,有一个隐含的假设,即数据确实不是随机丢失的,例如,用户花费大量精力观看和评价电影的事实已经告诉我们很多关于他们的偏见对于这部电影(获得Netflix奖的团队利用这种偏见来发挥自己的优势)。隐藏此收视率并尝试对其进行预测与预测从整组电影中随机挑选的电影的收视率不同。

黑匣子神话

您可以构建成功的推荐系统,而不必担心所推荐的内容和建议的提供方式

一个好的推荐系统必须考虑用户如何与推荐进行交互。例如,显示的建议数量应告知优化过程(例如,您的目标是Precision @ 1还是precision @ 10?)。这些建议的布局方式(例如,水平/垂直)往往会影响用户交互。此外,能够解释提出建议的原因也可以轻易获胜。最后,在许多情况下,可用于生成建议的时间量受到限制。

除了UI / UX,好的推荐器系统的设计还必须考虑所推荐的内容。例如,音乐曲目和短视频可以播放多次,因此推荐用户已经看过的项目可能是个好主意。另一方面,诸如洗衣机和汽车之类的物品却很少被消耗。如果用户刚购买了一台洗衣机,他们不太可能很快就想要另一台洗衣机(但他们可能想要烘干机或晾衣绳)。

Hynt是电子商务的推荐系统即服务,我一直负责到去年年中。一般的想法是,商家只需在他们的商店页面上添加几行JavaScript,Hynt就在考虑用户和页面上下文的情况下完成了从商店推荐相关商品的艰苦工作。Hynt上线再次确认了许多著名的UI / UX课程。最为显着地:

  • *高于折痕比低于折痕。*在不滚动的情况下可见的Hynt小部件的参与度高于页面上较低的参与度。
  • *更多的建议胜于少数。*Hynt小部件具有响应能力,可以适应放置在其中的容器的大小。在显示更多建议时,参与的可能性更大,因为用户更可能无需滚动小部件就能找到自己喜欢的东西。
  • *快总比慢好。*如果建议的加载速度更快,就会有更多的人看到它们,从而增加了参与度。在Hynt的情况下,速度特别重要,因为在宿主页面完成加载后,窗口小部件将异步加载。

另一个重要的UI / UX元素是解释。在建议旁边显示合理的解释可以产生奇迹,而无需对基础建议算法进行任何更改。Nava Tintarev和Judith Masthoff对解释的影响进行了广泛的研究。他们已经确定了七个不同的解释目标,下表总结了这些目标)。

解释在现实世界的推荐系统中无处不在。例如,亚马逊使用“经常一起购买”和“购买此商品的顾客也购买”之类的解释,而Netflix提供了不同的推荐列表,其中每个列表都是由不同的原因决定的。

解决问题的神话

推荐系统的空间已被详尽探索

大约三年前,当我完成博士学位时,我加入了一家名为Giveable的小型创业公司作为第一名员工(基本上是创始人团队的一部分,该创始人是原始创始人Adam Neumann毕业于AngelCube并筹集了一些种子资金)。Giveable的原始产品是一个webapp,用户可以在其中连接其Facebook帐户并为他们的朋友找到礼物。

当时,关于礼物推荐的研究还很少,关于使用喜欢的页面为Facebook朋友推荐礼物的具体问题也几乎没有。以下是此问题与经典推荐方案不同的一些方法。

  • *需要考虑给予者和接受者。*与传统方案不同,推荐项不会被显示给他们的用户消费。在实践中,这意味着我们必须要考虑到赠与被赠者之间的关系。例如,妈妈可能给您的礼物类型与伴侣可能给您的礼物不同。
  • *点赞是历史性的,稀疏的,而且常常是荒谬的。*最好用一个例子来说明:喜欢一个页面,例如澳大利亚历史上的Tony Abbott –最差的PM,告诉我们用户可能喜欢的礼物吗?托尼·阿伯特(Tony Abbott)不再是总理,这是有历史意义的,尽管此页面非常受欢迎,但还有很多其他页面难以解释,只有少数人喜欢它。
  • *点赞不推荐的项目。*如上面的示例所示,仅仅因为您喜欢Tony,并不能完全带来有用的礼物。即使有与兴趣更相关的事物(例如作者和乐队),也不推荐将喜欢的页面作为礼物。
  • *点赞并不总是可以离线使用。*这是一个重要的工程考虑:从新用户授予我们查看他们的喜欢和朋友喜欢的角度出发,我们没有太多时间来生成建议。理想情况下,从我们从Facebook获得所有数据开始,推荐生成将花费不到一秒钟的时间。这严重限制了我们可以使用的算法类型。

有效解决Giveable建议问题的关键是尽可能多地进行离线处理。特别:

  • 使用潜在Dirichlet分配(可以视为协作过滤技术)推断出相似的页面。这样就可以使用未直接链接到礼品产品的页面上的信息,例如,在上述Tony Abbott的示例中,不喜欢他的人可能会左倾,这意味着很多其他利益。
  • Facebook页面与具有启发式Mechanical Turk机器学习功能的优秀产品相匹配。这从本质上是部分手动的半监督学习中进行了几次迭代,在此过程中,我们通过试探法和手动标记获得了高可信度匹配,然后使用它来训练用于对不确定性匹配进行分类的分类器。然后通过手动标记子样本来验证保留集上的分类结果。
  • 我们使用来自Freebase知识图中的结构化信息丰富了页面和产品数据。这使我们能够轻松地将礼品产品与喜欢的页面进行匹配,例如将图书与作者进行匹配。

在线部分包括获取接收者的喜欢页面,推断相似页面的喜欢程度,以及将所有这些页面匹配到优等产品推荐的排名和多样化列表。这些建议附带说明,在这种情况下,说明非常重要,因为送礼物的人必须知道为什么要送礼物。

总之,推荐者与数据科学一样模糊。就像数据科学一样,推荐系统的边界很难定义,有时会被过度宣传。这种炒作可能导致人们在他们真正不需要的推荐系统上进行投资,就像数据科学中过早投资的常见问题一样。但是,炒作是基于真实价值,如果正确使用推荐系统,这些肯定可以实现。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SQLAlchemy 是一个 SQL 工具包和对象关系映射(ORM)库,用于 Python 编程语言。它提供了一个高级的 SQL 工具和对象关系映射工具,允许开发者以 Python 类和对象的形式操作数据库,而无需编写大量的 SQL 语句。SQLAlchemy 建立在 DBAPI 之上,支持多种数据库后端,如 SQLite, MySQL, PostgreSQL 等。 SQLAlchemy 的核心功能: 对象关系映射(ORM): SQLAlchemy 允许开发者使用 Python 类来表示数据库表,使用类的实例表示表中的行。 开发者可以定义类之间的关系(如一对多、多对多),SQLAlchemy 会自动处理这些关系在数据库中的映射。 通过 ORM,开发者可以像操作 Python 对象一样操作数据库,这大大简化了数据库操作的复杂性。 表达式语言: SQLAlchemy 提供了一个丰富的 SQL 表达式语言,允许开发者以 Python 表达式的方式编写复杂的 SQL 查询。 表达式语言提供了对 SQL 语句的灵活控制,同时保持了代码的可读性和可维护性。 数据库引擎和连接池: SQLAlchemy 支持多种数据库后端,并且为每种后端提供了对应的数据库引擎。 它还提供了连接池管理功能,以优化数据库连接的创建、使用和释放。 会话管理: SQLAlchemy 使用会话(Session)来管理对象的持久化状态。 会话提供了一个工作单元(unit of work)和身份映射(identity map)的概念,使得对象的状态管理和查询更加高效。 事件系统: SQLAlchemy 提供了一个事件系统,允许开发者在 ORM 的各个生命周期阶段插入自定义的钩子函数。 这使得开发者可以在对象加载、修改、删除等操作时执行额外的逻辑。
SQLAlchemy 是一个 SQL 工具包和对象关系映射(ORM)库,用于 Python 编程语言。它提供了一个高级的 SQL 工具和对象关系映射工具,允许开发者以 Python 类和对象的形式操作数据库,而无需编写大量的 SQL 语句。SQLAlchemy 建立在 DBAPI 之上,支持多种数据库后端,如 SQLite, MySQL, PostgreSQL 等。 SQLAlchemy 的核心功能: 对象关系映射(ORM): SQLAlchemy 允许开发者使用 Python 类来表示数据库表,使用类的实例表示表中的行。 开发者可以定义类之间的关系(如一对多、多对多),SQLAlchemy 会自动处理这些关系在数据库中的映射。 通过 ORM,开发者可以像操作 Python 对象一样操作数据库,这大大简化了数据库操作的复杂性。 表达式语言: SQLAlchemy 提供了一个丰富的 SQL 表达式语言,允许开发者以 Python 表达式的方式编写复杂的 SQL 查询。 表达式语言提供了对 SQL 语句的灵活控制,同时保持了代码的可读性和可维护性。 数据库引擎和连接池: SQLAlchemy 支持多种数据库后端,并且为每种后端提供了对应的数据库引擎。 它还提供了连接池管理功能,以优化数据库连接的创建、使用和释放。 会话管理: SQLAlchemy 使用会话(Session)来管理对象的持久化状态。 会话提供了一个工作单元(unit of work)和身份映射(identity map)的概念,使得对象的状态管理和查询更加高效。 事件系统: SQLAlchemy 提供了一个事件系统,允许开发者在 ORM 的各个生命周期阶段插入自定义的钩子函数。 这使得开发者可以在对象加载、修改、删除等操作时执行额外的逻辑。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值