企业官网建设流程全解析

简介：这是一份基于Python的情感分析系统完整源码包，专门面向自然语言处理初学者、Web后端开发者以及需要快速搭建文本情感分类服务的项目团队。系统覆盖数据清洗、模型训练、情感判别与Flask Web接口，能够对输入文本输出正向、负向或中性的分类结果，并附带情感标签、情感值与分类方式说明。压缩包共34个文件，以22个Python脚本为主体，并包含情感词表、配置文件、需求说明、Excel验证数据等辅助材料，整体大小仅1.6MB，目录结构清晰、易于本地部署与二次开发。目前已有77人学习浏览。除核心训练与预测模块外，资源还提供数据清洗脚本、在线/离线验证工具、情感词库、Web接口模块及基于SnowNLP的对比实现，可帮助读者掌握从原始非规整文本清洗、语料构建到模型训练与服务发布的完整链路，对课程设计、毕业课题或企业级情感分析原型开发均有直接参考价值。

1. 一个能直接调接口的情感分析系统：先看它能解决什么

做文本情感分析的人应该都经历过这个尴尬阶段：拿现成的库跑 demo 很爽，一放到自己的业务语料上就失灵。这套基于 Python 的情感分析系统源码，解决的正是这个场景。它不是只给你一个能返回正向、负向、中性标签的接口，而是把「语料清洗 → 模型训练 → 模型加载 → Flask 对外服务」整条链路都拆开摊在面前。压缩包里有训练脚本、预测脚本、Web 接口模块和一批客服场景的语料文件，可以直接从命令行跑通，也可以嵌入到已有的服务里。对做客服质检、舆情监控、评论打标的人，最省事的路径是先把现成接口跑通，再用自己的数据重新训练替换内置模型，省掉从零搭工程的时间。如果你只想要一个能出分数的 demo，这套代码反而偏重；但如果你想把情感分析真正接进业务，它的价值就在那些你没注意到的细节里。

2. 源码结构与数据流：从 txt 语料到 sentiment.marshal 的完整链路

在动手跑之前，先花几分钟把压缩包里的文件分类。很多人一上来就python xxx.py，跑完发现用的还是 SnowNLP 内置模型，就是因为没搞清楚哪些文件管训练、哪些管加载、哪些只是辅助验证。这个包的目录结构不算复杂，但混在一起看会让人误判入口。

2.1 文件分类：训练、预测、验证三块各有各的主心骨

先按用途把文件归成几组，运行的时候才不会拿错入口。

train.py 是训练的主入口，prepareTrainData.py 是它的前置步骤。emotionclassify.py 是分类核心，会被 Flask 接口和验证脚本同时引用。start_flask.py 负责拉起 Web 服务，deploy.py 则是在服务器上做部署时用的启动脚本，两者关系有点像开发模式和生产模式。common 目录里的 log.py 统一记录日志，textSimilarity.py 做文本相似度计算，主要用在数据清洗时剔除重复或高相似度的客服话术，避免同一句话在训练集里出现太多次导致模型偏置。

有一点容易让人迷惑：pos_53kf.txt和neg_53kf.txt看起来是原始语料，但直接拿去训练往往效果不好。源码里数据准备脚本的作用，就是把这两份原始对话转成真正可以进模型的干净语料。pos_words.txt和neg_words.txt是情感词典，训练时可以扩充特征，也可以在做规则兜底时直接查词。理解了这个分工，后面每一步都不会找错文件。

2.2 prepareTrainData.py 到底洗掉了什么：不要小看这一层

很多人在情感分析上翻车，翻得最多的不是模型不好，而是数据没洗干净。原始客服对话里混着大量系统消息、工单号、表情代码、HTML 残留，如果直接进贝叶斯分类器，模型学到的不是情感，而是这些噪声的模式。

prepareTrainData.py 这类脚本的核心，是一组正则替换规则。我一般会按照这个思路处理原始行：

