社区图书馆的旧登记本上,记着每一位读者的借阅记录。管理员老周有个朴素经验:借过《三体》的读者,十有八九也借过《球状闪电》和《流浪地球》。于是每当有人来借《三体》,老周就顺手从柜台下抽出《球状闪电》递过去,十次有八次对方会惊喜地收下。他没有读过任何一本书,也不懂科幻为何物,仅凭“哪些书常常被同一个人借走”这条规律,就成了馆里最强的荐书员——这就是基于物品的协同过滤(ItemCF)的灵魂:物以类聚,用人人都能观察到的行为共现,找出物品之间的隐秘默契。本文就沿着这条线索,从“借阅登记本”(共现矩阵)出发,教你算出书与书的默契(相似度),为读者开出私人书单(推荐召回),并聊聊如何应对《新华字典》这种人手一本的热门书带来的麻烦,以及如何在真实系统中落地这套算法。

岗位关联

一句话价值:ItemCF 是工业界应用最广的推荐算法之一,掌握了它,你就能为电商、视频、书城等场景搭建“看了又看”式的推荐能力,并真正理解推荐系统的核心权衡。

目录
  1. 可视化演示
  2. 共现矩阵构建
  3. 相似度计算
  4. 推荐召回流程
  5. 工程优化实践
  6. 热门物品处理
  7. 场景与评估
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示ItemCF详解的核心机制,通过入门/进阶/实战/优化四种模式展示关键概念与交互流程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

ItemCF详解:Item ItemCF的核心思想与Use 物品共现矩阵的构建方法 核心机制可视化 ItemCF详解整体架构与关键组件

共现矩阵构建

图书管理员的柜台下压着一本厚厚的借阅登记本,每位读者还书时,老周都会在本子上添一笔:谁、借了哪些书、什么时候还。他从不评价书的内容,只知道一件事——这本本子记录了“哪些书被同一个人带回家过”。这“同时被借走”的关系,就是 ItemCF 最原始的原料。

把登记本上的记录翻译成数学语言:先按读者分组,把每个人借过的所有书两两配对,统计每对书同时出现的次数,就得到了一张“物品 × 物品”的共现矩阵。矩阵里不存书的任何属性,只有行为统计。实际工业实现时,不同行为(点击、收藏、购买)的权重可能不同,通常在构建矩阵前先把行为信号归一化成统一的权重值,避免高频点击和低频购买在数值上失衡。

老周管这张矩阵叫“默契表”——它不问书里写了什么,只记录哪些书总是一起被借走。不过这张表很快会暴露一个麻烦:它又大又稀疏,因为绝大多数书对从未被同一个人借过。

Ci,j=∣{u∈U:i∈N(u), j∈N(u)}∣\displaystyle C_{i,j} = \left|\left\{u \in U : i \in N(u),\ j \in N(u)\right\}\right|
这个公式定义:物品 i 和 j 的共现次数,等于“同时拥有 i 和 j 的用户”的人数。
  1. 用户集合U 代表全体读者,N(u) 是用户 u 借过的物品集合
    u∈U\displaystyle u \in U
  2. 同现条件要求 i 和 j 都属于同一个用户 u 的借阅集合,说明它们被同一个人带走
    i∈N(u), j∈N(u)\displaystyle i \in N(u),\ j \in N(u)
  3. 计数运算两个竖线表示集合的大小,统计满足条件的用户总数,得到共现次数
    ∣{⋅}∣\displaystyle \left|\left\{ \cdot \right\}\right|

相似度计算

老周发现《三体》和《新华字典》也经常一起被借——因为《字典》几乎人手一册。如果单纯按共现次数排序,热门书会跟所有书都“沾亲带故”,真正有默契的书反而排不上号。他需要一个公式,既看“一起被借的次数”,又对“各自太热门”这件事做出惩罚。

余弦相似度正是这样一把尺子。分子统计两个物品共同的用户数,分母用各自用户数的乘积开方来压制热门物品。这样《三体》与《球状闪电》的相似度不会因为两者都热门而虚高,而是要求“共现人数相对各自热度来说足够显著”。

老周满意地看着这张新表:《新华字典》因为分母太大,和谁的数字都被拉低了;而《三体》和《球状闪电》在剔除热度干扰后,依然保持着最高的默契值。

