简介基于LSTM的文本情感分析实战项目配套完整Python源代码与说明文档主要面向深度学习入门者及NLP爱好者帮助理解循环神经网络在文本分类中的应用。压缩包共4个文件含Python脚本.py、Markdown说明.md和结果示意图片.png整体仅83KB虽小但结构清晰便于快速部署。已有212人学习适合结合GPU环境运行情感分类任务。代码基于PyTorch实现LSTM模型包含数据预处理、模型训练与预测流程README中提供运行说明另附百度网盘数据集下载链接读者可完整复现实验并在此基础上扩展调参或迁移到其他文本分类场景。1. 用LSTM做文本情感分析为什么至今仍值得一练一提到文本情感分析很多人第一反应是“直接上BERT不就行了”。但当你想搭一条能快速迭代、能看透每个权重的基线模型LSTM仍是性价比最高的选择——它没有Transformer那种动辄几千万参数的黑匣子也没有预训练模型的下载和微调成本。这个Pytorch实战项目要做的事情很具体把一段文本输入LSTM输出它属于正面还是负面全程用GPU加速训练。适合刚学完PyTorch基础、想走一遍“数据处理→建模→训练→预测”完整闭环的人也适合给后续上注意力机制、上BERT做效果对照的基线版本。我实际做完这个项目最大的体会是LSTM的情感分析不难难的是把数据切分、长度对齐、GPU显存分配这些“边上”的活干干净。这篇文章从代码层面拆开讲参数怎么定、坑在哪、训练时看什么指标都按我踩过的路走一遍。2. 搭建LSTM情感分析模型从词表到输出的三层结构在写模型之前必须先搞清楚输入和输出长什么样。情感分析通常是一个二分类问题但也有三分类正面/中性/负面。本文按二分类讲代码改一行就能扩成多分类。模型的骨架分三层Embedding层把词索引映射成稠密向量LSTM层负责捕捉时序依赖最后的全连接层把最后一个时间步的隐状态压成类别得分。2.1 数据预处理把一段文本变成固定长度的张量PyTorch的LSTM接收的是形状为(seq_len, batch_size, embedding_size)的输入新手最容易在这里迷路。所以预处理的核心就两件事建立词表、把句子变成等长的索引序列。import torch from torch.utils.data import Dataset, DataLoader from collections import Counter import re def build_vocab(sentences, min_freq2): 统计词频构建词表。min_freq过滤掉只出现一次的词避免过拟合噪声。 counter Counter() for sent in sentences: # 简单按空格分词。中文可先做jieba分词英文直接split即可 tokens re.findall(r\b\w\b, sent.lower()) counter.update(tokens) vocab {pad: 0, unk: 1} for word, freq in counter.items(): if freq min_freq: vocab[word] len(vocab) return vocab class SentimentDataset(Dataset): def __init__(self, sentences, labels, vocab, max_len64): self.data [] for sent, label in zip(sentences, labels): tokens re.findall(r\b\w\b, sent.lower()) ids [vocab.get(t, vocab[unk]) for t in tokens] # 截断或padding到max_len if len(ids) max_len: ids ids[:max_len] else: ids ids [vocab[pad]] * (max_len - len(ids)) self.data.append((torch.tensor(ids, dtypetorch.long), label)) def __len__(self): return len(self.data) def __getitem__(self, idx): return self.data[idx]这里有三个参数直接影响训练效果。min_freq2只出现一次的词既学不到语义又会让词表膨胀通常设2或3。max_len64LSTM按时间步展开句子太长计算量大且梯度容易消失情感分析里64个词通常够用如果你发现很多样本被截断再调到128。pad用0是因为后续如果使用预训练词向量padding位置通常不参与更新。DataLoader那边要注意一个细节LSTM需要按batch打包同一个batch里的样本长度必须一致。上面代码已经在Dataset里统一pad到max_len了所以DataLoader里不需要再写collate_fn。如果你的数据长短差异大想用动态padding再自定义collate_fn做按batch内最长长度对齐能省显存但代码会复杂一截。2.2 LSTM模型定义embedding_size、hidden_size、num_layers怎么设模型本身在PyTorch里是标准三层。我见过不少新手把batch_firstTrue这个参数漏掉导致维度一直对不上。建议统一加这个参数让输入变成(batch, seq_len, embedding_size)更符合人类直觉。import torch.nn as nn class LSTMSentiment(nn.Module): def __init__(self, vocab_size, embedding_size128, hidden_size128, num_layers2, num_classes2, dropout0.3): super().__init__() self.embedding nn.Embedding(vocab_size, embedding_size, padding_idx0) self.lstm nn.LSTM(embedding_size, hidden_size, num_layersnum_layers, batch_firstTrue, dropoutdropout if num_layers 1 else 0) self.dropout nn.Dropout(dropout) self.fc nn.Linear(hidden_size, num_classes) def forward(self, x): # x: (batch, max_len) emb self.embedding(x) # (batch, max_len, embedding_size) lstm_out, (h_n, c_n) self.lstm(emb) # lstm_out: (batch, max_len, hidden_size) # 取最后一层的最后一个时间步的隐状态 last_hidden h_n[-1] # (batch, hidden_size) out self.dropout(last_hidden) return self.fc(out) # (batch, num_classes)embedding_size我一般128起步。太小语义表达力不够太大在小型数据集上容易过拟合而且拖慢训练。hidden_size128够用如果数据量大、任务复杂提到256。num_layers2两层LSTM能捕捉更高层的抽象特征但到了3层以上训练难度明显增加对情感分析这种短文本任务收益很小。dropout只在多层LSTM层间和最后的全连接前加注意PyTorch官方文档写明如果num_layers1LSTM内部的dropout参数会被忽略。这里有个细节h_n形状是(num_layers, batch, hidden_size)取h_n[-1]就是最后一层的隐状态这也是为什么这里不取lstm_out[:,-1,:]的原因——两者结果一样但前者语义更明确。2.3 训练循环交叉熵损失与Adam配置训练部分比模型定义更容易被忽视。如果数据集只有几千条训练轮数、学习率、梯度裁剪这三样直接决定最终准确率是70%还是85%。import torch.optim as optim from torch.nn.utils import clip_grad_norm_ def train_model(model, train_loader, val_loader, epochs10, lr1e-3, devicecuda): model.to(device) criterion nn.CrossEntropyLoss() optimizer optim.Adam(model.parameters(), lrlr) for epoch in range(epochs): model.train() total_loss 0 for batch_x, batch_y in train_loader: batch_x batch_x.to(device) batch_y batch_y.to(device) optimizer.zero_grad() logits model(batch_x) loss criterion(logits, batch_y) loss.backward() # 梯度裁剪防止LSTM长期依赖下的梯度爆炸 clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() total_loss loss.item() # 验证 model.eval() correct 0 total 0 with torch.no_grad(): for batch_x, batch_y in val_loader: batch_x batch_x.to(device) batch_y batch_y.to(device) logits model(batch_x) preds torch.argmax(logits, dim1) correct (preds batch_y).sum().item() total batch_y.size(0) acc correct / total print(fEpoch {epoch1}, Loss{total_loss/len(train_loader):.4f}, Val Acc{acc:.4f})clip_grad_norm_不是可选项。LSTM在序列长度超过50时梯度范数经常冲到几十甚至几百一次参数更新就把loss打飞也就是大家说的“炸了”。max_norm5.0是常见取值你可以从5开始调小到1会训练变慢调大到10则防不住爆炸。lr1e-3对Adam是安全起点但如果你发现loss下降很慢可以先看是不是数据或padding问题不要急着调lr。这里的损失函数用的是CrossEntropyLoss它内部已经包含了Softmax所以模型的最后一层不需要再手动接Softmax——推理时想要概率再torch.softmax。3. GPU加速训练CUDA环境检查与单卡/多卡切换训练慢不是GPU的锅多半是数据还在CPU上打转。很多人以为把模型to(device)就完事了结果每个batch又在CPU上生成再拷贝到GPU来回倒腾反而比纯CPU还慢。这一章讲清楚GPU加速的完整链路。3.1 先确认你的GPU能被PyTorch用起来很多环境装好了PyTorch但装成了CPU版本torch.cuda.is_available()返回False。这一步骤能省掉后面所有玄学问题。import torch print(PyTorch版本:, torch.__version__) print(CUDA可用:, torch.cuda.is_available()) if torch.cuda.is_available(): print(GPU名称:, torch.cuda.get_device_name(0)) print(显存:, torch.cuda.get_device_properties(0).total_memory / 1024**3, GB)如果is_available()是False不要急着改代码先检查三件事显卡驱动是否装了NVIDIA-smi能跑PyTorch是不是带CUDA的版本如果是在conda环境里nvidia-smi显示的CUDA版本和torch.version.cuda不一定一致前者是驱动支持的版本只要驱动版本大于PyTorch要求的就行。一个常见问题是装了pytorch-cpu包重装为pytorch即可。3.2 把模型和数据搬上GPU的三种写法确定GPU可用后设备切换要覆盖模型、每个batch的输入张量、标签张量。我一般会在项目开头定义一个全局device然后所有.to(device)都指向它避免后面改设备要到处找。device torch.device(cuda if torch.cuda.is_available() else cpu) # 写法1模型一路带过去 model LSTMSentiment(vocab_sizelen(vocab)).to(device) # 写法2数据进batch时转移在训练循环里用 for batch_x, batch_y in train_loader: batch_x batch_x.to(device) batch_y batch_y.to(device) # 写法3直接构造张量时指定device适合验证阶段 # dummy_input torch.randint(0, 100, (1, 64), devicedevice)第二种写法最常用但要注意batch_x.to(device)会返回一个新的张量原张量还在CPU上所以必须重新赋值。另外如果数据加载用了num_workers0子进程里的数据拷贝不会占用GPU显存但主进程的GPU张量不能直接传给DataLoader必须在训练循环里转移。3.3 多卡训练时一个容易忽略的坑当你有多张GPU时用DataParallel可以让模型在单机多卡上并行。但这里有个新手常踩的坑DataParallel包装后的模型model.module才是原来的模型结构保存权重时如果不注意加载时会维度对不上。if torch.cuda.device_count() 1: model nn.DataParallel(model) # 保存时如果用了DataParallel想保存原始模型权重 torch.save(model.module.state_dict(), model_state_dict.pth) # 否则直接torch.save(model.state_dict())权重key带module.前缀单卡加载会报错我建议工程项目里先不用多卡。情感分析这种任务单卡2080或3060在几万样本上跑十几轮也就十几分钟多卡并行带来的通信开销可能抵消加速收益。只有单个batch的显存放不下时才考虑DataParallel或DistributedDataParallel。真要用建议从始至终用DistributedDataParallel它比DataParallel更稳定也不会留下module.前缀这种坑。还有一个显存优化的常用技巧在验证阶段用with torch.no_grad():包裹并且不调用loss的计算这样显存占用会大幅下降。训练时如果CUDA out of memory优先把batch_size减半同时把max_len调小而不是换模型。4. 训练过程调参与效果验证别让loss曲线骗了你模型跑起来只是开始。情感分析项目翻车最多的地方不在模型结构而在训练策略——loss在下降不代表模型学会了语义也可能是在记住训练集里的噪声。这一章讲三个关键判断点。4.1 学习率与batch_size的搭配经验业界有个不成文的经验batch size翻倍学习率也翻倍。因为batch越大梯度越平滑可以用更大步长。但这是对固定数据集的粗略经验值不能套用到所有任务。# 常见搭配参考表 # batch_size: 32 - lr1e-3, 适合小数据集 # batch_size: 64 - lr2e-3, 适合中等规模 # batch_size: 128 - lr4e-3, 适合大数据集且需配合warmup # 实际做法先用小batch跑通再调batchlr跟着缩放 batch_size 32 lr 1e-3 # 如果你改batch_size64lr改为2e-3还有一个反直觉的点学习率太低时loss会在一个较高的平台值原地踏步看起来每一轮都在降但降得极慢。这时候正确做法是先把学习率调大一个数量级观察一两轮如果不炸再微调。学习率太高则表现为loss在几个epoch后突然飙升这种事我遇到不下十次解决方案不是降学习率而是加载之前保存的最优权重从那个点重新用小学习率训练。4.2 用验证集和混淆矩阵判断模型是真会还是背题训练集的loss趋近于0验证集准确率却不到60%这是典型的过拟合。LSTM的参数量远超小样本量时很容易发生。怎么判断看验证集loss是否在某个epoch后开始回升训练loss还在下降——这就是“曲线骗了你”的名场面。from sklearn.metrics import confusion_matrix, classification_report # 收集预测结果 preds_list [] labels_list [] model.eval() with torch.no_grad(): for batch_x, batch_y in val_loader: batch_x, batch_y batch_x.to(device), batch_y.to(device) logits model(batch_x) preds torch.argmax(logits, dim1).cpu().numpy() preds_list.extend(preds) labels_list.extend(batch_y.cpu().numpy()) print(confusion_matrix(labels_list, preds_list)) print(classification_report(labels_list, preds_list, target_names[negative, positive]))混淆矩阵能告诉你模型是在“均匀犯错”还是“只偏向某一类”。情感分析数据如果正负样本不均匀模型可能把所有样本都预测成多数的那个类此时准确率看着不错其实毫无泛化能力。解决方式是加class_weight到损失函数或者过采样少类样本。classification_report输出的F1-score比准确率更诚实尤其当样本不平衡时。4.3 常见loss不下降的原因排查loss不下降时第一先排除代码bug而不是调参。做过几次之后总结出这几条高频原因按优先级排查标签和损失函数不匹配如果用CrossEntropyLoss标签必须是0到num_classes-1的整型不能是[0,1]的one-hot编码更不能是浮点。padding位置的梯度污染虽然padding idx0的embedding不更新因为padding_idx的作用但LSTM仍然会把这个填充位当成真实输入导致隐状态被无意义的padding影响。解决办法是真正使用pack_padded_sequence但对于定长截断到64的小数据集影响不算大。学习率太大直接梯度爆炸loss变成NaN大概率是学习率问题或数据里出现异常值。先设lr1e-4跑通再逐步加大。验证集和训练集的数据预处理不一致例如训练时做了小写转换验证时没做导致OOV词全部变成unk性能断崖下跌。遇到loss不降先打印一个batch里的logits和labels确认形状和值域是否合理。logits全是一个数说明模型没有学进去常是embedding层初始化或LSTM维度设置的问题。5. LSTM情感分析避坑指南5条真实踩坑记录这一章的每一条都是实操中遇到过的不是理论推导。按“现象→原因→解决”写方便你遇到对应问题时直接对照。5.1 加载模型参数时提示size mismatch现象保存训练好的模型后换机器或换环境重新加载报size mismatch for embedding.weight: expected [19999, 128], got [20001, 128]。原因重新构建词表时单词过滤阈值min_freq变了或者数据预处理时没过滤干净导致词表数量变化。解决把词表保存下来和权重一起打包。不要每次运行脚本都重新build_vocab。正确做法是把vocab对象用json或pickle存下来加载模型前先恢复词表再初始化模型。5.2 batch_firstFalse导致的维度错乱现象RuntimeError: input must have 3 dimensions, got 2或者训练中loss正常但预测阶段结果完全不对。原因LSTM默认batch_firstFalse输入是(seq_len, batch, embedding_size)。如果数据在Dataset里是(batch, seq_len)网络会混淆时间步和batch维度。预测阶段batch_size1时尤其隐蔽因为(1, seq_len)和(seq_len, 1)在某些情况下不报错但语义完全错了。解决在LSTM定义里显式加batch_firstTrue并在模型forward里加注释说明输入形状。不要依赖默认值。5.3 训练时GPU显存一直在涨最后OOM现象每个epoch刚开始显存占用正常跑到后来越占越多直到CUDA out of memory。原因验证阶段忘了写torch.no_grad()或者训练循环里把每步的loss都追加到一个list而这个list保留了整个计算图。另一个常见原因是DataLoader的num_workers开太多每个进程复制了模型副本。解决验证阶段必须用no_gradloss累加时用loss.item()提取Python数值不要直接total_loss loss否则计算图会一直保留。num_workers一般设4~8即可超过物理核心数反而因进程切换增加开销。5.4 中文数据你没分词就直接按空格split现象中文文本按空格split后一句话变成一长串词表巨大而且几乎每个词只出现一次模型准确率只在55%左右。原因中文没有天然的空格分词。re.findall(r\b\w\b, text)在中文上会匹配一整段连续汉字相当于把整个句子当一个词。解决中文数据统一用jieba.cut做分词。预处理流程改为“分词→去停用词→索引化”。这一条影响极大不处理的话词表数量和OOV率都会失控。5.5 LSTM输出层用sigmoid还是softmax现象二分类训练完预测时用sigmoid输出概率阈值怎么调都不对准确率始终在50%附近徘徊。原因模型输出层是Linear(num_classes)没加激活函数。二分类如果用Sigmoid对应的损失函数是BCEWithLogitsLoss而CrossEntropyLoss期望的是每个类一个得分。两者混用时模型输出的logits含义完全不同。解决要么保持CrossEntropyLoss 输出层两个节点推理用softmax要么改成单节点输出 SigmoidBCEWithLogitsLoss。不要混搭。这个坑在二分类任务里特别隐蔽因为代码不报错但结果非常奇怪。6. 把模型用到实际文本单条预测与分析结果的细节训练完了最终的落脚点是给一条没见过的文本做预测。这时最容易踩的坑是单条数据没有batch维度模型直接forward会报错。另外推理时的预处理必须严格复刻训练时的流程——不是“差不多”是“完全相同”。def predict_single(text, model, vocab, device, max_len64): # 和训练时一样的分词、转索引、padding tokens re.findall(r\b\w\b, text.lower()) ids [vocab.get(t, vocab[unk]) for t in tokens] if len(ids) max_len: ids ids[:max_len] else: ids ids [vocab[pad]] * (max_len - len(ids)) tensor torch.tensor([ids], dtypetorch.long, devicedevice) # 注意[ids]变成了(1, max_len) model.eval() with torch.no_grad(): logits model(tensor) probs torch.softmax(logits, dim1) # (1, 2) positive_prob probs[0, 1].item() return positive_prob这段代码里有三个细节值得记一下第一torch.tensor([ids])比torch.tensor(ids)多一对方括号才符合模型要求的(batch, seq_len)形状第二推理时一定要切到model.eval()否则模型里的dropout和BatchNorm行为会变化导致预测不稳定第三positive_prob是一个0到1的浮点数你可以根据业务需求设阈值比如大于0.6才算正面而不是死认0.5。更进阶的用法是把中间隐状态抽出来。LSTM最后一个时间步的隐向量可以当作文本的稠密表示你可以把它喂给聚类或者相似度检索。这在情感分析之外是个惊喜相当于免费拿到一个“句向量”功能。做法是在forward里把last_hidden返回出来或者单独写一个特征提取方法。最后说一个我的习惯保存模型时连带着保存max_len、vocab、device这些配置打包成一个字典文件。以前我偷懒只保存state_dict后来换数据重新跑了一次词表全变了换个模型等于重训。现在我会这样保存torch.save({ model_state_dict: model.state_dict(), vocab: vocab, max_len: max_len, embedding_size: embedding_size, hidden_size: hidden_size, num_layers: num_layers, num_classes: num_classes, }, sentiment_lstm.pth)加载时用保存的配置重建模型恢复词表再loadstate_dict全程不需要手动记录任何超参数。这一套做完这个项目就能真正“收盘”了。希望这些经验帮你在自己数据集上少绕几个弯一次跑通。本文还有配套的精品资源点击获取