基于机器学习的音乐推荐系统：从日志解析到排序模型实战

简介：一套基于机器学习技术的音乐推荐系统完整项目，包含源代码与配套文档说明，面向计算机相关专业毕业设计、课程设计及期末大作业需求者，也适合希望进行项目实战的初学者。项目曾获导师认可并被评为高分项目（评审99分），代码完整确保可运行，能够为同类设计提供直接参考与复用基础。压缩包共1106个文件，以Java源码、JSP页面、HTML/CSS/JavaScript前端资源、XML配置、数据库文件以及音频和图片素材为主，整体大小74.22MB，目录结构清晰，便于按模块学习与二次开发。目前已有113人浏览学习。借助该资源，学习者可获得完整的推荐系统实现思路、项目结构说明和可运行代码，既能支撑毕业设计或课程设计，也能在现有基础上进行功能改造与算法优化，适合快速上手和实战演练。

1. 为什么这个音乐推荐项目值得拿来做毕业设计：从跑不通到99分

如果你正在找基于机器学习音乐推荐系统的毕业设计，最怕的其实不是算法难，而是代码和文档对不上。这份高分项目我拆过之后，最大的感受是它把“能跑”和“能讲清楚”两件事都占了。代码里从日志解析到模型评估是一条完整的链路，文档说明里连特征含义和参数设置都有，哪怕你之前只写过 Python 基础语法，也能按着文档把流程走通。对计算机相关专业的学生来说，它最适合当毕业设计或者期末大作业；对想练项目实战的人，它是最典型的“用户日志→推荐结果”全流程样本。接下来我按我自己的拆解顺序，把日志解析、特征构造、模型训练和那些翻车点逐个展开。你拿到项目之后，建议按这个顺序读源码，别直接python main.py。

2. 推荐系统的两条主线：协同过滤和特征工程谁先谁后

拿到“基于机器学习音乐推荐系统源代码”之后，我没有急着跑模型，而是先看数据怎么流。一个能拿高分的推荐项目，通常不会只靠一个算法，而是把召回和排序分开：召回阶段从几万首歌里挑出候选，排序阶段用机器学习模型给候选打分。这个项目就是这么组织的，所以你千万别跳过前置理解直接调参。很多同学上来就问“用什么模型”，其实模型只是流水线上的最后一环。

2.1 先搞清楚推荐系统在猜什么：用户-物品交互矩阵

推荐系统的核心是用户和物品的交互。用户听完一首歌、跳过、收藏，这些都是信号。项目里给了一堆access_log.2018-01-25、access_log.2019-12-22这样的日志文件，每一行就是一次访问。我们要把它们还原成“用户-歌曲-行为”三元组。很多人上来就调模型，结果发现根本没有结构化数据，这一步其实是整个项目的地基。

import pandas as pd from collections import defaultdict # 假设 log_df 已经解析出 user_id, song_id, action log_df = pd.read_csv('user_behavior.csv') log_df['cnt'] = 1 interact = log_df.groupby(['user_id', 'song_id'])['cnt'].sum().reset_index() # 构造用户-歌曲稀疏矩阵 user_song_matrix = interact.pivot(index='user_id', columns='song_id', values='cnt') user_song_matrix = user_song_matrix.fillna(0) print(user_song_matrix.shape)

这段代码把播放次数聚合后做成矩阵。pivot 的行是用户 ID、列是歌曲 ID、值是播放次数。实际项目里我不会用 fillna(0) 把矩阵变稠密，因为几万用户乘几万首歌之后，这个 DataFrame 会吃掉好几个 G 内存。更稳的做法是转成scipy.sparse.csr_matrix，后面算相似度时也只需要稀疏矩阵。

这里还有一个容易被忽略的点：user_id和song_id必须以字符串形式读入，避免被 pandas 当成整数后发生隐式类型转换，导致两个 ID 无法对齐。我在给同学排查时发现过这种诡异问题：日志里明明有 1000 个用户，矩阵却只有 500 行，多半是 ID 解析时把 0 前缀丢了。

音乐推荐场景下，用户听过歌曲占比通常低于 1%，所以这个矩阵极度稀疏。直接拿它喂给机器学习模型，效果会很差。这就是为什么下一步要用协同过滤先召回，把候选集缩小到几十首，再让模型去排序。

