网易云音乐情感分类数据集：39.5万条三元组实战指南

简介：面向音乐情感分析的数据集，取自网易云音乐官方歌单与歌曲标注信息，累计约39.5万条情感标签记录，适合自然语言处理、推荐系统及音乐情感分析方向的研究者、数据科学初学者与竞赛选手使用。每条数据包含歌曲ID、歌单ID与情感标签三列，可支撑情感分类模型训练、词表与标签分布统计、歌单画像构建等任务，也方便进行数据清洗与特征工程。压缩包内共8个文件，主体为3个jsonl格式的训练/验证/测试集，辅以2个json格式的元数据与配置说明、1个md格式的README说明文档，整体约3.06MB，结构紧凑，便于快速预览和加载。已有479人学习下载，适合希望在轻量数据集上快速跑通文本分类基线、探究音乐与情绪关联的读者；凭借官方来源和明确的字段设计，也可直接用于教学演示或作为多模态情感分析的前期预处理数据。

1. 网易云音乐情感分类数据集：39.5 万条标签到底装了什么

网易云音乐情感分类数据集这名字直白，但拆开看，价值比第一印象大不少。压缩包里不是歌词库，也不是爬虫脚本，而是一份约 39.5 万条规模的歌曲-歌单-情感标签三元组：歌曲 ID 指到具体一首歌，歌单 ID 表示它出现在哪个歌单，情感标签告诉你这首歌在这个场景下被用户归到哪类情绪。数据采集自网易云音乐官方网站，每条样本由歌曲 ID、歌单 ID、情感标签三个字段组成，训练、验证、测试三份 jsonl 文件已经按行切好。对做情感分析模型、文本分类或音乐推荐的人来说，它解决的是“有数据可练、有标签可学”的问题，不需要自己爬歌单、标标签，解压即用。适合想快速验证情感分类思路的研究者，也适合拿现成数据练手的数据科学初学者。唯一要提前说清楚的是，这份数据给的是 ID 和标签，不是歌词正文，怎么把文本特征补上，第 3 章会专门展开。

2. 拆包与字段解构：把 rar 里的三元组变成干净的 DataFrame

用解压工具打开网易云音乐情感分类数据集.rar，里面不是一个大文件，而是 8 个文件组成的标准工程结构。我第一次看到这堆文件时，差点把 .gitignore 和 .gitattributes 当垃圾删掉，后来才反应过来，这是按 HuggingFace 数据集仓库规范打出来的包，这两个文件是给 Git 和 Git LFS 用的，删掉不影响读数据，但保留能让你以后直接用 datasets 库重新加载。

2.1 文件清单与各文件用途

先把包里每个文件的作用理清楚，避免拿到手对着文件名猜。

jsonl 和 json 的区别值得多说一句。jsonl 是每行一个独立 JSON 对象，不是一个大数组包着所有数据，这种格式的好处是可以用流式方式逐行读取，不用把 39 万条一次性塞进内存，训练脚本里常见做法就是for line in f: json.loads(line)。emo163.json 是标签清单，我后面清洗标签时会拿它做白名单。

2.2 核心字段语义：song_id、playlist_id、tag

先看一行长什么样，我习惯拿到新数据第一件事就是打印前三条原始记录。

head -n 3 songs-train.jsonl

输出大致是这样（字段名以实际解压结果为准，不同打包版本可能略有差异）：

{"song_id": "29837291", "playlist_id": "73456213", "tag": "伤感"} {"song_id": "29837291", "playlist_id": "22147890", "tag": "治愈"} {"song_id": "45283901", "playlist_id": "55432178", "tag": "安静"}

