企业官网建设流程全解析

我花了两个晚上把网易2018年数据挖掘实习生（云音乐方向）的笔试原题翻出来重新做了一遍。说实话，这套题放在今天看依然有很强的参考价值，它几乎把数据挖掘实习生应该具备的核心能力都覆盖到了：机器学习基础、推荐系统思路、特征工程、SQL取数，甚至还有一点业务 Sense。更关键的是，题目紧紧贴着云音乐的业务场景，不是那种背背公式就能过的卷子。这篇文章我打算拆解这套题背后的考点逻辑，再给出一份可以直接照着准备的复习路线，无论你是准备校招还是在职跳槽，都能从中挖出点东西。

先给个结论：网易这道笔试题并不是单纯考“你会不会用 sklearn”，它实际想筛选的是——能理解业务、能处理数据、能落地模型的人。云音乐的核心业务就是“听歌”，所以题目几乎都围绕着用户行为、歌曲推荐、播放序列这些真实场景展开。如果你只会调包而说不清样本怎么构造、召回和排序有什么区别，这套题会把你打回原形。

1. 笔试整体结构复盘：网易云音乐在找什么样的数据挖掘实习生

1.1 云音乐的业务特征决定了考点方向

网易云音乐和其他音乐App最不一样的地方有两块：个性化推荐和歌单UGC生态。日推、私人FM、每日歌单，这些功能背后全是数据挖掘的活。所以笔试题目从推荐链路切入是非常自然的。

数据挖掘实习生进了云音乐团队之后，日常工作大概是这几类：

• 用户画像建设：给用户打标签，比如“喜欢民谣”“偏好粤语老歌”“深夜听歌人群”
• 内容理解：对歌曲、歌单做语义分析，提取风格、情感、场景标签
• 推荐系统优化：召回策略迭代、排序模型升级、重排规则调整
• 运营分析：活动效果评估、用户生命周期分析、流失预警

对应到笔试题上，考察点就非常清晰了。选择题部分重点覆盖概率统计、机器学习基础、特征工程常识；编程和简答题则围绕用户行为数据展开，考察 SQL 取数、基础算法实现和推荐流程设计。整套题的设计逻辑是：先确认理论基础，再考察工程能力，最后用业务场景判断你的数据思维。

1.2 各模块的考察逻辑和典型题型

从我回忆的真题结构来看，这套卷子大致分为三个部分：

选择题（约40%）主要考基础概念。比如给一组样本让你算信息增益、给两个事件判断是否独立、给一个损失函数问它对应什么模型。这部分其实是在筛“基本功扎不扎实”，因为机器学习入门谁都会调库，但能够手推公式、理解原理的人才是团队想要的。

简答题（约30%）围绕音乐推荐业务出题。常见的有“如何为冷启动用户推荐歌曲”“如何评估推荐系统的效果”“如何从行为日志中提取用户特征”等。这些题没有标准答案，面试官关注的是你有没有清晰的解决思路。比如冷启动问题，你能不能想到用注册时选择的歌手类别做种子兴趣，再叠加热门歌曲兜底，这就是业务经验差异所在。

编程题（约30%）通常是 SQL 和基础算法混合出题。SQL 会给你一张用户听歌记录表、一张歌曲信息表，让你统计播放量Top10歌曲、计算用户活跃天数等。算法题则可能是手写一个协同过滤或者实现一个简单分类器。这部分考察工程落地能力，写不出来基本就凉了。

这里要插一句：很多人重视算法题却忽略SQL，这是大忌。数据挖掘实习生进了团队，前三个月干得最多的就是写SQL取数。如果连窗口函数都用不利索，哪怕模型原理背得再好，也很难过面试官这关。

2. 核心考点深度拆解：从推荐链路到机器学习细节

2.1 推荐系统链路：召回、排序、重排

这套笔试题里几乎一定会出现推荐相关题目，所以我第一时间把推荐链路完整梳理了一遍。一个完整的推荐系统通常分成三块，每一块的考察重心完全不同。

召回阶段的目标是从全量歌曲库（可能有几千万首）中快速筛出几百首候选歌曲。常用方法包括协同过滤（UserCF/ItemCF）、基于内容的相似推荐、向量召回（如 Item2Vec、双塔模型）等。笔试常见考法，是给你用户行为日志，让你设计一个召回策略。这个时候你要明确说明：召回为什么用协同过滤，而不是训练一个排序模型。因为协同过滤不需要复杂特征，只需要用户-物品交互矩阵，计算成本低、可解释性强，适合第一轮粗筛。而深度模型召回虽然精度高，但需要大量特征和训练资源，在工业场景中通常作为精排之后的升级方案，而不是一开始就上。

