简介面向机器学习与Python初学者的豆瓣评论情感分析资源利用SnowNLP库对《肖申克救赎》影评进行情感判断与词云展示覆盖文本读取、中文分词、情感打分和可视化等基础流程适合作为数据挖掘课程入门练习。压缩包共含10个文件以8个Python脚本为主体配套1个CSV测试数据集和1个TXT文本文件脚本按功能拆分为豆瓣评论读取、分词处理、SnowNLP情感分析等多个模块可直接运行并对照学习。资源总计37KB轻量简洁方便快速下载实验。目前已有16945人学习/下载适合希望掌握情感分析基本套路、积累文本挖掘代码的读者参考。通过本例可了解SnowNLP简单易用的API并据此迁移到其他评论文本的分析任务中。1. 为什么豆瓣短评得分高口碑却“翻车”一部电影豆瓣评分8.2点进短评却一片“烂尾”“尴尬”。评分是加权汇总影迷真正想看的是短评里的真实情绪。基于SnowNLP的豆瓣评论情感分析及词云分析就是把短评批量拿下来逐条给出01的积极概率再用词云找出大家到底在夸什么、骂什么。它适合产品运营看竞品口碑也适合课程设计和影评小组做一个小而完整的NLP项目。这套方案的落点不是训练大模型而是用SnowNLP在短文本上快速得到可排序的情绪分再用词云把关键词可视化。影视情感分析现在也有视频多模态情感分析的路线但文本判定仍是成本最低、最容易复现的一层。后面的章节会给出代码路径和掉过的坑新手照着能跑通熟手重点看阈值校准与词云失真的部分。2. SnowNLP的判定逻辑它凭什么给一条短评打分SnowNLP是一个中文文本情感分析库对很多做NLP的人来说是个“黑匣子”你输入一句话它输出一个0到1之间的sentiment值越接近1越正面越接近0越负面不提供特征权重解释性基本为零。但它胜在轻量CPU上单条打分是毫秒级不需要GPU也没有标注成本适合短文本批量初筛。豆瓣短评平均二三十个字正好落在这个库的舒适区里。但“能用”不等于“无脑用”。想要让SnowNLP输出能支撑分析结论你得知道它的判定机制、它擅长什么、它会在什么地方翻车以及它为什么面对影评这种领域时绝对分数不能直接当真理看。这一章把这三件事讲清楚。2.1 朴素贝叶斯在中文短文本上的“够用”边界SnowNLP内置的是一个朴素贝叶斯分类器核心思路是把句子分词后统计每个词在当前训练语料里属于“正面”和“负面”的条件概率然后用贝叶斯公式算整体属于正面的概率。它假设词与词之间互相独立也就是“演技”和“炸裂”各自对最终分数投票组合效果近似于两票相加。这个独立假设在长句上很吃亏但对豆瓣短评恰好还算能忍。短评里的评价性表达高度密集比如“演技炸裂剧本封神”“烂片浪费时间”信息基本都由几个关键词承载词之间的顺序和修饰关系没有长文章那么复杂。所以SnowNLP对短文本的排序能力比它在中长文本上稳定得多。真正不稳定的地方有两个。第一它不懂转折和否定范围。“好看但结局太仓促”会被拆成正面证据加负面证据最终输出一个居中的分数没法知道作者到底是偏向表扬还是批评。第二默认训练语料来自电商购物评论里面高频出现的是“质量、物流、客服、衣服”这些词到了影评语境“演技、剧本、剪辑、特效”几乎没有得到充分训练绝对分数会整体偏移。因此正确的用法不是拿0.5当铁判据而是把SnowNLP当排序工具同一批短评里哪些更正面、哪些更负面这个相对顺序大体是可信的。绝对阈值只能作为起点最后要用业务侧的真实标签校准这是第4章的重点。2.2 先清洗再打分分句、去噪声和简繁转换我见过很多直接拿原始爬虫文本喂给SnowNLP的做法出来的结果惨不忍睹问题不在SnowNLP而在数据。豆瓣短评里混着URL、用户、“来自豆瓣App”后缀、繁体字和重复空白这些噪声会进入分词结果并参与概率计算。先给一个我常用的清洗函数import re from zhconv import convert def clean_text(text): # 去掉URL和用户这两种token对情感判定没有贡献 text re.sub(rhttps?://\S|www\.\S, , text) text re.sub(r[\w\u4e00-\u9fa5_-], , text) # 去掉来自豆瓣App这类客户端签名 text re.sub(r来自豆瓣.*?$, , text) # 繁体统一成简体避免同一个词被切分成两个特征 text convert(text, zh-hans) # 合并连续空白字符 text re.sub(r\s, , text).strip() return text逻辑说明URL和用户基本都是情感中性token保留它们等于给每条评论注入一个高频无意义词词云阶段会第一个跳出来捣乱。来自豆瓣.*?$用于截掉客户端后缀注意末尾的$锚点只匹配行尾不会误伤正文里正常出现的“来自豆瓣”字样。繁体转简体这一步使用zhconv库convert(text, zh-hans)把整段文本统一成简体因为SnowNLP的词表基于简体训练同一句影评繁体版和简体版打出来的分数可能差0.1以上。还有一个经常犯的错把几十条短评拼成一个长字符串一次性丢给SnowNLP。正确做法是一条评论一个样本逐条处理。原因是SnowNLP把输入当作一个完整句子拼接后所有词的频率会被拉平均本来鲜明的正负信号被稀释。另外我一般不刻意删除标点符号句号逗号对贝叶斯概率影响很小感叹号有时还能带来一点语气信息删了不划算。2.3 跑通最小样例一条短评从字符串到sentiment值清洗完之后就可以跑最小样例了。下面这段代码只需要安装snownlp和zhconv即可运行from snownlp import SnowNLP sample 演技炸裂但剧本到后半段有点崩。 s SnowNLP(sample) print(s.sentiment)输出不会是一个极端值大概率落在0.4到0.6之间。原因在2.1已经说过模型把“演技炸裂”的正面证据和“剧本崩”的负面证据同时纳入朴素贝叶斯又没有阈值偏好所以两个方向互相抵消最后呈现为一个中性偏负或中性偏正的模糊分数。这里有个参数理解的问题sentiment是只读属性不接收任何参数它只返回模型对当前句子的正面概率。你没法通过它直接得到“正面/中性/负面”三分类结果需要自己在外面做区间判断。默认模型文件在snownlp/sentiment/目录下如果你自己训练了影评语料需要替换掉那个模型文件而不是给SnowNLP(sample, model_path...)传路径——它没提供这个入参。用几个典型短评对比会更直观短评SnowNLP分数人工判断演技炸裂剧本封神0.81正面烂片浪费时间别去看0.32负面还行中规中矩0.52中性不好看但特效值回票价0.44偏负面最后一行的0.44就是典型的骗局模型把“特效”识别为正面词拉高了整体分数但作者的落点是“不好看”。这种错不在代码而在模型能力边界。所以后面做批量分析时我一般会把score当作连续值保存而不是马上转成离散标签等校准完阈值再做三分类。既然SnowNLP有这么多边界为什么不用BERT微调答案是性价比。BERT类模型在影评情感分析上准确率确实更高但你需要准备几千条标注语料还要考虑GPU推理耗时。SnowNLP零标注、毫秒级、单机可跑用来做原型验证和舆情初筛完全够用。只有当你需要给客户或论文提供更严格的精度指标时再考虑用预训练模型做微调。3. 把豆瓣评论变成语料采集、清洗和CSV落地情感分析模型再能算也架不住数据里满是脏token和重复评论。这一章解决的是从零到一的数据工程问题怎么从豆瓣短评页拿到评论怎么清洗怎么去重怎么设计字段以及最容易踩的编码和页面结构坑。这些步骤看起来不起眼但直接影响后面所有统计和词云结论。采集之前先明确边界只拉公开页面里能看到的内容走正常网页端请求控制频率数据仅用于个人学习研究。豆瓣对爬虫不友好高并发必挂所以脚本里的限速不是摆设。3.1 用requests拉取短评页URL结构、请求头和限速豆瓣短评的网页地址格式比较固定主题ID加翻页参数即可。以《肖申克的救赎》为例短评页URL是https://movie.douban.com/subject/1292052/comments?start0limit20start从0开始每页20条。静态解析能拿到评论正文就不需要上浏览器模拟。import requests import time import random from bs4 import BeautifulSoup MOVIE_ID 1292052 # 《肖申克的救赎》 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, } def fetch_comments(movie_id, start0, limit20): url fhttps://movie.douban.com/subject/{movie_id}/comments?start{start}limit{limit} resp requests.get(url, headersHEADERS, timeout10) if resp.status_code ! 200: print(fHTTP {resp.status_code}: {url}) return [] soup BeautifulSoup(resp.text, html.parser) data [] for item in soup.select(div.comment-item): content item.select_one(span.short) if content is None: continue username item.select_one(span.comment-info a) label item.select_one(span.comment-info span) data.append({ user: username.get_text(stripTrue) if username else , label: label.get_text(stripTrue) if label else , content: content.get_text(stripTrue), }) return data逻辑说明div.comment-item是短评容器span.short是评论文本这两个选择器是豆瓣多年保持稳定的结构但页面改版后有可能失效。选择器一旦失效soup.select返回空列表程序不会报错而是静默产出空数据所以后面必须检查结果长度。span.comment-info a取用户名span.comment-info span取用户对短评打的标签标签可能是“力荐”“推荐”“还行”“较差”“很差”中的一种不是每一条都有。参数说明timeout10是指10秒没有响应就放弃当前页避免某个页面卡死导致线程悬停。请求头里的User-Agent是硬门槛豆瓣对没有UA的裸requests请求会直接返回403Accept和Accept-Language是补齐浏览器行为降低被识别的概率。翻页时start步长用20禁止调成100或200因为网页每页固定20条跳过了也拿不到更多数据只会加速触发限制。采集主循环加上随机延时all_rows [] for start in range(0, 60, 20): rows fetch_comments(MOVIE_ID, startstart) if not rows: break all_rows.extend(rows) time.sleep(random.uniform(2, 4))random.uniform(2, 4)模拟人工浏览间隔避免机器化的均匀节奏。if not rows: break处理短评翻到底或请求失败的情况直接退出。连续两页返回空的时候建议停手休息不要换UA再硬试。注意采集量控制在个人研究范围不要做全站抓取也不要拿数据做商用。豆瓣反爬严重遇到验证码就停手这不丢人。3.2 清洗、去重和字段设计别把脏数据带进情感分析采集到原始评论后第一步是调用上一章的clean_text做清洗第二步是去重第三步是过滤过短内容。这三步顺序不能乱。import csv import re from zhconv import convert def clean_comment(text): text re.sub(rhttps?://\S|www\.\S, , text) text re.sub(r[\w\u4e00-\u9fa5_-], , text) text re.sub(r来自豆瓣.*?$, , text) text convert(text, zh-hans) text re.sub(r\s, , text).strip() return text def deduplicate(rows): seen set() unique [] for row in rows: key (row[user], row[content]) if key in seen: continue seen.add(key) row[content] clean_comment(row[content]) if len(row[content]) 5: continue unique.append(row) return unique去重的主键选“用户内容”组合。豆瓣短评翻页时经常有同一用户对同一部电影重复评论或者同一句话被复制两遍只看内容会误删两条相似但不同用户的评论加上用户名能准确识别真正的重复。短于5个字的评论直接丢弃“好看”“冲啊”这种短句情感强度有限没有语境时会给词云增加无意义噪声。清洗顺序有讲究先去URL再去再砍客户端签名最后做繁简转换。如果先转简体再砍URL也没问题但不建议先把空白合并因为后面正则匹配URL时需要保留原始空白区间。字段设计上CSV至少保留四列movie_id、user、label、content。label就是短评标签列可能为空字符串但它后面要用来做SnowNLP输出的校准必须保存。3.3 编码、存储与“改版即失效”的页面解析保存CSV时有几个隐蔽坑。第一是编码推荐使用utf-8-sig而不是utf-8多了BOM头Excel打开不会乱码。第二是newlineWindows上写CSV如果不加每一行后面会多一个空行。第三是时间字段建议在采集时就把时间写进去方便后面做趋势分析。fieldnames [movie_id, user, label, content, fetched_at] with open(comments.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnamesfieldnames) writer.writeheader() for row in unique_rows: writer.writerow({ movie_id: MOVIE_ID, user: row[user], label: row[label], content: row[content], fetched_at: time.strftime(%Y-%m-%d %H:%M:%S), })fetched_at用time.strftime格式化精确到秒即可。如果你打算按小时做情感趋势这个字段必须保留只做静态情感分析可以暂时省略。页面结构改版是豆瓣采集最大的不稳定因素。当fetch_comments返回空列表先别怀疑IP被限制打开浏览器访问同一个短评页用开发者工具检查评论是不是还在div.comment-item里。如果HTML里能看到评论文本说明是选择器写错了如果页面能看到评论但requests.get拿到的HTML里没有说明评论已改成接口动态加载静态解析这条路走不通。动态加载的解决办法是换浏览器自动化工具让页面渲染完成后再抓取。我不建议一上来就上浏览器模拟因为浏览器实例吃内存、速度慢、更容易触发检测静态解析能跑就先跑静态。这类“改版”问题没有一劳永逸的答案排查路径本身就是数据处理能力的一部分。4. 批量情感分析阈值怎么定、结果怎么校验数据准备好之后批量打分这一步本身很简单复杂的是阈值设定和可信度校验。直接对整批CSV循环处理把每个score追加到字典里然后按0.6和0.4做三分类这是最常见的一版逻辑。但很多项目死就死在“阈值来自网上随便抄的0.6”没验证过就投产最后正负比例离谱还不自知。这章把阈值校准和校验动作做成一个完整流程。核心结论提前给出来SnowNLP的分数是连续值先保存原始分后决定阈值校准之前不要转离散标签。4.1 批量跑分与三分类阈值读取comments.csv逐条打分import csv from snownlp import SnowNLP def score_text(text): try: return SnowNLP(text).sentiment except Exception: return None rows [] with open(comments.csv, encodingutf-8-sig) as f: for r in csv.DictReader(f): score score_text(r[content]) rows.append({**r, score: score}) def to_sentiment(score): if score is None: return unknown if score 0.6: return positive if score 0.4: return negative return neutralscore_text里的try/except不是装饰是保护。总会有某条评论带着奇怪的控制字符或空白类型让SnowNLP内部分词崩溃单条报错会直接中断整批任务。**r拆包是Python 3.5以上字典解包语法把原始字段复制一份再追加score键保持数据形状统一。阈值选0.6和0.4是经验起点不是定论。作完批量打分后先看分布from collections import Counter cnt Counter(to_sentiment(r[score]) for r in rows if r[score] is not None) total sum(cnt.values()) for k in [positive, neutral, negative]: print(k, cnt[k] / total)如果正面比例超过60%而短评页里肉眼可见大量吐槽说明0.6这个阈值把很多负面评论推到了“中性”或“正面”。另一种情况是输出大量集中在0.45到0.55之间三分类分布扁平说明模型对这批语料区分力不足单纯调阈值也救不回来。4.2 用短评自带标签校准SnowNLP输出豆瓣短评的label是用户自己选的“力荐”“推荐”“还行”“较差”“很差”虽然和综合影评不完全等价但它比SnowNLP的电商语料更贴近影评的真实情绪。把它当弱标签可以校准阈值。import random manual_cases [r for r in rows if r.get(label)] sample random.sample(manual_cases, min(100, len(manual_cases))) def human_label(row): star_map {力荐: positive, 推荐: positive, 还行: neutral, 较差: negative, 很差: negative} return star_map.get(row[label], unknown) correct 0 for row in sample: if to_sentiment(row[score]) human_label(row): correct 1 print(accuracy on sample:, correct / len(sample))star_map的处理值得注意“还行”被归为中性不是正面也不是负面“力荐”和“推荐”都是正面“较差”和“很差”都是负面。抽样100条避免手动标注全量。如果准确率低于0.7先别急着调阈值打印错误样本看分布for row in sample: if to_sentiment(row[score]) ! human_label(row): print(row[label], round(row[score], 3), row[content])我见过最典型的结果SnowNLP把“太尬了”“烂片”“救命”全部打成中性因为默认词表对影评口语的低频情绪词几乎没有训练。这种情况下把阈值从0.6改成0.5没有意义因为它们打到0.48怎么调都过不去。更实际的做法是维护一个领域负面词表命中词表且分数低于0.55的强制归为负面之后再重新算准确率。4.3 输出情感分布和排序别只出一个平均数很多报告只写一个“正面比例66%”就完了这是把高维情感压成了一维平均数信息损失太大。至少要做两件事情感三分类占比以及正负两端的评论排序。neg_top sorted(rows, keylambda r: r[score] or 0)[:20] pos_top sorted(rows, keylambda r: -(r[score] or 0))[:20] print(最负面 20 条) for r in neg_top: print(round(r[score], 3), r[content]) print(最正面 20 条) for r in pos_top: print(round(r[score], 3), r[content])keylambda r: r[score] or 0把None安全地当成0处理避免排序时报错。负向排序用-score而不是升序再切片思路一致。排序列表的价值在于人工复核。SnowNLP输出的极端分数不一定真的是极端情绪可能只是模型对某些词反应过度。把正负Top20打印出来扫一遍如果发现明显误判说明整个打分结果需要重新审视而不是直接拿去做词云。如果采集时带了fetched_at还可以做时间维度的情感变化观察上映初期和后期短评的情感波动。不过豆瓣短评页只开放最近一部分翻页深度有限时间跨度通常只有几个月时间趋势仅适合大致参考不要强行做长周期分析。5. 避坑与排查豆瓣反爬、旧语料偏差和词云失真这一章是血泪经验的集中区。前半段是采集侧反爬后半段是情感分析和词云的常见失真。每条按“现象 → 原因 → 解决”的方式写遇到相同问题可以直接照方抓药。5.1 采集翻到后面突然403这不是被封是频率撞墙现象前两页短评正常返回start跳到40或60时突然HTTP 403再翻两页甚至出现验证码。原因豆瓣的访问频率控制是分段的前几个请求放行后续请求如果没有Cookie或请求间隔太短就会被判定为机器访问。翻页过深本身就偏离正常用户行为正常用户不会在一部电影短评页连续翻几十页。解决把time.sleep(random.uniform(2, 4))放宽到3到6秒并把采集页数上限控制在5页以内也就是100条短评。对情感分析初稿来说100条已经足够如果想要更多数据用多个时段分开采集而不是一次跑完。采集头里带上登录后的Cookie会明显缓解403但别为这事专门写一个绕过验证码的工具个人学习研究不划算也不合适。5.2 SnowNLP把“烂片”打成中性旧语料偏差现象人工读起来强负面的短评比如“烂片浪费时间谁去谁后悔”SnowNLP给出的分数是0.5左右在“中性”区间晃。原因默认训练语料是电商评论“烂片”“尬”这类影评高频词在语料中出现次数极少。朴素贝叶斯对低频词的贡献压得很低只要句中其他中性词数量上来了整体概率就会被拉向0.5。解决两个方案。快速方案是维护一个领域负面词表score高于0.4但命中负面词表的评论直接强制归为负面这是一种规则和模型结合的折中正式方案是收集几千条影评短文本自己训练一个新的情感模型替换默认模型。替换后阈值必须重新校准因为新模型的分数分布可能整体右移或左移。5.3 词云被“电影”“真的”占领停用词和词频权重现象生成的词云里字体最大的词是“电影”“真的”“一个”“没有”“就是”看完不知道观众到底在乎什么。原因WordCloud默认按原始词频统计中文虚词和泛化名词在短评里的出现频率天然最高。WordCloud内置的停用词表是英文的对中文完全不生效等于没设防。解决初始化WordCloud时通过stopwords参数传中文停用词集合把“电影、真的、一个、没有、就是、还是、这种、因为、所以”等全部放进去。更推荐的做法是做TF-IDF加权用jieba.analyse.extract_tags提取关键词后把权重字典传给generate_from_frequencies而不是直接传原始文本。TF-IDF会让“演技、剧本、特效、烂尾、拖沓”这些有区分性的词浮上来泛化词自动掉权重。5.4 jieba把“流浪地球”切成“流浪/地球”情绪跟着错现象词云和情感分里“流浪”和“地球”被拆成两个独立词情感分析分不清“地球”是星球还是片名。原因jieba默认词典里没有“流浪地球”这个电影名。分词切错会直接影响贝叶斯概率计算本来应该整体被识别为一个专名结果两个词各自把通用词频带进来。解决在任何打分和词云操作之前注册自定义词import jieba jieba.add_word(流浪地球) jieba.suggest_freq(流浪地球, True)注意add_word要在调用SnowNLP之前执行因为SnowNLP内部会调用jieba分词注册是全局的。把片名、主要演员名、角色名都放进一个外部配置文件逐行读入并注册不硬编码在代码里。5.5 Windows下词云不出字字体路径与中文编码现象代码在Mac上跑得好好的换Windows后词云图片里全是方框中文直接消失或者保存图片时遇到中文文件名报错。原因wordcloud的默认字体在Windows系统里没有对应字形需要显式指定中文字体文件。Windows和Mac的字体路径不同写死在代码里换个机器就跑不了。解决指定系统已有字体Windows常见路径是C:\Windows\Fonts\simhei.ttf或msyh.ttcMac可以用系统自带的/System/Library/Fonts/PingFang.ttc。更稳妥的方法是用matplotlib.font_manager扫描可用中文字体动态取路径避免硬编码。CSV文件读取时也保持用utf-8-sig不要用系统默认的gbk否则csv.DictReader解码直接报错。6. 进阶技巧把正面和负面拆成两张词云找口碑“真关键词”整体词云看的是高频但它会把正面词和负面词混在一起“演技”和“烂尾”同时出现看不出到底谁主导口碑。更实用的做法是拆开按情感阈值把语料分成正面评论集和负面评论集分别生成两张词云再并排看差异。6.1 按情感极性拆开正负词云不再互相“打架”pos_docs [r[content] for r in rows if to_sentiment(r[score]) positive] neg_docs [r[content] for r in rows if to_sentiment(r[score]) negative] pos_text .join(pos_docs) neg_text .join(neg_docs)然后分别做TF-IDF加权词云from wordcloud import WordCloud from jieba.analyse import extract_tags def gen_wordcloud(text, output_path, font_path): freqs {word: weight for word, weight in extract_tags(text, topK80, withWeightTrue)} wc WordCloud(font_pathfont_path, width800, height400, background_colorwhite, max_words80) wc.generate_from_frequencies(freqs) wc.to_file(output_path) gen_wordcloud(pos_text, pos_wordcloud.png, C:/Windows/Fonts/simhei.ttf) gen_wordcloud(neg_text, neg_wordcloud.png, C:/Windows/Fonts/simhei.ttf)extract_tags(text, topK80, withWeightTrue)返回的是TF-IDF权重不是原始词频。这样“电影”“真的”这类每一条都出现的词会被降权“演技”“剧本”“特效”这类有区分度的词才能浮上来。正面词云和负面词云并列看一部电影的真实口碑结构会非常清楚正面集中在“演技细腻、改编合理、配乐到位”负面集中在“节奏拖、结尾烂、逻辑硬伤”。这就比一个整体词云有说服力得多。6.2 从文本情感分析到多模态情感分析的衔接点如果项目要继续往前推进影视情感分析的下一个台阶是视频多模态情感分析把字幕文本、语音情绪、人脸表情都纳入判断。SnowNLP只能解决文本层但文本层通常是多模态系统里最稳定的基线。视频人物情感分析在处理对白时可以先把每句对白用SnowNLP打一个分再与音频特征、表情特征做融合文本分数作为其中一路输入而不是唯一结论。这个衔接点的工程意义是文本情感分析的输出不要只当一个最终指标把它当特征存档后面接任何多模态模型都能用。所以我在做项目时会一直保留score列和清洗前后的文本而不是只留一个百分比数字。我曾经因为没存清洗前的原始评论导致阈值调整后无法回溯“到底是清洗改变了解读还是模型分数变了”被迫从头抓数据。后来养成一个习惯每轮跑完把清洗前后样本、阈值配置、词云参数和输出图打包放一个目录。多花五分钟省掉的是几小时的重复劳动。这个习惯也希望能帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/30 16:26:40 · 阅读 1.2k 豆瓣短评情感分析与词云可视化：基于SnowNLP的完整实践
简介面向机器学习与Python初学者的豆瓣评论情感分析资源利用SnowNLP库对《肖申克救赎》影评进行情感判断与词云展示覆盖文本读取、中文分词、情感打分和可视化等基础流程适合作为数据挖掘课程入门练习。压缩包共含10个文件以8个Python脚本为主体配套1个CSV测试数据集和1个TXT文本文件脚本按功能拆分为豆瓣评论读取、分词处理、SnowNLP情感分析等多个模块可直接运行并对照学习。资源总计37KB轻量简洁方便快速下载实验。目前已有16945人学习/下载适合希望掌握情感分析基本套路、积累文本挖掘代码的读者参考。通过本例可了解SnowNLP简单易用的API并据此迁移到其他评论文本的分析任务中。1. 为什么豆瓣短评得分高口碑却“翻车”一部电影豆瓣评分8.2点进短评却一片“烂尾”“尴尬”。评分是加权汇总影迷真正想看的是短评里的真实情绪。基于SnowNLP的豆瓣评论情感分析及词云分析就是把短评批量拿下来逐条给出01的积极概率再用词云找出大家到底在夸什么、骂什么。它适合产品运营看竞品口碑也适合课程设计和影评小组做一个小而完整的NLP项目。这套方案的落点不是训练大模型而是用SnowNLP在短文本上快速得到可排序的情绪分再用词云把关键词可视化。影视情感分析现在也有视频多模态情感分析的路线但文本判定仍是成本最低、最容易复现的一层。后面的章节会给出代码路径和掉过的坑新手照着能跑通熟手重点看阈值校准与词云失真的部分。2. SnowNLP的判定逻辑它凭什么给一条短评打分SnowNLP是一个中文文本情感分析库对很多做NLP的人来说是个“黑匣子”你输入一句话它输出一个0到1之间的sentiment值越接近1越正面越接近0越负面不提供特征权重解释性基本为零。但它胜在轻量CPU上单条打分是毫秒级不需要GPU也没有标注成本适合短文本批量初筛。豆瓣短评平均二三十个字正好落在这个库的舒适区里。但“能用”不等于“无脑用”。想要让SnowNLP输出能支撑分析结论你得知道它的判定机制、它擅长什么、它会在什么地方翻车以及它为什么面对影评这种领域时绝对分数不能直接当真理看。这一章把这三件事讲清楚。2.1 朴素贝叶斯在中文短文本上的“够用”边界SnowNLP内置的是一个朴素贝叶斯分类器核心思路是把句子分词后统计每个词在当前训练语料里属于“正面”和“负面”的条件概率然后用贝叶斯公式算整体属于正面的概率。它假设词与词之间互相独立也就是“演技”和“炸裂”各自对最终分数投票组合效果近似于两票相加。这个独立假设在长句上很吃亏但对豆瓣短评恰好还算能忍。短评里的评价性表达高度密集比如“演技炸裂剧本封神”“烂片浪费时间”信息基本都由几个关键词承载词之间的顺序和修饰关系没有长文章那么复杂。所以SnowNLP对短文本的排序能力比它在中长文本上稳定得多。真正不稳定的地方有两个。第一它不懂转折和否定范围。“好看但结局太仓促”会被拆成正面证据加负面证据最终输出一个居中的分数没法知道作者到底是偏向表扬还是批评。第二默认训练语料来自电商购物评论里面高频出现的是“质量、物流、客服、衣服”这些词到了影评语境“演技、剧本、剪辑、特效”几乎没有得到充分训练绝对分数会整体偏移。因此正确的用法不是拿0.5当铁判据而是把SnowNLP当排序工具同一批短评里哪些更正面、哪些更负面这个相对顺序大体是可信的。绝对阈值只能作为起点最后要用业务侧的真实标签校准这是第4章的重点。2.2 先清洗再打分分句、去噪声和简繁转换我见过很多直接拿原始爬虫文本喂给SnowNLP的做法出来的结果惨不忍睹问题不在SnowNLP而在数据。豆瓣短评里混着URL、用户、“来自豆瓣App”后缀、繁体字和重复空白这些噪声会进入分词结果并参与概率计算。先给一个我常用的清洗函数import re from zhconv import convert def clean_text(text): # 去掉URL和用户这两种token对情感判定没有贡献 text re.sub(rhttps?://\S|www\.\S, , text) text re.sub(r[\w\u4e00-\u9fa5_-], , text) # 去掉来自豆瓣App这类客户端签名 text re.sub(r来自豆瓣.*?$, , text) # 繁体统一成简体避免同一个词被切分成两个特征 text convert(text, zh-hans) # 合并连续空白字符 text re.sub(r\s, , text).strip() return text逻辑说明URL和用户基本都是情感中性token保留它们等于给每条评论注入一个高频无意义词词云阶段会第一个跳出来捣乱。来自豆瓣.*?$用于截掉客户端后缀注意末尾的$锚点只匹配行尾不会误伤正文里正常出现的“来自豆瓣”字样。繁体转简体这一步使用zhconv库convert(text, zh-hans)把整段文本统一成简体因为SnowNLP的词表基于简体训练同一句影评繁体版和简体版打出来的分数可能差0.1以上。还有一个经常犯的错把几十条短评拼成一个长字符串一次性丢给SnowNLP。正确做法是一条评论一个样本逐条处理。原因是SnowNLP把输入当作一个完整句子拼接后所有词的频率会被拉平均本来鲜明的正负信号被稀释。另外我一般不刻意删除标点符号句号逗号对贝叶斯概率影响很小感叹号有时还能带来一点语气信息删了不划算。2.3 跑通最小样例一条短评从字符串到sentiment值清洗完之后就可以跑最小样例了。下面这段代码只需要安装snownlp和zhconv即可运行from snownlp import SnowNLP sample 演技炸裂但剧本到后半段有点崩。 s SnowNLP(sample) print(s.sentiment)输出不会是一个极端值大概率落在0.4到0.6之间。原因在2.1已经说过模型把“演技炸裂”的正面证据和“剧本崩”的负面证据同时纳入朴素贝叶斯又没有阈值偏好所以两个方向互相抵消最后呈现为一个中性偏负或中性偏正的模糊分数。这里有个参数理解的问题sentiment是只读属性不接收任何参数它只返回模型对当前句子的正面概率。你没法通过它直接得到“正面/中性/负面”三分类结果需要自己在外面做区间判断。默认模型文件在snownlp/sentiment/目录下如果你自己训练了影评语料需要替换掉那个模型文件而不是给SnowNLP(sample, model_path...)传路径——它没提供这个入参。用几个典型短评对比会更直观短评SnowNLP分数人工判断演技炸裂剧本封神0.81正面烂片浪费时间别去看0.32负面还行中规中矩0.52中性不好看但特效值回票价0.44偏负面最后一行的0.44就是典型的骗局模型把“特效”识别为正面词拉高了整体分数但作者的落点是“不好看”。这种错不在代码而在模型能力边界。所以后面做批量分析时我一般会把score当作连续值保存而不是马上转成离散标签等校准完阈值再做三分类。既然SnowNLP有这么多边界为什么不用BERT微调答案是性价比。BERT类模型在影评情感分析上准确率确实更高但你需要准备几千条标注语料还要考虑GPU推理耗时。SnowNLP零标注、毫秒级、单机可跑用来做原型验证和舆情初筛完全够用。只有当你需要给客户或论文提供更严格的精度指标时再考虑用预训练模型做微调。3. 把豆瓣评论变成语料采集、清洗和CSV落地情感分析模型再能算也架不住数据里满是脏token和重复评论。这一章解决的是从零到一的数据工程问题怎么从豆瓣短评页拿到评论怎么清洗怎么去重怎么设计字段以及最容易踩的编码和页面结构坑。这些步骤看起来不起眼但直接影响后面所有统计和词云结论。采集之前先明确边界只拉公开页面里能看到的内容走正常网页端请求控制频率数据仅用于个人学习研究。豆瓣对爬虫不友好高并发必挂所以脚本里的限速不是摆设。3.1 用requests拉取短评页URL结构、请求头和限速豆瓣短评的网页地址格式比较固定主题ID加翻页参数即可。以《肖申克的救赎》为例短评页URL是https://movie.douban.com/subject/1292052/comments?start0limit20start从0开始每页20条。静态解析能拿到评论正文就不需要上浏览器模拟。import requests import time import random from bs4 import BeautifulSoup MOVIE_ID 1292052 # 《肖申克的救赎》 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, } def fetch_comments(movie_id, start0, limit20): url fhttps://movie.douban.com/subject/{movie_id}/comments?start{start}limit{limit} resp requests.get(url, headersHEADERS, timeout10) if resp.status_code ! 200: print(fHTTP {resp.status_code}: {url}) return [] soup BeautifulSoup(resp.text, html.parser) data [] for item in soup.select(div.comment-item): content item.select_one(span.short) if content is None: continue username item.select_one(span.comment-info a) label item.select_one(span.comment-info span) data.append({ user: username.get_text(stripTrue) if username else , label: label.get_text(stripTrue) if label else , content: content.get_text(stripTrue), }) return data逻辑说明div.comment-item是短评容器span.short是评论文本这两个选择器是豆瓣多年保持稳定的结构但页面改版后有可能失效。选择器一旦失效soup.select返回空列表程序不会报错而是静默产出空数据所以后面必须检查结果长度。span.comment-info a取用户名span.comment-info span取用户对短评打的标签标签可能是“力荐”“推荐”“还行”“较差”“很差”中的一种不是每一条都有。参数说明timeout10是指10秒没有响应就放弃当前页避免某个页面卡死导致线程悬停。请求头里的User-Agent是硬门槛豆瓣对没有UA的裸requests请求会直接返回403Accept和Accept-Language是补齐浏览器行为降低被识别的概率。翻页时start步长用20禁止调成100或200因为网页每页固定20条跳过了也拿不到更多数据只会加速触发限制。采集主循环加上随机延时all_rows [] for start in range(0, 60, 20): rows fetch_comments(MOVIE_ID, startstart) if not rows: break all_rows.extend(rows) time.sleep(random.uniform(2, 4))random.uniform(2, 4)模拟人工浏览间隔避免机器化的均匀节奏。if not rows: break处理短评翻到底或请求失败的情况直接退出。连续两页返回空的时候建议停手休息不要换UA再硬试。注意采集量控制在个人研究范围不要做全站抓取也不要拿数据做商用。豆瓣反爬严重遇到验证码就停手这不丢人。3.2 清洗、去重和字段设计别把脏数据带进情感分析采集到原始评论后第一步是调用上一章的clean_text做清洗第二步是去重第三步是过滤过短内容。这三步顺序不能乱。import csv import re from zhconv import convert def clean_comment(text): text re.sub(rhttps?://\S|www\.\S, , text) text re.sub(r[\w\u4e00-\u9fa5_-], , text) text re.sub(r来自豆瓣.*?$, , text) text convert(text, zh-hans) text re.sub(r\s, , text).strip() return text def deduplicate(rows): seen set() unique [] for row in rows: key (row[user], row[content]) if key in seen: continue seen.add(key) row[content] clean_comment(row[content]) if len(row[content]) 5: continue unique.append(row) return unique去重的主键选“用户内容”组合。豆瓣短评翻页时经常有同一用户对同一部电影重复评论或者同一句话被复制两遍只看内容会误删两条相似但不同用户的评论加上用户名能准确识别真正的重复。短于5个字的评论直接丢弃“好看”“冲啊”这种短句情感强度有限没有语境时会给词云增加无意义噪声。清洗顺序有讲究先去URL再去再砍客户端签名最后做繁简转换。如果先转简体再砍URL也没问题但不建议先把空白合并因为后面正则匹配URL时需要保留原始空白区间。字段设计上CSV至少保留四列movie_id、user、label、content。label就是短评标签列可能为空字符串但它后面要用来做SnowNLP输出的校准必须保存。3.3 编码、存储与“改版即失效”的页面解析保存CSV时有几个隐蔽坑。第一是编码推荐使用utf-8-sig而不是utf-8多了BOM头Excel打开不会乱码。第二是newlineWindows上写CSV如果不加每一行后面会多一个空行。第三是时间字段建议在采集时就把时间写进去方便后面做趋势分析。fieldnames [movie_id, user, label, content, fetched_at] with open(comments.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnamesfieldnames) writer.writeheader() for row in unique_rows: writer.writerow({ movie_id: MOVIE_ID, user: row[user], label: row[label], content: row[content], fetched_at: time.strftime(%Y-%m-%d %H:%M:%S), })fetched_at用time.strftime格式化精确到秒即可。如果你打算按小时做情感趋势这个字段必须保留只做静态情感分析可以暂时省略。页面结构改版是豆瓣采集最大的不稳定因素。当fetch_comments返回空列表先别怀疑IP被限制打开浏览器访问同一个短评页用开发者工具检查评论是不是还在div.comment-item里。如果HTML里能看到评论文本说明是选择器写错了如果页面能看到评论但requests.get拿到的HTML里没有说明评论已改成接口动态加载静态解析这条路走不通。动态加载的解决办法是换浏览器自动化工具让页面渲染完成后再抓取。我不建议一上来就上浏览器模拟因为浏览器实例吃内存、速度慢、更容易触发检测静态解析能跑就先跑静态。这类“改版”问题没有一劳永逸的答案排查路径本身就是数据处理能力的一部分。4. 批量情感分析阈值怎么定、结果怎么校验数据准备好之后批量打分这一步本身很简单复杂的是阈值设定和可信度校验。直接对整批CSV循环处理把每个score追加到字典里然后按0.6和0.4做三分类这是最常见的一版逻辑。但很多项目死就死在“阈值来自网上随便抄的0.6”没验证过就投产最后正负比例离谱还不自知。这章把阈值校准和校验动作做成一个完整流程。核心结论提前给出来SnowNLP的分数是连续值先保存原始分后决定阈值校准之前不要转离散标签。4.1 批量跑分与三分类阈值读取comments.csv逐条打分import csv from snownlp import SnowNLP def score_text(text): try: return SnowNLP(text).sentiment except Exception: return None rows [] with open(comments.csv, encodingutf-8-sig) as f: for r in csv.DictReader(f): score score_text(r[content]) rows.append({**r, score: score}) def to_sentiment(score): if score is None: return unknown if score 0.6: return positive if score 0.4: return negative return neutralscore_text里的try/except不是装饰是保护。总会有某条评论带着奇怪的控制字符或空白类型让SnowNLP内部分词崩溃单条报错会直接中断整批任务。**r拆包是Python 3.5以上字典解包语法把原始字段复制一份再追加score键保持数据形状统一。阈值选0.6和0.4是经验起点不是定论。作完批量打分后先看分布from collections import Counter cnt Counter(to_sentiment(r[score]) for r in rows if r[score] is not None) total sum(cnt.values()) for k in [positive, neutral, negative]: print(k, cnt[k] / total)如果正面比例超过60%而短评页里肉眼可见大量吐槽说明0.6这个阈值把很多负面评论推到了“中性”或“正面”。另一种情况是输出大量集中在0.45到0.55之间三分类分布扁平说明模型对这批语料区分力不足单纯调阈值也救不回来。4.2 用短评自带标签校准SnowNLP输出豆瓣短评的label是用户自己选的“力荐”“推荐”“还行”“较差”“很差”虽然和综合影评不完全等价但它比SnowNLP的电商语料更贴近影评的真实情绪。把它当弱标签可以校准阈值。import random manual_cases [r for r in rows if r.get(label)] sample random.sample(manual_cases, min(100, len(manual_cases))) def human_label(row): star_map {力荐: positive, 推荐: positive, 还行: neutral, 较差: negative, 很差: negative} return star_map.get(row[label], unknown) correct 0 for row in sample: if to_sentiment(row[score]) human_label(row): correct 1 print(accuracy on sample:, correct / len(sample))star_map的处理值得注意“还行”被归为中性不是正面也不是负面“力荐”和“推荐”都是正面“较差”和“很差”都是负面。抽样100条避免手动标注全量。如果准确率低于0.7先别急着调阈值打印错误样本看分布for row in sample: if to_sentiment(row[score]) ! human_label(row): print(row[label], round(row[score], 3), row[content])我见过最典型的结果SnowNLP把“太尬了”“烂片”“救命”全部打成中性因为默认词表对影评口语的低频情绪词几乎没有训练。这种情况下把阈值从0.6改成0.5没有意义因为它们打到0.48怎么调都过不去。更实际的做法是维护一个领域负面词表命中词表且分数低于0.55的强制归为负面之后再重新算准确率。4.3 输出情感分布和排序别只出一个平均数很多报告只写一个“正面比例66%”就完了这是把高维情感压成了一维平均数信息损失太大。至少要做两件事情感三分类占比以及正负两端的评论排序。neg_top sorted(rows, keylambda r: r[score] or 0)[:20] pos_top sorted(rows, keylambda r: -(r[score] or 0))[:20] print(最负面 20 条) for r in neg_top: print(round(r[score], 3), r[content]) print(最正面 20 条) for r in pos_top: print(round(r[score], 3), r[content])keylambda r: r[score] or 0把None安全地当成0处理避免排序时报错。负向排序用-score而不是升序再切片思路一致。排序列表的价值在于人工复核。SnowNLP输出的极端分数不一定真的是极端情绪可能只是模型对某些词反应过度。把正负Top20打印出来扫一遍如果发现明显误判说明整个打分结果需要重新审视而不是直接拿去做词云。如果采集时带了fetched_at还可以做时间维度的情感变化观察上映初期和后期短评的情感波动。不过豆瓣短评页只开放最近一部分翻页深度有限时间跨度通常只有几个月时间趋势仅适合大致参考不要强行做长周期分析。5. 避坑与排查豆瓣反爬、旧语料偏差和词云失真这一章是血泪经验的集中区。前半段是采集侧反爬后半段是情感分析和词云的常见失真。每条按“现象 → 原因 → 解决”的方式写遇到相同问题可以直接照方抓药。5.1 采集翻到后面突然403这不是被封是频率撞墙现象前两页短评正常返回start跳到40或60时突然HTTP 403再翻两页甚至出现验证码。原因豆瓣的访问频率控制是分段的前几个请求放行后续请求如果没有Cookie或请求间隔太短就会被判定为机器访问。翻页过深本身就偏离正常用户行为正常用户不会在一部电影短评页连续翻几十页。解决把time.sleep(random.uniform(2, 4))放宽到3到6秒并把采集页数上限控制在5页以内也就是100条短评。对情感分析初稿来说100条已经足够如果想要更多数据用多个时段分开采集而不是一次跑完。采集头里带上登录后的Cookie会明显缓解403但别为这事专门写一个绕过验证码的工具个人学习研究不划算也不合适。5.2 SnowNLP把“烂片”打成中性旧语料偏差现象人工读起来强负面的短评比如“烂片浪费时间谁去谁后悔”SnowNLP给出的分数是0.5左右在“中性”区间晃。原因默认训练语料是电商评论“烂片”“尬”这类影评高频词在语料中出现次数极少。朴素贝叶斯对低频词的贡献压得很低只要句中其他中性词数量上来了整体概率就会被拉向0.5。解决两个方案。快速方案是维护一个领域负面词表score高于0.4但命中负面词表的评论直接强制归为负面这是一种规则和模型结合的折中正式方案是收集几千条影评短文本自己训练一个新的情感模型替换默认模型。替换后阈值必须重新校准因为新模型的分数分布可能整体右移或左移。5.3 词云被“电影”“真的”占领停用词和词频权重现象生成的词云里字体最大的词是“电影”“真的”“一个”“没有”“就是”看完不知道观众到底在乎什么。原因WordCloud默认按原始词频统计中文虚词和泛化名词在短评里的出现频率天然最高。WordCloud内置的停用词表是英文的对中文完全不生效等于没设防。解决初始化WordCloud时通过stopwords参数传中文停用词集合把“电影、真的、一个、没有、就是、还是、这种、因为、所以”等全部放进去。更推荐的做法是做TF-IDF加权用jieba.analyse.extract_tags提取关键词后把权重字典传给generate_from_frequencies而不是直接传原始文本。TF-IDF会让“演技、剧本、特效、烂尾、拖沓”这些有区分性的词浮上来泛化词自动掉权重。5.4 jieba把“流浪地球”切成“流浪/地球”情绪跟着错现象词云和情感分里“流浪”和“地球”被拆成两个独立词情感分析分不清“地球”是星球还是片名。原因jieba默认词典里没有“流浪地球”这个电影名。分词切错会直接影响贝叶斯概率计算本来应该整体被识别为一个专名结果两个词各自把通用词频带进来。解决在任何打分和词云操作之前注册自定义词import jieba jieba.add_word(流浪地球) jieba.suggest_freq(流浪地球, True)注意add_word要在调用SnowNLP之前执行因为SnowNLP内部会调用jieba分词注册是全局的。把片名、主要演员名、角色名都放进一个外部配置文件逐行读入并注册不硬编码在代码里。5.5 Windows下词云不出字字体路径与中文编码现象代码在Mac上跑得好好的换Windows后词云图片里全是方框中文直接消失或者保存图片时遇到中文文件名报错。原因wordcloud的默认字体在Windows系统里没有对应字形需要显式指定中文字体文件。Windows和Mac的字体路径不同写死在代码里换个机器就跑不了。解决指定系统已有字体Windows常见路径是C:\Windows\Fonts\simhei.ttf或msyh.ttcMac可以用系统自带的/System/Library/Fonts/PingFang.ttc。更稳妥的方法是用matplotlib.font_manager扫描可用中文字体动态取路径避免硬编码。CSV文件读取时也保持用utf-8-sig不要用系统默认的gbk否则csv.DictReader解码直接报错。6. 进阶技巧把正面和负面拆成两张词云找口碑“真关键词”整体词云看的是高频但它会把正面词和负面词混在一起“演技”和“烂尾”同时出现看不出到底谁主导口碑。更实用的做法是拆开按情感阈值把语料分成正面评论集和负面评论集分别生成两张词云再并排看差异。6.1 按情感极性拆开正负词云不再互相“打架”pos_docs [r[content] for r in rows if to_sentiment(r[score]) positive] neg_docs [r[content] for r in rows if to_sentiment(r[score]) negative] pos_text .join(pos_docs) neg_text .join(neg_docs)然后分别做TF-IDF加权词云from wordcloud import WordCloud from jieba.analyse import extract_tags def gen_wordcloud(text, output_path, font_path): freqs {word: weight for word, weight in extract_tags(text, topK80, withWeightTrue)} wc WordCloud(font_pathfont_path, width800, height400, background_colorwhite, max_words80) wc.generate_from_frequencies(freqs) wc.to_file(output_path) gen_wordcloud(pos_text, pos_wordcloud.png, C:/Windows/Fonts/simhei.ttf) gen_wordcloud(neg_text, neg_wordcloud.png, C:/Windows/Fonts/simhei.ttf)extract_tags(text, topK80, withWeightTrue)返回的是TF-IDF权重不是原始词频。这样“电影”“真的”这类每一条都出现的词会被降权“演技”“剧本”“特效”这类有区分度的词才能浮上来。正面词云和负面词云并列看一部电影的真实口碑结构会非常清楚正面集中在“演技细腻、改编合理、配乐到位”负面集中在“节奏拖、结尾烂、逻辑硬伤”。这就比一个整体词云有说服力得多。6.2 从文本情感分析到多模态情感分析的衔接点如果项目要继续往前推进影视情感分析的下一个台阶是视频多模态情感分析把字幕文本、语音情绪、人脸表情都纳入判断。SnowNLP只能解决文本层但文本层通常是多模态系统里最稳定的基线。视频人物情感分析在处理对白时可以先把每句对白用SnowNLP打一个分再与音频特征、表情特征做融合文本分数作为其中一路输入而不是唯一结论。这个衔接点的工程意义是文本情感分析的输出不要只当一个最终指标把它当特征存档后面接任何多模态模型都能用。所以我在做项目时会一直保留score列和清洗前后的文本而不是只留一个百分比数字。我曾经因为没存清洗前的原始评论导致阈值调整后无法回溯“到底是清洗改变了解读还是模型分数变了”被迫从头抓数据。后来养成一个习惯每轮跑完把清洗前后样本、阈值配置、词云参数和输出图打包放一个目录。多花五分钟省掉的是几小时的重复劳动。这个习惯也希望能帮到你。本文还有配套的精品资源点击获取