sim(i,j)=∣N(i)∩N(j)∣∣N(i)∣×∣N(j)∣\displaystyle \text{sim}(i,j) = \frac{|N(i) \cap N(j)|}{\sqrt{|N(i)| \times |N(j)|}}
两个物品的相似度,等于共同用户数与两个物品各自热度几何平均的比值,数值落在 0 到 1 之间。
  1. 交集计数分子统计同时借过 i 和 j 的读者人数,共现越多越相似
    ∣N(i)∩N(j)∣\displaystyle |N(i) \cap N(j)|
  2. 各自热度|N(i)| 与 |N(j)| 分别是借过 i、借过 j 的读者总数,热度越高分母越大
    ∣N(i)∣, ∣N(j)∣\displaystyle |N(i)|,\ |N(j)|
  3. 几何平均分母把两个热度相乘再开方,形成对热门物品的天然压制
    ∣N(i)∣×∣N(j)∣\displaystyle \sqrt{|N(i)| \times |N(j)|}
  4. 比值归一最终比值越接近 1,说明排除热度干扰后共现依然显著,这两个物品才是“真朋友”
    共同用户数热度几何平均\displaystyle \frac{\text{共同用户数}}{\text{热度几何平均}}

推荐召回流程

相似度表已经备好,老周开始给读者开书单。他的做法是:拿出这位读者最近借过的书当“锚点”,从每本锚点书的相似邻居里挑出 TopK 本书,再把这些候选的相似度按权重累加起来打分。锚点越相似,贡献越大;锚点越多,候选池越丰富。

形式上,推荐得分可以写成对“用户历史中恰好也是该物品邻居”的那些物品做相似度加权求和。用户对锚点物品的行为强度 r 通常取 1(隐式反馈),如果存在显式评分则直接使用评分。最后把得分排序,过滤掉用户已经借过的书,截取 TopN 输出。

这一步就像是老周把读者借过的每本书都当作“藤”,顺藤摸到一串相似书,再把几根藤上的果子合并去重、按重量排序,最后挑出最饱满的一把递过去。

p(u,j)=∑i∈N(u)∩S(j,K)sim(j,i)×ru,i\displaystyle p(u,j) = \sum_{i \in N(u) \cap S(j,K)} \text{sim}(j,i) \times r_{u,i}
物品 j 对用户 u 的推荐分,等于用户喜欢的每个物品 i 与 j 的相似度乘上用户对 i 的偏好后求和。
  1. 候选条件i 必须既在用户历史里,又出现在 j 的 TopK 相似邻居中,两边交集才参与打分
    N(u)∩S(j,K)\displaystyle N(u) \cap S(j,K)
  2. 相似度加权sim(j,i) 是物品 j 与锚点物品 i 的默契值,越相似贡献越大
    sim(j,i)\displaystyle \text{sim}(j,i)
  3. 行为权重r_{u,i} 表示用户对锚点的偏好强度,隐反馈通常取 1,评分则取原始分数
    ru,i\displaystyle r_{u,i}
  4. 累加求和对全部符合条件的锚点求和,得到 j 的总得分,再据此排序截取 TopN
    ∑i∈⋅sim(j,i)×ru,i\displaystyle \sum_{i \in \cdot} \text{sim}(j,i) \times r_{u,i}

工程优化实践

如果老周每次推荐都现场翻遍登记本重新算一遍默契表,图书馆的柜台早就被排队的人挤垮了。他的对策是“提前做功课”:每天闭馆后,把所有借阅记录整理一遍,完整算出一张新的默契表存在抽屉里;白天推荐时只查表,不重算。

工业界的 ItemCF 也遵循同样的节奏。共现矩阵和相似度表在离线任务中定时(如每日)重建,通常用 Spark 等分布式框架处理日志;线上服务只读取内存中的相似表做 TopN 召回。相似表的存储紧凑而高效:每个物品只保留相似度最高的 K 个邻居,以 item_id -> [(neighbor, score), ...] 的形式放进 KV 或内存。增量更新方面,新日志先进入增量通道,小批量合并到昨天的计数上,周期性全量重建纠偏。

老周的抽屉就是那张“在线相似表”,每晚更新一次,白天随查随用。而归一化就像给每本书的默契值统一换了一把刻度尺——否则书缘极广的书会凭“虚高”的原始分抢占所有推荐位。

