简介这份微博评论爬虫项目集合了数据采集、清洗与情感分析整套流程适合想兼修爬虫和NLP的实战学习者。项目基于requests与BeautifulSoup构造抓取逻辑可处理登录Cookie与验证码模拟并利用pandas将评论数据规范保存为CSV也可写入MySQL情感分析部分采用SnowNLP等模型配合jieba分词与词云统计能直观判断评论的正负倾向。压缩包共17个文件以txt配置、py脚本、png图解、csv样例数据及md说明为主体量仅467KB其中包含positive_words.txt、negative_words.txt等词典以及创建MySQL表的语句方便直接复用。包内还提供crawler脚本与text_emotion.py脚本从采集到分析均有可运行代码并带有cookie.txt填写示例和requirements.txt依赖列表能快速跑通整个流程。已有115人学习下载适合作为数据分析和NLP入门的小型综合项目。1. 微博评论爬虫先搞清你要的是一条评论流还是一个评论区先说个最常见的画面压缩包标题里写着“微博评论爬虫、爬取微博评论、微博分析、评论情感分析”看起来是一条龙服务但真正上手后你会发现卡住你的往往不是爬虫而是爬下来的数据没法直接用。有人折腾一天把评论区刷到 Excel结果满屏表情符号、“已过滤”和广告账号情感分析只报喜不报忧最后整份数据扔进回收站。这篇不讲抽象原理只讲从接口设计、数据清洗、情感分析到避坑的完整落地路径。适合谁读适合已经会写点 Python、手里有一个明确的微博 ID、想把它做成可分析数据集的开发者。读完你能照着复现出一条能跑的流水线也知道每一环的边界在哪里。2. 采集层设计评论接口、登录态与请求频率决定爬虫能活多久2.1 为什么不建议直接解析页面 HTML很多新手拿到“微博评论爬虫”的第一反应是用请求库抓页面源码再用解析库抠评论节点。这个思路在静态网页时代成立在微博评论区基本走不通。评论区是滚动加载的页面初始 HTML 里只有前几条评论后面全靠异步接口往回流你抓到的页面里压根没有完整评论数据。更麻烦的是页面结构经常调整。上个月还能用的 CSS 选择器下个月某个 class 名字一改整套解析逻辑就报废。相比之下服务端提供给页面渲染的 JSON 接口稳定得多字段结构清晰评论 ID、用户 ID、点赞数都给你分好了。接口返回的是结构化数据你不需要跟标签较劲只需要处理字典和列表。所以我自己的习惯是任何爬虫需求先打开浏览器开发者工具看 Network 面板找到页面异步加载数据的那个请求优先从接口拿数据而不是从渲染后的 HTML 里抠。从工程角度说直接解析 HTML 还有一个隐藏成本它会把评论正文、用户昵称、转发标识混在一起清洗时你还要自己拆。接口返回的 JSON 里这些字段天然分离能少写一半清洗代码。所以第一选择永远是找公开接口这是这个方案值不值得做的分水岭。2.2 评论接口的最小请求URL、参数和返回结构微博移动端的评论接口结构很典型。下面这个函数是采集层的最小可用版本只做一件事按页码拉取某条微博的评论列表。import requests import time COMMENTS_API https://m.weibo.cn/api/comments/show def fetch_comments(weibo_id: str, cookie: str, max_pages: int 10) - list: session requests.Session() session.headers.update({ User-Agent: ( Mozilla/5.0 (iPhone; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 ), Cookie: cookie, X-Requested-With: XMLHttpRequest, Referer: https://m.weibo.cn/detail/ weibo_id, }) results [] for page in range(1, max_pages 1): params { id: weibo_id, page: page, count: 20, } resp session.get(COMMENTS_API, paramsparams, timeout10) data resp.json() comment_list data.get(data, {}).get(data, []) if not comment_list: break results.extend(comment_list) # 每页之间必须停顿频率控制是长跑的关键 time.sleep(1.2 page % 3 * 0.2) return results这段代码里有几个参数需要重点说明。id是微博正文 ID通常在微博详情页的 URL 末尾可以看到page从 1 开始递增count是每页条数20 是比较保守的取值接口上限高一些但我不建议一上来就拉满。请求头里的User-Agent用移动端标识Referer要指向该微博的详情页X-Requested-With标记这是异步请求。这四件套搭配在一起比裸请求更容易通过基础校验。返回值里最外层的code字段为 0 表示成功data.data才是评论数组。每条评论的核心字段包括id、text、created_at、like_count、user和reply_to。注意text是 HTML 片段不能直接当纯文本用这一步留到清洗阶段处理。这里有一个判断是否要带 Cookie 的小技巧先不带 Cookie 跑一次如果返回的data为空或者code非 0再决定把登录态接进来。2.3 登录态 Cookie怎么拿、怎么用、什么时候必须用评论接口并不强制要求登录但你会发现不带登录态时一些“登录可见”的评论会被过滤掉翻页深度也受限。对严肃的微博分析来说公开评论一般够用但如果你想拿到更完整的评论区就需要给请求带上登录后的 Cookie。拿 Cookie 的操作不复杂用浏览器登录微博打开任意一条微博的评论区按 F12 进入开发者工具在 Network 面板里过滤出comments/show这个请求把请求头里的 Cookie 整段复制出来。这里有两个常见的翻车点。第一个是把 Cookie 硬编码进代码。代码一旦分享出去Cookie 就等于泄露了而且 Cookie 是有有效期的改起来也麻烦。第二个是不小心复制了多余的字符导致请求直接 403。我的习惯是把 Cookie 放到环境变量里脚本启动时读取。import os cookie os.getenv(WEIBO_COOKIE) if not cookie: raise RuntimeError(请先设置 WEIBO_COOKIE 环境变量)把敏感信息放进环境变量是采集工程里很基础但很多人不做的一件事。做个 Debug 输出时最多打印 Cookie 的前 20 个字符用来确认没有截断不要完整打印。另外要有个心理预期Cookie 不是永久的退出登录、更换密码、风控触发都可能导致它失效。所以我每次跑批任务前会先发一个最小的请求验证 Cookie 是否还活着而不是等脚本跑到一半才报错。什么时候必须用 Cookie判断标准有三个返回数据为空、翻页深度明显受限、接口明确返回登录提示。三者都不出现时可以不带 Cookie 降低风控暴露面。我一般会让工程默认支持带 Cookie但保留不带 Cookie 的开关方便排查问题。2.4 分页、时间窗与频率设计让采集行为“像人”采集层的设计目标不是“快”而是“活得久”。很多爬虫刚跑起来很顺利过几个小时就被限流问题多半出在频率上。不要用多线程、不要并发拉取先把单线程的顺序请求跑通再做优化这是这个方案最常见的可靠做法。分页这块有个重要的边界认知page参数翻页是有隐性上限的翻到 20 页之后接口经常开始返回重复评论或直接拒绝。原因在后面避坑章节会展开说这里先记住结论默认max_pages设成 10 到 20 就够不要贪心。时间窗方面评论接口能读到的数据通常集中在近期更早的评论要么被截断要么需要更长的分页游标。如果你想分析的是某条微博发布后前几个小时的舆论反应优先级是“尽早抓、尽快抓”因为评论区的热评排序会变化晚几个小时抓到的数据已经不是最初的舆论场了。参数设计参考下表这是我跑过多个项目之后沉淀下来的默认值参数建议值说明count20每页条数20 对新手更保险page1~20超过 20 页容易撞缓存和重复延时1.5~3 秒随机固定间隔更容易被识别并发1先单线程跑通再考虑并发超时10 秒网络异常时快速失败重试延时为什么强调随机而不是固定因为真实用户的操作间隔从来不均匀。固定每 2 秒一次请求短时间看起来没问题跑久了模式太明显。用随机函数生成每次停顿更接近人类行为这里的“更接近”本身就是低风险策略的一部分。提示如果发现 Cookie 频繁失效优先检查是否在多个地方同时使用同一个账号的登录态这比修改频率更容易触发风控。3. 清洗与存储把接口响应变成干净的分析数据集3.1 评论去重与过滤广告、机器人、重复转发怎么处理接口返回的评论数据不能直接进情感分析模型原因很简单text字段是 HTML 片段里面既有标签又有各类实体字符。还有一个容易被忽略的问题评论正文里会带“用户名:”这样的前缀一条微博被转发时评论区还会出现“//用户名:”这种转发痕迹。这些内容对情感分析都是噪声必须先清掉。import re import html def clean_comment_text(raw_text): text html.unescape(raw_text or ) # 去掉所有 HTML 标签 text re.sub(r[^], , text) # 去掉零宽空格与首尾空白 text text.replace(\u200b, ).strip() # 去掉“用户名:”前缀 text re.sub(r^[^:][:]?\s*, , text) # 去掉“//”后面的转发内容 text text.split(//)[0].strip() return text这段清洗函数有四个关键步骤。html.unescape先把amp;、lt;这类实体还原成原始字符否则后面正则匹配会漏掉内容。去标签用正则匹配所有尖括号包裹的内容这是处理 HTML 片段最直接的方式。零宽空格\u200b是微博评论里很常见的隐形字符肉眼看不见但会干扰分词。最后把“用户名”前缀和“//”转发尾巴切掉。表情符号要保留不要把它们当脏数据清掉。表情在微博评论里承载着大量情绪信息一个哭笑表情可能比整句话都重要。清洗只处理不可见字符和结构垃圾不处理可见的情绪符号。清洗完之后还要做两步过滤按comment_id去重以及识别疑似水军的高重复文本。import pandas as pd def process_comments(items): rows [] for it in items: rows.append({ comment_id: str(it.get(id)), weibo_id: str(it.get(status_id, )), user_id: str((it.get(user) or {}).get(id, )), user_name: (it.get(user) or {}).get(screen_name, ), clean_text: clean_comment_text(it.get(text, )), like_count: it.get(like_count, 0), }) df pd.DataFrame(rows) # 按评论 ID 去重 df df.drop_duplicates(subset[comment_id]) # 相同文本出现 5 次以上标记为疑似水军 text_counts df[clean_text].value_counts() spam_items set(text_counts[text_counts 5].index) df[is_spam] df[clean_text].isin(spam_items) return df这个处理过程把原始 JSON 变成一张行式表每一行是一条独立评论。drop_duplicates处理的是接口翻页时可能返回的重复数据is_spam标记的是重复度异常高的文本这种文本在真实评论区里一般是广告或机器人刷屏进情感分析前最好单独挑出来看。情感分析只针对is_spam为 False 的评论但如果水军比例超过 10%分析结论就要打个问号。3.2 时间字段与用户维度评论节奏分析的前提做微博分析时间字段是绕不开的维度。评论是“发布后一小时内爆发”还是“三天内持续发酵”结论完全不同。但评论接口返回的时间往往不是标准时间戳而是“1分钟前”“昨天 12:30”这类相对时间必须基于采集时刻做换算。from datetime import datetime, timedelta import re def parse_created_at(created_at, nowNone): now now or datetime.now() text (created_at or ).strip() if 分钟前 in text: n int(re.search(r\d, text).group()) return now - timedelta(minutesn) if 小时前 in text: n int(re.search(r\d, text).group()) return now - timedelta(hoursn) if text.startswith(昨天): hm text.replace(昨天, ).strip() t datetime.strptime(hm, %H:%M).time() return datetime.combine(now.date() - timedelta(days1), t) try: return datetime.strptime(text, %Y-%m-%d %H:%M) except ValueError: return None这里有一个需要注意的边界解析相对时间依赖“采集时刻”这个参考点。如果你把采集好的数据存到数据库过了几天再跑清洗流程用当前的datetime.now()去换算“昨天”就会错位。正确做法是在采集的时候就把时间字段解析好把相对时间换算成绝对时间存库清洗和解析永远在采集后立刻执行。用户维度主要在分析话题评论结构时用到按user_id统计每个用户贡献了多少条评论、给多少条热评点了赞。如果一个用户对同一条微博刷了几十条内容重复的评论通常要当作异常样本剔除。初级阶段只保留下user_id和user_name就够做更深入的用户画像时才需要扩展字段。提示如果你拿到的评论数据里有个别时间字段解析失败返回 None不要直接丢弃整行。可以把这条评论的 ID 单独记录回头手动核对因为时间解析失败往往意味着该评论的格式不常规。3.3 存储落库与增量更新不要每次全量重跑把清洗后的 DataFrame 存成 CSV 是最快的方案但只适用于一次性分析。真实项目中微博评论是会持续增长的今天跑完明天还有新评论进来每次都全量拉一遍既浪费请求又容易触发风控。常见做法是落 SQLite轻量、单文件、不需要额外部署数据库服务。import sqlite3 def save_comments(df, db_pathweibo_comments.db): conn sqlite3.connect(db_path) df.to_sql(comments, conn, if_existsappend, indexFalse) conn.close()第一次跑没问题第二次第三次就会出问题同一批评论会重复插入。所以建表时要显式定义主键插入时利用主键去重。更可靠的做法是让表结构提前固定下来第一次运行前建好表。CREATE TABLE IF NOT EXISTS comments ( comment_id TEXT PRIMARY KEY, weibo_id TEXT, user_id TEXT, clean_text TEXT, parsed_time TIMESTAMP, like_count INTEGER, is_spam INTEGER DEFAULT 0 );把comment_id设为主键后后续的增量采集只需要用 SQL 的去重插入模式。在应用层再包一层逻辑更直观每次先把新抓到的数据临时存一遍然后对比已有comment_id只保留新增部分。增量更新最好依托parsed_time做增量窗口判断只抓“上次采集时刻之后”的新评论这能大幅减少请求量。还有一个小习惯每次采集结束脚本打印一行统计摘要。我一般会输出“本次采集 N 条新增 M 条过滤广告 K 条”。如果下一次跑出来的新增条数锐减说明接口或 Cookie 可能出了问题能第一时间发现。4. 评论情感分析词典打分、开源模型、微调模型怎么选才不白干4.1 先定义任务你分析的是“情绪倾向”还是“意见倾向”很多开发者拿到评论数据就急着往模型里塞结果做出来的情感分析无法解释负面评论被标成正面正面评论被标成中性。问题往往不是模型不行而是任务没定义清楚。微博评论里的“情感”通常分两种一种是情绪倾向就是这句话是高兴还是愤怒另一种是意见倾向就是这句话在支持还是反对某个观点。两者不完全一样。我在项目里先按“正向、负向、中性”三分类来定义任务输出一个 0 到 1 的分数而不是硬分类。分数小于 0.4 视为负向大于 0.6 视为正向中间是中性。这个阈值不是拍脑袋定的而是在小批量人工验证后调整出来的。微博短文本里充满了反讽、夸张、网络梗完全靠模型硬判会经常翻车所以情感分析的第一原则是先能跑再谈准。4.2 三类方案对比与选型逻辑情感分析的实现路径有很多但真正适合微博评论、又能快速落地的方案就三类。我在做技术选型时会先统计数据量级然后对照下表选方案优点代价适用场景情感词典零训练、快、可解释对网络新词和反讽识别差数据 5 万条以下、先跑通开源预训练模型上下文理解更好资源占用高、短文本波动大数据量 10 万级以上微调轻量模型贴合微博语境需要几千条标注数据长期迭代、分析要求高情感词典方案最大的价值是快。数据量小到几千条时没必要引入重型模型词典方案几分钟就能出结果而且每条评论的打分依据是可解释的。反讽是它识别不了的比如“真是谢谢你啊”在词典里是正向词实际是负向情绪。开源预训练模型能学到上下文但微博评论太短、口语化太强直接套用效果也一般。真正贴合微博语境的方案是用你自己的评论数据去微调一个轻量模型代价是需要标注数据。基于这个对比我给大多数人的路线是第一版用词典打分出结果跑通全流程等积累了足够多的标注数据后再切换微调模型。而不是一开始就追求最复杂的方案。4.3 基于情感词典的快速打分先能跑再谈准Python 生态里有现成的中文情感分析库比较典型的是 SnowNLP。它的使用很简单但默认训练语料来自商品评论直接用在微博上效果一般。所以先写出能跑的打分函数再通过重新训练来提升准确率。from snownlp import SnowNLP def score_comment(text): if not text or len(text) 2: return 0.5 try: return SnowNLP(text).sentiments except Exception: return 0.5短于两个字符的评论没有足够上下文直接打 0.5 分给中性避免模型硬判。异常时也回退到 0.5保证整批数据不会因为个别脏文本中断。这个函数跑一遍就能给所有评论打分但它是基于通用语料的如果你想让它更贴合微博语境需要用自己的评论数据重新训练。from snownlp import sentiment # pos.txt 每行一条积极评论 # neg.txt 每行一条消极评论 sentiment.train(pos.txt, neg.txt) sentiment.save(sentiment.marshal)训练数据的组织方式很简单积极评论写入pos.txt消极评论写入neg.txt每行一条。SnowNLP 训练完成后会把模型保存到当前目录。这里有个重点重新训练不是为了替代模型而是为了让它在微博语境下更可用。每类评论建议至少准备 1500 条太少的话训练出来的模型反而不如默认版本。提示评论里常见的“绝绝子”“YYDS”“破防”这类网络热词在传统词典里是缺失的。你可以把这类词补充到训练语料对应的积极或消极文本里这是词典方案成本最低的调优方式。4.4 用标注数据微调一个轻量模型什么情况下值得做当评论数据量到了 10 万条以上或者你需要对情感分析结果做长期监控时微调一个中文预训练文本分类模型是更值得投入的方向。这里不展开完整训练代码先说透参数和踩坑点因为常见做法就是用开源的 transformers 工具链跑三五个 epoch。微调模型的参数表以我常用的配置为例参数经验值说明训练集每类至少 3000 条太少会严重过拟合batch_size16评论短小大 batch 意义不大learning_rate2e-5超过 3e-5 容易训飞epochs3首轮跑 3 轮观察验证集max_len64大部分微博评论不超过 64 字这个配置不是理论最优而是从大量实验里沉淀出的“不容易翻车”的组合。情感分析的训练非常容易出现过拟合因为短文本特征太稀疏模型背答案很快泛化能力却很差。所以训练集和验证集要按时间切分用前 80% 的时间段做训练后 20% 做验证模拟真实场景下的时间漂移。微调模型的价值在于它能学到微博特有的语气和表达。同一句“哈哈哈哈”在不同上下文里可能是嘲讽也可能是真开心模型能捕捉到前面那句话的语境这是词典方案做不到的。但代价是标注成本。如果项目只是做一次性分析数据量又不大投入标注和训练完全不划算词典方案已经足够。4.5 情感分数如何落回“微博分析”情感分析的结果不是终点它要服务于“微博分析”这个目标。最简单的分析维度是看整体正负分布但要避免一个陷阱低赞的高重复评论会稀释真实情绪。所以我一般会做两层计算一层是等权平均一层是点赞加权。def sentiment_distribution(df): positive (df[sentiment] 0.6).mean() negative (df[sentiment] 0.4).mean() neutral 1 - positive - negative return positive, neutral, negative def weighted_sentiment(df): total_likes df[like_count].sum() if total_likes 0: return df[sentiment].mean() return (df[sentiment] * df[like_count]).sum() / total_likes点赞加权平均的意义在于还原“舆论共识”。一条只有 1 个赞的反串评论和一条有 3000 个赞的热评对真实舆论的影响完全不同。如果等权平均显示负面比例很高但点赞加权显示整体偏正向通常说明负面声音集中在少量低赞评论里并没有形成舆情主流。这两个数字的差异本身就是分析结论。5. 微博评论爬虫避坑清单五个翻车现场、原因与解法5.1 页面能打开接口却 403现象浏览器里能看到评论区脚本发同样的请求返回 403有时连 HTML 页面都能打开接口就是不让进。原因通常是 Cookie 失效、请求头不全、访问特征太明显这三者之一。最常见的是从浏览器复制 Cookie 时没复制完整或者复制了一行带换行的文本导致请求头解析异常。另一个隐蔽原因是Referer字段缺失服务端会认为这不是从页面发起的合法请求。解决先打印 Cookie 长度做体检正常应该在 100 字符以上短于这个数基本是截断了。用requests.Session()保持会话不要每次请求新建连接。检查Referer是否正确指向该微博详情页。如果还不行手动在浏览器里访问一次评论接口确认当前登录态是否有效再换新的 Cookie 重跑。5.2 翻到后面全是重复评论现象数据量到几千条之后评论 ID 开始循环出现翻到第 40 页和第 41 页内容一样。原因评论接口用page参数做分页时有隐性限制深层翻页会落到服务端缓存的热评列表上而不是真正的全量评论。这是数据源层面的限制不是你的代码 bug。微博整个评论区动辄上万条能通过接口稳定拿到的往往是其中一部分。解决改用max_id游标分页。max_id是接口返回里自带的下一次请求标识用它翻页可以覆盖比page更深的范围。import random def fetch_with_max_id(weibo_id, cookie, max_pages50): session build_session(cookie) max_id 0 results [] for _ in range(max_pages): params { id: weibo_id, max_id: max_id, count: 50, } data session.get(COMMENTS_API, paramsparams).json() page_info data.get(data, {}) comment_list page_info.get(data, []) if not comment_list: break results.extend(comment_list) max_id page_info.get(max_id, 0) if not max_id: break time.sleep(random.uniform(1.5, 3.0)) return results用max_id时要注意max_id为 0 表示没有下一页如果某次请求返回的评论列表为空但max_id不为 0继续用新的max_id请求多次偶尔会恢复数据。我自己在统计结果时一定会标注“覆盖最近 N 条评论”不声称全量这是给自己留后路也是结论严谨性的底线。5.3 评论区里大量出现“已过滤”现象抓回来的评论文本字段就是“已过滤”三个字没有原文没有表情什么都分析不了。原因这条评论触发了平台审核机制或者评论者本身处于被限制的状态服务端向公开接口返回的就是“已过滤”占位文本而不是真实内容。这不是爬虫的问题是数据源本身有缺口你永远拿不到被过滤评论的原文。解决直接丢弃这类评论但要在统计里记录它的占比。如果“已过滤”占比超过 20%说明这条微博的评论区被平台干预的程度很高基于这份数据做的情感分析结论要谨慎下。我会单独输出一个字段filtered_ratio在最终报告里标注数据完整度避免拿着残缺数据做出武断结论。5.4 时间解析错位凌晨评论全部变成前一天现象跑完情感趋势分析发现凌晨 0 点到 6 点的评论全部落在前一天时间曲线出现了诡异的中断。原因时区没对齐。一种情况是用了time.gmtime()把时间戳转成了 UTC东八区的凌晨 2 点被转成了前一天下午 6 点另一种情况是解析“昨天”这个相对时间时用了服务器或容器的 UTC 时间作为参考点。解决解析相对时间时统一用本地时间datetime.now()不要用 UTC。处理绝对时间戳时先判断单位是秒还是毫秒再按东八区做偏移。最终存入数据库时统一用 pandas 的datetime64[ns]类型避免 Python 原生 datetime 和 pandas 类型混用导致精度错位。提示一个更省事的办法是记录采集时刻并写入每条数据这样任何时间转换出现问题都能用采集时刻做二次校准。5.5 连续采集三天后请求全失败现象第一天一切正常第二天开始部分请求失败第三天彻底连不上返回的提示基本是访问太频繁。原因采集行为被识别了。固定入口、固定频率、连续多天集中请求特征足够明显时就会被限制。很多人以为是 Cookie 失效换了新 Cookie 接着跑结果还是失败。解决把延时从固定值改成随机区间random.uniform(1.5, 3.5)单次采集时长控制在 30 分钟以内不要把脚本挂在服务器上全天跑。把全量抓取改成增量更新每次只抓新增部分请求量能降一个数量级。失败时做指数退避重试第一次失败等 30 秒第二次等 60 秒第三次等 120 秒超过三次就停下来发告警。不要试图靠硬扛来解决问题降低请求强度和缩短暴露时间是最可靠的做法。6. 把“能跑”变成“能看”情感趋势、关键意见与一个收尾习惯6.1 按小时聚合的情感趋势线现在你有了带时间戳和情感分数的评论表最直观的分析是看情感随时间的变化。我先按小时聚合再做一个小窗口的移动平均目的是平滑掉单点波动。df[hour] df[parsed_time].dt.floor(H) trend ( df.groupby(hour)[sentiment] .mean() .rolling(3, min_periods1) .mean() )这段代码把评论按小时切分算每个小时的平均情感分然后用 3 小时窗口做移动平均。如果某条微博发布后 1 小时情感分从 0.7 掉到 0.3说明舆论在快速转向如果全程平稳说明评论区没有出现明显对立。趋势线比单一的平均分更有分析价值。6.2 热评与情感分数的交叉验证模型打分和人工直觉需要互相印证。我的做法是拉出点赞数最高的 20 条评论逐个看模型打分是否合理。如果模型把明显嘲讽的评论打成正面说明模型还没有吃透当前语境的表达风格这时候整体情感分数不可信。更进一步的验证是用点赞数加权后的情感分与接近真实的舆论风向做对比。点赞加权分和人工感受差异很大时优先检查清洗环节是不是有大量评论没清干净把表情符号或 HTML 残留喂给了分析模型。十条常见的正确率如果达不到预期就回头查数据而不是急着换模型。6.3 我收尾时必做的三件事第一件事是抽十条评论做人工核对随机抽不挑顺眼的第二件事是把“已过滤”比例和疑似水军比例写进分析报告让结论的适用边界清清楚楚第三件事是把本次采集的评论总数和新增数记录下来下次采集时对比数字断崖式下跌往往意味着接口或登录态出了问题。我自己的经验是每一个情感分析项目第一版跑出来的结果都当成“能看见脏数据的版本”先人工核对再考虑是否值得继续投入。希望帮到你。本文还有配套的精品资源点击获取
