简介面向毕业设计与课程作业的 Python 酒店评论细粒度情感分析系统资源包。内容覆盖多源评论数据爬取、清洗、分词去停用词、属性抽取与情感极性判断等流程并支持基于 LSTM、BERT 等模型的细粒度分析及可视化展示适合自然语言处理初学者或需要快速搭建情感分析原型的开发者参考学习。压缩包内共 2000 个文件以 txt 数据文件为主包含约 2000 条正负面酒店评论、停用词表等另有 2 个 Python 脚本与 1 个说明文档整体大小仅 1.91MB便于直接下载使用。当前已有 98 人学习下载。资源提供了较完整的项目脉络从评论文本预处理到特征工程、PCASVM 或深度模型对比再到结果展示均有对应代码与数据支撑同时附有一份 README 说明可帮助快速理解目录结构与运行方式。对于正在做酒店评论情感分析相关课题或课程设计的学生这份资源能节省大量收集数据与搭建基础模型的时间直接作为系统原型或二次开发的起点。1. 基于python的酒店评论细粒度情感分析要拆的不是「好评差评」酒店评论里「位置好但隔音差」「早餐丰富不过电梯要等很久」这类句子很常见。粗粒度情感分析只能笼统给出正向或负向细粒度情感分析要做的是把「位置」「隔音」「早餐」「电梯」这些评价维度单独拆出来再对每个维度分别判断情感极性——同一个句子里位置是正、隔音是负系统要能同时给出这两种结论。基于 Python 实现这套系统核心工作落在三块能按酒店场景切分的评价维度体系、能联合完成「抽维度 判极性」的模型管线以及把人能看懂的结论送回前端的落地方案。本文按这条路线展开先定维度与标注规范再做数据清洗与增强然后讲多任务模型的选型和实现接着用 Streamlit 搭出可操作的系统界面最后给出跨维度一致性检验这种生产环境里最值得做的验证方法。适合已经会用 Python 做文本分类、想往细粒度方向深挖的读者也是酒店OTA做口碑拆解的常见做法。2. 先定义「细」到什么程度酒店评论的维度体系与训练数据准备细粒度情感分析落地时第一步不是选模型而是定义「细粒度」的边界。酒店评论里常见的维度包括位置、价格、房间、设施、服务、餐饮、卫生七类具体到某条评论可能同时涉及「房间」和「服务」两个维度。设计维度体系时我一般遵循两个原则一是每个维度在语义上互斥不出现「房间」和「床品」同时在一条评论里被当两个维度的情况二是维度数量控制在 5~8 个太多会让标注一致性和模型收敛都变得困难。2.1 七维度标注规范与数据来源以 7 个维度为例需要预先约定每个维度的别名表和判断规则。例如「服务员态度冷淡」应归到「服务」而不是「餐饮」「早餐的粥是凉的」归到「餐饮」「床垫太软」归到「房间」「停车场收费贵」归到「设施」或「位置」按实际语境判定。这个判定规则必须写进标注文档否则多人标注时一致性会崩掉。数据来源最常见的是爬取公开的酒店点评内容这里有一个值得注意的点爬取数据只用于模型训练和学术验证不用于商业发布。常见做法是用requests加限速策略去抓取公开页面再把内容做成 CSV结构为review_id, city, hotel_name, content, aspect_terms, polarities。import requests import time import pandas as pd from bs4 import BeautifulSoup def fetch_reviews(url, max_pages10): reviews [] for page in range(1, max_pages 1): resp requests.get(f{url}?page{page}, headers{User-Agent: Mozilla/5.0}) soup BeautifulSoup(resp.text, html.parser) for item in soup.select(.review-item): content item.select_one(.review-content).text.strip() reviews.append({content: content}) time.sleep(2) # 限速避免对目标站造成压力 return reviews if __name__ __main__: data fetch_reviews(https://example-hotel-reviews.com/beijing) df pd.DataFrame(data) df[aspect_terms] df[polarities] df.to_csv(hotel_reviews_raw.csv, indexFalse, encodingutf-8-sig)字段含义aspect_terms是人工标注出的评价维度多个维度用逗号分隔例如「位置,隔音」polarities与之一一对应例如「正向,负向」。注意aspect_terms和polarities在抓取时留空后续通过标注工具填充不要在采集阶段让爬虫去猜情感这会把噪声带进标注环节。2.2 标注工具选择与一致性校验标注时不需要开发复杂的前端常见做法是用 doccano 这类开源标注工具。Doccano 支持序列标注和文本分类两种模式对于「抽维度 判极性」的任务建议用序列标注模式框选「位置」「隔音」等词再打上「B-Aspect」「I-Aspect」和「Pos」「Neg」「Neu」标签。这样一次标注同时得到维度边界和情感极性避免两次标注带来不一致。标注完成后要算一致性。两人标同一批数据时用 Cohens Kappa 或简单的 F1 值衡量。酒店评论场景下 Kappa 低于 0.7 就需要回头修订维度定义。这一条在实操中经常被跳过结果就是模型训练时一个「位置」标签在标注文档里有三种理解最终准确率卡在 70% 上不去。2.3 数据增强与类别不平衡处理酒店评论数据天然存在两个不平衡一是「位置」维度出现频率远高于「隔音」二是正样本好评远多于负样本。常见做法是用回译做轻度增强保留原句的同时生成同义句更稳妥的方式是聚焦于改善真实数据而不是合成数据。这里给出一个小技巧对低频维度做句子级过采样即在每个 batch 里以一定概率重复包含「隔音」「电梯」等低频词的样本。import random def oversample_by_aspect(df, aspect隔音, repeat_ratio0.3): aspect_df df[df[aspect_terms].str.contains(aspect)] rest_df df[~df[aspect_terms].str.contains(aspect)] expanded aspect_df.sample(fracrepeat_ratio, replaceTrue, random_state42) return pd.concat([df, expanded], ignore_indexTrue) df_aug oversample_by_aspect(pd.read_csv(hotel_reviews_annotated.csv), aspect隔音)这里的逻辑是低频维度样本占比小模型很容易学到「预测多数类」的捷径过采样让模型在训练时更频繁看到「隔音」样本本质上是调整了损失函数中各维度的权重。repeat_ratio一般取 0.2~0.4过大会导致模型对少量样本过拟合验证集上其他维度反而掉点。3. 细粒度情感分析模型选型从管道方案到多任务联合抽取拿到标注数据后设计建模方案。常见做法是两种路线一是用「命名实体识别抽维度 文本分类判极性」的管道方式二是用多任务学习让两个子任务共享编码层。酒店评论场景下我通常直接选多任务方案。3.1 为什么不用「先抽取后判断」的管道方案管道方案在工程上思路直观先跑一个 NER 模型抽出「位置」「隔音」等词再把抽出的词和原句拼在一起输入情感分类器。问题是误差会累积NER 抽错一个边界情感分类器就对着错误的片段判断结果全错而且管道方式需要维护两个模型部署两套推理服务线上延迟翻倍。多任务方案让两个任务共享 BERT 层只在输出层分成两个 head。好处是分词、语义表示只做一遍训练时损失函数同时优化「维度边界识别」和「极性判断」模型在一个任务上学到的特征能被另一个任务复用。酒店评论这种短文本场景下效果提升不算特别大但代码更集中维护成本明显降低。3.2 基于 BERT 的多任务细粒度情感模型结构模型结构采用共享 BERT 编码层加两个输出头一个头做序列标注识别评价维度在句子中的起止位置另一个头做序列分类判断每个位置对应的情感极性。训练时两种损失相加最后取极性与最接近的维度词对齐。import torch import torch.nn as nn from transformers import BertModel, BertTokenizer ASPECTS [位置, 价格, 房间, 设施, 服务, 餐饮, 卫生] POLARITIES [POS, NEG, NEU] class AspectPolarityModel(nn.Module): def __init__(self, model_namebert-base-chinese, num_aspectslen(ASPECTS), num_polaritieslen(POLARITIES)): super().__init__() self.bert BertModel.from_pretrained(model_name) self.aspect_head nn.Linear(self.bert.config.hidden_size, num_aspects 1) # 加一个非评价维度类型 self.polarity_head nn.Linear(self.bert.config.hidden_size, num_polarities) def forward(self, input_ids, attention_mask, aspect_labelsNone, polarity_labelsNone): outputs self.bert(input_idsinput_ids, attention_maskattention_mask) sequence_output outputs.last_hidden_state aspect_logits self.aspect_head(sequence_output) polarity_logits self.polarity_head(sequence_output) loss None if aspect_labels is not None and polarity_labels is not None: loss_fct nn.CrossEntropyLoss(ignore_index-100) # aspect_head 只计算有效 token忽略 padding 部分 aspect_loss loss_fct(aspect_logits.view(-1, aspect_logits.size(-1)), aspect_labels.view(-1)) polarity_loss loss_fct(polarity_logits.view(-1, polarity_logits.size(-1)), polarity_labels.view(-1)) loss aspect_loss polarity_loss return aspect_logits, polarity_logits, loss参数说明num_aspects 1中特殊加出的 1 是「非评价维度」类别用于标记句子中流水词、标点等不承载评价信息的 tokenignore_index-100是 PyTorch 中标记忽略位置的常规做法保证 padding 部分不参与 loss 计算。bert-base-chinese直接处理中文不需要额外分词成词向量酒店评论这种短文本里效果比 word2vec 加 BiLSTM 的组合高出一截。3.3 训练时要注意的数据编码细节数据编码阶段要把句子转成 BERT 的输入格式。酒店评论长度通常在 50~200 字直接截断会丢失全句语义所以统一设定max_length128超出部分丢弃尾部确保 batch 内长度一致。from transformers import BertTokenizer, DataCollatorWithPadding from datasets import Dataset tokenizer BertTokenizer.from_pretrained(bert-base-chinese) def encode_fn(examples): encoded tokenizer( examples[content], max_length128, truncationTrue, paddingmax_length, return_tensorsNone ) # 将 aspect_terms 和 polarities 转换为 token 级标签的代码略去核心是 word_ids 对齐 return encoded dataset Dataset.from_pandas(df_aug).map(encode_fn, batchedTrue) data_collator DataCollatorWithPadding(tokenizertokenizer, paddinglongest)这里paddingmax_length在训练时统一用 128 长度好处是 tensor shape 固定避免边角 batch 报错推理时改为paddingTrue按 batch 内最长句填充省显存。很多 python 新手在这里会踩一个坑把tokenizer对象直接传入Dataset.map结果 tokenizer 在 batched 模式下无法被打包直接在环境里跑就一直报「请安装缺失的包」一类的错误。3.4 模型效果验证看什么指标细粒度场景下不能只丢一个准确率出来。正确做法是对每个维度分别计算精确率、召回率和 F1。在测试集上按维度聚合评估代码from sklearn.metrics import classification_report y_true [POS, POS, NEG, NEG, POS] y_pred [POS, POS, POS, NEG, POS] print(classification_report(y_true, y_pred, labels[POS, NEG, NEU], zero_division0))分类报告里要重点观察两个点一是「NEG」类的召回率如果偏低说明模型把负面评价误判成中性二是「NEU」类的精确率这个类别经常被模型大量预测导致整个系统看起来「安全」但信息量很低。对酒店评论系统来说宁可错判极性也不要把评价维度漏掉所以调参时常把 aspect loss 的权重调高 0.1~0.3。4. 系统设计与实现从模型到可操作的细粒度情感分析界面模型训练完成后要把它变成系统。整体流程是用户输入或导入评论后端调用训练好的模型推理结果按酒店维度拆解后展示在界面里。这里用 Streamlit 做前端理由很简单Python 生态内构建轻量应用最快一张页面能同时呈现维度命中和极性判断不需要额外起前后端两个服务。4.1 系统模块划分与数据流系统分三层数据接入层负责加载模型和接收文本模型推理层统一从model.predict()入口读取结果展示层用 Streamlit 和 pandas 渲染。推理层封装成独立类是这套设计的核心。import torch from transformers import BertTokenizer MODEL_PATH ./checkpoints/aspect_polarity_model tokenizer_path ./checkpoints/aspect_polarity_tokenizer class HotelSentimentModel: def __init__(self, model_pathMODEL_PATH, tokenizer_pathtokenizer_path): self.device torch.device(cuda if torch.cuda.is_available() else cpu) self.tokenizer BertTokenizer.from_pretrained(tokenizer_path) self.model AspectPolarityModel() self.model.load_state_dict(torch.load(model_path, map_locationself.device)) self.model.to(self.device) self.model.eval() def predict(self, text): inputs self.tokenizer(text, return_tensorspt, truncationTrue, max_length128) with torch.no_grad(): aspect_logits, polarity_logits, _ self.model(input_idsinputs[input_ids].to(self.device), attention_maskinputs[attention_mask].to(self.device)) # 将 logits 转为具体标签再用启发式将维度词与极性对应 aspect_ids aspect_logits.argmax(dim-1).squeeze().tolist() polar_ids polarity_logits.argmax(dim-1).squeeze().tolist() return {aspect_ids: aspect_ids, polarity_ids: polar_ids}self.model.eval()必须在推理前调用否则 dropout 层仍处于开启状态同一句话每次预测结果都会抖动。将模型加载封装在类的__init__里是为了避免 Streamlit 的脚本重跑机制在每次交互时重新装入一次权重后面讲冷启动策略时还要针对这个再做缓存。4.2 Streamlit 页面逻辑与状态管理Streamlit 的脚本重跑机制对模型推理不太友好页面任何按钮触发都会重跑整个脚本。我的做法是用st.session_state缓存模型只让模型加载一次。import streamlit as st import pandas as pd st.cache_resource def load_model(): return HotelSentimentModel() model load_model() st.title(酒店评论细粒度情感分析系统) input_text st.text_area(输入一条酒店评论, height120) if st.button(分析) and input_text.strip(): with st.spinner(模型推理中...): raw_result model.predict(input_text.strip()) result parse_result(raw_result, input_text.strip()) # 将 token 标签映射为维度极性 df pd.DataFrame(result, columns[评价维度, 情感极性, 对应原文片段]) st.dataframe(df, use_container_widthTrue)用st.cache_resource装饰加载模型的方法模型只会被初始化一次后续重跑直接命中缓存。st.dataframe直接把 pandas DataFrame 渲染成可滚动表格比st.write有更好的视觉效果。这里不推荐把模型直接放进session_state因为 Streamlit 官方对cache_resource的语义就是给「大对象、加载昂贵、无状态」用的模型正好符合。4.3 从标签到人话回复模板设计模型输出的是 token 级的标签序列例如aspect_ids可能是[0, 0, 5, 5, 0, 2, 2]对用户来说不可读。系统要有把离散标签翻译回自然语言摘要的能力。DIMENSION_MAP { 0: 无法识别, 1: 位置, 2: 价格, 3: 房间, 4: 设施, 5: 服务, 6: 餐饮, 7: 卫生 } POLARITY_MAP {0: 正向, 1: 负向, 2: 中性} def parse_result(raw, original_text): aspect_ids, polar_ids raw[aspect_ids], raw[polarity_ids] seen set() rows [] for i, (aid, pid) in enumerate(zip(aspect_ids, polar_ids)): dim DIMENSION_MAP.get(aid, 无法识别) if dim in seen or dim 无法识别: continue seen.add(dim) rows.append([dim, POLARITY_MAP.get(pid, 中性), original_text[max(0, i-3): i3]]) return rows注意seen集合的作用同一句里重复出现的相同维度只保留第一次结果避免一条「卫生」被拆成三个重复行。这种规则在工程上是必要的模型经常会针对同一维度输出多个连续标签用去重能把结果收敛到用户可读的粒度但如果你的需求是想看每个维度出现在句子里的多个位置就去掉这个去重逻辑。4.4 冷启动与热启动前面的部署动作直接决定了交互体验酒店评论细粒度分析系统在 Streamlit 里冷启动较慢最大开销是加载 BERT 模型权重。常见做法是把模型序列化为state_dict存到本地启动时直接load_state_dict也可以先用 ONNX 做精度对齐再在推理端启用加速。下面给出冷启动时的判断逻辑if initialized not in st.session_state: with st.spinner(请稍候模型加载中...): model load_model() st.session_state[initialized] True else: model load_model()这段代码的价值在于页面第一次打开时会走加载分支之后每次交互直接走else分支拿缓存模型不会再等。很多 python 入门者不理解 Streamlit 重跑机制把加载逻辑写在顶层结果每次点按钮都要等十几秒然后误以为是模型太慢其实是加载逻辑写错了位置。下表展示了前端反馈粒度与模型能力的对应关系前端反馈方式对应模型输出粒度多任务模型是否需要改造整体好评率/差评率全句二分类不需要直接用极性 logits 做聚合分维度柱状图/雷达图多个维度的各自极性不需要parse_result 后按维度聚合原文中高亮维度词token 级 BIO 标签需要把 aspect_head 输出映射回原文位置时间趋势分析多日/多酒店聚合结果需要后端额外存时间戳字段5. 生产环境里最值得做的验证跨维度一致性检验与维度级 A/B 测试模型上线前除了常规的准确率和 F1细粒度情感分析系统还应该做一项专项验证——跨维度一致性检验。它的目标很明确确保「位置好但隔音差」这类包含多个维度的评论系统给出的判断是合理且可解释的而不是维度之间互相矛盾。5.1 一致性公式要看的不是总体正确率系统在一条评论里同时输出「位置为正向」「隔音为负向」这两个判断不能互相矛盾。常见的做法是设定一致性约束同一维度在不同句子中语义相近的描述要得到相同的极性判断。例如「离地铁站近」和「步行到地铁站只要几分钟」都应判位置为正向如果一条判正向、一条判负向一致性低。一致性计算在工程上用一个简单的比值第i个维度的一致性 该维度预测结果与其语义近邻样本预测结果一致的个数 / 该维度近邻样本总数用余弦相似度找语义近邻再比对预测结论。这块代码推荐放到模型评估阶段跑from sklearn.metrics.pairwise import cosine_similarity def dimension_consistency(model, samples, dim位置, threshold0.6): embed_fn lambda text: model.tokenizer(text, return_tensorspt)[input_ids].mean(dim1) embs [embed_fn(s[content]).numpy() for s in samples] sim cosine_similarity(embs) count, total 0, 0 for i in range(len(samples)): for j in range(len(samples)): if i j or sim[i][j] threshold: continue total 1 if predict_dim(samples[i][content], dim) predict_dim(samples[j][content], dim): count 1 return count / max(total, 1)threshold0.6的设定依据是酒店评论这种词数少、句式相近的场景余弦相似度过低会引入大量无关样本过高则找不到足够近邻。predict_dim是拿模型对某个维度单独抽出来做预测的封装。建议该指标在 0.8 以上再放行上线否则要回头检查标注一致性或多任务权重配比。5.2 打个热补丁为模型加一个小白规则层任何纯模型方案在细粒度情感分析里都会有偶发的低级错误——把「免费矿泉水」判为「价格负向」把「前台办理很快」判为「服务中性」。这类错误不需要重新训练生产环境里更常见、更可靠的做法是加一个轻量规则层覆盖高频的否定词和转折词做一个修正用的黑白名单。规则类型触发条件修正动作否定词修正「不」「没」「无」紧邻维度词极性取反但不取反「不方便」这类本身含否定语义的词程度词修正「非常」「太」「极」极性强度调高一档展示层加语气词转折修正「但是」「不过」之后的维度后半句权重更大优先采用后半句的极性这个规则层和深度学习模型配合时优先级设在模型输出之后、展示之前。以 VSCode 配置 python 环境时安装额外依赖同理规则层就相当于一个轻量的补丁包不动骨架只动输出。这个做法在调用模型预测 5000 条历史评论做回归测试时能明显压低那些系统性误判。5.3 维度抽取的兜底策略上面规则层解决的是已然在维度列表内的场景更残酷的现实是模型偶尔会漏掉整段维度。面对「酒店隔音极差一晚上没睡着」这种情况规则层抽到「隔音」直接判负向能兜住但如果模型输出给的是无法识别系统就直接丢失这条有效的用户反馈。兜底做法是把原始文本切成短句逐句跑一遍关键词匹配命中维度词表就强制补一个结果进去。def fallback_aspect_fill(raw, model_result): dims [隔音, 位置, 早餐, 停车, 设施, 卫生, 电梯, 前台] for dim in dims: if dim not in [r[0] for r in model_result] and dim in raw: model_result.append([dim, 无法识别, raw[:10] ...]) return model_result这种补丁式逻辑看起来不够「机器学习」但酒店评论场景里它直接提高了维度召回率。提示补进去的无法识别极性不能参与后续统计否则这类带噪声样本会拉低整个数据面板的有效率给前端画框架图抽数据时也别把这类样本卷进去。到这里基于 Python 的酒店评论细粒度情感分析系统算是能落成一个可交付的纵向切片了。做好维度定义、把多任务模型和规则层接在一起、在部署时用缓存解决冷启动再把一致性校验跑进上线流程——这套做法足够撑起一个面向单酒店或区域酒店群的评论分析工具。本文还有配套的精品资源点击获取