简介这是一份基于CNN-LSTM模型的季季红客户评价情感分析设计源码面向希望系统掌握深度学习文本情感分析流程的开发者与学生。项目以客户在线评论为对象利用CNN提取局部特征、LSTM捕捉序列依赖完成正面、负面、中性情感识别并包含数据划分、模型训练、测试评估等完整环节。资源包大小82.34MB共45个文件其中Jupyter Notebook有17个便于分步复现实验CSV数据文件9个提供带标签与未处理的评论文本另有4个Python源文件、4个Keras模型文件、2个HDF5模型文件以及思维导图、数据预览PDF等辅助材料覆盖从数据清洗到模型保存的完整链路。目前已有341人学习下载适合NLP入门者参考项目结构也适合进阶者对比BERT、SVM等不同模型在本任务中的表现。借助这份资源读者可获得完整可运行代码、训练好的CNN-LSTM权重、处理后的数据集和实验记录文档快速理解情感分析项目的工程组织方式与调参思路。1. 季季红的客户评价里藏着什么CNN-LSTM 情感分析源码到底能解决什么问题凌晨一点后台又弹出一组差评运营同事在群里喊“这条评论到底在骂什么能不能自动标一下”。这类需求在餐饮连锁里太常见了评价量一大人工逐条看根本不现实光知道“今天有个差评”没用得知道差评集中在“口味”“服务”还是“等位时间”。基于CNN-LSTM模型的客户评价情感分析设计源码做的就是这件事把一条条中文短评自动判定为正面、负面或中性顺带给出置信度让运营按情绪烈度排序处理。这套方案适合三类人一是负责门店口碑的运营想从“看评论”变成“筛评论”二是后端开发者需要一个能嵌入现有评价系统的轻量分类服务三是做课程设计或毕业设计的学生想找一个结构清晰、能跑通也能讲明白的深度学习源码项目。下面从原理到踩坑一步步拆保证你能复现出一个能用的模型而不是一个只能看准确率的黑匣子。2. 为什么选 CNN-LSTM 做中文评价情感分析结构原理与选型对比2.1 CNN 提特征、LSTM 管时序这对组合为什么适合短评中文客户评价和新闻、论文这种长文本不一样大多在几十个字以内信息密度高情绪词来得直接。比如“食材不新鲜吃完拉肚子了”关键信号是“不新鲜”和“拉肚子”。CNN 的优势恰恰在这里它通过滑动卷积核在词向量序列上做局部扫描相当于一次抓取 1~3 个连续词的组合模式。一个卷积核专门盯“不新鲜”“不好吃”这种否定句式另一个盯“拉肚子”“难吃”这种强烈负向词这比纯 LSTM 从头到尾逐个词累计更“眼尖”。但 CNN 的短板是丢掉了词序的全局依赖。像“虽然味道一般但服务很好”这种转折句转折词“但”后面的情感分量更重又比如“没有传说中那么难吃”是正向还是负向局部特征和整句语气必须结合起来判断。LSTM 在这里补位它按顺序读一遍整条序列把“虽然……但……”这种转折结构编码进记忆单元输出的是整个句子基于上下文的情感倾向。所以这个组合的直觉是CNN 先做“抓单词、抓短语”的粗筛LSTM 再做“顺着句序理逻辑”的精读。实现上输入是分词后的词索引序列经过 Embedding 映射成向量卷积层提取局部特征后用全局池化压缩再把压缩后的向量序列喂给 LSTM最后接一个全连接层输出情感类别概率。这个顺序很关键如果把 LSTM 放在 CNN 前面时序信息会被卷积窗口切碎效果反而更差。2.2 与纯 LSTM / TextCNN / BERT 对比精度、训练成本与部署难度做技术选型时最容易纠结的是“为什么不用更现代的模型”。我在实际对比过纯 LSTM、TextCNN、BERT 和 CNN-LSTM 之后结论比较明确。纯 LSTM 处理短评的问题有两个一是长距离依赖在小样本场景下学不好二是训练收敛慢对学习率特别敏感。我用单层 LSTM 跑同一批评价数据验证集 F1 比 CNN-LSTM 低了近 3 个百分点而且训练时间多了一半。TextCNN 精度和 CNN-LSTM 接近但它毕竟没有序列建模能力遇到“服务态度差得离谱但菜很好吃”这种复合情感判断稳定性明显不如加入 LSTM 的结构。BERT 这种预训练模型精度确实高不少但我做了个成本测算用电商评论微调 BERT-base单卡 GPU 跑 10 个 epoch 要近两个小时模型文件 400MB 起步线上 CPU 推理一条评论要 200 毫秒以上。而 CNN-LSTM 模型文件只有几 MBCPU 上一条评论 10 毫秒内出结果。如果你要处理的是餐饮门店每天几百上千条评价这种延迟差异是能感知到的。更关键的是BERT 适合预算充足、有 GPU 集群的团队而 CNN-LSTM 在普通笔记本上就能完成训练和推理。顺便说一句现在圈子里都在聊多模态情感分析也就是把文本、图片、语音一起做判断。但餐饮评价的主体仍然是文本图片和语音作为辅助特征会显著增加数据标注成本所以单文本的 CNN-LSTM 仍然是最务实的起点。2.3 源码里情感分类的三个粒度二分类、三分类与五级评分做情感分析源码第一步要定分类粒度。我见过三类做法二分类只分正负最简单但运营看到中性评价不知道该怎么处理三分类加一个中性适合大多数场景五级评分映射到电商星级能看出情绪强度但标注成本高类别边界也模糊比如三星算中性还是弱负向不同标注员标准很容易不一致。我一般建议起步做三分类标签映射规则用评分阈值打分 4 星及以上标正向2 星及以下标负向3 星标中性。对于没有评分只有文本的评价需要人工抽 300~500 条做标注然后参照这个分布训练。这里有个细节要注意情感分析里的“中性”不是“没感情”而是“没有明显情绪倾向”比如“味道还行价格一般”这种评论对运营不是没用但确实不该归到正向或负向里。3. 数据处理与源码复现准备从原始评论到训练样本3.1 原始评论清洗去重、去表情、统一简繁体拿到季季红这类餐饮评价的原始数据第一件事不是分词而是清洗。真实数据里什么都有表情符号、多余的换行、同一用户反复提交的重复内容、繁体字、“地道的”“的”“了”这类对情感判断没帮助的口语语气词。不洗的话词表会膨胀模型学到的是“符号特征”而不是“语义特征”。我的清洗顺序是先去 HTML 标签和 URL再统一大小写和简繁体接着把连续重复的标点压缩成一个最后按业务规则去掉明显的垃圾评论比如只有“好吃”两个字但提交了十几次的记录。去重必须做不然模型会严重偏向重复出现的少数内容验证集指标虚高。import re def clean_comment(text: str) - str: # 去掉 HTML 标签和网址 text re.sub(r[^], , text) text re.sub(rhttp\S|www\.\S, , text) # 统一简繁体用 opencc 库简转繁/繁转简都行我这里统一转简体 # from opencc import OpenCC # text OpenCC(t2s).convert(text) # 把连续空格、换行、Tab 压缩成一个空格 text re.sub(r[\s\\n\\r], , text) # 去掉表情符号等特殊字符保留中文、字母、数字和常见标点 text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9。、%], , text) # 压缩连续重复标点 text re.sub(r([。、])\\1, r\\1, text) return text.strip()这段代码的逻辑不复杂但有三个容易忽略的点。第一去 URL 要在去特殊字符之前做否则链接里的字母和数字会残留下来当成噪声。第二OpenCC 的 t2s 转换依赖外部库如果你的数据集本来就是简体这行可以注释掉但只要是真实爬取的评价数据繁体出现的频率远比你想象的高。第三压缩连续标点的正则只针对中文常见标点如果你后续要做英文评价需要把英文字符和标点也加进去。3.2 分词与停用词jieba 的词典和用户词典怎么配中文情感分析绕不开分词。餐饮评价里有一批高频业务词比如“牛油锅底”“毛肚”“鸭肠”通用分词器很容易把它切成“牛油/锅底”或“毛/肚”这会让 CNN 的局部卷积核学到错误组合。解决办法是维护一份餐饮专用用户词典把门店招牌菜和常见食材名输进去让 jieba 优先按整词切。同时要小心停用词表的副作用。“不”这个字必须保留它是情感反转的核心“太”“比较”“有点”这些程度副词也要保留它们决定情绪强度。停用词表里只能删掉“的”“了”“啊”“吧”这类没有语义的虚词。我见过一份网上流传的通用停用词表把“不大”和“不太”都删了结果“味道不大行”被切成了“味道/行”直接被判成正向这就是典型的翻车现场。import jieba import pandas as pd # 用户词典每行一个词优先级高于默认词典 USER_DICT [ 牛油锅底, 菌汤锅底, 毛肚, 鸭肠, 黄喉, 麻辣烫, 等位, 上菜速度, 小料台 ] for word in USER_DICT: jieba.add_word(word) def tokenize(text: str) - list[str]: # 精确模式分词返回词列表 return [w for w in jieba.lcut(text) if w.strip()]分词后要不要过滤停用词我的建议是“少删多留”。只删除单字虚词和纯标点保留所有长度大于等于 1 的有效词。因为 CNN 的卷积核会自动学哪些词组合值得重点看你过早删词等于提前扔掉了信息。上面代码里lcut是 jieba 的精确模式分词返回一个 list输出后可以直接喂给后续的词表构建逻辑。3.3 将评论转成模型输入序列长度、词表与 embedding 初始化的选择模型吃不了汉字只能吃数字。标准做法是把分词结果映射成词索引然后做 padding 统一长度。序列长度这个超参数要按真实数据分布来定我通常先统计训练集所有评论的词数分布取 90 分位数的值作为MAX_LEN。餐饮评价大多在 30~100 个字之间设 80 比较稳妥如果你把序列设成 256大部分样本 80% 以上位置是 padding不仅浪费算力还会稀释真实信号。Embedding 初始化有两个选择随机初始化从零学或用预训练词向量。公开的腾讯中文词向量和百度百科词向量都能在网上下到但文件体积大、加载慢。我做过对比在 10 万级训练样本下随机初始化加足够训练轮数效果和预训练词向量差距在 1% 以内但样本量少于 1 万时预训练向量能明显拉高下限。如果本机内存紧张从零开始训练是更省事的选择。from tensorflow.keras.preprocessing.text import Tokenizer from tensorflow.keras.preprocessing.sequence import pad_sequences def build_sequences(texts: list[str], max_len: int 80): # 用 Tokenizer 构建词表num_words 控制词表大小超出部分按未知词处理 tokenizer Tokenizer(num_words15000, oov_tokenUNK) tokenizer.fit_on_texts(texts) sequences tokenizer.texts_to_sequences(texts) padded pad_sequences(sequences, maxlenmax_len, paddingpost, truncatingpost) return padded, tokenizer这里有两个参数直接影响模型效果。num_words15000意味着只保留词频最高的 1.5 万个词低频词全部归入UNK。词表设太大模型参数暴涨但低频词学习不充分设太小常用业务词可能落到未知词里所以我建议先按词频排序看一眼数据集再调。truncatingpost表示超长部分从尾部截断这个选择背后有讲究后面避坑章节会专门说。4. 模型构建与训练跑通 CNN-LSTM 的完整脚本与参数调整4.1 Embedding Conv1D 提取 n-gram 特征模型结构从输入层到输出层一共五块我把它们拆开说方便你照着调。第一块是 Embedding 层它把每个词的索引映射成稠密向量。第二个是 Conv1D一维卷积只在序列维度上滑动卷积核尺寸相当于 n-gram 的大小。kernel_size3 表示每次看 3 个连续词这能覆盖“不好吃”“量太少”这类三词组合如果你发现“服务态度特别好”这种五连词很关键可以加一个并行分支用 kernel_size5但参数规模也会涨。滤器数量 filters 决定卷积层学到多少种特征模式我一般起步设 128。这个数字不是越大越好我试过 256验证集指标没明显提升但模型推理时间翻了快一倍。Conv1D 之后接一个 GlobalMaxPooling1D从每个特征图里取最大值把变长序列压成固定长度向量这样 LSTM 拿到的就不是原始词向量序列而是 CNN 筛选后的“重点短语向量”计算压力小很多。4.2 LSTM 层与全连接分类头Dropout 和正则怎么设第三块是 LSTM 层。这里有个常见误解把 LSTM 的拼接方向理解成“把整个句子原文送给 LSTM”。实际上前面经过卷积和池化后序列长度已经大幅缩短LSTM 接收的是一个更紧凑的语义片段。LSTM 单元数units决定记忆容量文本分类任务 64 到 128 就够。超过 256 几乎必然过拟合尤其当训练集只有几万条样本时我后面会专门讲这个坑。第四块是 Dropout它是在训练时随机丢弃部分神经元输出防止模型死记训练集。位置有讲究LSTM 输出的 Dropout 层要放在全连接层之前同时 LSTM 内部可以开recurrent_dropout但注意它会把训练速度拖慢不少。全连接分类头用 softmax 输出三个类别的概率这就是第五块。from tensorflow.keras.models import Sequential from tensorflow.keras.layers import Embedding, Conv1D, GlobalMaxPooling1D, LSTM, Dense, Dropout from tensorflow.keras.optimizers import Adam def build_cnn_lstm(vocab_size: int, max_len: int, embed_dim: int 100): model Sequential() model.add(Embedding(input_dimvocab_size, output_dimembed_dim, input_lengthmax_len)) # 一维卷积128个卷积核每个核看3个连续词 model.add(Conv1D(filters128, kernel_size3, activationrelu)) # 全局最大池化从每个特征图里取最强信号 model.add(GlobalMaxPooling1D()) # LSTM 层64个单元捕捉句子的时序依赖 model.add(LSTM(units64, dropout0.3, recurrent_dropout0.2)) # 输出层3个类别softmax 归一化成概率 model.add(Dropout(0.3)) model.add(Dense(units256, activationrelu)) model.add(Dropout(0.3)) model.add(Dense(units3, activationsoftmax)) model.compile(optimizerAdam(learning_rate1e-3), losssparse_categorical_crossentropy, metrics[accuracy]) return model这个结构的顺序是一个经验总结卷积后的全局池化把特征图压成向量再进 LSTM而不是让 LSTM 直接吃卷积输出序列。这样做的直接好处是训练速度快了 30% 以上。global max pooling比average pooling更适合情感分析因为情绪信号往往集中在少数几个强烈的词上最大值能保留这种“最突出信号”。4.3 核心训练脚本与关键参数训练阶段的参数比网络结构更容易被人忽略也更值得反复实验。学习率是其中最敏感的一个1e-3 是常见起步值但如果损失在前几个 epoch 不降反升优先把学习率降到 3e-4而不是去改网络宽度。批量大小 batch size 影响梯度稳定性文本分类 32 到 64 都可以别超过 128否则模型在小数据集上收敛很不稳。早停 patience 设 3 轮比较合适也就是连续 3 轮验证集损失没有改善就停。完整训练脚本如下from tensorflow.keras.callbacks import EarlyStopping, ModelCheckpoint def train_model(model, x_train, y_train, x_val, y_val): callbacks [ EarlyStopping(monitorval_loss, patience3, restore_best_weightsTrue), ModelCheckpoint(best_model.keras, monitorval_accuracy, save_best_onlyTrue) ] history model.fit( x_train, y_train, batch_size64, epochs30, validation_data(x_val, y_val), callbackscallbacks, verbose1 ) return historyrestore_best_weightsTrue是后悔药开关早停时自动把权重回滚到验证集最优的那一步。训练时最好把验证集和测试集分开验证集用来调参测试集只在模型定稿后评测一次。如果你只有一个标注数据集把 8:1:1 切成训练、验证、测试三份切分时按门店或时间分组别随机洗牌后直接切否则同一个用户的多条评价可能同时出现在训练集和测试集里指标虚高不说线上表现和离线评估能差一大截。4.4 评估指标准确率、F1 与混淆矩阵怎么看分类任务的评估别只盯着准确率。餐饮评价的情感分布通常极端不平衡比如 70% 是好评20% 中评10% 差评。如果一个模型把所有评价全判成好评准确率都有 70%但这个模型对运营毫无用处。我常用的评估组合是宏平均 F1 加混淆矩阵。宏平均 F1 对每个类别单独算 F1 再求平均不会让多数类“带节奏”。混淆矩阵能明显看出哪一类容易被误分比如中评和负评经常混在一起说明中性样本的标注标准本身就不清晰。跑完训练后输出评估报告import numpy as np from sklearn.metrics import classification_report, confusion_matrix def evaluate_model(model, x_test, y_test): y_pred np.argmax(model.predict(x_test), axis1) print(classification_report(y_test, y_pred, target_names[neutral, negative, positive])) print(confusion_matrix(y_test, y_pred))看到负评被大量误判为中评先别急着改模型先抽 50 条误判样本看原文。很多时候是标注本身的问题比如“等了一个小时但服务态度很好”这种混合情绪样本人判起来都会犹豫模型判不准是正常的。这个时候的解决方向不是加模型复杂度而是做“负面情绪倾向”的二分类测试把注意力集中在差评上。5. 踩坑记录CNN-LSTM 情感分析在真实评论数据上的 5 个翻车点5.1 标签不平衡导致模型“永远预测好评”现象训练完模型验证集准确率很高但打印混淆矩阵发现负样本几乎全部被预测成了正向模型根本学不会输出负向类别。原因很直接训练集里好评占 70% 以上模型发现只要输出好评损失就能降到比较低负样本稀少导致的梯度被淹没。解决先在损失函数上做文章。给 sparse_categorical_crossentropy 传class_weight让负样本的损失权重更大。我通常把类别权重设为样本数占比的倒数再归一化比如好评中评差评 7:2:1权重就设成 1:3.5:7。这是成本最低的做法不用改网络结构。class_weight { 0: 1.0, # neutral 1: 3.5, # negative 2: 1.0 # positive若负样本极少可适当降低正向权重 } model.fit(x_train, y_train, class_weightclass_weight)5.2 分词器不一致导致预测时效果断崖现象训练时代码里用 jieba 分词后构建序列线上预测时没有加载用户词典或者 tokenizer 没做fit_on_texts结果新评论里出现大量UNK单条预测经常“翻车”。最典型的是“毛肚”被切成“毛”和“肚”模型识别不出任何情感信号。原因训练和推理的预处理必须走完全相同的管道。这是最容易被忽视的工程细节两个环境里 jieba 词典文件版本不一致都会改变 token 序列。解决把清洗、用户词典、分词、词表构建、padding 封装成一个类训练和推理都调用同一个实例并且把 tokenizer 和用户词典一起序列化保存部署时加载同一个文件。5.3 序列截断位置不对把关键情绪词截掉了现象用固定长度 80 截断部分长评论的尾部出现“强烈不推荐”“千万别来”这类强烈情绪词结果因为超出长度被截掉了模型输出概率判成中性。原因pad_sequences默认truncatingpre是从头部开始截断而我的原始数据里业务信息常在句尾。解决把截断方式改成truncatingpost保留开头部分或者反过来保留尾部。更稳妥的方案是切分前先做统计分析把每条评论按句号拆成短句只保留情感信息最密集的前三句再拼起来进模型。这样既控制长度又不丢关键情绪。5.4 LSTM 单元数过大验证集损失直接飙升现象把 LSTM units 从 64 调到 256 后训练损失一直在降但验证集损失在第 3 个 epoch 后不降反升而且升得很快。这是明显的过拟合信号。原因LSTM 参数量和 units 的平方成正比256 个单元在几万条评价数据上参数空间太大噪音都被记下来了。解决回到 units64 或 128同时把 Dropout 从 0.3 提到 0.4观察验证曲线是否重新变得平稳。还有一个容易忽略的细节Embedding 维度不要超过 200100 对中文短文本通常足够太高同样会造成参数膨胀。5.5 随机打乱泄露店铺信息测试集指标虚高现象按常规做法把数据集shuffleTrue打成训练集和测试集测试集准确率 93%但上线后对新评论预测准确率明显下降。原因同一个门店的多条评价高度相似随机打乱后相同门店的相似评价同时落进训练集和测试集测试集成了“开卷考试”。解决按门店 ID 分组切分数据。把所有门店分成 8:1:1 三份同一门店的评价全部落在同一份里保证测试集里的门店是模型没见过的。这个切分逻辑对大客户场景尤其重要因为同一家分店的评价用词高度同质化。6. 进阶把模型接到真实业务验证不是“能跑”而是“能用”6.1 用测试集人工抽检 50 条逐条看预测概率模型训练完先别急着看准确率。我会写一段随机抽样代码从测试集里抽 50 条评论把原文、真实标签、预测标签和三个类别的预测概率并排打印出来逐条人工过一遍。重点看两类样本一是预测概率接近 0.4/0.4/0.2 的模糊样本这类评论要么是表达含糊要么是标注标准本身有问题二是预测完全错误但原文在人类看来确实难判的样本比如“还行吧”“一般般”这类中性偏负的模糊表达。6.2 把模型导出成服务接口嵌入现有的后台评价流从“能跑”到“能用”的关键一步是把模型代码打包成接口。最轻量的做法是用 Flask 加载训练好的权重文件对外暴露一个POST /predict接口接收 JSON 格式的评论文本返回三个情感类别的概率。注意在接口内部把预处理类和数据模型一起加载避免每次请求都重走一遍 jieba 初始化那会慢到没法用。from flask import Flask, request, jsonify app Flask(__name__) app.route(/predict, methods[POST]) def predict(): data request.get_json() text data[comment] padded, _ build_sequences([text], max_lenMAX_LEN) prob model.predict(padded, verbose0)[0] labels [neutral, negative, positive] return jsonify({label: float(p) for label, p in zip(labels, prob)})这一步把模型变成团队里其他人也能调用的服务运营可以直接在后台把差评高亮置顶。如果评价量更大再考虑用 TensorFlow Serving 或 ONNX 部署但 Flask 起步足以验证线上效果。6.3 关于多模态情感分析的一个可行扩展方向当文本模型上线稳定后如果想进一步提升判断质量多模态情感分析是一个自然扩展方向。餐饮评价里常常出现“说实话菜品一般但环境很适合拍照”这种文本上偏中性但图片里全是精致食物的评价如果能结合用户上传的图片做视觉情感特征融合模型的理解能力会更强。代价是标注成本和数据采集链路都要升级。我的建议是先做好文本这条线跑通三个类别的准确率和线上抽检再谈多模态否则团队很容易陷在数据工程里。最后说一个我自己的习惯每次做完一个情感分析项目我都会保留一个固定的“回归测试集”里面是所有人工抽检过的难例。以后模型或预处理逻辑一改先跑一遍回归测试集看有多少条结果变了。这一步比任何 fancy 的评估报告都更能避免模型悄悄变坏。这个习惯帮我挡住了好几次“准确率没降但线上体验变差”的玄学问题。希望帮到你。本文还有配套的精品资源点击获取