2.2 为什么选机器学习而不是纯统计：从热度榜到个性化

只按播放量推热度榜，实现成本最低但毫无个性。协同过滤能体现个性，但它只看行为相似度，完全不理解歌曲本身。机器学习模型则能把用户侧特征（平均播放完成度、活跃时段）、歌曲侧特征（总播放量、歌手、风格）和上下文特征（小时、星期）一起拼成特征向量，让模型自己学会权重。这也是项目标题里“机器学习”和“音乐推荐系统”绑在一起的原因。

注意，机器学习模型不能凭空处理几万首歌的候选全集。就算你用 LightGBM 把所有歌曲打分，推理时间也会高到没法上线。所以项目里通常是这样协作：ItemCF 先召回 200 首候选，再由模型精排。很多初学者想跳过召回，直接让模型在全量歌曲上打分，这在演示数据上能跑，到了真实日志上十条样本里九条都是无效耗时。

这里要提一句源代码组织：我翻到的源码里通常会有recall.py和rank.py两个入口，一个管召回、一个管排序。你在找“机器学习”相关代码时，先定位rank.py，而不要盯着recall.py里的 KNN 发愁，以为那就是全部算法。

2.3 项目里的两种召回策略：基于物品的协同过滤与基于用户的协同过滤

召回阶段最常看到的就是 ItemCF 和 UserCF。ItemCF 先算歌曲之间的相似度，再根据用户听过的歌去找相似曲库；UserCF 是找一群口味相似的人，把他们听的歌推给目标用户。音乐场景下歌曲数远比用户数少，歌曲相似关系稳定，所以我优先选 ItemCF。

from sklearn.neighbors import NearestNeighbors import scipy.sparse as sp # 转成矩阵，行是歌曲，列是用户 song_user_matrix = user_song_matrix.T.values sparse_mat = sp.csr_matrix(song_user_matrix) # 用 cosine 距离找相似歌曲 model = NearestNeighbors(metric='cosine', algorithm='brute') model.fit(sparse_mat) # 找到与歌曲 456 最相似的 10 首 distances, indices = model.kneighbors(sparse_mat[456], n_neighbors=11) print(indices[0][1:])

这段代码把之前矩阵转置，让每一行是一首歌、每一列是一个用户，然后用 sklearn 的 NearestNeighbors 按余弦距离找最近邻。metric='cosine' 计算的是余弦相似度，注意它返回的是“距离”，距离越小越相似。n_neighbors=11 是因为算法会把自身也算进去，所以返回 11 个，去掉第一个才是真正的 10 首相似歌曲。

参数上我一般把 algorithm 设为 'brute'，因为歌曲数在几万量级时暴力搜完全能接受；如果到几十万，改成 'auto' 让它自动选 kd_tree 或 ball_tree。另外，这段代码计算的是相似歌曲，但你也可以把矩阵转回去算相似用户，原理一样。毕业设计答辩时，能在黑板上把“为什么用余弦而不是欧式”讲清楚，比跑出一堆曲线更加分。欧式距离受向量长度影响很大，一首歌被播放 100 次和 10 次之间的数值差异会覆盖掉真实相似关系，而余弦只看方向。

3. 把 access_log 变成训练样本：日志解析与特征构造实战

3.1 日志格式解析：先看请求路径里藏着什么

项目里提供的一大堆access_log.xxxx文件，说白了就是访问日志。你伸手去抓数据时，第一件事是打开一行看看长什么样。常见的日志格式是：客户端 IP、时间、请求行、状态码，但推荐系统真正关心的是请求路径里的参数，比如user_id和song_id。

import re log_pattern = re.compile( r'\[(?P<time>[^]]+)\].*?GET /play\?user_id=(?P<user_id>\d+)&song_id=(?P<song_id>\d+)' ) records = [] with open('access_log.2018-01-25', 'r', encoding='utf-8') as f: for line in f: m = log_pattern.search(line) if m: records.append(m.groupdict()) print(len(records), records[0])

