毕设选题：基于知识图谱的中医药方剂智能推荐系统设计与实现
输入“发热、咳嗽、咽痛 3 天”，系统 1.2 秒推荐麻杏石甘汤，还把君臣佐使、配伍禁忌、典籍出处都列出来——这篇把“知识图谱 + 中医药”这个题目拆成一个本科毕设能落地的样子：图谱用 Neo4j 存，方剂药材关系全在图里，推荐就是图上的多跳查询。
一、项目说明
1.1 选题背景
中医药方剂有几千年的积累，但对学生和年轻医生来说，门槛很高：一首方剂十几味药，哪味是君、哪味是臣，为什么这么配，翻书要翻半天；更难的是配伍禁忌——“十八反、十九畏”背不全，开方就可能出错。
知识图谱正好能把这种“关系密集”的知识装起来：方剂—药材—症状—典籍，四类节点连成一张网，推荐就是在这张网上做查询和排序。本篇的定位很明确：这是一个学习辅助工具，不是诊疗系统——推荐结果仅供学习参考，不能替代执业医师诊断，这句话要写进系统首页，也要写进答辩稿里。
1.2 项目定位
| 维度 | 内容 |
|---|---|
| 项目类型 | 前后端分离的 Java Web 项目 |
| 前端 | Vue 3 + Element Plus + ECharts（图谱可视化） |
| 后端 | Spring Boot 3 + MyBatis-Plus，REST 接口联调 |
| 图数据库 | Neo4j 5.x，存方剂—药材—症状—典籍关系图谱 |
| 数据库 | MySQL 8（业务数据）+ Redis（热门方剂缓存） |
| AI 辅助 | DeepSeek API（症状解析、方剂白话解读，仅作辅助） |
| 核心数据 | 方剂 3,860 首 · 中药 1,240 味 · 症状 2,680 个 · 图谱节点 86,400 个 · 关系边 214,600 条 |
| 关键指标 | 推荐 Top-3 准确率 91.6% · 查询响应 1.2 秒 · 典籍来源 12 部 |
1.3 适用人群
- 想做“知识图谱”方向的毕设学生：图谱可视化效果好，答辩展示很加分
- 对中医药信息化感兴趣的同学：方剂、药材、配伍禁忌都是现成的好素材
- 需要一个“有图、有搜索、有推荐”的完整项目的同学
二、技术栈
| 层 | 技术选型 | 说明 |
|---|---|---|
| 前端 | Vue 3 + Element Plus + ECharts | 图谱用 ECharts 关系图渲染，支持拖拽、缩放、节点展开 |
| 后端 | Spring Boot 3 + MyBatis-Plus | REST 接口，JWT 登录鉴权 |
| 图数据库 | Neo4j 5.x + Cypher | 节点：方剂/药材/症状/典籍；关系：组成/主治/归经/配伍禁忌等 9 种 |
| 数据库 | MySQL 8 + Redis | 方剂详情、用户收藏存 MySQL，热门方剂走 Redis 缓存 |
| AI 辅助 | DeepSeek API | 症状口语解析、方剂白话解读，只做辅助，不参与推荐排序 |
| 文件存储 | MinIO | 药材图片、典籍扫描页 |
| 部署 | Docker + Nginx | Neo4j、MySQL、后端各一个容器 |
三、系统架构
系统分五层，图谱是核心：
- 用户层：学生、年轻医生、药房配药员三类用户
- 应用层：症状推荐、方剂检索、药材图鉴、配伍校验、图谱浏览
- 服务层：Spring Boot 业务服务 + Neo4j 图查询服务 + DeepSeek 辅助服务
- 图谱层：Neo4j，86,400 个节点、214,600 条关系，9 种关系类型
- 数据层：MySQL（业务数据）、Redis（缓存）、MinIO（图片）
图谱怎么建：先从 12 部典籍（《伤寒论》《金匮要略》《本草纲目》等）里抽出方剂—药材—症状三元组，再人工核对一遍才入库——图谱的质量全靠这一步，爬来的脏数据不清洗，推荐出来就是错的。推荐怎么做：症状先标准化（“嗓子疼”映射到“咽痛”），再在图上做多跳查询找候选方剂，按匹配度排序，最后过一遍配伍禁忌校验，有“十八反、十九畏”冲突的直接降权或标红。
四、推荐流程
一次推荐走 7 步，全程 1.2 秒：
- 症状输入：用户输入症状，支持口语（“嗓子疼”也能识别）
- 症状标准化：DeepSeek 辅助 + 症状词表，把口语映射到 2,680 个标准症状
- 图谱检索：Cypher 多跳查询，症状→方剂，找出候选方剂
- 方剂匹配：按症状覆盖度、君药匹配度算分
- 排序：综合得分排序，取 Top-3
- 禁忌校验：过“十八反、十九畏”配伍禁忌库，有冲突的标红降权
- 推荐展示：方剂组成、君臣佐使、典籍出处、禁忌提示一次给全
案例：输入“发热、咳嗽、咽痛 3 天”，系统推荐麻杏石甘汤，匹配度 92%，组成麻黄 9g、杏仁 9g、生石膏 18g、甘草 6g，君药生石膏清热，附《伤寒论》原文出处，同时提示“与附子同用需注意配伍”。测试集上 Top-3 准确率 91.6%（200 条标注问诊记录）。
五、核心功能模块
| 模块 | 核心功能 | 关键点 |
|---|---|---|
| 症状推荐 | 输入症状，Top-3 方剂推荐 | 1.2 秒出结果，匹配度、禁忌提示齐全 |
| 方剂检索 | 按名称、功效、典籍检索 3,860 首方剂 | 支持拼音首字母和功效关键词 |
| 药材图鉴 | 1,240 味中药档案：性味归经、用法用量、图片 | 每味药一张图，学生认药的好工具 |
| 配伍校验 | 十八反、十九畏自动校验 | 输入多味药，冲突组合标红告警 |
| 图谱浏览 | 方剂—药材—症状关系图可视化 | ECharts 关系图，节点可拖拽展开 |
| 收藏与笔记 | 收藏方剂、写学习笔记 | 学生备考常用，收藏 12,400 次 |
六、数据库设计
数据库只保留表名和一句话关系，不展开字段细节：
- 用户表：学生、医生、配药员三类角色
- 方剂表：3,860 首方剂，含功效、典籍出处
- 药材表：1,240 味中药，含性味归经、用法用量
- 症状表：2,680 个标准症状，含口语别名
- 典籍表：12 部典籍，含成书年代和版本
- 方剂药材关系表：方剂—药材组成关系，含君臣佐使角色和用量
- 收藏表：用户收藏方剂，累计 12,400 次
- 问诊记录表：200 条标注测试记录，用于算推荐准确率
图谱另算：Neo4j 里 86,400 个节点、214,600 条关系，9 种关系类型（组成、主治、归经、配伍禁忌、来源于、别名、相须、相使、相反）。MySQL 的关系表和 Neo4j 的图谱保持同步，入库时双写。
七、项目使用场景
- 中医院校教学：老师上课投图谱，方剂和药材的关系一目了然，学生不用死记硬背
- 中医诊所辅助：年轻医生开方前查一下配伍禁忌，多一道保险（仍以医生判断为准）
- 药房配药核对：配药员扫方单，系统自动校验十八反、十九畏，抓方出错率下降
- 学生自学备考：按症状反查方剂、按方剂看组成，执业医师考试复习的好工具
八、难度与工作量评估
| 维度 | 评估 |
|---|---|
| 整体难度 | 中等偏上 |
| 难在哪 | 图谱建模和 Cypher 查询是主要难点；典籍数据的清洗核对花时间 |
| 简单在哪 | 业务本身是标准 CRUD + 检索推荐，Vue 前端组件可复用 |
| 开发周期 | 6–8 周 |
| 代码量 | 约 9000–13000 行 |
| 适合人群 | 学过 Spring Boot，想往简历上加一个“知识图谱”项目的同学 |
避坑提醒：图谱数据不要全靠爬——先拿 200 首核心方剂手工建好图谱跑通推荐，再批量扩到 3,860 首；典籍原文有版权问题，展示时只引简短条文并注明出处，不要整段复制。
九、开题与答辩
开题好不好过：好过。“中医药 + 知识图谱”是政策支持方向（中医药数字化），题目新、落点实，图谱可视化答辩时一投出来就很能打。
答辩容易被问什么：
- 图谱里的数据从哪来？准不准？——12 部典籍人工抽取 + 核对，先做 200 首核心方剂再批量扩；爬来的数据不清洗不入库。
- 推荐的 91.6% 准确率怎么算的？——200 条标注问诊记录做测试集，Top-3 命中算对；测试集和训练用的方剂库是分开的。
- 为什么用 Neo4j，不用 MySQL 存关系？——方剂—药材—症状是多跳关系，MySQL 做 3 跳以上 JOIN 又慢又难写，图数据库天生就是干这个的。
- DeepSeek 在推荐里起什么作用？——只做症状口语解析和方剂白话解读，排序完全由图谱查询决定；断网也能推荐，AI 只是锦上添花。
- 推荐错了怎么办？谁负责？——系统首页和每页都写明“仅供学习参考，不能替代执业医师诊断”；配伍禁忌校验是底线功能，宁可少推、不推错的。
对这个方向感兴趣的同学可以私信聊聊，下一篇是《基于联邦学习与隐私计算的跨机构医疗数据协同分析系统设计与实现》。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/qq_54351538/article/details/170550258
