去年折腾毕设的时候，我翻遍了各种选题库，最后定在了“餐饮评论情感分析+餐厅推荐系统”这个方向上。原因很简单：题目够具体，技术栈横跨数据分析、大模型、推荐系统，既有传统机器学习的内容，又能蹭上大模型的热点，还能做出一个看得见摸得着的Web系统。尤其是Python+大模型的组合，答辩的时候一说“用大模型做细粒度情感分析”，评委的兴趣马上就不一样了。这篇就把整个项目从0到1的搭建过程、关键算法选型、以及我填过的那些坑全部摊开讲，给后面选类似题目的同学一个完整参考。
这个题目的核心价值在于它不是一个孤立的算法实验，而是一个“数据→算法→应用”的闭环：先采集餐饮评论数据，再对大模型做情感分析，最后把情感分数注入推荐系统，生成用户想去的餐厅。整套流程跑通之后，论文的创新点、系统演示、甚至答辩PPT都能顺势推进。我建议把它定位成“面向餐饮领域的大模型情感分析与个性化推荐系统”，目标人群就是正在做毕设、又想快速出成果的学生，以及对NLP落地感兴趣的开发爱好者。
1. 为什么毕设选这个方向：情感分析+推荐系统的组合逻辑
1.1 从评论文本里挖出用户的真实意图
餐饮平台的评论区里藏着大量信息：用户说“环境不错但菜太咸”，用传统的星级评分看是4分，但情感其实是负面的；用户说“排队两小时终于吃上了，牛肉真的绝”，星级只有3分，情感却非常正向。这些细节说明，光靠星级做推荐会丢失大量语义信息，而情感分析能把“片面的分数”还原成“立体的评价”。
这也是为什么毕设题目一定要带上“情感分析”——它让整个项目有了足够深的切入点。你可以对比传统方法和大模型方法的效果差异，也能针对餐饮领域优化分类维度，细化到“口味”“服务”“环境”“性价比”四个子维度，让情感分析结果具备可解释性。
1.2 大模型不是花架子，它让毕设天花板高了很多
放在几年前，情感分析的主流做法是TF-IDF+朴素贝叶斯或者BERT微调。但BERT微调的标注成本很高，动辄几千条人工标注，对学生来说时间上根本耗不起。大模型路线的优势在于：可以用少量样本（甚至零样本）就能达到可用的效果，而且对于“阴阳怪气”的评论、网络新词、谐音梗，理解能力明显更强。
我在项目里采用了一条折中路线：不微调，而是用精心设计的Prompt调用开源底座模型进行推理。这样既避免了大模型训练的高昂成本，又能保证项目“大模型”这个标签能落进论文里。后续如果你有条件，再在开源底座模型上加一层LoRA微调作为进阶实验，工作量也够写一篇小论文了。
1.3 推荐系统负责把算法价值变成用户能感知的页面
如果只做情感分析，系统演示就是个“输入评论、输出概率”的枯燥页面。加上了餐厅推荐，用户视角就完全不同了：输入偏好（比如“川菜”“人均100以内”），系统返回一份按“综合口味分”排序的餐厅列表，点进去能看到情感分析雷达图。这样一来，算法结果有了业务出口，也更容易在答辩现场讲出场景感。
我设计的推荐逻辑没有用太重的图神经网络，而是用“情感分数注入+多因子加权排序”：情感分析为每家餐厅生成一个“口碑情感分”，再与用户的历史偏好、餐厅的星级、人均消费、评论热度做加权融合。这套方案计算量小、可解释性极强，非常适合毕设展示。
2. 数据是地基：餐饮评论数据采集与预处理的完整链路
2.1 先解决数据从哪来的问题
做这个项目的第一步不是写算法，而是搞定数据。我在实际开发中使用了两种数据组合：一部分是公开的餐饮评论脱敏数据集（网上有各种NLP标注语料），另一部分是自行采集的模拟评论。这里必须强调，正规做法是使用官方公开数据集、学术共享数据集，或者通过平台合规接口获取，绝对不要做破坏性爬虫，否则轻则无法答辩，重则有法律风险。毕设的核心是证明你掌握了数据处理方法，而不是证明你能绕过反爬机制。
我建议的数据规模是：至少1万条有效评论，其中餐饮相关评论占比超过80%。如果实在凑不够，可以通过数据增强方式，对已有的优质样本做同义词替换、句式变换，凑到8000条以上。答辩的时候数据量是一个很敏感的点，评委一问“数据有多大”，小于5000条会有点难看。
2.2 评论字段的取舍与用户评分建模
原始评论数据通常长这样：
| 字段 | 示例 | 用途 |
|---|---|---|
| comment_id | C1002301 | 去重依据 |
| user_id | U88921 | 构建用户历史偏好 |
| shop_id | S3301 | 关联餐厅维度 |
| rating | 4（星级） | 作为弱标签/初始分数 |
| content | 味道不错，上菜快，但空调太吵 | 情感分析输入 |
| taste_labels | 酸辣, 微辣 | 口味标签匹配 |
| price_per_person | 85 | 过滤候选餐厅 |
| comment_time | 2024-03-12 | 时间衰减权重 |
拿到这些字段后，第一步是按comment_id去重，去掉内容长度少于5个字的“无意义评论”，比如“好”“赞”这类对于情感分析价值太低。然后对正文做预处理：去掉HTML标签、修正全角半角、统一繁简，同时保留表情符号，因为表情是情感的重要信号。
2.3 弱标签生成与人工校准
餐饮评论没有现成的正负情感标签，我采用了“星级映射+人工抽检”的弱标签策略：4星及以上初始判定为积极，2星及以下判定为消极，3星标为中性。这种方法争议很大，因为很多3星评论其实情感偏正面，所以我又从不同星级中各抽200条，人工修正标签，最终得到600条标注集作为评估基准。其余评论的情感标签则由大模型推理生成，再把推理结果与人工标签做比对，评估准确率。
这里有个很实用的预处理技巧：按“转义字符处理→jieba分词→停用词过滤→文本长度截断（最长200字）”的顺序走。分词时记得把“串串”“撸串”这类餐饮词加入自定义词典，否则分出来的效果特别怪。
3. 大模型情感分析落地：从Prompt设计到效果调优
3.1 为什么选择“Prompt+开源底座模型”而不是微调
毕设有自己的时间预算，微调一个大模型需要准备训练集、调参、跑好几轮，稍有不对就前功尽弃。我的选择是直接调用一个参数量7B左右的开源底座模型，在它的基座上做Prompt推理。这个方案的好处在于：零训练成本、结果可复现、方便换底座模型做对比实验。论文里可以写“基于预训练语言模型的零样本情感分析”，听起来很高级，实操却只需要写几百行调用代码。
如果后续想提升准确率，可以在同一底座模型上做LoRA微调，用那600条人工标注数据训一个小分支，通常能让F1提升5-8个百分点。这个作为“扩展实验”写进论文，答辩时被问到“你觉得大模型方案还能怎么改进”，就可以自然回答“做微调”。但主流程我强烈建议用Prompt方案先把系统跑通。
3.2 Prompt模板要能“逼”模型输出结构化JSON
直接让模型输出“积极/中性/消极”，结果很难被程序解析，因为模型可能输出“正面积极，情绪较为满意”这种长文本。所以Prompt里必须指定输出格式，我用的是：
你是一位餐饮评论情感分析专家。请分析以下评论的情感极性，并输出包含三个字段的JSON： - sentiment: "positive" / "neutral" / "negative" - scores: 口味、服务、环境、性价比四个维度的情感分数，范围0~1 - reason: 一句简短解释 严格只输出JSON，不要输出额外文字。 评论：{comment}实测下来，7B底座模型对格式的遵循度普遍在95%以上，偶尔会出现多了一个反引号或者字段名拼错的情况。所以后处理必须做一层JSON修复逻辑：用正则提取JSON对象，如果解析失败则调用一次“仅以JSON输出”的重试提示。
3.3 批量推理的工程细节：缓存、重试与并发
批量分析1万条评论，如果逐条串行调用模型，可能要跑好几个小时。我加了两层缓存：第一层是内存缓存，用评论的MD5作为key，避免重复推理；第二层是磁盘缓存，把已经推理的结果存成JSONL文件，中途断掉也能断点续跑。并发方面，本地推理时就开多进程，每进程一个模型实例，配合请求队列。如果是调用在线API，则要控制QPS，否则容易触发限流。
评估阶段我拿600条人工标注数据做了测试，准确率大概在82%-85%之间，F1值在0.80左右，相比直接用星级映射的60%出头，提升非常明显。这种对比结果是论文里非常有价值的一张表，建议一定保留。
4. 餐厅推荐系统的设计与情感分数的注入
4.1 把食堂级推荐做到“说得清道理”
很多人一上来就想用DeepFM、GraphEmbedding，反而不好收场。毕设推荐系统最忌“黑盒”，评委问一句“为什么推荐这家”，你答不上来就尴尬了。我最后采用的是一个加权排序模型，指标全部可解释：
- 基础活跃度：餐厅评论数量权重，避免冷门餐厅靠单条好评刷上来
- 情感总分：由大模型对每条评论的情感分数聚合而来，某个维度的平均值越高，对应餐厅在该维度上的分数越高
- 用户偏好匹配度：用户历史浏览/点评中高频出现的关键词，与餐厅标签做相似度计算
- 时间衰减：越近的评论权重越高，因为餐厅状态变化很快
综合得分的计算公式为：FinalScore = 0.3*情感总分 + 0.3*口味匹配度 + 0.2*环境分 + 0.1*服务分 + 0.1*价格匹配度
这个权重不是拍脑袋定的，我用了简单的网格搜索，在用户的模拟点击日志上找了一组最优参数，论文里可以写清楚。
4.2 用户偏好画像与候选集生成
用户画像从两个维度构建：一个是从历史评论中提取的高频口味词（火锅、粤菜、甜品），另一个是通过情感分析结果反推的用户“满意关键词”，比如用户对“服务”维度的情感分数长期偏低，就说明他对服务不敏感，不会因为某家店服务差就强排除。
候选集生成需要先用硬规则过滤：根据用户选择的地理范围、人均价格区间、餐厅类型过滤一轮，把候选数量压到50家以内；再用上面的加权公式排序，取Top10展示。每次推荐展示后，记录用户是否点击、是否查看详情，作为后续权重优化的依据。
4.3 冷启动问题怎么在毕设里“装得专业”
新餐厅没有评论，情感分是空值，我的处理方法是：用同商圈、同类型餐厅的情感分均值作为冷启动填充。这个办法虽然粗糙，但逻辑清晰。答辩时被问到冷启动，我直接拿出这条方案，说明自己考虑了稀疏性问题，然后指出“更深层的冷启动方案可以引入图神经网络”，评委一般不会再追问。
5. 从代码到答辩：系统实现、演示与毕设材料整理
5.1 系统整体架构与关键依赖
我的系统分四层：数据层（SQLite/MySQL存评论与餐厅信息）、算法层（情感分析服务、推荐排序服务）、服务层（Flask/FastAPI提供REST接口）、展示层（一个简洁的Web前端页面）。个人经验是用Flask写后端最稳，前端用原生HTML+CSS+一点JavaScript就足够，不要为了炫技引入太重的前端框架，毕设精力有限。
核心依赖清单如下，版本建议锁死：
| 组件 | 用途 |
|---|---|
| Python 3.10 | 主开发语言 |
| transformers | 加载开源底座模型 |
| torch | 模型推理 |
| jieba | 中文分词 |
| Flask | 后端接口 |
| Bootstrap | 前端样式 |
5.2 系统演示流程要提前排练
答辩现场最尴尬的就是系统崩溃。我的建议是准备两条演示路径：线下完整演示和录屏备份。演示时先输入“川菜、人均80”，系统返回推荐列表；点开第一家餐厅，展示情感分析雷达图（口味、服务、环境、性价比的细粒度分数）；再展示评论文本和对应的情感极性高亮，这样整个数据处理链条就完整呈现了。整个演示控制在3分钟以内，提前录一份5分钟的完整视频，现场万一网络波动就播视频。
5.3 论文、LW、PPT的素材组织法
LW（论文）的结构可以直接对标系统架构：
- 绪论：餐饮评论场景下情感分析与推荐系统的研究意义
- 技术基础：传统情感分析、大模型发展、推荐算法综述
- 需求分析：系统功能与非功能需求，绘制用例图
- 系统设计：整体架构、数据库设计、情感分析模块设计、推荐算法设计
- 系统实现：关键代码、页面截图、核心函数说明
- 实验与分析：模型效果对比、推荐效果评估、案例分析
PPT则按“背景→创新点→系统演示→实验数据→总结展望”五段式来做。创新点我写了三条：一是将大模型情感分析引入餐饮评论，二是细粒度情感维度拆解，三是情感分数与推荐算法的融合。不要贪多，三条足够。
6. 毕设踩坑实录：那些文档里不会告诉你的问题
6.1 大模型推理的“格式幻觉”比想象中严重
我第一次跑批量情感分析的时候，把所有评论直接灌给模型，结果有几百条返回了“基于以上分析，我认为……”。这种“说废话”的输出会直接导致JSON解析失败。后来我加了两道保险：一是在Prompt里用“严格只输出JSON”这种命令式语气，二是后处理里写了一个兜底正则，抓取花括号内的内容并补全缺失引号。这个坑在论文里可以写成“针对大模型输出结构化数据不稳定性的处理策略”，反而是个加分项。
6.2 数据不均衡导致情感分析整体偏向“好评”
餐饮评论天然就是好评多、差评少，如果不加处理，模型会对负面评论特别不敏感。我在抽样时对负面评论做了1.2倍过采样，又在Prompt里加了一句“注意识别隐含的负面情绪”，效果明显改观。如果你时间充裕，还可以在评估时单独看差评的Recall，因为差评对推荐系统“排除坏店”的价值更大。
6.3 弱标签和人工标注之间要留“纠错通道”
直接用星级当标签会导致推荐结果跟平台星级高度重合，评委一看觉得没有增量。所以我特意在系统里加了一个“情感偏移量”：如果一条评论的内容情感极性与星级不一致（比如星级3星但文字全是好评），就把它标记为“偏移样本”，单独统计。这个偏移量在论文里可以作为“情感分析相对于传统评分的独特价值”的实证数据，非常出彩。
6.4 演示机器上模型推理速度太慢，差点翻车
第一次上演示机器，我用CPU跑7B模型，一条评论要十几秒，整个页面卡到没法看。后来我做了三个优化：先把所有餐厅评论的情感分析结果预计算好存入数据库，用ONNX格式量化模型减小体积，页面加载时只展示预计算结果。这样答辩现场只是查表，速度飞快。如果你的机器实在不行，也可以考虑把模型切换到更小的版本，牺牲一点点准确率换流畅度，演示效果优先。
我个人的最终体会是：这类毕设项目的成败不在于用了多牛的算法，而在于每个环节都讲得清、连得上。情感分析不是越高分越好，能把它和推荐系统自然地缝合起来，让评委觉得“这个系统换个人也能跑通”，你就赢了。后面做类似题目的同学，最需要盯住的就是那条从评论到推荐的数据流，把这条链路走顺，项目就成功了大半。
