简介面向计算机、人工智能等专业学生设计的酒店评论情感分析系统是一套融合机器学习、自然语言处理与Flask Web展示的完整实践项目适合用于毕业设计、课程作业及NLP入门实践。系统以酒店评论文本为对象借助TF-IDF特征向量化与逻辑回归/XGBoost分类模型判别情感倾向用户只需通过浏览器输入评论文本即可得到实时预测反馈。压缩包共11个文件、约6.78MB涵盖Python应用脚本、3个HTML前端模板、多个pkl格式的模型与向量器、Jupyter分析笔记本、示例图片及README说明文档从原始数据到前端展示覆盖项目全流程。目前已有179人学习浏览项目结构清晰便于按需查阅。从使用价值看资源内置完整可运行的Flask应用与两个备选情感预测模型附带的Jupyter笔记完整记录了数据集探索、模型训练和性能评估过程读者可在此基础上扩展模型、替换界面或将其改造为其他文本分类场景适合参考和学习完整项目套路。1. 先搞清这个酒店评论情感分析系统解决什么问题我做 NLP 相关项目时最常遇到的需求不是“训练一个 99% 准确率的模型”而是“给我一条评论快速告诉我它是好评还是差评”。这个酒店评论情感分析系统 zip 包就是标准的这种落地形态它把文本清洗、TF-IDF 特征工程、逻辑回归训练、Flask Web 应用集成在一起用户打开浏览器输入一句“房间很干净但是隔音太差”页面直接返回情感倾向。项目里还额外放了一个 XGBoost 模型作为备选训练过程的完整思路记录在 Jupyter Notebook 里。适合的人群很明确做 NLP 入门实战、课程作业、毕业设计参考的人已经懂一点机器学习、想看看“模型怎么快速变成 Web 服务”的开发者也能从里面抄到一套成熟的组织方式。它给我的第一印象是“麻雀虽小链路完整”。没有云服务依赖没有复杂的分布式结构一个 Python 环境加几个库就能跑。这也意味着你可以把它当成一个模板换成电商评论、餐饮评论、客服工单情感分类都能复用同一套思路。下面我按“架构拆解 → 核心链路 → 模型对比 → 运行避坑 → 二次开发”的顺序把它掰开讲清楚。2. 架构与目录拆解Flask 应用、模型产物、HTML 模板各司其职2.1 技术栈选型为什么是 Flask 加 sklearn 体系这个项目的技术选型非常克制几乎没有多余组件。Web 层用 Flask因为推理服务本质上只需要一个表单页和一个结果回显页Flask 的内置 Jinja2 模板直接就够不需要上 Django 这种重型框架。机器学习层用 scikit-learn 的 LogisticRegression 接收 TF-IDF 向量理由是评论短文本在高维稀疏向量下线性模型的解释性和稳定性都够用且训练成本低。XGBoost 作为备选模型则是为了处理“词语组合关系”这种非线性特征时能有更高的上限。模型产物全部序列化保存为 pkl 文件这是这类推理项目的核心做法训练在 Notebook 里完成训练结束后把模型和向量器存成文件Web 应用启动时一次性加载到内存后续请求只做预测不做重训练因此响应速度能控制在几十毫秒级别。这里值得注意的一个点是向量器也必须保存。很多新手只存模型预测时重新 fit 向量器结果特征空间完全变化模型预测直接失效。这个项目把 vectorizer.pkl 和模型放在一起就是正确的教学示例。还有一个细节是代码里同时存在 logreg_model.pkl 和 xgboost_model.pkl 两个模型文件说明作者在训练阶段做了对比实验最终把两种产物都保留下来。这种“多版本模型共存”的做法我认为很值得参考——线上切换模型时不需要重新训练只需要改加载路径。2.2 目录结构与文件职责清单拿到 zip 包后解压出来大致是这样Sentiment-Analysis-of-Hotel-Reviews-main/ ├── app.py # Flask 应用入口路由 预测逻辑 ├── logreg_model.pkl # 逻辑回归情感分类模型 ├── xgboost_model.pkl # XGBoost 情感分类备选模型 ├── tfidf_vectorizer.pkl # 训练好的 TF-IDF 向量器 ├── vectorizer.pkl # 向量器的另一份副本或兼容产物 ├── sentimentAnalysisofHotelReviews.ipynb # 训练过程完整记录 ├── templates/ │ ├── index.html # 首页评论输入与结果展示 │ ├── hotel_detail.html # 单条酒店评论详情展示 │ └── recommendations.html # 推荐或聚合信息展示页 ├── image1.jpg # 页面配图素材 └── README.md # 项目说明文档逐个文件说作用。app.py 是整个系统的入口负责三个事加载 pkl 模型文件、接收前端表单提交的评论文本、调用模型预测并渲染 HTML 页面。logreg_model.pkl 是训练好的逻辑回归分类器它对外暴露 predict 和 predict_proba 两个方法predict 返回 0 或 1 的类别标签predict_proba 返回属于每个类别的概率具体怎么用我在第 3 章细讲。tfidf_vectorizer.pkl 是特征工程阶段的产物它保存了训练语料的词表、IDF 值等全部状态预测时只需要对新文本做 transform严禁重新 fit。templates 目录下三个 HTML 页面各有分工。index.html 是核心交互页包含一个文本域和一个提交按钮hotel_detail.html 在常见实现里负责展示单条评论的详细信息和对应情感预测可以理解成“点开某条评论看详情”recommendations.html 一般承载聚合维度的推荐或酒店排序结果。image1.jpg 是静态素材放在 templates 目录下是因为直接用它来做页面配图。2.3 Notebook 里的训练流程与任务边界sentimentAnalysisofHotelReviews.ipynb 是这个项目的“黑匣子揭秘手册”。我翻看这类 Notebook 时最关注几条线数据集是什么格式、正负样本怎么分布、清洗到什么程度、评估用了什么指标。虽然 zip 包里没有显式列出 CSV 数据集文件但 Notebook 里应该定义了数据的读取和预处理流程常见做法是读取包含评论文本和情感标签的表格标签化成为二分类目标也就是 0 表示负面、1 表示正面。这个项目要解决的任务边界需要提前说清楚它是“单条评论级”的情感分类不是“酒店级”的综合评分聚合。index.html 输入一句评论得到对应情感这是模型的主要能力。hotel_detail 和 recommendations 这类页面更多是展示层的扩展如果你想把“一个酒店下所有评论的预测结果汇总成综合好评率”那属于二次开发要做的聚合逻辑第 6 章我会给改造方向。3. 核心链路拆解一条酒店评论从文本到情感标签的完整旅程3.1 Flask 表单入口与模型加载先看 app.py 里最核心的一段这也是整个系统运行的主干。import os import joblib from flask import Flask, render_template, request app Flask(__name__) BASE_DIR os.path.dirname(os.path.abspath(__file__)) model joblib.load(os.path.join(BASE_DIR, logreg_model.pkl)) vectorizer joblib.load(os.path.join(BASE_DIR, tfidf_vectorizer.pkl)) app.route(/, methods[GET, POST]) def index(): prediction None comment if request.method POST: comment request.form.get(comment, ).strip() if comment: vec vectorizer.transform([comment]) label model.predict(vec)[0] prediction 正面评价 if label 1 else 负面评价 return render_template(index.html, commentcomment, predictionprediction) if __name__ __main__: app.run(debugTrue, port5000)逻辑说明应用启动时先从当前文件所在目录加载模型和向量器避免你在其他路径下启动导致找不到文件。路由同时支持 GET 和 POST首次访问是 GET返回空表单提交后是 POST从表单里取出 name 为 comment 的字段。拿到文本后先做 transform把字符串转成 TF-IDF 稀疏矩阵再喂给模型预测最后把结果和用户输入的原文一起塞给模板渲染。参数说明vectorizer.transform 接收的是一个列表不是字符串所以代码里用[comment]包了一层model.predict 返回的是一个一维数组取[0]是因为这里只预测一条评论。debugTrue 只在开发阶段用它会在代码变更后自动重载并且把报错信息直接显示在浏览器里部署到公网时一定要改成 debugFalse。3.2 TF-IDF 向量化为什么预测阶段只能 transformTF-IDF 是这类文本分类项目里最常见的特征化方案它做的事情是统计每个词在评论中出现的频次并用逆文档频率削弱“的、了、不错”这类高频词的权重。现在向量器已经被训练并保存预测阶段必须遵循一个铁律只 transform绝不重新 fit。new_comment 位置方便但是房间有点旧 new_vec vectorizer.transform([new_comment]) print(new_vec.shape) # (1, 特征维度)逻辑说明训练阶段 fit 会建立从词语到固定维度的映射关系预测阶段如果重新 fit词汇表会发生变化特征维度对不上模型直接报错或者给出毫无意义的结果。transform 则是拿着已有的词汇表把新文本映射到同一特征空间这是保证训练与预测一致性的关键。常见参数说明TF-IDF 训练时一般会设置 max_features 控制最大特征数比如 5000 或 10000只保留高频词ngram_range 控制是否加入相邻词语组合(1, 2)表示单个词加双词短语sublinear_tf 常用于压制纯词频带来的偏斜。如果模型是从 Notebook 里重新训练的这几个参数要和训练阶段保持一致否则模型效果会明显退化。我在实际项目中一般会在加载向量器后先打印它的参数看一眼print(vectorizer.get_params())这样能快速确认线上环境拿到的向量器不是被意外重存过的。3.3 逻辑回归预测与概率解读逻辑回归模型加载后可以直接调用但更好的实践是同时使用 predict 和 predict_proba让结果带上置信度。下面这段代码是我在这个项目基础上习惯性做的增强import numpy as np def predict_sentiment(raw_text: str): vec vectorizer.transform([raw_text]) prob model.predict_proba(vec)[0] label int(model.predict(vec)[0]) confidence float(np.max(prob)) display_label 正面评价 if label 1 else 负面评价 return display_label, confidence逻辑说明predict_proba 返回的是一个形状为(1, 2)的数组第一列是负面概率第二列是正面概率取最大值的索引对应的就是模型的最强判断。confidence 越大说明模型越确定比如 0.98 和 0.53 虽然都判定为正面但可信度完全不同。这样返回给前端时页面不只是显示“好评/差评”还能标记“疑似误判”的样本。一个容易踩坑的细节模型标记的 0 和 1 分别代表什么取决于训练时标签的编码方式。最好在训练后查看model.classes_确认 0 对应的是负面还是正面。很多项目翻车就翻在这里标签倒置模型预测原本是好的页面上却显示“差评”。3.4 模板层Jinja2 回显与页面联动Flask 默认从 templates 目录找 HTML 模板index.html 的表单结构大致是这样:form methodpost textarea namecomment rows5 placeholder写下你的入住体验…{{ comment }}/textarea button typesubmit情感分析/button /form {% if prediction %} p情感倾向strong{{ prediction }}/strong/p {% endif %}逻辑说明textarea 里的 name 属性必须与后端request.form.get(comment)的字符串完全一致这是前后端对接的契约。{{ comment }}是 Jinja2 变量插值提交后刷新页面时把用户刚刚输入的内容回显在文本域里方便修改后重新预测。prediction 变量在 GET 请求下为 None{% if %}判断不会渲染结果区域。hotel_detail.html 和 recommendations.html 这两个页面在常见实现里会配合模型输出做更复杂的展示。比如 hotel_detail 接收一个评论 ID从数据库或缓存中取出评论文本、预测情感、置信度渲染成详情卡片recommendations 则可以根据酒店维度聚合预测结果把好评率高的酒店排在前面。这套从单条预测到聚合展示的链路正是从“能跑”迈向“能用”的关键一步。4. XGBoost 备选模型为什么保留两个模型以及怎么切换4.1 逻辑回归和 XGBoost 的模型定位差异很多初学者会问既然逻辑回归已经能预测为什么还要保留一个 XGBoost 模型这要从两者对文本特征的处理方式说起。TF-IDF 转化后每条评论变成一个极高维且稀疏的向量大部分维度是 0。逻辑回归在这个空间里学到的是一条线性决策边界适合判断“出现这些词倾向好评、出现那些词倾向差评”这类简单模式。但酒店评论里大量存在转折句和组合特征典型如“虽然房间小但是很干净”。线性模型很难处理好这种词与词之间的交互关系。XGBoost 是梯度提升树模型它可以在每次分裂时自动选择最有区分力的特征组合对非线性关系更敏感。因此作者在 Notebook 里同时训练两个模型本质上是给自己留了一手先用逻辑回归做基线再尝试用 XGBoost 看能否在测试集上提升。从工程角度看保留多个模型产物还有一个实际好处线上出了问题可以快速回退。比如 XGBoost 在线上流式数据上表现异常切回逻辑回归只需要改一行加载代码。4.2 训练与评估的对比实现在 Notebook 里两个模型的训练流程通常是共用一个训练集和测试集这样对比结果才有意义。核心代码逻辑大致如下from sklearn.model_selection import train_test_split, cross_val_score from sklearn.linear_model import LogisticRegression from xgboost import XGBClassifier X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42, stratifyy ) lr LogisticRegression(max_iter1000, class_weightbalanced) xgb_model XGBClassifier( n_estimators200, learning_rate0.1, max_depth5, eval_metriclogloss, ) lr_scores cross_val_score(lr, X_train, y_train, cv5, scoringf1) xgb_scores cross_val_score(xgb_model, X_train.toarray(), y_train, cv5, scoringf1)逻辑说明stratifyy保证训练集和测试集中正负样本的比例一致这在评论数据正负不平衡时非常关键。class_weightbalanced让逻辑回归自动调整正负类权重防止模型偏向多数类。XGBoost 的 n_estimators 控制树的数量learning_rate 是每棵树贡献的步长max_depth 限制单棵树深度防止过拟合。cross_val_score返回的是五折交叉验证的 F1 分数数组不要只看 accuracy因为如果原本负面样本只占 20%模型全预测正面也能有 80% 准确率但毫无使用价值。F1 兼顾精确率和召回率是情感分类更可靠的对比指标。注意我给 XGBoost 传的是X_train.toarray()这是为了兼容某些版本下 XGBoost 对稀疏矩阵的处理差异遇到报错时就先转成稠密矩阵。评估环节常见的补充操作是输出混淆矩阵看模型到底把哪些负面评论误判成了正面。这个环节留下的结论直接决定了最终选择哪个 pkl 作为默认加载模型。4.3 线上切换模型环境变量驱动切模型不需要改视图代码只需要在加载模型的地方加一个开关import os import joblib USE_XGB os.environ.get(USE_XGB, 0) 1 if USE_XGB: model joblib.load(os.path.join(BASE_DIR, xgboost_model.pkl)) else: model joblib.load(os.path.join(BASE_DIR, logreg_model.pkl))逻辑说明这样设计的好处是同一个 app.py 文件同时管理两个模型想切换时只需要在启动命令前加上USE_XGB1不用动代码。对熟悉命令行的人来说比每次修改源码路径要安全得多也不会出现“上次改了什么忘了改回来”的问题。参数说明两种模型默认使用同一个 TF-IDF 向量器因为两者训练时都基于同一套特征空间。但要注意XGBoost 训练时如果把文本转成了 other 格式或做了额外处理那线上也要走完全相同的预处理路径。我的习惯是每次切换模型后先手动预测三条已知评论确认输出和训练阶段一致再放量使用。用表格做个粗略对比的话逻辑回归适合作为默认主力胜在训练快、内存占用低、结果是概率可解释XGBoost 适合对效果有更高要求且数据量足够的场景它的调参空间更大但要小心过拟合。对比维度逻辑回归XGBoost训练速度快秒级内完成较慢树模型迭代多特征交互线性组合难捕捉转折句树分裂自动组合特征可解释性系数直接可见需要特征重要性辅助资源占用低适合小服务部署较高树模型体积大适用场景基线、快速验证、资源受限追求更高准确率、样本充足5. 环境配置、启动流程与避坑指南5.1 虚拟环境搭建与依赖安装这个项目对 Python 环境的要求很常规3.8 及以上版本都能跑。我建议使用虚拟环境避免把依赖装进全局环境导致版本冲突python -m venv .venv source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate pip install flask scikit-learn pandas xgboost joblib逻辑说明venv 创建的是当前项目的独立 Python 环境后续安装的包只影响这个项目。xgboost 在 Windows 下的安装包较大如果下载速度慢可以换成国内镜像源但注意镜像源的包版本可能与官方略有差异。安装完成后用pip list确认关键库已到位。依赖安装还有一个隐藏坑pkl 文件中保存的是训练时的库版本信息和类路径如果当前环境的 scikit-learn 版本和训练时差距过大加载模型时会直接报错。最稳妥的做法是安装完依赖后马上执行一次加载测试把问题暴露在最前面。5.2 启动应用与验证预测结果依赖安装完成后启动非常简单python app.py看到类似“Running on http://127.0.0.1:5000”的输出后打开浏览器访问该地址。在文本域输入“酒店位置很好离景区很近下次还来”点击分析应当返回正面评价输入“房间卫生很差床单有污渍前台态度也不好”应当返回负面评价。如果你的环境没有浏览器或者你想快速验证模型本身是否正常可以在命令行里直接试curl -X POST http://127.0.0.1:5000/ -d comment房间很干净床很舒服返回的 HTML 里会包含预测结果。这条验证命令的价值在于它把 Web 层和模型层一次性覆盖了如果 curl 正常而浏览器异常问题通常出在浏览器缓存或端口被代理劫持上。5.3 四类高频问题的现象、原因与解决这类项目翻车点其实很集中我把最容易遇到的几类列出来按“现象 → 原因 → 解决”的思路逐个说清楚。问题一加载模型时报错“AttributeError: Cant get attribute TfidfVectorizer”现象是joblib.load执行到一半直接中断原因是当前环境的 scikit-learn 版本与训练时不一致pkl 里记录的模块路径在当前环境找不到对应类。解决方法分两步先尝试升级或降级 scikit-learn 到训练时版本最直接的办法是查看 Notebook 开头记录的环境版本如果无法精确复现可以用pickle配合自定义find_class加载但更推荐的做法是重新训练一次模型并保存当前环境的 pkl毕竟训练脚本就在 Notebook 里。问题二中文评论全部被预测为同一个标签现象是输入“垃圾”和“好评”得到的结果完全一样。原因大概率出在清洗函数上很多示例代码会用re.sub(r[^a-zA-Z], , text)这类规则它把中文全部当成特殊字符删掉了模型看到的实际内容是一串空格自然只能给出一个统一预测。解决方法是检查清洗逻辑把中文字符也保留下来比如re.sub(r[^\w\u4e00-\u9fa5], , text)同时确认训练语料本身包含中文而不是一个纯英文模型被拿来处理中文。问题三predict 报错“dimension mismatch”或“feature count mismatch”现象是模型能加载但一预测就报维度不一致的错误。原因几乎都是预测阶段对文本做了重新向量化比如又调了一次fit_transform导致生成的特征矩阵列数和训练时不一致。解决方法是确认代码里调用的是transform而不是fit_transform并检查向量器是从哪个 pkl 加载的确保加载的是模型配套的向量器而不是其他实验产物。问题四浏览器打开页面报 Internal Server Error现象是终端能看到请求记录但页面显示服务器内部错误。常见原因是在项目根目录之外执行了python app.py导致 Flask 找不到 templates 目录渲染模板时抛出异常。解决方法是在项目根目录下启动或者在 app.py 里显式指定模板路径app Flask(__name__, template_folderos.path.join(BASE_DIR, templates))这一行能彻底解决“从别处启动就找不到模板”的问题也是我在部署多个项目时养成的固定习惯。6. 二次开发指南替换模型、扩展酒店维度与回归验证如果你想把这个项目用到自己的场景里最值得改造的是模型接入方式。现在 app.py 里直接加载 pkl 并调用逻辑分散在路由函数里。更规范的做法是抽一个模型适配层让页面代码只依赖稳定接口class SentimentModel: def __init__(self, model_path, vectorizer_path): self.model joblib.load(model_path) self.vectorizer joblib.load(vectorizer_path) def predict(self, text: str): vec self.vectorizer.transform([text]) prob self.model.predict_proba(vec)[0] label int(self.model.predict(vec)[0]) return label, float(max(prob))替换成新模型时只要新类也有 predict 方法app.py 里的调用代码就不用改。这比到处判断USE_XGB干净得多也方便以后接 BERT 这类模型时做统一适配。产品层面更值得做的改造是把“单条评论预测”升级成“酒店口碑聚合”。比如在数据库里维护一张评论表每条评论预测完成后同时写入酒店 ID 和情感标签在 recommendations.html 里按酒店分组统计正面评论占比就能得到“哪些酒店口碑更好”的结论。hotel_detail.html 也可以进一步展示“近 30 天该酒店评论情感分布”。这一步扩展不需要重新训练模型纯粹是业务层的数据聚合但对项目的完整度提升非常明显。最后说一个我自己的血泪经验每次改完特征或模型都必须让新旧版本跑同一份固定测试集。我的做法是把 200 条典型评论手工标注后固定保存分别用旧模型和新模型预测对比准确率和每一条的差异。这个习惯帮我避过了无数“改完不知道是变好还是变坏”的翻车现场。从那以后我每换一次模型都强制先跑一遍同一份黄金测试集把旧模型的输出存成 baseline 文件再动任何一行特征代码。希望帮到你。本文还有配套的精品资源点击获取