简介一份基于协同过滤算法的商品推荐系统毕业设计论文参考文档面向计算机相关专业正在准备毕业论文或毕业设计的用户。文档围绕选题动因、背景意义、系统设计、关键技术等展开系统基于SpringBoot框架采用B/S架构与MVC模式详细阐述了用户—用户协同过滤与物品—物品协同过滤两种推荐算法并结合用户历史行为数据说明推荐模块的实现思路还覆盖绪论、开发环境、数据库设计、系统功能、结论展望等完整章节可作为论文结构编排与内容撰写的范本。资料为单个docx文件约1.16MB技术栈涉及Java、SpringBoot、MyBatis、MySQL、Vue等目录层次清晰方便对照理解。已有2806人学习下载需要配套项目源码、数据库SQL或开发文档的读者可按页面提示私下联系作者进一步获取。1. 协同过滤推荐系统论文能立项、代码能跑通交付那一刻才是分水岭基于协同过滤算法商品推荐系统这个标题看起来像是毕设选题表里的一行字但它背后牵出的是一条完整的工程链路算法选型、数据建模、Java 服务实现、离线评估、接口联调以及上线之后才暴露出来的各种脏数据问题。很多开发者一开始以为核心难点在协同过滤公式本身真正动手才发现算法只占三成工作量剩下七成都在跟数据格式、相似度矩阵规模、接口响应时间和推荐效果验证较劲。这篇笔记面向的是要交论文、要跑通演示、或者要在小规模商品场景里快速落地一个推荐模块的人。我会把 ItemCF 的选型理由、Java 实现路径、离线评估方法和五个高频踩坑点一次讲透让你照着做就能产出一个结构完整、能写进文档的推荐系统。2. 协同过滤算法选型为什么商品场景优先 ItemCF 而不是 UserCF2.1 UserCF 与 ItemCF 的本质差异以及商品场景的适配判断协同过滤分两类基于用户的协同过滤UserCF找的是“和我兴趣相似的人”把那些用户买过的商品推荐给我基于物品的协同过滤ItemCF找的是“和这个商品相似的商品”把用户买过的商品的相似品推荐出来。两者的计算对象完全不同带来的工程代价也就不同。商品推荐场景通常用户量远大于商品量。以某电商平台为例注册用户可能上千万在售商品只有几十万冷门类目可能只有几千。UserCF 要维护一张用户与用户的相似度矩阵规模是用户数的平方千万级用户意味着万亿级的相似度条目无论内存还是计算时间都无法接受。ItemCF 维护的是商品与商品的相似度矩阵规模是商品数的平方几十万商品对应百亿级条目虽然也不小但可以通过截断相似度、只保留 TopK 来控制。从推荐效果看ItemCF 更适合商品这类兴趣相对稳定的对象。用户的兴趣会漂移上个月买母婴用品这个月买数码配件UserCF 找出来的相似用户可能还在推母婴。而商品与商品的相似关系相对稳定一款手机和它的充电配件在很长时间内都是强关联。ItemCF 还有天然的可解释性推荐结果可以标注“因为你看过 A所以推荐 A 的相似商品 B”这对电商转化率很重要。2.2 三种相似度计算方法对比余弦、皮尔逊、Jaccard 怎么选计算物品相似度之前要先定义“两个商品相似”的数学度量。评分数据完整度不同适用的公式也不同。余弦相似度是推荐系统最常用的度量它把每个商品被所有用户的行为看成一条向量计算两个向量的夹角余弦。公式的直观含义是两个商品被同一批用户喜欢它们的方向就越一致。余弦相似度对数值大小不敏感适合隐式反馈数据也就是用户只有“点击过”“购买过”这样的 0/1 行为没有明确打分。皮尔逊相关系数在余弦相似度的基础上做了均值中心化减去了商品向量的均值。它的优势是消除用户评分习惯的差异有的用户习惯打高分有的用户习惯打低分皮尔逊能把这种系统性偏差去掉。代价是如果商品被交互的用户数很少均值本身就不稳定算出来的相关系数会忽高忽低。Jaccard 相似度只看交集比例计算方法是“同时交互过两个商品的用户数”除以“交互过任意一个商品的用户数”。它忽略行为数值适合极度稀疏的场景但区分度有限很多商品算出来都是 0 或很小的值。实际项目中我的选择标准很简单如果是购买记录这种 0/1 数据用余弦如果有真实的评分数据用皮尔逊如果数据稀疏到大部分商品只有几条交互先用 Jaccard 做粗筛再对粗筛出的候选集用余弦精排。2.3 物品相似度矩阵到 Top-N 推荐列表的完整流程整个 ItemCF 的推荐流程可以拆成四个阶段。第一阶段是数据准备从行为日志表里取出用户对商品的交互记录清洗掉重复数据、异常数据和测试数据。第二阶段是相似度矩阵计算对每一对商品计算相似度只保留相似度大于阈值的条目写入矩阵。第三阶段是候选集生成拿到目标用户最近交互过的一组商品从相似度矩阵中找到与这些商品最相似的 K 个商品作为候选同时过滤掉用户已经交互过的商品。第四阶段是打分排序候选商品的最终得分是“用户对已交互商品的兴趣权重”乘以“商品与已交互商品的相似度”的加权和按得分倒序截取 TopN。这个流程里最容易出问题的是第三阶段的“过滤已交互商品”这一步。很多初版实现忘了过滤导致推荐列表里大量出现用户刚买过的东西看起来就像系统在重复推荐。还有一个细节是打分阶段要做归一化否则热门的相似商品会因为总交互量大而持续霸榜冷门但精准的商品永远排不上去。3. Java 工程怎么落地数据表设计、MyBatis 映射与 ItemCF 核心代码3.1 数据模型设计用户信息表、商品表、行为记录表与推荐结果表工程落地第一步是定义数据模型。一个能支撑离线推荐和在线服务的数据库结构至少要包含四张表用户表、商品表、用户行为表和推荐结果表。用户行为表是协同过滤的原料字段要记录 user_id、item_id、behavior_type 和 create_timebehavior_type 用数字区分浏览/收藏/加购/购买。推荐结果表的作用是保存每次离线计算的 TopN 结果线上接口直接查这张表返回推荐列表避免每次请求都现算相似度。结果表要冗余一个 generation_time 字段以便后续判断推荐结果的新鲜度。接下来是建表 SQL我用 MySQL 语法示范字段命名保持通用CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, name varchar(50) DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE item ( id bigint NOT NULL AUTO_INCREMENT, title varchar(200) DEFAULT NULL, category_id bigint DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE user_behavior ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL, item_id bigint NOT NULL, behavior_type tinyint NOT NULL COMMENT 1:浏览 2:收藏 3:加购 4:购买, create_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user (user_id, behavior_type), KEY idx_item (item_id, behavior_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE recommend_result ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL, item_id bigint NOT NULL, score double NOT NULL, rank int NOT NULL, generation_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_rank (user_id, rank) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;行为表上必须建联合索引一组指向 (user_id, behavior_type)另一组指向 (item_id, behavior_type)。因为相似度计算要按商品聚合行为数据用户推荐要按用户聚合行为数据两个方向的查询都很频繁没有索引会让离线计算变成全表扫描跑几个小时也出不来。3.2 相似度矩阵计算单机 Java 串行实现与参数说明离线计算相似度矩阵的核心逻辑可以单机跑通不必一开始就上 Spark。先按商品维度聚合用户行为构建“商品到用户集合”的倒排表再遍历商品对计算余弦相似度。下面这段代码是完整可运行的 ItemCF 相似度计算骨架public class ItemSimilarityCalculator { // 输入用户-商品行为记录behaviorType4 表示购买 public MapLong, MapLong, Double calcSimilarity(ListBehavior behaviors, int topK) { // 第一步构建商品 - 用户购买记录的倒排表 MapLong, MapLong, Double itemUsers new HashMap(); for (Behavior b : behaviors) { if (b.getBehaviorType() ! 4) continue; itemUsers .computeIfAbsent(b.getItemId(), k - new HashMap()) .put(b.getUserId(), 1.0); } ListLong itemIds new ArrayList(itemUsers.keySet()); MapLong, MapLong, Double similarityMatrix new HashMap(); // 第二步两两计算余弦相似度 for (int i 0; i itemIds.size(); i) { long itemA itemIds.get(i); MapLong, Double usersA itemUsers.get(itemA); for (int j i 1; j itemIds.size(); j) { long itemB itemIds.get(j); MapLong, Double usersB itemUsers.get(itemB); double dot 0.0; for (Long uid : usersA.keySet()) { if (usersB.containsKey(uid)) { dot usersA.get(uid) * usersB.get(uid); } } if (dot 0.0) continue; double normA norm(usersA.values()); double normB norm(usersB.values()); double sim dot / (normA * normB 1e-9); similarityMatrix .computeIfAbsent(itemA, k - new HashMap()) .put(itemB, sim); similarityMatrix .computeIfAbsent(itemB, k - new HashMap()) .put(itemA, sim); } } // 第三步每个商品只保留相似度最高的 topK 个邻居 MapLong, MapLong, Double result new HashMap(); for (Map.EntryLong, MapLong, Double entry : similarityMatrix.entrySet()) { ListMap.EntryLong, Double list new ArrayList(entry.getValue().entrySet()); list.sort((a, b) - Double.compare(b.getValue(), a.getValue())); int limit Math.min(topK, list.size()); MapLong, Double neighbors new HashMap(); for (int k 0; k limit; k) { neighbors.put(list.get(k).getKey(), list.get(k).getValue()); } result.put(entry.getKey(), neighbors); } return result; } private double norm(CollectionDouble values) { double sum 0.0; for (double v : values) sum v * v; return Math.sqrt(sum); } }这段代码有几个关键参数需要理解。topK 控制每个商品保留的邻居数量建议从 10 到 30 之间起调太小会让推荐候选不足太大让后续打分阶段引入大量弱相关商品。过滤行为类型的逻辑目前只统计购买行为实际项目中可以把加购和收藏也纳入但要给不同行为类型不同的权重否则购买、浏览、收藏混在一起算相似度结果会偏向高频浏览的商品。这个串行实现的复杂度是商品数的平方乘以每个商品的平均用户数几万个商品完全能单机扛住。如果商品数超过十万就要考虑按类目拆分计算或者用 Spark 跑分布式版本。3.3 推荐生成从相似度矩阵到 TopN 列表的完整调用链相似度矩阵算好之后推荐生成逻辑要读取目标用户最近交互过的商品对每个已交互商品从矩阵中取出邻居加权累加得到候选商品得分。下面这段代码实现了推荐列表生成注意已经把用户买过的商品过滤掉了public class Recommender { private final MapLong, MapLong, Double similarityMatrix; public Recommender(MapLong, MapLong, Double similarityMatrix) { this.similarityMatrix similarityMatrix; } public ListRecommendItem recommend(Long userId, ListBehavior userBehaviors, int topN, int maxNeighbor) { // 第一步找出用户最近交互过的商品这里以购买行为为主取最近10个 MapLong, Double userItemWeights new HashMap(); userBehaviors.stream() .filter(b - b.getBehaviorType() 4) .sorted(Comparator.comparing(Behavior::getCreateTime).reversed()) .limit(10) .forEach(b - userItemWeights.put(b.getItemId(), userItemWeights.getOrDefault(b.getItemId(), 0.0) 1.0)); // 第二步遍历已交互商品从相似度矩阵取邻居并加权累加 MapLong, Double scores new HashMap(); SetLong seenItems userItemWeights.keySet(); for (Map.EntryLong, Double entry : userItemWeights.entrySet()) { Long itemId entry.getKey(); double weight entry.getValue(); MapLong, Double neighbors similarityMatrix.getOrDefault(itemId, Map.of()); neighbors.entrySet().stream() .limit(maxNeighbor) .forEach(nb - { if (seenItems.contains(nb.getKey())) return; double addScore nb.getValue() * weight; scores.merge(nb.getKey(), addScore, Double::sum); }); } // 第三步按得分倒序截取 TopN ListRecommendItem result new ArrayList(); scores.entrySet().stream() .sorted(Map.Entry.Long, DoublecomparingByValue().reversed()) .limit(topN) .forEach(e - result.add(new RecommendItem(e.getKey(), e.getValue()))); return result; } }这段逻辑里最常见的调参点是 maxNeighbor。它控制在计算推荐得分时每个已交互商品最多贡献多少个邻居商品。这个值一般比建矩阵时的 topK 小比如建矩阵时保留 20 个邻居生成推荐时只用最相似的 5 到 8 个。原因是离得很远的邻居本身相似度就很低累加进来只会在候选集里引入噪声对提升准确率反而帮倒忙。用户行为权重这里也做了简化同一商品买过一次和买过三次的权重不同。更精细的做法是给行为时间加衰减越近的购买行为权重越高这样推荐结果能反映用户当前的兴趣变化。时间衰减的典型实现是权重乘以exp(-lambda * daysDiff)lambda 通常取 0.01 到 0.05根据商品类目更新频率调整。4. 评估与调参准确率、召回率和 K 值到底怎么取舍4.1 离线评估的三个核心指标准确率、召回率、覆盖率的最小实现推荐系统上线前必须先做离线评估否则参数选得好不好全靠感觉。离线评估的思路是把行为数据按时间切分前 80% 作为训练集计算相似度矩阵后 20% 作为测试集验证推荐效果。对每个测试用户用训练集生成 TopN 推荐然后看推荐列表和测试集里实际发生行为的商品重合度。准确率计算的是推荐列表中有多少商品真的被用户交互了召回率计算的是用户实际交互的商品中有多少被推荐出来了。覆盖率则是一个整体指标统计推荐系统总共推荐了多少不同商品除以全量在售商品数用来衡量推荐结果是不是只集中在少数热门商品上。我用一段 Python 脚本做离线评估因为数据分析场景 Python 更方便Java 负责生产逻辑评估脚本独立维护import math from collections import defaultdict def evaluate(test_behavior, recommend_func, top_n10, all_itemsset()): # test_behavior: dict, user_id - set(实际交互商品) # recommend_func: 传入用户id, 返回推荐商品id列表 hit, rec_cnt, test_cnt 0, 0, 0 recommended_items set() for uid, actual_items in test_behavior.items(): rec_items recommend_func(uid, top_n) rec_cnt len(rec_items) test_cnt len(actual_items) recommended_items.update(rec_items) hit len(actual_items set(rec_items)) precision hit / rec_cnt if rec_cnt else 0.0 recall hit / test_cnt if test_cnt else 0.0 coverage len(recommended_items) / len(all_items) if all_items else 0.0 return {precision: precision, recall: recall, coverage: coverage}评估时需要注意一个 Epch 坑按用户随机划分训练集和测试集会数据泄露同用户的行为一部分进训练集一部分进测试集相似度矩阵已经见过用户的部分偏好评估结果虚高。我用的是按时间切分比如把 6 月之前的行为作为训练集6 月之后的行为作为测试集这样更接近线上真实环境。4.2 K 值、相似度截断阈值和热门商品惩罚的配合调参ItemCF 有三个核心参数相似度矩阵保留的邻居数 topK、参与推荐打分的邻居截断数 maxNeighbor、以及相似度截断阈值。它们之间不是独立的调参时应该遵循“先定矩阵规模再调打分截断最后看覆盖率补惩罚项”的顺序。下面是一组典型的调参实验结果基于一个模拟商品数据集行为总量约 20 万条商品数 8000用户数 15000参数组合准确率召回率覆盖率说明topK10, maxNeighbor50.1820.2140.156整体偏低邻居太少导致候选不足topK20, maxNeighbor100.2410.3020.187效果提升明显候选集更丰富topK30, maxNeighbor150.2380.2950.194准确率略降噪声邻居拖累topK30, maxNeighbor10, 相似度阈值0.30.2560.3180.169过滤弱关系后准确率回升从这组数据能看出一个规律topK 从 10 升到 20 的效果最明显从 20 再升到 30 收益递减。maxNeighbor 与 topK 保持约一半的比例效果较好。相似度阈值的作用是过滤掉那些交集合很小、纯属巧合的高相似度商品对比如只有两个用户同时买过两款商品计算出的余弦相似度可能高达 1.0这是典型的过拟合噪声阈值过滤非常必要。热门商品惩罚是覆盖率低时的补救手段。如果一个商品被大量用户购买它和其他商品的共同交互数都会偏高导致它频繁出现在相似度矩阵里。常见做法是在相似度计算时给热门商品的贡献加一个衰减系数公式可以写成sim dot / (normA * normB) * log(总用户数 / 商品交互用户数)这个 log 项就是 IDF 权重。加了惩罚之后推荐结果会更倾向挖掘长尾商品覆盖率能有明显提升。5. 协同过滤避坑指南五条真实踩坑记录5.1 相似度矩阵计算三小时没跑完商品数量膨胀某个实验项目里离线计算任务跑了三个多小时还没结束。打开日志发现商品总数已经到 12 万代码还在双重循环里逐个算余弦相似度。主要原因是没有做任何粗筛冷门商品之间也要两两计算而这些商品对绝大部分没有共同交互用户。解决方法是按类目拆分计算。商品相似度几乎不会跨类目产生强关联可以先按 category_id 分组组内计算相似度矩阵组间结果直接丢弃。类目拆分后原本 12 万商品的全量两两对比变成几千个类目内的小矩阵计算耗时从三小时降到十几分钟。另一个办法是设置最低共同交互用户数比如两个商品至少有 3 个用户共同购买过才计算相似度否则直接跳过。5.2 行为记录很少的用户推荐结果像随机抽奖冷启动用户只有一两条行为记录时从相似度矩阵里只能找到一两个可用的邻居推荐结果基本取决于那一两条行为对应的相似商品。比如用户只买过一袋大米推荐列表可能全是各种品牌的米用户的真实诉求可能是厨房用品整体采购。这类问题的本质是数据稀疏下相似度估计不可靠根因不在算法而在数据量不足。我常用的兜底方案是分级推荐当用户有效行为少于 3 条时直接返回热门商品 TopN行为 3 到 10 条时用 ItemCF超过 10 条才用完整的加权推荐。热门商品作为兜底虽然个性化了但至少保证推荐结果不是完全离谱用户的点击率也能支撑住。5.3 新上架商品永远进不了推荐列表新商品在上架初期没有任何交互记录无论 UserCF 还是 ItemCF 都无法把它推荐给用户。这个问题的根因是协同过滤本质上是一个基于历史数据的算法对新对象天然无感知。应对方案的思路是给新商品一个“探索期”上架后 48 小时内在推荐候选里按 5% 到 10% 的比例混入新品按类目偏好排序展示。探索期结束之后如果新品积累了足够的交互记录就正常进入相似度矩阵参加计算。如果交互记录仍然很少就继续留在探索池里。这里要注意探索池的体积控制混入的新品比例太高会拉低整体推荐准确率因为大部分新品确实不是用户想要的。5.4 皮尔逊相关系数算出一堆 NaN 和 1.0用皮尔逊公式计算相似度时如果两个商品的用户集合完全相同且评分值也完全相同分母会出现零。更隐蔽的情况是商品向量标准差为零此时相关系数未定义。我之前调试时看到相似度矩阵里出现 1.0 和 NaN第一反应是代码逻辑错排查半天才发现是数据分布问题。解决方法是计算前对商品行为稀疏度做检查当两个商品共同交互用户数小于阈值时直接返回 0不进入皮尔逊计算。另外在公式里加上数值保护比如分母小于 1e-9 时直接返回 0。如果业务中评分数据比较稠密也可以直接用余弦相似度替代皮尔逊省掉均值中心化带来的各种边界问题。5.5 论文架构图跟工程代码对不上改代码还是改文档这是写毕设和项目文档时最常见的坑。论文里画了 UserCF 和 ItemCF 双路实现的架构图实际代码只做了 ItemCF论文里说推荐结果做了实时更新实际上线跑的是离线任务每小时刷一次。答辩时被评审一问就露馅。我的处理原则是“代码能跑通是第一位的文档跟随代码修正”。架构图必须和实际模块对应如果代码只实现了 ItemCF就把架构图里 UserCF 的部分改成“预留扩展模块”再补一段话说明为什么不实现 UserCF。对于离线计算和在线接口的时间关系文档里要写清楚离线计算周期、结果落表方式、在线请求读表策略。文档里出现的每一个模块、每一条数据流都应该是代码里真实存在的这样的文档才经得起追问。6. 高阶技巧用 Redis 分层缓存推荐结果与增量更新策略先从一个具体的工程痛点说起离线计算每小时生成一次推荐结果但用户打开 App 的请求是实时的如果每次都把 TopN 结果重新算一遍接口响应会直接拖到几百毫秒甚至秒级。我一般的做法是把推荐结果分成两层缓存第一层用 Redis 存每个用户的推荐列表第二层用本地进程缓存存相似度矩阵本身。第一层缓存的做法很直接离线任务生成推荐结果后把 user_id - 商品列表写入 Rediskey 设计成rec:user:{userId}:v3v3 是算法版本号方便后续切换新版本时实现秒级灰度。写入时设置过期时间为计算周期加一小时的冗余保证用户看到的推荐结果新鲜度可控。接口收到请求后直接拼接 key 查 Redis没有命中再走后备查询。下面是一段 Spring Boot 中查询推荐结果的简化代码RestController public class RecommendController { Autowired private StringRedisTemplate redisTemplate; GetMapping(/api/recommend) public ListLong recommend(RequestParam Long userId) { String key rec:user: userId :v3; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { // 缓存命中直接把逗号分隔的商品id串拆成列表返回 return Arrays.stream(cached.split(,)) .map(Long::parseLong).collect(Collectors.toList()); } // 缓存未命中查库兜底 return queryFromDb(userId); } }这段代码里缓存时间如果设置太短离线任务还没跑完缓存就过期了接口会在一个周期内出现缓存穿透。我习惯把过期时间设为离线任务执行周期的 1.5 倍比如任务每半小时跑一次缓存就设置 45 分钟过期留足缓冲。相似度矩阵的增量更新策略有三个档位不同阶段选不同的更新频率。第一个档位是全量重建每天凌晨跑一次适合商品量和用户量都比较稳定的小规模系统。第二个档位是周期增量每小时把新增行为数据合并进行为表重新计算受影响的商品对相似度并更新 Redis。第三个档位是近实时增量通过监听行为日志的 MQ 消息增量更新商品相似度中的分子分母统计量这个方案适合商品数量不大但行为量很大的场景。我实际项目中最常用的是第二个档位每小时增量更新一次。理由是全量重建间隔时间长发现新兴趣慢近实时更新出一个 bug 很难排查前面三种增量更新方案在实施成本、实时性和稳定性上已经形成了一条完整的演进路径从最简单的定时全量到事件驱动更新每一步都有明确的适用边界和代价。理解了这条路径你拿这个方案去对接生产环境时就不会心慌。最后说一个我自己的教训第一次做推荐系统的时候我把百分之八十的精力花在调相似度公式上结果上线后用户反馈“推荐的东西我根本不感兴趣”。后来才发现问题不在算法而在于展示位置太靠后、推荐理由文案太弱用户根本没感知到这是个性化推荐。从那以后我就养成了一个习惯推荐结果上线前先让两三个非技术同事用真实账号试一周看看他们能不能说出“这系统知道我喜欢什么”。这比任何离线指标都管用。希望帮到你。本文还有配套的精品资源点击获取