Django+大模型美食推荐系统毕设实战：从架构到落地

每年毕设季节我都会看到一大批美食推荐系统的题目说实话大部分都做成了换皮的商品管理系统用户管理、菜谱增删改查、简单的评分推荐答辩的时候放两张截图就算完事。但如果你在这个题目里加一个大模型整个项目的高度就完全不同了——它不再是一个CRUD演示而是一个从传统推荐算法到LLM应用、从关系型数据管理到数据分析可视化的综合性系统。这篇博文我打算把Django大模型美食推荐系统这个毕设题目从选题逻辑到系统架构、从推荐方案到数据分析和最后的交付文档完整拆开讲一遍。我带过不少做这类系统的学生这篇里大部分内容都是从那些项目里沉淀下来的实际方案和踩坑记录适合正在选题或者已经开干、但不太清楚大模型和大数据部分该落到什么程度的同学参考。1. 这个选题为什么值得做从凑数项目到技术融合亮点1.1 美食推荐系统不新鲜新鲜的是技术组合先说句实在话纯粹的美食推荐系统在推荐算法层面已经没什么可折腾的了。用户-菜谱-评分这三张表加上协同过滤或者简单的内容推荐本科毕设里一抓一大把。但含大模型量不同。这几年无论是企业面试还是毕业答辩关注点都在你如何把LLM落到实际业务里而不是你调用了哪个大模型的API做了个聊天机器人。美食推荐系统恰好是一个特别自然的落地场景——推荐系统需要理解用户偏好、理解菜品语义、生成个性化推荐理由这些全是传统算法做不好、大模型却能轻松胜任的地方。所以这个选题的竞争力不在推荐二字而在传统推荐LLM增强数据分析这三个技术栈的融合。你等于用一个题目同时覆盖了后端开发、算法设计、大模型应用、数据处理与可视化四个方向答辩的时候任何一个方向的评委都能找到他想听的东西。1.2 这个项目适合什么样的人选实话实说这个题目比普通的CRUD系统至少多出30%-50%的工作量不是所有人都适合。我建议符合下面两种情况的同学选它你有Python基础Django哪怕只会写Model和View但愿意花时间读文档、调接口。大模型的接入本身不复杂难点在业务整合如果你的Python功底不够后面容易卡壳。你对推荐系统和数据可视化至少有一个方向有真实兴趣。这个题目最怕的就是两部分都敷衍最后做出来四不像。如果只是想要一个稳妥、省事的毕设那我建议老老实实做一个普通的美食管理系统加一个简单的协同过滤别硬上大模型。但如果你确实想在毕设里体现一点技术含量也愿意花时间那这个题目的上限非常高——我见过有学生把推荐解释、菜谱问答、饮食数据分析全部做完最后论文直接被院里推优的。2. 系统架构与技术选型Django如何扛起一台大模型大数据应用2.1 整体分层设计先给一个经过实际项目验证的分层架构你在做系统设计章节的时候可以直接参考表现层前端HTML模板Bootstrap或Vue图表用ECharts。推荐理由生成、菜谱详情、数据分析看板都在这一层展示。应用层Django Views负责用户请求处理、业务逻辑编排、调用推荐服务和LLM服务。服务层Service模块包括推荐引擎召回排序、LLM服务封装推荐解释、菜谱问答、语义标签提取、数据分析模块统计计算、聚类分析。数据层MySQL存业务数据用户、菜谱、评分、收藏Redis做缓存热门菜谱、大模型响应缓存如果需要存储向量可以用一个轻量的向量存储如Chroma或者直接存PostgreSQL的pgvector。这个分层的核心原则是大模型相关逻辑绝对不能散落在View函数里必须独立成Service模块。原因有两个一是方便替换模型今天用这个API明天想换另一个只改Service层二是答辩的时候你能清楚地讲出我把大模型能力封装成了服务接口这是架构思维的体现。2.2 Django后端为什么不是FastAPI、Spring Boot我特意让学生在毕设里用Django不只是因为题目要求而是Django在毕设场景下确实有不可替代的优势。Django自带Admin管理后台菜谱、用户、分类这些数据的管理界面几乎零成本搞定自带ORM和迁移机制建表改表比手写SQL省太多事自带模板、表单、认证体系你完全不需要额外折腾用户登录注册。你可能会问大模型调用通常是异步任务Django同步请求-响应模型够用吗我的答案是毕设场景足够。每次推荐解释的生成控制在2-3秒内用户可接受也不需要Celery。如果你想做得更专业可以给Django配一个后台任务队列比如用Celery加Redis把LLM调用放到异步任务里但这不是必选项。我的建议是第一版全部同步实现在2-3秒内返回跑通之后有余力再上异步不要一上来就引入Celery增加无谓的复杂度。2.3 数据处理和分析模块的位置大数据毕业设计这个标签落到实际操作层面并不是真的让你搭Hadoop集群。你真正要做的是把这几个部分做好数据规模菜谱数据至少准备几千到上万条。可以通过爬虫获取要注意爬取频率和数据合法性也可以找公开数据集。数据量达标了大数据分析才说得上话。数据预处理写一个完整的清洗脚本包括缺失值处理、去重、文本归一化、标签整理把脏数据变成可分析的干净数据这个环节非常重要答辩时往这一讲懂行的评委立刻知道你不是在糊弄。分析维度后续章节细讲但大概要覆盖菜品分类分布、食材使用频率、热量营养结构、用户口味偏好等多个维度。可视化呈现用ECharts或者Plotly输出交互式图表做成一个数据看板页面让分析结果可视、可读、可操作。我反复跟学生强调毕设里的大数据重点是数据链路的完整性——采集、清洗、存储、分析、可视化、决策反馈。你把这六步讲清楚了比任何大数据框架都更有说服力。3. 推荐系统的核心实现召回、排序与有温度的推荐理由3.1 召回层基于协同过滤和内容相似度的候选集生成推荐系统第一步是召回——从几千道菜里挑出几十道候选。这一步用大模型做代价太高也没必要传统算法足够。我推荐在毕设里做两种召回渠道将来写论文也能形成对比实验基于物品的协同过滤Item-Based CF用户对菜谱评分或收藏之后计算菜谱之间的相似度矩阵。相似度的依据是哪些菜品经常被同一用户操作。创建用户-菜谱交互矩阵用余弦相似度或皮尔逊相关系数计算菜品相似度然后对用户操作过的菜找最相似的N道菜。这是最经典的方法推荐结果稳定而且可以在系统里清晰地用表格展示因为A所以推荐B。基于内容的召回Content-Based对菜谱的名称、食材、分类、标签做文本向量化。可以用TF-IDF也可以用预训练模型如Sentence-BERT将菜谱描述编码成向量再用余弦相似度计算内容相似度。后者效果明显更好但需要注意模型体积和推理时间可以离线先算好所有菜谱的向量存数据库召回时只查一次。两种召回各取TopN比如各取30合并去重后得到60道左右的候选集交给排序层。伪代码大致是这样def recall(user_id, top_n30): # 基于物品协同过滤召回 interacted get_user_interacted_items(user_id) cf_candidates item_cf_recall(interacted, top_ntop_n) # 基于内容相似度召回 content_candidates content_based_recall(interacted, top_ntop_n) # 合并、按综合得分排序 merged merge_and_score(cf_candidates, content_candidates) return merged[:top_n]3.2 排序层大模型作为排序器如何工作召回之后你手上有几十道候选菜这时候让大模型做排序。大模型没有办法直接对几十道菜的数值分数排序——这是大模型不擅长的事你不能让LLM做一个精确计算。所以我的方案不是让大模型打分排序而是让大模型的语义理解能力帮传统排序做增强。具体做法给大模型一个用户画像包括用户的口味偏好标签比如爱吃辣偏爱素食对海鲜过敏、历史交互菜品的口味倾向。把候选菜谱的标签和描述作为上下文丢给模型让模型输出一个语义匹配评分1-5分表示这道菜在语义层面和用户偏好的匹配程度。把语义匹配评分和传统算法的排序分数加权融合得出最终排序。举例来说用户历史爱点麻辣香锅水煮肉片召回里有宫保鸡丁和清蒸鲈鱼传统协同过滤可能因为数据稀疏给两者差不多分但大模型看一眼就知道宫保鸡丁更符合这个用户的重口味偏好语义匹配分天然更高。这一层就是整个系统最出彩的部分答辩时评委对这个机制一定会感兴趣。提示词模板给一个可以照着改的版本你是一个美食推荐助手。下面是我整理的用户偏好{user_profile} 候选菜谱列表如下{candidate_list} 请对每道菜与用户偏好的语义匹配程度进行打分1-5分只输出JSON格式结果 {items: [{dish_id: 1, score: 4.2, reason: 用户偏好重口味该菜品以麻辣为特色}]}这里有个操作细节必须要求大模型输出结构化JSON并且用response_format之类的参数固定格式。不要让模型自由发挥否则解析结果会搞到你崩溃。3.3 推荐解释生成让系统会说话这是我在项目里最喜欢的一个模块也是大模型最能秀肌肉的地方。传统推荐系统只能说根据你的收藏推荐但大模型可以生成一段有温度的话看你最近常搜川菜今天推荐的这道辣子鸡用的是鸡腿肉比起鸡胸更嫩而且我觉得你会喜欢它的干辣椒配花生米的香气。要不要试一下生成推荐理由有三种做法效果从低到高模板拼接最基础把用户标签和菜品标签拼成固定句式。效果僵硬但胜在稳定。标签LLM扩写推荐先提取用户偏好标签和菜品味型标签让大模型基于标签生成解释。比纯模板自然得多又比把全部上下文丢给模型省Token。全上下文多轮对话进阶把用户历史行为和这道菜的特征全部送入模型让模型自由发挥。效果最好但要注意输出长度和审查问题。我的建议是选第二种。第三种如果处理不好容易让模型脑补出用户没点过的菜反而在答辩时被问倒。还有很重要的一个体验细节推荐理由不要每次打开页面都重新生成生成一次就缓存到Redis至少缓存一天。不然用户刷新一次页面理由变了观感非常差而且你的API账单会很难看。4. 菜谱食谱数据分析从数据清洗到可视化看板的完整链路4.1 数据获取与预处理数据是整个项目的地基。菜谱数据从哪里来公开数据集、爬虫、手动标注都可以但不管来源是什么你必须构建一个连贯的数据获取-清洗流程。我建议至少准备菜谱名称、分类口味标签川菜、粤菜、甜点等食材清单包含用量信息后面做营养分析要用烹饪步骤文本描述热量、蛋白质、脂肪、碳水等营养数据能从食材估算最好浏览量、收藏量、评分等行为数据可以自动生成模拟数据清洗环节要注意几个坑食材名称不统一土豆和马铃薯、标签格式不一致有的空格分隔有的逗号分隔、营养数据缺失。写一个Python清洗脚本用Pandas处理核心逻辑包括全表去重、缺失值填充策略营养数据缺失可以按食材均值估算、标签标准化映射。4.2 分析维度与可视化方案数据分析模块建议做一个数据看板页面包含以下维度每个维度配对应的图表菜品分类分布饼图或环形图看八大菜系和甜点主食各占多少比例。食材使用频率TopN条形图统计哪些食材出现频率最高。热量区间分布直方图查看菜品的能量分布规律明确清淡菜和热量炸弹的比例。口味标签共现分析用气泡图或矩形树图展示辣和川菜、甜和烘焙等标签之间的关联关系。用户操作行为分析折线图展示某个时间段内收藏、评分、浏览的趋势变化。每个分析维度建议配一段文字结论比如从食材高频榜看辣椒、蒜、姜三大基础调味食材在数据集中占有主导地位。答辩时这种图表数据洞察的组合非常加分证明你不只是画了图是真的做了分析思考。4.3 让数据分析支撑推荐决策这里有个容易忽略但又特别能出彩的点数据分析结果要反过来服务推荐系统。比如高热度菜品、高评分菜品的标签分布可以作为推荐系统的全局热门候选聚类分析可以将菜谱划分为重口型清淡型甜口型等口味簇辅助构建用户画像某些食材的可替代关系可以在推荐时考虑用户不吃的食材做排除。也就是说让数据分析模块成为推荐系统的一个上游输入而不是一个孤立的、展示用的页面。这一条如果能讲清楚你的系统在逻辑上就形成了一个完整的闭环数据采集 - 分析 - 画像 - 推荐 - 反馈 - 再分析。这是真正拉开和普通毕设差距的地方。5. 大模型接入的实战细节API选择、提示词模板、成本与降级策略5.1 模型选型与部署方式这个问题在答疑群里被问了无数次。明确说结论别自己微调也尽量别自己本地部署一个十几B的大模型。你的机器没有足够的显存推理慢还会耽误进度。最优选择是用成熟的大模型API服务国内可直连的模型服务不少选一个你觉得文档顺手、有免费额度的用就行。等系统功能全部跑通之后如果你想展示部署能力可以用Ollama在本地跑一个小参数的模型做一个降级备选但这属于加分项不是必选。选择模型时重点考虑三个维度语义理解能力推荐解释和排序打分都依赖它、输出稳定性必须是中文能力扎实的模型、响应速度推荐场景3秒内返回比较好。5.2 提示词模板设计与上下文管理提示词模板是整个大模型模块最核心的工程点。实操中我会把模板拆成三部分管理System Prompt定义角色和行为边界。比如你是专业的美食推荐助手只回复与菜谱推荐、饮食偏好相关的内容不回答无关问题。User Context动态拼入用户画像和当前请求相关的数据候选菜品、历史偏好、排除食材等。Output Constraint严格指定输出格式并要求只输出JSON不要额外内容。这一步能省掉后面大量解析代码。一个常见坑上下文太长。如果你把所有候选菜谱的完整描述都塞进Prompt不仅慢还费钱。解决办法是抽特征只传菜名、标签、核心食材、热量这几个关键字段把完整描述留在系统里供展示用。我实测过只传摘要字段的效果和传全文几乎一样成本却少了一半以上。5.3 缓存、超时与降级处理调用大模型API有一个毕设里几乎必遇的情况线上服务偶发超时或报错。处理不好用户刷到推荐页直接白屏开题的时候会被答辩老师抓住这个痛点削弱整体印象。我的建议是做一个三层兜底第一层Redis缓存。同一用户同一场景的推荐解释6小时内不重新生成直接命中缓存。第二层超时控制。用requests或者httpx调大模型API时设置明确的超时时间5秒超时后触发本地兜底逻辑。第三层本地模板兜底。大模型挂了就用根据你的{标签}偏好为你推荐{菜品名}这类模板生成推荐理由。前端的处理也要做推荐解释区域先渲染骨架屏或生成中...的占位符大模型响应返回后再替换而不是整个页面等接口。这三层做完无论线上API怎么抽风你的系统都能正常演示这个健壮性设计本身就是答辩时的亮点。6. 毕业设计四件套源码、LW文档、PPT、演示讲解的准备技巧6.1 源码工程如何组织才不像demo很多学生的源码树一眼看去就是随手写的练习对自己很不利。我给学生的统一要求是源码目录必须体现业务分层至少要有apps/业务模块、services/核心服务推荐、LLM、数据分析、utils/通用工具、scripts/数据清洗、数据导入这几个目录。每个服务模块内部再按职责拆成文件recommender.py、llm_service.py、data_analyzer.py。另外很重要但容易被忽略的两件小事一是配置文件和环境变量要分开用python-decouple或django-environ管理密钥千万别把API Key硬编码在代码里且随源码一起提交。答辩老师如果看到源码里有硬编码密钥印象分会降不少。二是代码里必须写关键注释和README说明怎么迁移数据库、怎么配置大模型API、怎么跑数据清洗脚本。这三样加起来给人的第一印象就是这是个正经工程。6.2 LW文档的写作重心LW文档也就是任务书、开题报告、论文这类文档材料的写作最忌变成流水账。你不能把系统操作流程写完了事必须体现技术深度。按照我的经验论文主体要重点突出这几块传统推荐算法的原理与实现细节协同过滤计算过程、相似度公式、数学推导大模型增强推荐的设计动机与技术方案为什么需要大模型、语义匹配逻辑、与协同过滤的融合策略数据分析的方法论与结果解读数据清洗步骤、图表设计、分析结论系统测试特别是推荐效果的评估命中率、用户满意度问卷、与传统方法对比实验这里强烈建议做一个对比实验同一个用户一组只看协同过滤结果一组看协同过滤大模型增强结果统计点击率或满意度评分。这个对比实验做出来论文的含金量直接上一个台阶。6.3 PPT和答辩演示的节奏设计答辩PPT不要超过20页逻辑线建议这样走选题背景与意义 - 系统架构 - 核心技术是怎么实现的 - 数据分析结果展示 - 系统演示截图 - 总结与展望。重心放在第三和第四部分前面两三页快速过完。演示环节我的建议提前准备一份带干净数据的演示账号演示操作脚本要在答辩前完整走3遍以上。准备好几个关键演示点——大模型生成的推荐解释、数据看板的交互图表、推荐效果对比实验的结果页面。另外一定要提前检查大模型API能不能用万一答辩当天服务抽风要能用本地兜底方案完成演示。这条踩坑经验是真的带过血的教训有个学生答辩当天遇到模型服务限流推荐理由一片空白磕磕绊绊讲完分数惨淡。7. 六个月踩坑清单排期规划与常见问题应对7.1 时间排期建议按4-5个月的常规毕设周期我是这样给学生规划的第1个月选题确认、技术预研、数据收集与清洗。这个月最关键数据量不达标后面一切白搭。第2个月Django基础搭好用户、菜谱、评分、收藏这几个核心模块做完。第3个月推荐系统核心实现协同过滤跑通能把推荐列表展示出来。第4个月大模型接入推荐解释生成、菜谱问答、语义排序完成。第5个月数据分析模块、可视化看板、系统测试、文档撰写。最后留一周做PPT和答辩预演。很多人时间规划出问题的根源是把数据清洗和预研拖到了第二个月。这个必须前置不然第4月你会发现推荐模块是在垃圾数据上做出来的返工成本极高。7.2 高频踩坑点每周答疑都能遇见的坑我挑几个有代表性的列出来建议收藏备用Djang ORM的N1查询。推荐列表一次查几百个菜谱没用select_related和prefetch_related的话内存和耗时直接爆炸。查菜谱时必须连食材表、标签表一起预取。大模型输出解析失败。前面说的只输出JSON实操中模型还是可能多输出一段废话。解析时不要json.loads一把梭做一个容错函数尝试提取第一个{到最后一个}之间的子串再解析还能顺带处理Markdown代码块包裹的情况。菜谱图片。很多学生忽略图片字段觉得用占位图就行结果展示的时候整个页面灰蒙蒙的答辩观感非常差。尽量找带真实菜品图片的数据源没有图片就搜索可免费使用的图片资源补充。排行榜和猜你喜欢的数据同步。用户收藏、评分后需要刷新推荐建议做成信号机制Model保存后自动更新用户的候选池缓存而不是每次请求都重算。Python版本兼容性。安装Django、pandas、sentence-transformers这些库时最怕Python版本过新或过旧。建议统一用Python 3.10-3.11能避免90%的依赖噩梦。踩过这些坑之后我自己做这种Django大模型项目的时候反而是最放心的因为问题都是可预见的方案也都是成熟的。如果非要说还有什么变量那就是大模型服务本身的质量波动——所以兜底策略我从第一版就开始做做到答辩前一晚还在优化。这个项目的上限不低下限其实也硬关键就看你愿不愿意把每一个模块都按能拿出来讲的标准去打磨。