Seq2seq+LSTM+Attention：聊天机器人情绪检测系统实战

简介这是一份用于毕业设计或NLP入门实战的聊天机器人情绪检测项目资源面向计算机相关专业学生及自然语言处理爱好者解决在Seq2seq框架下融合LSTM与Attention机制实现智能对话并同步完成用户情绪状态初步检测的需求。技术栈包括TensorFlow2.0Keras、HTMLVueAjax项目从文本预处理、模型构建与训练、抑郁分类模型训练到网页设计与交互均有覆盖。资源共45个文件包含Python源码、Jupyter Notebook训练与推理脚本、已训练好的h5模型与pkl词表文件、前端html模板、图片及数据集等压缩包大小约66.81MB目录结构清晰便于定位核心代码。借助带标签数据和分类模型可进行文本抑郁检测用户在网页对话过程中即可获得情绪判断反馈适合作为毕业设计完整方案或入门NLP项目的实战参考。目前已有191人学习具备一定的参考与复用价值。1. 聊天机器人 情绪检测一个对话链路里跑两套模型拿到这份毕设项目时我第一时间跑完了整套流程发现它最值钱的地方不是能闲聊而是把 Seq2seq LSTM Attention 的生成式对话模型和文本抑郁分类模型叠在了同一个服务里用户在 Vue 写的前端页面发一句消息后端 Flask 先让对话模型生成回复同时把这句话喂给情绪检测模型输出一个抑郁倾向概率。qingyun.tsv 青云语料做训练数据lstm_java_total.h5 和 Word2Vec_java.pkl 都是训练好的产物从 chatbot_train.ipynb 到 chatbot2_inference_Attention.ipynb 的链路可以直接复现不是只给 demo 的半成品。想快速跑通 NLP 完整毕设、或者想研究情绪检测从数据处理到网页呈现全流程的人这份代码几乎不用改就能作为蓝本。2. Seq2seq LSTM Attention 架构拆解编码器状态、权重计算与参数选型2.1 为什么是 Seq2seq LSTM 而不是直接上 Transformer先回答一个拿到项目的人都会问的问题现在生成式对话不都流行 Transformer 和预训练模型吗为什么这套毕设还在用 Seq2seq LSTM因为毕设场景有很现实的约束语料量级只有十万级没有大规模 GPU需要在网页端实时返回结果答辩时还要能把每个参数讲清楚。LSTM 在这四个约束下都很稳显存占用低训练一个 epoch 也就几分钟推理时单句响应在 CPU 上也能跑到百毫秒级而且梯度路径、门控机制、状态向量这些概念在论文里都好画图、好解释。我一般会把 encoder 和 decoder 都设成单层 LSTMunits 取 256embedding 用 Word2Vec_java.pkl 里预训练好的 200 维向量做初始化。这里有个常见的误解以为 units 越大效果越好。实际上在十万级的中文闲聊语料上512 units 的收益非常有限训练时间却翻倍256 是性价比很高的折中。项目里给的 lstm_java_total.h5 是训练完整的权重文件如果你不打算重新训练直接加载这个权重就能进推理阶段对机器几乎没有要求。选型理由还可以补一条情绪检测模块本身也是一个文本分类模型和对话模型共享同样的 embedding 空间和序列 padding 方式这样两个模型在服务端可以共用一套预处理函数代码量少很多。这一点在你做系统设计说明时是很好的切入点。2.2 Attention 权重怎么算从编码器输出里挑重点这个项目叫改进的 Seq2seq 模型改进点就落在 Attention 上。传统的 Seq2seq 在 decoder 每一步只能看到 encoder 最后一步的隐藏状态长句子前面说过的信息早就被压扁了加了 Attention 之后decoder 在生成第 t 个词时会把 encoder 所有时间步的输出拿出来做一个加权和权重越大说明这个源词和当前生成位置越相关。这个加权过程在 Keras 里封装成一个自定义 Layer 时核心计算就三行先算 score然后过 softmax 得到权重最后拿权重对 encoder outputs 做加权求和。写出来大概是这个样子import tensorflow as tf from tensorflow.keras.layers import Layer class AttentionLayer(Layer): def __init__(self, **kwargs): super(AttentionLayer, self).__init__(**kwargs) def build(self, input_shape): # input_shape: [(batch, seq_len, hidden), (batch, hidden)] self.W self.add_weight( nameatt_weight, shape(input_shape[0][-1], input_shape[0][-1]), initializerglorot_uniform, trainableTrue ) self.b self.add_weight( nameatt_bias, shape(input_shape[0][-1],), initializerzeros, trainableTrue ) super(AttentionLayer, self).build(input_shape) def call(self, inputs): # encoder_out: (batch, seq_len, hidden) # decoder_h: (batch, hidden) encoder_out, decoder_h inputs # 1. 计算 score把 encoder_out 投影到 decoder 的隐状态空间 score tf.tanh(tf.tensordot(encoder_out, self.W, axes[2, 0]) self.b) # 2. 用 decoder 当前隐状态做打分得到每个源词的重要程度 score tf.reduce_sum(score * tf.expand_dims(decoder_h, 1), axis-1) weights tf.nn.softmax(score, axis-1) # 3. 加权求和得到 context 向量 context tf.reduce_sum(encoder_out * tf.expand_dims(weights, -1), axis1) return context, weights这段代码里最值得讲的是第二步score 是 (batch, seq_len, hidden) 的中间结果把 decoder_h 扩展一个维度后做逐元素相乘再求和实际是在做decoder 当前状态和每个源词隐藏状态的相似度打分softmax 之后 weights 就是概率分布可以看到模型每生成一个词时把注意力放在了哪个源词上。context 向量最后会拼接到 decoder 的输入里和词嵌入一起喂给 LSTM。训练时这个 Layer 的参数是参与反向传播的这就是改进的三个字的落点。2.3 核心参数表从词表维度到束搜索宽度把这份项目里需要手动调的参数整理成了一张表照着设基本不会翻车参数推荐值说明embedding_dim200必须等于 Word2Vec_java.pkl 的向量维度lstm_units256encoder/decoder 统一用 256别盲目加大max_len20中文闲聊句子长度集中在 20 字以内截断这里性价比最高batch_size128显存不足就降到 64learning_rate1e-3 起衰减到 1e-4Adam 优化器下这个区间比较稳beam_width5推理阶段只在带 Attention 的版本里用提示embedding_dim 必须和 Word2Vec_java.pkl 的向量维度保持一致否则加载预训练词向量时会直接维度报错。max_len 这个参数很多人不注意但它是预处理脚本 get_data.ipynb 里最先写死的东西。qingyun.tsv 里长句子不少如果 max_len 设成 50padding 量剧增LSTM 的训练时间肉眼可见地变长设成 20 又要注意推理时用户输入超长要截断。我习惯先用一个脚本统计语料长度分布取 90 分位数作为 max_len比拍脑袋定值科学得多。3. 语料预处理与词表构建繁体转简体、Word2Vec 对齐与 padding 细节3.1 qingyun.tsv 的原始格式和脏数据长什么样这份项目用的训练语料是 qingyun.tsv这是做中文闲聊对话很常见的青云语料格式是标准的问题 \t 回答每行一对。但直接用会出问题语料里混着大量繁体中文、全角标点和网址。最典型的现象是你跑完分词一看词表发现我们和我們同时存在两个词各占一个词表位置互相之间没有任何共享信息这对十万级语料来说是很严重的词表浪费。项目里 language/zh_wiki.py 和 langconv.py 这两个文件就是为这个准备的。zh_wiki.py 是繁简词条映射表langconv.py 是转换器实现用 Converter(zh-hans).convert() 就能把整句繁体转成简体。我做预处理时习惯把这个转换放在最前面先转简再去处理标点顺序反了的话很多全角符号会影响转换结果。3.2 清洗脚本简繁转换、符号过滤与长度截断get_data.ipynb 里干的事可以浓缩成下面这个 清洗函数import re from language.langconv import Converter def clean_sentence(s): # 1. 繁体转简体必须在标点处理之前做 s Converter(zh-hans).convert(s) # 2. 去掉网址、用户、多余空白 s re.sub(rhttp\S|www\.\S, , s) s re.sub(r\w, , s) # 3. 只保留中英文、数字和常用中文标点 s re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9。…、], , s) # 4. 合并连续空白 s re.sub(r\s, , s).strip() return s第 1 步放在最前面是有原因的langconv 的转换依赖对原字符串的字符级解析如果先删掉了特殊符号再接转换部分繁体词条的匹配会失败。第 3 步的白名单正则要按你自己的需求调如果语料里有大量英文缩写就把英文保留下来如果只是纯中文闲聊可以连英文字母一起过滤掉。清洗完之后还要做一次空样本过滤。青云语料里有些行在清洗后变成空字符串这类数据必须删否则训练时模型学到的是空输入映射到空输出非常污染 loss。同时超过 max_len 的句子要截断截断我一般取前 max_len 个字符而不是后截断因为中文对话的有效信息往往在句首。3.3 词表对齐检查word_to_index 和 Word2Vec 的交集命中率项目里有两个容易混淆的文件vocab_bag.pkl 和 word_to_index.pkl。前者是词袋集合后者是词到整数 id 的映射字典。构建好词表后接下来要做的是把 Word2Vec_java.pkl 里的向量填进 embedding 矩阵。这里 90% 的坑出现在两个词表的 key 不统一vocab_bag.pkl 里存的是分词后的词Word2Vec_java.pkl 里存的也是词但有一方没做简繁转换或者有一方过滤掉了低频词最后交集命中率低得可怜。我一般会写一段检查代码先把命中率打出来再决定要不要继续训练import pickle import numpy as np vocab pickle.load(open(vocab_bag.pkl, rb)) w2v pickle.load(open(Word2Vec_java.pkl, rb)) embedding_dim 200 embedding_matrix np.random.uniform(-0.05, 0.05, (len(vocab), embedding_dim)) hit 0 for i, w in enumerate(vocab): if w in w2v: embedding_matrix[i] w2v[w] hit 1 print(vocab size:, len(vocab)) print(hit rate: {:.2%}.format(hit / len(vocab)))hit rate 低于 60% 说明两边词表存在明显的预处理差异最可能的原因就是繁体没转干净。我遇到过最离谱的一次是 hit rate 只有 12%查了半天发现 Word2Vec 训练时用的分词工具和构建 vocab_bag.pkl 时用的分词工具不是同一个词被切成了不同粒度这个只能重新对齐分词方式没有捷径。正常干净的语料上命中率应该在 75% 以上剩下的低频词用随机初始化兜底即可。4. 模型训练与推理Teacher Forcing、注意力解码与抑郁分类模型4.1 训练主流程Embedding、LSTM 与 Dense 的配置训练部分的核心文件是 lstm.py 和 train.py。lstm.py 负责任务train.py 负责组织数据。Keras 里搭 Seq2seq 模型最关键的一点是训练阶段的 decoder 输入和推理阶段不一样训练时要让 decoder 看到真实的目标词而不是自己上一步生成的词这种策略叫 Teacher Forcing。整个训练模型的结构可以简化成这样from tensorflow.keras.layers import Input, Embedding, LSTM, Dense from tensorflow.keras.models import Model lstm_units 256 vocab_size 50000 embedding_dim 200 max_len 20 # encoder encoder_inputs Input(shape(max_len,), nameencoder_inputs) encoder_embedding Embedding(vocab_size, embedding_dim, mask_zeroTrue)(encoder_inputs) encoder_lstm LSTM(lstm_units, return_stateTrue, nameencoder_lstm) encoder_outputs, state_h, state_c encoder_lstm(encoder_embedding) encoder_states [state_h, state_c] # decoder decoder_inputs Input(shape(max_len,), namedecoder_inputs) decoder_embedding Embedding(vocab_size, embedding_dim, mask_zeroTrue)(decoder_inputs) decoder_lstm LSTM(lstm_units, return_sequencesTrue, return_stateTrue, namedecoder_lstm) decoder_outputs, _, _ decoder_lstm(decoder_embedding, initial_stateencoder_states) decoder_dense Dense(vocab_size, activationsoftmax, nameoutput_projection) output decoder_dense(decoder_outputs) model Model([encoder_inputs, decoder_inputs], output) model.compile(optimizeradam, losssparse_categorical_crossentropy, metrics[accuracy]) model.summary()两个细节值得说。第一encoder_lstm 没有开 return_sequences因为我们只想要最后一步的隐藏状态来初始化 decoderdecoder_lstm 必须开 return_sequences因为每一步都要输出一个词的概率分布。第二loss 用的是 sparse_categorical_crossentropy 而不是 categorical_crossentropy标签是词 id 的整数而不是 one-hot能省下一大块内存vocab_size 是五万的场景下这个区别很实在。mask_zeroTrue 也别忽略。padding 出的 0 在 embedding 层会被 mask 掉LSTM 在计算时不把 padding 位置当真实输入这样 loss 不会把预测出 padding当作错误惩罚收敛会快不少。训练时的 batch_size 推荐 128用 ModelCheckpoint 每个 epoch 保存一次EarlyStopping patience 设 3 到 5 个 epoch。4.2 带 Attention 和不带 Attention 的推理差异项目里同时给了两个推理 notebookchatbot_inference_non-Attention.ipynb 和 chatbot2_inference_Attention.ipynb这个对比对理解模型很有帮助。不带 Attention 的推理decoder 每一步只有一个 LSTM 状态向量作为上下文长句生成到后半段时早期信息基本丢失回答经常跑偏。带 Attention 的推理每一步都会重新计算 encoder 所有位置输出的加权和解决了长句遗忘的问题。这两种推理模式代码结构上有个关键差异不带 Attention 的版本 decoder 初始状态直接复用 encoder 的最终状态带 Attention 的版本还要把 encoder_outputs 作为 Attention 层的输入在每一步 decode 时动态计算 context 向量拼进去。这里我建议你直接跑项目里两个 notebook 对比同一句输入实际体验比看代码更直观。推理阶段我还会在生成时加一个长度控制防止模型无限输出。常见的做法是设置最大生成长度并加上 EOS 停止符的判断一旦预测出 EOS 就停止没预测到但到达最大长度也强制停止。4.3 抑郁分类模型的装配与初步预测情绪检测部分是一个独立的文本二分类模型项目里 model/W--184-0.5949-.h5 就是训练好的权重文件按命名惯例 184 是训练轮数0.5949 是验证集上的某个分数确实不算高所以后面接阈值校准时要认真对待。和它配套的 pad_question.npy 和 answer_o.npy 是已经 padding 好的输入序列和标签数组加载后直接就能复现训练数据import numpy as np from tensorflow.keras.models import load_model # pad_question.npy: 预处理并 padding 后的输入序列 # answer_o.npy: 对应的标签0 表示正常1 表示有抑郁倾向 x_train np.load(pad_question.npy) y_train np.load(answer_o.npy) emotion_model load_model(model/W--184-0.5949-.h5) loss, acc emotion_model.evaluate(x_train, y_train, verbose0) print(emotion model acc:, acc)这里要提醒一句加载这个模型前最好也确认一下它是不是自定义结构。如果训练时用了 Attention 或其它自定义层load_model 时同样要传 custom_objects具体报错和处理放到下一章说。这个分类模型的输入和对话模型一样是词 id 序列所以预处理函数是共用的这也是为什么服务端代码可以很简洁。5. 跑通项目必看的 5 个坑自定义层加载失败、词表错位与阈值误报5.1 Keras 加载 .h5 直接报 Unknown layer: Attention现象执行 load_model(model/lstm_java_total.h5) 时抛 ValueError: Unknown layer: Attention。原因Keras 在加载模型权重时需要把模型结构也反序列化出来。但 AttentionLayer 是自定义类序列化文件里只存了类名Keras 不知道这个类从哪导入所以报错。解决加载时显式声明自定义层from tensorflow.keras.models import load_model model load_model( model/lstm_java_total.h5, custom_objects{Attention: AttentionLayer} )这段代码里的 AttentionLayer 要和训练时用的类定义完全一致包括类名和参数。如果你把训练和推理写在不同文件里一定要把 AttentionLayer 的定义复制到推理文件顶部不要偷懒只写一个 import。5.2 Word2Vec 词向量装进去后大量随机初始化现象训练 loss 降得慢几个 epoch 后 BLEU 或者回答质量还是上不来检查 embedding 矩阵发现大片随机噪声。原因词表交集命中率低。vocab_bag.pkl 里有一半的词在 Word2Vec_java.pkl 里查不到这些词只能随机初始化而常见的低频词恰恰是闲聊里最影响观感的名词和语气词。解决先跑第 3.3 节的命中率检查脚本。如果命中率低于 60%检查两边的预处理流程重点看繁体转换方式和分词器是否一致不要急着调模型结构。5.3 繁体语料没转干净回答全是嗯啊现象生成回复质量尚可但代词和人称经常乱套或者某些输入直接产生不太寻常的字符。去词表里一查同一批词有两个写法占两个 id。原因qingyun.tsv 本身含繁体跳过 langconv 直接初始化词表。这类问题在对话型任务里特别隐蔽因为 10% 的错字不影响句子通顺度但严重影响 embedding 的学习效率。解决预处理必须跑一遍 clean_sentence 里的 Converter(zh-hans).convert()之后重新构建词表和 Word2Vec再训练或者重新生成 embedding_matrix。没有捷径只能重跑数据管线。5.4 训练 loss 正常推理时答非所问现象训练集上 loss 稳定下降但推理时模型生成的句子不通顺甚至一个词循环重复。原因典型的 Teacher Forcing 与自回归的差距。训练时 decoder 每一步输入是真实词推理时输入的是自己上一步生成的结果一旦第一步生成错后续全错错误像滚雪球一样积累。解决推理时用 beam searchbeam_width 取 5每次保留分数最高的 5 个候选序列最后选整体概率最高的。同时加一个长度惩罚防止模型倾向于生成短句。这个改动在带 Attention 的推理版本里通常能明显提升回复质量。5.5 抑郁检测阈值直接用 0.5误报率高得离谱现象用户随便聊两句今天好累就被标成抑郁倾向前端弹预警体验很糟。原因情绪检测模型的验证集分数只有 0.59 左右本身区分度就不高而且负样本正常闲聊远多于正样本抑郁倾向文本模型预测分数整体偏低0.5 这个默认阈值在偏斜分布上不适用。解决先跑一遍验证集画出 PR 曲线找曲线拐点作为阈值而不是用 0.5。同时把判断逻辑从单句超阈值改成连续 3 句超阈值才提示这样能过滤掉大量偶然性波动。这两条改完实际误报率能下降一半以上。6. 把情绪检测接进聊天流程Flask 接口、阈值校准与冒烟测试6.1 Flask 路由里同时挂聊天与检测接口server.py 是整个系统的心脏前端的 newchat.html 通过 Ajax 把用户输入发过来后端在同一个接口里完成两件事生成回复 情绪打分。接口设计成 JSON 进出前端拿数据后直接把分数渲染在页面上逻辑非常清楚from flask import Flask, request, jsonify app Flask(__name__) app.route(/chat, methods[POST]) def chat(): data request.get_json() msg data.get(msg, ) # 1. 对话模型生成回复 reply seq2seq_model.generate(msg, beam_width5) # 2. 情绪检测模型打分 score emotion_model.predict_one(msg) # 3. 连续多句加权判断降低单句误报 history.append(score) if len(history) 10: history.pop(0) avg_score sum(history) / len(history) flagged avg_score THRESHOLD and len(history) 3 return jsonify({ reply: reply, depression_score: float(score), flagged: flagged }) if __name__ __main__: app.run(host0.0.0.0, port5000, debugFalse)注意第 3 步里我用了一个简单的滑动窗口只取最近 10 句的平均分。这样设计的原因很直白情绪判断本来就应该是趋势判断一个人的情绪状态不会因为一句话就定性。这个逻辑在答辩时可以展开讲比单纯调阈值有说服力得多。6.2 阈值校准该怎么定不要拍脑袋定阈值。我的习惯是拿验证集里所有预测分数画一条 PR 曲线然后看我们到底更怕误报还是更怕漏报。对抑郁检测这个场景我倾向宁可不报也别让正常用户被反复问你还好吗所以阈值我会往高调比如 0.7 左右叠加连续 3 句条件。前端拿到的 flagged 字段就是做弹窗提示用的正常聊天几乎触发不到。6.3 一条快速验证链路的冒烟测试改完后端千万别直接开前端慢慢试。我会先写一个最简陋的冒烟测试脚本确认接口通、模型能出结果再碰页面import requests def smoke_test(): r requests.post( http://localhost:5000/chat, json{msg: 最近总是失眠感觉压力好大} ) res r.json() assert reply in res, missing reply assert depression_score in res, missing score print(reply:, res[reply]) print(score:, res[depression_score]) if __name__ __main__: smoke_test()这个脚本不需要断言分数必须大于多少只要保证接口返回完整就够了阈值是不是合理另外用验证集去调。从那以后我每次碰这种多模型服务都强制自己先写这样一个 20 行的冒烟脚本不跑通不碰前端省下的调试时间远比写脚本的时间多。希望这个习惯对你有参考价值希望帮到你。本文还有配套的精品资源点击获取