排序阶段负责对召回出的几百首候选歌做精细化打分。常用模型是 LR、GBDT、FM，以及后来的 DeepFM、DIN 等。笔试中常考的是：给定一组特征（用户年龄、歌曲风格、播放时长、收藏次数等），你选择什么模型，为什么。这个题目没有唯一答案，但你要体现出对特征和模型的匹配理解。比如 LR 适合处理大规模稀疏特征，可解释性强；GBDT 能自动发现特征交叉，适合处理数值型特征；FM 则擅长二阶特征交叉。如果面试官接着问“你线上用哪个”，你要会说“先用 LR 做基线，再迭代到 GBDT+LR 或 FM”。

重排阶段则是站在业务视角做调整。比如避免连续推荐同一歌手的歌、控制推荐列表的多样性、给新歌更多曝光机会。这块虽然模型上不复杂，但很考验产品感觉。笔试如果问“推荐结果单一怎么办”，你要能从多样性、新颖性、探索与利用（EE）这几个角度去回答。

2.2 机器学习基础：样本构造、特征工程、评估指标

数据挖掘的笔试，机器学习基础是躲不过的。但在云音乐的场景下，基础知识的考察会有很强的“落地倾向”。

举几个高频考点：

样本构造是最容易出问题的地方。推荐系统的样本通常来自用户曝光日志和播放日志。暴露给用户但没有点击/播放的歌曲就是负样本，点击/播放了就是正样本。但这个逻辑有个坑：很多曝光用户根本没看见，没看见不等于不喜欢，所以负样本有大量噪声。更好做法是“随机负采样”，即从未曝光歌曲中随机抽取一部分作为额外负样本，保持正负样本比例在合理范围（比如1:3到1:5）。笔试如果问到“如何构造训练样本”，你要能把这个思考过程讲出来。

特征工程方面，云音乐场景最常用的是用户行为序列特征。比如用户最近一周播放的歌曲风格分布、播放时长均值、收藏次数、歌手喜爱度Top3等。时间衰减也很重要——用户上周听过的歌和半年前听过的歌，信号强度完全不同。常见做法是给行为加上时间衰减权重，比如 ( w = e^{-\lambda \Delta t} )，(\lambda) 根据业务调整，通常取值0.01~0.1。

评估指标更是必考。推荐系统常用的是 AUC、GAUC、NDCG、Recall@K、Precision@K。其中 AUC 衡量的是排序能力，而 GAUC 是按用户分组计算的 AUC 加权平均，更贴近推荐场景，因为推荐结果是给单个用户看的，整体 AUC 会被活跃用户主导。笔试问你“用什么指标评估推荐效果”，你说 AUC 没错，但能补充 GAUC 和业务指标（播放率、收藏率、完播率）会明显加分。

2.3 SQL 取数和数据处理的实战套路

SQL 是数据挖掘实习生的基本功，2018年网易这套题里也出现了。很多候选人死磕算法题，结果在 SQL 上翻车，非常可惜。

常见题型是：给你用户行为表（user_id, song_id, play_time, duration, event_type）、歌曲信息表（song_id, singer, genre, publish_date），要求统计各种指标。基本上把这几类 SQL 练熟就够用了：

基础聚合：统计每个用户的播放次数、播放时长、活跃天数。这时候用 GROUP BY 加聚合函数就行。

窗口函数：统计每个用户最近一次播放的歌曲、按播放次数排名前3的歌手。这里要用 ROW_NUMBER() 或 RANK() 配合 PARTITION BY。2018年很多学校课程不讲窗口函数，所以这道题能筛掉一批人。

TopN问题：找出每个风格下播放量最高的歌。先 JOIN 两表，再用窗口函数或子查询取 Top1。这类题在真实工作中极其常见，比如“每个城市播放量最高的歌”“每个用户最常听的歌手”。

如果一道 SQL 题你只会写 GROUP BY 和 JOIN，那基本只能拿到一半分数。窗口函数这个东西，笔试前必须练熟。

3. 实操环节：手写一道简化版的云音乐推荐题

3.1 题目设定

网易这套笔试题里编程题是当场写代码，我在这里给出一道高度类似的简化版练习题，方便大家感受考场上要做什么。原题核心思想大概是：给定用户历史播放记录，预测每个用户未来一周可能播放的歌曲，输出 Top10 推荐列表。这道题看起来简单，实际要处理的问题不少：数据稀疏、冷启动、相似度计算、排序去重。

下面是我按当时考核难度设计的练习版本，大家可以在本地跑一跑，完整走一遍数据挖掘的工作流。

数据格式是两个 CSV：用户行为表（user_id, song_id, play_count, timestamp）和歌曲属性表（song_id, singer, genre）。目标：基于用户历史播放行为，为每个用户预测未来可能播放的10首歌。

