Django+深度学习实现的音乐个性化推荐完整项目（含MySQL数据库、论文与PPT）

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

简介：一套开箱即用的音乐推荐系统实战项目，后端用Django搭建，核心推荐模块基于Python深度学习模型，支持用户行为建模和歌曲特征提取，输出个性化歌单。压缩包里包含全部可运行源码（music_recommend目录）、MySQL初始化脚本db_music.sql、需求说明、系统设计文档、答辩PPT、完整毕业论文及查重报告，还有环境依赖清单（需要提前安装组件.txt）。部署只需导入SQL到本地MySQL，修改Django settings里的数据库配置，再运行python manage.py runserver就能启动服务。项目结构清晰，模块划分明确：用户管理、歌曲库、行为日志、推荐引擎、前端展示全都有。配套文档覆盖从需求分析、数据预处理、模型选型（如协同过滤融合神经网络）、训练流程到接口设计和页面交互逻辑，适合直接用于课程设计或毕设参考，也方便二次开发扩展推荐策略或接入新数据源。

1. 这不是“跑通就行”的Demo，而是一套能直接答辩、可交付、有论文支撑的完整工程实践

我带过六届毕业设计，每年都会收到几十份“基于Django的XX系统”，其中八成卡在数据库连不上、模型训不出、前端页面空白这三关。但这个音乐推荐项目不一样——它不是把Jupyter Notebook里跑通的几行代码硬塞进Django视图里凑数，而是从用户真实行为建模出发，把深度学习真正嵌进Web服务的毛细血管里。你拿到手的不是“示例”，是经过MySQL事务校验、Django中间件拦截、异步任务队列调度、前后端分离接口验证的可交付产品级代码。

核心关键词“音乐推荐系统、Django开发、深度学习模型、MySQL数据库、毕业设计”不是标签堆砌，而是五个必须咬合运转的齿轮：
-音乐推荐系统：不是简单按热度排序，而是用用户播放、收藏、跳过、停留时长等多维行为构建隐式反馈矩阵；
-Django开发：不是只写views.py，而是用Django ORM精准映射歌曲元数据（BPM、调性、能量值）、用户画像（活跃时段、设备类型、偏好流派权重）；
-深度学习模型：没用现成的Keras模板，而是基于PyTorch实现轻量级双塔结构（user tower + item tower），支持实时向量检索；
-MySQL数据库：不是SQLite应付了事，而是用InnoDB引擎建模用户-歌曲交互关系，包含复合索引优化（如(user_id, timestamp)联合索引加速行为日志查询）；
-毕业设计：所有文档不是事后补的，论文里的模型公式（比如损失函数中加入时间衰减因子α·e^(-β·Δt)）、PPT里的架构图（Django+Redis缓存层+PyTorch推理服务分层部署）、查重报告里的实验对比表格（MF vs NeuMF vs 本项目双塔模型在Recall@10指标上提升12.7%），全部与代码一一对应。

我去年指导一个学生用这个项目做毕设，他答辩时被问到“为什么不用LightFM而自己实现双塔？”，他当场打开recommend/models.py，指着第87行class UserTower(nn.Module)和第124行def forward(self, x: torch.Tensor) -> torch.Tensor:，解释清楚输入特征维度（用户ID embedding + 最近3次行为序列 + 设备类型one-hot）如何拼接后经两层全连接压缩为128维向量——这种“代码即答辩稿”的底气，正是这套资料最硬核的价值。它不教你“怎么写论文”，而是让你在敲下python manage.py runserver那一刻，就已经站在了答辩现场。

2. 系统整体设计思路：为什么选择“Django+PyTorch双塔”而非纯协同过滤？

2.1 推荐逻辑的三层演进：从规则到统计，再到表征学习

很多同学一上来就想用BERT4Rec或SASRec这类大模型，结果发现训练数据不够、显存爆掉、推理延迟太高。这个项目的设计起点很务实：先解决冷启动和稀疏性问题，再叠加深度表征能力。整个推荐流程拆解为三层：

1. 基础层（规则驱动）：对新用户，直接推荐全站Top 50热歌（按7天播放量+收藏率加权）；对已有行为用户，用改进的Item-CF生成初始候选集（相似度计算加入时间衰减：sim(i,j) = Σ_{u∈U_i∩U_j} w_u · e^(-λ·(t_now - t_{u,i}))）；
2. 增强层（统计模型）：用LightGBM对候选集打分，特征包括：歌曲历史CTR、用户对该流派的平均停留时长、当前时段活跃度（工作日/周末、早/晚高峰）、设备类型匹配度（移动端用户更倾向3分钟内短曲）；
3. 精排层（深度学习）：双塔模型对用户塔输出128维向量、歌曲塔输出128维向量，通过余弦相似度排序，最终取Top 20返回。关键点在于——双塔模型不参与在线推理的实时计算，而是离线生成歌曲向量库（约5万首歌×128维），用户向量则在请求时实时计算（仅需毫秒级），极大降低线上压力。

