SSM框架下的个性化图书馆推荐系统毕设实战：协同过滤与全流程设计

搞java毕设的同学应该都遇到过这种情况：题目看起来简单，真正动手才发现坑不少。就拿这个“个性化图书馆推荐系统”来说，关键词拆开无非是java、SSM、推荐系统三件事，但合在一起，既要完成图书馆的图书入库、借阅归还、读者管理，又要在这些基础功能之上做出一个能根据用户偏好主动推书的推荐引擎，工作量直接翻倍。这篇文章我就用最实在的方式，把整个项目的需求拆解、技术选型、数据库设计、推荐算法实现、部署调试和答辩要点全部过一遍，尽量让拿到类似题目的你少走弯路。

1. 项目拆解与需求分析

1.1 这个项目到底在解决什么问题

图书馆管理系统本身是一个老掉牙的课题，随便搜都能找到一堆代码。但加了“个性化推荐”四个字之后，性质就不一样了。传统系统只解决“书怎么管”的问题，也就是图书的增删改查、借还记录、逾期统计；个性化推荐则解决“书怎么找”的问题，核心是：一个读者登录之后，不应该靠搜索框自己翻半天，而是系统能根据他的历史借阅记录、收藏行为、图书分类偏好，主动告诉他“你可能想看这几本”。

这套逻辑放到移动互联网里很常见，比如购物软件猜你喜欢、视频网站为你推荐。但放到毕设场景里，难点不在于概念新，而在于怎么在有限的代码量和答辩深度之间找一个平衡点。我见过不少同学把这个题目做成一个披着推荐外衣的普通CRUD，推荐模块只是按图书点击量排个序，这样答辩时一定会被老师追问推荐逻辑，答不上来就很被动。

所以接到这个题目，第一步不是写代码，而是先把功能边界画清楚。我建议分三个层次：底层是图书管理和读者管理，这是全流程管理系统的地基；中间层是借阅流通模块，包含预约、借书、还书、续借、逾期处理；顶层才是个性化推荐引擎，它依赖底层数据，输出推荐列表，同时用户对推荐结果的反馈（点开、收藏、借阅）又会回流到推荐引擎里，形成一个数据闭环。

1.2 功能需求拆解与优先级划分

从毕设工作量角度考虑，功能不是越多越好，而是要覆盖完整业务链条，并突出推荐系统这个核心差异化点。我按优先级整理了一张功能清单，你可以直接参考：

这里我特别说一下为什么要有两套协同过滤算法。很多教程只让你实现一个，但答辩时老师很爱问一句话：“你这个推荐算法适用于什么场景？如果换成另一种场景会怎样？”基于用户的协同过滤（UserCF）适合社交属性强、用户量小的场景，比如系里几十个学生内部系统；基于物品的协同过滤（ItemCF）适合用户量大、物品相对稳定的场景，比如正规图书馆几万册藏书。两个都实现，然后根据实时计算出的用户数、图书数动态切换推荐策略，这一下就把系统档次提升了。

1.3 全流程业务闭环的设计思路

所谓“全流程管理系统”，考验的是你对业务链条的理解。一个读者从注册开始，经历了搜索图书、查看详情、收藏、借阅、阅读、评价、归还、可能续借或逾期这一整条链路，每一个环节产生的数据都有价值。设计系统时，我特别建议采用事件驱动的思路：每一次点击行为，不仅是功能交互，更是推荐算法的输入数据。比如用户搜索了“算法”关键词，这个搜索记录被记录下来，就能用于分析他的兴趣主题；用户查看了某本计算机图书的详情但没借，这比直接忽略更有信号价值。把这些事件统一写入用户行为表，推荐引擎才能获得足够的数据原料。

2. 技术选型与架构设计

2.1 为什么题目偏偏要求SSM框架

先说个现实问题：现在工业界做java项目基本都是Spring Boot，但高校毕设题目里SSM（Spring + SpringMVC + MyBatis）依然占据半壁江山。原因并不复杂，很多学校的课程体系还停留在SSM阶段，数据库原理、Java Web、企业级开发这几门课用的就是这套组合；另外SSM是Spring Boot的前置知识，老师会默认你能手写配置才能更好理解自动装配的原理。

