网易云音乐推荐系统深度拆解：从召回排序到冷启动

网易云音乐应该是国内把推荐算法和社区氛围结合得最紧密的一款产品。每次打开私人FM，那种被精准拿捏的感觉，让很多用户心甘情愿把时间留在App里。作为一个在推荐系统方向摸爬滚打多年的工程师，我一直觉得网易云是研究音乐领域推荐系统的最佳样本之一：它有上亿曲库、丰富的用户行为、以及强烈的社区属性，几乎把推荐系统会遇到的所有典型问题都覆盖了。

这篇文章我想把网易云音乐这套推荐算法拆开来讲。从产品入口背后的设计逻辑，到召回排序的完整链路，再到冷启动、实时推荐这些难啃的骨头，最后聊一聊如果想复现这套思路，该怎么从零开始搭一个音乐推荐系统。适合正在做推荐系统、对音乐产品感兴趣，或者准备入行推荐算法的朋友阅读，内容不会涉及任何破解、抓包之类的灰色操作，纯粹聊算法和工程。

1. 先搞清楚网易云音乐到底在推荐什么

1.1 三个主要推荐入口背后的产品逻辑

很多人一提到网易云的推荐算法，第一反应就是“每日推荐”那个歌单。但实际网易云的推荐入口远不止这一个，至少有三个主要场景：每日推荐、私人FM、还有歌单/单曲的相似推荐。这三个场景虽然底层模型共享，但推荐目标其实不完全一样。

每日推荐的目标是稳定、精准、有新鲜感。它每天更新一次，面向的是用户长期的音乐品味，用户点开这个歌单，期望的是“里面大多数歌我都喜欢，但最好有几首是以前没听过的”。这种场景下，算法要平衡精读和探索，不能全是热歌，也不能全推冷门实验音乐。

私人FM则更偏向实时反馈和情绪匹配。用户处于“随便听听”的状态，对每一首歌的反馈（听完、切歌、收藏）会立刻影响下一首推什么。这种场景对实时性要求极高，行为到推荐的延迟通常要控制在分钟级甚至秒级，它更像一个会话式的推荐过程。

歌单和单曲的相似推荐则是以内容理解为驱动的。用户点进一首歌的详情页，看到“包含这首歌的歌单”和“相似歌曲推荐”，背后依赖的是歌曲内容特征和用户共现关系的融合，目的是让用户沿着当前兴趣点做深度浏览。理解了这三个入口的不同，再去看网易云的推荐系统架构，就不会一头雾水了。

1.2 推荐系统的核心链路：从行为日志到用户界面

抛开具体的应用场景，任何推荐系统的主干都可以拆成四个环节：数据、召回、排序、重排。

数据层负责把用户行为、歌曲属性、上下文信息变成特征向量，这是最容易低估的环节。网易云的用户行为数据非常丰富：播放、完播、切歌、收藏、评论、分享、加入歌单、搜索、关注……每种行为背后都隐含了不同程度的偏好信号，不能一视同仁地当作“正样本”。

召回层负责从千万级曲库里快速筛出几百个候选，矛盾在于“既要快又要准”。排序层则对这几百个候选做精细化打分，用更复杂的模型和特征，把用户最可能喜欢的那几十首歌排到最前面。最后的重排层通常负责多样性控制、去重、商业规则过滤，保证最终呈现给用户的结果不扎堆、不重复、有节奏感。

网易云这套链路的核心竞争力，我总结下来就三个字：场景细。它不是用一套通用模型打天下，而是在不同场景侧重复用不同的策略权重，让同一个用户在不同状态下都能觉得“推荐得挺懂我”。这是很多推荐系统容易忽视的地方——模型再强，场景定义不清晰，用户还是觉得你不懂他。

2. 数据根基：音乐推荐和普通商品推荐最大的不同

2.1 歌曲内容特征：从音频信号里挖出来的“听觉指纹”