sim′(i,j)=sim(i,j)max⁡k∈N(i)sim(i,k)\displaystyle \text{sim}^{\prime}(i,j) = \frac{\text{sim}(i,j)}{\max_{k \in N(i)} \text{sim}(i,k)}
每个物品的相似度都除以自身所有邻居中的最大值,让相似度范围统一到 [0,1],不同物品的邻居分数彼此可比。
  1. 最强邻居分母取物品 i 的所有相似邻居中相似度的最大值,作为基准
    max⁡k∈N(i)sim(i,k)\displaystyle \max_{k \in N(i)} \text{sim}(i,k)
  2. 相对比例分子是当前邻居 j 的原始相似度,除以基准后得到相对得分
    sim(i,j)max⁡ksim(i,k)\displaystyle \frac{\text{sim}(i,j)}{\max_{k} \text{sim}(i,k)}
  3. 统一量尺归一化后每个物品的邻居分数都在 0 到 1 之间,不会被“朋友特别多”的物品带偏
    sim′(i,j)∈[0,1]\displaystyle \text{sim}^{\prime}(i,j) \in [0,1]

热门物品处理

真正让老周头疼的是《新华字典》。它几乎人人借过,于是和每本书都有不小的共现数。按原始余弦公式算下来,字典成了许多书的 Top 邻居,推荐出来的候选清一色是大路货,冷门但有深度的书反而不见踪影。这在推荐系统中被称为“哈利波特问题”——太流行的物品容易与一切物品相似。

缓解思路是对“共现贡献”本身做降权:一个用户借的书越多,他的贡献就越不值得信任。因为“杂食读者”什么都借,并不能说明两本书之间真有缘分;反之,一个只借推理小说的人同时借了 A 和 B,才是强烈的信号。把这一修正放进余弦公式,分子从“共现人数直接求和”改为“对每个共现用户按活跃度倒数加权求和”。

老周从此多了一个原则:判断书与书的默契时,少听“杂食读者”的意见,多参考那些看一眼封面就知道自己要什么的老读者的选择。算法上的降权惩罚,正是这个朴素经验的形式化表达。

sim(i,j)=∑u∈N(i)∩N(j)1log⁡(1+∣N(u)∣)∣N(i)∣×∣N(j)∣\displaystyle \text{sim}(i,j) = \frac{\sum_{u \in N(i) \cap N(j)} \frac{1}{\log(1 + |N(u)|)}}{\sqrt{|N(i)| \times |N(j)|}}
在共现计数时给活跃用户打折:借阅越多的人,在相似度分子里的权重越低。
  1. 共现用户只看同时拥有 i 和 j 的用户,这一步和原公式相同
    u∈N(i)∩N(j)\displaystyle u \in N(i) \cap N(j)
  2. 活跃度惩罚1/log(1+|N(u)|) 随用户借阅量增大而变小,杂食读者的权重被压低
    1log⁡(1+∣N(u)∣)\displaystyle \frac{1}{\log(1 + |N(u)|)}
  3. 加权分子把每个共现用户的影响力累加,形成比单纯人数更可靠的“有效共现”
    ∑u1log⁡(1+∣N(u)∣)\displaystyle \sum_{u} \frac{1}{\log(1 + |N(u)|)}
  4. 热度归一分母保留余弦项,继续压制热门物品,两个惩罚叠加后长尾好书才有机会浮出水面
    ∣N(i)∣×∣N(j)∣\displaystyle \sqrt{|N(i)| \times |N(j)|}

场景与评估

老周的“默契表”并非万能。给少儿绘本区做推荐时,孩子的兴趣半年就换一茬,昨天的恐龙迷今天只爱宇宙飞船;给玩具城做推荐时,顾客买完就走,几乎没有回头客。ItemCF 真正发光的地方,是像会员制图书馆这样“人找书、口味稳”的场景:电商的商品推荐、视频平台的“相关剧集”、书城的“喜欢这本书的人也在看”。

在做技术选型时,ItemCF 常与 UserCF(基于用户的协同过滤)对比。UserCF 以人为锚点,适合新闻资讯这类兴趣漂移快、物品时效性强的场景;ItemCF 以物为锚点,计算出的推荐理由自然可解释:“因为你看过《三体》,所以推荐《球状闪电》”。评估维度上,离线常用召回率、精准率、覆盖率与多样性等指标衡量候选质量,在线则通过点击率、转化率的 A/B 实验验证真实收益。值得注意的是,ItemCF 对物品冷启动并不友好——新上架的书没有任何行为记录,自然也无法进入任何人的默契表,此时需要内容特征等冷启动策略兜底。

老周合上登记本,心里有数了:这套方法适合愿意长期泡在馆里的老读者,而不是走马观花的游客。选对算法的边界,比背熟公式更重要——这大概就是推荐工程师最重要的手艺。

