简介：一份评审分达99分的基于深度学习的电影评论情感分析项目资源包，适合计算机相关专业课程设计、期末大作业及入门实战，重点解决从数据爬取到模型训练演示中缺完整代码、缺数据集、缺文档的常见问题。资源围绕豆瓣短评设计，约5万条评论文本，包含爬虫脚本、数据清洗与预处理、深度学习模型训练与测试代码，并配有项目总结报告和答辩PPT，覆盖数据探索、建模调参、结果评估等完整流程。压缩包共14个文件，以ipynb交互式笔记本、py脚本、csv数据集和txt语料为主，另有pdf报告与pptx演示，整体21.28MB，目录划分清晰便于按环节学习。已有287人学习使用，代码完整可运行，是完成高分课程设计或快速入门NLP情感分析的可靠参考。
1. 电影评论情感分析：一个能写进简历的深度学习实战项目
电影评论情感分析大概是深度学习入门项目里被问得最多、也最容易被低估的一个：看起来就是「判断一段评论是好评还是差评」，但很多人第一次跑完，准确率卡在 85% 上下就再也上不去了——不是模型不够强，而是数据预处理、序列裁剪和评估方式这些细节在拖后腿。这个项目的完整闭环是：拿到公开的电影评论数据集，做清洗和切分，用 PyTorch 搭一个 LSTM 分类器完成训练和评估，最后把结果整理成一份能经得住追问的报告 PDF。整套流程跑通之后，你得到的不仅是一个能跑的模型，更是一套可以复用到其他文本分类任务的工程习惯。适合正在做课设、准备面试项目、或者想系统走一遍 NLP 流程的从业者。
2. 先选数据再选模型：评论数据的形态决定你接下来怎么走
2.1 数据形态与预处理管线
电影评论情感分析通常用的是某公开电影评论数据集，包含 5 万条左右的英文影评，正面和负面各占一半，每一条都已标注好标签。这个数据集的优点是规模适中、标签干净、文本长度差异极大——短的只有几个词，长的超过两千词。这种长度分布直接决定了后续所有预处理策略，也是很多人忽略的第一道坎。
拿到原始数据后，第一步不是训练，而是先做一次分布检查。我通常会把每条评论的长度画出来，看看中位数和长尾分布。常见做法是：
import numpy as np from collections import Counter # 以读取后的评论列表为例，每条评论已按空格切分为 tokens # review_tokens: list of list，每个内层 list 是一条评论的词序列 lengths = [len(tokens) for tokens in review_tokens] print("平均长度:", np.mean(lengths)) print("中位数:", np.median(lengths)) print("90分位:", np.percentile(lengths, 90)) print("最长:", np.max(lengths))这段代码的意义在于：平均长度可能是 200 出头，但 90 分位会到 500 左右，而最长的评论可能超过 2500 词。如果你把序列长度统一裁剪到 128，大概率会截断太多有效信息；如果统一到 512，训练时间和显存占用都会明显上升。所以「序列长度设多少」不是拍脑袋决定的，而是先看分布再决定。我自己的经验是：先取中位数的两倍左右作为初始值，跑一轮看损失曲线，再决定是否加长或缩短。
预处理管线还包含几个固定动作：把所有文本转成小写、把 URL 和数字替换成占位符、按空格或正则切分词。英文影评里常见的I don't可以切分成I don ' t也可以合并成don't，两种做法各有优缺点。我的习惯是合并常见缩略形式，保留don't、can't这种整体语义单元，减少模型需要学习的拼写变体。
2.2 训练集/验证集的划分与标签平衡
数据切分看起来是最没技术含量的环节，但实际操作里有三个容易被问倒的细节。第一个是随机种子：如果你不固定随机种子，每次运行得到的划分都不一样，模型结果无法复现，报告里写的准确率下一次就跑不出来了。第二个是评论来源去重：原始数据可能包含重复评论，直接随机切分会导致同一文本既出现在训练集又出现在验证集，评估结果虚高。第三个是标签平衡：虽然这个数据集正负各半，但如果你后面换了数据源，一定要检查类别比例。
from sklearn.model_selection import train_test_split # reviews 是文本列表，labels 是对应的 0/1 标签 # stratify=labels 保证切分后正负比例与原数据一致 train_texts, val_texts, train_labels, val_labels = train_test_split( reviews, labels, test_size=0.2, stratify=labels, random_state=42 ) print("训练集正样本比例:", np.mean(train_labels)) print("验证集正样本比例:", np.mean(val_labels))stratify参数在样本不均衡时尤其重要，它做的事情是让训练集和验证集的类别比例尽量接近原始分布。random_state=42是固定随机种子，保证每次切分的结果一致。如果原始数据里存在完全相同的重复评论，更好的做法是先做一次去重，或者按评论 ID 分组后再切分，避免同一评论的变体同时落在训练集和验证集里。
数据预处理做完，才是选模型的时候。这里给新手一个判断标准：如果机器上没有 GPU，或者想在 20 分钟内跑通全流程，优先选 LSTM/GRU 这类轻量序列模型；如果有 GPU 且时间充裕，可以直接上预训练 Transformer 做微调。这个项目标题里没有限定具体模型，那么用 PyTorch 搭一个 LSTM 分类器是最稳妥、最容易讲清楚、也最容易复现的方案。
3. 用 PyTorch 搭一个 LSTM 情感分类器：核心模型与可复现的完整训练流程
3.1 词表构建与 DataLoader
模型搭建的第一步是把文本变成数字。常见做法是：统计训练集里所有词的出现频率，保留出现次数最多的前 N 个词构成词表，其余词统一映射为<unk>。这里最关键的一点是词表只能基于训练集构建，不能看验证集——否则相当于把验证集信息泄漏进了模型。
import torch from torch.utils.data import Dataset, DataLoader from collections import Counter # 1. 统计词频并构建词表 word_counter = Counter() for tokens in train_texts: word_counter.update(tokens) # 保留频率最高的 20000 个词 vocab_size = 20000 most_common = word_counter.most_common(vocab_size - 2) vocab = {word: idx + 2 for idx, (word, _) in enumerate(most_common)} vocab["<pad>"] = 0 # 填充符号 vocab["<unk>"] = 1 # 未知词 # 2. 定义编码函数 def encode(tokens, vocab, max_len): ids = [vocab.get(t, vocab["<unk>"]) for t in tokens[:max_len]] # 长度不足 max_len 的部分用 0 填充 ids = ids + [0] * (max_len - len(ids)) return ids词表大小vocab_size设成 20000 是经验值：影评领域的常用词基本都能覆盖，超出部分用<unk>兜底，既控制了 embedding 层的参数量，又不会让模型因为过多稀有词而训练不稳。如果设成 50000，embedding 矩阵会大很多，但模型效果通常不会有明显提升。max_len的取值要回到第 2 章的长度分布来决定，我一般先试 256，再根据效果调。
有了词表之后，需要把编码逻辑包进 Dataset 类，让 DataLoader 自动完成批量化和填充：
class MovieReviewDataset(Dataset): def __init__(self, texts, labels, vocab, max_len): self.texts = texts self.labels = labels self.vocab = vocab self.max_len = max_len def __len__(self): return len(self.texts) def __getitem__(self, idx): tokens = self.texts[idx] ids = encode(tokens, self.vocab, self.max_len) return torch.tensor(ids, dtype=torch.long), torch.tensor(self.labels[idx], dtype=torch.float) train_dataset = MovieReviewDataset(train_texts, train_labels, vocab, max_len=256) train_loader = DataLoader(train_dataset, batch_size=64, shuffle=True)batch_size=64是在普通 CPU/入门级 GPU 上比较稳的取值。太大容易显存溢出，太小则训练速度慢且梯度更新不稳定。shuffle=True让每个 epoch 的样本顺序都不同，避免模型记住固定的批次排列。
3.2 模型结构：Embedding + LSTM + 全连接
模型结构是这个项目最核心的部分，也是报告里必须讲清楚的部分。我采用的结构是：Embedding 层把词 ID 映射为稠密向量，两层 LSTM 读取整个序列并输出最后一个时间步的隐藏状态，最后过一个全连接层得到二分类 logit。
import torch.nn as nn class LSTMClassifier(nn.Module): def __init__(self, vocab_size, embedding_dim, hidden_size, num_layers, num_classes=1): super().__init__() self.embedding = nn.Embedding(vocab_size, embedding_dim, padding_idx=0) self.lstm = nn.LSTM(embedding_dim, hidden_size, num_layers, batch_first=True, dropout=0.5) self.fc = nn.Linear(hidden_size, num_classes) def forward(self, x): # x: (batch, seq_len) embedded = self.embedding(x) # (batch, seq_len, embedding_dim) output, (h_n, c_n) = self.lstm(embedded) # output: (batch, seq_len, hidden) # 取最后一层最后一个时间步的隐藏状态 last_hidden = h_n[-1] # (batch, hidden_size) logit = self.fc(last_hidden).squeeze(1) # (batch,) return logit model = LSTMClassifier(vocab_size=20000, embedding_dim=300, hidden_size=128, num_layers=2)padding_idx=0告诉 Embedding 层：索引 0 对应的向量始终是零向量，且在反向传播时不更新。这是与<pad>填充符配套的关键设置，如果不加，填充位置会学出非零向量，干扰 LSTM 对真实序列的建模。dropout=0.5加在 LSTM 层之间，防止两层结构过拟合。h_n[-1]取的是最后一层 LSTM 的最后一个时间步输出，它聚合了整条评论的信息，也是全连接层的输入。
关于损失函数和优化器，常见做法是BCEWithLogitsLoss配合Adam。这里有一个新手容易翻车的点：如果你在模型里加了sigmoid，又在损失函数里用BCELoss，数值上虽然能跑通，但训练稳定性不如BCEWithLogitsLoss。后者把 sigmoid 和交叉熵合并计算，数值更稳定。所以我习惯在 forward 里直接输出 logit，不主动做 sigmoid。
3.3 训练循环与早停机制
训练循环的写法是固定的，但有几个细节决定了最终效果：梯度裁剪、早停、学习率调度。这三件事做完，模型训练的「玄学」成分会大幅降低。
import torch.optim as optim from torch.nn import BCEWithLogitsLoss device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model = model.to(device) criterion = BCEWithLogitsLoss() optimizer = optim.Adam(model.parameters(), lr=1e-3) best_val_loss = float("inf") patience = 3 bad_epochs = 0 for epoch in range(10): model.train() total_loss = 0.0 for batch_ids, batch_labels in train_loader: batch_ids = batch_ids.to(device) batch_labels = batch_labels.to(device) logits = model(batch_ids) loss = criterion(logits, batch_labels) optimizer.zero_grad() loss.backward() # 梯度裁剪，防止梯度爆炸 nn.utils.clip_grad_norm_(model.parameters(), max_norm=5.0) optimizer.step() total_loss += loss.item() # 验证 model.eval() val_loss = 0.0 with torch.no_grad(): for batch_ids, batch_labels in val_loader: batch_ids = batch_ids.to(device) batch_labels = batch_labels.to(device) logits = model(batch_ids) val_loss += criterion(logits, batch_labels).item() avg_train_loss = total_loss / len(train_loader) avg_val_loss = val_loss / len(val_loader) print(f"Epoch {epoch+1}: train_loss={avg_train_loss:.4f}, val_loss={avg_val_loss:.4f}") # 早停：验证损失连续 3 个 epoch 不下降则停止 if avg_val_loss < best_val_loss: best_val_loss = avg_val_loss bad_epochs = 0 torch.save(model.state_dict(), "best_model.pt") else: bad_epochs += 1 if bad_epochs >= patience: print("早停触发，训练结束") breakmax_norm=5.0的梯度裁剪是一个保守但有效的设置。LSTM 在长序列上容易出现梯度范数过大，导致损失出现尖峰，裁剪后训练曲线会平滑很多。早停的patience=3表示连续 3 个 epoch 验证损失不下降就停止，防止过拟合。torch.save只保存模型参数，不保存优化器状态，这样加载时更轻量，也方便在报告中说明「我们选择验证损失最低的模型作为最终模型」。
训练结束后，别忘了设置随机种子。PyTorch 的随机性来自多个来源：数据加载器的 shuffle、Dropout 层、Embedding 初始化。如果不固定种子，相同代码两次运行结果会有细微差异。一个常见做法是：
def set_seed(seed=42): torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) import random random.seed(seed) import numpy as np np.random.seed(seed) set_seed(42)这段代码要在模型实例化之前调用，否则模型参数的随机初始化已经是另一组值了。神经网络训练的「可复现性」看似小事，但放报告和答辩场景里，这是最容易被现场复现打脸的地方。
4. 模型评估与结果解读：别只盯着准确率，混淆矩阵才是关键
4.1 评估指标：准确率、精确率、召回率、F1
很多人在报告里只写一个「准确率 97%」，然后答辩时被问「这个指标是怎么算的」「为什么不用 F1」，就答不上来了。电影评论情感分析是二分类问题，正负样本均衡时准确率确实够用，但完整的评估应该包含四类指标：准确率（Accuracy）、精确率（Precision）、召回率（Recall）和 F1 分数。
from sklearn.metrics import accuracy_score, precision_score, recall_score, f1_score, confusion_matrix model.eval() all_preds = [] all_labels = [] with torch.no_grad(): for batch_ids, batch_labels in val_loader: batch_ids = batch_ids.to(device) logits = model(batch_ids) probs = torch.sigmoid(logits) preds = (probs >= 0.5).int().cpu().numpy() all_preds.extend(preds) all_labels.extend(batch_labels.numpy()) print("Accuracy:", accuracy_score(all_labels, all_preds)) print("Precision:", precision_score(all_labels, all_preds)) print("Recall:", recall_score(all_labels, all_preds)) print("F1:", f1_score(all_labels, all_preds)) print("Confusion Matrix:") print(confusion_matrix(all_labels, all_preds))这里的(probs >= 0.5)是一个默认阈值。如果模型在某个类别上偏保守或偏激进，可以调整这个 0.5 来改变 Precision 和 Recall 的平衡。在正负样本均衡的电影评论数据集上，0.5 通常够用，但如果后续换数据，这个阈值就需要重新调。
混淆矩阵的价值在于定位错误类型。我一般会看两个数：真正例（预测为正面且实际为正面）和假正例（预测为正面但实际为负面）。如果假正例偏高，说明模型把一些「带着讽刺的负面评论」当成了正面；如果假负例偏高，说明模型漏掉了一些正面信号不明显的评论。这个分析结论写进报告里，比单纯列一个准确率有说服力得多。
4.2 错误样本分析：模型在哪些句子上翻车了
评估不只是跑一段代码出几个数字，更重要的环节是人工查看模型预测错误的样本。这个步骤常常被跳过，但它恰恰是报告的亮点所在——它能告诉你模型的边界在哪里。
# 找出预测错误的验证集样本 misclassified = [] for i, (pred, label, text) in enumerate(zip(all_preds, all_labels, val_texts)): if pred != label: misclassified.append({ "text": text, "true_label": int(label), "pred_label": int(pred) }) # 打印前 5 条错误样本 for item in misclassified[:5]: print("原文:", item["text"][:200]) print("真实标签:", item["true_label"], "预测标签:", item["pred_label"]) print("---")常见错误模式有三类，几乎每次跑都会遇到，可以直接写进报告：
第一类是反讽和隐喻。评论写的是「我太喜欢这部电影的剧本了，它让我每一分钟都觉得自己在被当傻子耍」，句子包含明显的正面词汇但整体是负面态度。LSTM 只看词序和局部搭配，对这种需要全局推断的修辞基本无解。
第二类是与电影本身无关的评论。比如一条差评写的是「电影本身还行，但我看电影那天的爆米花是馊的」，情感主语根本不是电影，而是对影院环境的抱怨。这类样本即使人工标注也存在争议，模型预测错了不能完全算模型的错。
第三类是长文本中的局部矛盾。评论前半段骂得很凶，最后一句来一个「但整体还是值得一看」，模型容易只记住最后几个词，于是预测为正面。这种情况可以通过调整max_len或尝试双向 LSTM 来缓解，但不能根除。
错误样本分析做得好，报告 PDF 的「局限性分析」章节就有了真实素材，而不是堆砌套话。我一般会在报告里放一个 3 到 5 条错误样本的表格，每条样本标注真实标签、预测标签和错误类型，再配上几句话的解释，这比任何图表都能体现项目深度。
4.3 阈值调整与决策边界
0.5 这个阈值不是永远最优的。如果这个项目后续要落地到一个推荐系统里，把电影推荐给用户，那么漏推好剧（假负例）比误推烂剧（假正例）的代价更高，此时应该把阈值调低，让更多样本被预测为正面。反过来，如果是做一个「自动过滤低分评论」的工具，误删好评的代价更高，阈值就应该调高。
阈值调整不需要重新训练模型，只用在验证集上做一次扫描：
import numpy as np # all_probs 是之前保存的预测概率 thresholds = np.arange(0.3, 0.8, 0.05) best_f1 = 0.0 best_threshold = 0.5 for t in thresholds: preds = (all_probs >= t).astype(int) f1 = f1_score(all_labels, preds) if f1 > best_f1: best_f1 = f1 best_threshold = t print(f"最优阈值: {best_threshold:.2f}, 对应 F1: {best_f1:.4f}")这个扫描过程简单但很值钱，因为它能让模型在给定场景下的表现再提升一个档次，而且报告里写「我们针对实际应用场景调整了分类阈值」这句话，明显比写「准确率达到 XX%」更有说服力。要注意的是：阈值只能在验证集上选，选定后就不要再回去反复调，否则又变成另一种形式的过拟合。
5. 避坑指南：电影评论情感分析项目里最常踩的五个坑
5.1 序列长度裁剪导致验证集信息泄漏
现象：模型在训练集上准确率接近 99%，验证集上也到 90% 以上，但换到真实场景里的新评论，表现明显下降。排查后发现一个隐蔽问题：在填充和裁剪之前，模型已经接触过完整的未截断文本用于构建词表。
原因：词表的构建使用了全部数据，包括验证集。验证集里的稀有词在训练时已经有了对应的 embedding 向量，这相当于把验证集的信息泄漏进了训练过程。在电影评论这种领域词汇分布相对集中的数据上，影响可能不大，但严格来说这是流程错误。
解决：词表只从训练集构建，验证集和测试集的词表映射全部复用训练集的结果。验证集里出现但训练集没出现过的词，统一映射为<unk>。这个修改本身不会带来巨大的准确率提升，但它会让你的评估结果具备真实可信性。
5.2 标签不平衡被「均值准确率」掩盖
现象：数据正负样本各半时没问题，一旦换成自己爬取的真实评论数据，90% 都是好评，模型可能什么都不学就能达到 90% 准确率。这时候只看准确率完全看不出问题。
原因：准确率是所有样本的平均正确率。在类别不平衡的情况下，占多数的类别主导了这个数字，少数类别被完全忽略。
解决：第一，检查类别分布，np.bincount统计完直接打印到控制台；第二，报告中同时报告每个类别的 Precision/Recall/F1；第三，如果数据严重不平衡，考虑对少数类别做过采样，或在损失函数里给少数类别样本加权。不要一上来就换复杂模型，先解决数据层面的问题。
5.3 LSTM 训练损失震荡，准确率忽高忽低
现象：训练过程中损失曲线不是平滑下降，而是每隔几个 epoch 突然跳高，然后又回落。验证集准确率也不稳定。
原因：这是典型的梯度爆炸特征，尤其出现在序列较长、学习率偏大时。电影评论平均长度 200 词左右，LSTM 在长序列上累积梯度，一旦某个批次的词序列较长或包含极端词频的句子，梯度范数就会突然变大。
解决：clip_grad_norm_把梯度的全局范数限制在 5.0 以内，设置完通常能明显看到损失曲线变平滑。另一个备选方案是降低学习率到 3e-4，但我会先裁剪梯度，因为学习率调低会影响收敛速度，而裁剪只影响极端情况。
5.4 Dropout 在验证时忘了关闭
现象：训练过程正常，验证集准确率略低于训练集，这是正常的；但有些人会遇到验证集准确率离谱地低，甚至接近随机猜。
原因：模型定义里加了 Dropout 层，但测试时没有调用model.eval()，导致 Dropout 在验证阶段继续随机丢弃神经元。这是一个在 PyTorch 里非常常见的错误，因为model.eval()不是自动执行的。
解决：在验证和推理之前，显式调用model.eval()，之后用with torch.no_grad():包裹预测循环。eval()会关闭 Dropout 和 BatchNorm 的训练行为，no_grad()则关闭梯度计算，两者缺一不可。新手最容易漏掉的是前者，老手最容易漏掉的是后者。
5.5 报告 PDF 里模型参数表和实验配置对不上
现象：报告里写的模型参数和实际训练代码不一致，比如报告写 hidden_dim=256，代码里实际是 128；报告写训练了 10 个 epoch，代码日志里明显是第 4 个 epoch 就早停了。
原因：报告和数据是分开写的，代码改了一版之后报告没同步更新。这看着是人品问题，但本质是流程问题——代码和实验记录之间缺少一个自动对齐的机制。
解决：在训练脚本里把关键配置自动保存为一个 JSON 文件，训练结束后直接把这个文件的内容复制进报告的参数表：
import json config = { "vocab_size": vocab_size, "embedding_dim": 300, "hidden_size": 128, "num_layers": 2, "dropout": 0.5, "max_len": 256, "batch_size": 64, "learning_rate": 1e-3, "epochs": 10, "early_stop_patience": 3, "random_seed": 42 } with open("config.json", "w") as f: json.dump(config, f, indent=2)这个 config.json 不只是一份记录，它同时是复现实验的依据。别人拿到这份文件和代码，第一件事就是跑python train.py，然后拿输出和 config.json 对一遍，如果一致，这个项目的可信度就立住了。我见过太多报告写得漂亮但代码对不上的项目，这种硬伤在答辩和面试现场非常致命。
6. 进阶技巧：把模型封装成可交互的 Demo，并让报告变成一张「说服链」
6.1 用 Flask 封装一个最小可用的推理接口
模型训练完成后，光有 Jupyter Notebook 里的一堆输出还不够，把它封装成一个可交互的 Demo 会让整个项目的完成度上一个台阶。用 Flask 做是最轻量的方案，核心代码不超过 30 行。
from flask import Flask, request, jsonify import torch app = Flask(__name__) # 加载训练好的模型和词表，注意要和训练时的配置保持一致 model = LSTMClassifier(vocab_size=20000, embedding_dim=300, hidden_size=128, num_layers=2) model.load_state_dict(torch.load("best_model.pt", map_location="cpu")) model.eval() @app.route("/predict", methods=["POST"]) def predict(): data = request.get_json() text = data["text"] tokens = tokenize(text) # 复用训练时的切词函数 ids = encode(tokens, vocab, max_len=256) input_tensor = torch.tensor([ids], dtype=torch.long) with torch.no_grad(): logit = model(input_tensor) prob = torch.sigmoid(logit).item() sentiment = "positive" if prob >= 0.5 else "negative" return jsonify({"sentiment": sentiment, "prob": round(prob, 4)}) if __name__ == "__main__": app.run(port=8000)这个接口做的事情很简单：接收一段评论文本，走一遍和训练时完全相同的数据预处理管线，模型输出 logit 再经过 sigmoid 得到概率，最后按阈值映射为情感标签。重点在于，这个接口必须复用训练时的tokenize和encode函数，不能重新写一套，否则线上和训练时的输入分布不一致，模型表现会漂移。这个 api 的价值在于：演示的时候别人可以直接拿自己的评论来试，这种「可交互」的体验比 PPT 里的截图有说服力得多。
6.2 报告 PDF 的写作顺序：先讲问题，再讲方案，最后讲局限
报告 PDF 是这个项目的另一半交付物。很多人写报告是流水账：数据介绍、模型原理、代码展示、实验结果，每部分平均用力。我建议换一个思路：整个报告只为了回答一个问题——「我解决了一个什么问题，怎么解决的，解决到什么程度，还有什么没解决」。
具体到章节安排，我常用这样一条逻辑链：
第一段交代任务背景，也是整个报告的「锚点」：电影评论情感分析可以用于推荐系统、舆情监控、用户反馈分析。这一段要短，不要从人工智能发展史讲起，三句话以内说清楚为什么要做这件事。
第二段是数据说明。重点是让读者快速理解数据的规模和形态，以及你为它做了哪些预处理。放一张评论长度的直方图，再放一个预处理前后的示例对比表，比任何文字都直观。
第三段是模型结构和训练配置。这里贴模型结构图，再贴一张包含所有超参的表格。注意：这张表格里的每一项都必须能对应到代码里的实际参数，否则就是给自己埋雷。
第四段是实验结果和分析。除了准确率和 F1 表格之外，务必放混淆矩阵和错误样本示例。这几样东西呈现的信息量远大于一个孤零零的「准确率 97%」。
最后一段是局限性和可能的改进方向。常见写法是：LSTM 对长距离依赖建模能力有限，可以引入预训练语言模型；当前只做了二分类，可以尝试细粒度情感分级；阈值的选取可以结合业务场景进一步优化。这一段的价值在于展示你对模型边界有清晰认知，而不是只会跑通代码。
我自己的一个习惯是：报告写完后先放着，隔一天再从头到尾顺着逻辑读一遍。读的时候只问一个问题——如果我完全不了解这个项目，能不能只靠这份报告复现整个实验？答案如果是「能」，报告才算完成。这个习惯帮我避过很多次答辩现场被追问到哑火的状况。希望这整条从数据到模型再到报告的路径，能帮你把这个项目做成一份拿得出手的实战成果，少走一些我走过的弯路。
本文还有配套的精品资源，点击获取