import re def clean_line(raw: str) -> str: # 去掉 HTML 标签，例如 <br>、<span> raw = re.sub(r'<[^>]+>', '', raw) # 去掉表情代码，例如 [微笑]、[发怒] raw = re.sub(r'\[[^\]]*\]', '', raw) # 去掉 HTML 实体，例如 &amp; &nbsp; raw = re.sub(r'&[a-z]+;', '', raw) # 去掉英文和数字，客服数据里它们大多是单号、账号 raw = re.sub(r'[a-zA-Z0-9]+', '', raw) # 合并多余空白 raw = re.sub(r'\s+', ' ', raw).strip() return raw

逻辑说明：第一步先剥掉 HTML 标签，因为客服系统导出的聊天记录经常带富文本。第二步处理表情代码，这类数据里[微笑]这类标记其实有一定情感含义，但在清洗阶段通常先去掉，避免干扰统计特征。第三、第四步去掉英文数字，是因为客服对话里的订单号、链接地址没有情感信息，留在分词结果里只会变成低频噪声。最后一个\s+合并，是为了让语料干净整齐。

参数说明：正则表达式里的[^>]+表示匹配任意不是>的字符，&[a-z]+;用于匹配&开头、分号结尾的实体。如果你手里的数据包含中文状态下全角符号，可以在清洗函数里加一步raw = raw.replace('\u3000', ' ')。

比正则更重要的是「去除非人工对话」。53kf 这类在线客服渠道导出的文本里，会混入系统自动推送的欢迎语、离线留言提示、转人工通知。prepareTrainData.py 通常会用关键词过滤来处理：先把「【转人工】【系统消息】」这类标记直接丢弃，再用长度阈值筛掉过短的自动回复。我做过一次统计，不滤自动回复时训练出的模型，会把「请问有什么可以帮您」识别成强正向，因为这类句子在正向语料里反复出现。这个坑非常隐蔽，等上线后发现全评正向，回头查数据才找到原因。

2.3 emotionclassify.py 的分类逻辑：从概率到标签没那么简单

SnowNLP 的sentiments属性返回的是一个 0 到 1 之间的浮点数，代表正向概率。很多人以为大于 0.5 就是正向，但实际业务里这样做会把大量中性文本强行分到正负两边。

emotionclassify.py 里通常不是这样处理的，而是设置两个阈值，中间留一个中性区间：

def classify(text: str, pos_th: float = 0.6, neg_th: float = 0.4): from snownlp import SnowNLP score = SnowNLP(text).sentiments if score >= pos_th: label = '正' elif score <= neg_th: label = '负' else: label = '中性' return label, round(score, 4), 'snownlp_bayes'

逻辑说明：pos_th=0.6表示概率达到 60% 才认为是正向，neg_th=0.4表示低于 40% 才认为是负向，中间部分归为中性。这么做的好处是避免把「还不错吧」这类模棱两可的表达硬塞进某一类。

参数说明：这两个阈值不应该写死在代码里，而应该从 config.ini 读取。客服场景和电商评论场景的阈值差异很大：客服对话里用户措辞更急，阈值可以放宽到 0.55/0.45；评论场景用户表达更含蓄，阈值要收紧。

这个模块还负责记录分类方式，返回值里最后一个参数snownlp_bayes就是用来自证身份的——以后你换成了深度学习模型，这个字段能帮你区分线上请求到底走的是哪套逻辑。项目里的 test_snownlp.py 可以在改动阈值后快速跑一批样本看概率分布，我用它来确认新阈值没有把原本正常的负向文案推成中性。

3. 训练与部署实操：把自训练贝叶斯模型跑起来

从这一章开始可以按顺序抄作业了。整个训练链路是：准备环境 → 清洗语料 → 训练保存模型 → 验证效果。每一步都有明确的脚本入口，但如果不理解参数含义，很容易跑完不知道发生了什么。

3.1 环境准备：依赖装到什么程度才算够

先把 Python 依赖装好。这套源码的核心依赖是 Flask、snownlp 和 jieba，验证部分还要用到读取 Excel 的库。

pip install flask snownlp jieba openpyxl xlrd

逻辑说明：flask 负责提供 HTTP 接口，snownlp 是情感分析基础库，jieba 是 snownlp 默认的分词引擎，openpyxl 和 xlrd 用来读取 verify.xlsx 验证集。如果你只跑训练和离线验证，Flask 可以暂时不装，但项目脚本里有from flask import jsonify之类的引用，所以最好一次装齐。

