机器学习情感分析落地：从TF-IDF基线到预训练模型微调

1. 先想清楚：情感分析到底在解决什么问题

我接触过不少团队，一上来就说要做情感分析，问得细一点才发现，他们真正想解决的是"每天几万条用户反馈看不过来，想自动分出哪些是骂人的、哪些是表扬的、哪些是提需求的"。这三件事看起来都是"分个类"，实际处理方式差别很大：骂人的要优先响应，表扬的要做案例沉淀，提需求的要转给产品。所以在我这里，情感分析从来不是一个孤立的模型任务，它是"非结构化文本到可执行动作"的第一道筛子。

这篇文章讲的是使用机器学习进行情感分析的完整落地路径，从任务定义、数据准备、传统模型基线、预训练模型微调，一直讲到上线后的问题排查。它适合两类人：一类是刚入门、想找一个完整项目练手的同学，另一类是已经会调库、但模型在真实数据上总是"训练集 0.95、线上 0.6"的从业者。我会把参数为什么这么设、坑在哪、怎么排查写清楚，代码可以直接跑。

先说结论，省得你走弯路：绝大多数情感分析需求，用 TF-IDF 加线性模型就能做到 85% 左右的准确率，先把这条基线跑通、把数据质量摸清楚，再决定要不要上预训练模型。我见过太多人跳过基线直接微调大模型，最后发现瓶颈根本不在模型，而在标注数据里有一半标签是拍脑袋标的。

1.1 从业务问题倒推任务定义

动手写代码之前，有三件事必须先定死，否则后面全是返工。

第一件是粒度。文档级情感分析是把整条评论判成正/负，句子级是逐句判断，方面级（Aspect-Based）则是针对"物流""客服""价格"等具体维度分别判断。方面级最有业务价值，但标注成本是文档级的五到十倍。我的建议是：如果业务方只能给出"好评/差评"这种粗标签，就先做文档级，别硬上方面级。

第二件是标签体系。二分类（正/负）最省事，但真实数据里总有一大批"还行""一般般""没什么感觉"的中性表达，硬塞进二分类会污染边界。三分类（正/负/中）更贴近实际，代价是中性类往往最难分，F1 通常比另外两类低 10 个点以上。还有一种做法是把它当回归问题，输出 1 到 5 的分数，再按阈值切档，好处是保留了强度信息，坏处是标注一致性很难保证。

第三件是评价标准。这一点最容易被忽略。如果正负样本比例是 9:1，一个全部预测为正的"笨模型"准确率就有 90%，但它对业务毫无价值。所以情感分析我基本不看 accuracy，只看macro-F1和少数类的 recall。道理很简单：漏掉一条差评的代价，远大于误判一条好评。

提示：跟业务方确认指标时，别问"你想要多准"，要问"误判一条要花多少成本"。差评漏检可能导致舆情发酵，好评误判只是少一条案例，两者的容忍度完全不同。

1.2 三条技术路线的取舍逻辑

市面上做情感分析大致三条路，我把它们的适用边界列清楚，你对号入座就行。

词典规则那条路看着土，但它在冷启动阶段非常好用。我一般会先花半天搭一个"情感词典 + 否定词翻转 + 程度副词加权"的打分器，用它去给历史数据打伪标签，人工只做抽检和纠错，标注效率能提升三到五倍。这就是所谓的弱监督启动。

传统机器学习和预训练模型之间怎么选，我的经验是看两个数：标注数据量和领域差异度。数据量低于 5000 条，微调大模型的收益很有限，甚至不如调好参的线性模型稳；如果语料是高度垂直的领域黑话（比如某个细分行业的内部评价），通用预训练模型的优势会被削弱，这时候传统特征工程反而更可控。真正让预训练模型拉开差距的，是数据量过万且表达多样的情况。

2. 数据准备：八成工作量都在这里