商品推荐可以靠标题、品类、价格这些结构化文本特征起步，但音乐推荐如果只靠文本元数据，上限非常低。

同一首歌，不同版本的混音、现场、翻唱，听感差异可能天差地别；而两首完全不同语言的歌，编曲风格和情绪可能是高度接近的。要捕捉这些“听感”层面的相似性，必须回到音频本身做内容特征提取。

常见的音频特征可以分几个层面：

实际操作中，网易云这类平台通常会先做音频预处理，提取每首歌的幅度谱或梅尔频谱，再送进深度网络做embedding。这个embedding的目标函数通常是“让同一首歌的不同片段在向量空间里靠近，让不同歌曲的向量距离拉开”。

如果自己从零做，没必要一上来就上大模型。我试过的比较实用的方案是，先用现成的音频特征提取库（比如librosa）把MFCC、色度、节拍特征抽出来，做PCA降维后作为歌曲向量。实测下来，对流行音乐的曲风聚类效果已经非常不错，后续再接深度模型做精调。

2.2 用户行为特征的构建：长期偏好和短期兴趣要分开算

用户特征比物品特征复杂，因为一个人在不同时刻、不同状态下的口味是漂移的。

网易云对用户特征的刻画，长期和短期是有明确区分的。长期画像描述的是“这个人整体上喜欢什么”，比如古典占比高、民谣占比高、粤语歌多，这种画像更新频率低，适合用于每日推荐这种偏稳定的场景。短期兴趣则是“最近一周甚至最近几小时在听什么”，它要捕捉用户最近的收听轨迹，比如连续三个晚上都在听爵士，那短期标签就应该快速向爵士倾斜。

这两类特征在推荐系统里的用法不同。长期特征适合做精排模型的用户侧特征，短期特征更适合做实时召回和session级别的重排。

在构造行为特征时，有个容易被忽视的细节：不同类型的播放行为权重必须区分。主动搜索后播放的歌，权重要高于随机播放列表里的歌；完整听完并收藏的歌，权重高于听到一半就切掉的歌；切歌这个负反馈信号尤其重要，连续快速切歌往往说明推荐质量已经严重下滑了。如果把这些行为混在一起当正样本，模型会被噪声带偏。

2.3 标签体系与歌单文化：中文音乐平台独有的社交信号

网易云和其他音乐平台最不一样的地方，是它围绕歌单和评论区构建起来的社区生态。这个生态为推荐系统提供了普通音乐平台很难获得的数据红利。

歌单本身就是一种天然的“人工标注”。用户自己创建的每一个歌单，几乎都带有明确的主题和情绪倾向：“适合熬夜写的代码”、“下雨天适合听的纯音乐”、“健身房爆爽歌单”……这些歌单把一首首散落的歌，变成了有上下文关联的序列。

推荐系统可以从歌单里学到非常珍贵的共现信息：如果用户把A和B这两首歌放进同一个歌单，那说明在用户的认知里它们是同类的。这种信号质量比单纯的播放共现高得多，因为歌单的创建是主动行为，背后有审美判断，而不是算法推什么就听什么。

评论区数据则是更深层的信号。虽然文本内容本身涉及NLP，但有价值的推荐信号并不需要读懂评论的具体文字——只需要知道一首歌产生了多少评论、多少点赞、多少转发，这些互动指标综合起来可以直接作为歌曲社交热度的特征。歌曲再小众，如果评论区异常活跃，往往说明这个圈层的用户粘性非常高，值得进入候选池。

3. 召回阶段：先把候选池从千万缩到几百

3.1 多路召回的设计思路：协同过滤、内容匹配、热榜兜底

推荐系统在召回阶段的目标不是“找到最准的歌”，而是“用尽量小的成本覆盖用户所有可能感兴趣的角度”。网易云这类平台的曲库规模在亿级，但用户能消费的音乐类型是多样化的：可能既有循环了很多年的老歌，也有最近新发现的小众乐队，还有刷短视频听到的洗脑神曲。