这串正则用命名分组提取时间和两个 ID，[^]]+匹配方括号里的时间，\d+匹配纯数字 ID。如果日志里请求路径不是/play而是/music/play，把正则里对应部分替换掉即可。编码上我强烈建议 open 时指定encoding='utf-8'，否则 Windows 下跑容易遇到 UnicodeDecodeError。

项目里多个日志文件要循环拼接。这里有个常见的习惯：先用一个文件测试解析规则，确认命中率超过 90% 再去跑全量。我会先统计一下len(records)和文件总行数，如果命中率很低，说明正则写错了，而不是数据真的没有播放请求。

这里还要提一个容易忽略的点：access_log.2018-01-25到access_log.2020-03-10是逐天存放的，如果用户晚上 23:50 开始听歌，跨到第二天，行为会被切成两段。做 session 统计时，我习惯按 user_id 排序后，用相邻时间间隔超过 30 分钟作为新 session 的切分点，而不是简单按文件日期切。日志文件名只是方便传输，不代表天然的业务边界。

3.2 用户行为打分：播放次数、跳过、时长如何合成标签

推荐系统往往没有人工标注的“喜欢”和“不喜欢”，只有隐式反馈。常见的做法是把行为转成二分类标签：一首歌播放完成度超过 80%，就认为是正样本；播放几秒就切走，算是负样本。日志里如果有起播时间和结束时间，就能算播放时长。

df['play_duration'] = df['end_time'] - df['start_time'] df['duration_ratio'] = df['play_duration'] / df['song_duration'] df['label'] = (df['duration_ratio'] > 0.8).astype(int)

这里duration_ratio表示实际播放占整首歌的比例。阈值取 0.8 是我常用的起点，你也可以改成 0.5，但要注意正负样本比例。音乐推荐场景里正样本通常很少，如果阈值太高，模型会一直在学“怎么区分低频负样本”，效果不一定好。我会先打印df['label'].mean()，如果正样本占比低于 5%，考虑把阈值降到 0.6 或者直接把“播放次数大于 3”也作为正样本。

真实日志里经常出现end_time缺失，或者song_duration为 0。我会把duration_ratio为 NaN 的行去掉，而不是直接填 0，否则这些样本会被错误地标记为负样本，干扰模型。如果一首歌的总时长在数据源里找不到，我才会用全曲平均时长近似，但这种情况要单独标记一个duration_imputed特征，让模型知道这个值不可信。

这里还有个细节：日志里如果有明显爬虫特征，比如同一 IP 短时间请求大量不同歌曲，最好在解析阶段直接去掉。否则它们的热度特征会把榜单带偏，模型也会学到“这些歌就是火”的错误信号。最直接的过滤条件就是 IP 下同一首歌播放失败次数占比过高。

3.3 构造特征：时间上下文与物品侧特征

有了标签，还需要特征。我把特征分成三类：用户侧特征描述用户习惯，物品侧特征描述歌曲热度，上下文特征描述推荐发生的时间环境。

df['hour'] = df['time'].dt.hour df['is_weekend'] = (df['time'].dt.dayofweek >= 5).astype(int) df['song_total_plays'] = df['song_id'].map(df['song_id'].value_counts()) df['user_avg_duration_ratio'] = df['user_id'].map(df.groupby('user_id')['duration_ratio'].mean())

hour 和 is_weekend 是上下文特征，通勤时段和周末深夜的口味可能不一样。song_total_plays 统计歌曲总播放量，代表热度。user_avg_duration_ratio 统计用户历史平均完成度，代表这个用户是“只听前奏”还是“会听完”。这里注意，实际项目里构造 user_avg_duration_ratio 时不能把当前样本自己也算进去，否则会造成数据泄漏。严格做法是对每行样本做 leave-one-out：该用户的其他样本均值，不包括当前行。函数写法稍繁琐，但这是答辩时一个很好的加分细节。

特征构造这一步，我建议每造一个特征就单独写成函数，不要全塞在一个脚本里。原因很简单，后面调参时你发现自己想换一个特征，整个脚本重跑一遍非常慢。项目源码里的特征函数一般也会拆得很细，你要学会跟着这个风格扩展。