这里有一个容易误读的点：摘要里说“歌曲 ID 唯一标识每首歌曲”，指的是 song_id 这个字段本身指向唯一一首歌，而不是说数据里每首歌只出现一次。仔细看上面前两行，同一首歌出现在两个不同歌单，分别被标成“伤感”和“治愈”，这恰恰是音乐情感数据的常态——人对同一首歌的情绪判断本来就有场景差异。所以这份数据集本质上是“歌曲-歌单-标签”三元组，而不是“歌曲-唯一标签”的映射表，后续做单标签分类还是多标签分类，取决于你怎么聚合，这个第 5 章会详细讲。

playlist_id 表示歌曲所属歌单，它本身也是一个有信息量的字段。歌单是用户主动创建的，歌单标题和收录歌曲往往反映了某种情绪主题，比如“深夜emo歌单”里大概率是伤感曲目。这意味着 playlist_id 可以作为弱监督特征来用，即使没有歌词文本，光靠歌单 ID 也能学到一部分情感信号。

2.3 数据规模统计：行数、歌曲数、标签分布

不要凭感觉，直接写一段统计脚本，把规模、唯一值、分布都跑出来。这段代码在拿到任何 jsonl 数据集时都能复用。

import json from collections import Counter path = "songs-train.jsonl" total = 0 song_ids = set() playlist_ids = set() tags = Counter() with open(path, "r", encoding="utf-8") as f: for line in f: line = line.strip() if not line: continue obj = json.loads(line) total += 1 song_ids.add(obj["song_id"]) playlist_ids.add(obj["playlist_id"]) tags[obj["tag"]] += 1 print("总行数:", total) print("唯一歌曲数:", len(song_ids)) print("唯一歌单数:", len(playlist_ids)) print("标签种类数:", len(tags)) print("Top 10 标签:", tags.most_common(10))

逻辑说明：total 统计的是 jsonl 文件里的总行数，也就是三元组数量；song_ids 用 set 去重后得到唯一歌曲数，如果这个数明显小于 total，就说明同一首歌被多个歌单收录；tags 用 Counter 统计每个情感标签的出现频次，能直接看出标签分布是不是长尾。参数上需要注意，读取时强制指定encoding="utf-8"，Windows 下默认编码可能不是 UTF-8，不指定容易在解码阶段翻车。

从规模看，训练集是主体，验证集和测试集是留出集。三份数据合计约 39.5 万条，这个体量跑传统机器学习模型完全够用，跑深度学习也勉强能撑住。标签种类以 emo163.json 为准是 163 类，但实际 jsonl 里的标签取值可能比 163 更多，因为原始页面存在未归一化的写法，具体怎么处理看第 5 章第一条坑。

3. 清洗与切分：从原始 jsonl 到可训练样本的三个关键步骤

原始 jsonl 不能直接喂给模型，至少要做三件事：正确解压并处理编码问题、把标签归一化成规范集合、构造真正能用于训练的文本特征。这一步做不好，后面模型训练的所有结论都不可信。

3.1 解压与读入：注意中文文件名编码

rar 压缩包解压本身不复杂，但有几个隐藏坑。Windows 下用 WinRAR 或 7-Zip 解压时，如果目录或文件名带中文，偶尔会出现文件名乱码；macOS 和 Linux 下推荐用 unar，它对中文文件和特殊字符的处理比系统自带工具稳定。

# macOS / Linux 推荐 unar unar 网易云音乐情感分类数据集.rar # 如果 Linux 还没装 sudo apt install unar unar 网易云音乐情感分类数据集.rar

参数说明：unar 默认会自动处理编码，解压完检查文件名是否正常；如果系统自带 unzip 解压 rar 会直接报错，rar 格式必须用 unar、7-Zip 或 WinRAR 这类专用工具。解压后建议直接运行head -n 1 songs-train.jsonl确认文件能正常打开，这一步能提前暴露编码问题。

3.2 标签归一化：以 emo163.json 为白名单

原始标签里有三类脏数据：带空格，比如“伤感 ”；大小写不一致；组合标签，比如“伤感/安静”。这些不归一化，模型的类别数会虚高，而且同一个语义被拆成多个类别会直接拉低指标。常见的做法是加载 emo163.json 作为白名单，把所有标签统一成小写去空格，再按需求处理组合标签。

