Text-CNN+Word2vec：基于PyTorch的情感分析实战与部署优化

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这种局部特征抽取能力，正合适。

我用一个表格来对比三种方案在这个任务上的实际体验：

对比很明确：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 />、 、'之类的内容，先用正则替换成空格。
• 统一文本格式。英文字母全部小写，中文繁体转简体，全角标点转半角。
• 表情符号处理。这个是一个点睛操作。影评中的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标记固定为0，UNK固定为1。这种做法的理由是控制嵌入矩阵大小，避免向量维度倒挂。

序列化到定长的时候，需要统计长度分布。统计显示95%的样本在150词以内，于是我把序列长度设为150。超过150的部分，按照“尾部优先”策略截断：保留结尾，把开头截掉。这么做是因为影评的最终态度经常落在文章的结尾部分，比如“可惜的是，整体还是一部平庸之作”，真正的判断词在后面。如果保留头部丢弃尾部，等于删掉了最有信息量的部分。

用代码来表达序列化过程：

from collections import Counter def build_vocab(tokenized_corpus, max_size=50000, min_freq=3): 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_len=150): 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 ids

2.3 Word2vec训练：参数选择与代码实现

词表构建完成后，我直接使用全量分词后的语料来训练Word2vec。训练方式选择Skip-gram，不选择CBOW。原因是，Skip-gram每个词作为中心词更新周围的上下文词，它对低频词的向量质量更好。对于影评这种领域性强的语料，低频词往往是领域特有词，价值反而高。

向量维度选100。维度大固然信息容量多，但训练时间和内存也会上升；维度小又表达不了足够语义差异。100维是一个性价比很高的选择，在很多公开评测里，100维和300维在短文本分类上的差距并不显著。

训练用的工具是gensim，核心参数如下：

from gensim.models import Word2Vec sentences = [ ["电影", "剧情", "很", "紧凑"], ["演员", "演技", "在线"], # ... 全部分词后的评论 ] model = Word2Vec( sentences, vector_size=100, window=5, min_count=3, workers=4, sg=1, # 1=skip-gram，0=CBOW epochs=10, seed=42 ) model.save("word2vec_100d.model")

这里重点补充window的含义。window=5表示取中心词前后共5个词作为上下文窗口。影评里的转折词和程度副词经常出现在距离中心词2到3个词的位置，所以窗口取5可以覆盖这些信息；如果window设得太小，比如1或者2，就只能捕获紧邻的词，语义建模能力偏弱。

训练完之后，做一次直观检查非常有必要。直接查看“好看”的相似词：

word_vectors = model.wv for similar_word, score in word_vectors.most_similar("好看", topn=10): print(similar_word, round(score, 4))

如果有出现“精彩”“风趣”“感人”这类正向词，说明词向量质量基本在线；如果出现一堆无关词，就要检查语料质量或者提高epoch、调整窗口大小。词向量不是训练完就结束的，它相当于整个模型的“地基”。

2.4 嵌入矩阵的生成与映射

训练好Word2vec之后，下一步是按词表顺序生成嵌入矩阵。词表里的每个词，去Word2vec模型里查对应的向量；查到了就放在对应行，查不到就随机初始化一个较小的向量。这里需要用固定随机种子，保证每次运行结果可复现。

矩阵生成代码：

import numpy as np def build_embedding_matrix(vocab, w2v_model, embed_dim=100): 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_idx=0，空白位置就不会对卷积结果产生贡献。

另外，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的大小。k=2时卷积核看见两个词的组合；k=3时看见三个词的组合。多组不同高度的卷积核，相当于用一组“词组匹配器”在文本里扫描。

经过卷积后，每个卷积核得到一个变长的特征图。最大池化层把每个特征图中的最大值取出来，作为该卷积核捕捉到的最重要特征。这样，无论输入的句子长短，池化后都能得到定长的特征向量，从而接入全连接层。

为什么用最大池化而不是平均池化？情感分析里，一条评论往往是通过某个词强烈表达情感，比如“剧情烂透了”，关键信号在于“烂透”。最大池化会把“烂透”对应的强激活保留下来，不会被周围几个中性词稀释掉。平均池化更适合所有位置贡献均匀的场景，情感分析显然不是这种场景。

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_filters=100, filter_sizes=(2, 3, 4), num_classes=2): super().__init__() self.embedding = nn.Embedding(vocab_size, embedding_dim, padding_idx=0) 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, dim=1) # (batch, num_filters*len) merged = self.dropout(merged) logits = self.fc(merged) return logits

这里按行拆解，顺带说明一些容易被忽视的细节：

• nn.Embedding(vocab_size, embedding_dim, padding_idx=0)：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, freeze=False)，几乎所有参数都会参与训练。这里说的“几乎所有”，是因为PAD位置的嵌入向量虽然参与计算，但梯度为零，不会更新。

实际经验是：整个训练过程分成两个阶段效果更好。

第一阶段，把嵌入层冻结，设置freeze=True，只训练卷积层和全连接层。这样做的好处是，模型先用已经训练好的语义空间去拟合分类任务，不会因为随机初始化的卷积层产生动荡梯度，反过来把词向量带偏。

第二阶段，训练两个epoch之后，解冻嵌入层，设置freeze=False，所有参数一起训练。这个时候模型已经基本稳定，微调词向量可以让每个词在分类任务方向上稍微挪动，通常能再涨1到2个点的准确率。这个“先冻结再解冻”的思路，在迁移学习中很常见，但很多入门教程没有提到。

embedding_matrix = torch.tensor(embedding_matrix, dtype=torch.float32) model.embedding = nn.Embedding.from_pretrained(embedding_matrix, freeze=False)

4. 训练配置、指标评估与调参过程

4.1 超参数设置的逻辑与参考配置

我把完整超参配置列出来：

• 序列长度：150
• 词向量维度：100
• 卷积核宽度：2、3、4
• 每种宽度卷积核数量：100
• Dropout：0.5
• Batch size：64
• 优化器：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_size=64, shuffle=True) val_loader = DataLoader(val_dataset, batch_size=64, shuffle=False) optimizer = torch.optim.Adam(model.parameters(), lr=1e-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(f"epoch: {epoch}, loss: {loss.item():.4f}, val_acc: {val_acc:.4f}")

这个机制看似简单，但实际项目里如果不去实现，经常会出现训练到第10轮模型效果反而不如第6轮的情况。因为随着训练进行，模型开始记住训练集中的噪声模式，验证准确率会出现先升后降的曲线，这几乎是所有小模型训练都会遇到的规律。

4.3 指标选择：准确率够用吗

情感分析中，准确率是一个最直观但不完善的指标。如果数据里90%是正面评论，哪怕是瞎猜全是正面也有90%的准确率。所以我们需要看精确率、召回率和F1。

在这个项目的数据里，正面和负面基本均衡，我最后给业务的结论就用F1值最合适。F1同时惩罚漏判和误判，避免只看单一指标带来的偏差。模型最终效果如下：

对于基于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_norm=5)

这行代码让所有梯度范数限制在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流行就盲目追求大模型，先把基础方案的准确率、成本和可维护性全部测清楚，再决定要不要向更重的模型迁移，这是更理性的工程判断。