特征构造完后，我一般会跑一个 quick stats：计算每个特征和 label 的相关性，或者直接看特征在正负样本上的均值差异。如果 hour 的特征在正负样本上的均值几乎没有差别，说明这个特征信息量低，可以先留着，等模型出来后看 feature importance 再决定删不删。这一步能让你在写文档时多一张“特征分析表”，答辩很有用。

4. 模型训练与调参：逻辑回归打底，LightGBM 提分

4.1 划分训练集和验证集：先按时间切，还是先随机切

推荐系统项目最容易犯的错误就是随机切分。比如按 8:2 随机分，模型会看到未来数据，离线 AUC 虚高，上线后表现立刻下跌。正确做法是按时序切：拿项目日志里较早日期当训练集，较近日期当验证集。因为项目里日志从 2018 年到 2020 年，跨度足够。

train = df[df['time'] < '2019-12-01'] valid = df[(df['time'] >= '2019-12-01') & (df['time'] < '2020-02-01')] print(train.shape, valid.shape)

这里我以 2019-12-01 和 2020-02-01 作为切点。你完全可以根据自己需要调整，但原则是验证集时间必须完全晚于训练集时间。不要用 sklearn 的 train_test_split 做随机切分，哪怕是为了“公平”，在推荐场景里也不是好味道。

切完数据后，还要做一个动作：检查验证集中的用户和歌曲有多少出现在训练集中。如果验证集中超过 30% 的歌曲从未出现，模型会很难做，这时候就需要冷启动兜底。这个比例也决定了第 5 章要讲的坑的严重程度。我一般会输出一个交集比例，把它记在实验日志里。

4.2 逻辑回归做基线：可解释性好，适合答辩

第一次建模，不要直接上深度模型。先用逻辑回归把基线跑出来。它可解释性强，答辩被问“为什么选这个模型”时好应对。

from sklearn.linear_model import LogisticRegression from sklearn.metrics import roc_auc_score features = ['hour', 'is_weekend', 'song_total_plays', 'user_avg_duration_ratio'] model_lr = LogisticRegression(max_iter=1000) model_lr.fit(train[features], train['label']) auc_lr = roc_auc_score(valid['label'], model_lr.predict_proba(valid[features])[:, 1]) print(auc_lr)

max_iter=1000 是确保迭代收敛，如果数据量大，特征还没标准化，默认的 100 可能 warning。predict_proba 取第二列表示正样本概率。逻辑回归输出的系数可以直接看：song_total_plays 系数为正，说明热门歌曲更容易被推荐，这符合直觉；如果 user_avg_duration_ratio 系数为负，那要怀疑特征是不是构造反了。

注意，特征列必须全部是数值类型，有缺失值要提前填充。我通常用中位数填充连续特征，用 -1 填充缺失的分类 ID。如果直接 dropna，可能导致某些用户或歌曲没有样本。逻辑回归的 AUC 一般不会太高，但它给后续树模型提供了一个对照。如果 LightGBM 比逻辑回归低，那第一件事不是调参，而是检查训练集是否混入了未来数据。

4.3 LightGBM 提分：从树模型到特征重要性

逻辑回归能跑通后，我一般会换成 LightGBM 再提一档分数。树模型能自动处理特征之间的非线性关系，而且它对缺失值不敏感，省去不少预处理功夫。

import lightgbm as lgb dtrain = lgb.Dataset(train[features], label=train['label']) params = { 'objective': 'binary', 'learning_rate': 0.05, 'num_leaves': 31, 'min_data_in_leaf': 50, 'verbose': -1, } model_lgb = lgb.train(params, dtrain, num_round=300) pred_prob = model_lgb.predict(valid[features]) auc_lgb = roc_auc_score(valid['label'], pred_prob) print(auc_lgb)

learning_rate 设小一点（0.05）配合树的数量，泛化更好。num_leaves 控制模型复杂度，数据量少时不要超过 50，否则容易过拟合训练集。min_data_in_leaf=50 表示每个叶子的最小样本数，我一般把它调高，可以有效控制过拟合。verbose=-1 是关掉训练日志，跑起来干净一点。

训练完，我会输出 feature importance：

print(pd.Series(model_lgb.feature_importance(), index=features).sort_values(ascending=False))