建议在虚拟环境里执行，不要直接往系统 Python 里塞。我之前吃过一次亏，服务器上有一个旧版本的 snownlp，sentiment.train接口行为不一样，导致训练报错找不到handler属性。装完后可以用pip show snownlp确认版本，如果发现异常，先升级到最新版再继续。

目录方面，准备好这些文件：

pos_53kf.txt neg_53kf.txt pos_words.txt neg_words.txt config.ini train.py

config.ini里的model_path是训练产物要保存的位置，也是后面 Flask 加载模型的路径。我一般会把训练产物放在单独的models/目录下，避免和源码混在一起，方便git clean的时候不误删。

3.2 train.py：语料进入模型前必须分词

SnowNLP 的情感分类器是朴素贝叶斯，它的训练接口要求传入的每条句子不是字符串，而是分词后的词列表。这个细节非常关键，如果你直接把字符串传进去，训练出来的模型基本不能用。

train.py 的核心逻辑大致是这样：

import jieba from snownlp import sentiment def load_data(pos_path, neg_path): data, labels = [], [] for path, label in [(pos_path, 1), (neg_path, 0)]: with open(path, encoding='utf-8') as f: for line in f: line = line.strip() # 过滤过短和明显无意义的行 if len(line) < 2: continue # 这里用 jieba 分词，和线上预测时保持一致 data.append(jieba.lcut(line)) labels.append(label) return data, labels data, labels = load_data('pos_53kf.txt', 'neg_53kf.txt') sentiment.train(data, labels) sentiment.save('sentiment.marshal') print('训练完成，样本数:', len(data))

逻辑说明：load_data把正向语料标为 1，负向语料标为 0，这是朴素贝叶斯训练的标准标签格式。sentiment.train(data, labels)接收两个长度相同的列表，data里每一项是分词后的词列表，labels里每一项是对应的 0/1 标签。训练完成后sentiment.save('sentiment.marshal')把模型序列化到磁盘。

参数说明：len(line) < 2的过滤很重要。客服语料里经常有「嗯」「哦」「哈」这类单字回应，它们不是情感标签的好学习对象，放进训练集只会让模型对短句产生错误偏好。如果你手里的语料噪声比较多，可以把阈值提到 4，过滤掉「好的」「收到」这类短回复。

这里还有一个值得做的优化：pos_words.txt 和 neg_words.txt 是情感词典，虽然不直接参与贝叶斯训练，但我会把它读进来做特征扩展。具体做法是把词典里的词拼接到每条训练文本后面，相当于给模型注入先验的情感词特征。实测下来，在语料量只有几千条时，这个操作能让验证集准确率提升 2 到 3 个百分点。

训练完成后，你会在目录下看到sentiment.marshal文件。这个文件就是整个系统里最重要的资产，后续所有预测都会基于它。注意：如果训练后没有生成新文件，或者文件大小和初始的一致，马上检查是不是 save 路径没写对。

3.3 verify.py 与 verify_online.py：离线与在线两条验证路径

训练完不能直接上线，至少要过一遍验证。verify.xlsx 里是人工标注好的文本和标签，每行包含text和label两列。verify.py 读取这个文件，对每条文本调用分类函数，统计准确率。

import pandas as pd from emotionclassify import classify df = pd.read_excel('verify.xlsx') hit = 0 for _, row in df.iterrows(): label, score, method = classify(row['text']) if label == row['label']: hit += 1 print('准确率 %.2f%%' % (100.0 * hit / len(df)))

逻辑说明：这段脚本把 Excel 里的每行文本交给classify，拿返回的标签和人工标注比对。classify返回的是(label, score, method)三元组，我们只取 label 参与比对。

参数说明：pd.read_excel依赖 pandas 和 openpyxl，如果你不想装 pandas，用openpyxl的load_workbook也能读，但代码会啰嗦一些。验证集最好单独准备，不要用训练集里出现过的句子。我之前犯过一个错，把训练语料直接当验证集跑，准确率报 98%，上线立刻打脸。

