简介一份基于LBS和混合推荐算法的智能旅游导游系统完整项目资源面向计算机专业毕业设计或课程作业主要解决个性化景点推荐与实时位置服务结合的问题。压缩包共91个文件约6.47MB包含Android工程源码xml、kt、java、Gradle构建脚本、第三方jar包与so库以及png/jpg图片资源和README文档覆盖前端界面、后端逻辑与数据库配置等模块。资源提供LBS定位、混合推荐算法融合内容与协同过滤等策略、用户行为采集与推荐展示的完整代码可直接导入Android Studio运行学习。当前已有173人学习适合准备智能旅游类课题的学生参考也可作为理解推荐系统与移动定位集成的实战范例。通过阅读项目结构、算法调用与接口设计能快速掌握从数据采集到推荐落地的整体流程。1. 为什么说 LBS 是混合推荐的第一道闸门做旅游导游类系统最先遇到的不是推荐算法而是“用户到底在哪儿、周边有什么”。一个用户站在景区门口你把三公里外的热门景点推到第一条推荐再准也显得不智能。LBS 解决的就是这个问题先把候选集压到用户当前可触达的范围内再做个性化排序。单纯用 LBS 的缺点是“附近即喜欢”它不关心用户是否真的对这类景点感兴趣。真正能支撑起一个毕业设计级项目、同时回答“为什么这么设计”的方案是把 LBS 作为召回层的硬约束再叠加混合推荐算法用内容偏好和用户行为共同影响排序。这套思路适合课程设计、本科毕设也适合想快速验证推荐闭环的小型工程团队。2. 从定位到候选集LBS 过滤机制与景点数据建模2.1 LBS 不只是拿一个经纬度移动端的定位通常来自 GPS、Wi-Fi 和基站三者的融合结果。Android 上我一般用FusedLocationProviderClient它比直接调LocationManager更省电定位间隔也更好控制。很多人只关注拿到经纬度忽略了精度和时效性。FusedLocationProviderClient fusedClient LocationServices.getFusedLocationProviderClient(context); fusedClient.getCurrentLocation(LocationRequest.create() .setPriority(LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY) .setInterval(10000), null) .addOnSuccessListener(location - { double lat location.getLatitude(); double lng location.getLongitude(); // 把定位结果传给后端推荐服务 });这段代码里有两个参数值得关注。PRIORITY_BALANCED_POWER_ACCURACY会在百米级精度和省电之间取平衡适合景区导航如果做步行导航可以改成PRIORITY_HIGH_ACCURACY。setInterval(10000)表示 10 秒获取一次位置频繁回调会消耗电量和流量。拿到坐标后建议先做一次合理性校验经纬度是否在 090 和 -180180 的合法范围内防止把异常坐标直接送到推荐接口。2.2 景点表设计空间字段和标签字段缺一不可推荐系统离不开结构化数据。景点表至少要包含两类字段一类是空间字段用于距离计算另一类是内容标签用于后续的内容推荐。MySQL 8.0 以上可以用ST_Distance_Sphere旧版本则自己实现 Haversine 公式。CREATE TABLE poi ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, lat DOUBLE NOT NULL, lng DOUBLE NOT NULL, tags VARCHAR(255), category VARCHAR(32), popularity INT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); SELECT id, name, lat, lng, tags, (6371000 * acos( cos(radians(?user_lat)) * cos(radians(lat)) * cos(radians(lng) - radians(?user_lng)) sin(radians(?user_lat)) * sin(radians(lat)) )) AS distance FROM poi HAVING distance 5000 ORDER BY distance ASC;?user_lat和?user_lng是传入的用户坐标6371000 是地球半径单位米。这条 SQL 一次性完成“算距离 范围过滤 距离排序”。如果数据量超过几万条HAVING distance 5000会让全表扫描此时应该改成先用经纬度范围粗筛再用 Haversine 精算比如lat BETWEEN ?user_lat - 0.05 AND ?user_lat 0.05。2.3 距离阈值里的业务含义阈值设多少是 LBS 过滤最关键的问题。小型景区半径设 2 公里城市级导览设 5 公里。阈值太小热门经典景点会被滤掉系统显得“不智能”太大又回到了无差别推荐。我习惯把阈值和交通方式绑定步行模式用 3 公里驾车模式用 10 公里。这个参数不要写死放到配置中心或者用户设置项里方便后续调优。3. 混合推荐算法内容召回、协同过滤与加权融合3.1 内容召回用景点标签计算用户偏好LBS 过滤完成之后候选景点可能还有几百个。混合推荐的第一步是内容召回核心思路是记录用户历史上浏览、收藏、预约的景点标签算出用户对哪些标签更感兴趣再拿这个偏好向量和景点标签向量做相似度计算。from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity # 假设有 5 个景点tags 是景点标签组合 poi_tags [ 历史 古迹 博物馆, 海滨 亲子 度假, 历史 古城 文化, 自然 山林 徒步, 博物馆 艺术 展览 ] tfidf TfidfVectorizer(token_patternr[\w\u4e00-\u9fa5]) tag_matrix tfidf.fit_transform(poi_tags) # 用户偏好向量来自用户历史行为的标签统计 user_profile tfidf.transform([历史 博物馆 文化]) scores cosine_similarity(user_profile, tag_matrix).flatten() print([round(s, 4) for s in scores])上面输出的是每个景点和用户偏好向量的余弦相似度。token_pattern这里保留中文和英文字符避免中文标签被空格切碎。user_profile的构造不是随便写一句话而是从用户行为表里按标签频次生成比如“历史”出现 5 次“博物馆”出现 3 次就拼接出加权后的文本。这个方法的优点是冷门景点也能被推荐因为它不看别人是否喜欢只计算文本相似度。3.2 协同过滤从行为矩阵找相似用户内容偏好无法发现意外兴趣所以还要补一路协同过滤。基于物品的协同过滤在景点场景里通常比基于用户更稳定因为景点数量变化慢用户兴趣变化快。我常用的是物品余弦相似度import numpy as np # 行是用户列是景点值是行为权重浏览1收藏3预约5 interaction_matrix np.array([ [5, 0, 3, 0, 1], [0, 3, 0, 5, 0], [1, 5, 0, 0, 3], [0, 0, 4, 3, 0] ]) def cosine_sim(a, b): return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b) 1e-9) # 计算景点0和其他景点的相似度 item_vec interaction_matrix[:, 0] for i in range(interaction_matrix.shape[1]): print(fitem{i}: {cosine_sim(item_vec, interaction_matrix[:, i]):.4f})这段代码把用户行为矩阵压缩成物品向量然后计算任意两个景点的相似度。分母加1e-9是为了避免除零。行为权重的设定会直接影响结果浏览只代表“看到”预约代表“有意向”所以权重差异不能太小。得到相似度之后召回用户之前高权重交互过的景点的相似物品形成协同过滤候选集。3.3 把三路分数合成一个可解释的排序到这一步每个候选景点有了三个分数内容匹配度score_content、协同过滤分数score_cf、以及 LBS 距离分score_distance。混合推荐最朴素也最有效的做法是加权求合然后统一排序。final_score W1 * score_content W2 * score_cf W3 * score_distance参数默认值作用调节方向W10.4控制内容偏好的影响力用户兴趣明确时调高W20.4控制相似行为的迁移力行为数据充足时调高W30.2控制距离的重要性导览场景调高但不要超过 0.4三个分数要先做归一化否则距离分单位是米内容分单位是余弦相似度直接相加会失去意义。我用的是 min-max 归一化公式是(value - min) / (max - min)。W1 W2 W3最好等于 1确保最终分数保持在 01 之间方便前端直接展示推荐理由。这样做的好处是每一路分数都可以单独调试比如发现推荐结果偏向远距离景点就把 W3 调大其他两路不变。4. 工程落地Android 端接入与推荐接口联调4.1 后端推荐接口的输入输出约定混合推荐服务要暴露给移动端的接口我一般定义成一次带经纬度和用户标识的 POST 请求。返回结果里不仅要有景点列表还可以携带每个景点命中的推荐理由方便前端展示“距离你 800 米因为你喜欢历史古迹”。POST /api/recommend { userId: u_1001, lat: 31.2304, lng: 121.4737, radius: 3000, limit: 20 }{ code: 0, data: [ { poiId: 101, name: 豫园, distance: 850, score: 0.82, reason: [距离你较近, 与本城历史类景点偏好匹配], tags: [历史, 园林, 古迹] } ] }radius和limit是两个建议参数前者由客户端传入后者控制返回条数。reason字段不是算法必须的但对毕设答辩和 Demo 演示非常重要它能把黑盒推荐变成可解释推荐让用户和评委都更容易理解系统价值。4.2 移动端定位、请求与缓存Android 端我通常用 Retrofit 封装接口记得把定位结果存入内存而不是数据库避免权限变更后读到脏数据。代码里要注意两个细节一是定位请求和网络请求都要做超时处理二是不要在 Android 的主线程里调用推荐接口。interface RecommendApi { POST(api/recommend) suspend fun recommend(Body request: RecommendRequest): RecommendResponse } // ViewModel 中调用 suspend fun loadRecommend(lat: Double, lng: Double, radius: Int) { val request RecommendRequest(userId currentUser, lat lat, lng lng, radius radius) val response api.recommend(request) // 推荐结果写缓存地图拖动后再取缓存 cache.put(last_recommend, response) }用suspend函数可以避免回调地狱但要注意 Retrofit 里的suspend需要kotlinx-coroutines支持。若项目是 Java 写的就改成enqueue(new Callback...)。cache.put这一步容易被忽略用户在地图上拖动后如果每次都重新请求后端压力会非常大且用户体验差。推荐在 1 公里范围内复用上一次的结果超过范围再重新请求。4.3 数据库与配置文件的协同项目里出现的gradle.properties、cloud.js和proguard-rules.pro各自扮演不同角色。gradle.properties建议放 JVM 内存参数避免构建时 OOMproguard-rules.pro要保留推荐模型类的字段名否则混淆后反射拿不到属性名cloud.js如果是云函数建议只放纯计算逻辑不要放数据库连接串。推荐服务的配置项比如默认权重 W1/W2/W3放到application.yml或环境变量里方便部署后热更新。5. 推荐质量验证与调参技巧5.1 离线评估看三个指标不要只看准确率毕设演示通常只给人看排序结果但系统能不能上线需要离线指标来兜底。对推荐系统来说只看准确率会误导人因为用户不点不代表不喜欢可能是首页没有曝光。我建议至少看这三项指标含义算法说明PrecisionK推荐列表前 K 个中用户真实感兴趣的比例K 通常取 5 或 10RecallK用户感兴趣集合中有多少个被推到了前 K衡量召回能力Coverage推荐算法能覆盖多少不同景点覆盖率太低说明推荐结果总是同一批热门景点计算时把用户历史行为划分为训练集和测试集比如取出用户 80% 的行为训练模型另外 20% 做验证。混合推荐的目标不是让单一指标最高而是让 Precision 和 Recall 的平衡最好。如果调到 W1 和 W2 都是 0.5发现 Coverage 下降就说明结果过于集中需要给权重加一点随机的探索项。5.2 冷启动的兜底策略是评分的一部分新用户没有行为记录协同过滤算不出来。此时内容推荐也缺乏用户偏好因为还没有历史标签。我的处理方式是把冷启动用户的排序逻辑改成“距离优先 热度修正”先按距离升序取前 30 个景点再用popularity分数做二次排序。这个热度分数就是景点表的popularity字段。这套策略也能服务新景点上架新景点没有行为数据需要用内容召回兜底否则永远进不了推荐列表。5.3 推荐参数开关与埋点调试实际项目里我习惯把 W1/W2/W3 这三个参数做成线上可调的配置配合日志埋点观察变化。埋点至少记录三项曝光景点列表、用户点击景点的 ID、以及最终产生预约行为的景点 ID。有了这三类数据就能计算推荐列表的真实转化率。比如发现 W2协同过滤权重提高后用户点击率上升但预约率下降那就说明推了用户想看的内容但不符合出行计划需要回退 W2 并调大距离权重 W3。具体调参时我会把用户分成两组分别使用旧权重和新权重跑一周再对比数据比本地人为调参更可靠。每次调完参数记得把配置文件里的版本号也更新字段避免上线后分不清线上跑的是哪组配置。本文还有配套的精品资源点击获取