我做过统计，一个情感分析项目里，纯写模型代码的时间大概占 15%，剩下 85% 全在数据上：找数据、清洗、标注、校验、分析分布。这部分最枯燥，但也最决定天花板。模型再花哨，也救不了一堆标错的样本。

2.1 语料从哪来，标注怎么组织

数据来源无非三条：自有业务数据、公开数据集、人工构造。自有数据最贴合业务分布，但往往没有标签；公开数据集可以拿来预热模型、验证流程，缺点是领域不匹配，直接拿来上线的效果通常打七折。我的常规做法是：用公开数据跑通全流程、验证代码没错，再用自有数据做真正的训练和评估。

标注环节有几个细节值得抠。第一，先写标注规范再标。"这条评论算正面还是负面"这种问题，不同人的判断边界差别巨大。规范里要明确写清楚：只吐槽快递但商品没问题的算不算负？带脏话但是开玩笑的算不算负？只发一个表情包的怎么处理？把这些边界案例写成条目，标注前集体过一遍。

第二，多人标注 + 一致性检验。我一般让两个人独立标 500 条，算一下 Cohen's Kappa。低于 0.6 说明规范有问题，得回去改；0.6 到 0.8 属于可接受；0.8 以上算质量不错。这个数字比任何模型指标都重要，因为它是标签噪声的下界。

第三，分层抽样标注。别按时间顺序从头标到尾，那样容易集中在某个时段的话题上。按类别、按渠道、按时间分层抽，保证覆盖度。我踩过的坑是：早期图省事只标了近三个月的数据，结果模型上线后对老用户的表达习惯完全无感，因为语言风格是会漂移的。

import pandas as pd from sklearn.model_selection import train_test_split df = pd.read_csv("raw_comments.csv") # 字段: text, label(0/1/2) # 分层抽样，保证各集合类别比例一致 train_df, temp_df = train_test_split( df, test_size=0.3, random_state=42, stratify=df["label"] ) val_df, test_df = train_test_split( temp_df, test_size=0.5, random_state=42, stratify=temp_df["label"] ) print(train_df["label"].value_counts(normalize=True)) print(val_df["label"].value_counts(normalize=True)) print(test_df["label"].value_counts(normalize=True))

这段代码里stratify是关键参数，不传它的话，小类别可能在验证集里一条都没有，评估结果就完全失真了。我见过有人随机切分之后 test 集里中性样本只有 3 条，然后拿着 0.33 的中性 F1 到处找模型问题，其实只是样本太少。

2.2 中文分词的坑与处理策略

中文不像英文有天然空格，分词质量直接影响特征质量。常用的就是 jieba、pkuseg 这类工具，默认词典对通用文本够用，但遇到领域黑话就废了。我的处理顺序是：先加自定义词典，再做停用词过滤，最后处理否定词。

自定义词典这件事收益极高、成本极低。把业务里的高频专有名词、产品名、网络新词导进去，分词准确率立刻上一个台阶。比如"真香""绝绝子"这类词，不加词典会被切碎，加进去就成了一个强情感信号。

import jieba # 自定义词典：每行 "词 词频 词性"，词频给大一点保证不被切开 jieba.load_userdict("domain_dict.txt") def tokenize(text): words = jieba.lcut(text) # 过滤纯标点、空白、单字（单字信息量低且噪声大） return [w for w in words if len(w) > 1 and not w.isspace()] print(tokenize("这个功能真的好用到爆，但是客服响应太慢了")) # ['这个', '功能', '真的', '好用', '到', '爆', '但是', '客服', '响应', '太慢']

注意输出里"太慢"这个词，其实是被切成了"太慢"，这已经算不错了。但如果切成了"太"和"慢"，情感强度信息就丢了。所以程度副词和情感词的组合，最好在词典层面处理掉。

停用词表也别直接用网上那份通用表。情感分析有个特殊情况："不""没""别""无"这类否定词绝对不能进停用词表，否则"不好"和"好"在特征空间里完全一样，模型直接学反。同理，"很""太""非常""有点"这些程度副词也得留着，它们携带强度信息。