import json # 加载标签清单，兼容两种常见结构 with open("emo163.json", "r", encoding="utf-8") as f: raw = json.load(f) if isinstance(raw, list): valid_tags = {str(t).strip().lower() for t in raw} elif isinstance(raw, dict): valid_tags = set() for v in raw.values(): if isinstance(v, list): valid_tags.update(str(t).strip().lower() for t in v) else: valid_tags.add(str(v).strip().lower()) else: valid_tags = set() def normalize_tag(tag: str): tag = str(tag).strip().lower() if "/" in tag: parts = [t.strip() for t in tag.split("/")] else: parts = [tag] cleaned = [t for t in parts if t in valid_tags] return cleaned if cleaned else ["other"] print(normalize_tag("伤感 ")) print(normalize_tag(" 治愈 / 温暖"))

逻辑说明：emo163.json 可能是 list 也可能是嵌套 dict，代码里做了兼容处理，取 values 时如果嵌套了 list 就展开，最后统一成小写字符串集合。normalize_tag 处理组合标签时按/分割，保留命中白名单的部分；如果所有部分都不在白名单里，就归入other，这样类别数从 163 变成 164，不会被未知脏标签撑爆。

参数上有一点要想清楚：other不是情感标签，而是脏数据的收容所。如果other占比超过 1%，说明原始数据质量有问题，应该回头检查是不是白名单加载错了，而不是继续往下训练。

3.3 构造文本特征：没有歌词时用什么做输入

这是这份数据集最关键的边界：三元组里只有 ID 和标签，没有歌曲名、歌手名、歌词。想做文本分类，必须先解决“文本从哪来”的问题。常见做法有三个，按成本从低到高排列。

做法一是用 playlist_id 做特征。歌单本身就是一种弱监督信号，把 playlist_id 做 target encoding 或直接 one-hot，喂给模型预测歌曲所在歌单最常见的情绪。这个基线不需要任何外部数据，能验证三元组内部的关系是否一致。

做法二是用歌曲 ID 去关联外部歌词语料。如果你手里有歌词库，用 song_id 做键把歌词文本拼进来，再走 TF-IDF 向量化，这是最标准的文本分类流程。代码上就是建一个lyric_map = {song_id: text}字典。

做法三是把数据聚合成歌曲级样本，先看歌曲的情感标签分布。

import json from collections import Counter, defaultdict song_tag_counter = defaultdict(Counter) with open("songs-train.jsonl", encoding="utf-8") as f: for line in f: obj = json.loads(line) song_tag_counter[obj["song_id"]][obj["tag"]] += 1 # 每首歌取最高频标签，作为单标签样本 single_label = { song_id: counter.most_common(1)[0][0] for song_id, counter in song_tag_counter.items() } print("歌曲数:", len(single_label)) print("标签分布示例:", list(single_label.items())[:5])

逻辑说明：把同一首歌的所有标签聚合成一个 Counter，然后取最高频标签作为该歌曲的单标签。这样处理后，一份 39.5 万行的三元组会被压缩成几万个歌曲级样本，训练和评估的粒度都变成“歌”，更接近真实业务里按歌曲判情感的场景。如果做多标签任务，不要把 Counter 丢弃，保留完整分布，后续训练时把标签列表或者多热编码作为目标。

参数上，取most_common(1)是最简单的投票策略，但如果最高频标签只比第二名多几次，投票结果其实很不稳定。进阶一点的做法是设置阈值，最高频占比低于 60% 的歌曲直接剔除或标记为“混合情感”，避免把噪声当标签硬学。

4. 训练情感分类基线：TF-IDF 与逻辑回归的完整落地

数据准备完，进入模型环节。我的建议是不要一上来就上 BERT 这类预训练模型，39.5 万条三元组听着大，但歌手级样本只有几万，预训练模型在这个规模上优势不明显，还容易过拟合。先跑通一个 TF-IDF 加逻辑回归的基线，确认标签本身可学，再决定要不要升级模型。

