每年到了毕设季都会有一批同学被“Django大模型推荐系统”这类题目吸引又不知道怎么下手。前几天有位学弟问我题目是“基于Django和LLM大模型的智能旅游路线规划与个性化推荐系统”听起来很高大上但实际要做哪些模块论文怎么组织答辩怎么讲这其实就是今天我想聊的话题——做完一个同类毕设项目后我把它拆成几层看数据层怎么做、推荐怎么和LLM配合、路线规划怎么落地、数据分析怎么呈现以及真正会踩的坑在哪里。这篇内容既适合选了这个题目、还没定技术方案的人参考也适合已经写了部分代码、但发现系统“只是CRUD”的同学对照补全。我尽量用做过一遍的实际视角来讲不给你甩一堆论文腔每一块都尽量落到能跑、能演示、能答得出来的具体程度。1. 拆题与架构这个毕设题目真正要交付的是什么很多同学看到题目里有“LLM大模型”就直接往“聊天机器人”方向想结果做出来就是套壳问答。这个题目的核心其实是一套完整的旅游服务闭环用户来了、表达偏好、系统给推荐、系统给路线、用户看数据可视化、再反馈。大模型是中间增强体验的组件不是全部。1.1 题目里的四个关键词到底对应哪些交付物“Django”对应一个完整体验的B/S系统需要用户端、管理端、前端页面、后端API、数据库表“LLM大模型”对应至少两个具体能力理解用户的自然语言偏好、生成推荐理由或路线说明“数据分析”对应统计页面要能按热度、类别、时间等维度展示图表“个性化推荐”对应一套能根据用户历史和行为产生排序结果的算法模块“旅游路线规划”对应把多个景点排成合理行程的后端算法。这五块不是并列关系而是一条数据流水线数据底座支撑推荐和路线LLM又从数据里提取人的意图并做表达最终在页面统一呈现。论文结构和个人工作日记的分节也可以照着这条逻辑写。我之前看到有人只做了登录注册加景点列表题目写上“智能推荐”结果答辩论证算法时一句话都说不出。所以第一件事就是把每块交付物列清楚别把题做窄了。1.2 我推荐的系统技术栈与整体分层技术选型决定了你开发效率、演示稳定性和答辩可聊深度。我的建议如下表不一定是最新版本但组合起来最稳妥层次选型说明后端Django 4.x Django REST Framework用DRF写API比直接render模板更干净方便前端做交互前端Bootstrap 5 或 Vue3 Element UI熟悉HTML就选Bootstrap想加分可以上Vue3但时间成本高一截数据库MySQL 8.0开发期可用SQLite毕设演示用SQLite最方便提交文档写MySQL即可缓存Redis缓存推荐结果和大模型回复减少重复调用可视化ECharts图表丰富答辩时视觉效果最好大模型通用大模型API或本地开源模型有API Key走API没预算就本地部署一个开源对话模型推荐算法手写基于内容召回 协同过滤不建议上来就用复杂深度学习毕设手写经典算法更好讲整体架构我习惯按四层分展示层页面图表、接口层Django View/DRF、业务层推荐、路线、数据统计、数据层MySQLRedis。大模型服务单独封装成一个Client不直接散落在业务代码里这样它挂了也不会让整个系统崩掉。这种分层的好处是你答辩时问“某个模块怎么改”你能说清楚哪一层动哪里。比如想换推荐策略只换业务层里一个函数想换大模型厂商只换Client内部实现。这比把所有逻辑堆在一个view函数里好讲一百倍。2. 数据底座景点画像、用户行为与预处理建模比写接口更早不管是推荐、路线规划还是数据分析最终都是吃数据的。很多同学一上来先写页面写到一半发现没有数据可用又回头造数据这是最浪费时间的方式。我的建议是开工第一周先把数据表和一批演示数据定下来。2.1 核心数据模型景点表、用户表、行为表怎么设计这个系统至少需要以下几张表我整理成可以直接参考的字段清单景点表id、名称、城市、类别标签自然风光/历史人文/亲子娱乐、评分、门票价格、热度指数、经度、纬度、建议游玩时长、简介、封面图、开放时间。用户表id、昵称、注册时间、偏好标签JSON字段存“亲子”“轻松”“美食”这类关键词。行为表id、用户id、景点id、行为类型浏览/收藏/下单、行为时间、行为分值。路线表id、用户id、生成方式推荐算法/大模型调整、景点id列表、每日安排、总时长、备注。统计缓存表id、指标类型、统计值、统计日期用于加速数据面板。景点表里的“经度、纬度、建议游玩时长”是路线规划的硬依赖少了它们后面算法根本没法跑。行为表是推荐系统的数据来源建议一开始就写上“行为分值”比如浏览0.5分、收藏1分、下单2分后面算用户偏好向量会非常顺手。2.2 数据来源与预处理经纬度、标签归一化、行为分布数据来源这块我建议优先使用公开的演示数据集或者自己构造一批符合真实分布的模拟数据。自己造数据时要遵守上限热门景点浏览量大、冷门景点少评分符合长尾分布不要每个景点数据都一样否则推荐算法演示出来就是一潭死水。预处理环节有几件事一定要做一是经纬度统一到小数点后6位方便计算距离二是类别标签做归一化比如“自然”“自然风光”“山水”统一映射成“自然风光”否则推荐召回全串戏三是热度指数按Log变换压到0到100区间避免个别极值拉爆比较四是门票价格、评分字段做缺失值填充一般用均值或类别最频繁值。我实际做的时候发现最容易被忽略的是“时间字段”。行为表必须保留时间因为数据分析模块要画“旅游热度随月份变化”的折线图没有时间你会卡在这里重新造数据。2.3 用JSON偏好结构把自然语言需求“翻译”给系统用户在前端输入的可能是一整句话“我想带爸妈去某市玩3天节奏轻松点喜欢逛公园和古镇预算别太高。”这段文本不能直接用于SQL查询需要把它转成结构化偏好。我在项目里定义了一个统一的偏好JSON样例如下{ destination: 某目标城市, days: 3, travel_type: 家庭游, pace: 轻松, budget_level: 中等, preferred_tags: [公园, 古镇], avoid_tags: [爬山], must_visit: [某海滨公园], start_location: 用户酒店经纬度 }这个JSON是最关键的中间结构。它同时喂给三处后端查询条件、推荐算法的标签权重、路线规划的时间约束。所以你看“大模型”不是终点而是从一句话到结构化数据之间的转换器。3. 推荐模块协同过滤、内容召回与大模型精排的三种协作方式推荐是这个题目的灵魂也是最容易在答辩环节被追问的部分。你不需要做得多“深”但要能清晰说出来我的推荐系统分哪几步每一步解决什么问题。3.1 先看基础量用户协同过滤和基于内容的召回怎么写我建议做两个基础召回不要只做一个。基于内容的召回思路把用户的历史行为标签加权汇总成用户偏好向量再与景点标签向量做余弦相似度。一个可以跑的简化版本大概是import numpy as np def content_recall(user_pref_vec, spot_vectors, top_n30): # user_pref_vec: 用户对标签的加权偏好向量 # spot_vectors: 景点标签向量矩阵 scores np.dot(spot_vectors, user_pref_vec) # 归一化 scores scores / (np.linalg.norm(spot_vectors, axis1) 1e-8) top_indices scores.argsort()[-top_n:][::-1] return top_indices基于用户的协同过滤思路先算出活跃用户之间的相似度再找“和你喜欢相近景点”的人把这些人额外喜欢的景点推荐出来。用户相似度可以用Pearson相关系数也可以用余弦相似度关键是要说明你选某个相似度指标的理由。毕设里用余弦相似度最简单也最好解释。实际执行时两个召回各取Top30然后合并去重进入重排阶段。不建议直接对全量景点做排序召回后再排序是业界通用方案复杂度可控效果也足够演示。3.2 大模型在推荐里的三个真实用途意图解析、重排、推荐理由大模型在推荐系统里不是替代算法而是做三件算法做不好的事。第一是意图解析。前面说的偏好JSON就是由大模型从用户自然语言里抽取出来的。你需要写一个Prompt要求模型输出固定JSON结构然后后端用JSON解析入库。这个能力一旦跑通整个系统立刻显得“智能”不少。第二是基于规则的轻量重排。我当时的做法是把召回阶段得到的Top候选和偏好JSON一起发给大模型让它根据“是否避开必去景点、是否符合预算、是否符合标签偏好”做一次排序调整。注意这里是调整不是让模型凭空创造景点否则它可能给你编一个“某市梦幻城堡”这种不存在的景点。第三是生成推荐理由。比如“为您推荐A景点因为您过去经常浏览公园类景点而且它评分高、适合慢节奏游玩”。这段文字如果用模板生成会显得很机械用大模型生成答辩现场演示时观感很好。3.3 混合推荐的执行流程与接口设计我在业务层里写了一个统一的推荐入口函数流程是这样判断用户是否有足够行为数据如果行为少于3条走冷启动策略直接推平台热门Top。有行为的用户并行执行内容召回和协同过滤召回。两个Top30合并去重保留相关性分。调用大模型意图解析输出偏好JSON。偏好JSON参与重排规则过滤掉避开类别的景点再按加权分排序。取Top10返回前端同时异步调用大模型给前3个景点生成推荐理由。不要每次请求都实时跑一遍大模型。实测下来大模型单次响应基本在1到3秒用户体验很受影响。我当时做了一层Redis缓存把同一用户的推荐结果缓存30分钟大模型生成的推荐理由缓存到展示结束。这样演示时丝滑也体现你考虑过性能设计。接口设计建议给DRF写一个/api/recommend/参数只要一个用户id或session标识返回推荐景点列表、推荐理由、路线预览三块内容。一个接口搞定前端调起来也省事。4. 路线规划景点排序不只是算法题它是多个约束的取舍路线规划是另一个容易做花哨但不落地的地方。很多同学一说路线规划就想上TSP、遗传算法但对一个毕设系统来说真正重要的是先把“约束”想全再选择合适的算法。4.1 硬约束游玩时长、交通时间、开放时段、节奏偏好我先列几个必须考虑的硬约束每日可用时间。比如一天从9点到18点扣掉午餐实际游玩窗口只有8小时。景点建议游玩时长。每个景点在表里都有这个字段累加不能超过窗口。景点间交通时间。不能直接算直线距离要按城市路况给一个换算系数。开放时段。有些景点周中闭馆或者下午才开要考虑进去。用户节奏偏好。节奏松则每天最多排2个核心景点加1个备用紧凑可以加到4个。起点终点。通常需要从用户入住的酒店位置出发最后回到酒店。好多人在算法上折腾很久结果忽略了“用户第三天要返程”路线硬排到了返程时间外。这种属于需求理解不到位答辩时也很容易被问倒。所以开始写算法之前先把约束写成配置比如MAX_DAILY_HOURS8、TRAFFIC_COEFcity_coef。4.2 贪心构造与2-opt优化一段可运行的核心逻辑路线生成我推荐一个做法先用贪心最近邻构造初始路线再用2-opt做局部优化。不要一上来就写遗传算法贪心加局部优化已经能覆盖大部分演示需求而且每一段逻辑你都讲得清。贪心构造思路从用户起点出发计算候选景点距离。优先选择“当前时间窗口内能到达且能游玩完毕”的景点。选择综合分最高的景点加入路线更新当前时间。重复直到时间窗口用完或候选为空。这里综合分可以定义为score 0.6 * 景点评分 0.3 * 偏好匹配度 - 0.1 * (交通时间/最大交通时间)。这个公式不用多复杂关键是你要能解释每一项的意图。2-opt优化核心是依次尝试交换路线中两个景点的访问顺序如果总交通时间变短且不违反约束就保留交换循环直到没有改进。距离计算可以用Haversine公式from math import radians, asin, sqrt, sin, cos def haversine(lon1, lat1, lon2, lat2): R 6371.0 dlon radians(lon2 - lon1) dlat radians(lat2 - lat1) a sin(dlat / 2) ** 2 cos(radians(lat1)) * cos(radians(lat2)) * sin(dlon / 2) ** 2 return 2 * R * asin(sqrt(a))这个函数不光路线用地图展示和分析模块也能复用所以放一个独立的utils.py里。跑完之后把路线存到路线表生成行程单格式类似“第一天酒店-海滨公园3小时-老街2小时-酒店”并附上每天的交通时间合计和总距离。这已经是完整可展示的结果了。4.3 为什么最终展示路线要让大模型做“包装”而不是做“计算”一开始我也想靠大模型直接规划路线后来发现它最大的问题是“自信地编数据”。问它A景点到B景点要多久它能一本正经给你一个很好看的数字但实际可能完全相反。旅游路线这种涉及真实坐标、时间和距离的任务模型算力再强也拼不过确定性算法。所以我的分工很明确算法负责精确计算和约束检查大模型负责文案包装与用户沟通。算法生成的是“第1天 09:00-11:00 海滨公园”大模型负责把它变成“上午先到海滨公园吹吹风全程步行栈道适合带长辈慢慢走大约2小时然后去老街吃午饭”。前者保证可靠性后者提升体验。答辩的时候我把这个分工讲清楚其实非常加分说明你理解大模型的能力边界。5. 数据分析模块从数据库到ECharts的完整链路数据分析不能只放几张静态截图。系统内要做成“数据一变图表就变”的动态面板才能体现Django后端处理和前端可视化的联动。5.1 分析指标怎么选热度、画像、季节性、区域分布我建议从上到下列几个能撑起全程演示的指标目的地热度榜按收藏量、浏览量和点评数加权排序的Top10景点。景点类别占比自然风光、历史人文、亲子娱乐等类别的收藏占比用饼图。月度热度趋势近12个月的用户行为量变化折线图能看出节假日峰值。用户画像分布年龄段、出游类型亲子/情侣/好友的分布柱状图。区域热力地图把景点经纬度打在目标城市地图上用热力图展示热度聚集。回答“为什么做这些指标”时要有个统一主线它们分别服务推荐系统冷启动热门榜、路线偏好类别占比、运营趋势和用户理解。换句话说数据分析不是孤立模块它和推荐、路线是扣在一起的。5.2 后端聚合查询与接口设计我用了Django ORM的聚合查询不需要写原生SQLfrom django.db.models import Count, Sum, F from .models import Behavior, Spot def hot_spot_data(): return ( Behavior.objects .values(spot__name) .annotate(cntCount(id)) .order_by(-cnt)[:10] )响应结构统一成{categories: [...], values: [...]}前端ECharts直接填充。区域热力图再单独给一个接口返回景点经纬度和热度值的数组前端用地图散点加聚合实现。性能上如果数据量小每一页动态查询没问题但为了答辩演示流畅我当时对几个高频统计页做了缓存每天早上计算一次聚合结果写入缓存表页面刷新时先读缓存。这个设计在答辩里非常值得讲——它说明你考虑了真实业务场景下的数据时效和查询压力。5.3 演示时最容易加分的数据问答与智能报告数据分析也接上大模型会让演示效果上一个档次。我的实现是做几个预设的数据问题模板比如“本季度热度最高的3个景点是什么”“哪类景点最受欢迎为什么”后端先把统计结果查出来然后用大模型把数据组织成一段自然语言汇报。这里注意不要让大模型直接碰数据库。你把聚合好的数字放进Prompt让模型做事实描述。比如“自然风光类景点收藏占比38%排名第一历史人文类31%排名第二。适合推荐给偏好自然景色的新用户作为冷启动候选”这段文字既有数据支撑又有人味。我当时还在页面侧边加了一个“数据问答”输入框用户输入问题系统匹配预设模板、执行统计、交给大模型生成回答。虽然只支持有限的几个问题模板但演示时几乎每次都有人追问“这是不是真的随便问都行”你只要说清楚规则边界就显得很扎实。6. 从开发到答辩这个题目常见的坑与应对方法最后这部分是我最想写的因为代码写不出来的坑、答辩被问倒的瞬间往往比功能本身更折磨人。6.1 环境与依赖的兼容性问题Django 5和部分第三方库版本不一定完全兼容尤其DRF版本、Python版本之间容易出幺蛾子。我踩过的坑一开始装了Python 3.12加Django 5.0结果某个后端依赖包没跟上跑测试直接崩溃。后来老老实实退回Python 3.10加Django 4.2一切就稳定了。建议固定一套版本组合写进requirements.txt不要追求最新。另外开发期数据库用SQLite确实省事但如果你选题里明确要求MySQL最好早一点切换过去别拖到快答辩才换到时候编码、时区、大小写敏感问题一起冒出来心态会崩。6.2 大模型调用稳定性与成本控制大模型API调用有几个实际烦恼超时、限流、返回格式不稳定。我的处理办法是在llm_client.py里统一封装设置超时时间为8秒失败自动重试一次重试仍失败就降级返回预设的模板内容保证系统不白屏。返回格式的稳定性更坑。你让模型输出JSON它有时候在前头多一句“好的根据您的需求生成如下结果”导致json.loads直接报错。解决方式是Prompt里写死“只输出JSON不要任何解释”同时后端用正则把第一个{之前的内容去掉再做解析。双保险之后演示时基本不会翻车。成本方面演示时建议全程走API缓存命中真要让模型实时生成控制在几轮以内。本地部署开源模型是备选方案但显存和推理速度你要提前测别等答辩当天才首次启动。6.3 演示数据与演示流程的准备演示数据要“有故事感”。我造了一套目标城市的100个景点、500个模拟用户、2万条行为记录数值都按真实分布拍过。这样推荐、路线、数据面板都能出现“合理的结果”而不是十个景点全是5分。答辩场景切换也要排好顺序先走用户注册和偏好填写展示意图解析JSON再看推荐列表和推荐理由然后生成路线看行程单最后切数据面板讲趋势。每步控制在1分钟以内总共5分钟讲完主线。还有一个容易被忽略的点准备一套“用户无任何行为”的演示路径。专门展示冷启动推荐怎么给热门榜既说明你处理过冷启动又防止现场操作失误时没有退路。6.4 答辩常见提问与回答思路把自己当答辩老师列出最可能被追问的几个问题提前准备好回答为什么选择Django而不是Flask答Django自带ORM、Admin后台和完整生态适合快速交付一个多模块业务系统Flask轻量但需要自己拼装太多组件。大模型在系统里具体服务哪个环节答意图解析、推荐理由生成、路线文案包装和数据问答并强调不做数据计算。推荐结果怎么评估答用离线数据做召回率、TopN命中率对比在线部分用点击率、收藏率观测毕设里可以做一个简单的A/B对比表。冷启动怎么解决答行为不足时走热门榜兜底同时用用户注册时填写的偏好标签做基于内容的推荐。路线规划你的算法有没有证明最优答没有证明全局最优但通过约束检查和2-opt局部优化能在可行时间内得到接近最优的可行解这对实际用户场景已经足够。这些问题不需要背大段文字关键是能脱稿讲清逻辑。我自己当时害怕被追问算法数学细节后来发现只要能把“输入、输出、约束、为什么这么选”讲顺老师基本不会再深挖。做这个题目最大的体会是技术栈本身不复杂难的是把各模块串成一个闭环并且给每一步选择留好理由。如果让我重新做一次我会把更多时间花在数据质量和演示流程上而不是多写几个看起来花哨但用不上的功能。你真正需要的是一个“每一步都能自证为什么”的完整系统——这正是答辩时最值钱的东西。
每年到了毕设季都会有一批同学被“Django大模型推荐系统”这类题目吸引又不知道怎么下手。前几天有位学弟问我题目是“基于Django和LLM大模型的智能旅游路线规划与个性化推荐系统”听起来很高大上但实际要做哪些模块论文怎么组织答辩怎么讲这其实就是今天我想聊的话题——做完一个同类毕设项目后我把它拆成几层看数据层怎么做、推荐怎么和LLM配合、路线规划怎么落地、数据分析怎么呈现以及真正会踩的坑在哪里。这篇内容既适合选了这个题目、还没定技术方案的人参考也适合已经写了部分代码、但发现系统“只是CRUD”的同学对照补全。我尽量用做过一遍的实际视角来讲不给你甩一堆论文腔每一块都尽量落到能跑、能演示、能答得出来的具体程度。1. 拆题与架构这个毕设题目真正要交付的是什么很多同学看到题目里有“LLM大模型”就直接往“聊天机器人”方向想结果做出来就是套壳问答。这个题目的核心其实是一套完整的旅游服务闭环用户来了、表达偏好、系统给推荐、系统给路线、用户看数据可视化、再反馈。大模型是中间增强体验的组件不是全部。1.1 题目里的四个关键词到底对应哪些交付物“Django”对应一个完整体验的B/S系统需要用户端、管理端、前端页面、后端API、数据库表“LLM大模型”对应至少两个具体能力理解用户的自然语言偏好、生成推荐理由或路线说明“数据分析”对应统计页面要能按热度、类别、时间等维度展示图表“个性化推荐”对应一套能根据用户历史和行为产生排序结果的算法模块“旅游路线规划”对应把多个景点排成合理行程的后端算法。这五块不是并列关系而是一条数据流水线数据底座支撑推荐和路线LLM又从数据里提取人的意图并做表达最终在页面统一呈现。论文结构和个人工作日记的分节也可以照着这条逻辑写。我之前看到有人只做了登录注册加景点列表题目写上“智能推荐”结果答辩论证算法时一句话都说不出。所以第一件事就是把每块交付物列清楚别把题做窄了。1.2 我推荐的系统技术栈与整体分层技术选型决定了你开发效率、演示稳定性和答辩可聊深度。我的建议如下表不一定是最新版本但组合起来最稳妥层次选型说明后端Django 4.x Django REST Framework用DRF写API比直接render模板更干净方便前端做交互前端Bootstrap 5 或 Vue3 Element UI熟悉HTML就选Bootstrap想加分可以上Vue3但时间成本高一截数据库MySQL 8.0开发期可用SQLite毕设演示用SQLite最方便提交文档写MySQL即可缓存Redis缓存推荐结果和大模型回复减少重复调用可视化ECharts图表丰富答辩时视觉效果最好大模型通用大模型API或本地开源模型有API Key走API没预算就本地部署一个开源对话模型推荐算法手写基于内容召回 协同过滤不建议上来就用复杂深度学习毕设手写经典算法更好讲整体架构我习惯按四层分展示层页面图表、接口层Django View/DRF、业务层推荐、路线、数据统计、数据层MySQLRedis。大模型服务单独封装成一个Client不直接散落在业务代码里这样它挂了也不会让整个系统崩掉。这种分层的好处是你答辩时问“某个模块怎么改”你能说清楚哪一层动哪里。比如想换推荐策略只换业务层里一个函数想换大模型厂商只换Client内部实现。这比把所有逻辑堆在一个view函数里好讲一百倍。2. 数据底座景点画像、用户行为与预处理建模比写接口更早不管是推荐、路线规划还是数据分析最终都是吃数据的。很多同学一上来先写页面写到一半发现没有数据可用又回头造数据这是最浪费时间的方式。我的建议是开工第一周先把数据表和一批演示数据定下来。2.1 核心数据模型景点表、用户表、行为表怎么设计这个系统至少需要以下几张表我整理成可以直接参考的字段清单景点表id、名称、城市、类别标签自然风光/历史人文/亲子娱乐、评分、门票价格、热度指数、经度、纬度、建议游玩时长、简介、封面图、开放时间。用户表id、昵称、注册时间、偏好标签JSON字段存“亲子”“轻松”“美食”这类关键词。行为表id、用户id、景点id、行为类型浏览/收藏/下单、行为时间、行为分值。路线表id、用户id、生成方式推荐算法/大模型调整、景点id列表、每日安排、总时长、备注。统计缓存表id、指标类型、统计值、统计日期用于加速数据面板。景点表里的“经度、纬度、建议游玩时长”是路线规划的硬依赖少了它们后面算法根本没法跑。行为表是推荐系统的数据来源建议一开始就写上“行为分值”比如浏览0.5分、收藏1分、下单2分后面算用户偏好向量会非常顺手。2.2 数据来源与预处理经纬度、标签归一化、行为分布数据来源这块我建议优先使用公开的演示数据集或者自己构造一批符合真实分布的模拟数据。自己造数据时要遵守上限热门景点浏览量大、冷门景点少评分符合长尾分布不要每个景点数据都一样否则推荐算法演示出来就是一潭死水。预处理环节有几件事一定要做一是经纬度统一到小数点后6位方便计算距离二是类别标签做归一化比如“自然”“自然风光”“山水”统一映射成“自然风光”否则推荐召回全串戏三是热度指数按Log变换压到0到100区间避免个别极值拉爆比较四是门票价格、评分字段做缺失值填充一般用均值或类别最频繁值。我实际做的时候发现最容易被忽略的是“时间字段”。行为表必须保留时间因为数据分析模块要画“旅游热度随月份变化”的折线图没有时间你会卡在这里重新造数据。2.3 用JSON偏好结构把自然语言需求“翻译”给系统用户在前端输入的可能是一整句话“我想带爸妈去某市玩3天节奏轻松点喜欢逛公园和古镇预算别太高。”这段文本不能直接用于SQL查询需要把它转成结构化偏好。我在项目里定义了一个统一的偏好JSON样例如下{ destination: 某目标城市, days: 3, travel_type: 家庭游, pace: 轻松, budget_level: 中等, preferred_tags: [公园, 古镇], avoid_tags: [爬山], must_visit: [某海滨公园], start_location: 用户酒店经纬度 }这个JSON是最关键的中间结构。它同时喂给三处后端查询条件、推荐算法的标签权重、路线规划的时间约束。所以你看“大模型”不是终点而是从一句话到结构化数据之间的转换器。3. 推荐模块协同过滤、内容召回与大模型精排的三种协作方式推荐是这个题目的灵魂也是最容易在答辩环节被追问的部分。你不需要做得多“深”但要能清晰说出来我的推荐系统分哪几步每一步解决什么问题。3.1 先看基础量用户协同过滤和基于内容的召回怎么写我建议做两个基础召回不要只做一个。基于内容的召回思路把用户的历史行为标签加权汇总成用户偏好向量再与景点标签向量做余弦相似度。一个可以跑的简化版本大概是import numpy as np def content_recall(user_pref_vec, spot_vectors, top_n30): # user_pref_vec: 用户对标签的加权偏好向量 # spot_vectors: 景点标签向量矩阵 scores np.dot(spot_vectors, user_pref_vec) # 归一化 scores scores / (np.linalg.norm(spot_vectors, axis1) 1e-8) top_indices scores.argsort()[-top_n:][::-1] return top_indices基于用户的协同过滤思路先算出活跃用户之间的相似度再找“和你喜欢相近景点”的人把这些人额外喜欢的景点推荐出来。用户相似度可以用Pearson相关系数也可以用余弦相似度关键是要说明你选某个相似度指标的理由。毕设里用余弦相似度最简单也最好解释。实际执行时两个召回各取Top30然后合并去重进入重排阶段。不建议直接对全量景点做排序召回后再排序是业界通用方案复杂度可控效果也足够演示。3.2 大模型在推荐里的三个真实用途意图解析、重排、推荐理由大模型在推荐系统里不是替代算法而是做三件算法做不好的事。第一是意图解析。前面说的偏好JSON就是由大模型从用户自然语言里抽取出来的。你需要写一个Prompt要求模型输出固定JSON结构然后后端用JSON解析入库。这个能力一旦跑通整个系统立刻显得“智能”不少。第二是基于规则的轻量重排。我当时的做法是把召回阶段得到的Top候选和偏好JSON一起发给大模型让它根据“是否避开必去景点、是否符合预算、是否符合标签偏好”做一次排序调整。注意这里是调整不是让模型凭空创造景点否则它可能给你编一个“某市梦幻城堡”这种不存在的景点。第三是生成推荐理由。比如“为您推荐A景点因为您过去经常浏览公园类景点而且它评分高、适合慢节奏游玩”。这段文字如果用模板生成会显得很机械用大模型生成答辩现场演示时观感很好。3.3 混合推荐的执行流程与接口设计我在业务层里写了一个统一的推荐入口函数流程是这样判断用户是否有足够行为数据如果行为少于3条走冷启动策略直接推平台热门Top。有行为的用户并行执行内容召回和协同过滤召回。两个Top30合并去重保留相关性分。调用大模型意图解析输出偏好JSON。偏好JSON参与重排规则过滤掉避开类别的景点再按加权分排序。取Top10返回前端同时异步调用大模型给前3个景点生成推荐理由。不要每次请求都实时跑一遍大模型。实测下来大模型单次响应基本在1到3秒用户体验很受影响。我当时做了一层Redis缓存把同一用户的推荐结果缓存30分钟大模型生成的推荐理由缓存到展示结束。这样演示时丝滑也体现你考虑过性能设计。接口设计建议给DRF写一个/api/recommend/参数只要一个用户id或session标识返回推荐景点列表、推荐理由、路线预览三块内容。一个接口搞定前端调起来也省事。4. 路线规划景点排序不只是算法题它是多个约束的取舍路线规划是另一个容易做花哨但不落地的地方。很多同学一说路线规划就想上TSP、遗传算法但对一个毕设系统来说真正重要的是先把“约束”想全再选择合适的算法。4.1 硬约束游玩时长、交通时间、开放时段、节奏偏好我先列几个必须考虑的硬约束每日可用时间。比如一天从9点到18点扣掉午餐实际游玩窗口只有8小时。景点建议游玩时长。每个景点在表里都有这个字段累加不能超过窗口。景点间交通时间。不能直接算直线距离要按城市路况给一个换算系数。开放时段。有些景点周中闭馆或者下午才开要考虑进去。用户节奏偏好。节奏松则每天最多排2个核心景点加1个备用紧凑可以加到4个。起点终点。通常需要从用户入住的酒店位置出发最后回到酒店。好多人在算法上折腾很久结果忽略了“用户第三天要返程”路线硬排到了返程时间外。这种属于需求理解不到位答辩时也很容易被问倒。所以开始写算法之前先把约束写成配置比如MAX_DAILY_HOURS8、TRAFFIC_COEFcity_coef。4.2 贪心构造与2-opt优化一段可运行的核心逻辑路线生成我推荐一个做法先用贪心最近邻构造初始路线再用2-opt做局部优化。不要一上来就写遗传算法贪心加局部优化已经能覆盖大部分演示需求而且每一段逻辑你都讲得清。贪心构造思路从用户起点出发计算候选景点距离。优先选择“当前时间窗口内能到达且能游玩完毕”的景点。选择综合分最高的景点加入路线更新当前时间。重复直到时间窗口用完或候选为空。这里综合分可以定义为score 0.6 * 景点评分 0.3 * 偏好匹配度 - 0.1 * (交通时间/最大交通时间)。这个公式不用多复杂关键是你要能解释每一项的意图。2-opt优化核心是依次尝试交换路线中两个景点的访问顺序如果总交通时间变短且不违反约束就保留交换循环直到没有改进。距离计算可以用Haversine公式from math import radians, asin, sqrt, sin, cos def haversine(lon1, lat1, lon2, lat2): R 6371.0 dlon radians(lon2 - lon1) dlat radians(lat2 - lat1) a sin(dlat / 2) ** 2 cos(radians(lat1)) * cos(radians(lat2)) * sin(dlon / 2) ** 2 return 2 * R * asin(sqrt(a))这个函数不光路线用地图展示和分析模块也能复用所以放一个独立的utils.py里。跑完之后把路线存到路线表生成行程单格式类似“第一天酒店-海滨公园3小时-老街2小时-酒店”并附上每天的交通时间合计和总距离。这已经是完整可展示的结果了。4.3 为什么最终展示路线要让大模型做“包装”而不是做“计算”一开始我也想靠大模型直接规划路线后来发现它最大的问题是“自信地编数据”。问它A景点到B景点要多久它能一本正经给你一个很好看的数字但实际可能完全相反。旅游路线这种涉及真实坐标、时间和距离的任务模型算力再强也拼不过确定性算法。所以我的分工很明确算法负责精确计算和约束检查大模型负责文案包装与用户沟通。算法生成的是“第1天 09:00-11:00 海滨公园”大模型负责把它变成“上午先到海滨公园吹吹风全程步行栈道适合带长辈慢慢走大约2小时然后去老街吃午饭”。前者保证可靠性后者提升体验。答辩的时候我把这个分工讲清楚其实非常加分说明你理解大模型的能力边界。5. 数据分析模块从数据库到ECharts的完整链路数据分析不能只放几张静态截图。系统内要做成“数据一变图表就变”的动态面板才能体现Django后端处理和前端可视化的联动。5.1 分析指标怎么选热度、画像、季节性、区域分布我建议从上到下列几个能撑起全程演示的指标目的地热度榜按收藏量、浏览量和点评数加权排序的Top10景点。景点类别占比自然风光、历史人文、亲子娱乐等类别的收藏占比用饼图。月度热度趋势近12个月的用户行为量变化折线图能看出节假日峰值。用户画像分布年龄段、出游类型亲子/情侣/好友的分布柱状图。区域热力地图把景点经纬度打在目标城市地图上用热力图展示热度聚集。回答“为什么做这些指标”时要有个统一主线它们分别服务推荐系统冷启动热门榜、路线偏好类别占比、运营趋势和用户理解。换句话说数据分析不是孤立模块它和推荐、路线是扣在一起的。5.2 后端聚合查询与接口设计我用了Django ORM的聚合查询不需要写原生SQLfrom django.db.models import Count, Sum, F from .models import Behavior, Spot def hot_spot_data(): return ( Behavior.objects .values(spot__name) .annotate(cntCount(id)) .order_by(-cnt)[:10] )响应结构统一成{categories: [...], values: [...]}前端ECharts直接填充。区域热力图再单独给一个接口返回景点经纬度和热度值的数组前端用地图散点加聚合实现。性能上如果数据量小每一页动态查询没问题但为了答辩演示流畅我当时对几个高频统计页做了缓存每天早上计算一次聚合结果写入缓存表页面刷新时先读缓存。这个设计在答辩里非常值得讲——它说明你考虑了真实业务场景下的数据时效和查询压力。5.3 演示时最容易加分的数据问答与智能报告数据分析也接上大模型会让演示效果上一个档次。我的实现是做几个预设的数据问题模板比如“本季度热度最高的3个景点是什么”“哪类景点最受欢迎为什么”后端先把统计结果查出来然后用大模型把数据组织成一段自然语言汇报。这里注意不要让大模型直接碰数据库。你把聚合好的数字放进Prompt让模型做事实描述。比如“自然风光类景点收藏占比38%排名第一历史人文类31%排名第二。适合推荐给偏好自然景色的新用户作为冷启动候选”这段文字既有数据支撑又有人味。我当时还在页面侧边加了一个“数据问答”输入框用户输入问题系统匹配预设模板、执行统计、交给大模型生成回答。虽然只支持有限的几个问题模板但演示时几乎每次都有人追问“这是不是真的随便问都行”你只要说清楚规则边界就显得很扎实。6. 从开发到答辩这个题目常见的坑与应对方法最后这部分是我最想写的因为代码写不出来的坑、答辩被问倒的瞬间往往比功能本身更折磨人。6.1 环境与依赖的兼容性问题Django 5和部分第三方库版本不一定完全兼容尤其DRF版本、Python版本之间容易出幺蛾子。我踩过的坑一开始装了Python 3.12加Django 5.0结果某个后端依赖包没跟上跑测试直接崩溃。后来老老实实退回Python 3.10加Django 4.2一切就稳定了。建议固定一套版本组合写进requirements.txt不要追求最新。另外开发期数据库用SQLite确实省事但如果你选题里明确要求MySQL最好早一点切换过去别拖到快答辩才换到时候编码、时区、大小写敏感问题一起冒出来心态会崩。6.2 大模型调用稳定性与成本控制大模型API调用有几个实际烦恼超时、限流、返回格式不稳定。我的处理办法是在llm_client.py里统一封装设置超时时间为8秒失败自动重试一次重试仍失败就降级返回预设的模板内容保证系统不白屏。返回格式的稳定性更坑。你让模型输出JSON它有时候在前头多一句“好的根据您的需求生成如下结果”导致json.loads直接报错。解决方式是Prompt里写死“只输出JSON不要任何解释”同时后端用正则把第一个{之前的内容去掉再做解析。双保险之后演示时基本不会翻车。成本方面演示时建议全程走API缓存命中真要让模型实时生成控制在几轮以内。本地部署开源模型是备选方案但显存和推理速度你要提前测别等答辩当天才首次启动。6.3 演示数据与演示流程的准备演示数据要“有故事感”。我造了一套目标城市的100个景点、500个模拟用户、2万条行为记录数值都按真实分布拍过。这样推荐、路线、数据面板都能出现“合理的结果”而不是十个景点全是5分。答辩场景切换也要排好顺序先走用户注册和偏好填写展示意图解析JSON再看推荐列表和推荐理由然后生成路线看行程单最后切数据面板讲趋势。每步控制在1分钟以内总共5分钟讲完主线。还有一个容易被忽略的点准备一套“用户无任何行为”的演示路径。专门展示冷启动推荐怎么给热门榜既说明你处理过冷启动又防止现场操作失误时没有退路。6.4 答辩常见提问与回答思路把自己当答辩老师列出最可能被追问的几个问题提前准备好回答为什么选择Django而不是Flask答Django自带ORM、Admin后台和完整生态适合快速交付一个多模块业务系统Flask轻量但需要自己拼装太多组件。大模型在系统里具体服务哪个环节答意图解析、推荐理由生成、路线文案包装和数据问答并强调不做数据计算。推荐结果怎么评估答用离线数据做召回率、TopN命中率对比在线部分用点击率、收藏率观测毕设里可以做一个简单的A/B对比表。冷启动怎么解决答行为不足时走热门榜兜底同时用用户注册时填写的偏好标签做基于内容的推荐。路线规划你的算法有没有证明最优答没有证明全局最优但通过约束检查和2-opt局部优化能在可行时间内得到接近最优的可行解这对实际用户场景已经足够。这些问题不需要背大段文字关键是能脱稿讲清逻辑。我自己当时害怕被追问算法数学细节后来发现只要能把“输入、输出、约束、为什么这么选”讲顺老师基本不会再深挖。做这个题目最大的体会是技术栈本身不复杂难的是把各模块串成一个闭环并且给每一步选择留好理由。如果让我重新做一次我会把更多时间花在数据质量和演示流程上而不是多写几个看起来花哨但用不上的功能。你真正需要的是一个“每一步都能自证为什么”的完整系统——这正是答辩时最值钱的东西。