还有一个高频坑是标点符号。"好！"和"好？"的情感强度完全不同，感叹号往往意味着情绪强烈。我的做法是保留连续感叹号和问号作为特殊 token，其他标点过滤掉。这个改动在业务数据上通常能带来一到两个点的 F1 提升。

2.3 标签噪声与类别不平衡的处理

标签噪声几乎是必然存在的。清洗手段有两个：一是规则过滤，比如文本长度小于 5 个字的直接踢掉，纯表情包、纯链接、纯数字的也踢掉；二是模型辅助找异常，先用全量数据训一个模型，把"模型非常有把握但预测与标签相反"的样本捞出来人工复核，通常能揪出一批标错的。

类别不平衡的处理方式我按优先级排一下：

• 首选 class_weight='balanced'，一行参数的事，让损失函数自动给小类别加权，简单有效。
• 次选调整分类阈值，模型输出概率后，把小类别阈值从 0.5 降到 0.3，用验证集找最优切点。
• 再考虑重采样，欠采样会丢信息，过采样容易过拟合，SMOTE 在文本高维稀疏空间里效果不稳定，我不太推荐。
• 最后才是构造损失函数，比如 Focal Loss，实现成本高，收益不一定对得起投入。

注意：不要在划分训练集之前做重采样，那会造成数据泄漏，验证集指标虚高。正确顺序是先切分，只对训练集重采样。

3. 传统方案实操：TF-IDF 加线性模型

这条路线是我建议所有人都先跑一遍的基线。它的价值不在于最终效果，而在于给你一个参照系：后面上大模型如果只提升两个点，你就得掂量一下值不值。

3.1 特征工程的关键参数怎么定

TF-IDF 的核心参数有四个，我逐个说清楚它们的作用和取值逻辑。

max_features控制词表大小，常用 10000 到 50000。样本量小的时候给 10000 就够，给太大反而引入噪声。判断依据是：词表大小不应该超过训练样本数的十分之一，否则很多词只出现一两次，学不到稳定权重。

ngram_range控制 n 元组。(1,1)只取单词，(1,2)包含二元组。情感分析里二元组很有价值，因为"不 好""太 贵"这类组合的极性反转信息只有二元组才能捕捉。但代价是特征维度暴涨，我一般用(1,2)配合较小的max_features。

min_df和max_df是文档频率过滤。min_df=2表示出现少于两次的词丢掉，能显著降噪；max_df=0.9表示出现在 90% 以上文档里的词丢掉，这类词基本没有区分度。

sublinear_tf=True这个参数容易被忽略，它把词频换成对数尺度，防止某个词重复出现太多次导致权重失衡。评论里"好好好好好"这种表达很常见，开了这个参数会稳很多。