---

AI 应用场景

电商“看了又看”与“买了又买”

阶段:召回 → 排序 → 推荐展示

解决的问题:传统电商靠运营人工配置相关推荐位,覆盖不全且更新慢。ItemCF 基于全量用户购买记录自动发现商品间的共现关系,用户在详情页看到“与该商品搭配购买”的候选,转化率显著提升。

具体案例:某图书商城上线 ItemCF 后,详情页的“喜欢这本书的人也在看”模块点击率提升 32%,且长尾图书的曝光量翻倍。系统每天离线重建相似表,用户进入详情页时实时取 TopK 邻居渲染。

视频平台“相关剧集推荐”

阶段:候选召回 → 相关性打分 → 排序展示

解决的问题:视频平台需要把正在追剧的用户自然导向同类内容,避免逐集看完后流失。ItemCF 通过“观看序列共现”捕捉剧集间的隐性相似,比人工打标签更细粒度。

具体案例:某长视频平台将 ItemCF 应用于“下一集看完后推荐”,追剧用户停留时长提升 18%。相似表按周重建,热门剧集做降权惩罚,使中小成本佳作也能获得推荐位。

音乐与书城的“口味延续”

阶段:行为收集 → 共现矩阵构建 → 相似推荐

解决的问题:音乐和图书消费具有强烈的口味粘性,用户需要“听着相似但要新鲜”的推荐。ItemCF 把同一歌单或同一次借阅记录中的作品视作共现,自动挖掘风格以外的隐藏联系。

具体案例:某有声书 App 使用 ItemCF 构建“听友也在听”模块,以用户收听序列构造共现矩阵,并引入活跃度惩罚降低刷量影响,次日留存率提升约 6%。

Python 演示

python73 行
# -*- coding: utf-8 -*-"""从零实现基于物品的协同过滤 ItemCF"""from collections import defaultdictimport math  def build_user_items(interactions):    """原始交互记录 -> 用户到物品集合的映射"""    user_items = defaultdict(set)    for user, item in interactions:        user_items[user].add(item)    return user_items  def build_item_users(user_items):    """反转为物品到用户集合的映射,供热度统计使用"""    item_users = defaultdict(set)    for user, items in user_items.items():        for item in items:            item_users[item].add(user)    return item_users  def calc_item_similarity(user_items, item_users):    """基于共现矩阵计算物品余弦相似度,并按物品组织邻居列表"""    co_count = defaultdict(int)    for user, items in user_items.items():        items = list(items)        for i in range(len(items)):            for j in range(i + 1, len(items)):                co_count[(items[i], items[j])] += 1                co_count[(items[j], items[i])] += 1    sim_map = defaultdict(list)    for (a, b), cnt in co_count.items():        denom = math.sqrt(len(item_users[a]) * len(item_users[b]))        sim_map[a].append((b, cnt / denom))    for a in sim_map:        sim_map[a].sort(key=lambda x: -x[1])    return sim_map  def recommend(user, user_items, sim_map, K=3, N=5):    """取历史物品的 TopK 相似邻居,累加得分后返回 TopN"""    liked = user_items[user]    scores = defaultdict(float)    for item in liked:        for neighbor, sim in sim_map[item][:K]:            if neighbor in liked:                continue            scores[neighbor] += sim    return sorted(scores.items(), key=lambda x: -x[1])[:N]  def main():    interactions = [        ('Alice', '三体'), ('Alice', '球状闪电'), ('Alice', '流浪地球'),        ('Bob', '三体'), ('Bob', '球状闪电'), ('Bob', '深海'),        ('Carol', '流浪地球'), ('Carol', '三体'), ('Carol', '深海'),    ]    user_items = build_user_items(interactions)    item_users = build_item_users(user_items)    sim_map = calc_item_similarity(user_items, item_users)    print('相似物品示例(Top2 邻居):')    for item in ['三体', '球状闪电', '流浪地球']:        friends = ', '.join('%s(%.3f)' % (n, s) for n, s in sim_map[item][:2])        print('  %s -> %s' % (item, friends))    print('\n为 Alice 推荐:')    for item, score in recommend('Alice', user_items, sim_map):        print('  %s (得分 %.3f)' % (item, score))  if __name__ == '__main__':    main()
目的:用 9 条借阅记录构建共现矩阵与余弦相似度表,并为 Alice 生成 TopN 推荐。
  1. user_items = defaultdict(set)用集合保存每个用户的物品列表,天然去重且方便后续交集运算。
  2. co_count[(items[i], items[j])] += 1对同一用户的两两物品组合计数,这一步完成共现矩阵的核心统计。
  3. denom = math.sqrt(len(item_users[a]) * len(item_users[b]))用两本书各自的借阅人数乘积开方,作为余弦公式中的热门惩罚项。
  4. sim_map[a].sort(key=lambda x: -x[1])将邻居按相似度降序排列,方便推荐阶段直接取 TopK。
  5. for neighbor, sim in sim_map[item][:K]只取 K 个最近邻,控制每个锚点的候选规模。
  6. if neighbor in liked: continue过滤用户已购买的物品,避免推荐重复内容。
  7. scores[neighbor] += sim累加多个锚点贡献的相似度,得到该物品的最终推荐得分。

