数据挖掘-推荐系统

推荐系统 

动机

● 在线世界：信息和项目过载

    ■ 太多的项目：产品、歌曲、电影、新闻文章、餐厅等。

    ■ 更多的选择需要更好的过滤器 ➜ 推荐引擎

用户的观点	提供者的观点
● 识别相关项目   ● 最小化努力 （为了找到相关的项目） ● 最大化满足度 ● 优化资金和注意力的花费	● 最大化销售/交易 ● 最大化用户参与度 （例如，为了最大化广告收入） ● 获得竞争优势

编辑推荐

● 由“专家”推荐

    ■ 专家 = 对某个项目有专业知识的人 （例如，电影或餐厅评论家、员工作家、记者）

    ■ 客观、详尽、可信、有信誉 （至少在理想的世界中是这样...）

    ■ 写编辑推荐通常是有报酬的工作

同伴推荐

● 由普通用户推荐

    ■ 在线口碑推荐 （然而，用户通常是陌生人）

    ■ 在购物/预订网站上常见的功能

    ■ 通常是主观的、简短的、有偏见的

    ■ 每个项目的许多评论形成了平均观点 但再次代表了信息过载。

手工推荐 — 优点 & 缺点

● 优点

    ■ 语义丰富（评分、纯文本、图片、视频等）

    ■ 可解释性 / 可解读性

● 缺点

    ■ 手工努力 — 写评论的动机是什么？

    ■ 缺乏个性化

幼稚/替代方法

推荐简单汇总

IMDB 最佳250部电影

● 根据汇总分数对项目进行排名

简单汇总 — 优点 & 缺点

● 优点

    ■ 相对容易计算（通常基于不同因素进行加权汇总）

    ■ 通常是好的/安全的推荐（特别是对于新的/未知的用户）

● 缺点

    ■ 需要每个项目有足够数量的评分

    ■ 高风险的受欢迎偏见；缺乏多样性 （"富者更富"效应，"少数变富"效应）

    ■ 缺乏个性化

个性化推荐

● 用户有不同的偏好，这决定了项目的相关性

    ■ 偏好 = 兴趣、喜好、需求、想要、欲望等

    ■ 相关项目 = 最符合用户偏好的项目

● 基本设置

    ■ 用户集合 U={u1,u2,…,un}

    ■ 项目集合 V={v1,v2,…,vm}

    ■ 评分矩阵 R 有 |U| 行和 |V| 列

    ■ 矩阵元素 Ruv​：u 对 v 的评分 （例如，1-5 星，二进制 0/1）

个性化推荐 — 核心任务

1. 收集评分 Ruv​

2. 推断缺失值 ​

  ● 实际上，主要对高值感兴趣

  ● 推荐系统的算法组件

  ● 有各种现有的方法

3. 评估：推荐有多好？

  ● 将 ​ 与测试集中的真实 Ruv​ 进行比较

收集评分

● 显式

    ■ 请/邀请/鼓励用户评价项目

    ■ 付费给用户评价项目（例如，众包）

● 隐式 — 从用户行为中推断评分，例如：➜ 高评分 （但如何获得低评分？）

    ■ 购买的产品

    ■ 观看的视频

    ■ 阅读的文章

    ■ 点击的链接

    ■ ... 

关键挑战：实际中的评分矩阵 R 非常稀疏！

评估

● 将 R 分为训练集和测试集

● 性能指标

    ■ 均方根误差（用于数值评分）

    ■ 精确度、召回率、F1得分等 （对于二进制评分或在转换数值评分后的二进制推荐的 TP, TN, FP, FN）

    ■ 精确度@k, 召回率@k （关于前 k 个最高预测评分的精确度和召回率）

    ■ 通过和 与  之比较排名 （还要考虑前 k 个最高评分的顺序）

使用关联规则的推荐

● 用户偏好和喜好

    ■ 项目：电影、歌曲、书籍等

    ■ 交易：观看/听/阅读历史

● 有趣的规则（电影）：

    ■ 观众观看了电影 {a, b} 也观看了电影 {x, y}

    ■ 例子：{大白鲨} ➜ {它}

● 限制

    ■ 基本的AR算法忽略了评分

    ■ 受欢迎的偏见：具有非常独特口味的用户 可能会得到不佳的推荐

使用聚类的推荐

● 方法

    ■ 根据"有用"的特征对电影进行聚类 （类型、导演、编剧、长度...）

    ■ 推荐用户评价高的电影所在的聚类中的电影

● 限制

    ■ 在实践中找到好的特征 非常困难（我们会回到这一点）

    ■ 不系统：没有明确定义的 选择推荐的过程

使用回归（或分类）的推荐

● 示例方法：线性回归

    ■ 自变量：电影特征

    ■ 因变量：用户评分

● 限制

    ■ 每个项目都需要好的特征

    ■ 冷启动问题：需要大量的 用户评分来建立一个好的模型

