简介本资源是一套面向数据科学初学者与NLP实践者的大众点评评论文本挖掘完整项目覆盖从网页爬取、数据清洗、结构化入库到情感分析与可视化展示的全流程实战。项目采用Python技术栈包含6个Jupyter Notebook含爬虫实现、探索性数据分析、情感分析建模等核心模块、3个Python脚本含代理IP管理、MySQL入库、停用词处理、3个文本文件含自定义停用词、示例数据、说明文档及配套图表与字体资源共24个文件压缩包大小18.99MB。目录结构清晰模块解耦合理便于分阶段学习与调试代码注释详实关键步骤附有执行说明与结果截图6张PNG并提供可直接运行的CSV样本与MySQL配置支持。目前已有113人学习下载适合希望掌握真实场景下文本挖掘工程化落地能力的学习者尤其有助于理解电商评论类数据的采集规范、清洗逻辑与情感判别模型构建方法。1. 大众点评评论文本挖掘为什么爬完数据反而更难做分析你花两天写好爬虫成功抓下 50 万条餐厅评论兴冲冲导入 MySQL——结果发现37% 的文本是“好吃”“不错”“还行”21% 带 emoji 和乱码如“太赞了”14% 是复制粘贴的团购文案“环境优雅服务周到性价比高…”还有 8% 是纯数字标点组合“⭐⭐⭐⭐⭐ 2023.05.12 19:32”。这不是数据量不够而是原始评论天然携带噪声、冗余、非结构化和语义漂移——这正是大众点评文本挖掘最真实的起点。本项目不是教你怎么“拿到数据”而是解决“拿到之后怎么让数据真正可用”从真实爬取反爬策略非模拟登录、无 Selenium、清洗时保留地域/时间/星级等业务维度、构建可复用的清洗 pipeline、用轻量级模型做细粒度情感归因不止“正面/负面”还要识别“服务差”还是“上菜慢”最后落地为可查询的分析看板。适合已有 Python 基础、做过简单爬虫但被清洗卡住、想把评论变成业务指标如“某商圈服务类差评率环比上升12%”的工程师与分析师。2. 爬取大众点评评论绕过动态渲染与频率限制的最小可行方案大众点评前端大量使用 React 动态加载且对 IP、User-Agent、Referer、Cookie 组合校验极严。直接 requests.get 返回空 divSelenium 启动浏览器又慢又易被识别。我们采用“接口逆向 请求头精细化构造 分布式请求节流”三阶策略不依赖任何第三方库如 playwright、scrapy-splash全程用原生 requests json 实现。2.1 定位真实评论接口并提取参数规律打开大众点评某餐厅页如 https://www.dianping.com/shop/xxxxx/review_allF12 打开 Network → XHR筛选关键词review找到类似请求https://www.dianping.com/ajax/bizrev/reviewlist?shopIdxxxxxcityId10pageSize20currentPage1sortType0关键发现shopId在页面 HTML 中以meta nameshop-id contentxxxxx存在需先 GET 页面解析cityId非固定值但可通过城市拼音映射表获取如shanghai→10,beijing→2该表已内置在项目config/city_map.jsonsortType0表示“最新”1为“最热”业务上建议固定用0避免热度排序导致新店评论缺失currentPage从 1 开始但实际返回总页数藏在响应 header 的X-Total-Page字段中而非响应体这是翻车高发点。2.2 构造抗检测请求头与会话管理大众点评校验以下 5 项组合缺一即返回 403Header 字段必须值示例说明User-AgentMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36必须匹配主流浏览器最新 UA且需随请求轮换项目内置 12 条 UA 池Refererhttps://www.dianping.com/shop/xxxxx/review_all必须带完整 shop URL且域名后缀不能少/Cookiesafedkxxx; _lxsdk_cuidxxx; _lxsdkxxx;必须包含_lxsdk_cuid和_lxsdk二者通过首次访问首页https://www.dianping.com自动 set不可伪造X-Shardsxxx由shopId经简单哈希生成算法见utils/shard_gen.py非固定值Acceptapplication/json, text/plain, */*必须包含application/json提示Cookie 中_lxsdk_cuid和_lxsdk是会话标识每次启动新会话前必须先 GET 一次首页获取否则所有请求均失败。项目crawler/session_manager.py封装了自动刷新逻辑。2.3 实现分页爬取与异常熔断# crawler/fetch_reviews.py import requests from utils.session_manager import get_valid_session from utils.shard_gen import generate_shard def fetch_shop_reviews(shop_id: str, city_id: str 10) - list: session get_valid_session() # 自动处理 Cookie 刷新 reviews [] page 1 while True: url fhttps://www.dianping.com/ajax/bizrev/reviewlist params { shopId: shop_id, cityId: city_id, pageSize: 20, currentPage: page, sortType: 0 } headers { User-Agent: get_random_ua(), # 轮换 UA Referer: fhttps://www.dianping.com/shop/{shop_id}/review_all, X-Shard: generate_shard(shop_id), # 动态生成 Accept: application/json, text/plain, */* } try: resp session.get(url, paramsparams, headersheaders, timeout10) if resp.status_code ! 200: raise Exception(fHTTP {resp.status_code}) data resp.json() if not data.get(reviewList): break # 无数据则退出 reviews.extend(data[reviewList]) total_pages int(resp.headers.get(X-Total-Page, 1)) if page total_pages: break page 1 except Exception as e: print(fPage {page} failed: {e}) # 熔断连续 3 次失败则 sleep 60s 并重置 session if page % 3 0: time.sleep(60) session get_valid_session() continue return reviews逻辑说明get_valid_session()内部先 GET 首页再提取并缓存 Cookie避免每次请求都刷新generate_shard(shop_id)使用xxhash.xxh32(shop_id).hexdigest()[:8]生成实测通过校验X-Total-Page从 header 读取而非响应体这是官方未文档化的关键字段熔断机制防止 IP 被封连续失败时重置会话 延迟比单纯 retry 更有效。3. 数据清洗入库用 pandas 做结构化转换同时保留原始语义线索爬取的 JSON 原始字段杂乱reviewInfo嵌套 3 层、userLevel是数字编码1新手5钻石、star是字符串5星、reviewText含 HTML 标签和广告文案。清洗目标不是“删干净”而是构建可分析的中间表结构一张reviews主表含 cleaned_text、sentiment_label、service_score 等一张review_tags标签关联表存储“上菜慢”“服务员态度差”等细粒度标签一张shop_meta店铺元数据表用于后续商圈分析。全部用 pandas 处理不依赖 Spark单机 100 万条以内足够。3.1 定义清洗 pipeline 与字段映射规则清洗不是线性流程而是分阶段、可回溯的 pipeline基础字段提取从嵌套 JSON 提取shop_id,user_id,review_time,star_num从5星→5文本净化移除 HTML 标签、广告短语如“【美团】”“【大众点评】”、重复标点→语义增强在cleaned_text中显式插入结构化标记如[服务:差][上菜:慢]供后续情感分析定位标签抽取基于规则 词典匹配识别“价格贵”“WiFi 不好”等 23 类常见槽位存入review_tags质量过滤剔除10 字或90% 数字/标点的低质评论如“⭐⭐⭐⭐⭐ 2023-05-12”。注意[服务:差]这类标记不参与模型训练仅作人工校验与下游分析索引避免模型学习虚假模式。3.2 实现可复用的清洗函数与配置驱动# clean/pipeline.py import re import pandas as pd from typing import List, Dict # 预编译正则提升性能 HTML_PATTERN re.compile(r[^]) AD_PATTERN re.compile(r【[^】]】|【.*?】) EMOJI_PATTERN re.compile(r[^\w\s\u4e00-\u9fff]) REPEAT_PUNCT re.compile(r([!?.。]){2,}) def clean_review_text(text: str) - str: if not isinstance(text, str): return # 1. 移除 HTML text HTML_PATTERN.sub(, text) # 2. 移除广告标记 text AD_PATTERN.sub(, text) # 3. 合并重复标点 text REPEAT_PUNCT.sub(r\1, text) # 4. 清理多余空格 text re.sub(r\s, , text).strip() return text def extract_tags(text: str) - List[str]: 基于词典匹配抽取细粒度标签返回如 [服务:差, 上菜:慢] tags [] # 词典定义在 config/tag_dict.yaml含 23 类槽位及关键词 for slot, keywords in TAG_DICT.items(): for kw in keywords: if kw in text: # 匹配“上菜慢” → 上菜:慢“服务员态度差” → 服务:差 tag f{slot}:{get_sentiment_by_keyword(kw)} if tag not in tags: tags.append(tag) return tags def build_clean_df(raw_data: List[Dict]) - pd.DataFrame: df pd.DataFrame(raw_data) # 字段映射 df[shop_id] df[shopId] df[user_id] df[userId] df[review_time] pd.to_datetime(df[reviewTime], unitms) df[star_num] df[star].str.extract(r(\d)星).astype(int) df[raw_text] df[reviewText] df[cleaned_text] df[raw_text].apply(clean_review_text) df[tags] df[cleaned_text].apply(extract_tags) # 质量过滤长度 10 或数字/标点占比 70% df[text_len] df[cleaned_text].str.len() df[punct_ratio] df[cleaned_text].apply( lambda x: len(re.findall(r[!?.。\d], x)) / len(x) if x else 0 ) df df[(df[text_len] 10) (df[punct_ratio] 0.7)] return df[[shop_id, user_id, review_time, star_num, cleaned_text, tags]]参数说明TAG_DICT从config/tag_dict.yaml加载格式为服务: [服务员态度, 服务差, 态度不好, 服务一般] 上菜: [上菜慢, 等了很久, 上菜太慢, 催了三次]get_sentiment_by_keyword(kw)是简单映射函数如含“差/不好/慢”→“差”含“好/赞/棒”→“好”不依赖模型保证可解释性punct_ratio过滤阈值设为 0.7实测能筛掉 92% 的无效数字串同时保留“价格¥88很值”这类有效信息。3.3 批量入库与索引优化清洗后 DataFrame 直接写入 MySQL不建视图、不触发存储过程用pandas.to_sqlON DUPLICATE KEY UPDATE实现幂等写入# clean/db_writer.py from sqlalchemy import create_engine def write_to_mysql(df: pd.DataFrame, table_name: str): engine create_engine(mysqlpymysql://user:pwdlocalhost:3306/dp_mining) # 主表 reviews设置 shop_iduser_id 为联合主键避免重复插入 df.to_sql( table_name, conengine, if_existsappend, indexFalse, methodmulti, chunksize1000, dtype{ shop_id: sqlalchemy.types.VARCHAR(32), user_id: sqlalchemy.types.VARCHAR(32), review_time: sqlalchemy.types.DATETIME, star_num: sqlalchemy.types.SMALLINT, cleaned_text: sqlalchemy.types.TEXT, } ) # 标签表 review_tags需拆解 tags 列为多行 tags_records [] for _, row in df.iterrows(): for tag in row[tags]: tags_records.append({ shop_id: row[shop_id], user_id: row[user_id], tag: tag, created_at: datetime.now() }) pd.DataFrame(tags_records).to_sql( review_tags, conengine, if_existsappend, indexFalse, chunksize1000 ) # 执行 clean_df build_clean_df(raw_reviews) write_to_mysql(clean_df, reviews)关键配置chunksize1000防止内存溢出10 万条评论约需 300MB 内存dtype显式指定字段类型避免 pandas 自动推断为object导致 MySQL 插入失败ON DUPLICATE KEY UPDATE依赖表结构中PRIMARY KEY (shop_id, user_id)确保同一用户对同一店铺的评论只存最新一条。4. 评论情感分析不用 BERT用规则轻量模型做可解释归因大众点评评论情感高度依赖上下文“贵”可能是“价格贵但值得”“小”可能是“店面小但温馨”。BERT 类大模型虽准但部署成本高、推理慢、无法解释“为什么判为负面”。本项目采用“规则初筛 TextCNN 微调 归因可视化”三级架构先用规则过滤明确情感词如“失望”“后悔”再用 TextCNN 对剩余文本分类最后用 LIME 生成局部解释如高亮“上菜慢”导致负面判定。模型在 10 万标注样本上训练准确率 89.2%推理速度 120 QPS单卡 T4。4.1 构建可解释的标注体系与数据集标注不按传统“正面/负面/中性”而是“主情感 槽位归因”双维度原始评论主情感槽位归因“上菜慢但菜品味道很好”中性[上菜:慢], [口味:好]“服务员爱理不理环境嘈杂”负面[服务:差], [环境:差]“性价比超高强烈推荐”正面[价格:好], [推荐:强]数据集来源人工标注 2 万条覆盖上海/北京/广州 3 城市半监督扩展用规则模板如“贵但”→中性“差”→负面生成 8 万条伪标签经人工抽检 95% 准确率后加入训练。提示标注重点不是“全量打标”而是覆盖长尾槽位如“停车难”“带娃友好”这些在通用语料中极少出现。4.2 TextCNN 模型实现与训练细节# model/textcnn.py import torch import torch.nn as nn from torch.nn import functional as F class TextCNN(nn.Module): def __init__(self, vocab_size, embed_dim, num_classes, filter_sizes(2,3,4), num_filters32): super().__init__() self.embedding nn.Embedding(vocab_size, embed_dim, padding_idx0) self.convs nn.ModuleList([ nn.Conv2d(1, num_filters, (fs, embed_dim)) for fs in filter_sizes ]) self.dropout nn.Dropout(0.5) self.fc nn.Linear(len(filter_sizes) * num_filters, num_classes) def forward(self, x): # x: [batch, seq_len] embedded self.embedding(x).unsqueeze(1) # [batch, 1, seq_len, embed_dim] conv_outs [] for conv in self.convs: # [batch, num_filters, seq_len-fs1, 1] conv_out F.relu(conv(embedded)).squeeze(3) # [batch, num_filters, seq_len-fs1] pool_out F.max_pool1d(conv_out, conv_out.size(2)).squeeze(2) conv_outs.append(pool_out) # [batch, num_filters * len(filter_sizes)] cat_out torch.cat(conv_outs, dim1) return self.fc(self.dropout(cat_out)) # 训练配置train.py model TextCNN(vocab_size50000, embed_dim128, num_classes3) optimizer torch.optim.Adam(model.parameters(), lr0.001) scheduler torch.optim.lr_scheduler.StepLR(optimizer, step_size3, gamma0.8) for epoch in range(10): for batch in train_loader: logits model(batch[input_ids]) loss F.cross_entropy(logits, batch[labels]) loss.backward() optimizer.step() optimizer.zero_grad() scheduler.step()关键参数说明filter_sizes(2,3,4)捕获 bi-gram“上菜慢”、tri-gram“服务员态度差”、quad-gram“WiFi信号不稳定”num_filters32平衡效果与显存T4 卡可跑 batch_size64dropout0.5防止过拟合实测比 0.3 更稳定lr0.001StepLR第 3/6/9 轮衰减避免早停。4.3 用 LIME 实现槽位级归因与可视化LIME 解释 TextCNN 输出定位影响分类的关键 n-gram# explain/lime_explainer.py from lime.lime_text import LimeTextExplainer def explain_prediction(model, tokenizer, text: str, class_names[负面, 中性, 正面]): explainer LimeTextExplainer(class_namesclass_names) def predict_proba(texts): # texts: list of str → tokenized → model output inputs tokenizer(texts, truncationTrue, paddingTrue, max_length128, return_tensorspt) with torch.no_grad(): logits model(inputs[input_ids]) probs F.softmax(logits, dim1).cpu().numpy() return probs exp explainer.explain_instance( text, predict_proba, num_features5, # 只显示 top5 关键词 top_labels1 ) return exp.as_list() # [(上菜慢, -0.42), (但, 0.18), ...] # 示例输出 explain_prediction(model, tokenizer, 上菜慢但菜品味道很好) # → [(上菜慢, -0.39), (但, 0.21), (菜品, 0.15), (味道, 0.12), (很好, 0.08)]归因逻辑负值表示该词推动预测向当前类别此处为“中性”的反方向即“上菜慢”是负面线索正值表示支持当前类别“但”“菜品”“味道”“很好”共同构成中性判断依据结果直接存入数据库review_explanations表字段含review_id,keyword,weight,slot由 keyword 匹配 tag_dict 自动填充。5. 避坑指南大众点评文本挖掘的 4 个血泪经验大众点评数据看似公开实则暗坑密布。以下 4 条是团队踩过、验证过、写进 SOP 的硬核避坑点每一条都曾导致整批数据报废或分析结论失真。5.1 爬取时忽略X-Total-Pageheader导致漏页率达 37%现象爬取某热门商场 200 家餐厅每家只拿到前 3 页评论实际平均有 12 页。原因大众点评接口返回的data.totalPage字段始终为 1前端 JS 会二次计算真实总页数只在 response header 的X-Total-Page中返回。解决强制从 header 读取X-Total-Page代码中必须写resp.headers.get(X-Total-Page, 1)绝不能解析响应体。5.2 清洗时删除所有 emoji误杀关键情感线索现象清洗后“环境很棒”变成“环境很棒”模型将“很棒”判为中性因语境缺失实际应为正面。原因emoji 在中文评论中承担 23% 的情感强度如 肯定否定热烈失望直接删除等于抹去半条情感链。解决用emoji.demojize()替换为文字如→:thumbs_up:再映射为情感权重:thumbs_up:→ 0.8保留在cleaned_text中。5.3 情感分析用通用词典如知网 HowNet对“贵”“小”等词误判率超 65%现象评论“这家店贵但食材新鲜”通用词典将“贵”标为负面模型整体判负忽略“但”后的转折。原因大众点评语境中“贵”常与“值”“新鲜”“正宗”共现需领域适配。HowNet 等通用词典未覆盖本地化表达。解决构建领域词典dp_sentiment_dict.txt收录 127 个歧义词及其上下文规则例如贵: {default: -0.5, context_after: [值, 新鲜, 正宗], weight: 0.3} 小: {default: -0.3, context_before: [店面, 包间], weight: 0.4}清洗时动态注入权重而非静态替换。5.4 MySQL 存储cleaned_text用VARCHAR(255)导致 18% 评论被截断现象入库后查询发现“排队两小时终于吃上了...省略 200 字”实际原文 327 字。原因MySQL 默认VARCHAR(255)限制长度而大众点评长评论平均 286 字P90312 字。解决建表时cleaned_text字段必须用TEXT类型并确认sql_mode不含STRICT_TRANS_TABLES否则超长插入报错而非静默截断。6. 把评论变成业务动作用分析结果驱动门店运营改进文本挖掘的价值终点不是报表而是可执行的运营指令。我们落地了三个闭环场景差评归因自动派单、竞品对比预警、商圈热度迁移分析。每个场景都对应一个 SQL 查询 一个 Python 脚本 一个企业微信机器人推送模板全部开源在analysis/目录下。6.1 差评归因自动派单从“服务差”到具体责任人目标当某门店“服务”类差评率负面标签含“服务:差”单日超阈值5%自动推送工单给店长并附带高频问题词云。-- analysis/daily_service_alert.sql SELECT shop_id, COUNT(*) FILTER (WHERE tag LIKE 服务:%) * 1.0 / COUNT(*) AS service_bad_rate, STRING_AGG(DISTINCT SPLIT_PART(tag, :, 2), , ) AS bad_reasons FROM reviews r JOIN review_tags t ON r.shop_id t.shop_id AND r.user_id t.user_id WHERE r.review_time CURRENT_DATE - INTERVAL 1 day GROUP BY shop_id HAVING COUNT(*) FILTER (WHERE tag LIKE 服务:%) * 1.0 / COUNT(*) 0.05;执行逻辑每日凌晨 2 点调度此 SQL结果写入alert_service_daily表Python 脚本analysis/alert_dispatcher.py读取该表调用企业微信 API 推送【服务预警】XX路店今日服务差评率 7.2%阈值 5% 高频问题态度冷淡(4次)、响应慢(3次)、结账错误(2次) 建议动作核查前台排班检查 POS 系统稳定性关键设计bad_reasons用STRING_AGG聚合避免推送 20 条重复“态度差”聚焦根因。6.2 竞品对比预警识别“被抢客”信号大众点评用户常在评论中提及其他店如“比隔壁老王家便宜”“没有 XX 餐厅上菜快”。我们构建“提及竞品”识别 pipeline从cleaned_text中抽取所有餐饮品牌名用jieba 自定义词典dict/restaurant_names.txt过滤非本商圈品牌如上海店提“北京海底捞”视为无效统计“提及频次”与“情感倾向”生成competitor_mention_reportshop_idcompetitormention_countavg_sentiments123c45612-0.62s123c78980.33提示avg_sentiment用 TextCNN 对提及句如“比 c456 便宜”单独打分非整条评论。当某店对竞品 A 的提及情感均值 ≤ -0.5 且频次 ≥5触发预警“顾客感知 c456 价格优势显著建议核查定价策略”。6.3 商圈热度迁移用评论地理坐标发现新消费聚集区大众点评评论含latitude/longitude从页面 JS 提取我们用 DBSCAN 聚类发现新兴热点# analysis/geo_cluster.py from sklearn.cluster import DBSCAN import numpy as np # 加载近30天带坐标的评论 df pd.read_sql(SELECT lat, lng FROM reviews WHERE review_time NOW() - INTERVAL 30 days, conn) coords df[[lat, lng]].values # DBSCAN 参数调优eps0.001≈110米min_samples50 clustering DBSCAN(eps0.001, min_samples50).fit(coords) df[cluster] clustering.labels_ # 输出新聚类中心排除 -1 噪声点 hotspots df[df[cluster] ! -1].groupby(cluster)[[lat, lng]].mean() hotspots.to_csv(output/new_hotspots.csv, indexFalse)业务落地将new_hotspots.csv坐标导入高德地图生成热力图对比历史热力图若某区域新增聚类且平均星级 ≥4.2标记为“潜力商圈”推送招商部实测案例上海虹桥火车站南广场2023Q4 新增聚类 3 个平均星级 4.5半年后引入 7 家首店。我坚持一个习惯所有分析脚本第一行必写# -*- coding: utf-8 -*-所有 SQL 查询必加WHERE review_time ?参数化所有模型预测必存confidence_score。不是教条而是过去三年里每一次线上事故都始于某个被忽略的编码、SQL 注入或置信度过低的误判。文本挖掘不是炫技是让每一句“好吃”背后都能指向厨房的火候、服务员的排班、甚至商圈的租金变化。希望帮到你。本文还有配套的精品资源点击获取