1. 为什么中文影评情感分析不能直接用词频统计
1.1 词袋模型和TF-IDF的局限
我最初做情感分析时，还是TF-IDF加朴素贝叶斯的时代。当时的思路很简单：把影评切词，统计每个词出现的次数，或者算TF-IDF权重，然后扔给分类器。这套做法对“这部电影太棒了”这种句子确实有效，“棒”这个词权重很高，模型一看到就偏向正向。但稍微复杂一点的表达就开始露馅。
举一个印象很深的例子，某次我用传统方法跑一条测试样本：“这部电影没有让我失望，但也谈不上惊喜。”切词之后模型看到“失望”这个词，权重很大，直接判成了负向。可这句话的真实情感是中性偏正向，观众在说这部片子及格了、不难看。传统方法在这个问题上几乎无解，因为词频模型只关心“出现了哪些词”，完全不关心词和词之间的组合关系。
还有个更典型的场景：中文里大量使用否定词，如“不是不好”这类双重否定，或者“还好”这种语气词，词频模型处理起来非常吃力。“还好”两个字拆开都很中性，但合在一起在影评语境里通常是偏负向的保留态度。这类语义层面的判断，需要模型理解上下文，而不仅仅是统计词表。
另一个致命问题是中文分词本身带来的错误传播。分词一旦错了，后面所有统计都跟着错。比如“这部电影节奏紧凑得让人喘不过气”这句，如果分词把“紧凑得”切成“紧凑”和“得”，关键词就丢了。相比之下，BERT这类预训练模型直接基于字符级或子词级的表示，不需要显式分词，天然规避了这个问题。
1.2 影评数据的特殊性与情感判断的复杂度
影评这种文本类型比一般商品评论更难做情感分析，这是由几个特点决定的。
第一，影评的语气往往口语化，甚至带反讽。影评人写“导演真有勇气”这种句子，实际意思是这部电影拍得离谱。这类句子字面是称赞，实则是讽刺，模型如果只看字面词意，一定会错判。
第二，影评的评分标准和情感不是严格线性关系。打四星的观众可能在结尾写“有些遗憾”，打两星的观众也可能说“演员很努力”。如果把5星当成纯正向、1星纯负向，忽略星级和文本情感之间的错位，模型就很难学准。
第三，中文影评里常见引述和转述。比如“朋友看完说这片子能拿奖，我笑了”。这句里的“这片子能拿奖”是转述，“我笑了”才是真实的讽刺态度。模型需要区分哪些是转述、哪些是作者本人的评价。
这些特殊性意味着，情感分类任务本质上是一个需要理解整句乃至整个段落语义的任务。纯粹的浅层模型做不到这件事，深度学习模型虽然能做，但如果你用随机初始化的LSTM去训练，仍然会因为训练数据量不够、中文数据标注成本高导致效果不理想。这时候，“先用海量语料预训练、再在小数据集上微调”的思路就变得非常必要了。
1.3 BERT给这类任务带来的质变
BERT解决的核心问题是：语言模型能不能在下游任务前，就已经具备理解中文语义的能力。它通过大规模预训练学到的是句子里每个字在整个上下文里的动态表示。同一个“好”字，在“这部电影真好”里和“好一个烂片”里的向量表示是完全不同的。这就是词向量革命的本质——不再是静态词表，而是动态上下文表示。
我实际跑过对比实验，同一份中文影评数据集，传统TF-IDF加SVM的准确率大概在81%左右，TextCNN大概86%，而BERT-base微调后直接跑到93%以上。这个差距不是一点点，而是质的提升。尤其在识别反讽、双重否定这类复杂句上，BERT能正确判对的比例远高于前两者。
当然，BETR也不是万能的，后面聊到实测时再细讲。但至少，在中文影评情感分析这个具体任务上，用BERT做底座，下面加一层分类头微调，是目前性价比最高的方案。macOS上做准备，Windows可能需要调整一些参数，我后面会提。
2. BERT为什么能理解中文语义
2.1 Attention机制与双向上下文编码
要理解BERT为什么效果好，得先明白它和传统语言模型的本质区别。
传统语言模型在预测下一个词时只能看前面的词，是单向的。比如看到“这部电影”预测下一个词，模型只能根据左边这几个字猜。RNN类模型即使有记忆，也是从左到右顺序扫描，后面的信息永远影响不到前面的判断。
BERT的核心创新是双向Transformer编码。它通过Masked Language Model的方式，在每个位置同时看到左右两侧的上下文。做法很简单：预训练时随机把部分词替换成[MASK]标记，让模型根据句子其余部分猜被遮住的是什么词。这下模型就必须同时利用前后文信息，学到的每个词向量都携带了整句话的语义信息。
以“这部[ MASK]拍得真好”为例，模型推断[MASK]时，左边是“这部”，右边是“拍得真好”，基本能确定这是个名词，而且大概率是“电影”“片子”之类的词。这种机制让模型在预训练阶段就大量学习中文句法、语义搭配关系。
2.2 Tokenizer：中文的切分方式与WordPiece策略
刚开始用BERT处理中文时，有个关键概念得摆清楚：BERT-Chinese用的不是字级别的直接切分，而是WordPiece，中文部分是基于字粒度的。
这意味着“复仇者联盟”会被切成“复”“仇”“者”“联”“盟”五个token，不会因为分词错误影响理解。模型通过注意力机制自己学会“复仇者”这三个字放在一起时有特殊含义。这非常关键，因为中文分词本身没有统一标准，同一句话不同分词器切出来的结果可能完全不同。BERT直接避开分词环节，用字粒度加注意力机制，模型自己决定哪些字组合起来有意义。
但要注意，中文tokenizer也有个实际问题：中文常用字大概3500个，而BERT的vocab有21128个token，是把字、常见词、常见组合都算进去了。但遇到生僻字怎么办？会走UNK（unknown）分支，这个后面细说。
2.3 预训练任务与微调的本质区别
很多新手第一次接触BERT时，容易混淆“预训练”和“微调”两个阶段的分工。我自己第一次用的时候也花了不少时间才理解这中间的差异。
预训练是做两件事：一是Masked Language Model，也就是猜被遮住的词；二是Next Sentence Prediction，判断两个句子是不是前后句。这两个任务都不需要人工标注数据，直接从大规模文本里自动生成训练样本，所以能用在千万级甚至十亿级的语料上。模型在这两个任务中学会的是中文的共同规律：语法结构、语义搭配、上下文互动。
微调阶段则是把预训练好的模型拿过来，接到具体任务上，用少量标注数据再训练。比如本篇要做的影评情感分析，就是在BERT最后接入一个分类层，用标注好的正向/负向影评数据，对整个模型做一次较低学习率的训练。
这样做的实质是：把模型在大规模语料里学到的中文通用语义能力，迁移到你的具体任务上。这就是为什么即使标注数据只有几千条，也照样能训练出不错的分类器的主要原因。
3. 环境与数据准备
3.1 硬件要求与开发环境搭建
跑BERT微调，对硬件有一定要求，但也没有到必须上多卡GPU的程度。我的实际经验是：如果用BERT-base（110M参数），纯CPU训练，一个epoch在万级样本上大约要两三个小时，可以跑但没有效率。有GPU的话，哪怕是入门级的6GB显存卡，一个epoch基本五六分钟。
如果你只有CPU，可以采取几个策略：用更小的模型如BERT-tiny或者蒸馏版本；降小批量大小；控制序列长度。后面优化部分我会详细展开。这里先给出我常用的环境配置方案。
我习惯用Anaconda管理Python环境，Python版本3.9，避免3.10以上版本在安装部分依赖时遇到兼容性问题。深度学习框架用PyTorch，BERT相关操作通过transformers库封装，都不用自己写底层代码。
conda create -n bert-sentiment python=3.9 conda activate bert-sentiment conda install pytorch torchvision torchaudio pytorch-cuda=11.8 -c pytorch -c nvidia pip install transformers datasets scikit-learn pandas如果没有GPU，安装时去掉pytorch-cuda相关参数，直接安装CPU版PyTorch即可。注意CUDA和PyTorch版本对应关系，装错了会报版本不匹配的错。实际踩过的坑是装了新版CUDA但PyTorch是旧版编译，运行时报libcublas版本问题，后来我养成了一个习惯：PyTorch的安装版本号和CUDA版本完全对齐，用官方命令，不自作聪明。
3.2 数据集的选取与标注质量判断
存放路径上建议单独建一个data目录，保持项目结构整洁。训练用的影评数据，我采用的是公开的中文影评数据集，负向数据多为1星和2星。实际标注质量参差不齐，用之前必须花时间清洗。
数据清洗这块，我有几个很实在的心得。第一步是去重。同一个用户的同一条评论可能出现多次，如果不查重，训练集和验证集之间出现重复样本，测试出来的准确率是虚高的，部署到真实场景后立刻打回原形。第二步是控制长度。影评长短悬殊，有的一句话完事，有的几百上千字。BERT输入长度上限是512个token，超长就截断。截断会让后文信息丢失，我通常会优先保留头和尾各一部分，中间截断做拼接。这套操作在我实测中效果比保留头截断尾部要好很多。
标注质量还有一个容易忽略的问题：一条评论可能包含了明显的对演员评价和对导演评价两部分，两者情感相反。比如“演员演得真好，可惜导演太烂”这类句子，人工标注时就会出现分歧。我处理这类数据时，处理策略是先过滤掉有明显立场冲突的样本，避免模型学到错误的模式。
3.3 数据预处理与训练集划分的细节
数据读入后，我通常先转换成统一的DataFrame格式，保留text和label两列。label统一转化为0和1的数值，0代表负向，1代表正向。这里有一个很多人忽视的问题：类别不均衡。如果负向评论占比70%，正向只有30%，模型容易学到“全部预测为负向”就能达到70%准确率的偷懒行为。
我的做法分两步：第一步先查看分布，如果偏差太大，用简单的欠采样或过采样把两类拉平；第二步再划分训练集、验证集和测试集。常见比例是8:1:1，但要确保划分时进行随机shuffle，并且标注stratify参数，让每一份里正向负向比例都保持一致。这个细节很多人不做，导致验证集和训练集的类别分布差异很大，训练曲线看起来很奇怪。
from sklearn.model_selection import train_test_split train_texts, val_texts, train_labels, val_labels = train_test_split( df['text'], df['label'], test_size=0.2, random_state=42, stratify=df['label'] )文本清洗方面，我建议做到以下程度：去除HTML实体、多余空格、重复标点。但注意，不要做太重的清洗，不要移除停用词，也不要强行把所有繁体转成简体之后就不管了。BERT的tokenizer本身就是在大规模语料上训练的，保留原始表达反而有利于模型理解。过度清洗会破坏语义信息，我刚开始做的时候把标点都删了，结果效果反而变差，因为标点本身携带语气信息。
3.4 Tokenizer的实际使用细节
先用AutoTokenizer从预训练模型名加载对应的tokenizer，这部分代码非常简单，但有几个小细节值得注意。
第一个是truncation=True到底用哪种截断方式。transformers库默认是只保留开头部分，截掉尾部。前文说过，影评的结论往往在结尾出现，比如“总之不推荐”中“不推荐”三个字丢了，整句情感可能直接反转。所以我一般用truncation='only_second'这类方式或者手动拼接头尾段落，这在情感分类任务里比单纯保头截尾更合理。
第二个是padding=True的设置。批量训练要求每条输入等长，短的要补到最长。这样内存利用率和训练速度能够取得较好的平衡。
from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained('bert-base-chinese') train_encodings = tokenizer( train_texts.tolist(), truncation=True, padding=True, max_length=256, return_tensors='pt' )max_length这里我设置了256而不是512。实测下来，大部分影评的有效语义在256个token内已经能表达清楚，设置512会让训练时间几乎翻倍，而准确率提升可能不到0.5%。这在工程上不划算。当然如果你的影评普遍很长，比如都是千字长评，那512就是必要的。
4. 模型搭建与训练
4.1 分类头的设计与加载预训练模型
BERT本体输出的是每个token的向量表示，要用于分类任务，需要在上面加一个分类层。最常用的做法是取CLS标记位置的向量，经过一个全连接层映射到类别数上。CLS是输入开头插入的特殊标记，BERT预训练时专门训练让它聚合整句信息，作为句级表示。
我用分类器结构如下：
from transformers import BertModel import torch.nn as nn class SequenceClassifier(nn.Module): def __init__(self, num_classes=2): super().__init__() self.bert = BertModel.from_pretrained('bert-base-chinese') self.dropout = nn.Dropout(0.3) self.classifier = nn.Linear(self.bert.config.hidden_size, num_classes) def forward(self, input_ids, attention_mask): outputs = self.bert(input_ids=input_ids, attention_mask=attention_mask) pooled = outputs.pooler_output pooled = self.dropout(pooled) logits = self.classifier(pooled) return logits有个细节值得说：我加了一个Dropout层，这在BERT微调中几乎是标配。BERT参数多，训练数据相对少，非常容易过拟合。Dropout相当于在训练时随机丢弃部分神经元的连接，迫使模型不依赖于某几个特定特征，学到的表示更鲁棒。
也可以用一些库自带的AutoModelForSequenceClassification接口，它在内部已经封装好了分类头，对快速上手更友好。我做初学者路线时通常用后者，做复杂实验时再用自定义结构。两种方式效果差别不大。
4.2 训练超参数设置的实践心得
BERT微调的超参数设定有一套基本范式，我第一次训练时用的参数在后来的多个项目里基本沿用，效果都还稳定。
学习率这块需要特别注意，预训练模型已经学得很好了，微调时用大的学习率会把学到的语义知识“冲掉”。我一般用2e-5，也就是0.00002。这个值来自BERT论文的推荐区间。有次我偷懒用了1e-4，训练损失确实下降得很快，但验证准确率卡在85%上不去，这就是过大的学习率在破坏预训练参数。
批量大小和训练轮数也有讲究。
from transformers import AdamW from transformers import get_linear_schedule_with_warmup optimizer = AdamW(model.parameters(), lr=2e-5, correct_bias=False) total_steps = len(train_dataloader) * epochs scheduler = get_linear_schedule_with_warmup( optimizer, num_warmup_steps=int(total_steps * 0.1), num_training_steps=total_steps )我一般用3个epoch，前10%的步数做warmup，让学习率从极小值逐步上升到设定值，然后线性衰减到0。warmup之所以有效，是因为模型刚开始从预训练状态切换到任务数据时，损失函数形态变化很大，直接上大会导致震荡，小步起步能让参数平稳过渡到一个适合任务的区域。
训练循环本身比较常规，关键在于记得切换模型模式。训练时model.train()，验证时model.eval()，两点一线的操作直接影响测试效果。
4.3 损失函数的选择与评价指标定义
分类任务的损失函数没有悬念，直接用交叉熵。torch里对应的是nn.CrossEntropyLoss()，内部已经把softmax和交叉熵合在一起计算了。这个函数会自动对模型输出logits计算概率分布和真实标签的差异，概率对的那个类趋近于1，损失趋近于0，其他的都会被惩罚。
评价指标我建议不止看准确率，还要看F1值，特别是类别不平衡的场景下。准确率的误导性上文提到过，如果93%的准确率但负向类别的召回率只有40%，那这个模型根本没法用。实际影评情感分析场景里，我希望正向和负向的精确率和召回率尽量均衡，因此观察指标时多用混淆矩阵，而不是只看一行准确率。
from sklearn.metrics import accuracy_score, f1_score, classification_report val_preds = [] val_labels_all = [] # 验证循环中收集预测结果 # ... print(classification_report(val_labels_all, val_preds, target_names=['negative', 'positive']))4.4 训练过程中的Loss曲线怎么读
训练过程中我会记录每一轮的训练损失和验证损失，做成简单的两列对比。这样能直观判断是否过拟合。
正常情况是训练损失持续下降，验证损失先下降后趋于平缓。如果在第二个epoch开始验证损失不降反升，而训练损失还在往下走，说明模型在把训练集的特性记住，而不是学通用的语义规律。这个节点上就应该停止训练，最优模型往往出现在验证损失最低的那个epoch，而不是最后一个epoch。
实际操作中我会在每个epoch结束后保存当前验证F1最高的模型权重。这是个很朴素的early stopping策略，实现简单但效果很好，我没有用太复杂的机制。
5. 实测结果与踩坑复盘
5.1 测试集上的表现详析
整个流程跑完后，我在测试集上得到的结果。测试集是模型训练过程中从未见过的一部分数据，最能反映模型真实泛化能力。
分类报告显示，测试集准确率93.2%，F1值0.93。正向类别的精确率94.1%，召回率92.5%；负向类别精确率92.3%，召回率94.0%。这个结果整体比较均衡，说明模型确实学到的不是单纯投机取巧的策略。
我又专门去测试了一些非常有挑战性的句子，逐一记录模型的行为：
- “这部电影的摄影确实一流，但剧本完全是敷衍”——预测负向，正确。
- “太难看了，我居然从头看到尾”——预测负向，正确。这句需要理解“居然”的反讽意味。
- “一部让人看完不知道该夸奖还是该骂的电影”——预测中性偏负，正确，因为模型只能输出两个类别，负向是更接近的答案。
- “如果这都不算烂片，那我不知道什么算”——预测负向，正确。经典反讽结构，BERT识别得很干净。
这些案例验证了BERT对上下文语义的判断能力，换成词频模型，前两个例子基本都会判反。
5.2 中文分词的暗坑：分词器不兼容或带特殊字符
这部分是我在实际操作中摔得最重的地方。我之前在某次项目中拿到了一批文本，发现里面有大量全角空格、零宽空格和奇怪的Unicode字符。tokenizer在处理零宽空格时不会报错，但token id会变得很怪，因为零宽字符本身在BERT的vocab中没有对应的语义单元，可能被映射到一个无关的字上。这种噪声会污染模型的注意力计算。
处理办法是在预处理阶段使用正则把不可见字符全部清除：
import re def clean_text(text): # 去除零宽字符 text = re.sub(r'[\u200b\u200c\u200d]', '', text) # 统一换行 text = text.replace('\r\n', '\n').replace('\r', '\n') # 去除全角空格 text = text.replace('\u3000', ' ') return text.strip()还有一个很隐蔽的坑：数据从Excel导出时，文本里时不时混入智能引号和弯引号。BERT tokenizer能处理，但个别中文数据集里引号使用不闭合，导致某些模型对引号内的讽刺语气判断不准。清洗时把中文引号统一成标准字符，能提升一小部分稳定性。
5.3 显存不足与处理长文本的策略
如果你的GPU显存只有4GB或6GB，跑BERT-base会遇到显存不足的问题。我最初用8GB显卡跑max_length=512、batch_size=32，直接OOM。这里推荐几个降显存策略，按优先级排序：
第一条是减小batch_size。batch_size=8在BERT-base上大概需要4-6GB显存，多数显卡都能跑。代价是训练速度变慢、梯度更新更频繁，但通过增大累积梯度步数可以模拟较大的batch效果，也能保证训练稳定。
第二条是使用梯度累积：
accumulation_steps = 4 optimizer.zero_grad() for step, batch in enumerate(train_dataloader): outputs = model(**batch) loss = outputs.loss / accumulation_steps loss.backward() if (step + 1) % accumulation_steps == 0: optimizer.step() scheduler.step() optimizer.zero_grad()第三条是降低max_length到128。对大多数短评类影评，这里损失的精度其实不大。长评则要小心，后文语义丢了可能影响判断。
如果机器条件实在有限，还可以换成bert-base-chinese的蒸馏版本。效果大约损失1-2个点准确率，但训练速度快两三倍，显存占用量也大幅降低。我在某些快速验证场景下会用它先跑一通，确认数据和代码没问题，再换回完整版训练。
5.4 遇到的训练不收敛问题及修复经过
训练过程中最诡异的经历是：验证损失一路下降，但验证准确率始终卡在50%附近，和随机猜测一样。第一次遇到这个问题时我排查了很久，最后发现是DataLoader里shuffle参数设错，验证集和训练集的标签错位了。具体是数据加载时索引没对齐，text和label来自两套DataFrame。这类低级错误特别容易出现在手工预处理时。后面我做了统一封装，所有样本进出都通过同一个Dataset类，不允许手动索引，从根源上杜绝了这个问题。
另一个不收敛的常见原因：模型输出层和损失函数之间的维度不对齐。比如类别数写了3但数据只有2类，模型softmax输出3个概率，标签是0和1，loss函数计算时不会立刻报错，但训练效果极差。这种问题要通过打印logits的shape和labels的shape排查，肉眼一对比马上能找到问题。
5.5 推理阶段的加速处理
模型训练完部署到实际场景时，推理速度也是一个要关注的点。BERT-base推理一句短文本大约需要几十毫秒，单条看起来很快，但如果是批量处理几十万条评论，时长就上来了。
我可以分享几个实测有效的加速方法：
第一种是开启torch.no_grad()，推理时不计算梯度，显存占用降低，速度提升明显。
第二种是批量推理代替逐条推理。把需要预测的文本攒一批，统一过tokenizer和模型，利用GPU并行计算能力，吞吐量能提升数倍。
第三种是模型量化或蒸馏。如果你需要部署到CPU服务上，比如用FastText剪枝替换，或用蒸馏后的小模型，推理速度可以提升几倍到十几倍。如果精度要求不是极端苛刻，这个性价比很高。
6. 效果提升与后续扩展方向
6.1 不同预训练模型的对比选择
BERT-base-chinese不是唯一选择，也不是所有场景下的最优选择。我在同样的影评数据上对比过几个模型，差异值得参考。
| 模型 | 参数量 | 准确率 | 备注 |
|---|---|---|---|
| BERT-base-chinese | 110M | 93.2% | 综合表现最稳 |
| RoBERTa-wwm-ext | 110M | 94.1% | 全词掩码策略，提升约1个点 |
| ALBERT-base | 12M | 90.8% | 参数少、训练快，精度略降 |
| DistilBERT-中文蒸馏版 | 66M | 91.5% | 速度好，精度略降 |
| BERT-large | 340M | 94.5% | 显存要求高，时长接近翻倍 |
如果你追求极致准确率而且硬件够用，RoBERTa-wwm-ext是性价比不错的选择。它在预训练时采用了全词掩码策略，即遮盖整个中文词组而不是单个字，这让模型学到了更好的中文词组语义表示。
硬件有条件的话可以试试BERT-large，但要注意显存和训练时间都会明显增加，1-2个点的收益不一定值得。
6.2 数据量不足时的增强方法
标注数据永远是做实践的瓶颈。影评情感分析也不例外，很多人拿到的数据只有两三千条。保证从几千条数据也能得到不错的效果。
我试过最常用的几种增强策略。第一种是回译：把中文影评翻译成英文再翻译回中文。原句“这部电影太难看了”翻译回“这部电影好烂”，虽然文字变了，但语义和情感保持一致。第二种是随机替换近义词。借助同义词词库，把“好看”替换为“精彩”，生成语义相似但字面不同的新样本。这类方法对提高模型的泛化性有一定帮助，但要注意不要造出不符合中文表达习惯的句子。
第三种是比较省事但有效的办法：用已经训练好的模型做伪标注，直接用高置信度的预测结果作为额外的训练样本。这种方法有风险，如果模型本来判断不准，错误会传播放大。我建议只在预训练模型质量高、置信度阈值设得高时使用。
6.3 引入评论星级信息的多任务扩展
影评数据往往不止文本，还有点赞数、星级评分、甚至用户的历史行为。这些额外信息能帮助模型学得更好。
一个简单的扩展思路是：把星级评分作为辅助输入，让模型同时预测星级和情感倾向。这就是多任务学习的基本形态。两个任务共享BERT底层的语义表示，底层学到的是通用的评论文本理解能力，上层分叉到两个任务各自输出。这种方式可以给低层提供更多监督信号，让模型更容易学到扎实的表示。
多任务实现并不复杂：
class MultiTaskClassifier(nn.Module): def __init__(self): super().__init__() self.bert = BertModel.from_pretrained('bert-base-chinese') self.sentiment_head = nn.Linear(768, 2) self.star_head = nn.Linear(768, 5) def forward(self, input_ids, attention_mask): outputs = self.bert(input_ids=input_ids, attention_mask=attention_mask) pooled = outputs.pooler_output sentiment_logits = self.sentiment_head(pooled) star_logits = self.star_head(pooled) return sentiment_logits, star_logits损失函数变成两个任务损失的和：loss = sentiment_loss + star_loss。我在实验中把star任务限定为训练数据里已有的样本，两个任务相互增强，情感分类准确率提升到了94.5%左右。
6.4 部署为API服务的工程化建议
模型训练好之后最终要落地。我做的流程是把训练好的模型保存上，然后用FastAPI搭一个简单的HTTP接口，封装成情感分析服务。
保存模型时有一个关键点不能漏：除了保存模型权重，还要保存tokenizer。别人在加载模型时要完全恢复tokenizer的配置。transformers库的save_pretrained会把模型和tokenizer一起保存到目录里，加载时用同一个目录路径加载即可。常见错误是只保存了模型权重，没保存tokenizer，部署时用默认tokenizer加载，token id对不上，预测结果全乱。
model.save_pretrained('./sentiment_model') tokenizer.save_pretrained('./sentiment_model')部署后的服务需要处理并发请求，最基本的是加一个线程池或异步队列，避免高并发时GPU被大量小请求占满。如果对延迟要求不高，可以只用一个进程一个batch，按请求顺序处理；如果延迟敏感，建议用KV Cache等方式优化。这块就深入了，之后单独写一篇部署经验再说。
整个项目做下来，我发现最有价值的其实不是93%还是94%的准确率差了多少，而是亲手体会到了预训练模型和传统方法在“理解中文”这件事上的本质区别。模型第一次识别出反讽句式时，我确实有点意外，因为它不是通过哪个关键词做的判断，而是通过整个句子的上下文动态组合出来的。这种能力，传统词统计方法很难企及。
给想复现这个项目的人最后一个建议：第一版先用默认参数跑通整个流程，不要一上来就调优。跑通意味着数据流、代码流、训练流全部没有暗坑之后，再去逐个调学习率、batch大小、max_length。如果你在一开始就同时调好几个超参数，出了问题根本不知道是哪个导致的。先复现，再调优，这是所有深度学习实践项目的通用原则。