verify_online.py 走的是另一条路径。它不直接调用 classify 函数，而是向已经启动的 Flask 服务发 HTTP 请求，验证的是「服务化之后的完整链路」：请求进来、参数解析、调用分类模块、序列化返回。这条路径能发现一些离线验证发现不了的问题，最常见的就是分类模块里生成了numpy.float64类型导致 JSON 序列化失败。所以我的习惯是：训练完先跑 verify.py 看模型效果，服务启动后再跑 verify_online.py 看链路通不通，两个都过了才往线上走。

4. Flask 接口封装：分词、情感值与 JSON 返回的完整链路

模型训练好后，接下来的任务是把它变成可以对外服务的 HTTP 接口。这一章围绕 start_flask.py 和 flask_module 目录展开，重点看 Blueprint 怎么切分、返回结构怎么设计、配置怎么热更新。

4.1 Blueprint 模块划分：为什么拆成 emotion_blueprint 和 config_blueprint

这个包的设计没有把所有路由塞进一个 app，而是用 Flask 的 Blueprint 按业务域拆分。emotion_blueprint 负责情感分类请求，config_blueprint 负责阈值和模型配置的读取与更新。

创建蓝图的代码如下，下面这段是 emotion_blueprint 的核心结构：

# flask_module/emotion_blueprint/__init__.py from flask import Blueprint, request from .emotionclassify import classify from common.log import logger from flask_module.result_json import ok, fail emotion_bp = Blueprint('emotion', __name__) @emotion_bp.route('/api/emotion', methods=['POST']) def emotion_api(): data = request.get_json(force=True) text = data.get('text', '') if not text: return fail('text 不能为空') label, score, method = classify(text) logger.info('text=%s label=%s score=%s', text, label, score) return ok({'text': text, 'label': label, 'score': score, 'method': method})

逻辑说明：Blueprint('emotion', __name__)声明了一个名为 emotion 的蓝图，@emotion_bp.route('/api/emotion', methods=['POST'])把 POST 请求绑定到emotion_api函数。request.get_json(force=True)表示即使请求头没写Content-Type: application/json，也尝试把请求体解析为 JSON。

参数说明：force=True是一把双刃剑。它能让调用方少写一个请求头，但如果传过来的是格式错误的字符串，解析会直接抛异常。我一般会保留force=True，因为在内部服务调用场景里，很多脚本用requests.post(url, data=json.dumps(payload))忘了写请求头，force=True可以省去这类低级报错。生产环境如果要严格一些，可以改成request.get_json(force=False)并捕获异常。

config_blueprint 的作用是让你不用重启进程就能调整阈值。它提供一个 GET 接口查看当前配置，一个 POST 接口更新情感阈值。更新阈值时要加一个线程锁，否则并发请求可能在更新过程中读到一半的配置值。源码里应该有类似threading.Lock()的逻辑，这是容易被忽略但很重要的细节。

4.2 返回结构：code、msg、data 三层别嫌多

接口返回格式我建议统一走 result_json.py，它封装了两个函数：ok和fail。这样做的好处是前端只需要判断一个code字段，不需要每写一个接口就重新约定错误格式。

from flask import jsonify def ok(data=None, msg='success'): return jsonify({'code': 0, 'msg': msg, 'data': data}) def fail(msg='fail', code=1): return jsonify({'code': code, 'msg': msg, 'data': None})

逻辑说明：ok返回code=0，业务层拿到的最终响应长这样：

{ "code": 0, "msg": "success", "data": { "text": "这款产品发货快，客服态度也很好", "label": "正", "score": 0.8732, "method": "snownlp_bayes" } }

参数说明：score在返回前一定要做一次float()转换。SnowNLP 内部计算概率时返回的是 Python 的 float，但如果你在 classify 里用了其他逻辑，可能会得到numpy.float64，Flask 的 jsonify 无法序列化这个类型，会直接报TypeError: Object of type float64 is not JSON serializable。result_json.py 里对 score 做了 round 处理，但为了保险，我习惯在 classify 返回前就强制转换。

实际调用方式很简单：