单一召回策略不可能同时照顾到这些不同维度的兴趣，所以工业界普遍采用多路召回架构。每一路召回独立工作，各自筛出几百首歌，最后合并去重，再进入排序层。

网易云典型的多路召回大致包这些路：

每一路召回的候选质量参差不齐，但没关系，召回只要保证“找得到”，把精准打分的责任交给排序层。

我在实际项目里最常犯的错误，就是花太多时间优化某一路召回，希望能做到尽善尽美。但多路召回的设计哲学恰恰相反：单路召回不必完美，多路的覆盖度才是核心。就像撒网打鱼，每张网小一点没关系，关键是网要撒得足够分散。

3.2 矩阵分解与向量召回：从行列式到向量近邻搜索

多路召回里最经典的技术是协同过滤。传统的物品协同过滤ItemCF，通过用户对物品的行为矩阵计算物品之间的相似度，然后推荐“和你听过歌相似的歌”。这种方法的优点是可解释性强，缺点是计算复杂度高，而且很难泛化到没有行为的冷门物品上。

矩阵分解是协同过滤的进阶形态。它把用户行为矩阵分解成用户隐向量和物品隐向量，用隐向量的内积来预测用户对物品的偏好。网易云这类平台通常会对SVD、SVD++这些经典方法做过不少工程优化，比如加入隐式反馈、时间衰减、偏置项等等。

在张量计算层面，矩阵分解得到的用户向量和物品向量，其实就变成了向量召回的基础。当曲库规模大到一定量级，精确计算用户和所有歌曲的内积已经不现实，这时候就要依赖向量近邻检索。业界常用的工具包括Faiss、Annoy、HNSW等，通过建立空间索引结构，把“在千万向量里找最相似的TopN”这个问题的耗时压缩到毫秒级。

一个常见误区是，以为向量召回一定能比协同过滤召回效果好。实际上，矩阵分解和向量召回的收益取决于数据稠密度。用户行为非常稀疏时，隐向量很难学出有效表示，这时候传统ItemCF反而更稳定。所以在一个成熟的推荐系统里，不同阶段的路由策略会有序组合，而不是简单地用新方法替换旧方法。

3.3 召回结果融合：常见的加权与去重策略

多路召回各自返回一批候选后，需要一个融合策略来决定最终让哪些候选进入排序层。最简单的融合方式是等权合并+去重：每路选Top100，把重复歌曲去掉，得到几百个候选。这种方式的问题是热门歌曲会在多路里重复出现，占据大量候选名额。

更进阶一些的做法是加权融合。一般规则是给精准度高的路（比如协同过滤）更高权重，给探索性强的路（比如内容召回）较低权重。权重的确定可以先离线用历史数据预估各路的点击率、播放率，再按比例分配候选名额。

实际工程里还有一个容易被忽略的步骤：按召回来源做配额。如果用户连续几次推荐结果都是同一路召回占主导，会导致推荐结果单一化。我见过不少系统，定向召回、热门召回各占固定比例，即使某一路质量更高，也不允许超过规定比例。这种“人为干预”看起来不智能，但对控制推荐生态非常有效。

融合完成之后，召回层产出的候选集合会被送入排序层。这里注意，召回层的每一路都应该保留一个分数，可以是相似度、热度或者行为概率，这些分数在排序模型里可以作为特征使用，帮助排序模型理解“这个候选是怎么进来的”。

4. 排序阶段：真正的重头戏都在这里

4.1 特征工程：排序模型到底在学什么

排序模型的任务是对召回阶段产出的几百个候选做精准打分。如果召回解决的是“找得到”，排序解决的就是“排得好”。

在排序阶段，特征的重要性怎么强调都不为过。业界有个共识：特征比模型重要。模型选得差一点，最多掉两三个点的效果；特征工程做得不好，调参再猛也无济于事。

网易云音乐这类场景里的排序特征，大体可以分成这几类：

