简介这是一个基于Neo4j图数据库的医疗知识图谱智能问答机器人完整项目专为计算机专业毕业设计、期末大作业及项目实训打造。项目覆盖从医学实体关系数据构建知识图谱、对用户问句进行语义解析、生成CQL查询、到返回答案并呈现于前端界面的完整链路并附带详细的项目使用说明便于上手部署。压缩包共36个文件其中8个Python源码实现知识图谱构建、问句分析、答案检索等核心功能10个TXT文档提供说明与注释另有HTML/CSS/JS页面和PNG/JPG图片整体15.34MB目录结构清晰。该项目是导师指导认可的高分设计评审得分98分所有源码均经本地编译调试、可稳定运行直接用于课程设计或毕业设计参考也便于二次功能扩展。已有296人学习下载适合需要完整可运行项目来理解医疗知识图谱问答技术的学生。1. 这个医疗知识图谱问答机器人先想清楚它值不值得你花时间做毕设选型时我拿到这份“Python基于Neo4j图数据库的医疗知识图谱智能问答机器人”源码第一反应是它到底是真的问答还是披着图谱外衣的关键词匹配把项目跑起来之后我确认了它是一个完整走完“医疗数据建模 → 写入Neo4j → 问句解析 → Cypher生成 → 答案组装”的闭环系统不是那种拿if-else糊弄的演示项目。它的价值在于把知识图谱和问答机器人两个高频考点一次落地适合正在做期末大作业、毕业设计的学生也适合想快速复现一个图谱项目的实战学习者。下面我按自己拆项目的顺序从目录结构、建图逻辑、问答链路、常见坑四个层面把它讲透。2. 把七个脚本串成一条问答链路从目录看懂运行顺序拿到压缩包先别急着跑花十分钟把文件分工看清楚能省掉后面大量“不知道改哪个文件”的纠结。这份源码的结构很典型几乎所有基于图数据库的问答项目都会按“建图、问句分析、查询组装、答案生成”四个阶段拆分代码。2.1 项目里的核心文件与各自职责先看根目录下与业务直接相关的文件我按它们在流水线中的位置列了一张表文件职责在链路中的位置build_medicalgraph.py读取data/下的原始医疗数据清洗后写入 Neo4j第 1 步clear_graph.py清空图中已有节点和关系让建图可重复执行建图前可选question_analysis.py对用户问句做分词、实体抽取、意图识别第 2 步keyword_template.py维护问法模板和关键词映射辅助意图判定配合上者get_cql.py把“意图 实体”翻译成 Cypher 查询语句第 3 步get_answer.py把 Neo4j 返回的结果组装成自然语言答案第 4 步chat_robot.py命令行问答主循环负责接收输入并调用以上模块启动入口main.py总入口按需调用建图或问答流程可选入口data/原始医疗语料一般按实体类型分文件存放数据源dict/自定义分词词典提高医疗词汇的识别准确率辅助配置static目录通常是前端静态资源或图片__pycache__是 Python 运行缓存.gitattributes是 Git 换行符配置这些都不影响主流程。重点记住一个判断凡是名字里带 get 的都在做“查询相关”的事凡是带 build / clear 的都在改图数据。后面排错时按这个命名习惯定位文件会很快。2.2 问答主流程一次提问在系统里怎么流转整个系统本质上是一条单向管道数据从左侧流入答案从右侧流出用户输入 → question_analysis.pyjieba 分词 实体抽取 意图识别→ keyword_template.py模板匹配确认意图→ get_cql.py生成 Cypher→ Neo4j 查询 → get_answer.py组装答案→ chat_robot.py 控制台输出有一个容易被忽略的点这个项目把“意图识别”和“Cypher 生成”拆成了两个文件。我一开始觉得多此一举后来在改代码时才体会到好处——当你新增一种问法比如“XX 有什么忌口”只需要在keyword_template.py加模板、在get_cql.py加一条分支不用动解析逻辑。如果你的大作业也要二次开发这个拆分习惯值得保留。2.3 第一次跑通的最小操作步骤我建议按“先建图、后问答”的顺序做不要一上来就跳进chat_robot.py因为问答的前提是 Neo4j 里已经有数据。三条命令就能看到效果# 1. 确保 Neo4j 已启动浏览器能访问 http://localhost:7474 # 2. 建图把 data/ 下的数据写入图数据库 python build_medicalgraph.py # 3. 启动问答机器人的命令行交互 python chat_robot.py这里的第 1 步是环境前提Neo4j 默认 HTTP 端口是 7474、Bolt 端口是 7687。第 2 步运行时build_medicalgraph.py会逐行读取数据文件并创建节点控制台会打印实体数量、关系数量等统计信息如果看到“共创建 XX 个节点”这类输出说明建图成功。第 3 步进去后直接输入“感冒有什么症状”试试能返回结构化答案就说明最简链路通了。提示如果第 2 步报错90% 是 Neo4j 没启动或认证密码不对先回浏览器确认能登录 Neo4j 再跑脚本别急着改代码。3. 把医疗数据写进 Neo4j图谱模型与入库策略问答机器人表现好不好一半取决于建图质量。这一章讲清楚build_medicalgraph.py到底做了什么以及为什么数据模型这么设计。3.1 医疗图谱的实体、关系与数据来源从项目目录看data/下放着医疗原始语料常见做法是按实体类型拆成不同文件疾病库、症状库、药品库、检查项目库、科室库、食物库。这个项目的核心实体大致覆盖以下类型实体类型含义典型属性Disease疾病name、简介Symptom症状nameDrug药品nameCheck检查项目nameDepartment科室nameFood食物name实体之间通过关系连接关系就是问答时的“路径”。我根据文件名和课程设计常见套路推断关系至少包含这几类疾病与症状的HAS_SYMPTOM、疾病与药品的RECOMMEND_DRUG、疾病与检查项目的CHECK_ITEM、疾病与科室的DEPARTMENT、疾病与食物的EAT_GOOD / EAT_BAD。这套模型最大的优点是直观一条“疾病 → 关系 → 实体”就能回答绝大多数医疗问句比如“感冒挂什么科”就是查感冒 -[DEPARTMENT]- 科室。3.2 建图脚本的入库逻辑与 Cypher 写法build_medicalgraph.py的核心逻辑分两步先建实体节点再建关系边。用 py2neo 操作时典型的节点写入方式是from py2neo import Graph, Node graph Graph(http://localhost:7474, auth(neo4j, your_password)) # 用 merge 而非 create按 name 属性去重避免重复建点 disease_node Node(Disease, name感冒) graph.merge(disease_node, Disease, name)这里最关键的是merge而不是create。merge会先检查是否存在相同的“标签 唯一属性”存在则匹配、不存在才创建。做课程设计时数据可能不干净同一个疾病名出现两次很常见如果无脑create图谱里会出现两个“感冒”节点后面的问答全乱套。关系写入时也要小心先查出两个节点再建边# 找到疾病和症状节点再创建 HAS_SYMPTOM 关系 disease graph.nodes.match(Disease, name感冒).first() symptom graph.nodes.match(Symptom, name发热).first() if disease and symptom: graph.merge(Relationship(disease, HAS_SYMPTOM, symptom))我习惯在建边前加一个if判断因为原始数据里可能存在“某个疾病引用了不存在的症状”不判断直接建关系会抛异常。等价的 Cypher 写法是这样你在 Neo4j Browser 里手动验证数据时可以直接用MATCH (d:Disease {name:感冒}) MATCH (s:Symptom {name:发热}) MERGE (d)-[:HAS_SYMPTOM]-(s)注意MERGE在 Cypher 里也是幂等的重复执行不会产生双份关系。建图脚本本质就是把上面这些操作循环执行区别只是遍历数据源文件、按行拆字段。3.3 为什么建图前要清库clear_graph.py 的必要性项目里单独放一个clear_graph.py不是摆设。图谱数据最怕“叠加式建图”——你跑一次build_medicalgraph.py生成 200 个节点改了数据又跑一次因为部分数据变化库里新老节点混在一起问答结果越来越诡异。这个问题我踩过查了半天代码最后发现是库里有一批脏数据。clear_graph.py做的事情非常简单核心就一行from py2neo import Graph graph Graph(http://localhost:7474, auth(neo4j, your_password)) graph.run(MATCH (n) DETACH DELETE n)这里用DETACH DELETE而不是DELETE是因为图数据库里节点间有大量关系普通DELETE只能删没有连边的孤立节点直接删有关系的节点会报错。DETACH DELETE会先拆掉所有关系再删节点是清库的标准姿势。注意清库是不可逆操作跑之前确认库里没有你要保留的数据。我一般会在清库前用MATCH (n) RETURN count(n)看一眼节点总数留个底。4. 问句怎么变成 Cypher分词、意图判定与参数组装建完图只是第一步问答机器人的“大脑”在question_analysis.py、keyword_template.py、get_cql.py、get_answer.py这四个文件里。这一章把从“一句话”到“一条查询”再到“一句答案”的完整过程拆开看。4.1 分词的坑医疗词必须加载自定义词典问句解析的第一步是分词。项目里用的是 jieba它是 Python 生态里最常用的中文分词库。但直接拿默认词典切医疗文本会翻车比如“病毒性感冒”可能被切成“病毒性 / 感冒”或者“阿莫西林胶囊”被切成“阿莫西林 / 胶囊”实体抽取就会漏掉一半。解决办法是加载自定义词典import jieba # 加载项目 dict/ 下的自定义词典里面一般是疾病名、药名等专有名词 jieba.load_userdict(dict/medical_words.txt) # 对问句分词得到可用的词序列 user_input 感冒有什么症状 seg_list jieba.lcut(user_input) print(seg_list) # 期望输出类似[感冒, 有, 什么, 症状]load_userdict的作用是把自定义词加入 jieba 的词库让分词器优先把它们当成完整词。参数这里最需要注意的是字典文件路径如果脚本是从项目根目录启动路径就是相对根目录的否则会报找不到文件。分词结果出来后再跟dict/里的实体词表做匹配命中哪个实体就记哪个比如“感冒”命中 Disease 实体“发热”命中 Symptom 实体。4.2 意图判定keyword_template.py 的模板设计分词只能解决“提到了什么”还不能解决“用户想问什么”。“感冒有什么症状”和“感冒该吃什么药”都提到了感冒但要查的关系完全不同。keyword_template.py干的事就是意图分类常见实现是维护一组问法模板用户意图问法模板示例对应查询的关系查症状XX有什么症状 / XX的症状HAS_SYMPTOM查科室XX挂什么科 / XX去哪个科室DEPARTMENT查药品XX吃什么药 / XX用什么药RECOMMEND_DRUG查检查XX做什么检查 / XX怎么确诊CHECK_ITEM查忌口XX不能吃什么 / XX的饮食禁忌EAT_BAD判断逻辑一般是顺序匹配先看问句里是否包含“什么症状”“吃什么药”这类固定短语命中哪个就判定为哪个意图。这个方案有个天然局限——问法一变就识别不出来比如“感冒该注意什么”就没在模板里。对课程设计来说够用了但你要有心理准备扩大问法范围就要扩充模板这是后期工作量的大头。4.3 get_cql.py把意图和实体翻译成参数化 Cypher拿到意图和实体之后get_cql.py负责拼接出真正的查询语句。最稳妥的写法是参数化查询而不是把实体直接拼进字符串def build_cql(intent, entity): 根据意图和实体返回 cql 语句和查询参数 intent: 意图名称如 symptom/department/drug entity: 实体名称如 感冒 if intent symptom: cql MATCH (d:Disease {name:$name})-[:HAS_SYMPTOM]-(s:Symptom) RETURN s.name AS result elif intent department: cql MATCH (d:Disease {name:$name})-[:DEPARTMENT]-(t) RETURN t.name AS result else: cql None params {name: entity} return cql, params这里$name是参数占位符py2neo 会把params里的值安全地传进查询。用参数而不是字符串拼接一方面避免了引号、特殊字符把语句搞坏另一方面也更安全不用考虑注入问题。我还习惯把RETURN的字段统一命名成result这样get_answer.py处理结果时不用针对每个意图单独写一套解析逻辑。4.4 get_answer.py把查询结果拼回人话Neo4j 返回的是列表嵌套字典的结构直接输出非常难看get_answer.py就是把结果整理成“人能读的话”。核心逻辑不复杂# 假设 graph 是已连接的 py2neo Graph 对象 result graph.run(cql, params).data() # 把多个结果用顿号拼接没有结果时返回提示语 if result: answer 、.join([row[result] for row in result]) print(f{entity}的症状可能有{answer}) else: print(抱歉图谱里暂时没有找到相关的信息换个问法试试。)注意graph.run(cql, params).data()返回的是列表每个元素是字典键就是 Cypher 里RETURN的别名。这里的拼接逻辑有一个隐藏问题如果查询结果有几十条全部拼出来会很长。做课程设计可以不管但如果你想优化体验可以只取前 5 条再加一句“等”。5. 避坑实测Neo4j 连不上、答案为空、中文乱码这样排查这个项目最大的“黑匣子”在运行环境不在代码逻辑。我复现时踩了五个坑每一个都花了不少时间这里按“现象 → 原因 → 解决”写出来帮你跳过。5.1 环境对齐先确认三个版本能互相兼容这份源码是 Python 写的依赖 Neo4j 图数据库和 py2neo 驱动。常见能跑通的组合是Python 3.8 或 3.9、Neo4j 社区版、py2neo 4.x 或 5.x。注意 py2neo 4.x 和 5.x 的 API 有差异老版本用graph.run()传入字符串新版也支持但如果你看到代码里用的是Graph(http://localhost:7474, auth(neo4j, xxx))这个写法在 4.x 和 5.x 都成立兼容性比较好。提示如果机器上还没装 Neo4j建议用 Neo4j Desktop 管理版本它会自动绑定 Java 环境比手动配省心。启动后一定先看日志里的端口号确认 7474 和 7687 都起来了再跑 Python 脚本。5.2 问题一py2neo 报“Unable to connect”类错误现象运行build_medicalgraph.py报py2neo.database.ClientError或连接超时。原因Neo4j 服务没启动或者连接地址写错。项目默认连localhost:7474但 Neo4j 服务端可能只启了 Bolt 端口HTTP 端口未开放。解决先访问http://localhost:7474能打开浏览器登录页说明 HTTP 正常打不开就回 Neo4j Desktop 看服务状态把服务启动起来。连接写在脚本入口的Graph()构造参数里确认密码填的是 Neo4j 初始化时设置的那个不是别的数据库密码。5.3 问题二问“感冒有什么症状”返回空结果现象chat_robot.py能启动但问任何疾病都答“没找到信息”图谱里明明有数据。原因空结果大概率是实体没对上。用户输入的实体词和建图入库的名称不完全一致比如库里存的是“感冒”问句分词出来是“风热感冒”两者不匹配。解决先用get_cql.py的逻辑手动拼一条 Cypher在 Neo4j Browser 里跑一遍看能不能查到能查到说明代码查询条件有差异查不到说明是分词或实体映射问题。更快的定位方式是在question_analysis.py里临时打印分词结果和抽取到的实体确认实体确实被识别出来了。5.4 问题三中文乱码控制台输出变“口字旁方块”现象脚本运行正常但控制台打印的疾病名、症状名全是乱码。原因Windows 命令行默认编码是 GBK而 Python 源码和data/里的数据一般是 UTF-8两边编码不一致。解决在运行命令前加环境变量set PYTHONIOENCODINGutf-8Windows或者把启动命令写成PYTHONIOENCODINGutf-8 python chat_robot.py。如果是 PyCharm 跑把 File Encoding 和 Console Encoding 都设为 UTF-8。5.5 问题四重复跑建图脚本后同样的问题答案变多现象第一次跑完建图脚本“感冒”对应 5 个症状第二次跑完变成 10 个问答结果开始出现重复条目。原因建图脚本没用MERGE或者实体名称数据里有空格、换行符导致同一个实体被建了两遍。解决先跑clear_graph.py清库然后在build_medicalgraph.py里检查节点创建是否用了merge(node, label, key)同时在建实体前对名称做一次strip()去空格再去重# 清洗原始数据中的脏字符 name raw_name.strip().replace(\n, ) if not name: continue6. 用 clear_graph.py 把建图、问答、扩展串成闭环我的验证习惯拿到这类带图谱的项目最容易犯的错是“只跑通骨架就交差”。我自己的血泪经验是必须做一次“清库 → 重建 → 测试问题集 → 改数据 → 再清库重建”的完整闭环否则你根本不知道问答结果里哪些是代码问题、哪些是数据问题。我的标准操作是把流程固定成两条命令# 每次改动数据或建图逻辑后强制先清库再重建 python clear_graph.py python build_medicalgraph.py # 然后带上一份测试问题集启动问答 python chat_robot.py配套地我会准备一份 810 条问题的测试清单覆盖不同意图测试问题预期意图检查点感冒有什么症状查症状返回结果非空感冒挂什么科查科室返回科室名感冒吃什么药查药品返回药品名感冒不能吃什么查忌口返回食物名高血压做什么检查查检查返回检查项目随便乱问一句话兜底返回友好提示不报错跑完这组问题如果全部命中这份源码的“可得性”才算真正在你自己环境里验证过。再往后扩展路径已经很清晰把data/里的医疗数据替换成你自己领域的数据比如法律、教育、电商售后改实体标签和关系名再在keyword_template.py里加对应问法一个通用知识图谱问答的骨架就出来了。从那以后我每次拿到带图谱的项目都强制走一遍“清库 → 重建 → 测试问题集 → 改数据”的循环十次有八次的问题出在数据而不是代码上。做毕设最怕的就是把“能跑”当“做完”多验证一轮答辩时被问到底层的概率就小一分。希望帮到你。本文还有配套的精品资源点击获取