SSM这套组合各自承担的职责很清晰：Spring负责对象管理和事务控制，SpringMVC负责请求路由和参数绑定，MyBatis负责数据库访问。它们之间通过Spring的IoC容器整合在一起，SpringMVC的Controller被注册成Spring管理的Bean，MyBatis的Mapper接口通过动态代理注入到Service层。相比Spring Boot，SSM的配置确实繁琐，但理解了它的整合逻辑之后，后续学习Spring Boot的自动配置会轻松很多，这也是老师坚持SSM出题的深层原因。

如果你自己做选型，我给你一个忠告：不要为了展示技术盲目升级成Spring Boot。毕设评分看的是题目完成度和业务逻辑是否自洽，用SSM能稳定跑通，并且能在答辩中清晰说明SSM三个框架的边界和整合方式，就已经拿到基础分了。如果项目时间宽裕，可以把SSM作为基础版本写好，再额外用Spring Boot重写一个接口做对比，这是很好的加分思路，但前提是SSM版本已经足够稳定。

2.2 推荐算法选型：协同过滤与冷启动方案

推荐系统领域算法多如牛毛，但毕设场景里我强烈推荐从协同过滤切入，原因有三：一是它不需要构建用户画像和内容特征工程，只需要用户行为数据，实现门槛低；二是它足够经典，答辩时有大量理论基础可以讲；三是它可以通过离线实验直观展示推荐效果。我推荐用Spark MLlib做离线计算、用MySQL存储相似度矩阵的混合方案，但考虑到很多同学服务器配置一般，也可以直接用Java纯内存计算，数据量在几万条时性能完全够用。

协同过滤分为基于用户（UserCF）和基于物品（ItemCF）两条路线。UserCF的核心思想是找到和目标用户兴趣相似的其他用户，把这些相似用户爱看的书推荐给目标用户。ItemCF则反过来，先通过用户的集体行为计算图书之间的相似度，然后根据用户历史喜欢的图书，推荐与之相似的图书。从计算逻辑上看，UserCF在线部分需要实时计算用户相似度矩阵，扩展性较差；ItemCF可以离线算好物品相似度矩阵，在线只需要查表聚合，响应速度更快。这也是为什么工业界多用ItemCF的原因。

冷启动问题一定要写进设计文档里。新用户没有行为数据，协同过滤算不出任何相似度；新图书没有用户行为，也无法被推荐。我的处理方案是三层递进的冷启动策略：第一层，新用户直接推荐最近30天下架率低的热门图书Top 20，同时允许新用户在注册时勾选感兴趣的分类标签；第二层，用户产生少量借阅行为后，立即根据借阅图书所属分类做基于内容的最简单匹配，把同分类高评分图书推上去；第三层，行为量达到一定阈值（比如借阅超过5本）才切换成ItemCF算法。这样系统从上线第一天就能跑出合理结果，不会给评委留下“推荐列表是空的”这种致命印象。

2.3 系统整体架构与分层设计

我采用的还是经典三层架构，但在细节上做了一些适配。表现层用JSP+JSTL+CSS，没有引入太复杂的前端框架，原因很简单：毕设重点在业务逻辑和算法，前端保持整洁够用即可。控制层用SpringMVC，所有请求统一走Controller，JSON数据交互用Fastjson，上传图片用MultipartFile处理。业务层用Spring的声明式事务控制，借书和还书操作必须保证事务原子性，不然会出现库存被减为负数这种严重bug。

数据访问层用MyBatis，需要特别注意XML中的动态SQL写法，因为推荐系统的查询条件非常灵活，经常要根据用户ID、分类、时间区间组合过滤。MyBatis的 标签、 标签、 标签是高频使用的。整体数据流向是：浏览器发起请求，DispatcherServlet分发到对应Controller，Controller调用Service接口，Service实现类通过Mapper接口操作数据库，查询结果逐层返回，最终渲染成JSP页面或者JSON数据。

这套架构的好处是职责单一、便于扩展。比如后续想接入Redis缓存推荐结果，只需要在Service层加缓存逻辑，不涉及Controller和Mapper的改动；想换成Spring Boot，最顶层只需要改配置和依赖管理，业务代码几乎可以原样移植。

3. 数据库设计与核心实现

3.1 核心表结构设计与关系说明

数据库设计是整个项目的地基，推荐算法好不好用，一半取决于表设计。我先说一个很多新手容易踩的坑：把借阅记录和借阅历史当成同一张表。实际上它们应该分开，当前借阅是用来判断库存和逾期状态的，历史借阅是给推荐算法当数据源用的，混在一起会导致统计逻辑混乱。我的推荐表结构如下：