curl -X POST http://127.0.0.1:8300/api/emotion \ -H "Content-Type: application/json" \ -d '{"text":"漏发了一件，客服半天不回复"}'

返回的 score 会在 0.2 以下，label 为「负」。如果这个接口在浏览器里直接访问出现中文乱码，说明 Flask 返回 JSON 时开启了 ASCII 转义，需要在创建 app 后设置app.json.ensure_ascii = False，或者直接修改 Flask 配置。

4.3 config.ini：阈值、模型路径、服务端口都收敛到这里

后端最忌讳把参数 hard code 在代码里。这个项目的 config.ini 提供了一个统一的配置入口，我重点解释几个关键段。

[model] path = sentiment.marshal [threshold] pos = 0.60 neg = 0.40 [server] host = 0.0.0.0 port = 8300

参数说明：[model] path是训练产物的磁盘路径，[threshold] pos和neg对应第 2 章里的正负情感阈值，[server] host设置为0.0.0.0表示监听所有网卡，这样同一局域网的其他机器也能调用接口。端口默认建议改成 8300 而不是 Flask 默认的 5000，因为 5000 端口在部分系统上被其他服务占用概率很高。

代码里读取配置的一般姿势是：

import configparser config = configparser.ConfigParser() config.read('config.ini', encoding='utf-8') model_path = config.get('model', 'path', fallback='sentiment.marshal') pos_th = config.getfloat('threshold', 'pos', fallback=0.6) neg_th = config.getfloat('threshold', 'neg', fallback=0.4)

逻辑说明：getfloat会把字符串转成浮点数，fallback参数保证配置缺失时有一个默认值，不会直接抛异常。config_blueprint 的热更新接口，内部做的就是把新的阈值写进 config.ini，同时更新内存中的变量。注意不要只改文件不改内存变量，否则要等重启才生效，那就失去热更新的意义了。

5. 避坑与常见问题：五条能省一整天的踩坑记录

这一章全是真实发生过的问题，每条按「现象 → 原因 → 解决」的顺序来写。如果说前面是使用说明书，这里就是后悔药合集。

5.1 现象：训练完模型文件没变化，加载的还是内置模型

训练脚本跑完，日志也打印了样本数，但启动 Flask 后输入负面文本返回的分数还是很高。检查发现sentiment.marshal文件的时间戳根本没更新。

原因：sentiment.save('sentiment.marshal')保存的是单例sentiment对象，但 Flask 进程在启动时已经把这个模型加载到内存里了。训练完了不重启进程，或者训练脚本和 Flask 服务的模型路径不一致，都会导致线上还在用旧模型。另外，如果训练时data没有正确分词，保存出来的模型可能和旧模型几乎一样。

解决：训练完成后，确认磁盘上的模型文件大小发生了变化，再重启服务。服务启动时在日志里打印一行model loaded from sentiment.marshal，方便确认加载的是新文件。如果你用的是 deploy.py 部署，训练前先把正在运行的旧服务停掉，避免模型文件被进程占用。

5.2 现象：离线验证准确率高，线上新文本却乱标

verify.py 跑出来准确率有 90%，可一接线上真实文本，很多明显负面的抱怨被打成中性。

原因：验证集和训练集同源，都是 53kf 客服渠道导出的数据。模型学到的是这个渠道的说话习惯、术语和语气，而不是通用中文情感。线上文本里出现训练集没见过的口语化表达、品牌名、emoji 字符时，模型表现立刻下降。

解决：从线上真实请求里抽样 200 条做人工标注，单独存成一个online_check.txt，每运行一次就追加到验证集里。如果这套样本准确率低于 80%，先把错误文本回流到清洗流程，重新生成训练语料再训练。不要相信同源验证集的分数，它只能说明训练没有 bug，不能说明模型真的好用。

5.3 现象：所有结果都贴近 0.5，输出大量中性

接口能正常返回，但 score 永远在 0.45 到 0.55 之间，label 几乎全是「中性」，看不出区分度。

原因：正负训练样本数量严重失衡，或者训练集里有大量的短句、无意义话术。朴素贝叶斯在特征分布不均衡时，会倾向于输出接近先验概率的值。比如正向语料 5000 条、负向语料 800 条，模型默认给谁都往正向偏，但你又设置了 0.6 的正向阈值，于是大量样本落在中间区。