4.1 模型选型：为什么是 TF-IDF 加线性模型

选择逻辑回归不是因为它最先进，而是因为它在“文本稀疏特征 + 多分类 + 样本量中等”的场景下有四个明确优点：训练速度快，几万样本几十秒内收敛；对稀疏输入友好，TF-IDF 输出的稀疏矩阵直接喂进去，内存压力小；参数少，需要调的只有正则强度 C 和迭代次数；结果可解释，coef 权重能直接看出哪些词在驱动“伤感”和“治愈”的判定。相比之下，深度学习模型在特征维度上收益有限，还要额外处理 GPU、显存、训练时间这些工程问题。

4.2 训练脚本与参数详解

假设你已经按第 3 章准备好了一个lyric_map字典，键是 song_id，值是歌词文本。下面是完整可跑的脚本。

import json from collections import Counter, defaultdict from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.metrics import accuracy_score, f1_score def build_dataset(path, lyric_map): song_tags = defaultdict(Counter) with open(path, encoding="utf-8") as f: for line in f: obj = json.loads(line) song_tags[obj["song_id"]][obj["tag"]] += 1 X, y = [], [] for song_id, counter in song_tags.items(): text = lyric_map.get(song_id, "") if not text: continue X.append(text) y.append(counter.most_common(1)[0][0]) return X, y lyric_map = {} X_train, y_train = build_dataset("songs-train.jsonl", lyric_map) X_test, y_test = build_dataset("songs-test.jsonl", lyric_map) tfidf = TfidfVectorizer( max_features=20000, ngram_range=(1, 2), sublinear_tf=True ) X_train_vec = tfidf.fit_transform(X_train) X_test_vec = tfidf.transform(X_test) clf = LogisticRegression( C=1.0, solver="liblinear", max_iter=1000 ) clf.fit(X_train_vec, y_train) y_pred = clf.predict(X_test_vec) print("accuracy:", accuracy_score(y_test, y_pred)) print("macro f1:", f1_score(y_test, y_pred, average="macro"))

逻辑说明：build_dataset 按歌曲聚合标签并取最高频，和 3.3 节的做法一致，train 和 test 必须走同一套聚合逻辑，否则数据集分布不一致。然后 TfidfVectorizer 在训练集上 fit，在测试集上只做 transform，这里不能对测试集重新 fit，否则会造成特征空间不一致。

参数说明：max_features=20000 限制特征数量，歌词文本的词汇量很大，但高频有效词其实集中在前一两万，限制特征能显著降低训练时间；ngram_range=(1, 2) 同时使用词和相邻两个词组成的短语，能捕捉“好难过”“不想睡”这类组合表达；sublinear_tf=True 对词频取对数平滑，弱化高频词的绝对数量优势。LogisticRegression 的 C=1.0 是默认正则强度，C 越小正则越强，文本分类场景下 1.0 附近通常不需要大改；solver="liblinear" 适合中小规模稀疏矩阵，如果换用 saga 或 lbfgs，收敛行为和训练速度都会变，没必要在基线上折腾；max_iter=1000 防止在特征维度高时默认的 100 次迭代不收敛，liblinear 下这个值一般不会成为瓶颈。

如果暂时没有 lyric_map，也可以先跑一个只用 playlist_id 做特征的版本，把 build_dataset 里的 text 换成 playlist_id 字符串，看看能不能学到东西。这个弱基线的作用不是作为最终模型，而是确认歌单和情感标签之间存在相关性。

4.3 评估指标怎么读：多分类长尾下的正确姿势

163 个类别，直接用 accuracy 会被头部类别带偏。假设“伤感”“安静”两个头部标签占了 40% 的样本，你只需要全猜这两个类别就能拿 40% 准确率，这没有任何业务价值。所以评估必须同时看 macro F1，它对每个类别一视同仁，尾部类别表现差会直接拉低 macro F1。

