大模型+情感分析：餐饮评论深度挖掘与餐厅推荐系统实战

1. 项目概述1.1 为什么选这个题目从选题到落地的完整思路每到毕业季计算机专业的学生就在选题上反复纠结。做纯算法研究怕数学底子撑不住做普通管理系统又觉得太单薄没有技术亮点。去年我带过的一位学生下文叫他A同学选的就是Python大模型美团大众点评餐饮评论情感分析与餐厅推荐系统这个方向最终顺利通过答辩还拿到了优秀毕业论文。这个题目之所以值得做核心在于它把爬虫、数据清洗、情感分析、大模型应用、推荐算法、Web展示这一条完整的数据链路全部串起来了每一个环节都能对应到具体的课程知识点答辩时老师问什么都不怕没东西讲。先说清楚这个系统到底解决什么问题。美团和大众点评上有海量的用户评论比如这家店的牛肉粉分量足汤头鲜就是排队太久这句话里包含了三个维度的信息菜品评价牛肉粉分量足、汤头鲜、服务评价排队太久。传统的做法是用规则或者词典去判断整句是正面还是负面但整句打分显然会丢失细节。这个项目要做的是两件事第一基于用户评论做细粒度情感分析不只是判断好评差评还要把口味、环境、服务、价格这几个大家最关心的维度分别打分第二基于情感分析的结果构建一个餐厅推荐系统让用户输入自己的偏好比如想吃辣的环境安静适合约会系统返回符合条件的餐厅排序。1.2 项目的受众与价值这个项目适合谁三类人可以直接参考计算机/大数据相关专业的毕业生需要一个覆盖前后端算法数据库的完整课题想在大模型应用方向积累项目经验但落地场景还不明确的人对餐饮行业数据分析感兴趣想自己动手做一套评论挖掘工具的开发者从技术面试的角度看这个项目的价值在于面试官可以从任何一个点切入提问你的情感分析模型为什么选这个推荐结果是如何排序的爬虫怎么反爬数据量大了怎么存每一个问题都有明确的回答空间不会出现这块不是我做的这种情况。2. 项目整体架构与技术选型2.1 系统分层架构解析整个系统我在设计之初就明确划分为五个模块彼此独立、接口清晰这样不管是自己写还是一组人分工都容易推进。数据采集层 → 数据处理层 → 分析引擎层 → 推荐服务层 → 展示交互层数据采集层负责从美团、大众点评等平台获取餐厅信息和用户评论。这里要注意平台的网页结构和接口策略会变所以爬虫部分要做成可配置的不能把选择器写死。数据处理层对采集到的原始文本做清洗、去重、分词、格式转换形成结构化数据。这一层的工作量在整个项目里占比最高但也是最容易拿分的地方——只要你自己动手做过数据清洗答论文里的数据预处理章节就能写出真实细节。分析引擎层这是整个项目的技术核心。我采用了双轨并行方案传统机器学习模型与大模型方案共存。传统模型用基于预训练模型微调的方法做情感倾向判断大模型方案则负责细粒度分析和方面级情感抽取。推荐服务层把情感分析的结果变成推荐依据。这里包含两个推荐维度基于相似用户行为的协同过滤和基于用户偏好的属性匹配。展示交互层用一个Web界面把结果可视化呈现包括餐厅地图分布、情感得分雷达图、评论关键词云、推荐结果列表等。2.2 核心工具与框架选择理由这一节把我实际用过的技术栈完整列出来并解释为什么选它。Python 3.10数据分析生态最成熟没有之一。爬虫、数据处理、模型训练、Web框架全部在Python体系内完成避免多语言切换带来的部署复杂度。爬虫框架requests BeautifulSoup Selenium。美团和大众点评的部分数据在页面源码里直接返回用requests就能拿到。但涉及翻页、动态加载的内容就需要Selenium模拟浏览器操作。实测下来大众点评的评论翻页是动态加载的直接从HTML解析只能拿到第一页这里必用Selenium配合等待策略。中文分词jieba。虽然大模型能直接处理原始文本但分词后的结果在做关键词提取、词频统计时依然高效。核心模型这里给出具体的实现路径。传统方面推荐使用基于中文预训练模型BERT做微调数据集选用酒店餐饮评论与自行标注数据。大模型方面推荐选用Qwen系列的开源模型在评论情感分析场景上有较好的中文理解能力用API方式调用做细粒度分析。这种微调模型出基础得分大模型出多维解释的双轨设计答辩时很有说服力。数据库MySQL Redis。MySQL存全量数据Redis做缓存加速推荐接口响应。Web框架Flask或FastAPI均可。我习惯用Flask结构简单、博客和案例多、有问题好查。选择传统模型大模型双轨不是简单为了炫技。实际原因是微调模型在好评/差评二分类上速度快、精度高适合批量初筛大模型在环境怎么样服务态度如何这类细粒度问题上的语义理解能力更强。两者结合既保证系统响应速度又提升分析的深度。3. 数据采集与处理实战3.1 爬虫模块的落地细节先说爬虫。很多人一上来就想去爬全站数据这既不现实也容易被限制。我的建议是限定城市和美食分类构造可配置的采集范围。比如就以某个一线城市的川菜品类为目标采集前200家餐厅每家餐厅抓取前100条评论这样数据规模在2万条左右足够做分析和推荐实验。具体采集流程分三步第一步确定入口URL。从美团或大众点评的城市页进入按分类筛选得到列表页URL。这个URL里通常包含城市ID和分类ID可以参数化。第二步解析列表页并抓取餐厅详情链接。这一步的关键是选择器定位。用过Selenium后会发现很多HTML元素没有稳定的id和class最靠谱的办法是通过文本内容定位比如包含评论查看全部这类关键词的元素。第三步进入餐厅详情页抓取评论。重点难点在于评论的翻页。大众点评的评论翻页现在大多是Ajax请求直接改变URL参数不一定生效。我实际用的方案是用Selenium点击下一页按钮等待页面刷新后在DOM里抓取评论节点。爬虫最怕的就是被封IP我在这里做了三层防护请求间隔随机化每次请求前休眠2到5秒请求头完整模拟浏览器包括Accept、Referer、User-Agent等字段设置重试机制抓取失败后自动重新尝试三次三次失败记录日志跳过3.2 数据清洗的八个关键步骤数据采集到位后清洗环节决定了后面所有分析的质量。我把清洗流程整理成一张检查单去除重复评论。同一用户可能重复提交相同内容按用户ID餐厅ID评论文本三重条件去重去除纯表情和无意义文本如哈哈哈哈好好好统一全角半角符号把英文字母统一转为小写用jieba自定义词典补充餐饮领域词汇比如锅气免辣M这类词需要手动加入才能正确分词过滤广告和灌水评论这类评论通常包含外部联系方式或者重复字符清洗HTML标签转义字符比如nbsp;br等对评分字段做归一化处理不同来源平台评分满分可能不同统一到5分制时间字段格式化为后续做时间趋势分析做准备这八个步骤里最容易出问题的是去重和分词。去重时不能只看文本完全一致因为有人会在后面加个标点或者空格就能绕过去用文本相似度计算比如 difflib 的 SequenceMatcher更稳妥。分词则是餐饮领域特有词太多的场景jieba默认词典对轻食简餐深夜食堂这类词切得不够好要投入精力维护一个自定义词典。3.3 数据存储结构设计数据库表结构我在第一版设计时吃了不少亏后来重新调整才稳定下来。这里直接给出最终版本restaurant餐厅表restaurant_id主键、name、address、category、avg_price、rating、comment_count、latitude、longitudereview评论表review_id主键、restaurant_id外键、user_id、content、rating_score、review_time、like_countsentiment情感分析结果表review_id外键、sentiment_score、taste_score、env_score、service_score、price_score、analysis_detailJSON格式存大模型输出user_recommendation推荐记录表user_id、restaurant_id、recommend_score、reason推荐理由、create_time评论表一定要加索引在restaurant_id和user_id上不然后面几万条数据做查询会明显变慢。我当初测试时没加索引一个简单的join查询要跑300多毫秒加了联合索引后直接降到20毫秒以内。4. 情感分析模型构建与调优4.1 模型方案对比与选型思路情感分析方向有几条路可以选我花了大半个月做对比实验说下感受基于情感词典最简单但准确率上限低尤其面对这个店环境不错但是菜太咸了这种转折句词典法很难正确判断基于传统机器学习朴素贝叶斯、SVM等需要手工做特征工程泛化能力一般基于预训练模型微调BERT及其变体在情感分类任务上效果最好在小数据集上也能通过微调获得不错的效果是当前最主流方案基于大模型Qwen、ChatGLM等开源模型可以直接做零样本/少样本情感分析甚至输出分析理由但推理速度相对较慢成本也更高综合考量后我选择了微调BERT做二分类大模型做细粒度分析的双轨结构。BERT模型负责全量评论的快速初筛判断每条评论的情感倾向大模型只对有分析价值的评论进行方面级细粒度打分避免对所有评论都走大模型导致时间和成本失控。4.2 微调数据集构建与标注策略模型效果好不好七成靠数据。我构建了一个约8000条的多源餐饮评论数据集标注为正向和负向。数据的来源渠道主要有两个一是开源的中文评论情感数据集二是自己采集后人工清洗标注。为了避免开源数据和美团评论在语言风格上的差异我额外手动标注了约2000条美团评论专门补充平台特有的表达方式。标注时要特别注意隐含情感的判断。比如两个人吃了200块有点小贵这句话表面没有情绪词但实际隐含负面倾向。经验不足的同学容易在这类句子上标错。我给标注团队定的原则是先判断作者态度是褒是贬再判断有没有明显的正负情绪词。标注完成后按8:1:1切分训练集、验证集和测试集并且要保证三个集合中正负样本比例一致避免样本不均衡影响模型学习。4.3 BERT微调的关键参数配置这一节直接上实战参数都是我调出来的可用配置预训练模型使用中文BERT-base参数量约1.1亿完全够用max_seq_length128。评论平均长度在50字左右128足够覆盖95%以上的样本batch_size16显存有限时8也可以learning_rate2e-5使用AdamW优化器epochs3到5取决于验证集效果warmup前10%的step做学习率预热训练中我加了早停机制验证集F1连续3个epoch没有提升就停止训练防止过拟合。实测在8000条数据上训练时间大约20分钟单张消费级显卡最终在测试集上准确率能到92%以上F1分数也可以到91%左右。# 伪代码展示核心训练流程 from transformers import BertTokenizer, BertForSequenceClassification, Trainer, TrainingArguments tokenizer BertTokenizer.from_pretrained(bert-base-chinese) model BertForSequenceClassification.from_pretrained(bert-base-chinese, num_labels2) training_args TrainingArguments( output_dir./finetuned_model, learning_rate2e-5, per_device_train_batch_size16, num_train_epochs3, evaluation_strategyepoch, save_strategyepoch, load_best_model_at_endTrue ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, eval_dataseteval_dataset ) trainer.train()4.4 大模型做方面级情感分析的设计这部分的思路是每条评论拆分成口味、环境、服务、价格四个维度对每个维度分别给出得分1-5分和对应的文本依据。实际实现时我用的Prompt设计如下你是餐饮评论分析助手。请对以下用户评论在口味、环境、服务、价格四个维度 分别打分1到5分并给出每个维度对应的原文摘录作为证据。 如果评论中没有提到某个维度则该维度分数为空。 以JSON格式输出。 评论内容{待分析的评论}用这种方式调用大模型返回结果严格解析成JSON存入sentiment表。我测试了Qwen官方API接口的调用响应格式基本稳定偶尔会出现格式错误所以解析时要做容错如果JSON解析失败就重新生成一次或退回BERT的整句得分。大模型输出内容里常常带着分析依据这些内容不要扔掉后续推荐系统的推荐理由模块可以直接利用这些摘要生成类似口味得分高用户反馈汤头鲜、分量足这种可读性强的推荐说明。4.5 模型评估与badcase复盘训练完模型后不能只看总准确率还要看分维度的表现。我做了个对比实验取200条人工标注的细粒度样本分别用纯BERT方案和BBERT大模型方案评估。维度纯BERT的准确率BERT大模型的准确率整句情感倾向92.5%96.0%口味维度无此能力88.5%环境维度无此能力91.0%服务维度无此能力89.5%价格维度无此能力90.0%这个结果印证了双轨方案的价值传统模型只能给一个整体倾向但推荐系统更需要为什么推荐的细节信息而这恰恰是大模型的优势区间。复盘badcase时发现最集中的三类错误反讽和调侃识别困难比如这家店的环境真是高级得让我想哭多维度混合情感比如味道很好但等位两小时这类到底是好评还是差评比人类标注都有争议无明确情感倾向的客观描述被误判为正向针对反讽这个问题我尝试在Prompt中加入注意识别反讽语气的提示词但作用有限。最后的处理策略是对识别为高置信度反讽的样本单独打上存疑标签不进入推荐计算避免影响排序结果。5. 推荐系统的设计与实现5.1 推荐策略的选型从冷启动谈起毕业设计场景下推荐系统面临一个现实问题用户行为数据稀疏。真实的产品环境下用户有大量点击、下单记录可以做协同过滤建模。但毕设里你不可能真的让几百个用户来试用系统产生行为数据所以纯用协同过滤会面临没有数据推荐结果是空的的尴尬。我的解决方案是构建混合推荐策略新用户冷启动场景基于用户输入的偏好标签口味偏好、预算范围、场景选择触发属性匹配推荐有行为数据场景使用基于餐厅相似度的协同过滤找到用户曾经好评的餐厅相似的其他餐厅最终排序融合将两种策略的结果加权融合这个设计答辩时很加分——因为冷启动是推荐系统面试必问问题你直接告诉老师项目里已经处理了这个问题。5.2 基于情感得分构造用户偏好画像很多毕设做推荐就是简单用TF-IDF给评论聚类这种做法的颗粒度太粗。我在这里做了一个更落地的设计把用户对某餐厅的好评视为用户对此餐厅对应属性的偏好。举个例子用户A对餐厅X评价中口味得分5、环境得分3同时给餐厅Y的评价中环境得分5、服务得分5。那我们可以推断用户A的偏好向量接近于口味权重高环境和服务也比较看重。随着用户评价的餐厅增多用户画像越来越精准。实现上我用一个长为4的向量表示用户偏好每个元素对应一个维度的平均偏好强度。然后用余弦相似度计算用户与餐厅之间的匹配程度。5.3 推荐结果生成与可视化展示推荐接口返回的内容包括三个部分推荐餐厅列表、匹配得分、推荐理由。推荐理由的生成我做了三层第一层基于情感得分模板生成如该餐厅口味维度评分4.8分环境评分4.2分适合看重口味的用户第二层从大模型分析结果中摘取高频正向关键词如服务热情出餐快适合聚餐第三层定性标签从评论聚类结果中提炼的适合亲子性价比高网红打卡等标签三层信息组合起来前端展示时就是一段像模像样的推荐说明。答辩演示时这段内容特别能打动老师因为它直观展示了系统不只是算了个分。6. Web端可视化模块的实现6.1 页面结构与信息架构整个Web应用我设计了四个主页面餐厅地图页用地图展示所有餐厅分布按推荐分数用不同颜色标注餐厅详情页展示基本信息、情感得分雷达图、评论关键词云、大模型情感摘要推荐页支持用户输入偏好条件展示推荐结果列表及推荐理由数据看板页展示整体数据统计比如评论总量、情感分布、TOP10餐厅等页面的核心交互逻辑是用户在推荐页输入口味偏好价格区间场景类型系统后台调用推荐接口返回结果前端按匹配度降序展示。6.2 前端技术要点前端我用了轻量方案HTML Bootstrap ECharts 一点原生JavaScript。这样不引入前端框架复杂度又能满足可视化的需求。ECharts在这个项目里是绝对的主力。雷达图展示餐厅在各维度的得分非常直观关键词云用ECharts的wordCloud系列饼图展示好评/差评占比。ECharts的配置项网上资料很多不多讲了只提醒一点图表数据从后端接口拿JSON要注意字段名保持一致我就是因为后端返回的是snake_case如avg_price前端JS习惯性写了camelCase如avgPrice排查了半天才发现是命名不一致导致的。6.3 前后端接口设计样例我用FastAPI实现了RESTful接口统一返回结构{ code: 0, message: success, data: { restaurant_id: R0001, name: 某川菜馆, recommend_score: 4.7, dimension_scores: { taste: 4.8, environment: 4.2, service: 4.5, price: 4.3 }, reason: 该餐厅口味评分极高用户反馈水煮鱼麻辣鲜香辣子鸡外酥里嫩适合偏好重口味的用户 } }推荐接口的请求参数为user_id、taste_pref、price_min、price_max等。后端先查Redis看有没有缓存该用户的推荐结果有就直接返回没有就调用推荐引擎计算再写回缓存。7. 常见问题汇总与避坑指南7.1 爬虫篇问题排查问题1Selenium打开页面后拿不到评论数据。大概率是页面还没加载完就执行了解析。解决方案是使用显式等待等待某个评论节点出现后再开始抓取。我当时的写法是WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CLASS_NAME, review-item)) )问题2请求频率过高导致IP被限制。这是几乎必然会遇到的问题。解决策略除了前面说的休眠随机化和请求头伪装外还有一个有效方案抓取过程中监控返回状态码一旦出现403、429等状态立即停止当前任务并延长全局等待时间。7.2 数据与模型篇问题排查问题3BERT训练时显存溢出。消费级显卡显存普遍有限。解决方案减小batch_size到8或4同时启用梯度累积。BERT-base参数量不大但每条样本在128长度下也占不少显存从batch 16降到8通常就够用了。问题4大模型返回的JSON解析失败。大模型的输出不是你写什么格式就一定给你什么格式。我在解析端做了三层兜底直接用json.loads解析失败后用正则提取JSON片段再失败就放弃这条用BERT的结果顶替。实际运行中第一条成功率大约95%三层兜底后分析流程基本不会中断。问题5情感分析对特定类别如环境效果差。检查一下是不是训练样本里该维度标注过少。解决思路是单独为维度分类建立少量数据增强样本把环境好装修不错空间大这类表达扩充进训练集。7.3 推荐篇问题排查问题6推荐结果总是集中在少数几家餐厅。这是排序算法常见的羊群效应高分餐厅被推荐多次低分餐厅永远沉底。我的处理办法是把情感得分做归一化后加入一定随机扰动同时在排序中引入多样性惩罚项——如果连续推荐的前5家餐厅都属于同一品类则降低该品类的排序权重。问题7用户偏好画像稀疏导致推荐失效。用户只评价过一两家餐厅时画像结果极不稳定。我在实现中设置了一个阈值当用户有效评论数少于3条时不启用协同过滤只用属性匹配。这样设计可以把冷启动和正常状态分开处理效果更可控。8. 部署与答辩准备要点8.1 本地部署与打包整个系统我在一台配置中等的笔记本上就能跑通8核CPU、16GB内存、无独立显卡的环境足够胜任全部训练和预测流程只是BERT训练时间会长一些。部署的步骤很简单安装依赖pip install -r requirements.txt初始化数据库导入init.sql并执行数据表创建脚本启动后端服务python run.py启动前端将静态文件置于Flask的templates/和static/目录浏览器访问http://localhost:5000我把整个项目放到了共享文档平台上源码、数据库建表脚本、爬虫配置、训练脚本、答辩用的PPT全都分目录整理好目录里每个代码文件都写了功能说明和运行顺序。这一步对答辩的影响很大——老师现场想看代码时你得几秒钟内找到对应文件不能翻来翻去。8.2 答辩演示的演示脚本设计答辩现场最容易翻车的就是演示环节。我的建议是准备一个8分钟左右的演示脚本按以下节奏走第1分钟项目背景。一句话说明美团点评的海量评论需要情感分析来挖掘价值第2-3分钟架构概览。展示系统分层架构图重点说明爬虫→预处理→情感分析→推荐的主流程第4-5分钟核心功能演示。现场运行系统输入偏好条件展示推荐结果打开餐厅详情感分析结果第6-7分钟模型效果展示。展示模型训练曲线和评估指标现场跑几条评论实例展示BERT和大模型各自的输出第8分钟创新点总结。强调双轨情感分析、用户体验优化、冷启动处理这三个亮点关于答辩还有一条实在的建议把整个项目的环境在自己的电脑上提前准备好因为他很可能要求现场跑一遍一旦临时依赖缺失或数据连接不上现场会很难收场。8.3 核心创新点如何提炼论文和答辩PPT里不能只罗列做了什么要突出为什么这么做以及相比常规做法的优势。我帮A同学最终提炼了三个创新点双轨情感分析架构将传统BERT微调模型与大模型结合平衡速度与细粒度分析深度基于情感维度的推荐解释生成不只给出推荐排序还通过大模型抽取证据生成可读推荐理由提升推荐可信度面向冷启动场景的混合推荐策略在行为数据稀疏时用属性匹配保障推荐质量的底线这三个创新点每个都能对应一个实现细节和一个实验数据支撑答辩时按创新点→实现方案→效果验证的节奏讲基本不容易被追问到冷场。9. 项目扩展与后续演进思路如果时间充裕或者想在论文里加入对比实验还有几个扩展方向值得做方向一引入时间因素。评论的情感倾向会随时间变化餐厅从开业到成熟好评率和维度得分都有明显的动态规律。把时间特征加入情感分析模型做时序趋势预测这是一个很好的深入研究点。方向二多模态数据融合。评论中的图片其实也是重要信息来源图片文字联合建模可以做视觉情感分析。这个方向对技术要求高但也是目前学术界和工业界都在关注的问题。方向三推荐结果的可解释性增强。现有推荐系统大部分是黑盒输出如果能用自然语言生成更丰富、更有逻辑的推荐理由用户的信任度会显著提升。这部分我目前是模板关键词组合语言流畅度和个性化程度还有提升空间。我个人在实际操作中积累下来的经验是毕业设计项目不要追求功能堆砌而是追求链条完整。把一条数据管道从采集到展示走通每一个环节都有据可查、有数可测这种系统性思维的展示效果远比加一堆华而不实的算法要强。另外数据保存和备份这件事要多说一句——爬虫数据在采集过程中容易因各种原因中断建议边抓边存每完成一家餐厅就把数据落盘全量抓完再统一清洗能省下很多从头再来的时间。最后再分享一个小技巧代码里的中文注释值得用心写答辩或面试时被要求讲代码逻辑是常事好的注释能帮助你快速回忆起当时的思路也给别人留一个代码规范的好印象。这个项目做完之后大模型部分可以顺手迁移到其他领域比如电商商品评论分析、酒店评论挖掘思路和代码结构几乎不用大改换个数据集就能跑出新东西。