常见误区

误区还以为两个算法只是换了个名字,计算过程、适用场景都差不多,随便选一个实现就行。

正解两者锚点截然不同:ItemCF 以“物”为锚点,适合用户兴趣稳定、物品规模可控的电商、视频、书城场景;UserCF 以“人”为锚点,适合兴趣漂移快、物品时效性强的新闻资讯场景。选错方向,推荐效果会天差地别。就好比老周的图书馆读者都是老熟人,彼此不认识却能靠书结缘;而校园论坛里人人都在聊同一个热门话题,靠人找人反而更灵。

为何常见:两个算法的公式结构高度相似,都是从共现矩阵出发,初学者容易把差异归结为“矩阵换了个方向”。

误区觉得《三体》和《球状闪电》相似是因为它们都是科幻题材,所以应该用内容标签算相似度,统计用户行为多此一举。

正解ItemCF 的“相似”是行为层面的相似——同一批人买了 A 也买了 B。行为共现包含搭配习惯、口味偏好、品质感知等隐信号,比单纯内容标签丰富得多;而且行为数据自动更新,无需人工打标签。老周不读任何书也能做对推荐,正是因为他用的“行为默契”比“内容分析”更贴近读者的真实选择。

为何常见:人的直觉天然倾向于内容归类,容易低估行为数据中蕴含的深层关联。

误区以为推荐就是把相似度 TopN 的物品全部丢给用户,多省事。

正解真实流程要过滤用户已购物品,还要把“相似度 × 用户对锚点的偏好”累加得到推荐分,因为用户的历史中通常有多个锚点,每个锚点贡献的相似度需要加权合并。此外,若不做归一化,热门物品的原始分数虚高,直接排序会让推荐结果高度趋同。这就好比老周不仅要看书的默契值,还要看读者对这些锚点书的真正兴趣有多强。

为何常见:初学阶段只盯着相似度公式,忽略了推荐得分的设计意图和工程细节。

误区用户去年买的书和昨天刚买的书,在共现矩阵里权重完全一样,反正只数次数。

正解工业实现通常会对行为做时间衰减:最近的点击、购买更能代表用户当前兴趣,太久远的历史应该打折。否则老用户的“童年书单”会一直锁死推荐结果,热情早已冷却的品类仍然霸占着推荐位。这也是为什么相似表要周期性重建,而不是建一次用一辈子。

为何常见:教科书公式默认不画时间维度,初学者容易把“离线统计”误解为“静态不变”。

面试题

Q1. ItemCF 的核心推荐思想是什么?

单选题 · easy

  • A.依据相似用户的喜好
  • B.依据相似物品的关系← 正确答案
  • C.依据全网热点排行
  • D.依据运营人工选品

答案:B。ItemCF 全称是“基于物品的协同过滤”,它通过共现关系计算物品之间的相似度,再为用户历史物品匹配相似物品。A 是 UserCF 的思路,C 是热度推荐,D 是人工运营,都不属于协同过滤的自动挖掘方式。

Q2. ItemCF 中“共现”指的是什么?

单选题 · easy

  • A.两个用户买同一商品
  • B.两个物品被同一人买过← 正确答案
  • C.一个商品被反复购买
  • D.一个用户反复浏览商品

答案:B。共现矩阵统计的是“两个物品同时出现在同一用户的行为集合中”的次数,这是一切 ItemCF 计算的基础。A 是用户共现,C、D 都只涉及单个物品或单个用户,无法构成物品对的关系。

Q3. 下列哪个场景最适合使用 ItemCF?

单选题 · easy

  • A.社交平台的好友推荐
  • B.电商平台的商品推荐← 正确答案
  • C.搜索引擎的结果排序
  • D.语音助手的识别纠错