• 用户表(user)：用户ID、用户名、密码、姓名、院系、借阅证状态、注册时间、兴趣分类。
• 图书表(book)：图书ID、ISBN、书名、作者、出版社、分类ID、库存总数、剩余可借数、封面路径、上架状态。
• 分类表(category)：分类ID、分类名称、父分类ID。
• 借阅记录表(borrow_record)：记录ID、用户ID、图书ID、借书时间、应还时间、实际还书时间、状态（借出/已还/逾期）、续借次数、操作员ID。
• 收藏表(favorite)：收藏ID、用户ID、图书ID、收藏时间、备注。
• 评分表(rate)：评分ID、用户ID、图书ID、评分值（1到5分）、评论内容、创建时间。
• 用户行为日志表(user_behavior)：行为ID、用户ID、图书ID、行为类型（搜索/查看/收藏/借阅/评分）、行为值、创建时间。
• 图书相似度表(book_similarity)：ID、图书A ID、图书B ID、相似度值、计算时间。

图书表和分类表是一对多关系，分类表用自关联实现父子两级分类，比如“计算机”下面是“编程语言”和“数据库”。借阅记录和用户表、图书表是多对一关系。用户行为日志表是推荐算法的核心原料，它需要冗余用户ID、图书ID，因为推荐计算时不会每次都在线去关联查询用户表和图书表，那样太慢了。对于毕设规模完全可以这么设计，这也是考虑到评委要看逻辑清晰度，过度范式化反而让人看不懂。

3.2 推荐引擎的数据流与计算流程

推荐引擎整体分两个阶段：离线计算阶段和在线推荐阶段。离线计算每周跑一次，计算物品相似度矩阵并存入book_similarity表；在线推荐阶段，用户访问首页“为你推荐”板块时，系统实时从相似度表中查出该用户历史高评分图书的相似图书，聚合排序后返回。

这里我用IVFF算法索引来加速相似度矩阵查询，思路类似“先将物品经过粗粒度聚类，再在桶内计算精确相似度”。对于毕设，直接按分类过滤就行——先只把同分类的图书作为候选集，再计算相似度，计算量能缩小一个数量级。这个优化很多人没提，但你可以在答辩时说出来，表明你做过大数据量的思考，很加分。

计算相似度时，我选用的是改进的余弦相似度，公式是：sim(A,B) = (用户对A和B的评分内积) / (A评分向量模长 × B评分向量模长)，并且加入了评分均质化处理：将每个用户对单本书的评分减去该用户所有评分的平均值，这样可以消除用户评分尺度差异（有的人打分偏高，有的人偏低）。在实现时，把用户行为日志中的评分/收藏/借阅行为统一转成5分制分数：借阅=4分，收藏=3.5分，浏览=2分，评分就取原值。这就是把隐式反馈和显式反馈统一量纲的过程，也是推荐系统项目中真正的核心细节。

3.3 借阅全流程的业务实现细节

借阅模块是全流程管理系统的主体，业务规则至少要覆盖这些场景：借书时校验读者证状态、校验图书剩余库存、插入借阅记录、扣减可借数量；还书时计算是否逾期，如果逾期则按天数和罚金单价计算罚款并记录到罚款表，最后更新借阅状态并增加库存；续借时校验借阅记录状态、当前是否逾期、是否超过最大续借次数；预约则是在库存为0时登记预约队列，图书归还时按预约顺序通知用户。

这些操作全部要加事务控制，我举几个典型代码逻辑。借书操作的核心方法逻辑：

@Transactional(rollbackFor = Exception.class) public boolean borrowBook(Integer userId, Integer bookId) { User user = userMapper.selectById(userId); if (user == null || !"正常".equals(user.getStatus())) { throw new BusinessException("读者证状态异常，无法借阅"); } Book book = bookMapper.selectById(bookId); if (book == null || book.getAvailable() <= 0) { throw new BusinessException("图书不存在或已无库存"); } int update = bookMapper.decreaseAvailable(bookId); if (update == 0) { throw new BusinessException("库存扣减失败，请重试"); } BorrowRecord record = new BorrowRecord(); record.setUserId(userId); record.setBookId(bookId); record.setBorrowDate(new Date()); record.setDueDate(DateUtils.addDays(new Date(), 30)); record.setStatus("借出"); borrowRecordMapper.insert(record); return true; }