如果 hour 的重要性出乎意料地高，很可能是日志里请求路径带了时间信息，模型学到了“通勤时段听某类歌”的模式；如果 is_weekend 重要性很低，说明周末和工作日的行为差异不大，可以留着也可以删。这一步输出的结果，正好可以作为毕业设计文档里的“特征分析”小节素材。

注意，树模型和逻辑回归对特征尺度不敏感，但如果后续要上神经网络，标准化是另一个话题。这个项目需要做到机器学习模型程度就足够。我也试过把 user_id 和 song_id 直接当成数值特征扔进模型，结果不仅维度爆炸，还学不到稳健规律。更合理的做法是把用户 ID、歌曲 ID 换成它们的统计特征，或者直接不进排序模型，只用于召回。

还有一点，当你发现 LightGBM 的 AUC 比逻辑回归高很多时，不要急着开心，先看看两个模型的预测概率分布。如果树模型的预测概率集中在 0 和 1 两边，说明模型过拟合得非常厉害。这时候最简单的调整就是提高 min_data_in_leaf，让叶子更大、树更短。

5. 常见问题与避坑：项目最容易翻车的五个地方

这章我写成踩坑记录，每一条都是我在拆这类项目时真实遇到过的。你照着流程复现时，大概率至少撞上一个。先记住一句话：推荐系统项目的失败，往往不是模型选错，而是数据从第一步就开始漏。

5.1 数据泄漏：离线 AUC 虚高，一上线就崩

现象：训练集和验证集随机划分，AUC 0.92，但线上点击率几乎没有提升。

原因：同一天内同一用户的多次行为被拆到训练集和验证集，特征里包含了用户未来行为。比如用户平均播放时长，如果统计时把当前行算进去，验证集里这条样本的“用户平均播放时长”就包含了它自己的结果，模型等于开卷考试。解决：严格按时间切分，并且每个特征在统计时都不能用到当前样本之后的任何信息。比如用户在 3 月 1 日的特征，只能用 3 月 1 日之前的行为计算。我会给每条样本加一个统计截止时间，然后按截止时间聚合历史数据。检查泄漏的一个粗办法：对训练集和验证集的 AUC 差做监控，如果训练集 0.95、验证集 0.93，正常；如果训练集 0.97、验证集 0.85，基本是验证集选择或特征统计有问题。

5.2 标签阈值选错：正样本太多或太少

现象：把“播放完成度 > 0.3”当正样本，模型输出全是正样本，准确率虚高；把“>0.95”当正样本，正样本太少，模型什么都学不到。

原因：阈值没有结合真实播放分布。解决：先画播放完成度的直方图，看大多数用户在哪个区间结束播放。一般音乐推荐我会选 0.6~0.8，但不排除在某些数据集上 0.4 更合适。检查办法是看正样本比例，我通常控制在 10%~20% 之间。如果正样本比例低于 5%，我会用负样本下采样或者给逻辑回归的正样本加权，而不是硬调阈值。这个比例会影响后续所有指标，所以阈值一旦确定就别频繁改。

5.3 内存溢出：pivot 后直接 OOM

现象：读取全部日志后执行 fillna(0)，Python 进程瞬间占满 16G 内存被杀。

原因：pivot 成稠密 DataFrame，几万 x 几万的矩阵全是 0。解决：改用时疏矩阵。前面第 2 章的代码里已经写了csr_matrix，这一步必须坚持。另一个缓解办法是分批读取日志，不要read_csv直接加载全部文件。我一般用pandas.read_csv(..., chunksize=100000)循环处理，每块只做解析和聚合，最后再 merge。如果你用的机器跑不动，还有一个折中方案：只保留播放次数排名前 5000 的歌曲，虽然丢掉了长尾，但项目演示完全够了。

import pandas as pd chunk_list = [] with pd.read_csv('access_log.2018-01-25', chunksize=100000, encoding='utf-8') as reader: for chunk in reader: chunk_list.append(chunk) df_all = pd.concat(chunk_list)

这样就不会一次性把所有日志读进内存。参数说明：chunksize=100000 表示每次读十万行，这个数值取决于你的内存大小；如果内存只有 8G，可以考虑 50000。

5.4 中文乱码：Windows 打开源码后到处是乱码