from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.pipeline import Pipeline from sklearn.svm import LinearSVC from sklearn.calibration import CalibratedClassifierCV def build_pipeline(): tfidf = TfidfVectorizer( tokenizer=tokenize, token_pattern=None, # 用了自定义 tokenizer 必须关掉默认正则 ngram_range=(1, 2), max_features=30000, min_df=2, max_df=0.9, sublinear_tf=True, ) # LinearSVC 不直接输出概率，用校准包一层，方便后续调阈值 clf = CalibratedClassifierCV(LinearSVC(C=1.0, class_weight="balanced")) return Pipeline([("tfidf", tfidf), ("clf", clf)])

这里有个容易翻车的点：自定义 tokenizer 时必须把token_pattern设为 None。sklearn 新版本会对此报警告，老版本可能直接导致 tokenizer 不生效，你还在那儿纳闷为什么分词改了没效果。我第一次遇到这个坑排查了快一个小时。

3.2 训练、交叉验证与参数搜索

单次切分评估的方差很大，我现在基本都用分层 K 折交叉验证给出置信区间，再在验证集上做最终确认。5 折是常规选择，样本少的时候用 10 折，但训练时间翻倍。

from sklearn.model_selection import StratifiedKFold, cross_val_score import numpy as np X = train_df["text"].tolist() y = train_df["label"].tolist() pipe = build_pipeline() skf = StratifiedKFold(n_splits=5, shuffle=True, random_state=42) scores = cross_val_score(pipe, X, y, cv=skf, scoring="f1_macro", n_jobs=-1) print(f"macro-F1: {scores.mean():.4f} +/- {scores.std():.4f}")

输出里那个标准差很重要。如果五折之间差了 0.08，说明数据分布不稳定或者样本量不足，这时候盯着均值做决策是有风险的。

参数搜索我就搜两个：C（正则强度）和ngram_range。C越大正则越弱、越容易过拟合，取值在 0.1 到 10 之间网格搜一遍足够。朴素贝叶斯的话只搜alpha，取值 0.01 到 1.0。别搞大而全的网格，收益递减得太快。

3.3 阈值调优与结果解读

三分类模型训练完，别急着看总指标，先看混淆矩阵。我见过太多模型总体 F1 0.85，一看矩阵发现中性类的样本几乎全被分到正类去了，原因是中性样本只占 8%，权重压不住。

from sklearn.metrics import classification_report, confusion_matrix pipe.fit(train_df["text"], train_df["label"]) pred = pipe.predict(val_df["text"]) print(confusion_matrix(val_df["label"], pred)) print(classification_report(val_df["label"], pred, digits=4))

阈值调优的思路是：拿到三类概率后，先看验证集上哪一类的 recall 最低，针对性地降它的判定阈值。比如中性类 recall 只有 0.5，就把中性的概率阈值从 1/3 降到 0.25，牺牲一点精确率换召回。这个操作在小类别上经常能换回 5 到 8 个点的 F1。

调完之后一定要在独立的 test 集上再验一次。我踩过的坑是：在验证集上反复调阈值调了十几轮，验证集指标涨了，test 集纹丝不动甚至掉了——这就是变相过拟合验证集。阈值只在验证集上调一轮，定下来就别再动了。

4. 上深度学习：从词向量到预训练模型微调

传统模型跑出 0.85 左右之后，如果业务还是不满意，就该上预训练模型了。这一步的收益是实打实的，但成本也是实打实的，得算清楚账。

4.1 预训练模型微调的具体流程

流程本身不复杂：加载中文预训练模型和分词器，把文本截断到固定长度，加一个分类头，用较小学习率训练几轮。难点全在参数上。

max_length我给 128 作为默认值。原因是统计过业务评论的长度分布，95 分位在 100 个字符左右，128 足够覆盖，再长就是浪费显存。如果你的数据是长文章，那就得用 256 或者滑动窗口切分，但那样计算量会翻倍。

learning_rate用 2e-5 是主流起点。这个值不能大，因为我们是在一个已经训练好的模型上做微调，学习率太大会把预训练学到的语言知识冲掉，也就是常说的灾难性遗忘。我在 1e-5 到 5e-5 之间试过，2e-5 和 3e-5 通常最稳。

batch_size受显存限制，单卡 16G 跑 128 长度，16 或 32 都行。有个经验是：batch_size 减半时，学习率也大致减半，效果更稳定。

epochs用 3 到 4 轮。情感分析这种任务收敛很快，训太多轮一定过拟合。判断依据是看验证集 F1，连续两轮不涨就停。

warmup_ratio设 0.1，让学习率在前 10% 的步数里线性爬升，训练初期更稳。

from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, TrainingArguments, Trainer ) import torch from torch.utils.data import Dataset MODEL_NAME = "your-chinese-pretrained-model" # 换成实际可用的中文底座 tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME) model = AutoModelForSequenceClassification.from_pretrained(MODEL_NAME, num_labels=3) class SentimentDataset(Dataset): def __init__(self, texts, labels): self.enc = tokenizer( list(texts), truncation=True, padding="max_length", max_length=128, return_tensors="pt" ) self.labels = list(labels) def __len__(self): return len(self.labels) def __getitem__(self, idx): item = {k: v[idx] for k, v in self.enc.items()} item["labels"] = torch.tensor(self.labels[idx], dtype=torch.long) return item train_ds = SentimentDataset(train_df["text"], train_df["label"]) val_ds = SentimentDataset(val_df["text"], val_df["label"]) args = TrainingArguments( output_dir="./ckpt", learning_rate=2e-5, per_device_train_batch_size=16, per_device_eval_batch_size=32, num_train_epochs=3, warmup_ratio=0.1, weight_decay=0.01, logging_steps=50, evaluation_strategy="epoch", save_strategy="epoch", load_best_model_at_end=True, metric_for_best_model="f1_macro", fp16=True, )

