简介基于Bert实现情感分析与文本分类的完整项目包面向计算机科学、人工智能、数据科学等专业的学生、教师和开发者适合作为毕业设计、课程设计、大作业或入门进阶的参考。包内共43个文件压缩包约42.14MB以py源码为主搭配json词表与配置、csv数据集、md说明文档、png可视化结果、sh训练脚本等。目录结构按data、model、train、GUI、processing、sentiment、topic划分覆盖数据存储、模型训练、图形界面展示、数据预处理、情感分析、主题建模等完整环节并提供可训练的模型与测试数据便于直接运行和二次开发。代码已经功能验证附带项目说明与可训练模型赠送基于BERT的中文情感分类任务演示并提供词云、情感分析及分类结果的可视化展示从数据准备到结果展示均配有对应模块能帮助读者快速理解Bert微调、文本分类和情感分析的落地方式。已有398人学习下载适合希望系统掌握Bert微调流程并扩展NLP完整应用链路的读者。1. 直接跑通的BERT文本分类基线这个zip到底能帮你解决什么早几年做情感分析还要为每个词向量调半天换成BERT微调之后同一套代码既能跑情感分析也能跑文本分类效果还稳。这份以python源码、数据集和项目说明一起打包的zip本质上就是一套最小的BERT微调工程读入带标签的文本把预训练模型在领域数据上再训几个epoch最后输出分类标签。它能解决的具体问题很常见电商评论的正负面判断、新闻标题的主题归类、客服工单的自动分单。适合谁新手可以照着源码把训练流程从数据到预测完整跑通有经验的工程师可以把它当脚手架直接替换数据集改几个参数就复用到自己的任务上。这篇笔记不打算逐行解读压缩包里的源码而是把这类项目背后你需要掌握的实现路径、参数设置和踩坑点讲清楚。2. BERT文本分类的工作原理与选型从[CLS]向量到分类头2.1 为什么是[CLS]向量BERT输出的分类信息藏在哪先想一个基本问题BERT输入一句话输出是一串向量它怎么和标签对应上常见做法是取句子最前面的[CLS]标记对应的最后一层隐藏向量当作整个句子的语义表示再接一个线性分类头。BERT在预训练阶段学会了把上下文信息压进每个位置的向量里[CLS]被设计成聚合全句信息的特殊位所以微调时我们只需要训练这个分类头让[CLS]向量从通用语义向标签语义对齐。from transformers import BertTokenizer, BertForSequenceClassification tokenizer BertTokenizer.from_pretrained(bert-base-chinese) model BertForSequenceClassification.from_pretrained( bert-base-chinese, num_labels3 ) inputs tokenizer( 这家餐厅上菜很快但环境一般, return_tensorspt, paddingTrue, truncationTrue, ) outputs model(**inputs) logits outputs.logits这段代码的逻辑很直白先用tokenizer把原始中文句子切分成subword token并补上[CLS]、[SEP]、padding和attention_mask然后模型做一次前向计算返回每个类别的logits也就是未归一化的打分。参数num_labels3对应情感分析里的负面、中性、正面三类。如果你做的是二分类改成num_labels2即可。这里我不建议手动把BERT所有位置的向量取平均当作句向量再自己接分类器因为[CLS]已经由预训练任务对齐过通常比你随手pooling要稳定当然如果你在特定任务上对比过不同pooling效果那另说。为什么微调能比传统词向量好传统的Word2Vec或GloVe是静态词向量一个词只有一个固定表示遇到苹果手机很好用里的苹果没问题但遇到苹果价格近期下跌就容易混淆。BERT是上下文相关的同一个token在不同句子里会有不同的向量结果所以情感分析这种强依赖上下文的任务天然受益。这也是这类zip项目里坚持用BERT而不是TextCNN、RNN的主要原因之一。这里还有一个容易忽略的细节padding后的位置在计算时会被attention_mask屏蔽所以不参与attention计算也不参与后续分类。你在微调时如果手动实现loss要记得把padding位置排除掉否则损失函数会把无意义的位置也算进去。直接用transformers模型返回的loss它会内部处理不容易出错但如果你自己在[CLS]后面接了一个新的分类头就千万别跳过这一步。2.2 情感分析和文本分类是一套代码还是两套代码很多人第一次看项目说明会纠结情感分析和文本分类是不是两个完全不同的模型在BERT框架下其实是一套代码差异只在标签数量和损失函数。情感分析最常见的是二分类正面、负面或三分类正面、中性、负面本质是单标签多类分类。文本分类如果是新闻主题、工单类型这种互斥标签也是单标签多类分类。两者共用BertForSequenceClassification只需要改num_labels和对应数据集。真正需要换模型的是多标签任务比如一篇文章同时属于科技和财经两个标签这时输出不再是softmax互斥分布而是每个标签独立做sigmoid。常见做法是把BertForSequenceClassification换成一个BERT编码器加一个多标签分类头或者直接沿用这个类但把损失函数改成binary cross entropy。我一般会先确认两个问题标签是否互斥样本是否可能同时属于多个标签这两个问题决定了你该用CrossEntropyLoss还是BCEWithLogitsLoss。如果你把多标签问题硬当单标签做模型输出的概率会互相压结果往往是分数最高的标签率命中但第二、第三个真实标签永远排不上。标签映射表是整个项目的地基。假设你的数据集里标签是负面、中性、正面我习惯写成这样一张表标签原文本分类头索引输出维度负面0dim 0中性1dim 1正面2dim 2这张表看起来简单但训练时和预测时如果有一处不一致整个结果就偏了。比如你在训练集里把负面映射成0推理时却用id2label{0: 正面}那预测出的负面评论会被解读成正面项目说明书越厚这种错误越难发现。我每次跑通一个任务都会把train和predict的映射表打印出来对比一次。2.3 加载预训练模型的两条路直接下载还是离线拷贝这个zip项目里大概率会有模型加载的说明。常见做法是直接from_pretrained(bert-base-chinese)它会自动从模型仓库下载权重到本地缓存。第一次运行会在本地缓存下几百MB的模型文件包括pytorch_model.bin、config.json、vocab.txt之后离线也能用。如果你的项目环境无法访问模型仓库或者你要在离线服务器上训练就需要先在能联网的机器上把权重下载好然后把bert-base-chinese整个目录拷到目标机器再把from_pretrained(bert-base-chinese)改成from_pretrained(/your/path/to/bert-base-chinese)。这里有个容易犯的错只拷贝pytorch_model.bin不会自动带上config.json和vocab.txt加载时会报错。你得把整个模型目录一起拷过去。一个常常被忽略的细节是tokenizer和model必须配套。如果你的项目用的是bert-base-chinese预训练模型却把tokenizer换成别的模型词表id对应错位输出的logits就是一团乱码。项目说明里一般会写清楚请使用同一路径下的vocab.txt实际跑的时候要留意。这属于那种一旦对不上损失函数曲线看起来很漂亮但验证集准确率就是上不去的玄学问题。另外一个决策点什么时候用BERT-base什么时候用更小的预训练模型如果你只有几万条数据、显卡显存也小用12层的BERT-base大概率也能跑但训练速度慢。这类zip项目一般默认用BERT-base因为它是通用基线效果有保障。如果你做的是特定领域比如医疗或法律文本换用领域预训练模型通常比通用BERT涨好几个点的F1。在第5章我们会再提。还有一个贯穿始终的习惯在训练前固定随机种子。BERT的实现里有些层有dropout即使相同的数据和参数每次训练结果也会有波动。固定种子之后至少能保证你调参时看到的变化主要来自参数而不是随机性。这个习惯对判断验证集F1是否真的提升非常重要。3. 把数据集改造成BERT能吃的格式从csv到torch Dataset的完整流程3.1 先看数据这份zip里的情感分析数据集常见格式通常这类项目的数据集是csv或tsv至少两列text和label。label可能是0 1 2这样的数字也可能是负面 中性 正面这样的字符串。你需要先把字符串标签映射成数字否则CrossEntropyLoss不接受字符串。我习惯先打印前5条再用value_counts看分布再决定要不要做类别平衡处理。import pandas as pd df pd.read_csv(data/sentiment.csv, encodingutf-8) print(df.head()) print(df[label].value_counts()) label2id {负面: 0, 中性: 1, 正面: 2} df[label_id] df[label].map(label2id)这段代码里有三个关键点。encoding指定utf-8能避免中文乱码但如果你的csv是GBK编码utf-8会报错这时改成encodinggbk或读取时用errorsignore。value_counts能直接看到类别数量如果某个类特别少后面训练时就要考虑加权。label2id这个映射字典是整个项目的核心索引它后面的id顺序决定了分类头的第几维输出对应哪个标签训练和推理必须用同一份映射否则预测结果和标签就错位了。如果你拿到的数据集是tsv分隔符就不是逗号而是制表符读的时候要写pd.read_csv(..., sep\t)。还有文件里可能带表头也可能不带如果不带表头最好在读取时指定headerNone并手动给列命名为[text,label]。这个细节不处理好后面代码里df[text]直接报KeyError。文本清洗也是必不可少的一步。情感分析数据里常有超链接、emoji、多余空格、重复标点。BERT自带的分词器对连续重复的感叹号可能产生大量token白白占用序列长度。我一般只做最轻量的清洗去首尾空白、把多余空格合并成一个、保留常见标点。过度清洗反而会让模型丢失语气信息比如这也太棒了吧里的三个感叹号对情感判断是有用的。3.2 写预处理函数tokenize、padding和truncation必须一次做对BERT的输入不能是原始字符串需要tokenizer转成input ids还要加上attention_mask。常见做法是用tokenizer直接批处理省去手动循环。from transformers import BertTokenizer import torch tokenizer BertTokenizer.from_pretrained(bert-base-chinese) def encode_texts(texts, labels, max_len128): encodings tokenizer( texts, max_lengthmax_len, paddingmax_length, truncationTrue, return_tensorspt, ) encodings[labels] torch.tensor(labels) return encodings逻辑很清晰texts是一个字符串列表labels是对应的数字列表。tokenizer会把每句话切成token超过max_len的部分截掉不足max_len的位置拿0补齐attention_mask里真正有token的位置标1padding位置标0。参数paddingmax_length表示所有样本都补齐到max_len这样后续DataLoader才能打包成同形状的tensor。truncationTrue表示长度超过max_len时截断注意默认截断是从右侧开始而BERT的[CLS]在句首[SEP]在句尾截断尾部通常丢的是句尾内容。对长文本情感分类来说如果你觉得句尾更重要可以考虑把tokenizer的truncation_sideleft让句子开头被截断保留句尾的结论信息。还有一个参数return_tensorspt表示返回PyTorch张量如果忘了写返回的是Python列表后面就不能直接当tensor用了。实际项目里经常能看到两行长得很像的代码一个带return_tensors一个不带踩坑点就在这里。文本长度设定上我建议先统计一下数据集的长度分布用99分位数作为max_len而不是拍脑袋填128。比如训练集里99%的句子都在80个token以内那max_len96就够如果有2%超过200你就得决定是截断还是滑窗。3.3 把编码结果封装成Dataset与DataLoadertokenizer返回的dict不能直接给DataLoader用因为DataLoader需要按索引取样本通常封装成一个torch Dataset。from torch.utils.data import Dataset, DataLoader class SentimentDataset(Dataset): def __init__(self, encodings): self.encodings encodings def __len__(self): return self.encodings[input_ids].size(0) def __getitem__(self, idx): return {k: v[idx] for k, v in self.encodings.items()} dataset SentimentDataset(encode_texts(train_texts, train_labels)) loader DataLoader(dataset, batch_size16, shuffleTrue, num_workers2)这里__getitem__返回的是字典DataLoader会自动把同batch里同key的tensor堆起来。如果你的数据量不大num_workers可以设成0避免多进程报错。shuffleTrue在训练时打乱数据验证时可以设成False。Batch size的选择直接影响显存和梯度更新频率BERT模型一般batch_size在8到32之间太大会OOM太小训练不稳定。数据切分也应该在这里做用train_test_split时总会带上stratify参数按标签比例分层抽样避免某一类全跑到验证集里。这个坑后面第5章专门讲。如果数据量很大一次性把全部数据tokenize并放进内存可能让内存爆掉。常见做法是先tokenize成numpy数组缓存到磁盘或者用懒加载Dataset只在__getitem__里返回原始文本DataLoader的collate_fn里再tokenize。不过对情感分析这种短文本场景绝大多数数据集都在几十万条以内直接内存加载反而简单。3.4 数据量偏小时怎么验证流程拿到zip后不要急着全量训练我会先用100条样本跑通一个epoch。原因很简单BERT模型结构复杂如果数据预处理或环境依赖有问题全量训练会浪费大量时间。先用很少的数据让loss下降几个点确认前向、反向、保存、加载都能跑通再上全量数据。小样本验证时可以把max_len设小一点、batch_size设大一点反正只是验证链路。如果这100条样本训练时loss完全不动先检查三个地方tokenizer是否返回了正确的input_idslabels是否在0到num_labels-1之间模型加载时num_labels是否和标签数一致。这三个地方有一处错后面都是白跑。4. 微调训练与参数调优跑通一个情感分析模型的关键配置4.1 训练循环优化器、warmup和学习率衰减怎么配BERT微调和普通分类任务不同因为预训练权重已经很好了你只是微调学习率不能像训练CNN那样从1e-3开始通常是2e-5到5e-5。源码里常见的写法是用AdamW和get_linear_schedule_with_warmup。from transformers import AdamW, get_linear_schedule_with_warmup optimizer AdamW(model.parameters(), lr2e-5, correct_biasFalse) total_steps len(train_loader) * num_epochs scheduler get_linear_schedule_with_warmup( optimizer, num_warmup_stepsint(0.1 * total_steps), num_training_stepstotal_steps, )AdamW是Adam的一个变种weight decay和解耦更清楚。correct_biasFalse是为了和BERT原版优化器行为一致。warmup的意思是在训练最初的一小段步数里把学习率从0慢慢升到目标值这样模型微调初期不会因为梯度太大把预训练权重冲乱。warmup步数一般取总步数的5%到10%总步数等于batch数乘以epoch数。如果你数据很少warmup可以设成几十步数据很多按比例来。然后在训练循环里每个step后要做scheduler.step()但不要忘了每步清零梯度。常见坑是忘了optimizer.zero_grad()导致梯度累加loss曲线乱跳。损失函数用CrossEntropyLoss对logits和labels计算。模型输出里本身带loss你也可以直接用outputs.loss省去手动算。微调时还要注意BERT里所有的BN层其实是用LayerNorm不需要手动设置train/eval切换之外的东西。一个完整的epoch循环大概是这样for batch in train_loader: 取出input_ids、attention_mask、labelsoutputs model(input_ids..., attention_mask..., labels...)loss outputs.lossloss.backward()optimizer.step()scheduler.step()optimizer.zero_grad()。顺序不要写错先zero_grad再forward再backward再step这四步缺一不可。4.2 三个必调参数learning_rate、batch_size、max_len互相制约这里列一个表相当于我自己的调试参考范围参数常见范围调高后的影响调低后的影响learning_rate2e-5 ~ 5e-5收敛快容易震荡不收敛收敛慢可能陷入局部最优batch_size8 ~ 32梯度更稳但显存压力大梯度噪声大需要更多步max_len128 ~ 512保留更多信息训练变慢速度快但容易丢尾部信息这三个参数不是独立的。显存是硬上限如果你的显卡只能塞下batch_size8且max_len128那么想加大max_len就必须减小batch_size。我一般先把max_len定成128跑通再看验证集上长文本是否拖后腿如果句子普遍超过100字再提高到256。一次只动一个参数否则你根本不知道是哪个变化让F1涨了。情感分析这种任务句子一般不会太长max_len128够用。新闻文本分类可能句子长max_len256或512更稳妥。但BERT的attention复杂度是序列长度的平方长度翻倍显存会涨很多这也是为什么不要盲目把max_len设满512。如果你数据里真有几千字的长文档常见做法是分段截断或滑动窗口把BERT当编码器取多段向量再做聚合而不是硬塞进去。Epoch数也同样凌驾于这三个参数之上。BERT微调很少需要跑10个epoch常见是3到5个epoch就够。数据量小的时候第二个epoch可能就已经过拟合数据量大的时候两个epoch也能看到收敛趋势。我习惯在训练时打印每个epoch的验证集F1一旦连续两个epoch不再提升就早停。4.3 评估指标准确率会骗人F1才是情感分析的关键训练完模型后很多人只看验证集准确率但这个项目做情感分析时很容易踩中类别不平衡。比如一个评论数据集里70%是正面你都预测正面也能有70%准确率但负面评论一条也找不出来。这时应该看精确率、召回率和F1尤其是宏平均F1。from sklearn.metrics import classification_report y_pred [] model.eval() with torch.no_grad(): for batch in valid_loader: outputs model(**batch) y_pred.extend(torch.argmax(outputs.logits, dim1).cpu().numpy()) print(classification_report(y_true, y_pred, target_names[负面, 中性, 正面]))这段代码展示了验证阶段的固定套路先model.eval()再用torch.no_grad()避免构建计算图然后取logits的argmax作为预测标签。classification_report会输出每一类的精确率、召回率、F1和样本量最后还有宏平均F1比只看准确率靠谱得多。我一般用验证集F1作为选checkpoint的依据而不是用准确率。如果标签不均衡还可以给每个类别设置权重。CrossEntropyLoss自带weight参数比如负面样本少权重就给大一点。但这种做法需要你在训练时提前算好class_weight而且要记住验证时仍然用真实分布否则评估出来的F1没有参考性。更简单的做法是采样时让负面样本出现频率更高但又不要完全丢掉多数类。4.4 早停与checkpoint记录验证集F1决定什么时候停训练不是epoch越多越好BERT微调通常3-5个epoch。我会在训练循环里维护一个best_f1变量每个epoch结束算一次验证集F1如果比之前的最好成绩高就把当前模型权重保存下来。这样做比直接保存最后一次epoch可靠得多因为最后一个epoch可能在验证集上已经过拟合了。实现上可以用一个简单逻辑if valid_f1 best_f1: best_f1 valid_f1; torch.save(...)。具体保存格式在第6章讲。这里还要注意如果你用了学习率衰减最后一个epoch的学习率已经衰减到很小模型variance可能更低但验证集F1未必最高。所以以验证集F1决定保存时机才是最稳妥的做法。5. BERT微调避坑排查容易翻车的5个坑从显存爆炸到数据泄漏这些坑不是理论问题而是我在多次给文本分类项目做迁移时踩过的血泪经验。如果你照着源码跑大概率会遇到下面五类问题中的至少一类我把现象、原因、解决分开写方便你在调试时直接定位。5.1 显存溢出batch和长度必须一起降现象训练第二个step报CUDA out of memory或者刚开始没事跑了几个batch突然OOM。原因max_len设太大、batch_size太大或者显卡被其他进程占着。BERT的显存占用会随序列长度二次增长所以seq_len从128加到512显存不只是翻倍。解决先把batch_size降到4max_len降到128跑通确认模型能训练后再逐步提高batch_size或max_len。如果业务要求长文本使用梯度累积每8个step再更新一次梯度等效于batch_size32但峰值显存只占一个小batch的量。注意梯度累积时要手动控制一般在第0个step清零梯度每累积到第8个step才执行optimizer.step()和scheduler.step()。5.2 模型不收敛loss卡住或震荡现象loss从头到尾没有明显下降或者验证集准确率一直50%上下。原因学习率太大或太小未加warmup标签映射错位tokenizer和模型不匹配还有可能是数据预处理时把labels也做了归一化。这类问题最容易让人怀疑人生。解决先打印train_loader里一个batch的input_ids和labels确认labels是0/1/2而不是浮点字符串。然后把learning_rate设成3e-5加上warmup跑3个epoch看loss。如果还不降换一个更小的模型或者固定BERT层只训练分类头先验证数据链路是否正常。固定BERT层可以用冻结参数的办法只让分类头参与学习这样收敛更容易但上限可能低一点。5.3 长文本截断丢关键信息现象短文本验证集F1不错但线上评论普遍很长模型预测明显不在状态。原因tokenizer默认从尾部截断如果情感结论写在句尾或整段都是递进铺垫尾部被截掉等于掐死了判断依据。解决对单条长文本做滑窗切窗取多个窗口分别预测再用投票或平均logits合并。简单做法是把truncation_side设为left保留句子末尾。对于超过512的长文可以把前512字和后512字切成两段一起处理然后把两段预测结果平均。这个方案会牺牲一点速度但对长文本的情感分析效果提升很明显。5.4 类别不平衡多数类掩盖了少数类现象准确率82%但负面类F1只有0.1几乎没预测出负面。原因数据集本身正负样本悬殊模型为了降低整体loss学成了永远预测多数类。情感分析里中性或正面往往占大头负面样本被挤压。解决在训练集上用WeightedRandomSampler对少数类过采样或者给CrossEntropyLoss设置class_weight。但要注意验证集不要过采样保持真实分布否则评估值没有参考意义。评估指标用宏平均F1而不是准确率。这个问题在文本分类里同样存在尤其是工单分类退单或投诉类样本通常特别少。5.5 数据切分不分层导致验证集失真现象训练集和验证集的F1差距很大或每次随机跑结果不稳定。原因直接df.sample(frac0.8)切分没有按标签分层。如果某一类样本少很可能全部跑到训练集里验证集完全见不到。解决用sklearn的train_test_split并设置stratifydf[label]保证训练和验证集中各类别比例一致。如果是多标签stratify不能用要改用MultiLabelStratifiedSplit之类的工具或自己写采样函数。这个坑和5.4经常同时出现排查时先看验证集标签分布再下结论。还有一个小习惯固定random_state让每次切分可复现否则你调参时看到的指标波动可能只是切分随机性造成的而不是模型变化。6. 把模型变成可复用的服务保存、加载与批量预测的小技巧6.1 保存验证集F1最高的checkpoint而不是最后一个epoch训练过程中每个epoch都会更新模型最后一个epoch未必最优。一个简单的做法是在训练循环里记录验证集F1只在指标提升时覆盖保存。代码逻辑可以写在epoch结束的地方判断当前valid_f1是否大于best_f1是就保存当前模型状态。这个小习惯能让你省下反复重训的时间。6.2 用save_pretrained同时保存模型和tokenizer不要只torch.save(model.state_dict())那样加载时还要手动重建模型结构并且容易踩num_labels不一致的坑。更可靠的做法是model.save_pretrained(./best_model) tokenizer.save_pretrained(./best_model)保存之后best_model目录里会有config.json、pytorch_model.bin、vocab.txt加载时直接用from_pretrained(./best_model)模型结构和tokenizer会自动从配置文件里恢复。我一般还会额外保存一份标签映射文件比如label2id.json这样推理服务启动时不用再硬编码标签顺序。6.3 带tokenizer一起加载的预测函数模板加载模型做单条预测时最省事的方式是把tokenizer和模型放在同一个目录model BertForSequenceClassification.from_pretrained(./best_model) tokenizer BertTokenizer.from_pretrained(./best_model) def predict(text): inputs tokenizer( text, return_tensorspt, paddingTrue, truncationTrue, max_length128, ) logits model(**inputs).logits pred torch.argmax(logits, dim1).item() return label2id[pred]注意这里from_pretrained会从目录里的config.json读取num_labels所以只要保存时结构一致加载就不会错。预测函数里的max_length最好和训练时保持一致否则推理时序列长度分布和训练不一致效果会受影响。批量预测时把所有文本放进一个列表一次性传给tokenizer比for循环逐条预测快很多因为GPU推理本身就适合批量。我最早做这类项目时总图省事只存最后一个epoch后来换数据重训发现验证集F1波动很大才知道自己错过了最佳checkpoint。现在我把只保存最佳F1当成默认习惯不再凭最后一次epoch判断好坏。希望帮到你。本文还有配套的精品资源点击获取