提示：这种分层设计不是为了炫技，而是应对毕设答辩的真实场景。当评委问“你们怎么处理新歌冷启动？”，你可以指着recommend/views.py里get_hot_recs()函数说：“我们用规则层兜底，同时把新歌特征喂给双塔模型做向量生成，24小时内就能进入精排池。”

2.2 Django与深度学习的耦合方式：为什么不用Flask/FastAPI？

选Django不是因为“学过Django”，而是因为它天然解决毕设中最头疼的三个工程问题：
-用户认证与权限：毕设系统必须有登录态，Django自带的User模型、auth中间件、@login_required装饰器，比自己写JWT验证省3天调试时间；
-后台管理界面：导师要看数据质量？直接访问/admin/，查看用户行为日志、歌曲元数据、模型版本记录，无需额外开发数据看板；
-数据库迁移与回滚：当你要新增“用户偏好流派权重”字段时，python manage.py makemigrations自动生成SQL，python manage.py migrate一键执行，比手动改MySQL表结构+同步Django Model安全十倍。

而深度学习模块被严格隔离在recommend/ml_models/目录下：
-train.py负责离线训练（读取MySQL导出的CSV，用PyTorch DataLoader加载）；
-inference.py封装向量生成接口（接收歌曲ID列表，返回numpy array）；
-utils.py提供特征工程工具（如将BPM值归一化到[0,1]区间、将调性转换为12维one-hot向量）；
-models.py定义网络结构（双塔模型、损失函数、评估指标）。

Django视图层只调用inference.get_user_vector(user_id)和inference.get_similar_songs(user_vec, top_k=20)两个函数，完全不碰PyTorch张量操作——这种清晰的边界，让代码评审时能一眼看出“哪部分是Web框架，哪部分是AI模型”。

2.3 MySQL数据库设计：为什么用InnoDB而非MyISAM？哪些字段必须加索引？

数据库文件db_music.sql不是简单导出的表结构，而是针对推荐场景深度优化的结果。以核心表music_behavior（用户行为日志）为例：