这里有一个值得学习的细节：decreaseAvailable用的不是先查询再更新，而是直接执行UPDATE book SET available = available - 1 WHERE id = #{bookId} AND available > 0，并检查受影响行数。这是一种乐观锁的做法，能避免并发场景下两个人同时借最后一本书造成超借的问题。这类细节是评委特别注意的，务必体现。

4. 实操部署与推荐模块代码实现

4.1 环境准备与SSM项目搭建

这个项目开发环境我建议统一如下，能避免大量版本兼容问题：

搭建SSM项目时，Maven的pom.xml是最容易出错的点。核心依赖有：spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jstl、jackson-databind。注意spring和mybatis版本要互相兼容，我用的组合是Spring 5.3.x + MyBatis 3.5.x + mybatis-spring 2.0.x，这个组合在大多数环境测试稳定。

SSM整合特别注意一点：Spring容器只扫描Service和Dao，SpringMVC容器只扫描Controller，两者不要冲突。如果SpringMVC把Service也扫进去了，事务注解会失效，这是SSM新手最常犯的错误之一。正确配置是在SpringMVC配置文件中加<context:component-scan base-package="com.example.controller"/>并在Spring配置文件中写<context:component-scan base-package="com.example.service,com.example.dao"/>。

数据库连接池我用的Druid，配置监控页面通过 DruidStatViewServlet 开启。虽然毕设不要求很专业的运维监控，但Druid的SQL执行统计面板能帮我快速定位慢SQL，比如借阅历史查询该怎么加索引，都是通过它看到的，对答辩也有加分效果。

4.2 ItemCF推荐模块核心代码实现

推荐引擎的代码是整个项目的灵魂，我提供一个可以直接改用的ItemCF实现思路。注意这里不做全量百万级数据的高性能优化，而是以业务闭环完整、逻辑清晰为首要目标。推荐服务接口设计如下：

public interface RecommendService { List<Book> recommendBooksByUser(Integer userId, int topN); void computeBookSimilarity(); }

computeBookSimilarity方法离线计算图书相似度矩阵，核心逻辑是从用户行为日志中提取所有用户的行为记录，构建“用户-评分”映射，再两两计算图书相似度并存储到book_similarity表。关键代码如下：

