接到这个需求的时候对方给了我一整份微博评论的Excel说要做一个情感分析二分类模型。我当时没有急着去选网络结构而是先把样本从头到尾翻了十来分钟。翻完之后我的判断是这活儿不能照着教科书里的标准文本分类流程硬套。微博评论这东西短、乱、情绪表达高度口语化“哈哈哈这电影绝了”和“这电影绝了”可能就差一个词语义方向却完全不同。也正是这次经历让我最终确定了LSTMCNNGloVe词向量预训练模型这套方案CNN负责抓局部关键词LSTM负责串联上下文GloVe负责在标注数据有限的情况下给模型提供先验语义。这篇文章就把整个项目的来龙去脉完整写下来包括数据怎么洗、模型怎么搭、参数怎么调、最后踩了哪些坑给准备做类似评论情感分析任务的朋友一个能直接参考的完整路线。1. 先看数据再看模型微博评论的“脾气”与二分类边界1.1 微博评论和标准文本分类数据集差在哪如果你以前主要拿新闻语料或者商品评论做分类任务第一次面对微博评论的时候一定会有一个明显的不适应感。新闻文本结构完整、用词规范商品评论虽然口语化但目标明确——夸就是正面、骂就是负面。微博评论是完全不同的物种。首先它短。大多数评论不会超过30个字很多甚至就是三五个字的梗“绝了”“yyds”“笑不活了”“人麻了”。这种信息密度极低的文本传统基于词频统计的特征很容易失效因为同一个表达在不同语境下可能完全是两种情绪。其次是网络热词密集。我做数据预处理的阶段光自定义词典就加了上百个词yy ds、绝绝子、u1s1、栓Q、破防、emo……这些词在通用语料里很少出现或者即使出现分词器也容易把它们切成碎片。而且热词的迭代速度非常快这个月流行的梗下个月可能就没人用了所以模型必须依赖预训练词向量来兜底不然完全靠标注数据学这些词成本高得离谱。再次是噪声多。用户、URL链接、表情符号、重复叠词、繁体字、全角半角混用这些在评论里几乎是标配。一条“哈哈哈哈哈哈哈哈哈哈哈哈哈哈太好笑了吧”里面真正有效的情感词其实只有一个“好笑”剩下的全是冗余字符。如果不做压缩清洗词表会被这种无意义的字符组合撑爆模型也会被带偏。最后是反讽和隐晦表达多。豆瓣社区式的“阴阳怪气”、微博常见的“呵呵”“挺好”“你开心就好”这些在字面上看完全没有负面词但在上下文里往往是负面情绪。这让二分类任务的难度直接上了一个台阶也是我后来在错误样本分析里重点关注的类型。1.2 二分类边界中性样本怎么归置是个大坑需求方说要二分类但原始数据标注通常是三分——正面、负面、中性。这里就碰到了一个所有做情感分析的人都会纠结的问题中性样本到底算哪边我见过两种主流做法。第一种是把中性直接归入负面理由是电商场景里“不表扬就等于差评”用户没有明确表达满意说明体验离预期有距离。第二种是只保留明显正面和明显负面的样本把中性丢掉尤其当你的模型容量不大时混入大量中性样本会让决策边界变得很模糊“模型不知道该往哪边靠”。我当时选了第二种思路的变体先看三条标注的一致性把三个人都标成中性的样本直接剔除被标成中性的但带有明显情绪词的重新讨论归入对应类别最终保留正负两类各自一万条出头。做完这一步之后模型的收敛速度明显快了验证集上的指标也涨了一截。这里要提醒一句如果你的业务场景确实需要识别“中性”那就别硬做二分类扩成三分类任务更合理。二分类的前提一定是业务上只关心正负两个方向。否则你把中性样本生硬地塞进某一类模型学到的边界就是乱的上线之后预测结果也会让人摸不着头脑。1.3 为什么是LSTMCNNGloVe而不是直接上BERT模型选型这件事我的立场从来都是“先看自己手里有什么”。我当时手头只有一万多条标注数据对计算资源也有要求线上推理还得兼顾速度。直接上BERT类预训练模型不是不行但对这个体量的任务来说性价比不高。GloVe词向量的价值在于它在大规模语料上通过共现统计学习到了词的语义表示。比如“精彩”和“好看”虽然在标注数据里可能没有同时出现在同一条评论里但它们在词向量空间中是相近的模型可以通过Embedding层把这种相似性带到下游任务里来。这相当于把外部知识注入了模型是数据量不足时最划算的杠杆。CNN的强项是捕捉局部n-gram特征。情感表达往往由特定的关键词组合触发比如“太……了”“一点儿都……不……”“……到爆”。这类固定搭配通常只出现在一个很小的窗口内正好是CNN卷积核擅长扫描的范围多个不同尺寸的卷积核可以同时捕捉不同长度的短语模式。LSTM则负责把词的顺序和上下文关系串起来。短文本虽然信息少但语序往往决定语义“我不喜欢”和“喜欢我不”完全不是一回事。LSTM对顺序敏感双向LSTM还能同时看到某个词之前和之后的内容对“这部电影我劝你别看”这种句子很有帮助。把一个任务拆给两个模型分支去做最后把特征拼接起来是我在实际项目里验证过很稳的方案。单用CNN能抓到关键词但容易忽略语境单用LSTM能理解上下文却又对强特征词的响应不够直接。两个分支互补效果比各自单跑都有提升。2. 数据预处理清洗、分词、词表与序列化每一步都在影响最终效果2.1 清洗规则哪些该删哪些该留很多教程会把预处理写得轻描淡写好像正则替换几条规则就完事了。实际做下来清洗规则的设计直接决定词表质量也直接影响后续词向量的覆盖率。我在这部分花的时间比搭模型还多。我的清洗流程是这样的import re import opencc converter opencc.OpenCC(t2s) # 繁体转简体 def clean_text(text: str) - str: # 1. 去掉URL和用户 text re.sub(rhttps?://\S|www\.\S, , text) text re.sub(r\S, , text) # 2. 去掉话题标签符号保留话题文字 text re.sub(r#([^#])#, r\1 , text) # 3. 压缩重复字符哈哈哈哈哈哈 - 哈哈哈哈 text re.sub(r(.)\1{2,}, r\1\1, text) # 4. 繁体转简体、全角转半角 text converter.convert(text) text re.sub(r[“”], , text) # 5. 表情符号替换成特殊token text re.sub(r\[(.*?)\], r [EMOJI_\1] , text) return text.strip()这里有几条容易踩坑的规则。第一条是压缩重复字符一定要放在分词前面。微博里“哈哈哈哈哈”非常常见如果不压缩“哈哈哈哈”和“哈哈哈哈哈”在词表里会变成两个完全不同的词而GloVe预训练词向量里通常只收录了“哈哈”覆盖率一下子就掉下去了。我见过有人为了省事不压缩结果词表里光“哈”的各种长度组合就占了上百个词位。第二条是表情符号的处理。微博自带表情的原文形式是[赞]、[笑cry]这种中括号结构如果直接删掉会丢失大量情绪信号如果保留中括号原样分词又会变成奇怪的碎片。我的做法是把整个表情转成一个带标识的token比如[EMOJI_赞]、[EMOJI_笑cry]这样模型可以学到这个token和情绪之间的关联。当然这个做法要求你的词向量覆盖这些token覆盖不了也没关系Embedding层对没覆盖的词会随机初始化模型自己学。第三条更重要停用词表要慎用。做情感分析时否定词“不、没、别、无”和程度副词“太、很、非常、极其”绝对不能进停用词表。“太差”和“好”是正面词“不好”就是负面词你把“不”删了语义直接翻转。我刚开始就犯过这个错去掉停用词后F1掉了好几个点。2.2 分词与自定义词典让“yyds”变成一个词中文分词我用的是jieba的精确模式准确率够用关键是自定义词典必须跟上。做微博评论情感分析分词的质量直接决定后续所有环节的上限。你在通用语料里分词“yyds”可能被切成字母碎片甚至被当成英文过滤掉而“绝绝子”这种叠词结构也可能被拆成“绝绝”和“子”。我当时的做法是定期把训练集里出现频率较高的未登录词捞出来人工确认后加入自定义词典。举几个我自己加进去的词yyds、绝绝子、u1s1、栓Q、破防、下头、上头、安利、拔草、种草、真香、打call。这些词在微博语境里都是高频情绪词分词正确之后CNN分支的卷积核才有机会把它们识别为有效特征。另外分词之后我保留了词性过滤这一步但只过滤掉明显的虚词和标点词只保留长度大于1的。单字词里“牛”“绝”“妙”都是强情感词不能一刀切。过滤用的停用词表是经过人工挑选的和百度NLP那些通用停用词表不一样原因就是上一条说的情感分析场景下否定词和程度副词必须保留。2.3 词表构建、OOV与序列填充预处理完成之后进入序列化阶段。我用的是Keras的Tokenizer关键参数是num_words和oov_token。num_words我设的是五万也就是词表保留频次最高的前五万个词。这个值不是拍脑袋定的而是根据训练集的词汇量分布来的——五万以内基本覆盖了90%以上的评论词再往上大多是低频噪声。from tensorflow.keras.preprocessing.text import Tokenizer from tensorflow.keras.preprocessing.sequence import pad_sequences tokenizer Tokenizer(num_words50000, oov_tokenOOV) tokenizer.fit_on_texts(train_texts) sequences tokenizer.texts_to_sequences(train_texts) # maxlen 我选了50微博评论大部分在30字以内留出余量 padded pad_sequences(sequences, maxlen50, paddingpost, truncatingpost)这里有一个很容易被忽略的细节oov_tokenOOV会在词表里占一个索引所有没进前五万的词都会被映射到这个统一token上。这样做的好处是模型不会因为见到生词就崩溃坏处是OOV词丧失了个体语义。为了缓解这个问题我把num_words适当调大了一些并且在清洗阶段尽量把可能造成OOV的噪声处理掉。关于maxlen的选择短文本没必要拉太长。微博平均长度二三十字设成50已经覆盖了绝大多数样本如果设成100或200大部分序列会被大量padding填充模型在padding区域白白消耗计算量还容易引入噪声。paddingpost和truncatingpost的含义是从尾部填充和截断这样能尽量保留句子前面的完整语义。序列化之后还有一个必须检查的环节抽样看几条texts_to_sequences之后的索引序列是否和原文对应。我试过一次分词时没做繁简转换导致同一句话的简体版本和繁体版本被当成两个不同的词词表莫名其妙膨胀了很多。2.4 训练集和验证集划分的隐藏风险划分训练集和验证集时我遇到过最典型的坑就是同一条原始微博的不同评论被抓进了不同集合里。微博有评论串帖的现象一条热门微博下面可能有几百条回复这些回复共享同一个上下文主题语言风格也趋同。如果按评论级别随机划分主题相关的高相似样本会同时出现在训练集和验证集里验证集的指标会虚高给人“模型效果很好”的错觉上线之后立刻现原形。正确做法是按微博ID分组再划分保证同一条微博的所有评论只出现在一边。这个细节我在第一次跑实验时没注意验证集F1高达0.9换成按ID分组划分之后直接掉到0.8附近那才是最真实的水平。3. 模型搭建GloVe权重加载、TextCNN与BiLSTM融合的关键实现3.1 Embedding层的加载姿势对齐词表索引是核心模型搭建的第一步不是定义网络结构而是把GloVe预训练词向量加载进来并且把词表索引和词向量矩阵对齐。这一步错一个下标整个模型的学习过程就全乱了。GloVe词向量文件的标准格式是每行一个词行首是词后面跟着固定维度的浮点向量用空格分隔。加载逻辑并不复杂import numpy as np def load_glove_embedding(glove_path, word_index, embed_dim300): embeddings_index {} with open(glove_path, r, encodingutf-8) as f: for line in f: values line.strip().split() word values[0] coefs np.asarray(values[1:], dtypefloat32) embeddings_index[word] coefs # 词表index从1开始0留给padding embedding_matrix np.zeros((len(word_index) 1, embed_dim)) hit 0 for word, i in word_index.items(): vec embeddings_index.get(word) if vec is not None: embedding_matrix[i] vec hit 1 print(f词向量覆盖率: {hit}/{len(word_index)} {hit / len(word_index):.2%}) return embedding_matrix这里有两个关键点。第一embedding_matrix的行数必须是len(word_index) 1因为Keras的Embedding层在padding时用索引0这个位置要留出来。如果你写成了len(word_index)训练时会在最后一步报索引越界。第二词向量覆盖率一定要打出来看一眼。我当时洗过的数据常见词的覆盖率在80%以上剩下那些没覆盖到的主要是网络热词和特殊token。覆盖率如果低于70%就要回头检查清洗和分词环节是不是出了问题。关于词向量本身这里要特别说明一个中文场景的坑。GloVe官方提供的是英文预训练向量中文没法直接用。我当时用的是一个在中文语料上训练的GloVe版本格式和加载方式完全一样。如果你手头只有腾讯或搜狗那类通用中文词向量文件加载逻辑也是相同的只是文件格式里每个词的元信息不同解析时多处理一步就行。核心判断标准就一条你用的词向量必须覆盖你任务所在的语言和领域英文向量跑中文项目肯定不对路。Embedding层里还有一个参数值得反复拿捏trainable。如果标注数据很少建议把trainableFalse让Embedding层保持冻结状态模型只能利用预训练的语义表示如果像我这个项目一样有一万条左右的数据就可以把它设成True让模型在训练过程中微调词向量把领域知识学进去。我在实验里测过冻结时F1大约低三个点解冻后指标明显提升代价是训练时间变长而且训练初期容易过拟合需要配合早停策略使用。3.2 CNN分支多尺寸卷积核抓短语特征CNN分支的设计思路借鉴了TextCNN的结构。核心思想是用多个不同宽度的卷积核在Embedding序列上滑动相当于同时看2-gram、3-gram、4-gram的短短语模式。from tensorflow.keras.layers import ( Input, Embedding, Conv1D, GlobalMaxPooling1D, LSTM, Bidirectional, Dropout, Dense, concatenate ) from tensorflow.keras.models import Model def build_model(vocab_size, embed_dim, maxlen, embedding_matrix): inputs Input(shape(maxlen,)) emb Embedding( vocab_size 1, embed_dim, weights[embedding_matrix], trainableTrue, mask_zeroFalse )(inputs) # CNN分支3种卷积核各64个filter convs [] for kernel_size in [2, 3, 4]: conv Conv1D(filters64, kernel_sizekernel_size, activationrelu)(emb) pool GlobalMaxPooling1D()(conv) convs.append(pool) cnn_out concatenate(convs) # LSTM分支双向LSTM lstm_out Bidirectional(LSTM(units128, dropout0.3, return_sequencesFalse))(emb) concat concatenate([cnn_out, lstm_out]) dense Dense(128, activationrelu)(concat) dense Dropout(0.3)(dense) output Dense(1, activationsigmoid)(dense) model Model(inputs, output) return model我用了三种卷积核尺寸分别是2、3、4各64个filter。2-gram能抓到“不喜”“绝了”这种两词搭配3-gram能抓到“太好笑”“真无语”4-gram覆盖面相对更大。卷积之后的池化层选择很重要我用的是GlobalMaxPooling1D而不是平均池化。情感分析里往往只靠一两个关键短语就能定基调max pooling会把整个序列里“响应最强”的特征挑出来平均池化则会把关键信号稀释掉。3.3 LSTM分支双向结构捕捉上下文LSTM分支我用的是双向LSTM隐藏单元数128。双向的意思是同时有一个正向的LSTM从头到尾读句子一个反向的LSTM从尾到头读句子最后把两个方向的输出拼接起来。这对短文本来说特别有意义“这部电影不怎么样”里“不”对后面的“怎么样”有修饰作用正向来读能捕捉“不怎么样”这个组合而“一点都不可爱”里“可爱”位于句尾反向LSTM能从尾部往回看更好地捕捉“不可爱”的语义。这里return_sequencesFalse表示只保留最后一个时间步的隐藏状态把整条句子的压缩表示作为输出。很多人会误以为对短文本来说单层LSTM就够了我实测下来双向比单向稳定高两个点左右。缺点也很明显参数量翻倍训练时间变长。如果你的数据量小到只有两三千条建议把LSTM(units128)换成LSTM(units64)双向保留效果会更稳。LSTM内部我加了dropout0.3这是LSTM层自身的dropout主要作用于输入和循环连接能有效缓解过拟合。如果你发现训练集loss很低但验证集loss很高优先检查这一项其次再考虑全连接层的Dropout。3.4 特征融合与输出层两个分支的输出最后通过concatenate拼接成一个向量。CNN分支输出维度是3乘64等于192LSTM分支输出维度是双向128乘2等于256拼接后是448维。这个向量经过一个128维的全连接层再做一次Dropout最后接一个单节点sigmoid输出。sigmoid输出的是样本属于“正面”的概率通常以0.5为阈值划分正负但这个阈值不是死的后面我会专门讲怎么根据业务需求调整。这个模型结构不算复杂参数量大概在几百万量级一张普通的单卡就能跑起来。我当时用批量大小64训练十几个epoch每个epoch大概几十秒整个项目从零到一不到半天时间。这种轻量级结构最大的好处是容易调试、容易部署出问题时也容易定位到底出在哪个分支。3.5 一个容易忽略的细节padding区域的mask问题Embedding层的mask_zero参数我设成了False这里值得解释一下。mask_zeroTrue的意思是让Embedding层自动忽略索引为0的位置也就是padding的部分这对LSTM特别友好可以避免模型把无意义的padding当真。但问题在于如果设成mask_zeroTrueEmbedding层返回的是一个带mask的序列而CNN分支的一些操作对这种mask支持得不好容易报错或者导致卷积计算也被屏蔽。我当时图省事直接设了False好在maxlen不长padding对模型的影响很有限整体效果并没什么影响。如果你追求更精细的效果可以试一下mask_zeroTrue然后在对CNN分支做GlobalMaxPooling1D时留意行为是否有异常。这个细节属于锦上添花不是必选项。4. 训练调参实战从Loss曲线到类别不平衡的三板斧4.1 损失函数、优化器与学习率二分类任务的标准配置是sigmoid输出加binary_crossentropy损失优化器我用的是Adam。初始学习率设成1e-3这个值在大多数情况下都不会太离谱。from tensorflow.keras.callbacks import EarlyStopping, ReduceLROnPlateau model.compile( optimizeradam, lossbinary_crossentropy, metrics[accuracy] ) callbacks [ EarlyStopping(patience3, restore_best_weightsTrue), ReduceLROnPlateau(patience2, factor0.5, min_lr1e-5) ]ReduceLROnPlateau这个回调很容易被新手忽略但它在训练中后期非常有用。模型跑几个epoch之后如果验证集loss不降了回调会自动把学习率减半让模型在更小的步长下继续微调。我实测这个策略比死守初始学习率跑到底效果稳定得多。4.2 训练过程中的诊断信号训练的时候不能光盯着验证集准确率一定要同时看训练集loss和验证集loss的走势。这里有几个典型的信号我逐个说一下对应的处理方式。第一种情况训练集loss已经很低验证集loss却高企不下验证集准确率也上不去。这是过拟合的典型信号优先检查Dropout是否到位其次把EarlyStopping的patience调小。第二种情况训练集loss和验证集loss都降得很慢甚至在震荡。这时优先怀疑学习率是不是太大了把初始学习率从1e-3降到1e-4重新试。第三种情况也是我这次遇到的情况验证集loss降了几个epoch后突然反弹。排查了一圈发现是Embedding层解冻太早导致词向量被大量不相关样本带偏了。我的解决办法是分两阶段训练第一阶段冻结Embedding层只训练上游的CNN和LSTM分支等上层网络基本收敛后再解冻Embedding层用很小的学习率对整个模型微调。这个两阶段策略在数据量不充裕的任务里非常管用值得记下来。4.3 关键参数表与推荐值参考我把自己在本次项目里实际使用的参数整理成了一个表格供参考。数据规模、文本长度不同参数需要跟着调但初始值可以从这里起步。参数推荐值我的选择及依据maxlen30~60我选50因为微博评论多数在30字以内embed_dim100~300我选300与预训练向量维度一致卷积核尺寸2, 3, 4覆盖两词到四词短语filter数量64~128我选64兼顾效果与训练速度LSTM隐藏单元64~128我选128双向之后输出256维全连接层维度64~128我选128加Dropout防过拟合batch_size32~64我选64一万多条样本训练较快初始学习率1e-3~1e-4我选1e-3配学习率衰减early_stop patience2~4我选3避免模型在验证集上反复横跳4.4 类别不平衡三种处理手段微博评论的正负样本比例天然是不平衡的负面情绪更倾向于说得更冲、更明确而正面表达相对克制。我清洗后拿到的数据里负面样本比正面样本多了大概三成。类别不平衡如果不处理模型会往多数类严重倾斜全预测成负面准确率也可能不低但正面评论基本全废。我的处理顺序是先用class_weight给少数类加权训练时少数类样本的loss被放大。这个手段最简单不动数据只是告诉模型“少数类的错误更贵”。# 0是负面1是正面多数类是负面 class_weight {0: 1.0, 1: 1.4}如果加权后效果还不够再考虑过采样或者欠采样。但微博评论的情感标签噪声本身就不小无脑复制少数类样本容易让模型死记硬背某几条具体评论泛化能力反而下降。我更推荐的做法是去埋标签噪声而不是造更多噪声数据。另外还有一个容易被忽略的手段调整预测阈值。模型最终输出的是sigmoid概率默认以0.5为分界线。如果你的业务更看重“把正面评论准确捞出来”可以把阈值往上抬到0.6甚至0.7用召回率换准确率反过来就看你要的是啥。这个调阈值的过程不需要重新训练直接拿验证集试几分钟就能定下来。5. 评测复盘与下一步别只看准确率把错分样本拉出来看5.1 指标选择二分类不能只看accuracy很多初学者做完分类任务习惯只看准确率但这个指标在不平衡数据上很会骗人。假设你的验证集里60%是负面样本模型全部预测成负面准确率就是60%看起来“及格了”实际上正面评论一条都没分对模型毫无使用价值。我一般会先输出分类报告用sklearn一行搞定from sklearn.metrics import classification_report, confusion_matrix # y_pred是模型输出的0/1标签 print(classification_report(y_true, y_pred, target_names[negative, positive]))重点看两个数字正面类的F1和负面类的F1。如果两者相差超过五个点说明模型对某一类有明显的偏向需要回头检查类别不平衡处理是否到位。我当时正面类的F1到了0.83负面类是0.79整体算均衡说明加权和阈值调整起到了作用。混淆矩阵也是必看的。它能把“错在哪”具象化正面被误判成负面还是负面被误判成正面。这两类错误在业务上代价完全不同比如做舆情监控把负面舆情漏掉远比把正常评论误伤严重那就要把负面类的召回率拉满哪怕牺牲一点正面类的准确率。5.2 错分样本到底长什么样指标看完了必须把预测错的样本拉出来一条条看。这一步是提升模型的关键也是最容易偷懒不做的部分。我整理了一批典型的Bad Case列几个有代表性的原始评论标注模型预测问题分析这电影绝了正面负面“绝了”一词在语境中高度歧义模型偏向去学习字面负面特征呵呵负面正面字面中性词微博语境下是典型嘲讽模型缺少反讽识别能力666正面负面网络热词词向量覆盖不全模型只能靠随机初始化去猜无语这操作我直接人麻了负面负面正确预测但“人麻了”这类热词全靠自定义词典兜底“绝了”这种词是我踩过的最大坑之一。在GloVe词向量里“绝”的近邻词可能带有负面色彩模型学到的是“绝极端不好”但在微博语境里“绝了”经常是“太好看了”的口语化表达。这种词义漂移靠词向量很难纠正只能靠大量真实标注让模型自己去调整词义权重。“呵呵”则反映了一个更本质的问题情感分析的模型再强也只能学到表面词义和模式无法真正理解人类社会里的“阴阳怪气”。如果想进一步缓解可以尝试把表情符号和标点符号的上下文特征加入模型但说实话效果有限反讽永远是情感分析里最难的边界问题。5.3 还值得尝试的提效方向这套LSTMCNNGloVe的组合做完之后整体效果基本可用但还是有几个明显的可优化方向。以我自己的经验看优先级从高到低排列如下。第一优先级是继续提升数据质量。这听起来很土但实际收益最大。我把标注里三个人意见不一致的样本全部拉出来重新核对再补充清洗了一些高频噪声词之后F1从0.78出头提升到了0.83左右。这个提升幅度比我换任何网络结构都大。数据质量永远是深度学习的上限。第二优先级是给模型加入注意力机制。具体做法是在LSTM的输出上接一个注意力层让模型学习把注意力集中在句子里最关键的那几个词上。CNN分支用多个卷积核已经在做类似的事情但注意力机制能给模型更强的解释性——你可以直接看到模型在判断一条评论时更依赖哪些词。这对后续调试和改进非常有价值。第三优先级才是换更大的预训练模型。如果数据量能积累到五万条以上可以考虑让BERT类模型做教师模型把它的预测结果蒸馏出来训练一个更小的学生模型部署到线上。这个方案兼顾了效果和性能但实现成本高很多数据量不够时反而容易出现学生模型学不到位的尴尬。我个人对这类轻量级文本分类任务的经验是先把数据处理到极致再把一个中等复杂度的模型调明白它的效果已经能覆盖很多业务场景了。不要一上来就追求最先进的模型调参和调试的成本可能比收益还要大。回头复盘这个项目让我印象最深的不是网络结构本身而是“每一层细节都会传导到最终结果”这件事。分词不一致会让词向量覆盖率下降覆盖率下降会让模型被迫随机初始化随机初始化会让热词情感学习变得困难热词学不明白会让线上预测频频出错——每一个环节看似不起眼积累起来就是模型质量的差距。如果你正准备做类似的评论情感分析项目我的建议很简单数据清洗和标签质量上多花的时间最后都会在模型指标上还给你。