解决：训练前先统计两份语料的行数，把少的一方通过复制、改写、同义替换补齐到接近 1:1。另外检查清洗规则，如果很多句子长度小于 4 个字符，建议直接丢弃，不参与训练。我习惯在 train.py 里加一行print('pos=%d neg=%d' % (pos_cnt, neg_cnt))，一眼看出比例有没有问题。

5.4 现象：接口返回中文乱码或 JSON 序列化失败

curl 调用接口时，返回的label是\u6b63这样的转义字符，或者直接报TypeError: Object of type float64 is not JSON serializable。

原因：Flask 的默认 JSON 配置是ensure_ascii=True，所有中文都会被转成 unicode 转义；报序列化错是因为 score 是numpy.float64，不是 Python 原生 float。

解决：在创建 Flask 实例后加两行配置：

app = Flask(__name__) app.json.ensure_ascii = False

同时在 classify 函数里，返回前把 score 转为原生类型：

score = float(round(score, 4))

5.5 现象：deploy.py 启动后端口被占用，配置不生效

运行 deploy.py 报Address already in use，或者明明改了 config.ini 里的端口，启动日志显示还是 5000。

原因：旧服务没有完全退出，端口被残留进程占着。配置不生效则是因为代码里在读取 config.ini 之前，已经用默认值创建了 Flask app，端口被硬编码在启动语句里。

解决：启动前先查端口：

ss -lntp | grep 8300

找到占用进程用kill -9 PID清掉，或者换一个端口。配置要在创建 app 之前读取，保证app.run(host=cfg_host, port=cfg_port)用的是配置文件里的值。启动日志里特意打印一行当前监听的地址和端口，看起来是小事，排查问题时能省十分钟。

6. 进阶用法：把黑匣子打开，做一次真实文本的对比验证

到了最后这步，模型已经能跑通，接口也能返回分数。但「能跑」不等于「可靠」。我最后习惯做的一件事，是把 SnowNLP 内置模型和自训练模型拉到同一批真实文本上做对比。test_snownlp.py 这个脚本就适合干这个。

先建一个发送请求的小脚本，把同一段文本分别发给内置模型和自训练模型，记录分数差异：

from snownlp import SnowNLP from emotionclassify import classify samples = [ "发货速度快，包装很仔细", "东西坏了联系两天没人管", "还行吧，凑合用", ] for s in samples: builtin = SnowNLP(s).sentiments custom, score, method = classify(s) print( "文本: %s\n内置模型分数: %.3f\n自训练分数: %.3f\n标签: %s\n" % (s, builtin, score, custom) )

逻辑说明：SnowNLP(s).sentiments用的是 snownlp 自带的情感模型，classify(s)走的是你训练好的模型。两个模型对同一句话给出不同分数时，别急着说哪个准，先看差异模式。

我常用的分析维度是把 200 条线上文本分成三档：综合评分、正向召回、负向召回。只看综合准确率会掩盖一个问题：模型可能把所有句子都判成正向，综合准确率也还不错，但真正需要关注的负面投诉全漏了。所以我会额外统计预测为「负」的样本里，人工标注确实为负的比例。

对比结果可以做成一个简表：

参数说明：分界线不是固定 0.5。如果内置模型在「凑合用」上打分 0.47，自训练模型打到 0.52，说明你的语料让模型对这类中性表达更宽容。这时候可以再把 config.ini 里的pos阈值从 0.6 微调到 0.65，把中性区间拉大一点，减少误判。

我一开始也是只看准确率一个数，结果验证集涨了 5 个点就以为自己行了。后来一个线上反馈提醒我，准确率 95% 的模型对真正重要的负面句可能全漏了。从那以后，我每次换语料都会强制走一遍「线上抽样回验」：抽 200 条真实文本跑接口，先不看准确率，先看标签分布和错例分布，确认没有一边倒的情况，再决定要不要上线。这个方法看起来笨，但每次都能在正式部署前发现问题，希望帮到你。

本文还有配套的精品资源，点击获取