public void computeBookSimilarity() { List<UserBehavior> behaviors = userBehaviorMapper.selectAll(); Map<Integer, Map<Integer, Double>> userRatings = new HashMap<>(); for (UserBehavior behavior : behaviors) { double score = parseBehaviorScore(behavior.getBehaviorType()); userRatings .computeIfAbsent(behavior.getUserId(), k -> new HashMap<>()) .put(behavior.getBookId(), score); } Map<Integer, List<Integer>> userBooks = new HashMap<>(); for (Map.Entry<Integer, Map<Integer, Double>> entry : userRatings.entrySet()) { userBooks.put(entry.getKey(), new ArrayList<>(entry.getValue().keySet())); } // 统计同现次数 Map<String, Integer> coCount = new HashMap<>(); Map<Integer, Double> bookScoreSum = new HashMap<>(); for (Map<Integer, Double> ratings : userRatings.values()) { List<Integer> ids = new ArrayList<>(ratings.keySet()); for (int i = 0; i < ids.size(); i++) { for (int j = i + 1; j < ids.size(); j++) { int a = ids.get(i); int b = ids.get(j); coCount.merge(a + "_" + b, 1, Integer::sum); coCount.merge(b + "_" + a, 1, Integer::sum); } } } // 计算余弦相似度并写入表 // 实际代码需要遍历每本书与其他书的同现次数、模长，按公式计算结果 // 低于0.2的相似度可以丢弃，避免返回太多噪声数据 }

这里补充几个容易写错的点。parseBehaviorScore将行为统一转分值的逻辑必须保持一致，评分是用户显式表达，借阅是强信号，浏览是最弱信号，别把权重搞反；相似度矩阵只保存大于阈值的结果，不然book_similarity表会膨胀到无意义，存储效率和查询效率都会拖垮；每次计算完成，先清空旧表再批量插入，保证矩阵始终是当前数据状态的快照。这一块建议用日志输出一句统计信息，比如相似度计算耗时多少、生成多少对相似关系，答辩时拿得出数据。

4.3 在线推荐查询实现与前端联动

在线推荐是用户能直观感受到的部分，首页“为你推荐”板块的查询逻辑分三步走：第一步查用户是否有历史行为，没有就返回热门榜；第二步查该用户最近评分/借阅的最新的若干本书；第三步把这基本书作为种子，查book_similarity表中和它们相似度最高的候选图书，按相似度降序排列，同时排除用户已经借过或收藏过的图书，最后取Top N返回。

排除已读图书这个步骤很多人忽略，但实际必须做。不然用户刚借过《深入理解Java虚拟机》，首页还在推荐同一本书，体验极差。这一步放在SQL里解决，一条NOT IN子查询就搞定，不用在内存里做二次过滤。前端拿到推荐列表后用Bootstrap卡片组件渲染，每本推荐书都显示封面缩略图、书名、作者、相似度标签，同时在卡片右下角放一个“不感兴趣”按钮，点击后反馈到行为日志表，下一步重算推荐时就可以降低该图书的权重，这就形成一个透明的反馈调节闭环。

热门榜的冷启动逻辑也要单独实现，SQL类似：

SELECT b.id, b.name, b.author, COUNT(br.id) AS borrow_count FROM book b LEFT JOIN borrow_record br ON b.id = br.book_id WHERE b.status = 1 AND br.borrow_date >= DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY b.id ORDER BY borrow_count DESC LIMIT #{topN}

注意这里使用了LEFT JOIN，确保没有借阅记录的新书也会出现在结果里（虽然计数为0），而不是被排除掉。SQL里宁可多写几个条件也别写错JOIN方向，这是我在开发中反复踩到的坑。

4.4 管理后台的推荐策略配置

管理后台的推荐策略配置页面，可以支持动态调整推荐算法开关、推荐数量、相似度阈值、热门榜统计周期等参数。这些参数全部存在系统配置表里，后端提供queryConfig和updateConfig接口，前端用表单提交即可。把推荐参数做成可配置的意义在于：答辩时可以现场演示“把相似度阈值从0.3调到0.5，首页推荐结果立刻变化”，这个动态效果给人的冲击力远大于截图，也侧面证明推荐引擎是真实可运行、参数可控的。

5. 常见问题与排查技巧

5.1 SSM整合高频报错与修复方法

这部分我直接列一个排查表，全是实际项目中容易踩的坑：

SSM的报错90%都集中在包扫描和MyBatis映射这些静态配置上，排查思路是先看启动日志第一行报错属于哪个环节，是Spring容器初始化还是SpringMVC初始化，还是MyBatis映射注册阶段。按这个顺序定位，比对着报错信息百度有效率得多。

5.2 推荐效果不理想怎么办

推荐系统做得再完备，也经常面临“推荐结果感觉不够准”的尴尬局面。我总结最常见的四个原因和对应的调整方法。

数据稀疏是首要问题，推荐引擎的核心是用户行为数据，如果库里只有十个用户、几十条行为记录，任何算法都算不出好东西。解决办法有两种：一是批量生成模拟数据，写一个工具类自动随机生成几百个注册用户、上千条浏览借阅行为，保证算法有东西可算；二是在答辩时清晰说明系统在真实使用中会随数据积累而效果越来越好，这本身就是协同过滤的特性。但最好还是把模拟数据准备好，现场演示推荐列表不断变化，比口头解释有说服力。

评分权重不合理是第二个常见问题。我前面提到把借阅和浏览统一转5分制，如果你给的分数比例不对，比如浏览算5分、借阅算5分，那信号强的行为就被噪声淹没了。建议借阅=5分、收藏=4分、评分原位、浏览=1分，拉开差距，推荐结果会更贴近真实兴趣。

相似度阈值设置太死也会出问题。阈值太高，候选集合小到没结果；阈值太低，推荐列表全是低相关噪声书。我一般先用日志打印不同阈值下的候选集数量，再定一个合理值，比如0.3到0.5之间。这类调参过程写进论文里，就是一段很有说服力的实验内容。

还有个问题是推荐结果单一化，比如用户看了一本Java书，推荐的全是Java书，没有跨类目的惊喜。可以加一个多样性控制，推荐列表里最多有X%来自同一分类，其他从不同分类中挑相关性略低的补位。这个策略很多教程不会写，属于增值细节，答辩提出来会很亮眼。

5.3 答辩容易深挖的问题与应答思路

答辩环节老师的时间和注意力有限，通常只会在推荐算法和项目架构上做文章。我结合自己指导学生答辩的经验，把高频问题整理成一个应答小抄：

问题一：协同过滤和基于内容的推荐有什么区别？答：协同过滤只用用户行为数据，不需要对内容本身建模；基于内容需要提取图书属性（作者、分类、关键词）构建画像。协同过滤能发现跨内容类别的潜在兴趣，但面临冷启动；基于内容对冷启动友好，但推荐结果容易同质化。我的系统融合了两种思路，先用分类标签冷启动，再切换协同过滤。

问题二：为什么选择ItemCF而不是UserCF？答：ItemCF适合图书这类物品数量稳定、用户兴趣相对持久的场景，可以离线预先计算相似度矩阵，在线推荐速度快；UserCF适合新闻、短视频这种物品更新极快、用户兴趣瞬时变化的场景。图书馆典型场景下ItemCF更合理，而且我能从数据规模上论证。

问题三：推荐结果怎么评估准不准？答：我用了离线评估指标，把行为日志按8:2拆成训练集和测试集，用召回率和准确率评价推荐列表，同时统计预测评分和实际评分的误差。另外系统记录了推荐曝光后用户点击和借阅的转化数据，用于线上效果验证。

这几个回答只要提前组织了思路，现场就不慌。最难答的问题往往是“你的系统有什么改进空间”，这其实是送分题，只要提前想好两三个点，比如引入协同过滤与内容推荐的融合排序、用Redis缓存相似度矩阵提升响应速度、加入推荐解释功能“因为你看过XX，所以推荐YY”，就能让老师觉得你确实做了深入思考。

5.4 项目打包与现场展示的注意事项

毕设最终要在答辩现场跑起来，这是最容易翻车的地方。提前两个月就要把部署流程固定下来：本机使用Tomcat部署war包，数据库初始化脚本必须能一键执行。我习惯把所有建表语句和初始数据都放在database/init.sql里，并且保证在一个全新的MySQL实例上执行不报错。演示用的浏览器建议用Chrome的无痕模式，避免缓存和插件干扰页面效果。

现场展示的演示脚本也值得提前写下来：第一步展示系统登录与管理员后台的图书管理增删改查；第二步展示一个新注册用户的冷启动推荐（热门榜）；第三步登录一个有历史行为的演示账号，展示首页ItemCF推荐；第四步演示用户收藏和评分后立即刷新推荐列表看到变化；最后打开Druid监控面板展示SQL统计，证明系统运行状态良好。整个演示控制在五分钟以内，节奏由你控制，比临时点哪里都点不到强得多。

6. 最终的经验沉淀与可扩展方向

这个项目做完之后，我个人最大的体会是：毕设题目里“个性化”三个字不是装饰，而是系统的地基。很多同学的失败点不是算法不会写，而是把推荐模块孤立在主体系统之外，数据和功能模块完全割裂。实际上个性化的真正价值在于打通全链路数据：每一次搜索、每一次翻页、每一次借还，最终都在帮助系统更懂读者。当你把这种“数据回流”的思想做进设计里，你的系统才不是一个作业，而是一个符合业务逻辑的真实产品。

如果你做完之后还有余力扩展，我建议优先尝试三个方向。一个是在推荐结果里加入“推荐理由”说明，比如“因为您借阅了《Java编程思想》，所以推荐《Effective Java》”，这种可解释性在真实推荐系统里非常关键。二是把相似度计算从MySQL搬到内存缓存里，用Redis的SortedSet存储各图书的相似图书Top N，在线推荐从毫秒级提升到亚毫秒级。三是引入定时任务，比如每天凌晨重新全量更新一次推荐矩阵，并记录数据更新日志，让推荐结果在长期使用中逐渐逼近读者真实兴趣。

最后分享一个小建议：论文和项目代码里一定要保留你做过实验的数据，比如同样的数据集下，UserCF和ItemCF各自的推荐准确率、覆盖率是多少；相似度阈值0.3和0.5对推荐列表的影响。这些真实数据会让你的答辩说服力大增，特别是在你说出“我做了一个控制变量的对比实验”这句话时，老师的眼睛是会亮起来的。