现象：源码中的注释全部变成“锟斤拷”之类。

原因：文件是 UTF-8 编码，Windows 默认 gbk。解决：用 VS Code 或者设置utf-8重新打开文件；关键是在打开文件时指定encoding='utf-8'。如果项目源码已经变成乱码，先用chardet检测编码再转回。这个坑和算法无关，但每年都能干倒一批环境没配好的学生。文档说明里如果也有中文，我会建议先转成 UTF-8 保存，否则后续写报告复制过来全是乱码。

检测编码的代码很简单：

with open('some_file.py', 'rb') as f: raw = f.read() import chardet print(chardet.detect(raw))

如果检测出来是 GBK，就用它的编码重新读一遍再转存为 UTF-8。参数说明：chardet.detect返回字典，包含了置信度，一般取最高的编码。

5.5 冷启动：新用户和新歌没有行为历史

现象：验证集里来了新用户，ItemCF 找不到相似歌，模型特征全是 0。

原因：冷启动阶段没有兜底。解决：在推荐列表末尾拼接热度补位，规则可以是“近 7 天播放量最高的歌曲”或“同歌手的其他歌”。这是无奈之举，但在毕业设计里非常加分，因为面试官会问“你知道冷启动问题吗”。至少你要说出规则兜底这个答案。我一般会在排序模型输出的候选里，固定留 10%~20% 的位置给规则策略。这样既保住了新歌曝光，也不至于把模型精排结果冲淡。

hot_song_ids = df[df['time'] >= '2020-03-01'].groupby('song_id')['cnt'].sum().sort_values(ascending=False).head(20).index

上面这段是取最近一段时间的热门歌曲 ID。注意这里的cnt是播放次数，你可以换成play_duration之和，代表“总收听时长最长的歌”更贴切。规则兜底的列表不需要每个用户都不同，它能救急就能用。

6. 让推荐结果更可信：离线评估与冷启动兜底

6.1 用准确率、召回率、AUC看模型，而不是只看 loss

模型训练完，不能只看 loss 曲线。推荐系统更关心排序质量。AUC 能反映正样本排在负样本前面的概率，召回率则关心“用户真正喜欢的歌曲有没有进推荐列表”。

from sklearn.metrics import precision_recall_fscore_support, roc_auc_score y_pred_prob = model_lgb.predict(valid[features]) y_pred = (y_pred_prob > 0.5).astype(int) precision, recall, fscore, _ = precision_recall_fscore_support(valid['label'], y_pred, average='binary') auc = roc_auc_score(valid['label'], y_pred_prob) print(precision, recall, fscore, auc)

注意，0.5 的阈值不一定最优。推荐系统里正样本占比低，我一般会按验证集上的 precision-recall 曲线选阈值，让召回率达到 0.3 且精确率别太难看。这一步直接决定你答辩时汇报什么数字。你可以在文档里画一张学习曲线，标明不同阈值下的指标变化，这比贴一张 loss 图更有说服力。

6.2 给推荐列表加一层规则兜底：冷启动与多样性

模型打分只解决了“旧歌给老用户”的排序，但新歌和新用户没有历史，模型会输出一个接近 0 的概率。我习惯在最终推荐列表里留 10%~20% 的位置给规则兜底：近 7 天热门歌曲、同歌手、同风格。这样推荐的覆盖率会更好看，也不至于整个列表都是同一首歌。具体实现时，可以把模型打分和规则打分做一个线性融合：最终得分 = 0.8 * 模型概率 + 0.2 * 规则分。规则分可以简单定义为歌曲在近 7 天播放量上的归一化值。

6.3 我养成的习惯：每次改特征都重跑评估

第一版模型跑通后，我给自己定了个规矩：每次改特征、改阈值、改模型参数，都在同一份验证集上重跑评估，并记录 AUC、召回率、精确率三行数字。否则很容易出现“改了个特征感觉涨了，其实是上一次调参的收益”。这个习惯让我的毕业设计文档里每一版结果都有据可查。从那以后，我每次拿到这种推荐项目，都会强制自己先写一个evaluate.py，把评估指标和验证集固定住，再开始折腾模型。希望帮到你。

本文还有配套的精品资源，点击获取