这个题目几乎是每年毕设场景里的常客Python加大模型美团大众点评情感分析再叠一个餐厅推荐系统。光看名字好像把热门技术都占齐了但真正动手之后你才会发现这个题目本质上是一条完整的技术链路——数据清洗、情感建模、推荐计算、Web展示每一环都是独立的分点凑在一起又刚好是一套能自圆其说的大数据应用系统。我每年都会带几组类似的模拟项目说实话能把这条链路跑通并且讲清楚的同学不多大多数卡在“大模型结果不可控”或者“推荐算法太浅”这两个地方。这篇内容我按自己带项目的实际节奏来写从题目拆解、数据准备、大模型情感分析、推荐系统实现一直写到论文、PPT和答辩讲解的整理方式。适合正在做毕业设计的学生也适合想从零搭一套“数据分析推荐”演示系统的开发者。看完你至少能回答清楚三个问题大模型在这个场景里到底解决什么问题情感分析结果怎么变成推荐分数答辩的时候怎么把项目讲得既有深度又不心虚。1. 项目整体设计与思路拆解1.1 需求拆解这个题目到底要交付什么别看标题很长拆开就是四件事爬取或获取餐饮评论数据、用大模型做细粒度情感分析、基于情感结果做餐厅推荐、把结果展示成可演示的系统。对应到毕业设计交付物就是源码、配套论文即标题里的LW、PPT和答辩讲解。这四个环节的定位完全不同我建议按“数据—模型—应用—展示”的顺序去做每一步都能单独作为论文的一章写内容。情感分析是技术核心推荐系统是应用落点Web展示解决“评委看得见”的问题LW和PPT解决“讲得清”的问题。需要注意毕设不是科研项目并不需要你做出一个效果吊打全网的产品它要证明的是“你理解这条技术链路并且每一步都有自己的决策依据和实验结果”。所以后面所有内容我都会刻意带出“为什么这样选”以及“对比了什么方案”这些才是论文里真正值钱的部分。1.2 整体架构离线分析加在线推荐的两层设计我给这个题目设计的架构是这样的第一层是离线分析层。原始评论是餐饮用户对具体店铺的海量短文本先把它们清洗成结构化数据再调用大模型API对每条评论做情感识别输出“整体情感倾向细粒度维度分数”。这一步跑完后把所有结果落库作为后续推荐的数据底座。第二层是在线推荐层。用户打开系统选择自己关心的维度比如口味权重高还是性价比权重高系统读取离线计算好的评论情感分数结合评论数量和评分热度按照融合公式计算每家餐厅的推荐指数排序展示再配上评论摘要和情感占比图表。这个“离线在线”的分层思路看起来简单却是大数据应用的标准结构。评委特别爱问“如果评论量很大怎么办”你就回答离线批量分析可以横向扩展在线推荐只做索引查询和轻量计算两者解耦。这样回答既落地又有架构感比单纯说我写了个推荐函数高好几个层次。1.3 技术选型为什么是Python加大模型选型层面有两个必须解释清楚的问题。第一个Python在这里毫无疑问。数据清洗用 Pandas情感分析调用API推荐计算用NumpyWeb展示用Streamlit整个生态都是现成的几乎没有造轮子的成本。第二个为什么用大模型而不是传统情感分析工具。很多答辩老师会问“SnowNLP和BERT也能做情感分类你何必用大模型”。我的回答逻辑是这样SnowNLP是词典加规则的方法对餐饮口语化表达“排队一小时但是值了”“齁咸”这种的泛化能力很差而且只能给出正负向无法回答“哪里好哪里不好”。BERT需要自己标注大量训练数据一个毕设周期内很难准备出高质量语料。大模型API在零标注的情况下可以直接输出结构化的维度级情感结果等于把“训练”这一步外包给了通用模型底座。成本低、效果好、可解释性强这是它最大的优势。实测下来国内主流大模型API在这类短文本情感任务上表现完全够用没必要强求更大规模的模型。2. 数据准备与情感标注方案2.1 数据来源公开数据集与合规演示数据这是整个项目里最容易踩坑的地方我必须先说。餐饮评论数据属于平台的核心资产批量抓取真实平台的内容存在合规和条款风险这点在开题阶段就得绕开。我的建议是优先使用公开的餐饮评论开源数据集或者自己构造仿真演示数据保证业务闭环。实际做法通常是两种并行。一方面去找公开的中文餐饮评论语料里面包含商家、用户、评分、评论文本等字段可以支撑后续分析。另一方面可以基于对话式生成构造补充数据覆盖一些长尾场景比如“分量太小”“环境适合约会”这类表达让展示效果更完整。这么做的好处是你在论文里可以光明正大写“数据获取约束与合规方案”这本身就是一个体现工程素养的加分点。而不是等评委问“你的数据哪来的”时支支吾吾。务必记住毕设是学术训练不是数据演练。2.2 情感标签体系整体倾向加维度细粒度标注情感分析这部分最核心的设计决策是不做单点情感分类而是做细粒度维度拆解。我给评论设计了两层结构第一层是整体情感三分类正面、中性、负面对应分数0到5。第二层是维度拆解四维度口味、服务、环境、性价比。每个维度单独输出情感倾向和分数并额外给出关键词片段比如“口味正面5分关键词入味、量足”。这组输出最大的价值是解释性后面推荐系统给用户看的不只是一个分数而是“这家店为什么适合你因为口味好、环境一般、性价比高”。这种推荐理由在展示环节非常加分。论文里写这一节时可以把“为什么分四个维度而不是直接一个总分”单独拎出来论证因为用户选餐厅时的决策变量不是单一的有人重口味、有人重环境。维度拆解后推荐系统才能按用户的个性化权重做个性化排序。这就是从“大众评分”到“个人适配”的关键一步。2.3 数据清洗与预处理实战要点清洗环节看起来基础但直接影响最终效果。说几个实际操作中一定会遇到的点。去重很关键。同一评论或高度相似的评论比如批量灌水内容必须按文本相似度去重不然一家店的评分会被重复内容扭曲。过滤超短评论。很多评论只有两个字甚至一个表情这种样本对情感分析没有意义我一般会设置长度阈值比如去除低于5个字符的评论。编码问题不能忽略。中文评论里的特殊符号、繁体字、表情符在调用大模型前建议统一做归一化不然模型偶尔会输出乱码。可以用简单的映射表把emoji替换成描述文字比如“开心”对应“开心”而不是一串无法解析的编码。还有一个容易被忽视的点是行业词识别。“排队”“等位”“网红”“打卡”“量大”“齁咸”这些词在通用情感词典里可能被误判或标记为中性但在餐饮场景里信息量极大。用大模型做标注时Prompt里明确要求“针对餐饮评论语境理解网络语和方言”能明显减少这类误判。这些细节写进论文就是“面向领域的情感分析优化策略”比单纯说用了大模型有说服力得多。3. 大模型情感分析与推荐系统的核心实现3.1 大模型情感分析Prompt设计与结构化输出用大模型做情感分析成败一半在Prompt设计。不能写“请分析这条评论的情感”然后拿一段散文回来那样后续完全没法处理。正确做法是指定严格的JSON输出模式。我给这个项目设计的Prompt示例大致如下你是一位专业的餐饮评论分析师。请分析下面这条用户评论输出严格的JSON格式结果。 字段要求 - overall_sentiment整体情感取值为 positive/neutral/negative 之一 - overall_score整体情感分数0到5的数字保留一位小数 - dimensions包含 flavor口味、service服务、environment环境、price_value性价比 每个维度下包含 sentimentpositive/neutral/negative和 score0到5 - keywords从评论中提取最能支撑判断的1到3个关键词短语 - summary用一句话概括这条评论的核心内容 注意事项 - 这是在餐饮场景中请理解“排队”“齁咸”“网红店”等口语表达 - 只输出JSON不要输出任何解释性文字 - 如果某维度没有提及sentiment设为 neutralscore设为3.0 用户评论 {评论文本}这段Prompt的三个设计点很关键。第一强调输出格式避免大模型自由发挥。第二给定了明确的维度字段让它按结构填充。第三加入了领域提示显著提升对口语化表达的理解准确度。实践中我发现加上“只输出JSON”这句话之后解析成功率能稳定保持在98%以上偶尔出现的异常输出也大多是JSON嵌套引号问题写个简单的容错解析就能处理。另外批处理效率和成本要提前设计。毕设数据量通常在几千到几万条全量调用API的成本不算高但时间不短。建议加一层缓存按评论哈希值去重后只分析一次结果存进本地文件或数据库。二次运行直接读缓存既快又省。3.2 与传统情感分析方法的效果对比大模型方案好归好但论文里需要对比实验。我实际做的对比对象有两个SnowNLP和一个简单的TF-IDF加逻辑回归模型。实验结论大致是这样的对比维度词典方法SnowNLP机器学习方法TF-IDFLR大模型API情感分类准确率抽样验证60%到70%75%到80%85%到92%细粒度维度输出不支持需分别训练多个模型原生支持对口语化表达的理解差依赖训练语料强标注成本无需要大量人工标注无可解释性弱弱强可输出理由和关键词额外开销低中API费用我抽样验证了一个100条评论的小评测集大模型在“整体情感倾向”上的准确率能到90%上下SnowNLP只有68%而且SnowNLP特别容易把“环境一般但菜好吃还是会再来”这种复杂句判断成负面。这其实就是大模型具备上下文理解能力的体现也是这个项目最核心的技术亮点。论文里可以把这个表格直接放进去再加上几个典型样例的逐条对比作为“为什么选用大模型”的核心论据非常有说服力。3.3 推荐系统设计情感分数如何变成推荐结果推荐模块是整个系统“应用价值”的落点。这里的核心问题是怎么把一群人的评价变成对一个用户的个性化推荐。单一做法往往是“整体评分排序”太普通了。我采用的是个性化权重加权评分加协同过滤混合的方案。首先是基础评分计算。每家餐厅的基础分数由三个部分构成评论情感分所有评论整体分数的平均值这是核心评论数量分评论数量越多代表热度越高但直接加权会导致新店完全没有机会所以需要做对数变换评分置信修正评论数量过少的餐厅分数向均值收缩避免个别极端评论主导结果第二个是用户个性化。用户在选择餐厅时可以设置四个维度的偏好权重比如“口味重要性价比其次环境无所谓”系统按权重重新聚合各维度的情感分数生成个人视角的总分。这就是从“大众榜单”到“个人推荐”的转变也是大模型细粒度分析真正发挥作用的环节。第三个是协同过滤兜底。先用情感分析和评论内容构建“餐厅相似度矩阵”再结合相似用户的浏览行为做召回处理长尾场景。考虑到毕设数据量有限协同过滤不需要做得太重有一路召回和融合逻辑就够了。3.4 评分融合计算一个可复制的规则公式推荐分数不能靠感觉必须给出明确的公式。我用的是如下计算方式final_score 0.70 * personalized_emotion_score // 个性化情感分 0.15 * popularity_score // 热度分评论数量对数变换后归一化 0.15 * review_confidence_score // 置信分评论量越多越接近均值越少越收缩其中个性化情感分的计算逻辑是personalized_emotion_score Σ(维度情感分 * 用户对应维度权重) / Σ(用户权重)这套公式有三个好处。第一参数可解释答辩时你能直接说出每个权重的意义。第二热度分加了置信收缩不会出现“只有2条评论但全是5星”的店排第一的问题。第三数据变化时分数变化方向直观调参容易。这里有一个实操细节做归一化时不要用“除以最大值”这种简单方法因为新评论进来后最大值会变整个榜单都得重算。建议用评分分位数归一化或者固定映射到1到5分区间稳定性好很多。这个细节虽然小但能看出你确实上手调过系统。4. 系统演示与毕业设计的完整交付4.1 用Streamlit搭建可视化原型毕设系统最重要的目标是让评委在5分钟内看懂整个流程。所以可视化原型不需要高大上的前端工程化Streamlit是最合适的选择。代码量小、图表接入方便、部署零门槛我基本上半小时就能搭出一套可交互的演示原型。推荐界面按三栏布局做左侧是控制面板放用户偏好设置和筛选条件。比如四个维度的滑块、餐厅类型下拉框、最低评论数限制。中间是推荐列表显示餐厅名称、综合推荐指数、情感总分、各维度雷达图、特惠标签。右侧是评论分析展示区选中餐厅后展示最新评论的大模型分析结果包括整体情感标签、维度关键词、情感分布饼图以及调用大模型生成的推荐语摘要。这个布局的逻辑是左侧体现个性、中间体现结果、右侧体现分析过程。评委一眼就能看出“用户设置不一样推荐结果会跟着变”这就是动态展示的价值比放两张静态截图有力得多。4.2 从代码到论文LW怎么组织才不虚这里的LW就是毕业设计的配套论文文档它的结构基本可以对着系统模块来写第一章绪论主要写题目背景和国内外情感分析研究现状研究现状里必须带出“传统方法在细粒度情感理解上的不足”和“大模型方法的优势”这直接呼应你的技术选型。第二章需求分析与总体设计写系统要解决什么、功能模块划分、采用“离线分析在线推荐”的架构原因。第三章数据获取与预处理包括数据来源说明注意合规表述、清洗规则、标签体系设计。第四章大模型情感分析模块这是技术核心章写Prompt设计过程、输出解析方案、对比实验数据和典型案例分析。第五章餐厅推荐系统实现写评分公式、权重融合逻辑、协同过滤配合策略。第六章系统测试与展示写功能测试用例放系统截图和结果指标。第七八章总结与展望重点写“还做得不够好的地方”比如大模型结果存在偶发不稳定、真实场景在线推荐延迟问题这些都是很好的延伸话题。有个常被忽视的点论文里的图表不要截大屏截图要单独导出曲线图、柱状图、对比表。截一个大框套小框的系统界面图打印出来文字都看不清那是减分项。4.3 PPT和答辩讲解10分钟讲清整套逻辑PPT不需要多每页都是核心我惯用的结构是11页封面标题和姓名学号选题背景餐饮评论数据量大、用户决策成本高、传统推荐缺乏个性化核心问题如何自动分析海量评论如何生成个性化推荐技术方案总览数据清洗、大模型情感分析、权重推荐、Web展示数据方案来源、规模、清洗前后对比大模型Prompt设计展示一段输入和结构化JSON输出对比实验一个大模型vs传统方法的表格推荐算法评分公式加参数说明系统演示录一段短视频或现场演示三个页面总结完成的工作与核心创新点致谢答辩讲解的核心技巧是前三分钟讲清楚“我做了什么、为什么这么做”中间五分钟用演示和截图讲“效果怎么样”最后两分钟总结“这项工作的价值和不足”。不要一上来就讲代码细节评委关心的第一个问题永远是“你这个题目解决的是什么问题”而不是“你用了几个循环”。5. 常见问题与排查技巧实录5.1 大模型输出不稳定怎么办这个是最常见的问题。偶尔模型会多输出一段“说明文字”导致JSON解析失败偶尔维度字段值格式不规范。我的处理方案有两层第一层容错解析。写一个专门的后处理函数不是直接用json.loads而是先用正则抽取文本里最像JSON的部分再尝试解析。万一还是失败把这条评论标记为待重试稍后统一重新调用。第二层缓存与重试机制。每条评论分析完后立刻缓存失败任务独立管理。不要让一次调用的异常影响整条流水线。实测这套机制可以把正常情绪分析的“成功率”稳定在99%以上。5.2 中文分词和编码问题传统方法路径下Jieba分词的结果质量会直接影响TF-IDF特征。比如“不太好吃”切成“不太/好吃”语义就偏正向了。大模型方案对分词不敏感但清洗环节偶尔会出现全角半角混用、特殊空白字符建议统一用unicodedata.normalize处理能避开很多坑。还有个小技巧在写入CSV文件时强制指定encodingutf-8-sig这样用Excel打开不会乱码。答辩前把中间数据和最终结果都导出为可视化图表这份表格放在论文附录里评委提问时直接查数据印象分会好很多。5.3 数据不均衡和异常值处理餐饮评分数据天然偏正4分以上评论占多数负面样本很少。这会带来两个问题一是情感分析模型对负面评论召回低二是推荐系统容易“全榜好评”区分度不够。处理思路是分析阶段在评估集里人为平衡三类评论的比例单独算负面评论的召回率推荐阶段增加评分离散程度展示比如“这家店虽然整体分不高但口味分极高”这反而是推荐逻辑的亮点。不要强行让模型天天去生成负面结论真实数据什么样就展示什么样说服力更强。5.4 答辩高频问题怎么接整理一下我观察到的评委针对这类题目问得最多的问题“为什么不用现成的BERT模型微调”回答框架是BERT微调需要高质量标注维度级标注成本过高大模型在零样本下已经能达到可用准确率更适合快速验证和迭代。同时承认BERT微调在完全监督条件下上限更高算是个人方案的一个改进方向。“你们的推荐和美团平台本身的推荐有什么区别”回答框架是平台基于用户行为日志和排序模型这里主要基于评论内容的语义理解。这里侧重解释技术差异“我们的分数来自评论情感而不是销量数据在评论区数据质量高的业务场景下更容易给出解释性推荐”。“大模型调用成本问题怎么考虑”回答框架是离线批量分析承担绝大部分成本在线模块使用缓存和索引单个用户查询不直接触发大模型调用这是工程可行性层面的折中方案。我自己带模拟项目的时候最常说的一句话是代码好不好不是第一位能不能一步一步讲清楚“为什么这样设计”才是核心。这个题目从头到尾就是一个完整的思考链——从评论文字到情感标签从情感标签到推荐分数从推荐分数到用户界面每一层都在上一个层的输出上叠加逻辑。把这套逻辑吃透了源码、LW、PPT、讲解四件套做起来就是水到渠成的事。最后一个建议答辩前务必把“一个用户完整的使用流程”在系统里跑三遍第一遍在论文里截图第二遍在PPT里录屏第三遍留着现场演示。这个准备做完你已经超过绝大多数同题目的同学了。