1. 项目缘起与整体设计思路中文电影评论的情感分类说白了就是让机器判断一条影评是“好评”还是“差评”。这个任务听起来简单但真正动手做过的人都知道中文文本的坑远比英文多——分词边界模糊、网络用语层出不穷、情感表达常常靠反讽和隐喻。我在实际项目中试过好几种方案从最朴素的关键词匹配到微调预训练模型最后发现对于中小规模数据集和快速上线的需求来说TextCNN是一个性价比极高的选择。这个项目的核心目标很明确输入一条中文电影评论输出它属于正面还是负面情感的概率。适合谁来参考如果你已经了解PyTorch的基本用法知道什么是张量、什么是nn.Module但还没完整走过一遍文本分类的流程那这个项目就是为你准备的。如果你是完全零基础的小白也不用慌我会把每一步的原理和操作都拆开讲你跟着敲一遍就能跑通。为什么选TextCNN而不是LSTM或者BERT这里面的考量值得展开说说。LSTM系列模型虽然能捕捉长距离依赖但训练速度慢调参成本高对于影评这种长度通常在几十到几百字的文本来说TextCNN的卷积核已经足够覆盖关键情感片段。BERT效果好但推理延迟高部署成本大如果只是做一个中小型影评分类服务用BERT有点“杀鸡用牛刀”。TextCNN的结构天然适合捕捉局部n-gram特征比如“演技炸裂”“剧情拖沓”这种情感强烈的短语卷积核一扫就能抓住。整个项目的设计思路分为四大块数据准备与预处理、模型搭建、训练与评估、推理与部署。数据准备阶段要解决中文分词和词表构建的问题模型搭建阶段要确定卷积核尺寸、通道数、Dropout比例等超参数训练阶段要处理类别不平衡和学习率调度推理阶段要考虑模型保存和加载的兼容性。每一块都有各自的坑我会在后面的章节里逐一拆解。提示TextCNN的原始论文是2014年提出的虽然年代久远但在文本分类任务上依然能打。不要因为“老”就轻视它很多工业级场景里它仍然是baseline的首选。2. 数据准备与中文预处理的核心细节2.1 中文分词工具选型与实操中文和英文最大的区别在于英文单词天然由空格分隔而中文是一串连续的字符。所以第一步必须做分词。我试过jieba、THULAC、HanLP这几个主流工具最后在影评分类任务上选了jieba。原因很简单jieba的准确率在通用领域足够用安装方便速度也快而且支持自定义词典。影评里经常出现电影名、演员名、网络流行语这些词如果被切碎了情感特征就丢了。安装jieba很简单pip install jieba用的时候可以加载自定义词典把“演技炸裂”“剧情拖沓”“五毛特效”这类短语加进去保证它们不被切开import jieba jieba.load_userdict(movie_dict.txt) text 这部电影的演技炸裂但剧情拖沓得让人想睡觉 words jieba.lcut(text) print(words) # [这部, 电影, 的, 演技炸裂, , 但, 剧情拖沓, 得, 让人, 想, 睡觉]注意标点符号和停用词要过滤掉。停用词表可以用哈工大停用词表或者百度停用词表网上都能找到。过滤之后文本就变成了干净的词序列。注意不要用jieba.cut返回生成器后直接转列表在大规模数据上会吃内存。建议用jieba.lcut逐条处理或者用jieba.cut配合生成器逐条消费。2.2 词表构建与序列截断策略分词完成后需要构建词表。词表的本质是一个“词到索引”的映射。我通常的做法是统计所有词的出现频率保留频率最高的N个词比如20000个其余的全部映射到UNK。为什么要限制词表大小因为低频词对模型训练的贡献很小反而会增加参数量容易过拟合。from collections import Counter all_words [] for text in corpus: all_words.extend(jieba.lcut(text)) word_counts Counter(all_words) vocab {word: idx 2 for idx, (word, _) in enumerate(word_counts.most_common(20000))} vocab[PAD] 0 vocab[UNK] 1序列截断是另一个关键点。影评长度差异很大有的只有几个字有的上千字。TextCNN要求输入固定长度所以需要设定一个max_len。我的经验是先统计所有影评的长度分布取95分位数作为max_len。比如95%的影评都在300字以内那就设max_len300。超过300的截断不足300的用PAD补齐。def encode(text, vocab, max_len300): words jieba.lcut(text) ids [vocab.get(w, vocab[UNK]) for w in words] if len(ids) max_len: ids ids [vocab[PAD]] * (max_len - len(ids)) else: ids ids[:max_len] return ids这里有个细节补齐的时候用PAD的索引0但计算损失的时候要忽略这些位置。PyTorch的CrossEntropyLoss本身不处理序列填充但TextCNN最后是全局池化所以填充位置的影响会被平均掉。不过更严谨的做法是在池化时用mask把填充位置排除掉这个后面讲模型的时候再说。2.3 数据集划分与类别平衡处理影评数据集通常正负样本比例不会太悬殊但也不绝对。我遇到过正样本占70%的情况这时候如果直接训练模型会倾向于预测正类准确率看起来很高但召回率惨不忍睹。解决办法有两个一是重采样对少数类过采样或者对多数类欠采样二是用加权损失函数给少数类更高的权重。from torch.utils.data import WeightedRandomSampler class_counts [len(pos_samples), len(neg_samples)] weights [1.0 / c for c in class_counts] sample_weights [weights[label] for _, label in dataset] sampler WeightedRandomSampler(sample_weights, num_sampleslen(sample_weights), replacementTrue)数据集划分我一般按8:1:1切分训练集、验证集、测试集。验证集用来调超参数和早停测试集只在最后评估一次。千万不要用测试集调参否则评估结果会虚高。3. TextCNN模型搭建与关键参数解析3.1 模型结构逐层拆解TextCNN的结构其实很简洁嵌入层 → 卷积层 → 池化层 → 全连接层。但每一层都有讲究。嵌入层把词索引映射成稠密向量。嵌入维度通常取128或256。我试过64和51264表达能力不够512参数量太大128到256之间比较平衡。嵌入层可以用预训练的词向量初始化比如用word2vec或者fastText在大量中文语料上训练好的向量。如果没有预训练向量随机初始化也能跑但收敛会慢一些。import torch import torch.nn as nn import torch.nn.functional as F class TextCNN(nn.Module): def __init__(self, vocab_size, embed_dim256, num_filters128, filter_sizes[2,3,4,5], num_classes2, dropout0.5): super(TextCNN, self).__init__() self.embedding nn.Embedding(vocab_size, embed_dim, padding_idx0) self.convs nn.ModuleList([ nn.Conv2d(1, num_filters, (k, embed_dim)) for k in filter_sizes ]) self.dropout nn.Dropout(dropout) self.fc nn.Linear(num_filters * len(filter_sizes), num_classes) def forward(self, x): # x: [batch_size, seq_len] x self.embedding(x) # [batch_size, seq_len, embed_dim] x x.unsqueeze(1) # [batch_size, 1, seq_len, embed_dim] x [F.relu(conv(x)).squeeze(3) for conv in self.convs] x [F.max_pool1d(conv, conv.size(2)).squeeze(2) for conv in x] x torch.cat(x, dim1) x self.dropout(x) x self.fc(x) return x卷积核尺寸选了2、3、4、5分别对应bigram、trigram、4-gram、5-gram特征。为什么不用更大的核因为影评的情感表达通常集中在短短语上太大的核反而会引入噪声。每个尺寸的卷积核数量设128四个尺寸加起来就是512个特征全连接层输入维度就是512。池化层用的是全局最大池化也就是对每个卷积核的输出取最大值。这样做的好处是不管输入序列多长池化后的维度都是固定的。而且最大池化能捕捉最强烈的特征比如“炸裂”这个词只要出现一次就会被池化层抓住。3.2 超参数选择与调参经验超参数这块我踩过不少坑这里直接给出一组经过验证的配置超参数推荐值说明嵌入维度256128到256之间视词表大小调整卷积核数量128每个尺寸128个总共512卷积核尺寸[2,3,4,5]覆盖常见n-gram范围Dropout0.5防止过拟合训练时随机丢弃学习率1e-3Adam优化器配合ReduceLROnPlateauBatch Size64显存不够就降到32训练轮数20配合早停通常10轮内收敛学习率调度我用的是ReduceLROnPlateau验证集损失连续3轮不下降就把学习率乘以0.5。这个策略比固定学习率稳得多尤其是训练后期小学习率能让模型更精细地收敛。optimizer torch.optim.Adam(model.parameters(), lr1e-3) scheduler torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, modemin, factor0.5, patience3)提示Dropout比例不要设太高0.5已经足够。设到0.7以上会导致欠拟合训练损失降不下去。3.3 损失函数与优化器选择二分类任务用CrossEntropyLoss就行它内部包含了Softmax。如果类别不平衡可以传weight参数class_weights torch.tensor([1.0, 2.0]) # 假设负类样本少给更高权重 criterion nn.CrossEntropyLoss(weightclass_weights)优化器选Adam学习率1e-3。Adam的自适应学习率在文本任务上表现很稳不需要太多手动调参。如果追求极致效果可以试试AdamW它把权重衰减和梯度更新解耦泛化能力稍好一些。4. 训练流程与实操现场记录4.1 训练循环的完整实现训练循环的骨架很固定前向传播 → 计算损失 → 反向传播 → 更新参数。但细节决定成败。我习惯在每个epoch结束后在验证集上评估记录损失和准确率同时保存验证集上最好的模型。def train(model, train_loader, val_loader, criterion, optimizer, scheduler, epochs20, patience5): best_val_loss float(inf) patience_counter 0 for epoch in range(epochs): model.train() total_loss 0 for batch_x, batch_y in train_loader: optimizer.zero_grad() logits model(batch_x) loss criterion(logits, batch_y) loss.backward() optimizer.step() total_loss loss.item() avg_train_loss total_loss / len(train_loader) # 验证 model.eval() val_loss 0 correct 0 total 0 with torch.no_grad(): for batch_x, batch_y in val_loader: logits model(batch_x) loss criterion(logits, batch_y) val_loss loss.item() preds torch.argmax(logits, dim1) correct (preds batch_y).sum().item() total batch_y.size(0) avg_val_loss val_loss / len(val_loader) val_acc correct / total scheduler.step(avg_val_loss) print(fEpoch {epoch1}: train_loss{avg_train_loss:.4f}, val_loss{avg_val_loss:.4f}, val_acc{val_acc:.4f}) if avg_val_loss best_val_loss: best_val_loss avg_val_loss torch.save(model.state_dict(), best_model.pt) patience_counter 0 else: patience_counter 1 if patience_counter patience: print(Early stopping triggered) break这段代码里有个容易忽略的点model.eval()和model.train()的切换。Dropout和BatchNorm在训练和推理时的行为不同忘记切换会导致验证结果不稳定。我见过有人忘了切eval()验证准确率忽高忽低排查了半天才发现是Dropout在作怪。4.2 训练过程监控与日志记录光看损失和准确率还不够我习惯用TensorBoard记录训练曲线方便对比不同超参数的效果。PyTorch自带SummaryWriter几行代码就能接入from torch.utils.tensorboard import SummaryWriter writer SummaryWriter(runs/textcnn_experiment) writer.add_scalar(Loss/train, avg_train_loss, epoch) writer.add_scalar(Loss/val, avg_val_loss, epoch) writer.add_scalar(Accuracy/val, val_acc, epoch)训练过程中要关注几个信号训练损失和验证损失的差距。如果训练损失持续下降但验证损失开始上升说明过拟合了需要增大Dropout或者加L2正则。如果两者都降不下去说明欠拟合需要增大模型容量或者提高学习率。注意TensorBoard的日志文件会越积越大实验多了之后记得定期清理不然磁盘很快就满了。4.3 模型保存与加载的兼容性处理保存模型有两种方式保存整个模型对象或者只保存参数字典。我强烈推荐后者因为保存整个模型对象依赖具体的类定义换了个环境或者改了类名就加载不了。# 保存 torch.save(model.state_dict(), best_model.pt) # 加载 model TextCNN(vocab_sizelen(vocab)) model.load_state_dict(torch.load(best_model.pt, map_locationcpu)) model.eval()map_locationcpu这个参数很重要。如果模型是在GPU上训练的加载时没有GPU或者GPU编号变了不加这个参数会报错。加上之后会自动把参数映射到CPU然后再手动搬到目标设备。5. 常见问题与排查技巧实录5.1 损失不下降的排查思路训练时最让人抓狂的就是损失不下降。我总结了一套排查流程现象可能原因解决办法损失始终在0.69左右模型输出恒定相当于随机猜检查学习率是否太小检查数据标签是否正确损失震荡剧烈学习率太大降低学习率或加梯度裁剪训练损失降但验证不降过拟合增大Dropout加L2正则早停损失突然变成NaN梯度爆炸加梯度裁剪降低学习率梯度裁剪在文本任务里很常用尤其是RNN系列模型。TextCNN虽然不容易梯度爆炸但加上也无妨torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0)5.2 中文分词的边界问题分词工具再厉害也会遇到切错的情况。比如“不喜欢”可能被切成“不”和“喜欢”情感极性完全反了。解决办法是在自定义词典里把“不喜欢”加进去或者用更细粒度的字符级模型。字符级模型不需要分词直接把每个字当成一个token缺点是序列变长计算量增大。我的建议是如果分词工具在验证集上的表现可以接受就用词级如果差得离谱再考虑字符级。5.3 推理速度优化技巧训练好的模型要上线服务推理速度很关键。TextCNN本身已经很快了但还有优化空间。第一把模型转成torchscript去掉Python解释器的开销scripted_model torch.jit.script(model) scripted_model.save(textcnn_scripted.pt)第二用ONNX Runtime推理在CPU上通常比原生PyTorch快20%到50%。第三批处理推理把多条影评攒成一个batch一起送进模型吞吐量能提升好几倍。提示转torchscript之前要确保模型里没有动态控制流TextCNN的结构是静态的转起来很顺利。5.4 实际部署中的坑与应对部署时最容易忽略的是预处理的一致性。训练时用的分词工具、停用词表、词表映射推理时必须完全一致。我见过有人训练时用了停用词过滤推理时忘了过滤结果模型效果大打折扣。解决办法是把预处理逻辑封装成一个类训练和推理共用同一份代码。另一个坑是词表外的词。推理时遇到训练时没见过的词要映射到UNK。如果UNK的比例太高说明训练数据和实际数据分布差异大需要考虑重新训练或者扩充词表。6. 效果评估与改进方向6.1 评估指标的选择准确率是最直观的指标但在类别不平衡时会有误导性。我通常同时看准确率、精确率、召回率和F1值。对于影评情感分类如果业务上更关心“不放过一个差评”那就重点看负面类的召回率如果更关心“不误伤好评”那就看负面类的精确率。from sklearn.metrics import classification_report print(classification_report(y_true, y_pred, target_names[负面, 正面]))混淆矩阵也很直观能看出模型到底把哪些样本分错了。我习惯把分错的样本导出来看看经常能发现一些标注错误或者分词问题。6.2 模型改进的可行路径TextCNN跑通之后如果效果不够好有几个改进方向。第一用预训练词向量初始化嵌入层比如用大规模中文语料训练的词向量通常能提升2到5个百分点的准确率。第二加注意力机制让模型自动学习哪些词对情感判断更重要。第三用多通道嵌入同时用静态和动态词向量类似Kim在2014年论文里的做法。第四如果数据量足够大直接上BERT微调效果会有质的飞跃但推理成本也相应增加。我个人在实际操作中的体会是先把TextCNN的baseline跑稳确认数据预处理和训练流程没有问题再去尝试更复杂的模型。很多人在预处理阶段就埋了雷换再好的模型也救不回来。另外影评数据里的反讽和隐喻是难点比如“真是太好看了我看睡了三次”这种样本TextCNN很难处理需要更深的语义理解能力。如果业务场景里这类样本占比高建议直接上预训练模型。最后再分享一个小技巧训练时可以用对抗训练FGM增强鲁棒性在嵌入层加扰动让模型对输入的小变化不敏感。实现起来不复杂但效果提升很明显尤其是在小数据集上。