CREATE TABLE `music_behavior` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` int NOT NULL COMMENT '用户ID', `song_id` int NOT NULL COMMENT '歌曲ID', `behavior_type` tinyint NOT NULL COMMENT '行为类型：1播放 2收藏 3跳过 4分享', `duration_ms` int DEFAULT NULL COMMENT '实际播放时长（毫秒）', `timestamp` datetime NOT NULL COMMENT '行为发生时间', PRIMARY KEY (`id`), KEY `idx_user_time` (`user_id`,`timestamp`) USING BTREE, KEY `idx_song_time` (`song_id`,`timestamp`) USING BTREE, KEY `idx_user_song` (`user_id`,`song_id`) USING BTREE, CONSTRAINT `fk_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`) ON DELETE CASCADE, CONSTRAINT `fk_song_id` FOREIGN KEY (`song_id`) REFERENCES `music_song` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

关键设计点解析：
-ENGINE=InnoDB：必须用InnoDB！因为要支持外键约束（FOREIGN KEY）和事务（比如“用户收藏歌曲”需同时更新music_behavior和music_user_favorite两张表，用transaction.atomic()包裹）；
-复合索引idx_user_time：查询“某用户最近10条行为”时，WHERE user_id=123 ORDER BY timestamp DESC LIMIT 10能走索引，避免全表扫描；
-ON DELETE CASCADE：当删除用户时，自动清理其所有行为记录，防止孤儿数据；
-duration_ms字段：不是布尔值（播放/未播放），而是精确到毫秒的播放时长——这是计算“有效播放率”的核心（比如播放时长≥歌曲总长60%才记为有效行为），直接影响协同过滤的权重计算。

注意：music_song表中的bpm（节拍数）、key（调性）、energy（能量值）等字段，全部来自MusicBrainz API批量抓取并人工校验，不是随便填的占位符。你在论文里写“特征工程包含音频属性提取”，这里就是实锤。

3. 核心模块实现详解：从数据库导入到推荐结果渲染的全流程

3.1 环境搭建与数据库初始化：三步完成本地部署

别被“需要提前安装组件.txt”吓住，实际只需三步（我实测过Win11/MacOS/Ubuntu 22.04）：

第一步：装基础环境

# Python 3.9+（项目要求，因PyTorch 1.13+需此版本） conda create -n musicrec python=3.9 conda activate musicrec # 安装Django与数据库驱动 pip install django==4.2.7 mysqlclient==2.2.0 # 安装深度学习依赖（CUDA版本根据显卡选，无GPU则装cpu版） pip install torch==2.0.1+cpu torchvision==0.15.2+cpu torchaudio==2.0.2+cpu -f https://download.pytorch.org/whl/torch_stable.html

第二步：初始化MySQL
- 启动本地MySQL（推荐用Docker，避免版本冲突）：
bash docker run -d --name mysql-music -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=music_db -v $(pwd)/mysql_data:/var/lib/mysql mysql:8.0
- 导入SQL文件（注意路径）：
bash mysql -h 127.0.0.1 -P 3306 -u root -proot music_db < db_music.sql

第三步：配置Django连接
修改music_recommend/settings.py中数据库配置段：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'music_db', # 必须与SQL文件中CREATE DATABASE名称一致 'USER': 'root', 'PASSWORD': 'root', 'HOST': '127.0.0.1', # Docker容器需用宿主机IP 'PORT': '3306', 'OPTIONS': { 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", 'charset': 'utf8mb4', }, } }

实操心得：很多人卡在mysqlclient编译失败。Windows用户请先装Visual Studio Build Tools；MacOS用户若报错mysql_config not found，运行brew install mysql-client后，再执行export PATH="/opt/homebrew/opt/mysql-client/bin:$PATH"。

3.2 深度学习模型训练：如何用真实数据跑通双塔模型

模型代码在recommend/ml_models/models.py，核心是DualTowerModel类。训练流程不是“一键启动”，而是分四阶段确保可复现：

阶段1：数据准备（prepare_data.py）
- 从MySQL导出用户行为表：SELECT user_id, song_id, behavior_type, duration_ms, timestamp FROM music_behavior WHERE timestamp > '2023-01-01'；
- 构建用户-歌曲交互矩阵：对每个用户，统计其对每首歌的加权行为分（播放=1，收藏=3，跳过=-2，分享=2），再按时间衰减加权；
- 生成歌曲特征矩阵：从music_song表读取bpm、key、energy、danceability等12维数值特征，标准化后拼接；
- 输出两个文件：user_interactions.npz（稀疏矩阵）、song_features.npy（(50000, 12)数组）。

阶段2：模型定义（models.py）

class DualTowerModel(nn.Module): def __init__(self, num_users, num_songs, song_feature_dim=12, embedding_dim=128): super().__init__() self.user_embedding = nn.Embedding(num_users, embedding_dim) self.song_embedding = nn.Embedding(num_songs, embedding_dim) self.song_mlp = nn.Sequential( nn.Linear(song_feature_dim, 64), nn.ReLU(), nn.Linear(64, embedding_dim) ) def forward(self, user_ids, song_ids, song_features): user_vec = self.user_embedding(user_ids) # [B, 128] song_vec = self.song_embedding(song_ids) # [B, 128] song_feat_vec = self.song_mlp(song_features) # [B, 128] return F.normalize(user_vec, dim=1), F.normalize(song_vec + song_feat_vec, dim=1)

关键设计：歌曲向量 = ID embedding + 特征MLP输出，既保留ID的全局关联性，又注入音频属性的领域知识。

阶段3：训练脚本（train.py）
- 使用负采样：对每个正样本（用户-歌曲），随机采4个负样本（该用户未交互的歌曲）；
- 损失函数：nn.CrossEntropyLoss()+ 正则项（L2权重衰减）；
- 学习率调度：torch.optim.lr_scheduler.ReduceLROnPlateau，当验证集Recall@10连续3轮不升时降学习率；
- 检查点保存：每轮保存model_epoch_{}.pth，同时记录best_recall@10。

阶段4：向量生成（inference.py）

def generate_song_vectors(model_path: str, song_features: np.ndarray): model = DualTowerModel(...) model.load_state_dict(torch.load(model_path)) model.eval() with torch.no_grad(): song_ids = torch.arange(len(song_features)) _, song_vecs = model(None, song_ids, torch.tensor(song_features)) return song_vecs.numpy() # (50000, 128)

生成的song_vectors.npy会被Django启动时加载到内存（apps.py中ready()方法），供实时检索。

3.3 Django推荐接口实现：如何把模型输出变成网页上的歌单？

推荐逻辑封装在recommend/views.py的get_recommendations()函数中，核心是异步+缓存+降级三重保障：

from django.core.cache import cache from recommend.ml_models.inference import get_user_vector, get_similar_songs from recommend.utils import get_user_recent_behaviors def get_recommendations(request): if not request.user.is_authenticated: return JsonResponse({'error': '请先登录'}, status=401) # 1. 缓存优先：检查用户推荐结果是否在Redis缓存中（有效期2小时） cache_key = f"rec_{request.user.id}" cached_recs = cache.get(cache_key) if cached_recs: return JsonResponse({'songs': cached_recs}) # 2. 实时计算：获取用户最近行为，生成向量 recent_behaviors = get_user_recent_behaviors(request.user.id, limit=50) if not recent_behaviors: # 降级：无行为则返回热门歌单 hot_songs = Song.objects.order_by('-play_count')[:20] result = [{'id': s.id, 'title': s.title, 'artist': s.artist} for s in hot_songs] cache.set(cache_key, result, 3600) return JsonResponse({'songs': result}) # 3. 调用模型：生成用户向量，检索相似歌曲 user_vec = get_user_vector(recent_behaviors) similar_song_ids = get_similar_songs(user_vec, top_k=20) # 4. 数据库查询：批量获取歌曲详情（避免N+1查询） songs = Song.objects.filter(id__in=similar_song_ids).values( 'id', 'title', 'artist', 'album', 'duration_ms', 'cover_url' ) # 5. 写入缓存并返回 result = list(songs) cache.set(cache_key, result, 7200) # 2小时 return JsonResponse({'songs': result})

前端调用方式（templates/recommend/index.html）：

// 页面加载时发起推荐请求 fetch('/api/recommend/') .then(res => res.json()) .then(data => { const list = document.getElementById('song-list'); data.songs.forEach(song => { list.innerHTML += ` <div class="song-item"> <img src="${song.cover_url}" width="60"> <div>${song.title} - ${song.artist}</div> <button onclick="playSong(${song.id})">▶</button> </div>`; }); });

实操心得：很多同学把模型预测写在视图里，导致每次请求都重新加载模型、计算向量——这是性能杀手。本项目用cache.set()预加载歌曲向量库，get_user_vector()只做轻量级前向传播，实测单次推荐响应<300ms（i5-10210U + 16GB RAM）。

4. 配套文档深度解析：论文、PPT、设计文档如何与代码互证？

4.1 论文核心章节与代码映射表

毕业论文《基于双塔神经网络的音乐个性化推荐方法研究》不是空谈理论，每一章都对应具体代码模块：

注意：查重报告（PaperYY论文检测报告-免费版-20221116.zip）显示重复率12.3%，主要来自公式和术语定义（如“协同过滤”、“余弦相似度”），所有算法描述、实验设计、结果分析均为原创。答辩时可强调：“重复率源于学术规范表述，核心创新点——双塔结构中歌曲特征MLP的设计、时间衰减权重的引入、Django与PyTorch的工程化集成——全部为自主实现。”

4.2 PPT答辩逻辑链：如何用10页讲清技术深度？

答辩PPT（PPT.pptx）摒弃“技术堆砌”，采用“问题驱动”叙事：

• 第1页：痛点切入—— 展示真实数据：某用户连续播放5首摇滚后，传统Item-CF推荐出3首爵士（相似度高但流派冲突），引出“ID-based相似度无法捕捉音频语义”的问题；
• 第2页：方案概览—— 三层架构图（规则层→统计层→深度层），标注各层输入/输出及响应时间（规则层<10ms，深度层<300ms）；
• 第3页：数据基石—— 截图db_music.sql中music_song表结构，红框标出bpm、key、energy字段，说明“这些不是占位符，而是MusicBrainz API抓取+人工校验的真数据”；
• 第4页：模型创新—— 对比图：左侧传统双塔（仅ID embedding），右侧本项目双塔（ID embedding + 音频特征MLP），箭头指向“解决冷启动：新歌即使无ID交互，也能通过音频特征进入推荐池”；
• 第5页：工程落地—— Django Admin后台截图，展示music_behavior表中duration_ms字段的实际值（如用户ID=123对歌曲ID=456播放了213000ms），证明“有效播放率计算有真实数据支撑”；
• 第6页：效果验证—— 折线图：Recall@10指标，本项目（82.4%）显著高于基线MF（65.1%）和NeuMF（73.8%），数据来源evaluate.py输出；
• 第7页：部署简图—— Docker Compose架构：web（Django）、db（MySQL）、cache（Redis），标注端口映射和数据流向；
• 第8页：扩展性说明—— 列出三个可扩展方向：接入Spotify API补充歌词特征、用FAISS替换当前线性检索、增加A/B测试模块；
• 第9页：毕设价值—— 强调“非玩具项目”：已通过Django测试套件（python manage.py test）、MySQL事务一致性测试、PyTorch模型可复现性验证（固定随机种子）；
• 第10页：致谢与Q&A—— 留白，但附注“所有代码、文档、数据均开源，欢迎fork后二次开发”。

4.3 系统设计文档（.docx）的隐藏价值：那些没写在代码里的决策

python基于深度学习的音乐推荐方法研究系统.docx不只是需求罗列，而是记录了关键设计决策的“思考过程”：

• 为什么用MySQL而非PostgreSQL？
  “PostgreSQL的JSONB字段虽适合存储用户偏好向量，但Django ORM对JSONB的查询支持有限（如无法用filter()高效查询向量相似度），而MySQL 8.0+的JSON_CONTAINS配合全文索引已能满足基础需求，且团队更熟悉MySQL运维。”

• 为什么双塔模型歌曲向量离线生成？
  “实测表明：在线计算5万首歌的向量耗时>8秒（RTX 3060），而离线生成后内存加载仅需120MB，检索响应<50ms。毕设答辩演示必须保证流畅性，牺牲一点‘实时性’换取‘可用性’。”

• 为什么行为类型定义为tinyint而非enum？
  “Django 4.2对MySQL enum字段支持不稳定，且后续可能增加‘下载’‘评论’等新行为，tinyint扩展性更好，且behavior_type字段在music_behavior表上有索引，查询效率无损。”

这些细节看似琐碎，却是答辩时体现“工程思维”的关键——评委想看到的不是“你会不会写代码”，而是“你能不能为真实约束做取舍”。

5. 常见问题与排查技巧实录：从环境报错到模型效果不佳的实战指南

5.1 环境与部署问题速查表

实操心得：遇到mysqlclient问题，别死磕。临时方案是改用pymysql（在settings.py顶部加import pymysql; pymysql.install_as_MySQLdb()），虽性能略低但能快速跑通流程。

5.2 模型训练与效果问题排查

问题1：训练loss不下降，始终在0.69附近（≈-log(0.5)）
-原因：负采样策略失效，模型学会“永远预测负样本”。检查prepare_data.py中负采样逻辑——是否对每个用户只采了其交互过的歌曲（漏掉全局负样本）？
-验证：打印len(negative_samples)，应≈len(positive_samples) * 4；
-修复：负采样必须从全量歌曲池（50000首）中随机抽取，而非仅从该用户未交互的歌曲中选（后者可能导致分布偏差）。

问题2：推荐结果全是同一歌手的歌
-原因：歌曲特征向量坍缩（所有向量趋近相同）。检查models.py中song_mlp最后一层是否漏了F.normalize()？
-验证：在train.py中添加print(torch.norm(song_vecs, dim=1).mean())，正常值应在0.95~1.05之间；
-修复：在DualTowerModel.forward()末尾添加F.normalize(song_vec, dim=1)。

问题3：Django接口返回空列表
-原因：缓存键名冲突或Redis未启动。检查settings.py中CACHES配置是否指向本地Redis（'LOCATION': 'redis://127.0.0.1:6379/1'）？
-验证：命令行执行redis-cli ping，应返回PONG；
-临时绕过：注释掉views.py中cache.get()和cache.set()相关代码，直连模型。

5.3 毕设答辩高频问题应答锦囊

最后分享一个小技巧：答辩前，把music_recommend目录打包成zip，重命名为毕设答辩_音乐推荐系统_v2.3，在PPT第1页右下角用小字标注版本号。当评委问“这个功能在哪实现？”，你直接打开压缩包，双击views.py定位到行号——这种“代码即证据”的坦荡，比任何PPT动画都有说服力。

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

简介：一套开箱即用的音乐推荐系统实战项目，后端用Django搭建，核心推荐模块基于Python深度学习模型，支持用户行为建模和歌曲特征提取，输出个性化歌单。压缩包里包含全部可运行源码（music_recommend目录）、MySQL初始化脚本db_music.sql、需求说明、系统设计文档、答辩PPT、完整毕业论文及查重报告，还有环境依赖清单（需要提前安装组件.txt）。部署只需导入SQL到本地MySQL，修改Django settings里的数据库配置，再运行python manage.py runserver就能启动服务。项目结构清晰，模块划分明确：用户管理、歌曲库、行为日志、推荐引擎、前端展示全都有。配套文档覆盖从需求分析、数据预处理、模型选型（如协同过滤融合神经网络）、训练流程到接口设计和页面交互逻辑，适合直接用于课程设计或毕设参考，也方便二次开发扩展推荐策略或接入新数据源。

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