1. 项目背景与整体方案选型前阵子接了个小任务给一个影评聚合网站加自动评价倾向判断功能。用户评论一进来系统要在百毫秒级别内判断这段评价总体是正面还是负面输出结果给推荐系统和内容运营同事使用。团队里第一时间有人提议直接用BERT或者更大规模的预训练模型但评估下来发现线上推理用的是CPU资源池存储与响应时间都不太允许拖一个几百MB的模型到处跑。权衡之后我最终选了“PyTorch Text-CNN Word2vec”这套偏传统的技术组合。为什么说这套组合在Transformer时代依然值得用因为它把“可接受的准确率”和“极低的部署成本”很好地平衡在一起。Text-CNN作为轻量级分类器参数规模只有几十万到几百万Word2vec提供的词向量又给模型补充了预训练知识不至于让CNN从头瞎猜词义。这个组合特别适合文本分类、情感分析这类局部特征很关键的任务也是很多中小型团队最常采用的落地路线之一。这篇文章不是泛泛讲原理。我会按真实项目流程把每个环节拆开数据怎么清洗、词向量怎么训练、Text-CNN怎么搭、训练和调参有哪些关键细节、我实际踩过的坑是什么。如果你是打算做NLP入门项目或者要在生产环境里快速落地一个情感分析模型这篇可以直接当操作手册用。1.1 任务拆解电影评论情感分析到底要解决什么问题先说任务表面输入一段文本输出一个类别正面/负面。但实际生产环境里的问题要复杂得多。影评文本是高度口语化的常见特征包括长度分布极不均匀从一句“好看”到几千字长评都有。反讽、双关、引号用法非常多字面词性和情感极性经常相反。大量领域词汇和简称比如电影角色名、导演昵称、系列篇名。中英文混杂表情符号和网络新词频繁出现。这些都导致一个结果直接把原始文本喂给模型效果会非常差。所以整个项目最花时间的不是模型设计而是数据工程。我大概统计过数据处理和清洗占了整个项目60%以上的工作量。模型本身倒是很成熟几行PyTorch代码就能搭起来。还要补充一点情感分析不是只有一个分类维度。有些场景需要输出多个情绪标签愤怒、失望、兴奋有些需要判断强度分数。但这个项目业务方只关心正负方向所以二分类就够了。如果后续需要多分类模型结构上的改动其实很小只要把输出层的num_classes改掉即可。1.2 为什么选Text-CNN而不是RNN或Transformer做文本分类模型选型一般有三条路RNN/LSTM、Text-CNN、Transformer。我直接给结论没有哪个模型绝对最好只有哪个模型最适合手头场景。一个是数据量另一个是部署约束这两点决定了选型上限。RNN/LSTM在处理文本时天然适合序列建模但它是顺序计算的训练和推理都慢很难并行加速。在短文本情感分析上LSTM的双向版本通常能有不错的准确率可是CPU推理时延往往是CNN的两三倍。Transformer类模型比如BERT、RoBERTa系列准确率一般是最高的尤其擅长处理反讽和长距离语义。但这类模型参数量大推理依赖GPU或专业加速卡就算做蒸馏部署复杂度也比CNN高一个量级。对一个只需要判断影评正负的项目来说属于杀鸡用牛刀。Text-CNN则完全不同。它的灵感来自计算机视觉中的卷积神经网络把句子看成一幅一维的“图像”。多个不同高度的卷积核在句子窗口上滑动提取不同长度的局部特征然后经过最大池化得到一个定长的特征向量。局部n-gram特征恰恰是情感分析的核心判断“烂片”“惊艳”“不值票价”这类表达不需要很长的上下文局部几组词已经足够。CNN这种局部特征抽取能力正合适。我用一个表格来对比三种方案在这个任务上的实际体验方案准确率表现CPU推理速度部署复杂度LSTM中等约87%~89%较慢单条约30毫秒以上中等Text-CNN略低于LSTM约1个百分点快单条约5~10毫秒低BERT类高可达95%左右很慢CPU上经常超过500毫秒高对比很明确Text-CNN在准确率上没有拉开太大差距但推理速度和部署成本优势非常突出。我当时在CPU上单测Text-CNN处理一条短评大概在5~10毫秒换成LSTM要到30毫秒以上BERT在CPU上更夸张单个样本经常要500毫秒起步。业务要求百毫秒级Text-CNN是唯一不需要做额外工程优化的方案。1.3 Word2vec在这个方案里的角色模型只负责“怎么分类”但文本必须要先变成模型能计算的数字才行。最粗糙的做法是One-hot编码一个词对应一个稀疏向量。这种表示最大的问题是词汇鸿沟“电影”和“影片”在一两个维度上不同但它们语义接近的事实完全无法体现。训练数据中“电影”出现了一万次“影片”只出现了十次模型对“影片”的理解就会非常弱。Word2vec就是为了解决这个问题出现的。它通过语言模型的旁路任务把每个词映射到一个低维稠密向量空间目标是让语义相近的词在向量空间里距离更近。训练出“好看”和“精彩”的向量距离很近“难看”和“难受”的距离很近。模型拿到这种初始化好的词向量之后就不再是从零开始学习词义学习负担大大降低。在这个项目里我没有直接用公开预训练词向量而是用自己收集的影评语料重新训练了一套。原因有两方面第一影评领域的专有词汇在通用预训练向量里覆盖率不高比如“彩蛋”“路演”“院线”“观众口碑”这些词在新闻语料里很少出现第二通用向量通常偏向正式文本和影评这种口语化表达存在分布偏差。自训练词向量虽然不敢说质量顶尖但和下游任务分布非常契合。2. 数据准备与词向量构建这一部分进入实操环节。我尽量把每个步骤解释清楚包括“为什么要这么做”。2.1 影评数据的获取与清洗流程项目使用的是某公开电影评论数据集总共约10万条短评每条都有正负标签。短评平均长度约40个词中位长度35个词非常适合CNN场景。因为句子短不会出现长距离依赖问题CNN的局部特征优势能得到充分发挥。拿到原始数据后第一件事是清洗。这里我把清洗流程拆成四步去HTML和转义字符。爬虫数据里经常残留br /、nbsp;、#39;之类的内容先用正则替换成空格。统一文本格式。英文字母全部小写中文繁体转简体全角标点转半角。表情符号处理。这个是一个点睛操作。影评中的emoji有很强的情感信号比如笑脸和哭脸。直接删掉会丢失信号保留又会造成词表膨胀。我选择把常见emoji映射成特殊标记例如笑脸类映射为_pos_emoji哭脸类映射为_neg_emoji。这样既压缩了词表又保留了情感信息。过滤无效样本。比如全篇只有无意义字符的评论长度小于两个词的短评统一删除。这些样本没有分类价值留着只会增加噪声。预处理代码大致如下import re html_re re.compile(r[^]|[a-zA-Z];) at_re re.compile(r[\w\-]) def clean_text(text): text html_re.sub( , text) text text.lower() # 繁体转简体可调用开源库此处用占位函数 text trad_to_simp(text) text at_re.sub( , text) emoji_map {: _pos_emoji, : _neg_emoji, : _neg_emoji} for key, val in emoji_map.items(): text text.replace(key, val) return text.strip()实际运行中我遇到一个情况有个别评论通篇就是一行网址这种内容没有情感信息通过规则过滤掉远比让模型学要划算。所以我在清洗阶段还顺手加了URL过滤规则。2.2 分词、词表与序列化中文文本分词是必须的。用基于统计的分词工具加载默认词典后对每条评论切词。这里有个细节分词之后不要急着打标签最好顺手做一遍错别字的批量替换。影评里常见网络热词我维护了一个手工词表把它们映射成标准词或通用情感词。虽然覆盖不了全部但常见高频词都能处理效果提升还挺明显。词表构建的流程是统计全语料中分词后的词频按照频次降序排列每个词分配一个整数ID。词表大小控制在5万以内出现次数低于3次的词统一替换为UNK标记。PAD标记固定为0UNK固定为1。这种做法的理由是控制嵌入矩阵大小避免向量维度倒挂。序列化到定长的时候需要统计长度分布。统计显示95%的样本在150词以内于是我把序列长度设为150。超过150的部分按照“尾部优先”策略截断保留结尾把开头截掉。这么做是因为影评的最终态度经常落在文章的结尾部分比如“可惜的是整体还是一部平庸之作”真正的判断词在后面。如果保留头部丢弃尾部等于删掉了最有信息量的部分。用代码来表达序列化过程from collections import Counter def build_vocab(tokenized_corpus, max_size50000, min_freq3): counter Counter() for sent in tokenized_corpus: counter.update(sent) vocab {PAD: 0, UNK: 1} for word, freq in counter.most_common(max_size - 2): if freq min_freq: vocab[word] len(vocab) return vocab def encode_and_pad(tokens, vocab, max_len150): ids [vocab.get(w, 1) for w in tokens] if len(ids) max_len: ids ids[-max_len:] # 保留尾部 else: ids ids [0] * (max_len - len(ids)) return ids2.3 Word2vec训练参数选择与代码实现词表构建完成后我直接使用全量分词后的语料来训练Word2vec。训练方式选择Skip-gram不选择CBOW。原因是Skip-gram每个词作为中心词更新周围的上下文词它对低频词的向量质量更好。对于影评这种领域性强的语料低频词往往是领域特有词价值反而高。向量维度选100。维度大固然信息容量多但训练时间和内存也会上升维度小又表达不了足够语义差异。100维是一个性价比很高的选择在很多公开评测里100维和300维在短文本分类上的差距并不显著。训练用的工具是gensim核心参数如下from gensim.models import Word2Vec sentences [ [电影, 剧情, 很, 紧凑], [演员, 演技, 在线], # ... 全部分词后的评论 ] model Word2Vec( sentences, vector_size100, window5, min_count3, workers4, sg1, # 1skip-gram0CBOW epochs10, seed42 ) model.save(word2vec_100d.model)这里重点补充window的含义。window5表示取中心词前后共5个词作为上下文窗口。影评里的转折词和程度副词经常出现在距离中心词2到3个词的位置所以窗口取5可以覆盖这些信息如果window设得太小比如1或者2就只能捕获紧邻的词语义建模能力偏弱。训练完之后做一次直观检查非常有必要。直接查看“好看”的相似词word_vectors model.wv for similar_word, score in word_vectors.most_similar(好看, topn10): print(similar_word, round(score, 4))如果有出现“精彩”“风趣”“感人”这类正向词说明词向量质量基本在线如果出现一堆无关词就要检查语料质量或者提高epoch、调整窗口大小。词向量不是训练完就结束的它相当于整个模型的“地基”。2.4 嵌入矩阵的生成与映射训练好Word2vec之后下一步是按词表顺序生成嵌入矩阵。词表里的每个词去Word2vec模型里查对应的向量查到了就放在对应行查不到就随机初始化一个较小的向量。这里需要用固定随机种子保证每次运行结果可复现。矩阵生成代码import numpy as np def build_embedding_matrix(vocab, w2v_model, embed_dim100): matrix np.random.uniform(-0.05, 0.05, (len(vocab), embed_dim)) for word, idx in vocab.items(): if word in w2v_model.wv: matrix[idx] w2v_model.wv[word] matrix[0] np.zeros(embed_dim) # PAD 向量置零 return matrix这里有一个非常关键的细节PAD位置的向量必须置为零。因为在卷积池化时如果PAD向量是随机值而非零模型会从空白位置学到虚假特征。而置零配合padding_idx0空白位置就不会对卷积结果产生贡献。另外UNK位置的向量可以是随机小值不要置零。因为真实样本中会出现UNK让它的值可训练、在训练中更新效果远好于固定零向量。3. Text-CNN模型设计与PyTorch实现3.1 从卷积核到池化Text-CNN的核心机制先把Text-CNN的结构讲透。输入是一个词ID序列经过嵌入层查表后变成一个形状为batch_size, seq_len, embedding_dim的三维矩阵。把embedding_dim作为矩阵的“宽度”seq_len作为“高度”整个输入可以看成一幅宽度固定、高度可变的图像。卷积层使用Conv2d但特殊的kernel_size(k, embedding_dim)。这意味着卷积核的宽度与词向量维度相等卷积只会沿着序列方向滑动不会在向量维度上做卷积。这种设计考虑是每个词向量维度里每一个分量没有独立的局部位置意义卷积混合向量维度会发生混乱。卷积核的高度k代表一次覆盖几个词也就是k-gram的大小。k2时卷积核看见两个词的组合k3时看见三个词的组合。多组不同高度的卷积核相当于用一组“词组匹配器”在文本里扫描。经过卷积后每个卷积核得到一个变长的特征图。最大池化层把每个特征图中的最大值取出来作为该卷积核捕捉到的最重要特征。这样无论输入的句子长短池化后都能得到定长的特征向量从而接入全连接层。为什么用最大池化而不是平均池化情感分析里一条评论往往是通过某个词强烈表达情感比如“剧情烂透了”关键信号在于“烂透”。最大池化会把“烂透”对应的强激活保留下来不会被周围几个中性词稀释掉。平均池化更适合所有位置贡献均匀的场景情感分析显然不是这种场景。3.2 PyTorch实现逐段解读完整模型代码如下import torch import torch.nn as nn import torch.nn.functional as F class TextCNN(nn.Module): def __init__(self, vocab_size, embedding_dim, num_filters100, filter_sizes(2, 3, 4), num_classes2): super().__init__() self.embedding nn.Embedding(vocab_size, embedding_dim, padding_idx0) self.convs nn.ModuleList([ nn.Conv2d(1, num_filters, (kernel_size, embedding_dim)) for kernel_size in filter_sizes ]) self.dropout nn.Dropout(0.5) 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, seq_len, embed_dim) x x.unsqueeze(1) # (batch, 1, seq_len, embed_dim) conv_outs [] for conv in self.convs: c conv(x) # (batch, num_filters, conv_out_len, 1) c torch.relu(c) c c.squeeze(3) # (batch, num_filters, conv_out_len) pooled F.max_pool1d(c, c.size(2)).squeeze(2) # (batch, num_filters) conv_outs.append(pooled) merged torch.cat(conv_outs, dim1) # (batch, num_filters*len) merged self.dropout(merged) logits self.fc(merged) return logits这里按行拆解顺带说明一些容易被忽视的细节nn.Embedding(vocab_size, embedding_dim, padding_idx0)padding_idx参数一旦指定该位置的嵌入向量不参与梯度更新。nn.Conv2d(1, num_filters, (kernel_size, embedding_dim))输入通道为1因为嵌入结果经过unsqueeze(1)之后增加了一个通道维度输出通道为num_filters表示这种宽度的卷积核数量。F.max_pool1d(c, c.size(2))这里的c.size(2)是卷积后的特征图长度对整个长度做最大池化输出形状变成batch, num_filters。nn.Dropout(0.5)在池化之后、全连接层之前加Dropout这是防止过拟合的关键动作。模型代码里还有一个微调当输入序列长度固定为150时不同宽度卷积核产生的特征图长度不同。宽度越大特征图越短但最大池化会把它们都压缩成1个值所以不同宽度之间不会出现形状不一致的问题。这也是Text-CNN非常适合定长序列分类任务的原因。注意嵌入层的padding_idx一旦确定后续推理时的PAD索引必须保持为0。词表一旦固定编号映射就要固定下来最好额外存一份JSON文件做运行时校验防止训练和线上两套逻辑不一致。3.3 嵌入层初始化与微调策略模型初始化时如果用from_pretrained(embedding_matrix, freezeFalse)几乎所有参数都会参与训练。这里说的“几乎所有”是因为PAD位置的嵌入向量虽然参与计算但梯度为零不会更新。实际经验是整个训练过程分成两个阶段效果更好。第一阶段把嵌入层冻结设置freezeTrue只训练卷积层和全连接层。这样做的好处是模型先用已经训练好的语义空间去拟合分类任务不会因为随机初始化的卷积层产生动荡梯度反过来把词向量带偏。第二阶段训练两个epoch之后解冻嵌入层设置freezeFalse所有参数一起训练。这个时候模型已经基本稳定微调词向量可以让每个词在分类任务方向上稍微挪动通常能再涨1到2个点的准确率。这个“先冻结再解冻”的思路在迁移学习中很常见但很多入门教程没有提到。embedding_matrix torch.tensor(embedding_matrix, dtypetorch.float32) model.embedding nn.Embedding.from_pretrained(embedding_matrix, freezeFalse)4. 训练配置、指标评估与调参过程4.1 超参数设置的逻辑与参考配置我把完整超参配置列出来序列长度150词向量维度100卷积核宽度2、3、4每种宽度卷积核数量100Dropout0.5Batch size64优化器Adam初始学习率0.001训练轮数10含早停Batch size为64在单卡GPU的情况下批处理计算很快显存占用也很小。如果用更大的batch比如256收敛速度是快了但验证集准确率通常会下降这是因为大batch让梯度方向更稳定但同时更容易陷入尖锐极值点。学习率0.001是Adam的常规默认值适合大多数小模型。如果发现loss迟迟不下降可以尝试0.0005或0.002但一般情况下不必急着调。优化器选Adam而非SGD是因为Adam自带一阶动量和二阶动量对学习率不那么敏感更多时候省心。如果换了SGD可能还要配合学习率衰减策略训练过程会变得慢很多。训练初期我把clip也加上了防止个别异常样本把梯度炸飞。4.2 训练循环与早停机制训练代码本身简单但“早停”是很重要的机制。它不只决定训练多久还决定了保存哪个模型。我在验证集上计算准确率如果连续两个epoch没有提升就停止训练并回滚到最佳epoch的参数。实现方式best_acc 0.0 patience 2 not_improved 0 for epoch in range(10): train_one_epoch(model, train_loader, optimizer, criterion) val_acc evaluate(model, val_loader) if val_acc best_acc: best_acc val_acc torch.save(model.state_dict(), best_model.pt) not_improved 0 else: not_improved 1 if not_improved patience: print(early stop at epoch, epoch) break为了跑清楚过程数据加载部分的代码大致是train_loader DataLoader(train_dataset, batch_size64, shuffleTrue) val_loader DataLoader(val_dataset, batch_size64, shuffleFalse) optimizer torch.optim.Adam(model.parameters(), lr1e-3) criterion nn.CrossEntropyLoss() for epoch in range(10): model.train() for batch_x, batch_y in train_loader: optimizer.zero_grad() logits model(batch_x) loss criterion(logits, batch_y) loss.backward() optimizer.step() val_acc evaluate(model, val_loader) print(fepoch: {epoch}, loss: {loss.item():.4f}, val_acc: {val_acc:.4f})这个机制看似简单但实际项目里如果不去实现经常会出现训练到第10轮模型效果反而不如第6轮的情况。因为随着训练进行模型开始记住训练集中的噪声模式验证准确率会出现先升后降的曲线这几乎是所有小模型训练都会遇到的规律。4.3 指标选择准确率够用吗情感分析中准确率是一个最直观但不完善的指标。如果数据里90%是正面评论哪怕是瞎猜全是正面也有90%的准确率。所以我们需要看精确率、召回率和F1。在这个项目的数据里正面和负面基本均衡我最后给业务的结论就用F1值最合适。F1同时惩罚漏判和误判避免只看单一指标带来的偏差。模型最终效果如下指标计算方式最终结果准确率预测正确的样本数除以总样本数89.7%精确率预测为正面且实际也为正面的比例91.2%召回率实际为正面且被正确预测出来的比例88.4%F1值精确率和召回率的调和平均数89.8%对于基于CNN的情感分析来说这个结果在合理范围内。短评越短预测越准长评涉及复杂转折误判率会明显上升。4.4 错误样本分析训练结束后我故意在验证集里挑了100条被错分的样本逐条看。排在前面的错误类型是反讽和转折句。比如“这部电影太‘好’看了好到我全程都在玩手机”表面词是“好”实际情感是负面。Text-CNN无法理解引号和双关目光聚焦在“好”“好看”这种正面词上自然判错。更麻烦的是转折句“演员阵容很强剧情也很流畅但总体来说还是乏善可陈。”模型会捕捉“强”“流畅”“强”而把“乏善可陈”这个关键负面词丢失。这时如果想提升可以尝试在预处理阶段做关键词加权或者引入更复杂的模型。但在业务可以接受的情况下我选择先接受这个精度毕竟反讽识别本身是个高级语义问题。5. 实战问题复盘与排查心得5.1 数据处理阶段的常见坑第一个坑分词后没有过滤数字和URL。影评里经常出现“2023年”“视频平台名”等内容数字和品牌名并不携带情感信号如果不加过滤它们会占据词表位置稀释有效特征。我的经验是在分词后增加一轮规则过滤但不是把所有数字都删掉保留“1星”“5星”这种带有评价含义的数字组合。第二个坑标签噪声。用户打分数据并非永远可靠比如有人手滑标了三星却写了长评“强烈推荐”。我抽检了约1%的样本发现大约有2%的标签和内容明显不符。最初我没有处理模型在训练时表现出奇怪的震荡后来做了一次简单规则清洗把评分和文本情感极性严重不一致的样本剔除掉模型稳定了很多。数据噪声是影响情感分析模型上限的关键因素之一花时间清洗远比盲目加模型参数更有效。第三个坑长度截断策略。我一开始用的是“保留前150词”结果长评的准确率明显偏低。后来统计后发现影评的情绪结论经常出现在后三分之一于是改成截头留尾。就是这一改整体准确率提升了约1.5个百分点。长度分位数的统计比拍脑袋定长度靠谱得多95%分位数是一个不错的起点。5.2 模型训练过程中的经典问题训练中最常见的问题是loss直接变成NaN。第一次出现时我一度怀疑是学习率太大后来定位到是文本预处理没有过滤超长连续无空格字符导致输入里出现了一个超长单词。这个单词在嵌入层查到了正常向量但经过卷积后梯度异常放大。解决办法是在优化器更新前加上梯度裁剪nn.utils.clip_grad_norm_(model.parameters(), max_norm5)这行代码让所有梯度范数限制在5以内防止梯度爆炸。加了之后NaN几乎不再出现。第二个常见问题是模型过拟合。Text-CNN的卷积层参数不多但全连接层仍然可能过拟合。Dropout加0.5配合早停基本能有效控制。如果还不行可以引入权重衰减Adam的weight_decay设置为0.0001即可。第三个问题是训练和验证效果不一致。如果训练集准确率99%验证集只有85%说明过拟合严重如果训练集只有80%那说明模型本身欠拟合。需要根据这两个数字的差异来决定调整方向。如果欠拟合优先增加卷积核数量或词向量维度如果过拟合优先增强Dropout、加入权重衰减或扩大训练数据。不要一上来就疯狂调learning rate。还有一个容易被忽略的问题类别不均衡。如果数据里正面评论占绝大多数模型很容易把几乎所有样本都预测成正面。我用了WeightedRandomSampler对负样本做了加权采样让每个batch里两个类别的比例接近1:1。实测这个方法让验证准确率又提高了1个百分点。5.3 部署与上线注意事项模型上线阶段最容易被忽略的是“训练与服务的一致性”。我曾在另一个项目里吃过亏训练时用的分词版本和线上环境版本不一致分词结果出现差异结果就翻天覆地。后来我把分词、清洗、词表、模型文件全部打包进同一个产物用统一的工具函数在前后端调用。注意线上推理阶段必须复跑和训练时完全一致的预处理流程。清洗规则、分词版本、词表映射、截断方向等任何一个环节不一致都会导致输入分布发生变化准确率会迅速下滑。另一个部署小技巧是模型推理不需要额外处理batch维度。Text-CNN模型定义里forward方法接收的x维度是batch, seq_len推理时输入一条评论只要x x.unsqueeze(0)包装成batch为1即可。很多新手在这里会卡住以为模型只能一次处理一批其实不是。还有一个容易被忽略的问题词表是训练时固定的。线上推理如果碰到训练时没见过的新词会全部变成UNK这种情况不可避免。应对办法是定期用增量数据重新训练Word2vec和分类模型或者至少定期重建词表。对于变化很快的互联网文本每个月更新一次模型是比较合理的节奏。6. 工程经验复盘与后续迭代方向6.1 沉淀下来的工程习惯文本预处理环节永远把清洗、分词、编码合并成同一个函数并且放在独立模块中训练和推理都调用它而不是写两份逻辑。我之前经历过两次因为“只改了一份代码”导致的线上事故这个教训值得记住。模型训练环节先跑一两个小epoch验证流程可以通再安排长时间训练。我习惯先把batch size调成64、epoch调成2跑通全流程后再正式训练。这样可以提前发现维度不匹配、数据读取出错等低级问题不用在正式训练时浪费时间。调参环节如果时间充裕可以试一下学习率衰减比如每隔两个epoch把学习率乘以0.5。这个策略通常相比固定学习率有零点几个百分点的提升在Text-CNN这种小模型上尤其明显。6.2 后续迭代方向如果准确率要再往上走可以考虑知识蒸馏或引入情感词典。用一个大模型做teacher让Text-CNN做student能够把大模型学到的语义知识转移到小模型里。我在其他项目里试过模型体积不会明显变大准确率还能再往上走2到3个百分点。如果业务要处理反讽那就要上更复杂的模型。Text-CNN的卷积核本质上是在做“局部词组匹配”不具备长距离语义建模能力。反讽这种需要全文理解的场景更适合用BERT类模型或者至少引入一个词级别的情感强度先验。我的总体判断是如果业务场景对响应时间有要求、团队又没有太多GPU资源PyTorch Text-CNN Word2vec这套组合依然是文本分类和情感分析最靠谱的起点。不要因为Transformer流行就盲目追求大模型先把基础方案的准确率、成本和可维护性全部测清楚再决定要不要向更重的模型迁移这是更理性的工程判断。
