简介这套基于知识图谱的电影推荐系统源码源自高分毕业设计评审98分面向计算机专业准备毕设、课程设计或项目实战的学生提供了一套可运行、易扩展的知识图谱推荐完整项目。资源包共55个文件主体为43个Python脚本用于数据爬取、知识图谱构建与推荐算法另有4个TXT数据文件、4个CFG配置文件、3个MD说明文档和1个SQL数据库脚本压缩包整体仅890KB目录结构清晰。项目内容涵盖百度百科、互动百科及豆瓣数据源的爬虫采集电影信息处理与评分计算并基于知识图谱完成推荐流程同时附有README等说明材料方便快速上手与二次开发。目前已有155人学习下载适合作为毕业设计参考、课程设计模板也是学习知识图谱与推荐系统结合实践的理想样例。1. 每年毕设都做电影推荐为什么这次要加知识图谱每年毕业设计电影推荐系统都是热门选题但多数版本只是把协同过滤跑一遍答辩时老师问“亮点在哪”只能回答“调过参”。基于知识图谱的电影推荐系统是另一种做法把用户、电影、演员、导演、类型建成图里的节点和关系推荐时不再只看“和你相似的人”而是直接问图数据库“你看过的电影和候选电影之间隔着几跳、跳的是什么关系”答案本身就能变成推荐理由。这套 Python 毕业设计源码要解决的正是这个问题——知识图谱怎么建、推荐路径怎么抽、Web 壳怎么包以及这类项目里反复翻车的几个地方。适合想给推荐系统做出区分度、让答辩有东西可讲的同学。2. 先把知识图谱建起来实体关系设计、数据清洗与入库代码2.1 实体和关系怎么定让推荐路径先于属性知识图谱的基本单位是三元组头实体、关系、尾实体。建图时不能像设计关系型数据库那样先列字段而是要反过来问一句我将来想在图上走什么样的路这句话决定了建模的全部细节。对电影推荐来说最常见的用户行为路径是三条用户看过的电影通过“类型”关联到同题材电影通过“演员”关联到该演员参演的其他电影通过“导演”关联到同一导演的其他作品。所以这个项目里至少要准备五类实体和五类关系实体包括用户、电影、演员、导演、类型关系包括看过、评分、出演、执导、属于某类型。具体建模如下表实体关键属性说明Useruid, age, gender, occupation来自 MovieLens 的用户表Moviemid, title, year电影节点year 用于按年份过滤Actorname演员以名字做唯一标识Directorname导演以名字做唯一标识Genrename电影的题材分类关系侧就五条User -WATCHED- Movie、User -RATED- Movie、Movie -BELONGS_TO- Genre、Movie -ACTED_IN- Actor、Movie -DIRECTED- Director。这里有个常见误设计很多同学会把类型做成 Movie 节点上的一个字符串属性比如“Action|Adventure”用 Cypher 也能查到但走不了“电影-类型-电影”的关系路径元路径推荐就无从谈起。建表的原则很简单每一种关系都要能用“用户为什么该看这部电影”这句话解释解释不通的边先不建。确定了实体和关系下一步是把原始数据整理成能够入图的形状。这一步做得越干净后面 Cypher 查询和推荐逻辑越省事。2.2 数据清洗MovieLens 100K 的三个文件和类型列展开这个项目最常用的公开数据是 MovieLens 100K它包含三个文件u.user 是用户档案u.item 是电影条目u.data 是评分记录。第一次读这些文件时最容易踩的坑是编码u.item 里混着大量带特殊字符的电影名用 UTF-8 直接读会抛 UnicodeDecodeError所以读取时要显式指定 latin-1 编码。下面这段是标准的读取代码import pandas as pd # 用户文件uid, age, gender, occupation, zip users pd.read_csv(ml-100k/u.user, sep|, encodinglatin-1, names[uid, age, gender, occupation, zip]) # 电影文件mid, title, release_date, video_release_date, imdb_url, 19个类型标记列 movies pd.read_csv(ml-100k/u.item, sep|, encodinglatin-1, names[mid, title, release_date, video_release_date, imdb_url, unknown, Action, Adventure, Animation, Children, Comedy, Crime, Documentary, Drama, Fantasy, Film-Noir, Horror, Musical, Mystery, Romance, Sci-Fi, Thriller, War, Western]) # 评分文件uid, mid, rating, timestamp ratings pd.read_csv(ml-100k/u.data, sep\t, encodinglatin-1, names[uid, mid, rating, timestamp])读取逻辑里有两个参数值得说明。sep必须严格对应用户文件里的竖线分隔和评分文件里的制表符分隔混用会导致列数对不上。encodinglatin-1是因为 MovieLens 原始文件是 ISO-8859-1 编码改成 UTF-8 会在读取阶段就报错这不是 pandas 的 bug而是文件本身的编码属性。接下来是整份源码里最关键的一步数据变换u.item 里那 19 个类型列是 0/1 标记的宽表而图数据库要的是“电影-类型”这样的关系需要通过melt把宽表转成长表一行数据变成一条潜在关系genre_cols [Action, Adventure, Animation, Children, Comedy, Crime, Documentary, Drama, Fantasy, Film-Noir, Horror, Musical, Mystery, Romance, Sci-Fi, Thriller, War, Western] # 宽表转长表每个 (电影, 类型) 组合一行 movie_genres movies.loc[:, [mid] genre_cols].melt( id_varsmid, var_namegenre, value_nameflag) # 只保留 flag 为 1 的标记删掉无用的 flag 列 movie_genres movie_genres[movie_genres[flag] 1].drop(columnsflag) movie_genres.head()melt是这段代码的核心id_vars指定保留的主键列var_name是堆叠后新列的名字原来的 19 个类型列被折叠成两列一列是类型名一列是 0/1 标记。过滤时保留 flag 为 1 的行这就是“这部科幻电影属于 Sci-Fi 这个类型”的关系三元组。这一步完成后movie_genres的每一行都对应一条Movie -BELONGS_TO- Genre候选记录。MovieLens 100K 本身没有演员和导演数据这个缺口需要自己补。常见做法是准备一张 movie_cast.csv字段就是电影 id、人名、职业从 IMDB 的公开接口整理或者自己手工整理前 50 部电影都行。先跑通类型路径再补演员导演路径这是把项目拆小、避免一次导入失败到处排查的最好方式。2.3 写入 Neo4j约束、MERGE 与批量事务图数据入库我一般推荐直接用官方 driver而不是 py2neo。py2neo 在 Neo4j 4.x 时代还能用到 5.x 之后连接和事务经常出问题而且项目已经停止维护不如用官方驱动一劳永逸。下面是连接数据库并写入电影节点的最小代码from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, your_password)) # 写节点之前先给唯一字段建约束防止重复导入 with driver.session() as session: session.run(CREATE CONSTRAINT IF NOT EXISTS FOR (m:Movie) REQUIRE m.mid IS UNIQUE) session.run(CREATE CONSTRAINT IF NOT EXISTS FOR (g:Genre) REQUIRE g.name IS UNIQUE) def create_movie(tx, mid, title, year): tx.run( MERGE (m:Movie {mid: $mid}) SET m.title $title, m.year $year , midmid, titletitle, yearyear) with driver.session() as session: for row in movies.head(200).itertuples(): # 先导入前200部验证通路 year str(row.release_date)[-4:] if pd.notna(row.release_date) else session.execute_write(create_movie, str(row.mid), row.title, year)这段代码有两个设计点很关键。第一是MERGE而不是CREATEMERGE的做法是“有这个节点就匹配没有才创建”配合上面建的唯一约束可以保证重复运行时不会产生重复节点CREATE则无条件新建跑两次脚本节点就翻倍。第二是参数化查询$mid、$title这些占位符由 driver 做转义如果图省事用 f-string 直接把电影名拼进 Cypher遇到带引号的电影名会直接报语法错误这是后面避坑章节还会展开讲的问题。电影节点和类型节点建好之后再写入电影与类型之间的关系。关系写入同样走 MERGE避免重复边def create_belongs_to(tx, mid, genre): tx.run( MATCH (m:Movie {mid: $mid}), (g:Genre {name: $genre}) MERGE (m)-[:BELONGS_TO]-(g) , midmid, genregenre) with driver.session() as session: for row in movie_genres.itertuples(): session.execute_write(create_belongs_to, str(row.mid), row.genre)这里需要注意关系写入依赖 Movie 和 Genre 节点已经存在所以必须按“先节点、后关系”的顺序执行。execute_write会自动管理事务每批写操作在一个事务里写着写着如果某一部电影的 genre 值是空的MATCH匹配不到节点该条会静默跳过不会导致整批失败这也是数据容错的一部分。写完之后最好做一次全库盘点确认节点和边都建对了MATCH (n) RETURN labels(n) AS label, count(*) AS cnt ORDER BY cnt DESC这个查询会按实体类型返回数量统计如果 Movie 只有 200 部而 Genre 却有 1000 条记录说明类型表展开出了问题需要回头检查 melt 那一步。首次入库先跑前 200 部电影是刻意的图打通之后再全量导入避免一次写几万条数据时错误难以定位。3. 让推荐有理由元路径查询、评分聚合与权重调节3.1 为什么选元路径图嵌入和 GNN 在毕设里容易翻车知识图谱推荐在论文里常见三个技术路线基于元路径的相似度计算、基于图嵌入TransE 这类把实体和关系映射成向量的方法、基于图神经网络GNN/GCN 端到端学习。毕设项目最应该选的是元路径原因很朴素它能解释而且不需要训练。图嵌入和 GNN 看起来更“高级”但它们在小数据集上经常翻车。MovieLens 100K 总共才十万条评分用来训练 TransE 容易欠拟合GNN 则需要反复调参、处理邻居采样和过平滑问题。更要命的是答辩场景老师问“为什么推荐这部”嵌入向量给不出一个直观理由你只能说“模型学的”这在本科毕设里是很吃亏的回答。基于元路径的做法把推荐依据直接落在图结构上推荐结果可以写成“因为你喜欢科幻类型”或“因为你和这部电影共享同一个导演”一句人话就能讲清楚。元路径本身就是一个关系序列用来定义两个节点之间“怎么算相似”。比如“电影–类型–电影”这条元路径的意思是两部电影属于同一个类型就认为它们相似共享的类型越多相似度越高。把用户节点放在路径最前面就变成了完整推荐逻辑用户看过的电影沿着类型、演员、导演三条路径向外找候选电影统计候选电影与历史片单的重合次数重合次数就是推荐分数。这个思路在学术上叫 HeteRec 那一类方法但在毕设里不需要实现那么复杂Cypher 查询可以直接完成核心逻辑。三条路径当中类型的语义最宽泛、候选最多演员居中导演的筛选性最强。这个语义差异直接影响后面的权重设置也会影响查询语句的写法。3.2 把“用户-电影-类型-电影”翻译成 Cypher先看类型路径也就是“用户看过某部电影这部电影属于某类型该类型下还有哪些别的电影”MATCH (u:User {uid: $uid})-[:WATCHED]-(m:Movie)-[:BELONGS_TO]-(g:Genre)-[:BELONGS_TO]-(cand:Movie) WHERE cand.mid m.mid AND NOT (u)-[:WATCHED]-(cand) RETURN cand.mid AS mid, cand.title AS title, count(DISTINCT m) AS cnt ORDER BY cnt DESC LIMIT 20这条查询的模式分三段u是当前用户m是用户看过的电影g是这些电影的类型cand是通过类型关联到的候选电影。WHERE里的两个条件必须同时存在cand.mid m.mid排除候选电影和已看电影是同一部的情况NOT (u)-[:WATCHED]-(cand)排除用户已经看过的电影否则推荐列表里全是看过的老片前端演示时一眼就露馅。count(DISTINCT m)是这条查询的核心它统计的是“当前候选电影和你历史片单里多少部电影共享类型”。比如用户看过《玩具总动员》和《怪兽电力公司》这两部都属于 Animation候选电影《海底总动员》也属于 Animation那这条路径给《海底总动员》的计数值就是 2。共享得越多说明候选电影越贴合用户的类型偏好。演员路径和导演路径的写法完全对称只是把中间的关系节点换掉MATCH (u:User {uid:$uid})-[:WATCHED]-(m:Movie)-[:ACTED_IN]-(a:Actor)-[:ACTED_IN]-(cand:Movie) WHERE cand.mid m.mid AND NOT (u)-[:WATCHED]-(cand) RETURN cand.mid AS mid, cand.title AS title, count(DISTINCT m) AS cnt ORDER BY cnt DESC LIMIT 20导演路径就把ACTED_IN换成DIRECTEDActor换成Director。这三条查询刻意不写成变长路径[*1..3]原因是变长路径的搜索空间指数级膨胀一旦图里数据量上万单次查询就要好几秒后面避坑章节会专门讲这个问题。固定三段路径的语义也最清晰每一跳都能用一句人话解释清楚。3.3 三条路径的分数怎么融合权重与 Top-K三条路径单独跑出来的是三组候选分数最终推荐列表要把它们合并成一个总分。直接做简单求和的问题在于类型路径候选太多把演员和导演的信号淹没了所以合理的做法是给每条路径一个权重。下面这段代码把三条查询的结果在 Python 里聚合from collections import defaultdict def recommend_for_user(driver, uid, k20, weightNone): if weight is None: weight {genre: 1.0, actor: 1.2, director: 1.5} PATHS { genre: MATCH (u:User {uid:$uid})-[:WATCHED]-(m:Movie)-[:BELONGS_TO]-(g:Genre)-[:BELONGS_TO]-(cand:Movie) WHERE cand.mid m.mid AND NOT (u)-[:WATCHED]-(cand) RETURN cand.mid AS mid, cand.title AS title, count(DISTINCT m) AS cnt , actor: MATCH (u:User {uid:$uid})-[:WATCHED]-(m:Movie)-[:ACTED_IN]-(a:Actor)-[:ACTED_IN]-(cand:Movie) WHERE cand.mid m.mid AND NOT (u)-[:WATCHED]-(cand) RETURN cand.mid AS mid, cand.title AS title, count(DISTINCT m) AS cnt , director: MATCH (u:User {uid:$uid})-[:WATCHED]-(m:Movie)-[:DIRECTED]-(d:Director)-[:DIRECTED]-(cand:Movie) WHERE cand.mid m.mid AND NOT (u)-[:WATCHED]-(cand) RETURN cand.mid AS mid, cand.title AS title, count(DISTINCT m) AS cnt } scores defaultdict(float) titles {} with driver.session() as session: for path, cypher in PATHS.items(): results session.run(cypher, uiduid) for rec in results: scores[rec[mid]] rec[cnt] * weight[path] titles[rec[mid]] rec[title] ranked sorted(scores.items(), keylambda x: x[1], reverseTrue)[:k] return [{mid: mid, title: titles[mid], score: round(score, 2)} for mid, score in ranked]权重参数是最值得解释的地方。导演路径权重最高因为导演的平均作品数远少于类型下的电影数两个电影共享同一个导演是更强的信号类型路径权重最低因为“都喜欢科幻”覆盖的电影面太宽区分度弱演员路径居中。这个权重不是拍脑袋定的是根据数据分布调的——拿一小批用户跑一遍看每条路径给出来的候选电影相关性再调整比例。k一般取 10 到 20超过 20 条用户根本划不完答辩演示也显得冗长。整个推荐模块到这里已经能跑通用户输入 id函数返回一个带分数和标题的列表。但只有函数还不够毕业设计要拿出一个能点的网页下一步是包一层 Flask 接口。4. 给它包一层能答辩的 Web 壳Flask 接口与前端交互4.1 接口别只写推荐历史查询和健康检查一起做推荐系统不是只有一个推荐接口就完了。答辩时老师会先点开页面看看界面再随便输入几个用户 id 看推荐结果后端最少要提供三个接口推荐接口、历史记录接口、健康检查接口。历史记录接口的存在感很低但它能在前端显示“你看过这些”让推荐结果看起来有对照对答辩演示帮助很大。下面是最简版本的 Flask 接口代码直接复用上一章的recommend_for_user函数from flask import Flask, jsonify, request from recommend import recommend_for_user app Flask(__name__) app.json.ensure_ascii False # 让中文电影名别变成 \uXXXX 转义 app.route(/api/recommend/int:uid) def recommend_api(uid): k request.args.get(k, default20, typeint) items recommend_for_user(driver, uid, kk) return jsonify({code: 0, uid: uid, items: items}) app.route(/api/history/int:uid) def history_api(uid): with driver.session() as session: rows session.run( MATCH (u:User {uid:$uid})-[:WATCHED]-(m:Movie) RETURN m.title AS title, m.year AS year , uiduid) history [{title: r[title], year: r[year]} for r in rows] return jsonify({code: 0, history: history}) app.route(/health) def health(): return jsonify({status: ok})这里有个很小的坑Flask 2.x 里app.json.ensure_ascii False必须设置否则返回给前端的 JSON 里中文会变成\u6d77\u5c1a这种转义序列界面显示出来是一串乱码。很多同学在浏览器里看到\u开头的内容第一反应是编码问题实际上只是 Flask 的 JSON 序列化默认转义了非 ASCII 字符。去掉转义后前端直接拿item.title显示中文即可。k参数通过查询串传入调用示例是/api/recommend/10?k10默认值设成 20。uid在路由里用了int转换器如果传了非数字会自动返回 404比在函数内部做类型判断省事。4.2 前端模板一个输入框加一段 fetch 就够前端建议不要引入 Vue 或 React毕设项目的加分项在推荐算法和图数据库不在前端框架。一个纯 HTML 页面配上原生 fetch 就能把系统演示完整。模板里只需要三样东西输入用户 id 的输入框、触发推荐的按钮、渲染推荐列表的空列表节点body input iduid placeholder输入用户ID比如 10 value10 / button onclickloadRecommend()换一批推荐/button h3推荐列表/h3 ul idrec-list/ul script async function loadRecommend() { const uid document.getElementById(uid).value; const resp await fetch(/api/recommend/${uid}?k10); const data await resp.json(); const list document.getElementById(rec-list); list.innerHTML data.items .map(item li${item.score} 分 - ${item.title}/li) .join(); } /script /body这段模板刻意把逻辑压到最简单抓取输入框的值、请求接口、把返回数组拼成 li 标签插入列表。item.score是上一章算出来的融合分数前端直接展示出来老师能看到推荐结果不是随机的而是有排序依据的。如果要把脚本和模板分开就再把 fetch 逻辑放进单独的 app.js但这个小项目里合并在一起反而好维护。需要注意一点模板渲染没有对空列表做兜底。新用户没有任何观看历史时recommend_for_user返回空数组页面会只显示一个标题。毕业设计演示现场出现空页面很尴尬所以建议加一行判断列表为空时显示“这个用户还没有评分记录”冷启动的兜底方案在下一章给出完整写法。4.3 项目目录、依赖清单与启动顺序整套源码的文件组织建议按职责拆成五个文件不要写成一个几千行的单文件。下面这个目录结构是这类项目里最常见、也最利于答辩展示的组织方式movie-reco-kg/ ├── data/ # MovieLens 原数据、movie_cast.csv ├── data_process.py # 读取、清洗、宽表转长表 ├── graph_build.py # 连接 Neo4j写入节点与关系 ├── recommend.py # 元路径推荐、权重融合 ├── app.py # Flask 接口 ├── templates/ │ └── index.html # 前端页面 └── requirements.txt启动顺序必须是固定的先启动 Neo4j 服务再依次执行数据清洗、建图脚本、Web 服务。如果跳过了建图脚本直接起 Flask接口虽然能通但每次查询都匹配不到用户节点返回的全是空列表。Neo4j 的启动方式看操作系统Windows 下执行neo4j.bat consoleUbuntu 下执行neo4j console或者用 Docker 起一个容器端口映射到 7687 给 bolt 协议用。三个服务的启动命令如下pip install flask neo4j pandas python data_process.py # 生成清洗后的长表 python graph_build.py # 建图跑完出现约束创建成功日志 python app.py # 起 Flask默认 5000 端口服务起来后先用一条 curl 验证接口通没通再打开浏览器这两步分开做能少走弯路curl http://127.0.0.1:5000/api/recommend/10?k10返回结果是带code: 0和items数组的 JSON就说明从数据清洗到建图再到推荐算法的整条链路已经打通。这一步如果报错优先级最高的检查对象是 Neo4j 里的数据是否真有 uid 为 10 的WATCHED关系而不是 Flask 代码本身。5. 避坑手册图建模到 Web 上线的五个高频事故5.1 特殊字符和中文入库报错现象运行graph_build.py时电影名里含有引号、斜杠或拉美字符入库脚本直接抛出语法错误有时报错信息指向 Cypher 字符串的换行位置完全定位不到真实原因。原因用 f-string 把电影名拼进 Cypher 语句。比如fMERGE (m:Movie {{mid:{mid}}}) SET m.title{title}电影名里一旦出现单引号Cypher 字符串就被提前截断语法直接崩溃。这是写图数据库代码最常犯的错和 SQL 注入的道理一模一样。解决所有 Cypher 查询一律用参数化写法把变量通过tx.run(query, midmid, titletitle)传进去driver 负责转义不要手动拼字符串。另外读取 u.item 时必须用encodinglatin-1这个文件不是 UTF-8 编码强行用 UTF-8 读会在 import 阶段就失败。5.2 py2neo 版本不匹配连接直接失败现象代码里from py2neo import Graph导入正常但实例化Graph(bolt://localhost:7687)时长期卡住最后报Unable to connect to any of the hosts。原因py2neo 这个库在 2021 年后基本停止维护对 Neo4j 5.x 的认证和协议支持不完整。很多教程还停留在 py2neo 写法新手照着抄就翻车实际是库和数据库版本对不上。解决直接用官方neo4j驱动的GraphDatabase.driver第八章写的入库代码就是标准写法替换成本很低。如果坚持用 py2neo就把 Neo4j 版本锁在 4.4 以下但这意味着新特性享受不到不再推荐。5.3 查询从毫秒拖到秒级变长路径不加约束现象推荐接口刚跑通时很快数据量增加到几千部电影后单个用户请求要两三秒才返回再往上加数据直接超时。原因查询里写了[*1..4]这种可变长度路径。图数据库执行变长路径匹配时搜索空间随深度指数膨胀一旦某个节点的度很高比如一个热门演员连着几百部电影中间结果瞬间爆炸。解决路径全部改写成固定三段式如(u)-[:WATCHED]-(m)-[:BELONGS_TO]-(g)-[:BELONGS_TO]-(cand)明确每一跳的关系类型不搞模糊匹配。同时在 Cypher 末尾加LIMIT 20让数据库早停。定位慢查询时在 Cypher 前面加EXPLAIN会看到每一步的行数估算哪一步数据量暴涨一目了然。5.4 重复导入实体和边数直接翻倍现象建图脚本跑了两遍再查节点统计Movie 节点数量翻了一倍WATCHED关系更是成倍增长推荐结果出现大量重复电影。原因写入用的是CREATE。CREATE无条件新建节点不管图里是否已存在相同实体多跑一次就多一份数据。很多人以为“跑之前先清库就行”但清库本身也容易遗漏某个位置的实体类型。解决节点和关系统一用MERGE配合建图前执行的唯一约束CREATE CONSTRAINT ... IS UNIQUE让图数据库从机制上保证不重复。如果已经写脏了清库重导是最快的后悔药MATCH (n) DETACH DELETE n不要手动一条条删。5.5 新用户返回空列表冷启动兜底现象换一个新注册的用户 id前端页面空空如也老师以为是系统崩了。原因知识图谱推荐本质是基于历史的用户没有任何WATCHED关系就找不到任何元路径推荐分数为空返回[]。这是协同过滤类方法共同的缺陷知识图谱只是把历史行为换成了图上跳步解决不了从零开始的问题。解决接口层做兜底推荐结果为空时退回热度推荐按平均评分排序返回 Top10保证页面永远有内容。代码是在recommend_for_user返回空列表后追加一段if not items: with driver.session() as session: hot session.run( MATCH (u:User)-[r:RATED]-(m:Movie) RETURN m.title AS title, avg(r.rating) AS avg_rating ORDER BY avg_rating DESC, count(r) DESC LIMIT 10 ) items [{title: r[title], score: round(r[avg_rating], 2)} for r in hot]6. 答辩前最值得补的数字留一法评测与基线对比6.1 留一法每个用户最后一条评分当测试集推荐系统做得再花哨答辩现场老师问一句“推荐质量怎么证明”答不上来前面的工作都会打折扣。补评测最标准的做法是留一法对每个用户按时间排序后把最后一条评分单独拎出来当测试集其余评分训练建图然后看系统能不能在 TopK 推荐里找回这一条电影。HitRate 就是“测试电影出现在推荐列表里的比例”这个数字直接说明推荐算法到底有没有用。下面是完整的留一法评测代码直接复用前面已经建好的图和推荐函数import pandas as pd # 评分按时间排序每个用户最后一条评分作为测试集 ratings_sorted ratings.sort_values(timestamp) test_set ratings_sorted.groupby(uid).tail(1) train_set ratings_sorted.drop(test_set.index) # 为了严谨应按 train_set 重新建图这里省略重复建库步骤 hits 0 for uid in test_set[uid].unique(): topk recommend_for_user(driver, int(uid), k10) hit_mids {item[mid] for item in topk} true_mid test_set[test_set[uid] uid][mid].iloc[0] if str(true_mid) in hit_mids: hits 1 hit_rate hits / len(test_set[uid].unique()) print(fHitRate10: {hit_rate:.3f})注意严格做评测时要用 train_set 重新建一次图把测试集里的那条评分边删掉否则它已经出现在用户的历史里推荐时会被NOT (u)-[:WATCHED]-(cand)直接过滤掉命中率虚低。这段话的代码里我用了省略标记真实项目里建完 train_set 后要重新走一遍 graph_build这是一个容易被忽略的细节。6.2 和 ItemCF 摆在一起别只给人看界面评测的价值在于对比。只报一个 HitRate 数字老师不知道它高还是低拿基础的协同过滤做基线差距就能说明问题。实现一个最简单的 ItemCF 函数做同样流程的留一法评测表格一摆效果立刻直观。方法HitRate10能不能给出推荐理由知识图谱元路径实测为准每条推荐对应类型/演员/导演路径协同过滤 ItemCF实测为准只能解释为“相似用户打分高”这两张对比表就是答辩时的核心弹药。知识图谱方案在数据稀疏时往往比 ItemCF 高几个点更关键的是它每条推荐都带路径依据老师接着问“为什么推荐这部”你可以直接展示 Cypher 查询的中间过程。我当时做这套系统时最吃亏的就是一开始没跑评测觉得效果“肉眼可见”结果被问到数字哑口无言后来补了留一法才兜住。先跑通推荐、补齐测评数字、再美化前端这个顺序才是毕设项目性价比最高的推进路径希望帮到你。本文还有配套的精品资源点击获取