weight_decay=0.01是轻微的 L2 正则，防过拟合。fp16=True开启半精度，显存能省将近一半，速度也快，前提是你的卡支持。老卡开了可能出 NaN，那就老老实实关掉。

评估指标那块要自己实现 macro-F1，因为默认的 accuracy 在类别不平衡时完全没参考价值。

import numpy as np from sklearn.metrics import f1_score def compute_metrics(eval_pred): logits, labels = eval_pred preds = np.argmax(logits, axis=-1) return {"f1_macro": f1_score(labels, preds, average="macro")} trainer = Trainer( model=model, args=args, train_dataset=train_ds, eval_dataset=val_ds, compute_metrics=compute_metrics, ) trainer.train()

4.2 显存和训练成本怎么控

显存不够是最常见的拦路虎。我按性价比排序给几个手段：

降 batch_size 并开梯度累积。per_device_train_batch_size=8配合gradient_accumulation_steps=2，等效 batch 还是 16，显存占用却降了一半。这是首选方案，几乎不损失效果。

开梯度检查点。gradient_checkpointing=True能再省 30% 到 40% 显存，代价是训练速度慢 20% 左右。用时间换空间，训练轮数不多的话完全可以接受。

降 max_length。从 256 降到 128，显存和计算量都接近减半。前面说过，先统计一下你的数据长度分布，多半 128 就够。

冻结底层参数。只训最后几层和分类头，显存和时间的开销都大幅下降。数据量小的时候这招很有效，还能防过拟合。数据量大了就别冻了，全量微调效果更好。

提示：训练前先用 100 条样本跑一遍完整流程，确认数据管道、标签范围、评估函数都没问题再上全量。我吃过亏，跑了两小时发现标签里混进了一个 3，而模型只有 3 个类别，直接崩在 loss 计算上。

4.3 传统模型和预训练模型怎么融合

这两条线不是非此即彼。我常用的融合方式有两种：概率加权平均和特征拼接。

概率加权平均最简单，两个模型各自输出三类概率，按验证集上搜出来的权重加权，通常能比单模型高 1 到 2 个点。缺点是要维护两套模型，推理成本翻倍。

特征拼接更适合想只保留一套推理链路的场景：把 TF-IDF 特征和预训练模型的句向量拼在一起，喂给一个逻辑回归。这种做法在数据量中等（几千到两万条）时效果不错，因为 TF-IDF 补上了关键词的精确匹配能力，预训练模型补上了语义泛化能力。

我实际测下来的规律是：数据量越大，预训练模型的相对优势越明显；数据量小、领域黑话多的时候，融合方案比纯预训练模型稳。所以别迷信"上大模型就一定好"，先拿验证集说话。

5. 上线前后的问题排查实录

模型在测试集上表现好，上线后掉链子，这是情感分析最经典的剧本。原因通常不在模型本身，而在数据分布和工程细节上。

5.1 常见问题速查表

下面这张表是我这些年攒下来的，遇到问题先对着查一遍，能省不少时间。