注意 classification_report 在这种类别数下会输出一百多行，实战里只看最后两行就够了。我习惯把报告截断，或者只提取 macro avg 和 weighted avg 两行。macro F1 能跑到 0.5 以上，说明标签规则是可学的；如果只有 0.2 左右，先回去检查标签归一化和样本聚合是否合理，再考虑是不是文本特征和标签的关联本身就很弱。这一步验证做完，再谈换模型才有意义。

5. 避坑与排查：40 万条数据里的五个暗坑

这份数据集的体量不算小，但在实际使用中，我前后踩了五个坑，每一个都花了不少时间排查。这里按“现象 → 原因 → 解决”写清楚，你拿到手可以直接绕开。

5.1 坑一：标签种类数比 163 多

现象：统计训练集里 unique 标签，发现不止 163 个，多出来的标签语义还很混乱，比如 “伤感 ” 带末尾空格，“治愈系” 和 “治愈” 并存，甚至出现 “孤独/安静” 这种组合写法。

原因：emo163.json 是标准标签清单，但 jsonl 里的 tag 直接来自网易云页面原始爬取结果，没有做清洗。用户在创建歌单时填写的情感标签本来就是自由文本，只有部分命中了规范标签。

解决：以 emo163.json 为白名单做归一化，按第 3.2 节的 normalize_tag 处理。先 strip，再统一小写，遇到组合标签按/拆分，只保留命中白名单的部分，全部不命中就归入 other。我踩坑时没有做白名单校验，直接拿原始标签训练，类别数从 163 膨胀到 200 多，macro F1 掉了快 0.1，教训很直接。

5.2 坑二：song_id 和 playlist_id 是字符串不是整数

现象：用 pandas 读入后，发现 song_id 变成了浮点数，后面和外部数据做 join 时匹配不上，或者直接int(obj["song_id"])报 ValueError。

原因：song_id 在 jsonl 里是纯数字字符串，但位数可能超过 int64 的安全范围，或者带前导零。pandas 在自动类型推断时会尝试转成 int64，一旦溢出就直接变 float64，精度就丢了。

解决：全程用字符串类型，读取后显式转换。

song_id = str(obj["song_id"]) # 正确，保留原始精度 playlist_id = str(obj["playlist_id"]) # 同理

逻辑说明：字符串连接和 join 时两边都用 str，避免出现一边是 int、一边是 str 导致匹配失败的尴尬。我现在的习惯是读入后统一.astype(str)，这个习惯救了我很多次。

5.3 坑三：同一首歌带多个标签，直接去重会把数据洗坏

现象：做单标签分类时，用groupby(song_id).first()取标签，结果训练集和验证集的标签分布差得离谱，模型训练时 loss 震荡严重。

原因：同一首歌在不同歌单里被不同用户标记成不同情感，直接取第一条等于随机抽签，把本该是“情感倾向分布”的信息压缩成了一个随机标签，噪声占比极高。

解决：单标签任务用第 3.3 节的 Counter 投票策略，取最高频标签，同时可以设置最低占比阈值过滤混合情感样本；多标签任务保留完整标签集合，把目标从单分类改成多标签分类。从此以后我再也不敢用first()了。

5.4 坑四：jsonl 解码报错，定位不到脏行

现象：直接open("songs-train.jsonl")读文件报 UnicodeDecodeError，错误信息指向某一行，但用文本编辑器打开又看不到明显异常。

原因：文件本身是 UTF-8 编码，但某行内容里存在非法转义字符或不可见控制字符，这类字符在编辑器里被隐藏了，Python 的默认解码严格模式直接抛异常。

解决：读文件时显式指定编码，并对每行做 JSON 解码的异常捕获。

with open("songs-train.jsonl", "r", encoding="utf-8") as f: for idx, line in enumerate(f): line = line.strip() if not line: continue try: obj = json.loads(line) except json.JSONDecodeError: print(f"bad line {idx}: {line[:80]}") continue