网易云这类音乐平台对“时间上下文”特别敏感。工作日通勤时段和周末深夜，用户可能想听完全不同的歌。同一个用户，早上听快节奏的Pop、晚上听Lo-Fi，排序模型至少要把“小时”和“是否周末”这两个时间特征放进去。

交叉特征也是排序阶段的核心命门。用户长期偏好embedding和歌曲embedding做cosine相似度，这个特征的预测能力往往比模型本身更直接。我自己在实验里见过这种情况：把embedding相似度特征去掉，精排模型AUC直接掉了0.03到0.05，比换掉整个模型的损失还大。

4.2 从LR到深度排序模型：点击率预估模型的演进

排序模型走过了从逻辑回归到深度模型的演进过程。逻辑回归（LR）的最大优势是可解释性强，训练成本低，但特征之间的非线性关系需要靠人工做特征交叉，工程量巨大。后来的FM/FFM模型用隐向量的方式自动做特征组合，算是解决了LR在特征交叉上的不足。

近几年的深度排序模型则把用户行为序列和特征embedding整合进神经网络，代表模型包括Wide&Deep、DeepFM、DCN等。这些模型的本质，是用“宽”的部分记住用户的历史偏好，用“深”的部分做特征的高阶交叉。

网易云这类平台在实际线上用的模型不会只有一个，往往是多个模型组合：一个主模型负责整体CTR预估，另一个模型专门负责完播率预估，还有一个模型负责收藏/分享率预估。多目标的建模方式，让推荐结果不仅有高点击率，而且真正被用户听完、留下来。

如果从零开始实践，我的建议是不要一上来就搞DeepFM、大Transformer。先从一个两层的Wide&Deep开始，把特征梳理清楚，跑通全链路，再逐步加复杂度。很多团队花几个月从LR换到DeepFM，效果提升可能只有零点几个点，真正的瓶颈其实在特征质量。

4.3 时间上下文与重复消费惩罚：音乐排序里的特殊约束

音乐推荐排序和其他领域的推荐（比如电商、短视频）有个显著不同：用户对重复内容的容忍度极低。电商里，一个商品可以反复推给用户，因为购买是低频事件；短视频里，用户可能刷到重复视频也会快速划过，但损失没那么大。音乐则不同，一首歌连推两三次，用户会明显感觉“这个App推荐得真糟糕”。

所以音乐推荐排序里通常会加重复消费惩罚，要么在特征层加入“这首歌最近被推给该用户的次数”，要么在生成层做硬规则过滤，把短期内推过且没有积极反馈的歌直接移除。

时间衰减在音乐推荐里也比其他领域更重。一首歌如果你以前很喜欢、但最近一个月都没再听，推它的优先级应该下降；但如果一周前你单曲循环了一整天，短期兴趣模型就应该把它重新捞出来。这两种完全相反的判断需要同时存在于一个排序模型里，本质上是长期兴趣和短期兴趣两个分支对分数的影响在博弈。

多目标排序的调参也很有讲究。网易云的排序目标大概是“点击率 + 完播率 + 收藏率 + 分享率”的加权组合。不同场景权重不同：每日推荐更看重收藏率和完播率，私人FM更看重视觉上的完播率，排行榜侧重点击率。这些权重通常由产品经理和算法工程师一起定，而且会随着产品策略调整不断变化。

5. 冷启动与实时性：音乐推荐最考验功力的地方

5.1 新歌冷启动：没有行为数据时怎么推

新歌冷启动是所有音乐推荐系统最绕不开的问题。每天都有大量新歌上线，它们没有任何播放、收藏、评论数据，协同过滤和深度模型对它们毫无办法。

网易云的新歌冷启动方案，核心思路是靠内容理解和社交关系间接建模。

内容理解侧的方案是：将新歌的音频特征embedding提取出来，与曲库里己有歌曲的向量做相似度匹配，找到它跟哪些老歌“听起来像”，再把这些老歌的兴趣人群作为新歌的潜在受众。比如一首新的民谣歌曲，如果它的embedding和宋冬野、马頔的老歌高度接近，那“喜欢这些民谣歌手”的用户就是潜在的推荐目标。

