简介实现 BERT 情感分类的完整工程面向具备一定 Python 基础、希望快速上手预训练模型与文本情感分析的学习者也可直接用于课程设计或毕业设计参考。项目基于正向、无情感、负向三类共 1 万余条语料训练迭代 3 次后在 3000 余条测试集上准确率 81.2%、召回率 76%、F1 值 78.5%同时提供 GUI 界面与 Jupyter 示例便于直观体验模型效果亦可了解模型调参与评估细节。压缩包共 41 个文件核心为 16 个 Python 脚本含模型构建、训练、预测、UI 逻辑配合 10 个文本语料文件、Markdown 说明及 docx 报告整体仅 2.64MB目录结构清晰适合直接阅读与二次开发。已有 364 人学习使用若有情感分析项目需求可参考数据预处理、BERT 微调及评估流程节省从零搭建的时间。1. 情感分析里BERT 凭什么值得你重做一遍同样一条“这电影节奏拖沓但结尾让我哭了”词典打分的模型把“哭”算正面把“拖沓”算负面最后一起抵消判成中性。基于 Python 实现 BERT 的情感分析模型解决的就是这个事让模型看整句话、根据上下文判定情绪极性而不是数关键词。近几年文本情感分析的落地任务——短文本舆情情感倾向分析、电商评论挖掘、客服质检——几乎都迁到预训练模型这条路上。下面从模型选型到踩坑把端到端怎么接、参数怎么设、失败时看什么都摊开讲新手照步骤能跑通熟手直接看第 5 章能少走弯路。2. 环境与权重把 bert-base-chinese 拉下来并先跑通一次真正动手做情感分析模型选型往往不是学术问题而是显存和交付时间的问题。绝大多数中文场景我直接用 BERT 的 base 版本而不是去追更大的模型理由很实际base 在单卡 8G 显存里能舒舒服服地训练几个小时后就有可用的结果再大的模型在同样的机器上只能把 batch 压到 2训练起来反而容易不稳。2.1 选 base 还是轻量版先看显存和数据量中文情感分析常用的预训练模型就那几类差异主要在参数量和预训练策略。我在做选型时会顺手列一张表把每个选项在 batch_size16、max_len128 下的显存感受写清楚。模型结构情况显存感受适合场景bert-base-chinese12 层 / 768 维 / 约 1 亿参数约 4-6GB8G 卡能跑有几千条标注数据追求准确率hfl/chinese-roberta-wwm-extbase 结构全词掩码预训练和 base 相当正式语料、长句比例高rbt3 这类轻量版3 层左右约 1-2GBCPU 也能忍数据量小、延迟敏感、只求基线如果你手里的标注数据只有几百条base 版本不一定比轻量版强多少因为模型容量大、数据太少容易过拟合。反过来数据到了几千条以上base 的优势就出来了。第一次跑项目我建议直接选 bert-base-chinese它是中文 environment 里路径最顺的模型下载即用社区资料也最多。选定模型后别急着训练先把“能不能正常加载”这件事确认掉。很多翻车事故都发生在环境没对齐而不是模型本身。2.2 Python 环境与依赖三个核心库怎么配情感分析用 Python 做环境上只要盯住三个库torch、transformers、tokenizers。常见做法是 Python 3.10 配上 PyTorch 2.x 和 transformers 4.x这套组合在 CPU 和 GPU 上都稳。先建一个虚拟环境把依赖装干净。python3 -m venv bert_sentiment source bert_sentiment/bin/activate pip install torch transformers装完后跑一条命令确认版本目标是把 torch 和 transformers 的版本关系固定下来避免 transformers 版本太新、torch 太旧导致的算子不兼容。python -c import torch, transformers; print(torch.__version__, transformers.__version__)我一般会把这两个版本号记在 requirements.txt 里因为一周之后再回来跑同一个项目依赖一变结果就可能完全复现不出来。这不是代码问题是环境问题也是 BERT 项目里最常见的隐形坑。2.3 权重下载与加载自检先跑 3 条文本看 logits环境就绪后第一次加载权重时先写一个最小的自检脚本。transformers 会自动从模型库拉取 bert-base-chinese 的参数所以第一次运行需要联网之后就会落在本地缓存里。from transformers import BertTokenizer, BertForSequenceClassification model_name bert-base-chinese tokenizer BertTokenizer.from_pretrained(model_name) model BertForSequenceClassification.from_pretrained(model_name, num_labels3) texts [这个电影太好哭了, 速度很慢我等得很不耐烦, 一般吧没什么感觉] for t in texts: inputs tokenizer(t, return_tensorspt) logits model(**inputs).logits print(t, logits.tolist())这里的 num_labels3 表示做三分类正面、中性、负面。因为分类头是随机初始化的所以第一次打印出来的 logits 一定是一堆接近 0 的小数这很正常。你要检查的是它的 shape 是不是 [1, 3]只要维度对说明模型结构和标签数设置没有问题后面训练时只更新分类头和少量参数。注意如果这里报错先看是网络下载问题还是版本问题。网络下载失败一般会明确提示连接错误版本问题则常常报 tokenizer 或模型权重文件缺失。3. 数据与分词把 CSV 文本改造成 BERT 能吃的输入BERT 不是直接吃字符串的它要的是 input_ids、attention_mask 和 labels 三样东西。这个阶段的目标很单纯把手里的一列文本和标签整理成 torch Dataset 能吐出来的样本。3.1 标签编码与 Dataset通用的打包函数先处理标签。原始数据里可能是“正面 / 中性 / 负面”这样的中文也可能是“好评 / 差评”必须统一编码成 0、1、2。这一步做得不规范后面所有训练结果都是空中楼阁。import torch from torch.utils.data import Dataset class SentimentDataset(Dataset): def __init__(self, texts, labels, tokenizer, max_len128): self.texts texts self.labels labels self.tokenizer tokenizer self.max_len max_len def __len__(self): return len(self.texts) def __getitem__(self, idx): text str(self.texts[idx]) label int(self.labels[idx]) # 编码、补零、截断一次性完成 encoding self.tokenizer( text, paddingmax_length, truncationTrue, max_lengthself.max_len, return_tensorspt, ) return { input_ids: encoding[input_ids].squeeze(0), attention_mask: encoding[attention_mask].squeeze(0), labels: torch.tensor(label, dtypetorch.long), }这里有几个参数值得说清楚。paddingmax_length 会把所有样本补到同样的长度这样 DataLoader 在凑 batch 时不会因为长度不一致而报错truncationTrue 表示超过最大长度的部分直接截掉squeeze(0) 是因为 tokenizer 返回的是 [1, seq_len] 的二维张量而 Dataset 单样本只需要一维。这套设计在数据量不大时是最稳的写法后面训练时不用再写额外的 collate 函数。3.2 截断策略max_length 到底设多少max_length 是情感分析里最容易被低估的超参数。BERT 的输入上限是 512 个 token但很少有评论类文本真的需要 512。商品评论和社媒文本的长度通常集中在 64 个 token 以内直接设 128 既覆盖了绝大多数内容又省显存。我见过很多人一上来就设 512结果 batch 根本装不进去然后反过来骂显存不够。真实情况是你把健康检查文本末端的博纳感扩充到 512训得又慢又容易 OOM效果却和 128 差别不大。对长文本比如投诉工单或长影评我一般会在清洗阶段做“首尾拼接”而不是简单从头部截断。def clip_long_text(text, max_len120): if len(text) max_len: return text # 首尾各保留一半中间的丢弃 half max_len // 2 return text[:half] text[-half:]这条策略的逻辑在于中文情感信号往往分布在开头和结尾开头常是结论结尾常是总结或感叹。把这个函数放在 Dataset 之前执行比让 tokenizer 直接截断要友好得多。短文本舆情情感倾向分析里数据基本集中在几十个字这条函数一般不会触发但作为兜底它能保证你不被某条超长样本拖垮。3.3 中文语料清洗空格、全角标点、链接与 emojiBERT 的中文 tokenizer 按字切分所以不需要分词器但这不代表原始文本可以直接喂进去。CSV 里常见的坑包括全角空格、连续换行、URL、 用户名、以及从 Excel 带出来的空值。我一般会写一个轻量的清洗函数只做必要处理不做过度清洗。import re def clean_text(s: str) - str: if not isinstance(s, str): return s s.strip() # 全角空格替换为半角方便后续切分 s s.replace(\u3000, ).replace(\xa0, ) # 多余的空白折叠成一个空格 s re.sub(r\s, , s) # 去掉链接和 用户名它们对情感判定的噪声大于信息 s re.sub(rhttps?://\S, , s) s re.sub(r\S, , s) return s.strip()cleaning 的原理很简单tokenizer 会把 URL 拆成一堆无意义的子词白白占用 max_length还会干扰 attention 的分配。表情符号我建议保留因为在中文评论里emoji 本身就是很强的情感信号比如“绝了”和“绝了”完全是两种情绪。如果你把 emoji 清掉等于亲手抹掉一部分标注信息。清洗完成后把处理后的 text 和编码后的 label 一起丢进 SentimentDataset数据准备工作就算结束。这里有个原则清洗规则一旦定了训练集和验证集必须共用同一套逻辑千万不要训练集清洗、验证集不清洗那样评估结果会虚高得离谱。4. 微调训练分类头、超参与最小训练脚本数据准备好了下一步就是把预训练权重接到分类任务上。BERT 本身不做分类真正干活的是它后面的那个分类头。理解这一点你就知道微调到底在干什么。4.1 BertForSequenceClassification 在做的事BERT 模型接收一段文本经过多层 transformer encoder 之后在每个 token 位置都输出一个 768 维的向量其中第 0 个位置对应 [CLS] 这个特殊 token 的向量。情感分类的传统做法是拿 [CLS] 向量接一个全连接层输出到类别数维度。BertForSequenceClassification 正是做了这件事它内部结构是BERT 编码器 一个线性分类层。使用上只需要传一个 num_labels模型会自动把分类头的输出维度改成你想要的类别数。预先训练的分类头在预训练阶段见过 [CLS] token 的表征但对具体的情感标签并不认识所以我们在自己的小数据集上微调就是在教这个最终层“什么样的特征对应什么情绪”。from transformers import BertForSequenceClassification # num_labels3 对应正面、中性、负面三分类 model BertForSequenceClassification.from_pretrained( bert-base-chinese, num_labels3, )这里有个细节值得留意transformers 在检测到 num_labels 和预训练分类头不一致时会自动重新随机初始化分类层所以不用担心旧权重来干扰。你真正要关心的是自己在数据清洗和标签编码阶段定义的类别顺序比如 0neg、1neu、2pos之后在推理时保持一致这是最容易对不上的地方。4.2 训练超参数组合照着这张表起步就行微调 BERT 和从零训练一个网络是两回事学习率、epoch、batch size 都在一个比较固定的区间里才有正常表现。超参数常见范围第一次可用的值备注learning_rate1e-5 到 5e-52e-5超过 5e-5 很容易训飞batch_size8 到 3216显存不足先减 batchnum_train_epochs2 到 53以验证 loss 反弹为准warmup_ratio0 到 0.10.1学习率先缓慢上升再下降weight_decay0.01 附近0.01AdamW 的常规配置BERT 的预训练权重已经收敛得不错微调时用太大的学习率会把已经学好的表征打乱。用 2e-5 起步、跑 3 个 epoch是大多数情感分析任务里一个相当稳的起点。如果你的数据量只有几百条可以把 epoch 提到 5同时调低 learning_rate 到 1e-5用小步长慢慢适应而不是大步快跑。4.3 最小训练脚本从加载数据到保存权重训练脚本我习惯写成一个能独立跑完的小文件不依赖 Notebook 状态方便随时从头复现。下面这个脚本把 DataLoader、优化器、训练循环和保存逻辑全部串起来。import torch from torch.utils.data import DataLoader train_loader DataLoader( SentimentDataset(train_texts, train_labels, tokenizer, max_len128), batch_size16, shuffleTrue, ) device cuda if torch.cuda.is_available() else cpu model.to(device) optimizer torch.optim.AdamW(model.parameters(), lr2e-5) total_steps len(train_loader) * 3 model.train() for epoch in range(3): total_loss 0.0 for step, batch in enumerate(train_loader): input_ids batch[input_ids].to(device) attention_mask batch[attention_mask].to(device) labels batch[labels].to(device) outputs model( input_idsinput_ids, attention_maskattention_mask, labelslabels, ) loss outputs.loss loss.backward() optimizer.step() optimizer.zero_grad() total_loss loss.item() if step % 20 0: print(fepoch {epoch} step {step} loss {loss.item():.4f}) print(fepoch {epoch} avg loss {total_loss / max(len(train_loader), 1):.4f}) # 保存本地权重和分词器下一轮直接加载 model.save_pretrained(./sentiment_bert_local) tokenizer.save_pretrained(./sentiment_bert_local)这个脚本里的 loss 是 BERT 内部自带的交叉熵它在 forward 时根据 labels 自动计算不需要额外写 loss 函数。训练循环里每 20 步打印一次 loss是为了快速判断是否出现 nan 或发散。保存时用 save_pretrained而不是直接torch.save(model.state_dict())这样会把模型结构和分词器一起存好后续加载只用一行from_pretrained。训练结束后avg loss 一般在 0.3 到 0.6 之间属于正常范围具体取决于数据难度和类别平衡程度。如果训练 loss 降到 0.1 以下但验证表现一塌糊涂那不是模型不行大概率是过拟合或者标签编码出了问题去看第 5 章。5. 避坑指南BERT 情感分析训练里 5 个常见问题这一章是实战里最容易让人浪费一两天的部分。每一条我都按“现象 → 原因 → 解决”的顺序写照着排查就行。5.1 标签不平衡模型只输出“正面”这一种结果现象是训练 loss 正常下降验证准确率看着还行但把模型拿出来一测几乎所有样本都被判成“正面”负面样本一条都召不回。原因在于情感数据天然不平衡电商好评比例高负面样本可能只占 10%。BERT 学到的是“全猜正面”也能把整体 loss 压下去的策略但它根本没有学会识别负面情绪。解决方法是给少数类样本加大采样权重最简单有效的是用 WeightedRandomSampler。import numpy as np from torch.utils.data import WeightedRandomSampler labels_arr np.array(train_labels) class_counts np.bincount(labels_arr) # 每个样本的采样权重样本所在类别越少权重越高 weights 1.0 / class_counts[labels_arr] sampler WeightedRandomSampler(weights, num_sampleslen(labels_arr), replacementTrue) train_loader DataLoader( SentimentDataset(train_texts, train_labels, tokenizer, max_len128), batch_size16, samplersampler, # 用 sampler 替代 shuffle )使用 WeightedRandomSampler 后每个 batch 里负样本出现的概率被拉高模型才算真正见过少数类。注意这时 DataLoader 不能再设置 shuffleTrue两者会冲突。5.2 batch 内长度不一致拼接张量直接报错现象是训练到第一个 step 就报错报错信息类似The size of tensor a (50) must match the size of tensor b (47)。新手最容易懵因为单条数据都能跑通一批数据就炸。原因很简单tokenizer 默认不补齐长度每个样本的实际 token 数不同凑成一个 batch 时张量形状对不上。很多人只写了tokenizer(text)没传padding和truncation。解决方法是回到 3.1 的 SentimentDataset确保 tokenizer 调用里固定写全这三个参数encoding self.tokenizer( text, paddingmax_length, truncationTrue, max_length128, )只要 padding 用 max_length 而不是 longest所有样本长度就完全一致DataLoader 不会再报形状错误。顺便提一句batch 大小减小时注意修改 padding 长度128 是比较通用的选择。5.3 显存溢出把 512 直接换成 128世界清净了现象是模型能加载但训练一进入循环就报CUDA out of memory有时甚至 8G 显存都不够用。原因是 max_length 设成了 512batch_size 又设了 32。BERT 的显存开销和序列长度近似成正比512 长度和 128 长度差四倍再加上反向传播时要存中间激活值显存瞬间被掏空。低显存运行模型不是靠玄学而是靠减少长度和 batch。解决的顺序是先把 max_length 降到 128如果还溢出把 batch_size 降到 8然后开启梯度累积用“小步累积”模拟大 batch。accum_steps 4 for step, batch in enumerate(train_loader): outputs model(**batch) # 梯度除以累积步数保持整体梯度量级稳定 loss outputs.loss / accum_steps loss.backward() if (step 1) % accum_steps 0: optimizer.step() optimizer.zero_grad()这样每 4 个小 batch 才更新一次参数显存占用和 batch16 时基本一致训练效果接近大 batch。对 8G 显存来说max_length128、batch_size8、accum_steps4 是一个我能直接照用的组合。5.4 num_labels 与真实类别对不上现象是训练过程一切正常但预测结果里永远出不来某个类别或者加载保存的模型推理时维度报错。原因是数据里存在脏标签比如 CSV 中混入字符串 “好评”、“0”、“2” 三种格式在训练时被int()转换后错位或者一开始定义了三分类后来把一个类删掉了但模型保存的还是旧的 num_labels。解决办法是在训练前把标签映射固定下来并且和模型一起保存。label_names sorted(set(train_labels)) # 例如 [neg, neu, pos] label2id {name: idx for idx, name in enumerate(label_names)} id2label {idx: name for idx, name in enumerate(label_names)} # model 的 num_labels 必须等于 len(label_names)保存权重时用 PyTorch 的torch.save把映射一并存下来加载模型时再取回来。这个映射一旦进了训练流程就不要改动顺序否则前面所有训练都白做。恢复模型时用from_pretrained(./sentiment_bert_local, num_labelslen(label2id))能避免维度不匹配的报错。5.5 推理时不关梯度速度越来越慢显存悄悄被吃光现象是在 GPU 上做批量预测刚开始几十条很快越跑越慢最后直接 OOM在 CPU 上则表现为进程内存持续上涨预测结果偶尔还不一样。原因是模型没有切换到 eval 模式也没用torch.no_grad()导致 dropout 还在随机丢弃节点而且每次 forward 都会构建计算图并保存梯度信息这些计算图没有被及时释放内存就这样被慢慢耗光。解决方法是把推理封装成一个固定的函数开头写死两行model.eval() with torch.no_grad(): logits model(**inputs).logitsmodel.eval() 用来关闭 dropout 和 BatchNorm 的训练行为torch.no_grad()告诉 PyTorch 不需要为推理保存中间梯度。做好这一步同一句文本的预测结果不会再有波动速度也会快一截。这是我见过的频率最高、修复成本最低的问题只要封装到位永远不会再犯。6. 上线前自检推理脚本、阈值修正和一个好习惯模型训练完别急着接 API先写一个干净的推理函数。这个函数决定了你后面所有调用方式接口、测试脚本、监控都要从它走。def predict_sentiment(text, model, tokenizer, devicecpu, max_len128, threshold0.6): # 打进系统的数据不可信先做一遍清洗 text clean_text(text) if not text: return neu, 0.0 model.eval() inputs tokenizer( text, paddingmax_length, truncationTrue, max_lengthmax_len, return_tensorspt, ) inputs {k: v.to(device) for k, v in inputs.items()} with torch.no_grad(): logits model(**inputs).logits probs torch.softmax(logits, dim-1).squeeze(0).cpu() neg_prob, neu_prob, pos_prob probs.tolist() # 低置信度样本不硬顶优先归入中性减少误伤 if max(probs.tolist()) threshold: return neu, max(probs.tolist()) pred torch.argmax(probs).item() id2label {0: neg, 1: neu, 2: pos} return id2label[pred], probs[pred].item()这个函数里有几个值得说的设计。第一对空文本和清洗后为空的文本做了兜底数据管道上游的出参不可控时这里能挡住一半的烂请求。第二引入 threshold 参数高置信度才给出明确判断低于阈值的归为中性这在实际业务里远比硬贴标签合理。第三映射表 id2label 要和训练时的 label2id 一一对应顺序错了一切都错。上线前我习惯再做一件事打印 20 条真实未标注数据的预测结果和概率而不是只打印验证集里挑出来的样例。验证集经过清洗和标注不能代表线上真实分布从线上随机捞一批进预测函数你才能看清模型在真实嘈杂文本面前的表现。这个习惯给我挡过很多次“训练指标漂亮、上线立刻翻车”的尴尬。更进一步如果你手里的数据包含大量 emoji 和表情图片文本模型天然接收不到这些信号这时可以考虑把图片特征和文本特征融合从文本情感分析往多模态情感分析方向走。但这一步的前提是先把文本模型的清洗、阈值和边界打磨利索否则加再多模态都是沙上建塔。我的习惯是每次拿到新数据集先不改任何参数直接用现成模型预测一轮把预测结果和真实标签逐条并排打印看完分布再决定要不要动阈值。这个办法帮我在很多个模型里避免了无效调参希望帮到你。本文还有配套的精品资源点击获取