逻辑说明：捕获异常后打印行号和前 80 个字符，先定位脏行长什么样，再决定是修复还是丢弃。不要一开始就errors="ignore"把问题藏起来，这会让后续训练在不知不觉中吃进脏数据。

5.5 坑五：官方划分里同一首歌横跨 train 和 valid

现象：直接用官方给的 songs-train.jsonl 和 songs-valid.jsonl 训练，验证集指标比预期低很多，细查发现同一首歌在两个集合里都出现。

原因：jsonl 是按行划分的，不是按歌曲划分的。同一首歌出现在多个歌单，歌单 A 进了训练集，歌单 B 进了验证集，这首歌的信息就被泄漏到了验证集。这种泄漏让验证集指标虚高，但模型真正面对一首没见过的歌时表现反而更差。

解决：做泛化评估时按歌曲 ID 重新划分。

from sklearn.model_selection import StratifiedShuffleSplit song_ids = list(single_label.keys()) labels = [single_label[sid] for sid in song_ids] sss = StratifiedShuffleSplit(n_splits=1, test_size=0.2, random_state=42) train_idx, test_idx = next(sss.split(song_ids, labels)) train_songs = [song_ids[i] for i in train_idx] test_songs = [song_ids[i] for i in test_idx]

逻辑说明：在歌曲级做分层抽样，保证一首歌要么在训练集要么在测试集，不会跨界。random_state 固定保证结果可复现。如果你要复现官方报告里的指标，那用官方划分没毛病，但如果你要评估模型对新歌的泛化能力，请务必用歌曲级切分。

6. 把模型做成流水线：批量预测与 Top-K 多标签输出

训练完只是第一步，模型要能用起来，得封装成一个可复用的预测接口。这里分享一个我常用的做法：不直接输出单一情感标签，而是输出 Top-K，因为歌曲情感本身是模糊的，给用户展示“伤感 / 治愈 / 安静”三个候选，比硬塞一个标签更符合真实业务。

import joblib import numpy as np class EmotionClassifier: def __init__(self, model_path, tfidf_path): self.clf = joblib.load(model_path) self.tfidf = joblib.load(tfidf_path) def predict_topk(self, texts, k=3): vec = self.tfidf.transform(texts) proba = self.clf.predict_proba(vec) top_k_idx = np.argsort(-proba, axis=1)[:, :k] labels = self.clf.classes_ return [[labels[i] for i in row] for row in top_k_idx] # 使用 clf = EmotionClassifier("model.joblib", "tfidf.joblib") texts = ["那些年错过的大雨，那些年错过的爱情"] print(clf.predict_topk(texts, k=3))

逻辑说明：predict_topk 对输入的文本列表做向量化，predict_proba 得到每个类别的概率矩阵，np.argsort(-proba)按概率从高到低取前 k 个下标，再映射回标签名。返回的是列表套列表，每首歌一行，对应 Top-K 情感标签。注意模型和 TF-IDF 向量化器必须一起保存，推荐用 joblib.dump 同时存两份，否则单存模型在预测阶段会直接报特征维度不匹配。

保存时习惯上把两个对象打包成一个 dict：

joblib.dump({"clf": clf, "tfidf": tfidf}, "emotion_model.joblib")

加载时再分开取。这个封装的好处是批量预测只需传一个字符串列表，无论是给歌单批量打标，还是对单曲推荐情感候选，都不用重写逻辑。

以前我拿到这类数据集第一件事就是冲进模型训练，结果被标签噪声、ID 类型、歌曲泄漏这些问题反复折腾。现在我的习惯是严格按顺序走：先解压统计，再归一化标签，然后歌曲级聚合，最后才进模型。三步走完，后面的训练和评估基本不再翻车。希望这篇能帮你在 39.5 万条数据上少走弯路，跑得顺手。

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