社交关系侧则更巧妙：如果新歌来自一个已有一定粉丝基础的音乐人或厂牌，可以通过音乐人的粉丝群体做冷启动。关注了这个音乐人的用户，对新歌的接受度会显著高于普通用户。华语音乐圈的“独立小众音乐人”生态，恰恰和网易云的平台调性非常契合，很多新歌冷启动就是靠这批核心乐迷的口碑扩散完成的。

冷启动阶段的探索要控制力度。新歌不能大规模全量推荐，容易伤害用户体验。通常做法是设置曝光配额，把新歌的展示量控制在一个小比例内，先观察点击率、完播率等指标，表现好的再逐步加大推荐权重。

5.2 新用户冷启动：靠注册信息只能做到及格

新用户没有行为轨迹，连用户画像都是空白，这是推荐系统界的经典难题。网易云用户注册后会有一个“选择喜欢的音乐风格”的环节，这个交互就是最简单但有效的新用户冷启动手段。

这部分给出的风格偏好标签，可以作为初始用户特征直接参与召回和排序。不过，仅有这一步远不够。用户选的风格是“想成为的自己”，而实际倾听行为往往与自我认知有差异。所以新用户冷启动的关键，是快速通过行为反馈修正初始画像。

这里有一个工程上的细节：新用户的前几次推荐结果，通常会加入较大比例的“热门歌曲”作为兜底。因为热门歌曲被验证过对大多数人都友好，可以有效避免“新用户一进来就不合口味”的体验崩塌。在积累了足够行为后再过渡到个性化推荐。

另外，登录设备的型号、地域、使用时段，也可以作为游客状态的辅助特征。虽然这类特征的预测能力不强，但做冷启动时期的效果提升已经很大了。

5.3 实时推荐：从偏好漂移到情绪捕捉

网易云音乐对实时性要求最高的场景就是私人FM，“下一首歌”的生成需要尽可能贴合你此刻的状态。

实现实时推荐的关键在于两点：实时特征更新和近线召回更新。

实时特征更新是指用户最近几分钟的行为能立刻反映到特征里。比如刚才快进了三首歌，实时特征就应该记录“最近的切歌率升高”，排序模型对这个用户下一轮的推荐进行整体降权，或者调高近期兴趣向量的影响因子。这个链路的延迟通常要求在一分钟内。

近线召回更新是指召回结果不是每天计算一次，而是每5到10分钟更新一批。用户刚刚收藏或者反复播放过的歌，会在几分钟内进入召回路，把原本不在候选集合里的歌曲捞出来。

网易云有一个很明显的体验特征：FM里如果你连续点“喜欢”某几首同一风格的新歌，几首歌之后推荐内容就会明显向这个风格倾斜。这种“越听越懂”的感觉，就是实时特征+实时召回协同工作的结果。

情绪捕捉这个维度，虽然听起来玄学，但其实可以工程化。比如深夜时段自动调高安静、舒缓歌曲的比例；工作日早晚高峰增强节奏感强的歌曲权重；周末则偏向更轻松、更实验向的内容。不需要真的理解用户的情绪，只需要给上下文特征合理建模，就能在行为层面模拟出“猜情绪”的效果。

6. 想复现这套思路？从一个小型音乐推荐系统开始

6.1 数据准备：可用的公开数据集与埋点设计

如果你想从零开始做音乐推荐系统，建议先走通一套最小闭环，再去追求复杂模型。第一步永远是找数据。

公开数据集方面，学术常用的有Last.fm的播放日志数据、Million Song Dataset、以及一些图书音乐评论数据。Last.fm的数据集有约百万用户的播放记录，虽然年代较早，但对理解推荐系统全流程完全够用。另一个热门选择是抓取公开的歌单数据做协同过滤，但要注意数据合规，尽量使用公开数据集或者自己埋点。

