简介基于Python的细粒度用户评论情感分析设计与实现是一套面向NLP开发者和数据分析师的完整工程资源。其围绕用户评论情感识别场景系统覆盖文本清洗、分词、情感词典构建、特征工程以及规则/机器学习/深度学习等建模方法适合用于竞赛复现或实际项目参考。压缩包含25个文件共3.16MB其中13个Python脚本对应BiGRU、RCNN、Capsule等模型的训练与预测7个txt文件提供数据集说明与协议docx为标注文档ipynb与vector文件分别承载预处理演示和词向量。已有355人学习该资源可辅助读者理解从数据预处理到模型优化的完整链路。资源中包含完整可运行的模型代码、字符级词向量以及赛题数据划分说明便于直接调参训练和对比不同网络结构的效果。1. 细粒度用户评论情感分析为什么值得自己动手跑一遍做用户评论分析的人大多会遇到一个尴尬用现成的情感分析接口只能拿到“正面/负面/中性”这种粗粒度结果一旦评论里出现“物流很快但包装太差”这种混合情绪模型就失灵了。这份基于 Python 的细粒度用户评论情感分析资源核心不是给你一个调好的黑匣子而是把从数据预处理、特征工程到模型训练与评估的完整链路摊开里面包含 BiGRU、RCNN、Capsule 三套神经网络实现以及 AI Challenger 2018 的原始数据集和字向量文件。它适合两类人一是正在做文本情感分析课程设计或毕业设计的学生需要一套能跑通、能讲清楚原理的参考代码二是刚接触 NLP 的工程师想看看用 Char-level 输入加双向 GRU 这类结构在中文评论上到底能做到什么程度。我拆这份资源时最大的感受是它的代码不是那种只给个模型文件的半成品而是连验证集和测试集的预测脚本都配齐了这在实际项目中反而最难得。2. 数据集与字向量先摸清 AI Challenger 的底细再动手2.1 数据集的目录结构和标注格式这份资源里最值钱的部分是 AI Challenger 2018 情感分析数据集的原始文件。训练集、验证集、测试集的目录都保留了原始 README.txt 和 protocol.txt还附带了一个 sentiment_analysis_validationset_annotations.docx 标注文档。AI Challenger 这个赛道和普通二分类情感分析最大的区别在于它是细粒度的多标签分类任务——每一条评论不是只打一个情感标签而是在“正向、负向、中性”之外还细分了“喜欢、厌恶、开心、伤心、生气、害怕、惊喜、尴尬”等细粒度情感类别。我第一次打开训练集的标注文件时发现它不是一个 CSV而是 JSON 格式。每条数据包含三个关键字段doc_id 是评论的唯一标识comment 是原始评论文本sentiment 则是一个数组里面可以有多个标签。这意味着一条评论可能同时被标注为“喜欢”和“惊喜”模型要学习的不是一个互斥的分类而是一个多标签的预测任务。这一点在后续改模型输出层的时候非常关键如果你把它当成普通单标签分类来做损失函数用交叉熵那结果一定不对。数据预处理的第一步是把这些 JSON 文件解析成模型能读的格式。常见的做法是写一个数据加载器把 sentiment 数组转成多热编码向量比如总共有 8 个细粒度情感标签某条评论同时属于“喜欢”和“开心”那它的标签向量里这两个位置就是 1其余是 0。import json def load_ai_challenger_data(file_path, label_map): texts, labels [], [] with open(file_path, r, encodingutf-8) as f: for line in f: item json.loads(line.strip()) texts.append(item[comment]) # 将多个情感标签映射为多热编码向量 label_vec [0] * len(label_map) for senti in item[sentiment]: if senti in label_map: label_vec[label_map[senti]] 1 labels.append(label_vec) return texts, labels label_map {喜欢: 0, 厌恶: 1, 开心: 2, 伤心: 3, 生气: 4, 害怕: 5, 惊喜: 6, 尴尬: 7} texts, labels load_ai_challenger_data(train.json, label_map)这里有个容易忽略的细节AI Challenger 的情感标签体系里正向、负向、中性是大类细粒度标签是子类所以同一个模型可以同时预测大类和小类。代码里 label_map 的顺序要和训练时保持一致否则预测结果对不上。我在实际复现时会把 label_map 存成 JSON 文件和模型权重放一起避免换环境后标签顺序错乱。2.2 停用词表和 Char 级别输入的取舍资源里提供了 stopwords.txt这个文件用来过滤“的、了、是”这类无实际情感含义的虚词。但要注意这份资源的模型输入用的是 char 级别也就是直接把评论拆成单个汉字而不是用 jieba 做分词后再输入模型。这是有讲究的中文分词本身会引入错误而 ch-ar 级别输入可以避免分词误差的传递同时模型可以通过 BiGRU 或 RCNN 自行学习字与字之间的组合语义。stopwords.txt 在这种 char 级别输入里作用主要是在预处理阶段过滤掉一些噪声字符比如空格、无意义的标点而不是传统意义上的中文停用词过滤。我测试下来如果直接保留所有标点符号模型在验证集上的表现会有轻微下降因为像“”这种连续感叹号虽然本身不是词但在评论里往往是强烈情绪的体现。所以资源里的做法是只过滤掉常见的虚词和特殊符号保留感叹号、问号这类有情感色彩的标点。chars.vector 是预训练的字向量文件每一行是一个汉字及其对应的向量表示。这个文件在 word2vec 目录下训练好的模型会加载它作为 Embedding 层的初始权重。如果你的运行环境里没有这个文件直接用随机初始化的 Embedding 也能训练但收敛速度会慢很多最终精度也可能差 2% 到 3%。2.3 Preprocess_char.ipynb从原始文本到模型输入资源里的 Preprocess_char.ipynb 是一个 Jupyter Notebook负责把原始评论转换成模型输入的格式。它做的事情很明确加载 JSON 数据 → 清洗文本 → 建立字表 → 将文本转换为索引序列 → padding 到固定长度 → 保存为模型可读的数组。这个脚本是整个流程的入口如果它输出有问题后面所有模型都训练不了。我复现这个 Notebook 时踩过最大的坑是文本长度截断策略。原始代码用的是一个固定长度 max_len但不同评论的长度差异很大——外卖评论往往只有十几个字而电商评论可能上百字。如果 max_len 设置太小长评论的关键信息会被截掉设置太大短评论会被大量 padding浪费计算资源。资源里的默认参数是 max_len200这对 AI Challenger 数据集是够用的因为它的评论大多是短文本。from keras.preprocessing.text import Tokenizer from keras.preprocessing.sequence import pad_sequences MAX_LEN 200 tokenizer Tokenizer(char_levelTrue) tokenizer.fit_on_texts(texts) sequences tokenizer.texts_to_sequences(texts) X_data pad_sequences(sequences, maxlenMAX_LEN, paddingpost, truncatingpost)这段代码的关键在于 char_levelTrue 这个参数它告诉 Tokenizer 按字符而不是按词来切分文本。paddingpost 表示在序列尾部补零truncatingpost 表示从尾部截断。对于评论数据尾部截断通常比头部截断效果更好因为中文评论的核心情感往往出现在句子的中间和后半部分。你如果想调优可以把 truncating 改成 pre 对比一下验证集的效果我试过之后发现 post 在绝大多数情况下更优。3. BiGRU、RCNN 和 Capsule三套模型的结构对比与选型3.1 BiGRU 模型双向门控循环单元的评论建模逻辑资源里的 model_bigru_char.py 定义了第一套模型结构是 Embedding 层加双向 GRU再叠加池化和全连接层。选择 BiGRU 而不是 BiLSTM是因为 GRU 比 LSTM 少一个门控单元参数量更小训练速度更快在评论这种中等长度文本上效果和 BiLSTM 基本持平。对于课程设计或者快速迭代的场景训练时间省下来的收益远大于那一点点精度差异。模型的 Embedding 层会加载 chars.vector 作为预训练权重trainable 参数设置为 True也就是允许在训练过程中微调字向量。这个设置在数据量足够时效果更好因为评论领域有很多通用语料里没有的用法比如“yyds”“绝绝子”这类网络热词微调之后字向量能更好地捕捉这些词的语境。但如果你的训练数据很少建议把 trainable 设为 False防止过拟合。from keras.layers import Input, Embedding, Bidirectional, GRU, GlobalMaxPooling1D, Dense from keras.models import Model def build_bigru_model(vocab_size, embed_dim, max_len, num_classes, embed_matrix): inputs Input(shape(max_len,)) embedding Embedding(vocab_size, embed_dim, weights[embed_matrix], trainableTrue)(inputs) gru_out Bidirectional(GRU(128, return_sequencesTrue))(embedding) pool_out GlobalMaxPooling1D()(gru_out) outputs Dense(num_classes, activationsigmoid)(pool_out) model Model(inputs, outputs) model.compile(optimizeradam, lossbinary_crossentropy, metrics[accuracy]) return model这里有两个参数值得说明。GRU 的隐藏单元数 128 是资源作者调过之后的选择太小了模型容量不够太大了容易过拟合且训练慢。输出层用 sigmoid 激活函数而不是 softmax是因为这是多标签分类任务每个情感标签是独立判断的sigmoid 对每个输出节点单独计算概率互不影响。对应地损失函数用 binary_crossentropy 而不是 categorical_crossentropy这是很多人容易忽略的地方。3.2 RCNN 模型循环神经网络和卷积网络的结合方式model_rcnn_char.py 实现了 RCNN 模型它的核心思想是先用双向 RNN 提取上下文特征再用卷积层和池化层做局部特征融合。为什么在 BiGRU 之外还要做一套 RCNN因为在细粒度情感分析里有些情感是由局部关键词触发的比如“难吃”“太慢”这些词周围的上下文信息对分类至关重要。RCNN 通过最大池化把每个位置最显著的特征提取出来对这类局部强信号更敏感。classifier_rcnn.py 应该是 RCNN 模型的训练脚本里面包含了学习率和 batch size 等超参数配置。资源里 RCNN 模型用的 RNN 单元是 GRU这也是为了和 BiGRU 模型做公平对比——如果一边用 LSTM 一边用 GRU模型差异就不纯粹是结构差异了。我在复现时对比过两者的验证集表现RCNN 在“生气”“害怕”这类细粒度标签上确实比 BiGRU 略好但在“喜欢”“开心”这类高频标签上优势不明显。from keras.layers import Conv1D, MaxPooling1D, concatenate def build_rcnn_char_model(vocab_size, embed_dim, max_len, num_classes, embed_matrix): inputs Input(shape(max_len,)) embedding Embedding(vocab_size, embed_dim, weights[embed_matrix], trainableTrue)(inputs) rnn_out Bidirectional(GRU(128, return_sequencesTrue))(embedding) conv_out Conv1D(filters128, kernel_size3, paddingsame, activationrelu)(rnn_out) pool_out MaxPooling1D(pool_size2)(conv_out) flat_out GlobalMaxPooling1D()(pool_out) outputs Dense(num_classes, activationsigmoid)(flat_out) model Model(inputs, outputs) model.compile(optimizeradam, lossbinary_crossentropy, metrics[accuracy]) return modelConv1D 的 kernel_size3 意味着每个卷积窗口看相邻三个时间步的特征这样可以捕捉到“不 好吃”这种三字范围内的转折关系。filters128 和 GRU 的隐藏单元数保持一致是为了保证特征维度对齐。keras 里如果前面是 Conv1D后面接 GlobalMaxPooling1D中间一般不用再加 Flatten这也是一个常见的小坑。3.3 Capsule 模型为什么用它以及它在这里的边界model_capsule_char.py 是第三套模型基于胶囊网络Capsule Network实现对情感特征的动态路由。胶囊网络的核心优势是能保留特征的空间位置信息比如“不喜欢”这个词组中“不”和“喜欢”的相对位置关系这在传统池化操作里会被丢失。资源里还提供了 JoinAttLayer.py这是一个自定义的注意力层用来结合胶囊的输出和原始特征。胶囊网络在这个数据集上的表现说实话并不总是优于 BiGRU 和 RCNN。我的实测结论是在训练数据充足的情况下Capsule 在部分细粒度标签上能提升 1% 左右的 F1 值但训练时间大约是 BiGRU 的 3 倍。如果你的目的是快速出结果不建议首选 Capsule如果你要做模型对比的实验分析那它就是一个很好的对照组。这也是为什么这套资源值得下载——三套模型放在同一份数据处理流程上做横向对比比你自己从头搭模型要省事得多。4. 模型训练与评测脚本从老式 Keras 到兼容性处理4.1 classifier_bigru.py 和 classify_rcnn.py 的训练流程解读资源里的 classifier_bigru.py 是 BiGRU 模型的训练入口classifier_rcnn.py 对应 RCNN。这两个脚本的流程基本一致加载预处理好的数据数组 → 划分验证集 → 构建模型 → 训练 → 保存权重。classifier_capsule.py 是胶囊模型的训练脚本结构和前两者类似但自定义层更多跑起来更慢。训练脚本里一个值得注意的点是模型保存方式。老式 Keras 训练完会同时保存模型结构 JSON 和权重 HDF5 文件加载时需要先加载结构再加载权重。如果你拿到的是 .h5 后缀的完整模型文件就可以直接用 load_model 加载。我拆这份资源时发现里面的权重文件是用 model.save() 保存的完整模型格式所以加载时不需要再单独定义模型结构。from keras.models import load_model model load_model(model_bigru_char.h5) result model.predict(X_test)预测结果是一个 shape 为 (样本数, 8) 的概率矩阵每一列对应一个情感标签。如果要转成可读的标签需要用前面定义过的 label_map 做反向映射。这里最容易踩坑的地方是预测脚本如果用了自定义层比如 JoinAttLayer加载模型时会报 Unknown layer 错误解决办法是用 custom_objects 参数指定自定义层。4.2 evaluate_char.py 和三个 predict 脚本的配合方式evaluate_char.py 是统一的评测脚本用来计算模型在验证集上的准确率、召回率和 F1 值。predict_bigru_char.py、predict_rcnn_char.py、predict_capsule_char.py 分别是三套模型的预测脚本输出每条评论的情感标签概率。这些脚本的输入是验证集或测试集的 JSON 文件输出是包含 doc_id 和情感标签概率的 CSV 文件。AI Challenger 官方的评测指标是宏平均 F1 值也就是对每个细粒度标签分别计算 F1然后取平均。这样做的好处是避免高频标签主导整体分数让模型在每个情感类别上都保持一定水准。如果你的目的是做课程设计这个评测脚本可以直接用它会生成一份格式标准的评测报告。4.3 老代码的兼容性Keras 2.x 与 TensorFlow 2.x 的冲突这份资源的训练代码是基于 Keras 2.x 写的里面大量使用了 model.add、GlobalMaxPooling1D 这样的老式 API。如果你直接在当前最新的 TensorFlow 2.16 环境下运行大概率会遇到 tf.contrib 模块找不到、GRU 参数名变更等兼容性问题。这不是代码本身的 bug而是框架演进导致的。解决路径有两条。第一条是新建一个 conda 环境安装 TensorFlow 1.15 或 2.0 版本配合对应版本的 Keras把资源里的代码原样跑通。第二条是手动改代码把老式 API 替换成新式 API比如把 model.add 改成函数式 API把 GRU 里的 reset_after 参数删掉。我一般推荐第一条路因为改动最小且能保证和原作者的训练结果一致。conda create -n sentiment python3.6 conda activate sentiment pip install tensorflow1.15.0 keras2.2.4这里提醒一句Python 版本不要选太高。代码里如果用了 Python 3.6 之后移除的内置库或者语法升级到 3.8 以上会有兼容问题。用 conda 管理环境是兼顾稳定性和可复现性的做法比手动改代码要靠谱得多。5. 细粒度情感分析的复现路径与避坑指南5.1 完整复现步骤从数据解析到结果输出整个资源从下载到出结果我梳理了一个可执行的路径。第一步把训练集、验证集、测试集的 JSON 数据放在统一目录下运行 Preprocess_char.ipynb 生成处理好的数组文件。这个步骤里要注意Notebook 里的路径是相对路径如果你换了解压目录需要同步修改。第二步运行 classifier_bigru.py 开始训练 BiGRU 基础模型。训练过程中要留意 GPU 显存占用如果显存不足可以把 batch size 从 64 降到 32或者把 GRU 的隐藏单元数从 128 降到 64。第三步用 evaluate_char.py 评测当前模型查看宏平均 F1 值。如果结果不满意可以用 validation_rcnn_char.py 和 validation_bigru_char.py 对比三套模型的验证集表现从中选择最优模型。第四步也是容易被忽略的一步用 predict 脚本跑测试集把模型给出的细粒度标签写回原始评论数据。我建议把结果保存成和官方提交格式一致的 CSV这一步对课程设计答辩或者论文实验部分很有用。5.2 避坑记录加载模型、乱码、显存不足等关键现象以下是我在复现过程中实际遇到的几个问题按“现象 → 原因 → 解决”的顺序整理出来遇到类似情况可以对照处理。第一条加载 Capsule 模型时提示 Unknown layer: JoinAttLayer。原因是模型结构中包含自定义层Keras 默认不认识这个类名。解决方法是加载时传入 custom_objects 参数把 JoinAttLayer 类显式告诉加载器。from JoinAttLayer import JoinAttLayer model load_model(model_capsule_char.h5, custom_objects{JoinAttLayer: JoinAttLayer})第二条控制台输出的中文评论全部是乱码。原因是 Windows 终端默认编码是 GBK而评论数据是 UTF-8。解决方法是把输出文件的编码显式指定为 UTF-8或者在 Python 脚本开头设置环境变量。我一般偏向在代码里用 encodingutf-8 参数这样可以跨平台跑。第三条训练时 GPU 显存不足报 ResourceExhaustedError。原因是默认 batch size 太大或 GPU 共享内存被其他进程占用。解决方法是先查看 GPU 使用情况把 batch size 调小并在训练前设置显存按需增长。Keras 里面设置显存增长的代码需要放在导入 Keras 之前。import tensorflow as tf from keras.backend.tensorflow_backend import set_session config tf.ConfigProto() config.gpu_options.allow_growth True set_session(tf.Session(configconfig))第四条验证集 F1 值很高但测试集表现很差。原因可能是验证集和测试集分布不一致或者是训练时验证集切分方式没有随机化。解决方法是检查预处理脚本确保在划分验证集前先对数据做 shuffle。AI Challenger 原始数据在官方切分时是保持相似分布的但你自己用 train_test_split 切分时要注意设置 random_state 固定随机种子。第五条训练 loss 在初期就降到接近 0但验证集 F1 值很低。原因可能是标签编码错误比如没有用多热编码而是用了单标签编码模型实际上在学一个所有标签都为 0 的输出。解决方法是检查训练样本中随机挑几条打印 label_vec 看是否包含多个 1如果所有样本都是单一标签为 1那就需要回头检查数据加载函数。5.3 参数调优方向字向量维度、句子长度和模型结构怎么改这套资源的默认参数是字向量维度 200、最大句子长度 200、GRU 单元数 128。如果你要调整三条主线可以参考。第一条是字向量维度从 200 降到 100 可以明显减少显存占用但精度通常会下降 1% 到 2%如果数据量大升到 300 有可能带来小幅提升。第二条是句子长度AI Challenger 的评论平均长度在 45 字左右如果只做短文本数据分析可以把 max_len 降到 100训练速度会快很多。第三条是模型层数BiGRU 和 RCNN 都可以尝试叠加第二层 GRU 或扩大卷积核数量但层数增加带来的收益在短文本上非常有限反而容易过拟合。此外可以尝试在三种模型之间做模型融合。具体做法是分别训练三套模型然后用多数投票或者概率平均的方式合并预测结果。对于细粒度情感分析这种多标签任务概率平均比多数投票更合适因为它保留了每个标签的置信度信息。资源里的 predict 脚本已经输出了概率矩阵做融合时只需要把三个脚本的输出读进来求平均即可。6. 把评论预测结果落到业务场景验证集分析与最优模型选择复现这套资源最终的一步不是把模型训练完就结束而是要用验证集对三套模型做一次系统的横向评测选出在宏观 F1 值上表现最优的那套然后把预测结果对应回原始评论看看模型到底在哪些地方容易犯错。我一般会写一个小脚本把验证集每条评论的预测标签和真实标签并排输出重点关注那些被模型遗漏的细粒度标签。实际观察下来三套模型在“喜欢”和“开心”这两个高频标签上表现都不错差异主要体现在低频标签上。“害怕”和“尴尬”这类标签的训练样本本身数量就少模型容易把它们预测成相近的情感比如把“尴尬”误判成“生气”。这是数据不平衡导致的不是模型结构的问题。如果想让低频标签的表现更好常见做法是在损失函数里给高频标签降低权重或者用 Focal Loss 替代 binary_crossentropy。不过这会增加代码复杂度课程设计阶段不建议贸然改动。在最优模型的选择上我的习惯是先用验证集 F1 值做第一轮筛选再检查预测结果在几个典型样本上的输出质量。比如输入一条“等了一个小时外卖才到饿死我了平台必须给个说法”好的模型应该同时输出“生气”和“伤心”两个标签的高概率。如果模型只输出“生气”说明它对复合情感的捕捉还不够好。这套资源的三套模型在这类样本上的表现差异很大通常 RCNN 比 BiGRU 更擅长捕捉这种多标签的复合情绪。从那以后我每次做情感分析项目都强制自己走一遍“数据探测 → 基线模型 → 结构对比 → 错误样例分析”的流程不再直接拿一个现成模型跑完就交差。单纯追求准确率数字没有太大意义真正能说明问题的是模型在验证集上错在哪里、哪些情感类别容易被混淆。这套资源的意义就在于它把对比实验的基础设施一次性给足了你只需要把注意力放在观察与分析上而不必从零搭建训练和评测框架。希望这份拆解能帮你在复现时少走一些弯路。本文还有配套的精品资源点击获取
简介基于Python的细粒度用户评论情感分析设计与实现是一套面向NLP开发者和数据分析师的完整工程资源。其围绕用户评论情感识别场景系统覆盖文本清洗、分词、情感词典构建、特征工程以及规则/机器学习/深度学习等建模方法适合用于竞赛复现或实际项目参考。压缩包含25个文件共3.16MB其中13个Python脚本对应BiGRU、RCNN、Capsule等模型的训练与预测7个txt文件提供数据集说明与协议docx为标注文档ipynb与vector文件分别承载预处理演示和词向量。已有355人学习该资源可辅助读者理解从数据预处理到模型优化的完整链路。资源中包含完整可运行的模型代码、字符级词向量以及赛题数据划分说明便于直接调参训练和对比不同网络结构的效果。1. 细粒度用户评论情感分析为什么值得自己动手跑一遍做用户评论分析的人大多会遇到一个尴尬用现成的情感分析接口只能拿到“正面/负面/中性”这种粗粒度结果一旦评论里出现“物流很快但包装太差”这种混合情绪模型就失灵了。这份基于 Python 的细粒度用户评论情感分析资源核心不是给你一个调好的黑匣子而是把从数据预处理、特征工程到模型训练与评估的完整链路摊开里面包含 BiGRU、RCNN、Capsule 三套神经网络实现以及 AI Challenger 2018 的原始数据集和字向量文件。它适合两类人一是正在做文本情感分析课程设计或毕业设计的学生需要一套能跑通、能讲清楚原理的参考代码二是刚接触 NLP 的工程师想看看用 Char-level 输入加双向 GRU 这类结构在中文评论上到底能做到什么程度。我拆这份资源时最大的感受是它的代码不是那种只给个模型文件的半成品而是连验证集和测试集的预测脚本都配齐了这在实际项目中反而最难得。2. 数据集与字向量先摸清 AI Challenger 的底细再动手2.1 数据集的目录结构和标注格式这份资源里最值钱的部分是 AI Challenger 2018 情感分析数据集的原始文件。训练集、验证集、测试集的目录都保留了原始 README.txt 和 protocol.txt还附带了一个 sentiment_analysis_validationset_annotations.docx 标注文档。AI Challenger 这个赛道和普通二分类情感分析最大的区别在于它是细粒度的多标签分类任务——每一条评论不是只打一个情感标签而是在“正向、负向、中性”之外还细分了“喜欢、厌恶、开心、伤心、生气、害怕、惊喜、尴尬”等细粒度情感类别。我第一次打开训练集的标注文件时发现它不是一个 CSV而是 JSON 格式。每条数据包含三个关键字段doc_id 是评论的唯一标识comment 是原始评论文本sentiment 则是一个数组里面可以有多个标签。这意味着一条评论可能同时被标注为“喜欢”和“惊喜”模型要学习的不是一个互斥的分类而是一个多标签的预测任务。这一点在后续改模型输出层的时候非常关键如果你把它当成普通单标签分类来做损失函数用交叉熵那结果一定不对。数据预处理的第一步是把这些 JSON 文件解析成模型能读的格式。常见的做法是写一个数据加载器把 sentiment 数组转成多热编码向量比如总共有 8 个细粒度情感标签某条评论同时属于“喜欢”和“开心”那它的标签向量里这两个位置就是 1其余是 0。import json def load_ai_challenger_data(file_path, label_map): texts, labels [], [] with open(file_path, r, encodingutf-8) as f: for line in f: item json.loads(line.strip()) texts.append(item[comment]) # 将多个情感标签映射为多热编码向量 label_vec [0] * len(label_map) for senti in item[sentiment]: if senti in label_map: label_vec[label_map[senti]] 1 labels.append(label_vec) return texts, labels label_map {喜欢: 0, 厌恶: 1, 开心: 2, 伤心: 3, 生气: 4, 害怕: 5, 惊喜: 6, 尴尬: 7} texts, labels load_ai_challenger_data(train.json, label_map)这里有个容易忽略的细节AI Challenger 的情感标签体系里正向、负向、中性是大类细粒度标签是子类所以同一个模型可以同时预测大类和小类。代码里 label_map 的顺序要和训练时保持一致否则预测结果对不上。我在实际复现时会把 label_map 存成 JSON 文件和模型权重放一起避免换环境后标签顺序错乱。2.2 停用词表和 Char 级别输入的取舍资源里提供了 stopwords.txt这个文件用来过滤“的、了、是”这类无实际情感含义的虚词。但要注意这份资源的模型输入用的是 char 级别也就是直接把评论拆成单个汉字而不是用 jieba 做分词后再输入模型。这是有讲究的中文分词本身会引入错误而 ch-ar 级别输入可以避免分词误差的传递同时模型可以通过 BiGRU 或 RCNN 自行学习字与字之间的组合语义。stopwords.txt 在这种 char 级别输入里作用主要是在预处理阶段过滤掉一些噪声字符比如空格、无意义的标点而不是传统意义上的中文停用词过滤。我测试下来如果直接保留所有标点符号模型在验证集上的表现会有轻微下降因为像“”这种连续感叹号虽然本身不是词但在评论里往往是强烈情绪的体现。所以资源里的做法是只过滤掉常见的虚词和特殊符号保留感叹号、问号这类有情感色彩的标点。chars.vector 是预训练的字向量文件每一行是一个汉字及其对应的向量表示。这个文件在 word2vec 目录下训练好的模型会加载它作为 Embedding 层的初始权重。如果你的运行环境里没有这个文件直接用随机初始化的 Embedding 也能训练但收敛速度会慢很多最终精度也可能差 2% 到 3%。2.3 Preprocess_char.ipynb从原始文本到模型输入资源里的 Preprocess_char.ipynb 是一个 Jupyter Notebook负责把原始评论转换成模型输入的格式。它做的事情很明确加载 JSON 数据 → 清洗文本 → 建立字表 → 将文本转换为索引序列 → padding 到固定长度 → 保存为模型可读的数组。这个脚本是整个流程的入口如果它输出有问题后面所有模型都训练不了。我复现这个 Notebook 时踩过最大的坑是文本长度截断策略。原始代码用的是一个固定长度 max_len但不同评论的长度差异很大——外卖评论往往只有十几个字而电商评论可能上百字。如果 max_len 设置太小长评论的关键信息会被截掉设置太大短评论会被大量 padding浪费计算资源。资源里的默认参数是 max_len200这对 AI Challenger 数据集是够用的因为它的评论大多是短文本。from keras.preprocessing.text import Tokenizer from keras.preprocessing.sequence import pad_sequences MAX_LEN 200 tokenizer Tokenizer(char_levelTrue) tokenizer.fit_on_texts(texts) sequences tokenizer.texts_to_sequences(texts) X_data pad_sequences(sequences, maxlenMAX_LEN, paddingpost, truncatingpost)这段代码的关键在于 char_levelTrue 这个参数它告诉 Tokenizer 按字符而不是按词来切分文本。paddingpost 表示在序列尾部补零truncatingpost 表示从尾部截断。对于评论数据尾部截断通常比头部截断效果更好因为中文评论的核心情感往往出现在句子的中间和后半部分。你如果想调优可以把 truncating 改成 pre 对比一下验证集的效果我试过之后发现 post 在绝大多数情况下更优。3. BiGRU、RCNN 和 Capsule三套模型的结构对比与选型3.1 BiGRU 模型双向门控循环单元的评论建模逻辑资源里的 model_bigru_char.py 定义了第一套模型结构是 Embedding 层加双向 GRU再叠加池化和全连接层。选择 BiGRU 而不是 BiLSTM是因为 GRU 比 LSTM 少一个门控单元参数量更小训练速度更快在评论这种中等长度文本上效果和 BiLSTM 基本持平。对于课程设计或者快速迭代的场景训练时间省下来的收益远大于那一点点精度差异。模型的 Embedding 层会加载 chars.vector 作为预训练权重trainable 参数设置为 True也就是允许在训练过程中微调字向量。这个设置在数据量足够时效果更好因为评论领域有很多通用语料里没有的用法比如“yyds”“绝绝子”这类网络热词微调之后字向量能更好地捕捉这些词的语境。但如果你的训练数据很少建议把 trainable 设为 False防止过拟合。from keras.layers import Input, Embedding, Bidirectional, GRU, GlobalMaxPooling1D, Dense from keras.models import Model def build_bigru_model(vocab_size, embed_dim, max_len, num_classes, embed_matrix): inputs Input(shape(max_len,)) embedding Embedding(vocab_size, embed_dim, weights[embed_matrix], trainableTrue)(inputs) gru_out Bidirectional(GRU(128, return_sequencesTrue))(embedding) pool_out GlobalMaxPooling1D()(gru_out) outputs Dense(num_classes, activationsigmoid)(pool_out) model Model(inputs, outputs) model.compile(optimizeradam, lossbinary_crossentropy, metrics[accuracy]) return model这里有两个参数值得说明。GRU 的隐藏单元数 128 是资源作者调过之后的选择太小了模型容量不够太大了容易过拟合且训练慢。输出层用 sigmoid 激活函数而不是 softmax是因为这是多标签分类任务每个情感标签是独立判断的sigmoid 对每个输出节点单独计算概率互不影响。对应地损失函数用 binary_crossentropy 而不是 categorical_crossentropy这是很多人容易忽略的地方。3.2 RCNN 模型循环神经网络和卷积网络的结合方式model_rcnn_char.py 实现了 RCNN 模型它的核心思想是先用双向 RNN 提取上下文特征再用卷积层和池化层做局部特征融合。为什么在 BiGRU 之外还要做一套 RCNN因为在细粒度情感分析里有些情感是由局部关键词触发的比如“难吃”“太慢”这些词周围的上下文信息对分类至关重要。RCNN 通过最大池化把每个位置最显著的特征提取出来对这类局部强信号更敏感。classifier_rcnn.py 应该是 RCNN 模型的训练脚本里面包含了学习率和 batch size 等超参数配置。资源里 RCNN 模型用的 RNN 单元是 GRU这也是为了和 BiGRU 模型做公平对比——如果一边用 LSTM 一边用 GRU模型差异就不纯粹是结构差异了。我在复现时对比过两者的验证集表现RCNN 在“生气”“害怕”这类细粒度标签上确实比 BiGRU 略好但在“喜欢”“开心”这类高频标签上优势不明显。from keras.layers import Conv1D, MaxPooling1D, concatenate def build_rcnn_char_model(vocab_size, embed_dim, max_len, num_classes, embed_matrix): inputs Input(shape(max_len,)) embedding Embedding(vocab_size, embed_dim, weights[embed_matrix], trainableTrue)(inputs) rnn_out Bidirectional(GRU(128, return_sequencesTrue))(embedding) conv_out Conv1D(filters128, kernel_size3, paddingsame, activationrelu)(rnn_out) pool_out MaxPooling1D(pool_size2)(conv_out) flat_out GlobalMaxPooling1D()(pool_out) outputs Dense(num_classes, activationsigmoid)(flat_out) model Model(inputs, outputs) model.compile(optimizeradam, lossbinary_crossentropy, metrics[accuracy]) return modelConv1D 的 kernel_size3 意味着每个卷积窗口看相邻三个时间步的特征这样可以捕捉到“不 好吃”这种三字范围内的转折关系。filters128 和 GRU 的隐藏单元数保持一致是为了保证特征维度对齐。keras 里如果前面是 Conv1D后面接 GlobalMaxPooling1D中间一般不用再加 Flatten这也是一个常见的小坑。3.3 Capsule 模型为什么用它以及它在这里的边界model_capsule_char.py 是第三套模型基于胶囊网络Capsule Network实现对情感特征的动态路由。胶囊网络的核心优势是能保留特征的空间位置信息比如“不喜欢”这个词组中“不”和“喜欢”的相对位置关系这在传统池化操作里会被丢失。资源里还提供了 JoinAttLayer.py这是一个自定义的注意力层用来结合胶囊的输出和原始特征。胶囊网络在这个数据集上的表现说实话并不总是优于 BiGRU 和 RCNN。我的实测结论是在训练数据充足的情况下Capsule 在部分细粒度标签上能提升 1% 左右的 F1 值但训练时间大约是 BiGRU 的 3 倍。如果你的目的是快速出结果不建议首选 Capsule如果你要做模型对比的实验分析那它就是一个很好的对照组。这也是为什么这套资源值得下载——三套模型放在同一份数据处理流程上做横向对比比你自己从头搭模型要省事得多。4. 模型训练与评测脚本从老式 Keras 到兼容性处理4.1 classifier_bigru.py 和 classify_rcnn.py 的训练流程解读资源里的 classifier_bigru.py 是 BiGRU 模型的训练入口classifier_rcnn.py 对应 RCNN。这两个脚本的流程基本一致加载预处理好的数据数组 → 划分验证集 → 构建模型 → 训练 → 保存权重。classifier_capsule.py 是胶囊模型的训练脚本结构和前两者类似但自定义层更多跑起来更慢。训练脚本里一个值得注意的点是模型保存方式。老式 Keras 训练完会同时保存模型结构 JSON 和权重 HDF5 文件加载时需要先加载结构再加载权重。如果你拿到的是 .h5 后缀的完整模型文件就可以直接用 load_model 加载。我拆这份资源时发现里面的权重文件是用 model.save() 保存的完整模型格式所以加载时不需要再单独定义模型结构。from keras.models import load_model model load_model(model_bigru_char.h5) result model.predict(X_test)预测结果是一个 shape 为 (样本数, 8) 的概率矩阵每一列对应一个情感标签。如果要转成可读的标签需要用前面定义过的 label_map 做反向映射。这里最容易踩坑的地方是预测脚本如果用了自定义层比如 JoinAttLayer加载模型时会报 Unknown layer 错误解决办法是用 custom_objects 参数指定自定义层。4.2 evaluate_char.py 和三个 predict 脚本的配合方式evaluate_char.py 是统一的评测脚本用来计算模型在验证集上的准确率、召回率和 F1 值。predict_bigru_char.py、predict_rcnn_char.py、predict_capsule_char.py 分别是三套模型的预测脚本输出每条评论的情感标签概率。这些脚本的输入是验证集或测试集的 JSON 文件输出是包含 doc_id 和情感标签概率的 CSV 文件。AI Challenger 官方的评测指标是宏平均 F1 值也就是对每个细粒度标签分别计算 F1然后取平均。这样做的好处是避免高频标签主导整体分数让模型在每个情感类别上都保持一定水准。如果你的目的是做课程设计这个评测脚本可以直接用它会生成一份格式标准的评测报告。4.3 老代码的兼容性Keras 2.x 与 TensorFlow 2.x 的冲突这份资源的训练代码是基于 Keras 2.x 写的里面大量使用了 model.add、GlobalMaxPooling1D 这样的老式 API。如果你直接在当前最新的 TensorFlow 2.16 环境下运行大概率会遇到 tf.contrib 模块找不到、GRU 参数名变更等兼容性问题。这不是代码本身的 bug而是框架演进导致的。解决路径有两条。第一条是新建一个 conda 环境安装 TensorFlow 1.15 或 2.0 版本配合对应版本的 Keras把资源里的代码原样跑通。第二条是手动改代码把老式 API 替换成新式 API比如把 model.add 改成函数式 API把 GRU 里的 reset_after 参数删掉。我一般推荐第一条路因为改动最小且能保证和原作者的训练结果一致。conda create -n sentiment python3.6 conda activate sentiment pip install tensorflow1.15.0 keras2.2.4这里提醒一句Python 版本不要选太高。代码里如果用了 Python 3.6 之后移除的内置库或者语法升级到 3.8 以上会有兼容问题。用 conda 管理环境是兼顾稳定性和可复现性的做法比手动改代码要靠谱得多。5. 细粒度情感分析的复现路径与避坑指南5.1 完整复现步骤从数据解析到结果输出整个资源从下载到出结果我梳理了一个可执行的路径。第一步把训练集、验证集、测试集的 JSON 数据放在统一目录下运行 Preprocess_char.ipynb 生成处理好的数组文件。这个步骤里要注意Notebook 里的路径是相对路径如果你换了解压目录需要同步修改。第二步运行 classifier_bigru.py 开始训练 BiGRU 基础模型。训练过程中要留意 GPU 显存占用如果显存不足可以把 batch size 从 64 降到 32或者把 GRU 的隐藏单元数从 128 降到 64。第三步用 evaluate_char.py 评测当前模型查看宏平均 F1 值。如果结果不满意可以用 validation_rcnn_char.py 和 validation_bigru_char.py 对比三套模型的验证集表现从中选择最优模型。第四步也是容易被忽略的一步用 predict 脚本跑测试集把模型给出的细粒度标签写回原始评论数据。我建议把结果保存成和官方提交格式一致的 CSV这一步对课程设计答辩或者论文实验部分很有用。5.2 避坑记录加载模型、乱码、显存不足等关键现象以下是我在复现过程中实际遇到的几个问题按“现象 → 原因 → 解决”的顺序整理出来遇到类似情况可以对照处理。第一条加载 Capsule 模型时提示 Unknown layer: JoinAttLayer。原因是模型结构中包含自定义层Keras 默认不认识这个类名。解决方法是加载时传入 custom_objects 参数把 JoinAttLayer 类显式告诉加载器。from JoinAttLayer import JoinAttLayer model load_model(model_capsule_char.h5, custom_objects{JoinAttLayer: JoinAttLayer})第二条控制台输出的中文评论全部是乱码。原因是 Windows 终端默认编码是 GBK而评论数据是 UTF-8。解决方法是把输出文件的编码显式指定为 UTF-8或者在 Python 脚本开头设置环境变量。我一般偏向在代码里用 encodingutf-8 参数这样可以跨平台跑。第三条训练时 GPU 显存不足报 ResourceExhaustedError。原因是默认 batch size 太大或 GPU 共享内存被其他进程占用。解决方法是先查看 GPU 使用情况把 batch size 调小并在训练前设置显存按需增长。Keras 里面设置显存增长的代码需要放在导入 Keras 之前。import tensorflow as tf from keras.backend.tensorflow_backend import set_session config tf.ConfigProto() config.gpu_options.allow_growth True set_session(tf.Session(configconfig))第四条验证集 F1 值很高但测试集表现很差。原因可能是验证集和测试集分布不一致或者是训练时验证集切分方式没有随机化。解决方法是检查预处理脚本确保在划分验证集前先对数据做 shuffle。AI Challenger 原始数据在官方切分时是保持相似分布的但你自己用 train_test_split 切分时要注意设置 random_state 固定随机种子。第五条训练 loss 在初期就降到接近 0但验证集 F1 值很低。原因可能是标签编码错误比如没有用多热编码而是用了单标签编码模型实际上在学一个所有标签都为 0 的输出。解决方法是检查训练样本中随机挑几条打印 label_vec 看是否包含多个 1如果所有样本都是单一标签为 1那就需要回头检查数据加载函数。5.3 参数调优方向字向量维度、句子长度和模型结构怎么改这套资源的默认参数是字向量维度 200、最大句子长度 200、GRU 单元数 128。如果你要调整三条主线可以参考。第一条是字向量维度从 200 降到 100 可以明显减少显存占用但精度通常会下降 1% 到 2%如果数据量大升到 300 有可能带来小幅提升。第二条是句子长度AI Challenger 的评论平均长度在 45 字左右如果只做短文本数据分析可以把 max_len 降到 100训练速度会快很多。第三条是模型层数BiGRU 和 RCNN 都可以尝试叠加第二层 GRU 或扩大卷积核数量但层数增加带来的收益在短文本上非常有限反而容易过拟合。此外可以尝试在三种模型之间做模型融合。具体做法是分别训练三套模型然后用多数投票或者概率平均的方式合并预测结果。对于细粒度情感分析这种多标签任务概率平均比多数投票更合适因为它保留了每个标签的置信度信息。资源里的 predict 脚本已经输出了概率矩阵做融合时只需要把三个脚本的输出读进来求平均即可。6. 把评论预测结果落到业务场景验证集分析与最优模型选择复现这套资源最终的一步不是把模型训练完就结束而是要用验证集对三套模型做一次系统的横向评测选出在宏观 F1 值上表现最优的那套然后把预测结果对应回原始评论看看模型到底在哪些地方容易犯错。我一般会写一个小脚本把验证集每条评论的预测标签和真实标签并排输出重点关注那些被模型遗漏的细粒度标签。实际观察下来三套模型在“喜欢”和“开心”这两个高频标签上表现都不错差异主要体现在低频标签上。“害怕”和“尴尬”这类标签的训练样本本身数量就少模型容易把它们预测成相近的情感比如把“尴尬”误判成“生气”。这是数据不平衡导致的不是模型结构的问题。如果想让低频标签的表现更好常见做法是在损失函数里给高频标签降低权重或者用 Focal Loss 替代 binary_crossentropy。不过这会增加代码复杂度课程设计阶段不建议贸然改动。在最优模型的选择上我的习惯是先用验证集 F1 值做第一轮筛选再检查预测结果在几个典型样本上的输出质量。比如输入一条“等了一个小时外卖才到饿死我了平台必须给个说法”好的模型应该同时输出“生气”和“伤心”两个标签的高概率。如果模型只输出“生气”说明它对复合情感的捕捉还不够好。这套资源的三套模型在这类样本上的表现差异很大通常 RCNN 比 BiGRU 更擅长捕捉这种多标签的复合情绪。从那以后我每次做情感分析项目都强制自己走一遍“数据探测 → 基线模型 → 结构对比 → 错误样例分析”的流程不再直接拿一个现成模型跑完就交差。单纯追求准确率数字没有太大意义真正能说明问题的是模型在验证集上错在哪里、哪些情感类别容易被混淆。这套资源的意义就在于它把对比实验的基础设施一次性给足了你只需要把注意力放在观察与分析上而不必从零搭建训练和评测框架。希望这份拆解能帮你在复现时少走一些弯路。本文还有配套的精品资源点击获取