基于内容的推荐系统

两两项之间的相似性

● 直觉

    ■ 向用户 u 推荐与 v 相似且 u 评价很高的项目 v

    ■ 例子：同一类型的电影，同一艺术家的歌曲， 关于同一主题的文章，具有相似特征的产品等。

● 基本要求：项目概况 = 每个项目的特征向量，例如：

    ■ 电影：类型、导演、编剧、演员、长度、年份...

    ■ 产品：类型、品牌、价格、重量、颜色...

    ■ 文章：一组（重要的）

运行示例

● MovieLens 数据集

    ■ 项目：不同类型的电影

    ■ 特征：20种类型（包括“未分类”）

    ■ 评分：1-5 星（包括半星）

● "小"数据集的数字

    ■ 610 个用户，9,742 部电影

    ■ 大约100k的评分 ➜ 稀疏度：约1.7% 简单方法 — 两两项目相似性

● 两两项目相似性 sim(x,y)

    ■ x, y — 电影的特征向量

    ■ 常见的度量：余弦相似度  

● 限制：需要参考项目，例如：

    ■ 用户最近在观看的电影

    ■ 用户评价最高的电影

    ■ 用户当前正在浏览的电影

用户-项目相似性 

● 需要：用户概况 = 每个用户的特征向量

    ■ 要求：与项目概况形状相同，以计算相似性

    ■ 方法：用户概况 = 用户评价的项目概况上的"某种汇总"

项目相似性 - 二进制效用矩阵 

● — 例如， 如果

    ■ 用户 u 购买了电影 v

    ■ 用户 u 观看了电影 v 

暗示 u 喜欢 v（这里没有明确的评分可用；但也没有暗示的不喜欢！）

● 简单平均

用户-项目相似性 — 实值效用矩阵 

● — 例如， 星级评分

    ■ 用户 u 对电影 v 的明确评价

    ■ 重要：语义解释 — 评分既表示喜好也表示不喜欢（尽管所有评分都是正面的）

    ■ 使用评分作为权重为特征进行加权汇总

直觉

● 用户喜欢浪漫 和动画电影

● 用户不喜欢幻想 和冒险电影

用户-项目相似性 — 实值效用矩阵

● 第一步：标准化评分

    ■ 从每部电影的评分中减去平均用户评分

    ■ 将评分转化为正面（喜欢）和负面（不喜欢）的尺度

    ■ 区分"慷慨"的用户（大多数评分很高，3.0是低评分） 和更"暴躁"的用户（大多数评分低，3.0是高评分） 第二步：为用户概况计算加权特征

    ■ 权重是标准化权重

第二步：为用户概况计算加权特征

    ■ 权重是标准化权重

用户-项目相似性

● 两两项目相似性 sim(u,v)

    ■ u — 用户概况；v — 项目概况

    ■ 合适的度量标准：余弦相似性（注意用户和项目概况可以有不同的大小）

➜ 推荐最大相似性 sim(u,vi) 的项目 vi 给用户 u

● 实际考虑

    ■ 最相似的前 k 个项目总是相同的 ➜ 添加一些随机性以增加多样性 （如果用户评价更多项目，最相似的前 k 个项目集可能随时间变化）

    ■ 最相似的前 k 个项目可能包括用户已经评价过的项目 ➜ 移除这些项目 （实际中，推荐已知项目并不少见 — 例如，YouTube 推荐）

    ■ 可以设想更复杂的方法将项目概况聚合到用户概况 （例如：忽略代表性不足的特征，例如如果用户只评价了一部喜剧电影）

基于内容的推荐系统 — 优点 & 缺点

● 优点

    ■ 用户 u 的推荐不依赖于其他用户 （这也允许为具有非常独特口味的用户提供好的推荐）

    ■ 推荐还可以包括新的或不受欢迎的项目（即，没有或很少的评分）

    ■ 良好的可解释性（对高相似性影响最大的特征）

● 缺点

    ■ 冷启动问题：如何为新用户建立概况？ （天真的方法：向新用户推荐普遍受欢迎的项目）

    ■ 找到项目的好特征（和值！）是一个非琐碎的任务 （问题：电影类型是一个好的特征集吗？）

    ■ 过度专业化：默认情况下，用户概况之外没有推荐 （实践中：在推荐过程中加入一些随机性）

协同过滤

● 思路：利用他人的意见

    ■ 推荐其他具有相似口味/偏好/需求的用户喜欢的项目

    ■ 不需要项目或用户特定的特征

● 两个视角

    ■ 基于用户 — 如果两个用户对相同的项目评价相似，则它们是相似的

    ■ 基于项目 — 如果两个项目被用户等同评价，则它们是相似的

基于用户的 CF — 计算相似性

● 例子：电影评分

    ■ Bob 可能会 喜欢电影 "Heat" 吗？

