简介这是一份基于Python深度学习的音乐流行趋势预测系统完整项目配套设计报告和部署文档适合计算机相关专业人工智能、通信、自动化等学生用于课程设计、毕业设计或项目立项演示。系统涵盖数据预处理、特征工程、深度学习建模与趋势预测等环节案例源自音乐流行趋势预测竞赛场景并内置Django与Flask两套部署文档方便按环境选用。压缩包共64个文件整体约14.52MB其中36个ipynb为主力代码文件涵盖数据探索、模型训练与可视化13个csv和3个xlsx存放音乐数据及特征表3个pdf、3个md和2个caj包含研究论文、部署说明与赛题资料另有2个html页面和1个png预览图。目录结构清晰便于快速定位。已有244人学习下载代码经测试运行成功附设计报告、阿里音乐流行趋势预测大赛赛题与问答资料既能帮助读者完整理解项目脉络、复现预测流程也可作为毕业设计或竞赛方案的二次开发基础更是算法入门到工程落地的桥接案例。1. 音乐流行趋势预测为什么这件事比「推荐算法」更值得做先说一个反直觉的结论判断一首歌会不会火一个训练得当的深度学习模型往往比资深乐评人更稳但这套系统的难点从来不在模型结构而在「流行趋势」这四个字到底怎么定义成机器能学的目标。很多照着这套毕设选题开工的人前两周都花在纠结「我到底在预测什么」上——是预测播放量预测榜单排名还是预测一首歌什么时候进入上升期这决定了你的数据标注、模型选型和最后报告的写作逻辑。这套基于 Python 深度学习的音乐流行趋势预测系统本质上是一个时间序列预测项目输入一首歌过去若干周期的播放、收藏、分享等行为数据输出它未来一段时间的流行度走势。它与传统推荐算法的区别在于推荐解决的是「用户喜欢什么」而趋势预测解决的是「市场接下来会追捧什么」。适合谁来用一类是正在做音乐数据相关毕设或课设的同学需要完整跑通「数据清洗 → 特征工程 → 模型训练 → 部署展示」全链路另一类是对音乐流媒体运营感兴趣的数据从业者想验证深度学习在文化内容领域的边界。这篇文章按我自己做过的类似方案展开从标签构造、模型选型、训练调参到部署验证尽量把能复现的细节都写出来。2. 把「流行趋势」定义成模型能学的问题数据源与标签构造2.1 先想清楚预测目标是分类问题、回归问题还是序列问题很多人拿到这个题目第一反应是「预测这首歌火不火」然后直接套一个二分类模型。这其实是第一个大坑。「火不火」是一个静态概念而「趋势」天然带时间维度——一首歌可能第 4 周还在榜尾第 8 周突然冲到榜首第 12 周又回落。如果只预测「最终会不会火」等于把过程信息全扔掉了模型学到的东西也没有运营价值。我一般会把任务拆成回归问题来处理预测一首歌在未来 N 个时间窗口内的流行度数值序列。具体来说假设我们已经按周聚合了每首歌的播放量、收藏数、分享数那么训练目标就是给定前 T 周的特征序列预测后 H 周的播放量或标准化后的流行度得分。这个设定下模型输出的是一个长度为 H 的向量而不是单个标量既保留了趋势的形态信息也能在报告里画出漂亮的预测对比曲线。如果你的导师要求做成分类可以把预测结果映射到「上升期 / 平稳期 / 衰退期」三档但内部模型还是按回归训练只是换了一个损失函数。另一个需要考虑的问题是数据粒度。按天预测噪声太大周度数据是常见折中——一首歌的生命周期通常在几个月到一年按周聚合既能平滑掉单日波动又能保留足够的序列长度。我建议至少保留 24 周以上的历史数据作为模型输入窗口否则序列模型很难学到有意义的周期模式。2.2 公开数据源怎么选Spotify 与 Last.fm 的字段取舍做这个题目绕不开数据获取。常见的公开数据源有两个Spotify Web API 和 Last.fm API。Spotify 的特点是字段丰富尤其是audio_features那一组——danceability、energy、valence、tempo 等这些音频特征对模型来说是非常好的辅助信号。缺点是流行的单曲数据受地区限制且 API 对历史榜单的访问能力有限你只能从当前时间点往后爬很难补全一首歌发布后完整的生命周期曲线。Last.fm 的优势在于它有每首歌的周度播放排行历史能拿到一首歌过去几年的播放趋势正好弥补 Spotify 的短板。缺点是没有丰富的音频特征字段。常见做法是把两者结合用 Last.fm 拿趋势序列用 Spotify 拿音频特征和歌曲元数据以「艺术家名 歌曲名」作为 join key。需要注意这个 join key 并不可靠——同名歌曲、Remix 版本、大小写差异都会导致匹配失败我在实践中用「艺术家名 歌名 时长」三元组做匹配漏匹配率从 15% 降到 3% 左右。清洗后需要移除纯音乐和翻唱版本否则模型会学到「翻唱比原唱火」这种和你要预测的目标无关的噪声规律。SELECT s.artist_name, s.track_name, s.duration_ms, l.week_start, l.play_count, f.danceability, f.energy, f.valence FROM spotify_tracks s JOIN lastfm_trends l ON lower(s.artist_name) lower(l.artist_name) AND lower(s.track_name) lower(l.track_name) AND abs(s.duration_ms - l.duration_ms) 2000 JOIN spotify_features f ON s.track_id f.track_id WHERE s.duration_ms 150000这段 SQL 是在做数据合并时的核心逻辑。三个条件分别解决同名歌曲的三种误匹配场景准确度是「大小写不一致」匹配策略是统一转小写Remix 和 Live 版本时长通常差异较大用 2 秒以内的时长差过滤纯音乐时长通常极短或极长过滤掉 150 秒以下的作品降低无关样本比例。执行完这步你就拿到了一张「每首歌 × 每个周 × 特征 播放量」的宽表接下来才好做标签构造。2.3 标签构造用滑窗把趋势曲线切成训练样本拿到原始宽表后还不能直接喂给模型。我们需要把每首歌的长序列切成(输入窗口, 预测窗口)的样本对。假设一首歌有 40 周的播放数据输入窗口 T12预测窗口 H4那么这首独苗歌能产生 40 - 12 - 4 1 25 个训练样本。如果你把整首歌作为一个样本输入 LSTM样本量会严重不足泛化能力很差。def build_samples(trend_series, input_len12, pred_len4): samples_x, samples_y [], [] for i in range(len(trend_series) - input_len - pred_len 1): x trend_series[i:i input_len] y trend_series[i input_len:i input_len pred_len] samples_x.append(x) samples_y.append(y) return np.array(samples_x), np.array(samples_y)这段代码的核心思想是滑窗采样。每个样本的 x 是过去 12 周的流行度序列y 是未来 4 周的流行度序列两个窗口在时间轴上连续移动让模型看到各种不同的上升、下降、波动片段。滑窗的步长为 1 会让相邻样本高度相似但在这个数据量级下是可以接受的——它相当于一种数据增强让模型在不同相位上都见过趋势形态。如果你的数据量较大可以把步长改成 3 或 5 来降低样本冗余、加快训练速度如果数据量很小步长保持 1不要随意加大。这里还有一个容易被忽略的点标签 y 需要做归一化。不同歌曲的播放量数量级差异巨大Ed Sheeran 的新歌首周播放量可能是独立音乐人的几百倍。我在这里做了 z-score 归一化然后用同一个 scaler 对每首歌单独归一化而不是全量数据一起 fit——这一步是防止数据泄漏的关键后面避坑章节会展开。归一化之后模型学的不是绝对播放量而是「相对自己历史水平的涨跌」这对跨歌曲泛化至关重要。3. 特征工程与模型选型为什么常见方案首选 LSTM 而不是 CNN 或 Transformer3.1 三类特征趋势特征、音频特征、上下文特征数据准备好了接下来要梳理模型输入到底用什么特征。我做过的实践里特征分三类每类的信息密度和获取成本差别很大。第一类是趋势特征也就是播放量、收藏数、分享数、评论数的历史序列这是整个模型的骨架反映歌曲当前的生命周期阶段。第二类是音频特征包括 Spotify 提供的 danceability、energy、valence、tempo、acousticness 等它们描述歌曲本身的物理属性不随时间变化作为静态特征拼接到每个时间步上。第三类是上下文特征比如发行日期、艺人历史热度、是否签约大厂牌这些信息在部分数据源里能拿到对趋势预测的修正作用很明显。实际建模时我倾向于把三类特征拼成一个特征向量在每一个时间步上输入模型。趋势特征随时间变化每行不同而音频特征在整个序列上重复相当于给每个时间步加了一个「这首歌听起来像什么」的常量旁路。这种做法比「只输入趋势特征」的准确率高 58 个百分点代价是特征维度变大训练时间小幅上升整体可控。3.2 模型选型的边界LSTM 是性价比最高的起点现在的深度学习方案里序列建模有三个常见选择LSTM、Transformer、TCN时间卷积网络。很多毕设报告一上来就写「用 Transformer 替代 LSTM 提升效果」但我不建议你这么做原因很实际。第一音乐趋势预测的序列长度通常只有 1224 个时间步Transformer 的自注意力机制在这个长度下没有明显优势反而因为数据量不够很容易过拟合。第二LSTM 对「近期模式」有天然的偏置——门控机制会优先记住最近几个时间步的输入而这恰好符合流行趋势的特点上周的涨跌比 3 个月前的涨跌更能预示下周的走势。第三在小数据集上LSTM 训练比 Transformer 稳定得多调参空间也小不会出现那种「同一套参数跑两次结果差 10%」的玄学现象。那什么时候值得上 Transformer如果你手里的数据量很大比如几万首歌、每首歌 52 周以上的周度数据并且想把节假日、宣发周期这类长期依赖信息建模进去Transformer 的优势才显现出来。在数据量不足时强行上 Transformer典型表现是验证集损失先降后升训练集损失一路走低——经典的过拟合曲线。这不是你的代码有问题是模型的容量超过了数据能支撑的上限。常见做法是先用 LSTM 跑通一个端到端基线再在基线上尝试增强模型这样报告里也能做对比实验。3.3 最小实现用 PyTorch 搭建一个可训练的 LSTM 趋势预测模型下面给一个能直接跑通的最小实现。这里我按 PyTorch 写因为它在学术场景和毕设中的普及度最高网上资料也好找。模型结构很简单两层 LSTM 一个全连接输出层输入维度是特征数输出维度是预测窗口长度。import torch import torch.nn as nn class TrendLSTM(nn.Module): def __init__(self, input_size, hidden_size64, num_layers2, pred_len4): super().__init__() self.lstm nn.LSTM( input_sizeinput_size, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, dropout0.2 if num_layers 1 else 0.0 ) self.regressor nn.Sequential( nn.Linear(hidden_size, 32), nn.ReLU(), nn.Dropout(0.1), nn.Linear(32, pred_len) ) def forward(self, x, hiddenNone): # x: [batch, seq_len, features] out, hidden self.lstm(x, hidden) # 取最后一个时间步的输出 last_step out[:, -1, :] return self.regressor(last_step)模型逻辑分三段说。nn.LSTM接收三维输入——batch 大小、序列长度、特征维度batch_firstTrue让维度顺序更直观num_layers2代表堆叠两层 LSTM第二层能学到第一层输出之上的更高层抽象但超过两层在短序列上收益骤减而且训练变慢。dropout0.2只在层数大于 1 时生效这是 PyTorch 的一个约定——单层 LSTM 传 dropout 参数不会报错但会静默忽略。regressor拿最后一个时间步的隐状态做回归因为我们的任务是预测未来不是做序列到序列翻译用最后一个隐状态浓缩整段历史信息就够了。训练主循环我一般单独写一个函数不放进模型类里方便调整 batch size 和优化器def train_model(model, train_loader, val_loader, epochs50, lr1e-3): optimizer torch.optim.Adam(model.parameters(), lrlr, weight_decay1e-5) criterion nn.MSELoss() best_val float(inf) for epoch in range(epochs): model.train() train_loss 0.0 for x_batch, y_batch in train_loader: optimizer.zero_grad() pred model(x_batch) loss criterion(pred, y_batch) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() train_loss loss.item() # 早停逻辑 val_loss evaluate(model, val_loader, criterion) if val_loss best_val: best_val val_loss torch.save(model.state_dict(), best_model.pt) print(fepoch {epoch}: train_loss{train_loss:.4f}, val_loss{val_loss:.4f})这里有一个值得注意的细节clip_grad_norm_把梯度的范数裁剪到 1.0 以内。LSTM 在长序列上容易梯度爆炸导致 loss 在某个 step 突然跳到nan——这是训练循环里最常遇到的问题没有之一。加了梯度裁剪后即使偶尔出现大梯度也会被限制在一个安全范围内训练过程会稳定很多。weight_decay1e-5是 L2 正则化的实现方式在小数据集上能有效抑制过拟合。best_model.pt每次验证集 loss 创新低就保存一次这样即使后面 epoch 过拟合了也有「后悔药」可用。4. 训练与调参直接影响预测精度的四组参数4.1 输入窗口与预测长度的搭配12/4 与 24/8 的选择逻辑在 2.3 节的滑窗采样里我已经用了input_len12, pred_len4作为默认值。这个默认值不是拍脑袋定的它服务于一个具体的建模目标一周播放量数据代表一个时间点12 周的输入窗口让模型能看到一个季度内的完整形态——包括歌曲发行初期的爆发、平台推广带来的小高峰、自然回落这三个阶段。预测窗口 4 周对应大约一个月这足够运营方做一次决策又不会因为预测周期太长而让误差大到失去参考价值。如果你想预测更长远的趋势把参数改成input_len24, pred_len8会带来两个连锁变化第一样本数量减少——每首歌能切的滑窗数从总周数 - 16 1减少为总周数 - 32 1当歌曲总周数只有 40 时样本量会减少一半第二模型需要学习的映射关系变复杂了24 步的输入到 8 步的输出信息跨越时间更长梯度传播路径更深LSTM 的收敛速度会明显变慢。我的经验是数据量少于 5000 条样本时坚持用 12/4不要为了「预测得更远」牺牲样本数量数据量大到两万以上再试 24/8。有一种取巧的做法是把预测窗口切成两段分步预测——先预测 4 周再把输出接回输入继续迭代预测 4 周这在论文里叫多步预测的自回归方式实际效果一般是误差累加不如直接预测 8 周一刀切。4.2 学习率与归一化范围两个最常被忽略的随机因素学习率是 LSTM 训练中「玄学」成分最高的参数。1e-3是 Adam 优化器配合回归任务的常见起点但要注意它和归一化范围之间有一个隐藏的耦合关系。如果你把播放量归一化到 01 区间而不是 z-score 标准正态分布会让损失函数的曲率变得不均匀——数值大多集中在 0.20.8 之间梯度在某些区域特别陡峭1e-3的学习率可能直接让 loss 发散。我一般做法是归一化到标准正态分布配1e-3起步归一化到 01 区间配5e-4起步。如果训练了 10 个 epoch 后验证集 loss 纹丝不动首要检查不是调网络结构而是把学习率降到1e-4看 loss 是否有下降趋势。可能只需要 50 行代码就能省下你一下午的排查时间。batch size 的影响相对平滑。音乐趋势数据集的样本之间独立性比较强不像图片样本那样有天然的小批量语义所以 batch size 从 32 调到 128 对最终精度影响不大主要影响的是训练速度和显存占用。我在 CPU 上跑小数据集时用 64切到 GPU 后用 256最终精度差异不到 1%。4.3 防过拟合时间序列交叉验证的正确打开方式文本数据随机切分训练集和验证集是一个常见的翻车动作。因为相邻滑窗样本来自同一首歌的同一段趋势曲线随机切分会导致验证集里有大量和训练集重叠的信息——模型实际上已经「看过」验证集的过去 12 周了val_loss 虚低测试时真实表现打对折还多。时间序列交叉验证的标准做法是按时间段切分比如用第 140 周的数据做训练第 4144 周的数据做验证模拟「用历史预测未来」的真实场景。这里有一个取舍按时间切分后验证集的样本量通常会很小只有几百条导致验证集 loss 抖动剧烈。我见过不少人遇到这种情况后又退回随机切分「图省事」结果在答辩时被老师一个问题问穿。另一种做法是按歌曲切分——把 80% 的歌曲作为训练集20% 完全不进入训练过程的歌曲作为验证集。这种方式验证的是「模型能否预测它没见过的歌曲」更接近真实应用而且避免了时间切分样本量不足的问题。我一般两种都做在报告里对比呈现按时间切分验证 Trend 预测的连续性按歌曲切分验证模型的泛化能力。如果两者结果差在 3% 以内说明模型是稳健的如果差值超过 10%说明模型有严重的记忆倾向需要加 Dropout 或降低模型容量。4.4 序列长度归一化与掩码处理到了这一步很多复现方案会忽略一个细节不同歌曲的有效历史长度是不同的。有的歌发行 10 周就跌出榜单有的歌在榜 60 周还在榜单中部。直接把所有序列 padding 到同一个长度再喂给模型是有问题的——padding 部分都是 0而真实的 0 播放量可能代表「未发行」而不是「没人听」模型会被这个语义混淆带偏。常见解法是引入一个掩码向量标记哪些时间步是真实数据、哪些是 padding。LSTM 的batch_first输入配合pack_padded_sequence可以按真实长度压缩序列让模型跳过 padding 段。不过这个操作的代码会让新手劝退我个人的建议是如果你在构建滑窗时强制每首歌只保留超过input_len pred_len周的部分那么所有进入模型的序列天然是等长的不需要额外处理。丢弃那些历史太短的歌曲样本损失的只是一小部分长尾数据换来的是代码简洁和训练稳定。在数据量充足时这是更务实的选择。5. 避坑做这套系统最容易翻车的 5 个环节5.1 播放量归一化参数泄漏验证集永远虚高现象训练集 loss 正常下降验证集 loss 也一路走低但把模型拿到真实新歌上预测误差比验证集高出一倍。原因你在构造特征时把全部歌曲的播放量拿在一起求均值和标准差然后用同一组参数做归一化。滑窗切割之后验证集样本的归一化数值里已经包含了训练集歌曲的信息。模型在训练时「间接看到了」验证集的统计量这在深度学习里叫标签泄漏的常见变体。解决归一化要按歌曲分组进行每首歌用自己的均值和标准差做 z-score然后将训练集和验证集严格按不同歌曲切分。这样每首歌的归一化参数相互独立泄漏通道被切断。验证泄漏是否还存在的方式很简单用验证集歌曲里mean 0, std 0的样本单独跑一轮预测看误差分布是否和全量验证集一致。5.2 热门歌样本严重不平衡准确率高但毫无用处现象模型报告显示整体准确率 92%但你点开预测结果发现所有被预测为「会火」的歌其实都是原本就很火的歌真正处于上升期的冷门歌几乎全被漏掉了。原因样本分布天然倾斜——头部歌曲在数据集中占比不到 5%但它们的播放量绝对值占了大头。模型只要学会「播放量高的歌继续高」MSE 就能很低对「趋势拐点」的预测能力几乎为零。解决除了 MSE同步记录预测值相对真实值的符号方向是否正确——即模型预测的是「上升」还是「下降」方向单独统计这个方向准确率。如果方向准确率徘徊在 55% 以下说明模型在预测拐点上是失效的。缓解手段是在损失函数里对播放量变化率加权把(预测值 - 真实值) / 真实值的相对误差加入 loss让模型更关注变化而非绝对数量。5.3 部署文档里的 Python 版本和实际环境对不上现象按照资料包里的部署文档执行到某一步突然报错AttributeError: module numpy has no attribute float或者ImportError: cannot import name register from torch。原因文档里写的是Python 3.7 PyTorch 1.8 numpy 1.19但你的机器装的是Python 3.10 PyTorch 2.0 numpy 1.24。老代码里常见的np.float、np.int在新版 numpy 中被移除PyTorch 2.0 也改了不少 API。而旧环境又没有因为老版本 numpy 在 Python 3.10 上装不上——这就是「部署文档与实际环境不一致」的经典死结。解决不要在新环境里硬跑旧文档。优先在项目包中寻找requirements.txt或environment.yml如果找不到去看训练脚本头部 import 了哪些库然后根据这些库的版本来确定 Python 版本——PyTorch 1.8 时代对应 Python 3.7/3.8PyTorch 2.0 时代对应 Python 3.83.10。用 conda 建一个干净环境并锁定小版本比在全局环境里逐个修仓库依赖要快得多。这类问题被记录为部署文档中的高频报错点是有现实依据的——我在复现不少开源项目时80% 的排查时间都花在版本对齐上。5.4 训练出来的模型在推理时输出全为同一个值现象模型加载后做推理无论输入什么歌曲数据输出都是一条平坦的直线等于不同歌曲预测结果几乎相同。原因这大概率不是模型没训练好而是推理预处理时用了错误的归一化参数。训练时每首歌单独归一化推理时如果用全数据集的均值和标准差替代单曲的均值和标准差输入分布就会错位——模型看到的是完全不同的数值范围LSTM 的门控机制被偏向一侧输出自然收敛到一个常数。解决在保存模型权重的同时把每首歌的归一化参数每组均值和标准差一并存成 JSON 或 pkl 文件。推理时先根据目标歌曲的 ID查表获取对应的归一化参数还原出正确的模型输入。如果你的部署架构是 API 形态建议把归一化参数封装成预处理函数的一部分而不是在客户端做。5.5 趋势标签的定义在不同时间段会漂移现象模型上线后表现正常但两个月后预测精度逐步下滑甚至出现把明显衰退期的歌预测为上升期的错误。原因音乐流行趋势的定义不是静态的。一首歌在 2023 年的「火」和 2019 年的「火」对应的播放量阈值完全不同短视频平台的兴起让歌曲走红的周期从三个月缩短到两周。模型在历史数据上学习到的「上升期模式」可能在新时段内不再适用。解决定期用最近 8 周的数据重训练模型或者至少每周跑一次增量训练——只拿新样本微调最后两层不重新训练整个网络。增量训练的稳定性也更适合线上环境。作为备用手段监控预测值和真实值的偏差均值当偏差均值连续两周超过历史水平的 1.5 倍时触发自动重训练流程。6. 部署与验证把模型变成可调用的趋势预测接口6.1 模型导出与 API 封装从.pt文件到 Flask 服务的最小路径训练好的模型要真正可用不能停留在 notebook 里。常见的做法是用 Flask 封装一个轻量 API模型用torch.load加载后常驻内存每次请求直接走 forward不需要重新加载权重。这里有一个关键点是模型状态字典的加载方式——如果训练时用了model.state_dict()保存加载时必须先实例化一个同结构的TrendLSTM再调用load_state_dict。直接torch.load(best_model.pt)得到的是裸模型如果没有先定义类会报AttributeError。一个值得注意的细节是模型服务里不要包含数据清洗逻辑。数据清洗和特征构造放在服务外部通过请求参数传入已经处理好的特征序列这样 API 的服务端代码可以保持简洁也不容易出现「服务端和训练脚本里归一化逻辑不一致」的问题。训练脚本负责产出模型和特征参数API 只负责加载模型、接收特征、输出预测这条边界划清楚后后续调试会轻松很多。如果项目要求更高也可以考虑 ONNX 导出用onnxruntime替代 PyTorch 推理好处是部署环境不需要装 PyTorch坏处是 LSTM 的动态图转换需要额外处理——毕设场景里不推荐花的时间不值得。6.2 上线前的验证方法回测和滚动预测怎么取舍上线前有一个步骤很多人会跳过直接用历史数据重新预测一遍未来把预测结果和真实走势对比画出曲线。这个动作叫回测它能直观地告诉你模型在真实场景里有多准。回测有两个具体版本一是静态回测固定训练截止时间然后用截止时间之后的数据做预测二是滚动回测——每预测完 4 周就把这 4 周的真实数据并入训练集更新模型后继续预测下一个 4 周。滚动回测更接近真实部署环境因为线上模型确实会定期重训练但它的计算成本也更高每次更新都要重跑一次训练。适合毕设场景的验证指标有三个维度平均绝对误差MAE衡量整体偏差水平预测方向准确率衡量趋势判断能力峰值点命中率衡量「是否能预测到爆发周」。三个指标一起看才能给你的设计报告写出有说服力的数据分析。只放一个 MAE 值答辩时老师大概率会追问「你这个误差水平算好还是不好」到时候很难回答。6.3 更进一步从单一 LSTM 到多信号融合模型的进阶方向是把单模型扩展成多信号融合。我在实际项目中常做的一个升级是在 LSTM 的特征输入里加入平台侧的运营信号比如歌曲是否进入官方歌单、是否在首页有推荐位、艺人在社交媒体的热度指数——这些信号通常和播放量有着强相关性。操作方法很简单把这些信号作为额外的特征列拼接到原有特征向量的尾部模型结构完全不用变。这类信号在公开数据里不一定拿得到但如果是自己做项目可以用「分享次数变化率」和「评论数新增速率」作为近似它们也能捕捉到歌即将进入上升期的早期信号。最后的建议是用第一人称的经验收个尾。我做这套系统的教训是别在模型结构上花过多时间把精力投入在标签定义和数据处理上回报率高得多。一个简洁的 LSTM 加干净的数据效果永远好过一个花哨的 Transformer 配一堆脏数据。希望帮到你。本文还有配套的精品资源点击获取