答案:B。电商用户兴趣相对稳定、商品 SKU 数量可控,且推荐结果可以用“因为你看过某商品”来解释,是 ItemCF 的典型场景。好友推荐属于社交网络问题,搜索排序和语音纠错则分别属于检索与 NLP 领域。

Q4. 余弦相似度公式中分母的作用是什么?

单选题 · mid

  • A.放大热门物品的作用
  • B.消除物品热度造成的偏差← 正确答案
  • C.增加矩阵计算的复杂度
  • D.让相似度值覆盖到负数域

答案:B。分母用两个物品各自用户数的乘积开方作为热度惩罚,热门物品分母大、相似度被压低,从而避免“人人都买它”导致的和谁都相似。A 与真实效果相反,C 只是副作用而非设计目的,D 错误,余弦相似度结果落在 [0,1]。

Q5. 关于“哈利波特问题”,以下理解正确的是?

单选题 · mid

  • A.哈利波特是典型冷门长尾商品
  • B.热门商品易与所有商品相似← 正确答案
  • C.哈利波特类商品不应被推荐
  • D.推荐系统会把哈利波特屏蔽

答案:B。太流行的物品几乎和所有物品都有共现,导致其成为众多物品的相似邻居,推荐结果向热门集中,淹没长尾内容,这就是哈利波特问题。A 说反了,C、D 是错误的对策,真正做法是降权惩罚和归一化。

Q6. 为什么 ItemCF 要对相似度做归一化?

单选题 · mid

  • A.让热门物品有更多曝光机会
  • B.让不同物品的相似度可比← 正确答案
  • C.为了减少离线计算的时间
  • D.为了方便把相似表存入缓存

答案:B。每个物品“朋友圈”的原始相似度量纲不同,直接跨物品比较会偏向朋友多的物品。归一化把所有邻居分数压到 [0,1],推荐得分才跨物品可比。A 方向相反,C、D 与归一化目的无关。

Q7. Alice 买过 A、B、C,其中 A 与 X 的相似度为 0.9,B 与 X 为 0.8,C 与 X 为 0.1,取 K=2 时 X 的推荐得分是多少?

单选题 · hard

  • A.0.9
  • B.1.7← 正确答案
  • C.1.8
  • D.0.1

答案:B。K=2 表示只取相似度最高的两个邻居 A(0.9) 和 B(0.8),隐反馈权重 r 取 1,得分 = 0.9×1 + 0.8×1 = 1.7。C 错在把 0.8 放进 0.9 的名下,D 只看最低相似度。

Q8. 与 UserCF 相比,ItemCF 更适合电商场景的主要原因是什么?

单选题 · hard

  • A.用户兴趣稳定时优势不明显、计算代价高← 正确答案
  • B.UserCF 算法实现的代码更复杂
  • C.UserCF 无法进行离线预计算
  • D.UserCF 完全不需要相似度矩阵

答案:A。电商用户兴趣稳定,UserCF 的“人以群分”优势不明显;且电商用户量远大于物品量,UserCF 计算用户相似矩阵代价高昂。ItemCF 以物品为锚点,可离线建表、结果可解释。B、C、D 的说法都不成立,UserCF 同样可离线计算且需要用户相似矩阵。

Q9. ItemCF 工程中常用哪些手段降低热门物品影响?

多选题 · mid

  • A.对共现计数做热门降权← 正确答案
  • B.对相似度做归一化处理← 正确答案
  • C.仅保留用户最近一次购买
  • D.将热门商品从库存中删除

答案:AB。对活跃用户/热门物品的共现贡献打折和相似度归一化都是标准手段。C 属于时间衰减策略,影响的是用户历史权重而非热门物品;D 删除商品会破坏商品完整性,不是推荐系统的合理做法。

Q10. ItemCF 的“数据稀疏”问题体现在哪些方面?可以如何缓解?

多选题 · extreme

  • A.用户-物品矩阵通常高度稀疏← 正确答案
  • B.稀疏会让共现统计不可靠← 正确答案
  • C.稀疏问题完全无法缓解
  • D.可挖掘行为序列扩展信号← 正确答案

答案:ABD。绝大多数物品对的共现次数为 0,矩阵高度稀疏且统计不稳定。缓解手段包括利用用户会话/行为序列扩展共现信号、对高频物品截断、引入内容特征做冷启动补充等。C 过于绝对,与已知的工程实践矛盾。