3.2 基于 ItemCF 的完整实现

我直接用 ItemCF（物品协同过滤）来实现，因为这是工业界最简单可落的召回方案之一，考试时间有限的前提下，最优选择。

ItemCF 的核心思路：如果很多用户同时听了 A 歌和 B 歌，那么 A 和 B 相似。给用户推荐时，找出他听过的歌曲的相似歌曲，按相似度加权排序。

import pandas as pd import numpy as np from collections import defaultdict # 1. 加载数据 behavior = pd.read_csv('user_behavior.csv') song_info = pd.read_csv('song_info.csv') # 2. 构建“用户 - 已听歌曲集合” user_songs = defaultdict(set) for uid, sid in zip(behavior['user_id'], behavior['song_id']): user_songs[uid].add(sid) # 3. 构建“歌曲 - 哪些用户听过” song_users = defaultdict(set) for uid, sid in zip(behavior['user_id'], behavior['song_id']): song_users[sid].add(uid) # 4. 计算歌曲两两相似度（余弦相似度简化版） # sim(a,b) = |N(a) ∩ N(b)| / sqrt(|N(a)| * |N(b)|) song_sim = defaultdict(dict) song_list = list(song_users.keys()) for i in range(len(song_list)): s1 = song_list[i] users1 = song_users[s1] for j in range(i+1, len(song_list)): s2 = song_list[j] users2 = song_users[s2] common = len(users1 & users2) if common == 0: continue sim = common / np.sqrt(len(users1) * len(users2)) song_sim[s1][s2] = sim song_sim[s2][s1] = sim # 5. 为每个用户生成推荐 def recommend(uid, top_k=10): listened = user_songs[uid] score = defaultdict(float) for s in listened: for s2, sim in song_sim[s].items(): if s2 in listened: continue # 去掉已经听过的歌 score[s2] += sim # 按分数排序取TopK rec = sorted(score.items(), key=lambda x: x[1], reverse=True)[:top_k] return [s for s, sc in rec] # 6. 输出每个用户的推荐结果 for uid in list(user_songs.keys())[:10]: # 先看前10个用户 rec_songs = recommend(uid) print(uid, rec_songs)

这个代码跑起来不会有太大问题，但说实话只是实现了最基础的逻辑。如果要拿高分，还需要考虑几件事：

• 播放次数要作为权重加入，而不只是用“是否听过”这个二值信号
• 时间衰减要加进去，最近播放的歌曲应该有更高权重
• 相似歌曲如果同一歌手占比过高，要去重或做多样性惩罚

3.3 代码调试和常见坑点

我在复现这个题时踩了几个坑，写在这里给大家避雷。

第一个坑：相似度计算开销太大。如果歌的数量有10万首，两两计算就是 (10^{10}) 量级，直接跑死。真实做法是只对“有过共同用户”的歌曲对计算相似度，或者用 MinHash/LSH 做近似计算。笔试时数据量小无所谓，但你得在答案里提一句“大规模场景下要如何优化”，这就能和其他考生拉开差距。

第二个坑：推荐结果没有去重。用户听过周杰伦的《晴天》，系统可能推荐周杰伦的《七里香》《简单爱》《稻香》……结果 Top10 全是周杰伦。这个结果准确率可能不低，但用户体验很差。实际工业做法会在重排阶段做同歌手限制：Top10里同一个歌手最多出现2首。

第三个坑：忽略冷启动用户。如果某个用户只听了1首歌，他的推荐结果基本只能从这1首歌的相似歌里出，覆盖率极低。处理方式是：对行为数量少于N（比如5首）的用户，用热门歌曲兜底。这个逻辑在代码里要单独写一个分支，不能直接走常规推荐流程。

4. 笔试之后的面试追问：题目背后的深水区

4.1 评估指标的隐藏陷阱

笔试考你“用什么指标评估推荐效果”，很多人回答“AUC”，面试官表面点头，实际心里在等你补充。如果你只说“AUC”，大概率会被追问：“线下AUC涨了，线上指标没涨，甚至跌了，你排查思路是什么？”

这个问题非常经典。可能原因有三个。

样本选择偏差。线下训练的样本来自曝光日志，但曝光结果本身就受当前推荐策略影响。如果线上推荐策略变了，样本分布也就变了，线下评估自然失真。解决办法是加探索流量、做无偏学习（比如IPS加权）。

特征不一致。线下训练时用了未来数据（比如未来一周的播放量标签），但线上预测时这些特征不存在，结果线下分数虚高。这种情况我见过太多次，处理办法是严格按时间切分训练集和验证集，保证特征时间一致性。

