简介这是一套面向计算机相关专业学生与初学者的机器学习实战项目以商品评论分析为主题将网络爬虫与文本情感分析两条技术线完整串联。项目通过selenium爬取京东评论并针对淘宝反爬机制采用已有链接抓取策略情感分析同时实现情感词典与SnowNLP两种方案其中SnowNLP在准确率与召回率上表现更优最终借助tkinter构建图形界面实现链接解析、评论表格展示、词云生成以及好评差评数量统计的完整流程。资源包共906个文件以401个py源码、392个pyc编译文件、25个pyd扩展及17个exe可执行程序为主另含csv数据集、txt说明、jpg截图与xml配置等压缩包约18.79MB。已有392人学习下载。代码均经测试运行成功适合作为课程设计、毕业设计或项目立项演示的参考模板也可在此基础上修改扩展用于学习爬虫与情感分析的工程化落地。1. 商品评论分析系统从爬到的脏数据到能上线的模型中间隔着什么电商运营每天面对几千条新评论靠人工翻页看不过来这是最朴素的痛点。基于机器学习的商品评论分析系统核心就做三件事把评论爬下来、把情感倾向判出来、把结果聚合成能看的报表。听起来像是一个标准的 NLP 入门项目但真正动手做的人会发现从原始评论到可用的分类模型中间隔着一堆琐碎工程问题——中文分词边界、类别极度不均衡、短文本特征稀疏、模型上线后的推理延迟。这套系统适合两类人一是想拿一个完整项目练手机器学习全流程的开发者二是需要快速搭一套评论监控原型的团队。源代码和文档说明的价值不在于代码多复杂而在于它把数据清洗、特征工程、模型训练、接口封装这条链路完整串了一遍让你能看到每个环节的真实输入输出长什么样而不是只跑一个 sklearn 的 demo。2. 评论数据从哪来、怎么洗爬取与预处理的工程细节2.1 评论数据的采集边界与合规底线做评论分析第一步永远是数据。常见做法是用公开电商平台的商品页做采集但这里有一条硬边界只采公开可见的评论文本和评分不碰用户昵称、头像、订单号等任何可关联到个人的字段。我一般会在采集脚本里直接过滤掉这些列只保留review_text、rating、timestamp、product_id四个字段。采集频率也要控制单商品页请求间隔不低于 2 秒避免给对方服务器造成压力。如果你只是做本地实验更稳妥的方式是用公开评论数据集比如电商评论语料或酒店评论语料这些数据已经脱敏拿来直接跑通流程更省事。采集下来的原始数据通常是 JSON 或 CSV字段命名混乱、编码不统一。我见过最离谱的一份数据里同一列既有 UTF-8 又有 GBK 编码的文本直接读进来就是乱码。所以第一步不是急着分词而是统一编码和字段名。import pandas as pd # 读取原始评论数据强制指定编码避免乱码 df pd.read_csv(raw_reviews.csv, encodingutf-8, on_bad_linesskip) # 统一字段名只保留分析需要的列 df df.rename(columns{ content: review_text, score: rating, create_time: timestamp, item_id: product_id }) # 丢弃评论内容为空或评分缺失的行 df df.dropna(subset[review_text, rating]) # 评分统一转为整数过滤掉异常值 df[rating] pd.to_numeric(df[rating], errorscoerce) df df[df[rating].between(1, 5)] print(f清洗后剩余 {len(df)} 条评论) print(df[rating].value_counts().sort_index())这段代码做了四件事指定编码读取、重命名字段、丢弃关键字段缺失的行、把评分转成数值并限定在 1 到 5 之间。参数上on_bad_linesskip是为了跳过格式错乱的行宁可少几条数据也不要让整个读取过程崩掉。errorscoerce会把无法转成数字的值变成 NaN后续 dropna 或过滤时自然被剔除。跑完这一步你至少能得到一份字段干净、评分可用的评论表。2.2 中文评论清洗去噪、分词与停用词处理中文评论的脏法很有特色一堆表情符号、重复标点、拼音缩写、颜文字还有“好评”“差评”这种和情感无关但高频出现的词。清洗的目标不是把文本变得多干净而是让分词器能正确切出有意义的词。我一般按这个顺序处理先去 HTML 标签和 URL再统一标点然后分词最后去停用词。import re import jieba # 加载停用词表每行一个词 with open(stopwords.txt, encodingutf-8) as f: stopwords set(line.strip() for line in f if line.strip()) def clean_text(text): # 去掉 HTML 标签 text re.sub(r[^], , text) # 去掉 URL text re.sub(rhttp\S, , text) # 只保留中文、英文和数字其余替换为空格 text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9], , text) # 合并连续空格 text re.sub(r\s, , text).strip() return text def tokenize(text): words jieba.lcut(text) # 过滤停用词和单字 return [w for w in words if w not in stopwords and len(w) 1] df[clean_text] df[review_text].apply(clean_text) df[tokens] df[clean_text].apply(tokenize) # 看一下处理前后的对比 for i in range(3): print(原始:, df[review_text].iloc[i][:60]) print(分词:, df[tokens].iloc[i][:15]) print(---)clean_text里的正则[^\u4e00-\u9fa5a-zA-Z0-9]是关键它把中文、英文、数字之外的所有字符都替换成空格表情符号和特殊标点自然被清掉。tokenize里过滤单字是因为中文单字歧义太大“的”“了”“好”单独出现对分类贡献很小反而增加特征维度。停用词表建议用哈工大或百度的公开版本再根据你的数据补充“物流”“客服”“宝贝”这类平台高频但情感中性词。这一步做完每条评论就变成了一个词列表可以直接喂给特征提取器。注意分词前不要做词干化或去复数中文没有这套规则强行套英文预处理流程只会引入噪声。3. 特征工程与模型选型为什么 TF-IDF 加线性模型仍然是评论分析的首选基线3.1 从词袋到 TF-IDF短文本特征怎么提才不稀疏评论数据的特点是短平均长度可能就二三十个字。这种短文本用词袋模型会非常稀疏一万条评论可能产生几万个特征维度但每条评论只覆盖其中几十个。TF-IDF 的好处是能压制高频无意义词的权重同时保留有区分度的词。在 sklearn 里TfidfVectorizer可以直接接在分词结果后面但要注意几个参数。from sklearn.feature_extraction.text import TfidfVectorizer # 把分词结果拼回字符串TfidfVectorizer 需要字符串输入 df[token_str] df[tokens].apply(lambda x: .join(x)) vectorizer TfidfVectorizer( max_features5000, # 只保留权重最高的 5000 个词 ngram_range(1, 2), # 同时考虑单字词和双字词组合 min_df3, # 至少在 3 条评论中出现过的词才保留 max_df0.8, # 在超过 80% 评论中出现的词丢弃 sublinear_tfTrue # 用 1log(tf) 替代原始词频抑制高频词 ) X vectorizer.fit_transform(df[token_str]) print(f特征矩阵形状: {X.shape})max_features5000是控制维度的硬上限评论分析场景下 3000 到 8000 之间比较合适太少会丢信息太多会过拟合。ngram_range(1,2)让模型能捕捉“不 好”“很 好”这种双词组合对情感判断帮助明显。min_df3过滤掉只出现一两次的罕见词这些词往往是噪声。max_df0.8去掉“商品”“收到”这类几乎每条都有的词。sublinear_tfTrue是经验之谈评论里同一个词重复多次并不代表情感强度线性增加用对数压制更合理。3.2 模型选型逻辑回归、朴素贝叶斯还是 SVM在 TF-IDF 特征上线性模型的表現通常不差而且训练快、可解释。我一般会同时跑三个基线逻辑回归、多项式朴素贝叶斯、线性 SVM看哪个在验证集上 F1 最高。逻辑回归的优势是输出概率方便后续做阈值调整朴素贝叶斯训练极快适合数据量大的场景线性 SVM 在边界清晰的数据上往往更稳。from sklearn.linear_model import LogisticRegression from sklearn.naive_bayes import MultinomialNB from sklearn.svm import LinearSVC from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report # 把评分转为二分类标签4-5 星为正面1-2 星为负面3 星丢弃 df_binary df[df[rating] ! 3].copy() df_binary[label] (df_binary[rating] 4).astype(int) X_train, X_test, y_train, y_test train_test_split( X, df_binary[label], test_size0.2, random_state42, stratifydf_binary[label] ) models { 逻辑回归: LogisticRegression(max_iter1000, C1.0), 朴素贝叶斯: MultinomialNB(alpha0.1), 线性SVM: LinearSVC(C0.5) } for name, model in models.items(): model.fit(X_train, y_train) y_pred model.predict(X_test) print(f {name} ) print(classification_report(y_test, y_pred, digits3))这里有几个参数值得说。LogisticRegression的C是正则化强度的倒数越小正则越强评论数据噪声大时可以把 C 调到 0.5 甚至 0.1。MultinomialNB的alpha是平滑系数评论短文本建议设 0.1 到 0.5太小会过拟合太大又欠拟合。LinearSVC的C同理0.5 是一个比较保守的起点。三分类正面/中性/负面也可以做但中性评论的边界很模糊实际业务里往往直接二分类更实用。提示如果某个模型在验证集上 F1 明显低于其他两个先别急着调参检查一下特征矩阵里是不是混入了测试集的词。fit_transform只能在训练集上做测试集必须用同一个 vectorizer 的transform。4. 避坑与排查评论分析系统最常见的五个翻车现场4.1 分词把“不好”切成“不”和“好”情感直接反转现象模型在测试集上把大量差评判成好评人工看几条发现“质量不好”“不推荐”这类评论被误判。原因jieba 默认分词会把“不好”切成“不”和“好”而“不”往往在停用词表里被过滤掉剩下“好”就成了正面信号。解决在分词前把常见否定词和后面的形容词绑定或者直接用jieba.add_word(不好)把否定短语加入词典。更系统的做法是维护一个否定词表在分词后做规则修正。4.2 训练集和测试集来自同一批商品指标虚高现象交叉验证 F1 到 0.95上线后实际准确率不到 0.7。原因训练集和测试集里同一个商品的评论被随机分到了两边模型记住了商品特征而不是情感特征。解决按product_id做分组划分确保同一个商品的所有评论只出现在训练集或测试集其中一边。sklearn 的GroupShuffleSplit可以直接做这件事。4.3 类别不均衡导致模型只会猜多数类现象正面评论占 90%负面占 10%模型把所有评论都判成正面准确率还有 0.9但负面评论一条都抓不到。原因默认的损失函数对多数类友好少数类被忽略。解决在模型里设class_weightbalanced或者对少数类做上采样。逻辑回归和 SVM 都支持class_weight参数设成balanced后模型会自动按类别频率反比加权。4.4 新词和网络用语导致线上效果衰减现象模型训练时“yyds”“绝绝子”还没出现上线后这些词被当成普通词处理情感判断失准。原因TF-IDF 词表在训练时就固定了新词不在词表里直接被忽略。解决定期用新数据重新 fit vectorizer或者改用支持子词切分的方案。如果不想频繁重训可以在预处理阶段维护一个网络用语映射表把新词替换成已知的情感词。4.5 推理服务加载模型时内存翻倍现象本地训练好的模型部署到线上服务启动后内存占用比预期高一倍并发一上来就 OOM。原因TF-IDF 矩阵和模型对象在加载时被复制了多份或者用了pickle加载大对象没有做流式处理。解决用joblib替代pickle保存和加载 sklearn 对象它对大 numpy 数组更友好。另外把 vectorizer 和模型分开保存推理时只加载一次用全局变量持有。5. 从脚本到服务把评论分析模型封装成可调用的接口5.1 用 FastAPI 包一个最小推理服务训练完模型只是第一步要让运营同学能用起来得有个接口。FastAPI 是目前最省事的方案自带文档和类型校验。下面是一个最小实现加载保存好的 vectorizer 和模型暴露一个/predict接口。import joblib from fastapi import FastAPI from pydantic import BaseModel import jieba import re app FastAPI() # 启动时加载一次避免每次请求都读磁盘 vectorizer joblib.load(tfidf_vectorizer.joblib) model joblib.load(sentiment_model.joblib) with open(stopwords.txt, encodingutf-8) as f: stopwords set(line.strip() for line in f if line.strip()) class ReviewRequest(BaseModel): text: str def preprocess(text: str) - str: text re.sub(r[^], , text) text re.sub(rhttp\S, , text) text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9], , text) words jieba.lcut(text) words [w for w in words if w not in stopwords and len(w) 1] return .join(words) app.post(/predict) def predict(req: ReviewRequest): cleaned preprocess(req.text) vec vectorizer.transform([cleaned]) prob model.predict_proba(vec)[0] label int(model.predict(vec)[0]) return { label: 正面 if label 1 else 负面, confidence: round(float(max(prob)), 4) }preprocess函数必须和训练时的清洗逻辑完全一致否则特征分布对不上预测结果会莫名其妙。joblib.load在启动时执行一次把对象放在模块级变量里后续请求直接复用。predict_proba返回的概率可以用来做阈值过滤比如置信度低于 0.6 的评论标记为“待人工复核”而不是硬判。5.2 批量评论的异步处理与结果落库单条推理适合实时场景但运营更常见的是批量导入一个 CSV跑完导出结果。这种场景用异步任务更合适避免 HTTP 请求超时。我一般用 FastAPI 的BackgroundTasks或者直接写一个独立的批处理脚本读 CSV、逐条推理、写回结果表。import pandas as pd import joblib vectorizer joblib.load(tfidf_vectorizer.joblib) model joblib.load(sentiment_model.joblib) def batch_predict(input_csv: str, output_csv: str): df pd.read_csv(input_csv, encodingutf-8) df[clean] df[review_text].apply(preprocess) X vectorizer.transform(df[clean]) df[pred_label] model.predict(X) df[pred_prob] model.predict_proba(X).max(axis1) df[pred_text] df[pred_label].map({1: 正面, 0: 负面}) df.to_csv(output_csv, indexFalse, encodingutf-8-sig) print(f完成 {len(df)} 条评论预测结果写入 {output_csv}) batch_predict(new_reviews.csv, predicted_reviews.csv)encodingutf-8-sig是为了 Excel 打开时不乱码这个细节在实际交付时很加分。predict_proba(X).max(axis1)取的是模型对预测类别的置信度后续可以按这个值排序优先看低置信度的样本。批处理脚本不需要考虑并发但要注意内存如果 CSV 有几十万行建议分块读取每块一万行处理完就写盘。5.3 模型迭代什么时候该重新训练评论数据分布会漂移新品上市、促销活动、季节性变化都会让评论用词发生变化。我的经验是当线上低置信度样本比例连续一周超过 15%或者人工抽检准确率下降超过 5 个百分点就该重新训练了。重训不是从头来而是把新标注的数据追加到训练集用同样的流程跑一遍对比新旧模型在固定测试集上的 F1。如果提升不明显可能只是数据噪声不必急着上线。注意重新训练前一定要固定一个时间切分的测试集不能用随机划分否则新旧模型对比没有意义。时间切分能模拟真实上线场景更能反映模型在未来数据上的表现。5.4 一个容易被忽略的细节评论时间戳的时区采集下来的评论时间戳经常是 UTC 或者平台自己的时区如果不统一后续做趋势分析时会出现“凌晨三点评论暴增”这种假象。我一般会在入库前统一转成东八区并在字段名里标明timestamp_cn。这个细节不影响模型训练但影响报表的可信度运营看到时间对不上的报表对整个系统的信任度都会打折扣。希望帮到你。本文还有配套的精品资源点击获取