表格里第一条"训练集 0.95 验证集 0.60"，十个新手有八个会遇到。除了过拟合，最常见的原因是特征工程阶段用了全量数据。比如你先对全体数据算 TF-IDF 再做切分，验证集的信息就通过词表 IDF 值泄漏到训练里了。正确做法一定是先切分，再在训练集上 fit，然后 transform 验证集。

5.2 线上效果衰减怎么监控

模型上线不是终点。用户表达会变，热点话题会变，新的网络用语每天都在冒出来。我一般布三层监控。

第一层是输入分布监控。统计每天的文本长度分布、OOV 率（未登录词比例）、高频词变化。OOV 率突然从 5% 涨到 15%，基本说明出现了新话题或者新表达，模型的词表跟不上了。

第二层是输出分布监控。统计每天三类预测的比例。如果负面比例突然从 20% 涨到 45%，两种可能：要么真出事了，要么模型抽风了。这时候要立刻抽样人工看，别急着相信模型。

第三层是抽样人工复核。每天随机抽 100 条，人工标一遍，算和模型的一致率。这个数字掉到 80% 以下，就该考虑重训了。这件事听起来笨，但它是最可靠的信号，因为只有人知道真实答案。

# 一个极简的漂移监控脚本，每天跑一次 import json from collections import Counter def daily_check(texts, model_pipe, baseline_ratio): preds = model_pipe.predict(texts) dist = Counter(preds) total = len(preds) neg_ratio = dist.get(0, 0) / total # 假设 0 是负面 alert = [] if abs(neg_ratio - baseline_ratio) > 0.10: alert.append(f"负面比例偏移: {neg_ratio:.2f} vs 基线 {baseline_ratio:.2f}") avg_len = sum(len(t) for t in texts) / total if avg_len < 5: alert.append(f"平均长度异常偏短: {avg_len:.1f}") return {"neg_ratio": round(neg_ratio, 3), "avg_len": round(avg_len, 1), "alert": alert}

这个脚本很土，但有用。阈值 0.10 是根据历史波动定的，你自己跑一段时间基线之后就知道了。别设太灵敏，否则天天报警，最后就没人看了。

5.3 几个不上文档但很值的经验

第一，先做二分类再做三分类。如果中性样本实在难标、难分，索性先做正负二分类，把"模棱两可"的样本单独放到一个待定池，业务上按低置信度处理。这比硬凑三分类、把中性类搞成 0.5 的 F1 要实在得多。

第二，清洗规则要双向可逆。清洗函数上线前一定要留一个"原始文本 -> 清洗后文本"的对照日志。等线上出问题时，你能五分钟内定位是清洗规则吃掉了关键信息，而不是花两天去猜模型出了什么毛病。

第三，样本要按时间切分做一次额外评估。随机切分给出的是乐观估计，按时间切分（用早期数据训练、近期数据测试）才是接近线上真实情况的数字。我一般两个都做，如果时间切分的 F1 比随机切分低 5 个点以上，说明数据漂移严重，模型版本迭代频率得提高。

第四，别忽略"低置信度"这个输出。模型给出的最高概率低于 0.6 的样本，直接路由给人工，别硬判。业务上一条错判的差评可能引发连锁反应，而人工复核的成本远低于这个风险。这个设计比把准确率从 0.90 提到 0.92 有用得多。

第五，版本管理从第一天就做。数据版本、模型版本、预处理规则版本，三者绑定记录。我见过最惨的情况是模型效果回退，结果发现是两周前有人改了一行停用词表，谁也说不清当时为什么改。用简单的目录加配置文件就能解决，别嫌麻烦。

最后说个我自己的体会：情感分析这个任务，效果的上限往往不是被模型架构卡住的，而是被"人对情感的理解本身就不一致"卡住的。同一句"这价格我也是服了"，有人读成讽刺，有人读成赞叹。所以与其在模型上死磕最后两个点，不如先把标注规范打磨到两个人能达 0.8 的 Kappa。数据干净了，一个线性模型的 0.86，往往比数据脏兮兮的预训练模型的 0.84 更值得信任。