● 根据数据集的直觉

    ■ Alice 和 Bob 有相似的口味，所以 Bob 可能会给 "Heat" 一个和 Alice 相似的评分

    ■ Claire 和 Bob 有相似的口味，但 Claire 没有评价 "Heat"

    ■ Dave 和 Bob 的口味非常不同，所以 Dave 对 "Heat" 的意见不重要 （如果有的话，它应该是一个指示器，表示 Bob 会喜欢 "Heat"；通常在实践中不相关） 

● 用 他们的评分向量 v 表示所有用户

    ■ 评分矩阵的行

问题

    ■ 缺失值（0）被视为负面

    ■ 所有评分都是正值 ➜ 没有明确的不相似概念 (只是更少或更多的相似)

● 想法：标准化评分向量

    ■ 均值居中 — 从每个评分向量中减去行均值

    ■ 缺失值（0）现在表示平均评分

    ■ 差评（即，低于平均值）现在由负值表示

余弦相似性和皮尔逊相关系数都是衡量两个向量之间相似性的方法。当这两个向量表示评分或偏好时，它们可以在推荐系统中用来找到相似的用户或项目。

基于用户的 CF — 预测评分

●  = 来自相似用户的评分的加权平均值 

    ■ N — 已经评价项目 v 且与 u 最相似的 k 个用户的集合

基于项目的 CF

● 与基于用户的方法类似

    ■ 对于一个项目 v，找到最相似的项目 （如果两个项目在所有用户中的评分相似，则它们是相似的）

    ■ ​ = 相似项目的评分的加权平均值

    ■ M — 已经被 u 评价且与 v 最相似的 k 个项目的集合

注意：回想一下，在基于内容的推荐系统中，衡量 项目之间的相似性依赖于项目概况/特征向量。在 项目-项目 CF 的情况下，一个项目的评分向量代表了它的概况。

基于项目的 CF — 示例

计算均值居中的评分向量 （这里：评分矩阵的列）

计算 "Heat" 与 Bob 已经评价的所有其他电影之间的距离

协同过滤 — 基于用户 vs. 基于项目

● 理论上：基于用户和基于项目是双重方法

● 实际上：基于项目的通常优于基于用户的 ➜ 项目-项目相似性通常更有意义

    ■ 项目比用户"简单"

    ■ 项目可以更容易地被描述

    ■ 用户可以有非常多样化的口味  

基于模型的协同过滤

● 潜在因子模型

    ■ 潜在表示：每个用户 u 和项目 v 的 k 维向量

    ■ 从数据中学习潜在表示 （与基于内容的系统不同，其中特征向量是构建的）

    ■ 估计未知评分 

● 方法：矩阵分解 ➜ 找到 W, H 使得 R = WH

    ■ 将所有用户向量放入矩阵 W

    ■ 将所有项目向量放入矩阵 H

矩阵分解 — 基本设置

● 给定：评分矩阵 R

    ■ m — 用户数 |W|

    ■ n — 项目数 |H|

● 超参数 k

    ■ 潜在表示的大小

找到矩阵 W, H

● 最小化损失函数

● 使用梯度下降 

Input: rating matrix R^(m*n), latent vector size k, #iteration T

Initialization: W^(m*k),H^(k*n) with values 0..1

for 1 to T

for all u,v with R_{uv}>0

return W,H

找到矩阵 W, H- 示例

● 正则化的效果

    ■ 增加 𝜆：已知评分的拟合度较差，所有评分的"平滑"值

    ■ 减少 𝜆：已知评分的拟合度较好，未知评分的值更"极端"

协同过滤 — 优点 & 缺点

● 优点

    ■ 无需找到并创建好的特征 （例如电影的类型）

    ■ 直观的方法

● 缺点

    ■ 相似度计算依赖于足够数量的评分

    ■ 新用户或项目的冷启动问题

    ■ 受欢迎的偏见：具有非常独特口味的用户可能会得到次优的推荐 （因为即使是 k 个最相似的用户也不会真的非常相似）

    ■ 朴素实现非常昂贵：找到 k 个最相似的用户/项目 ∈ O(|R|) （需要优化技术：例如用户/项目的聚类以限制搜索空间）

推荐系统 — 总结 

(过度)个性化的危险

● 2 个臭名昭著的副作用 （特别是在推荐新闻或社交媒体帖子时）

    ■ 过滤泡泡

    ■ 回音室效应

● 核心问题

    ■ 服务提供商没有动机 确保（足够的）多样性

    ■ 用户不知道显示了哪些内容 以及为什么（或为什么不）

总结

● 推荐系统

    ■ 更具体地说：个性化推荐系统

    ■ 许多在线平台的组成部分

    ■ 用户：找到相关项目 + 提供商：展示相关项目

    ■ 但是：过度个性化推荐的风险

● 实施推荐系统

    ■ 广泛的数据挖掘技术都适用

    ■ 没有“一刀切”的解决方案

    ■ 在实践中，混合方法最为成功