如果你有机会从自己产品里获取数据，埋点设计就特别重要了。至少要记录的问题包括：用户ID、播放歌曲ID、播放开始时间、播放时长、歌曲总时长、是否完播、切歌时间点、收藏行为、分享行为。这些字段，按事件时间戳存储，后续所有用户行为特征都从原始事件表里衍生。

这里分享一个实用经验：原始行为表一定要保留“歌曲总时长”字段，因为它决定了一个关键指标“完播率”。完播率 = 实际播放时长/歌曲总时长。很多新人只记录播放时长，不记录总时长，后面要做完播预估的时候才发现字段缺失，补数据成本极高。

6.2 一个最小可用的召回排序实现

有了数据之后，可以从最简单的方案开始。召回层用ItemCF（物品协同过滤），排序层用逻辑回归，这两件套足以跑通一个能用的音乐推荐链路。

ItemCF的实现思路：统计所有用户的行为记录，构建“用户-歌曲”行为矩阵，计算歌曲间的余弦相似度。某首歌的相似歌曲，就是与它的行为向量最接近的那些歌。推荐时，找出用户最近听过的歌，取每首歌的TopN相似歌，合并去重得到候选池。

排序层用LR时，关键不是模型的复杂度，而是特征的有效性。初始阶段可以只放三个特征：候选歌曲与用户长期听歌embedding的余弦相似度、候选歌曲的全站热度、用户对候选歌曲所在曲风的历史完播率。特征从0到3的过程，推荐效果提升会很显著。

代码层面，Python配合Pandas做数据处理、SKLearn训练排序模型，就可以完成一版。如果数据量达到千万级，可以逐步切换到Spark/ClickHouse或向量检索工具。工程化不是初期的瓶颈，算法逻辑和数据理解才是。

6.3 评估指标与AB实验的注意事项

做完推荐系统，必须有一个可靠的评估体系，否则根本分不清“推荐变好”是玄学还是工程进步。

离线评估阶段，常用的指标有Recall@K、Precision@K、NDCG@K、HitRate@K。音乐场景比较特殊的一点是，不需要过于强调排序的绝对精确性，而要把“多样性”纳入评估。只做Precision，模型会收敛到把所有用户都推向热门歌，这时候Recall其实也能观测到下降。

在线评估阶段，网易云这类产品的核心指标包括：点击率、完播率、收藏率、次日留存、人均收听时长、切歌率。其中人均收听时长一般是北极星指标，因为它直接关联平台的商业价值。

做AB实验有几个常见的坑。第一个坑是分组不均匀。音乐推荐的效果受时段影响巨大，晚上的收听时长天然高于白天，如果实验组和对照组的流量分布时段不一致，实验结果就是无效的。分组必须按照用户ID做哈希分层，确保两组用户的画像和活跃时段分布基本一致。第二个坑是实验时长太短。音乐推荐有“新鲜度效应”，新模型刚上线用户有新鲜感，各项指标会虚高，一般要跑满至少一周才能看到稳定效果。第三，多目标权重调整时，往往是一个指标上升、另一个指标下降，需要产品先明确主目标，不然算法团队会一直在防御性指标里内耗。

7. 常见问题与调优经验

7.1 推荐结果趋同：多样性控制的几种手段

推荐系统跑一段时间后，最典型的问题是结果越来越“窄”。协同过滤天然有马太效应，热门歌曲越推越多，长尾歌曲越来越看不见。用户会觉得推荐的歌是“好听，但总是这些”，少了那种“哇，这首都能找到！”的惊喜感。

解决推荐趋同的常用手段有三个：

第一是召回层的配额控制。限制协同过滤路召回的占比，强制保留一定比例内容召回和长尾召回的候选。

第二是重排层加多样性约束。对排序结果做MMR（最大边际相关性）重排，核心公式是贪心地从候选列表里取歌，每次选取时同时考虑“和用户匹配度”和“与已选歌曲的差异性”。比如已经选了3首民谣，第4个候选即使民谣评分略高，也会因为风格重复被跳过，换成风格差异大的候选。