评估指标与业务目标不一致。AUC衡量的是排序相对关系，但业务目标可能是播放率提升、收藏率提升。如果排序把用户可能收藏的歌排到前面，但用户平时就是随便听，播放率反而可能下降。所以正确做法是线下看AUC，同时做离线仿真，估算线上业务指标的变化方向。

4.2 新用户冷启动怎么办

我相信这套笔试题的面试环节一定绕不开冷启动问题，因为音乐产品的新用户冷启动场景太典型了。

我的思路分三层。第一层是注册时获取兴趣信号。云音乐在注册时会让你选喜欢的歌手和风格，这就是强信号。把这些种子歌手作为初始召回池，从中用内容相似度扩展出候选集合。

第二层是实时行为反馈。用户进入App后的每一次点击、播放、跳过都要实时反馈到推荐策略里。比如用户连点了三首民谣，下一轮推荐就应该多出民谣候选。

第三层是热门兜底。冷启动阶段没有个性化信号，给最热门的歌是保证体验下限的选择。热门歌有播放数据，有用户反馈，能帮助系统更快学习用户偏好。

这三层是递进关系，从强信号到弱信号，从个性化到普适化。面试其实就是在考察你能不能构建这样一套完整的链路。

4.3 数据倾斜怎么处理

音乐推荐场景里数据倾斜问题非常常见。周杰伦的播放量可能是普通歌手的几百倍，这会导致推荐结果向头部歌曲集中。

处理方式有几种：对热门物品降权，在协同过滤计算中，如果物品的流行度过高，可以对其相似度贡献做惩罚；对热门歌曲做抽样限制，控制每个用户听歌记录中热门歌曲的比例；在召回阶段分桶，把歌曲按热度分成不同的桶，每个桶内独立做协同过滤，最后再合并。

这些方法在笔试里如果能提到两个以上，面试官会认为你真有实战经验。

5. 给准备校招的同学：复习范围和实操建议

5.1 时间分配建议

如果你离笔试还有两个月，我建议按这个比例分配复习时间：数据结构和算法30%，机器学习和统计学30%，SQL和数据能力25%，推荐系统基础15%。为什么算法和SQL加起来超过一半？因为笔试首先是一道编程门槛，过不去其他免谈。如果你只有一个月时间，把SQL和机器学习基础复习扎实，性价比最高。

刷题方面，LeetCode 刷150-200题足够，重点放在数组、链表、哈希表、字符串、二叉树上，动态规划适量刷。SQL 刷题推荐做 LeetCode 的数据库板块，把窗口函数、JOIN、子查询练熟。

5.2 容易被忽视的考察细节

有几个知识点，很多人觉得不重要，但网易这套题里确实出现过，我单独列一下：

概率统计不是背公式就行的。条件概率、贝叶斯公式、期望方差、常见分布（正态、泊松、二项）要能结合实际场景算题。比如“用户平均每天听20首歌，每首歌被收藏概率0.1，问用户7天收藏超过20首歌的概率”，这种题就是泊松分布的应用场景。

交叉熵损失函数为什么分类问题用交叉熵而不用均方误差。背后是梯度更新的角度，因为Sigmoid+MSE会导致梯度消失。这种“为什么”的问题特别容易被笔试选择题和面试追问考到。

样本不平衡怎么处理。虽然这个知识点在2018年还没有现在这么火，但在数据挖掘面试中一直是高频问题。上采样、下采样、Focal Loss、代价敏感学习，至少要知道两三种方案。

5.3 成套练习的复盘方式

刷题不是刷完就完了，复盘比刷题本身更重要。我建议每次笔试模拟后做三层复盘。

第一层，看自己哪些题不会做。这暴露的是知识盲区，需要针对性补课。

第二层，看哪些题会做但速度慢。这暴露的是熟练度问题，需要多刷同类型题目提高肌肉记忆。

第三层，看哪些题做对了但在面试中可能被追问。这种题目不能止步于答案本身，要多问自己几个“为什么”，把背后的原理吃透。

我记得当时准备网易这套题时，考完最深的体会是：这套卷子考的不是你背了多少公式，而是你有没有真正理解数据挖掘在业务里的位置和作用。云音乐需要的人不是会调参的“炼丹师”，而是能理解用户为什么听歌、为什么收藏、为什么切歌的人。如果你能从数据里读懂用户，再从用户需求反推模型设计，那这套题无论怎么变化，你都能找到解题的切入点。

最后分享一个小技巧：复习的时候不要把题目和业务割裂开。每次学到一个算法，试着想一下它在云音乐的场景里能解决什么问题、有哪些局限。比如倒排索引可以解决相似歌曲快速检索，Focal Loss 可以缓解收藏行为稀疏问题，这一切都在考查你的业务理解力。把这种思维训练成习惯，笔试、面试都会顺很多。