Python旅游推荐系统实战：从ItemCF协同过滤到Flask部署

简介基于Python的旅游推荐系统毕业设计论文文档docx格式面向计算机相关专业学生、毕业设计作者以及需要构建旅游推荐系统的小型项目开发者。文档完整覆盖论文规范章节从研究背景与现状、开发技术选型Django、MySQL、系统架构与E-R数据库设计到用户管理、信息展示、推荐算法、反馈模块及系统测试均有阐述能够帮助读者快速把握旅游推荐系统的整体设计流程与实现要点。包内仅含1个docx文件压缩包约1.6MB内容紧凑便于阅读与二次修改。目前已有332人在线学习适合作为毕业论文写作参考、开题报告辅助资料或系统开发前的方案依据可为同类课题节省从零梳理框架的时间。1. 一个论文标题背后的完整工程Python 旅游推荐系统不只是写个推荐算法「基于python的旅游推荐系统的设计与实现」这种文件名在毕业设计存档里很常见但它对应的工程通常不是「装个 Flask、跑个页面」那么简单。旅游推荐与电商推荐的差异在于出行决策低频用户一年撑死积累几十次收藏或下单行为一个景点同时受城市、季节、预算、假期约束几乎不存在「买了又买」的强信号。所以这套系统的难点不在算法本身而在数据表怎么设计、相似度矩阵如何解释、冷启动拿什么兜底、推荐结果用什么离线指标证明有效。下面按我实际做这类系统的路径来讲从数据建模、协同过滤选型到 Flask 接口和评测脚本全部是可复现的 Python 方案。2. 旅游推荐系统的设计落点数据模型、画像字段与召回通道写「设计与实现」类文档最忌讳一上来就写user_cf(user_id, spot_id)函数。评审或答辩时被问得最多的三个问题数据从哪来、字段为什么这么建、推荐分数由几部分组成。先把这三件事定死后面代码就是填空。2.1 数据来源爬虫、开源数据集还是手工构造最小可用集常见做法是爬虫抓取公开旅游平台的景点信息和用户点评配合开源数据集做结构参照。这里有两个现实约束一是爬虫要控制频率、遵守目标站点的 robots 协议测试阶段别对线上接口做高并发请求二是公开数据集多为电影或商品评分缺少城市、季节、门票这类旅游专属字段直接套用会让后续规则权重没有数据支撑。我一般会先手工构造一个「最小可用集」30 个城市、100 个景点、800 条行为记录。这个数据量用 SQLite 完全跑得动足以验证协同过滤、热度召回、预算筛选三条链路是通的。论文里写「数据规模」时也说得清小规模数据用来说明方案可行性真实场景下数据接入方式不变只是存储换 MySQL、行为表按天分区。关键点是行为表必须设behavior_type字段不要只留评分。旅游场景里评分极其稀疏大量有效信号藏在浏览、收藏、下单这三类隐式反馈里它们的权重完全不同。2.2 三张核心表的字段设计与建表语句系统里最稳定的部分是表结构它在论文里对应「数据库设计」章节。三张表如下表名核心字段说明useruser_id, age, city, budget, travel_styletravel_style 存「亲子/休闲/穷游」这类画像标签spotspot_id, name, category, city, ticket, season, labelslabels 存「海滨」「古镇」「雪山」等逗号分隔标签behaviorbehavior_id, user_id, spot_id, behavior_type, create_timebehavior_type 枚举 0/1/2对应浏览/收藏/下单建表时就把索引建好避免后续推荐查询全表扫描CREATE TABLE spot ( spot_id INTEGER PRIMARY KEY, name TEXT NOT NULL, category TEXT, city TEXT, ticket REAL DEFAULT 0, season TEXT, labels TEXT ); CREATE TABLE behavior ( behavior_id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, spot_id INTEGER NOT NULL, behavior_type INTEGER DEFAULT 0, create_time TEXT DEFAULT (datetime(now, localtime)) ); CREATE INDEX idx_behavior_user ON behavior(user_id); CREATE INDEX idx_behavior_spot ON behavior(spot_id); CREATE INDEX idx_behavior_time ON behavior(create_time);create_time用 SQLite 的本地时间作为默认值插入时不关心时间赋值召回查询要按时间窗口过滤所以create_time必须建索引。tags字段故意用逗号分隔文本而不是单独建关联表是因为旅游景区标签量级小关联表收益不高查询时用LIKE足够还能简化论文里的 ER 图。2.3 推荐流程分层召回、排序、解释工程上不做一个「大而全」的算法算总分而是拆成三段流水线召回层从地域热度、类别热度、协同过滤三条通道各取 TopN 候选合并去重。排序层对候选做加权融合加入预算、季节、城市距离约束需要时用 0-1 背包把候选压进用户预算。解释层给每条推荐附加「命中标签」前端直接展示「因为你在杭州推荐附近古镇」这是论文里最容易出彩的功能点。这个分层模型同时满足两个诉求算法部分方便做 A/B 对照实验论文架构图里每个模块都有明确输入输出。下面先用 SQL 把最简单的热度召回通道落地。2.4 用 SQL 直接实现地域热度召回通道热度召回是协同过滤之外的兜底通道也天然是冷启动用户的初始推荐。按「近 30 天行为数」排序取目标城市前 20 个景点SELECT s.spot_id, s.name, s.city, s.category, COUNT(b.behavior_id) AS hot_score FROM spot s LEFT JOIN behavior b ON b.spot_id s.spot_id AND b.create_time datetime(now, -30 days) WHERE s.city ? GROUP BY s.spot_id, s.name, s.city, s.category ORDER BY hot_score DESC LIMIT 20;用LEFT JOIN是关键细节没有产生任何行为的景点会以hot_score 0出现在结果尾部这比INNER JOIN直接丢弃新景点更安全。时间窗口 30 天是推荐系统里常用的经验值景区数据日更窗口太长热门景点会统治结果太短则噪声大。条件里的参数用?占位符避免字符串拼接注入问题SQLite 和 MySQL 都支持这种写法。召回解决的是「候选集从哪来」下一步要解决「候选之间如何排序」。3. 基于用户行为的协同过滤实现ItemCF 的相似度矩阵与行程规划旅游推荐系统论文里算法章节的核心通常是协同过滤。选型要先讲清楚理由旅游景点数量远小于用户数量物品更新频率低所以静态度量「景点与景点的相似度」比「用户与用户的相似度」更稳定也更好解释。3.1 为什么主推 ItemCF 而不是 UserCFUserCF 给用户推荐「和他行为相似的人喜欢的东西」在新闻、短视频这类内容快速流转的场景有效。旅游景点一年到头变化不大且一个城市的景点数量有限UserCF 的用户相似度矩阵会随着新行为反复抖动。反过来ItemCF 的相似度矩阵可以离线算好、增量更新线上只做查表和聚合响应速度快得多。论文实验里可以把两个算法都实现最后只报 ItemCF 的结果理由就写旅游决策重在「相似物品扩展」UserCF 在同一城市内行为稀疏时精度下降明显。这一句话既显专业又避开 UserCF 的冷启动硬伤。3.2 用 Python 构建 ItemCF 相似度矩阵基于行为表构造「用户-景点」倒排表再计算景点间 cosine 相似度from collections import defaultdict import math def build_item_sim(behavior): behavior: list of (user_id, spot_id, behavior_type) # 1. 用户到景点的倒排表 user_items defaultdict(set) for user_id, spot_id, _ in behavior: user_items[user_id].add(spot_id) # 2. 景点热度与共现矩阵 item_pop defaultdict(int) co_count defaultdict(int) for user_id, items in user_items.items(): for spot_a in items: item_pop[spot_a] 1 for spot_b in items: if spot_a spot_b: continue co_count[(spot_a, spot_b)] 1 # 3. cosine 相似度 热门惩罚 sim {} for (spot_a, spot_b), co in co_count.items(): denominator math.sqrt(item_pop[spot_a] * item_pop[spot_b]) if denominator 0: continue score co / denominator # 对热门景点做衰减log 平滑避免除零 score * 1.0 / math.log(1 item_pop[spot_b]) sim[(spot_a, spot_b)] score return sim相似度计算里最容易被忽略的是热门惩罚项。只看 cosine故宫这种热门景点会和几乎所有景点产生高共现1.0 / math.log(1 item_pop[spot_b])会把被比较侧的高热度分数拉低。behavior列表只取前两个字段是因为浏览、收藏、下单行为已经在构造阶段统一映射为「一次交互」权重差异放到排序阶段处理。3.3 召回排序行为权重加权与 TopK 候选生成拿到相似度矩阵后为用户生成推荐候选def recommend_for_user(user_id, user_behavior, sim, top_k20): interacted {spot_id for uid, spot_id, _ in user_behavior if uid user_id} # 行为权重浏览0.2收藏0.5下单1.0 weight_map {0: 0.2, 1: 0.5, 2: 1.0} user_action_weight defaultdict(float) for uid, spot_id, btype in user_behavior: if uid user_id: user_action_weight[spot_id] weight_map.get(btype, 0.2) score defaultdict(float) for spot_a, base_weight in user_action_weight.items(): for (x, y), sim_val in sim.items(): if x spot_a: target y elif y spot_a: target x else: continue if target in interacted: continue score[target] base_weight * sim_val # 按分数排序取 zui 高的 top_k return sorted(score.items(), keylambda kv: kv[1], reverseTrue)[:top_k]interacted集合用于排除用户已经去过的景点这是旅游推荐与电商推荐在业务规则上的差异电商允许重复购买景点不会重复消费同一地点。行为权重直接把收藏的下单倾向映射成数值三个值之间的倍数关系不需要精确论文里可以给出一组对比实验说明权重对指标的影响。3.4 把 TopN 候选压进预算0-1 背包做行程规划排序分数只解决「哪些景点值得去」还要解决「用户预算内选哪几个」。这是个标准 0-1 背包问题每个景点有门票成本ticket和推荐价值score在总预算内取价值最高的组合。def knapsack_select(spots, budget): n len(spots) # dp 记录每个预算下的最大价值 dp [0] * (budget 1) # choice 记录当前预算下是否选了第 i 个景点 choice [[False] * (budget 1) for _ in range(n 1)] for i in range(1, n 1): cost int(spots[i - 1][ticket]) value spots[i - 1][score] for b in range(budget, cost - 1, -1): if dp[b - cost] value dp[b]: dp[b] dp[b - cost] value choice[i][b] True # 回溯找出被选中的景点 selected [] b budget for i in range(n, 0, -1): if choice[i][b]: selected.append(spots[i - 1]) b - int(spots[i - 1][ticket]) return selected背包容量budget单位是「元」遍历时用range(budget, cost - 1, -1)逆序更新保证每个景点最多被选一次二维choice表记录决策路径用于最后的回溯。这套代码在论文里对应「行程规划模块」比单纯展示 TopN 列表更接近真实需求。数据量不大时不必优化空间复杂度可读性优先。4. 基于 Python 的工程实现Flask 接口、冷启动策略与跨浏览器展示算法链路跑通后要做成可访问的系统。工程环境建议 Python 3.9 以上版本用 pycharm 或 vscode 配置虚拟环境后安装flask、requests两个第三方库即可数据库继续用 SQLite 文件避免论文答辩现场还要启动 MySQL 服务。4.1 用 Flask 封装推荐接口接口设计遵循「一个用户一个请求拿全量结果」的原则把召回、排序、背包三个步骤串成一条服务端链路from flask import Flask, request, jsonify import sqlite3 app Flask(__name__) def query_db(sql, args()): conn sqlite3.connect(travel.db) conn.row_factory sqlite3.Row cur conn.cursor() cur.execute(sql, args) rows [dict(row) for row in cur.fetchall()] conn.close() return rows app.route(/api/recommend, methods[GET]) def recommend(): user_id request.args.get(user_id, typeint) city request.args.get(city, default) if not user_id: return jsonify({code: 400, msg: user_id is required}), 400 # 1. 取用户行为 rows query_db( SELECT user_id, spot_id, behavior_type FROM behavior WHERE user_id?, (user_id,) ) # 2. 无行为走城市热度冷启动 if not rows: spots query_db( SELECT spot_id, name, city, ticket FROM spot WHERE city LIKE ? ORDER BY hot_score DESC LIMIT 20, (f%{city}%,) ) return jsonify({code: 0, data: spots}) # 3. 有行为协同过滤 背包筛选 spots recommend_for_user(user_id, rows, sim, top_k20) spots_with_info [fill_spot_info(sid, score) for sid, score in spots] selected knapsack_select(spots_with_info, budget800) return jsonify({ code: 0, data: selected, strategy: itemcf if rows else hot_rank }) if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)fill_spot_info负责把spot_id补全成景点名、城市、门票等信息可以从spot表逐条查询也可以一次性WHERE spot_id IN (...)批量取回。接口里budget800是写死的默认预算真实场景应作为参数传入论文里可以描述成「默认按人均 800 元一日游标准规划」。debugTrue只在开发期打开答辩演示时也建议开着方便当场看报错。4.2 冷启动的三个兜底策略新用户没有任何行为记录协同过滤直接失效。按三个层次兜底地域热度用户在前端选了城市就返回该城市hot_score最高的 20 个景点。类别偏好前端可让用户选择「亲子/古镇/登山」等兴趣标签对应spot.labels LIKE %古镇%这类查询。兜底列表没有城市和标签返回全局热门 Top20。这三个策略的优先级要写清楚用户主动选择的标签 城市维度热度 全局热度。工程实现就是几段if ... elif但论文里值得用一小节单独描述每个策略的数据来源和适用条件。4.3 推荐结果展示跨浏览器兼容的前端页面推荐系统论文的「系统实现」章节通常含界面截图前端页面不必复杂但要求评审机器上的浏览器能正常渲染。用原生 HTML fetch最稳妥避免引入 Node 构建链!DOCTYPE html html langzh-CN head meta charsetUTF-8 title旅游推荐系统/title /head body div idrec-list/div script const userId 1; const city 杭州; // 老版本浏览器降级XMLHttpRequest 兜底 fetch const request window.fetch ? fetch(/api/recommend?user_id${userId}city${city}).then(r r.json()) : new Promise((resolve) { const xhr new XMLHttpRequest(); xhr.open(GET, /api/recommend?user_id${userId}city${city}); xhr.onload () resolve(JSON.parse(xhr.responseText)); xhr.send(); }); request.then(json { const html json.data.map(item div${item.name} - ${item.city} - 门票¥${item.ticket}/div ).join(); document.getElementById(rec-list).innerHTML html; }); /script /body /html兼容性处理的重点是window.fetch判断老内核浏览器没有fetch时自动切到XMLHttpRequest。前端不引入框架不依赖构建工具评审现场即使网络不通页面也能靠本地 Flask 服务跑起来。展示层面只输出推荐结果就不会出错后续要加用户反馈按钮只需在map里追加一个收藏按钮并绑定事件。4.4 把论文「系统测试」变成可执行的接口用例论文必备「系统测试」一章与其截图凑数不如写一段requests冒烟测试脚本输出结果粘贴到论文里更可信import requests cases [ (无用户ID, {city: 杭州}, 400), (冷启动用户, {user_id: 999, city: 杭州}, 200), (正常推荐, {user_id: 1, city: 杭州}, 200), (不存在的景点, {user_id: 1, city: 不存在城市}, 200), ] for name, params, expected in cases: resp requests.get(http://127.0.0.1:5000/api/recommend, paramsparams) assert resp.status_code expected, f{name} 状态码异常 if expected 200: data resp.json() assert data in data, f{name} 缺少data字段 print(f{name}: PASS (status{resp.status_code}))测试用例表可以直接搬进论文格式为「用例名称 — 输入参数 — 预期结果 — 实际结果」。这里特别加了一条「不存在的城市」用例预期返回空列表而不是 500因为LIKE %不存在城市%匹配不到任何行返回自然的空数组。5. 离线评测用 PK 与 NDCG 验证推荐效果而不是靠感觉调参推荐系统写没写对不能用「看起来挺准」评价。论文实验章节需要一组离线指标。最后一节给出一个完整的评测流程顺便讲清楚三个必调的坑。5.1 按时间切分训练集与测试集行为数据按create_time排序前 80% 做训练后 20% 做测试。不能用随机切分随机切分等于用未来行为预测过去评测结果虚高。import sqlite3 conn sqlite3.connect(travel.db) cur conn.cursor() cur.execute(SELECT COUNT(*) FROM behavior) total cur.fetchone()[0] cur.execute(SELECT * FROM behavior ORDER BY create_time LIMIT ?, (int(total * 0.8),)) train cur.fetchall() cur.execute(SELECT * FROM behavior ORDER BY create_time LIMIT -1 OFFSET ?, (int(total * 0.8),)) test cur.fetchall()LIMIT -1 OFFSET n是 SQLite 取「从第 n 行到末尾」的写法。训练集喂给协同过滤构建相似度矩阵测试集里每个用户已交互的景点作为标准答案系统推荐结果需要命中它们。5.2 三个核心评估指标与实现def precision_at_k(rec_list, ground_truth, k10): rec_hit len(set(rec_list[:k]) set(ground_truth)) return rec_hit / k def recall_at_k(rec_list, ground_truth, k10): rec_hit len(set(rec_list[:k]) set(ground_truth)) return rec_hit / len(ground_truth) if ground_truth else 0 def ndcg_at_k(rec_list, ground_truth, k10): dcg 0 idcg 0 for i, spot_id in enumerate(rec_list[:k]): if spot_id in ground_truth: dcg 1.0 / (i 1) # 注意是 i1 不是 i2保持第一名为满分位置 for i in range(min(k, len(ground_truth))): idcg 1.0 / (i 1) return dcg / idcg if idcg 0 else 0PK 衡量推荐列表前 K 个里有多少命中分数偏低正常因为用户去过的景点本身有限NDCG 额外惩罚排得靠后的命中项推荐列表第 10 位命中只贡献1/10的增益。aggregate 时取所有测试用户的平均值并记录用户数。5.3 调参方向与实验记录表参数取值范围影响趋势建议值TopK 召回数10 / 20 / 50K 越大Recall 越高PK 先升后降20热门惩罚 λ0 / 1 / 2惩罚过强长尾曝光多但精度下降1行为权重 order0.5 / 1.0 / 2.0下单行为权重越大结果越偏向热门1.0网格搜索的方式是固定其他参数遍历top_k [10, 20, 50]打印每组 P10、Recall10、NDCG10选 NDCG 最高的一组。这里有个常见误用precision_at_k的 K 和top_k召回数不是一个东西召回数决定候选集合大小评测 K 决定截断位置论文里要写清楚。最后一个技巧把评测代码和指标输出写成一个evaluate.py模块每次调参后直接跑一遍输出 CSV 或表格实验记录自动沉淀论文里的「不同参数下的指标对比表」就是从这里来的。本文还有配套的精品资源点击获取