第三是探索与利用的平衡。给候选池中的增量歌曲、低热度歌曲增加一个随机性系数，或者用Epsilon-Greedy策略，让一小部分流量完全随机播放。

这里的调优心得是：多样性不是越多越好。音乐推荐里有一个“惊喜度-准确性”的悖论：过多的探索会伤害用户。真正好的多样性，是在用户感兴趣的大方向内，寻找同一个圈层内的不同可能，而不是把完全不相干的类型混在一起。

7.2 热门歌曲压制长尾：如何让冷门好歌被看见

热门歌曲像磁铁一样吸走了大量推荐流量，这是所有推荐系统的常态。但网易云的社区氛围和华语独立音乐生态，决定了它对长尾内容的重视程度比其他平台高得多。

要缓解热门对长尾的压制，可以控制热门歌曲的曝光频次。一首歌推给同一个人三次都不被点，就降低该歌对这类用户的推荐频率。如果一首歌全站播放量很高，但推荐给的某个用户连续几天都没产生行为，说明这首歌不适合这个用户，该降权就降权。

另一个思路是给长尾歌曲增加权重补偿，但同时设置曝光上限。长尾歌曲曝光量少，但点击率和收藏率往往并不差。我见过一个做法：将歌曲的历史播放时长按分位数归一化，播放量越低的歌，在排序得分里有一个固定的加成值。这个加成不能让一首完全不该推荐的长尾歌进入前排，但可以让它在夹缝中获得展示机会。

在实践过程中，冷门歌曲推荐的风险也有控制。因为冷门歌没有稳定的热门底盘，推错了用户会很反感。所以我通常会设定一个保底机制：冷门歌的曝光占比不超过15%，并且对高点击率的冷门歌实行更激进的扩量。用户每一次对冷门歌的交集行为，都会被放大处理，争取让更多用户看到它。

7.3 我在实际做音乐推荐时踩过的坑

最后分享几个自己在做音乐推荐时踩过的坑，都是真金白银换来的教训。

第一个坑是过分相信离线指标。离线AUC涨了千分之几，就以为线上指标也会跟着涨，结果上线后发现播放量反而下降。音乐推荐的特殊性在于用户行为受“新鲜感”影响极大，用户对一直推同一批歌曲会产生疲态。所以离线评估时务必加上多样性、新鲜度的监控，不能只盯着精准性看。

第二个坑是负样本构造不严谨。音乐点歌的场景中，用户没有看到一首歌，并不代表他不喜欢；只有推给他之后划走了，才算负样本。很多新手把全部未被点击的歌曲当作负样本，会导致模型严重偏向热歌。正确的做法是只把展示过但没有积极反馈的歌作为负样本，且负样本与正样本的比例需要精心调节，一般从10:1开始调。

第三个坑是没有区分“短期爱听”和“长期品味”。同一首在一天内反复听了好几遍的歌，和一首三年里断断续续听了几十次的歌，对用户的忠诚度含义完全不同。如果不分长期短期去构建特征，模型很容易被短期行为“带跑偏”，推荐结果一直在用户最近喜欢的窄小圈层里打转，越来越单调。

第四个坑是标签噪声。歌单和用户打的标签里面有很多噪声，人对歌的感知是高度主观的，同时一首歌也常常会被打上相反的标签。如果不做标签置信度计算，直接把这些标签当特征喂模型，效果反而会退步。

这些坑说出来，很多做推荐的朋友可能心有戚戚。也正是因为这些坑的存在，让我一直对推荐系统保持敬畏。它不是单纯的算法比拼，而是一个对数据、对用户心理、对工程细节都要求极高的系统工程。每次看到网易云这样成熟的推荐系统，我都会提醒自己，要复现它的表面功能不算难，要复现它那种细腻的用户感知，还有很长的路要走。