简介：一份基于Python与Neo4j图数据库的医疗知识图谱智能问答机器人毕业设计项目，定位为计算机相关专业学生的毕设参考与项目实战练习。项目覆盖医疗数据清洗、知识图谱构建、问题意图解析、CQL查询生成和答案返回的完整链路，代码注释详细，配套使用说明文档，可直接运行或在此基础上做二次开发，也适用于课程设计与期末大作业。压缩包共36个文件，以8个Python源码文件为核心，搭配10个文本说明、网页前端文件、图片素材等辅助内容，整体仅15.34MB，轻量且结构清晰。已有701人学习下载，从中可提取疾病-症状-药品等实体关系建模思路、问答模板匹配策略、图谱构建与清空重置工具，以及完整的调试验证流程，可帮助快速复现一个可交互的领域问答机器人。

1. 医疗知识图谱问答机器人：先搞清楚它到底能答什么，再动手跑

Python基于Neo4j图数据库的医疗知识图谱智能问答机器人，这类毕设源码包在计算机专业里很常见，但我拆过不少项目后发现一个普遍现象：很多人拿到手第一件事是装环境、跑main.py，看到命令行出现“请输入问题”就算成功，然后答辩时被问一句“图查询的Cypher是怎么生成的”就卡住。这个项目不是那种只有一个预测脚本的玩具，它覆盖了知识图谱构建、问句意图识别、Cypher生成、答案返回的完整链路，源码带超详细注释。它解决的问题很具体：用户用自然语言问“感冒了吃什么药”，系统能把这句话拆成意图和实体，去Neo4j图谱里查出关联药品并组织成答案。适合正在做毕业设计、课程设计，或者想入门图数据库和知识图谱实战的读者，也适合想用最短路径把问答系统全流程串起来的人。

2. 医疗问答为什么选Neo4j：图遍历比多表JOIN更直观，以及源码包的文件分工

拿到源码包先别急着跑，第一步是理解选型逻辑。医疗领域的数据天然是网状结构，一个疾病关联症状、科室、药品、饮食建议、检查项目，这种关系用关系型数据库表达不是不行，但查询成本很高。这个项目选Neo4j图数据库，本质上是因为它把“关系”做成了存储和查询的一等公民。

2.1 从数据模型看选型：疾病-症状-药品天然是图结构

先看数据长什么样。医疗知识图谱里最常见的三元组是“疾病—关系—实体”，比如“感冒—有症状—头痛”“感冒—推荐用药—感冒灵颗粒”“感冒—建议就诊科室—呼吸内科”。如果用MySQL表达，至少要建疾病表、症状表、药品表、科室表，再加三张关联表，想查“感冒的所有关联信息”得写三四个JOIN，而且每多一层关系，SQL的可读性和维护性就下降一截。换成Neo4j，节点和关系直接落盘，查询用MATCH语法，一条语句就能从一个疾病节点出发，沿着不同关系类型遍历到所有邻居节点，这正是“neo4j查询从一个节点出发如何查询多条”的实际场景。

知识图谱本身是一组三元组的集合，图数据库负责存储和查询这组三元组。选Neo4j而不是Elasticsearch或者纯CSV硬查，是因为问答系统需要的是语义路径：用户问“头疼挂什么科”，系统不是做关键词倒排，而是识别出“头疼”这个症状实体，再沿着“症状—疾病—科室”这条语义路径反推答案。没有图结构，这个路径就断了。表 1 是这个项目里典型的实体和关系设计，后面构建图谱时你会反复用到。

2.2 源码包的模块分工：从main.py到chat_robot.py的问答主流程

这份源码包的文件分工很清晰，我拆目录时大概理了一下，每个文件负责一段链路：

• main.py：程序入口，启动问答循环，接收用户输入
• chat_robot.py：对话交互层，调用下游模块并组织输出
• question_analysis.py：问句分析，判断意图、抽取实体
• keyword_template.py：意图关键词和模板定义
• get_cql.py：根据意图和实体拼接Cypher查询语句
• get_answer.py：执行Cypher查询，把结果整理成自然语言答案
• build_medicalgraph.py：构建知识图谱，把data目录的数据导入Neo4j
• clear_graph.py：清理图数据，调试时重置用
• data：原始医疗数据，通常是CSV或JSON
• dict：自定义词典，辅助中文分词识别实体

整个问答流程是这样走的：main.py收到用户问句后，chat_robot.py把问句交给question_analysis.py，question_analysis.py先判断意图——是问病因、问症状还是问用药，然后结合dict词典把“感冒”“头痛”这类实体从问句里切出来；接着get_cql.py根据“意图+实体”拼接出Cypher语句，get_answer.py执行这条语句，把查询到的节点属性整理成“您可能想知道：…”这样的回答返回给用户。我建议你按build_medicalgraph.py → question_analysis.py → get_cql.py → get_answer.py的顺序读源码，这个顺序就是数据从文件流入图谱、再从图谱流回用户的全过程。

3. 把医疗数据灌进Neo4j：build_medicalgraph.py的实体关系设计与导入参数

图谱问答系统的地基是图里的数据质量。很多人在这一步翻车，不是因为代码写错，而是实体和关系设计得不对，导致后面查不到数据。本章结合build_medicalgraph.py讲清楚三件事：建什么样的节点、关系怎么定方向、数据怎么高效写进Neo4j。

3.1 实体与关系先建模：确定节点类型和关系方向

写构建脚本前，先做本体建模。这个项目的实体类型我已经在表 1 列出来了，实际构建时每个实体对应一类节点，Node的第一个参数就是节点标签。重点是关系方向，这个最容易被忽略：关系是“疾病→症状”还是“症状→疾病”，决定了查询时写(d)-[:有症状]->(s)还是(s)-[:属于]->(d)。我见过有人把关系方向建反，结果问“感冒有什么症状”返回空列表，而Neo4j数据浏览器里看起来图是完全正常的。

数据格式方面，data目录里的常见做法是结构化文件，比如disease.json保存疾病基本信息，symptom.txt保存症状列表，disease_symptom.csv保存关联关系。不管你拿到的是CSV还是JSON，构建脚本的第一步都是先把文件读成Python对象。下面给出build_medicalgraph.py里最核心的节点创建逻辑，这是简化后的写法：

from py2neo import Graph, Node, Relationship import json # 连接Neo4j，端口和密码按本机配置修改 graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password")) with open("data/disease.json", "r", encoding="utf-8") as f: disease_list = json.load(f) for item in disease_list: # 创建疾病节点，name是唯一属性，merge按name去重 disease_node = Node("疾病", name=item["name"], desc=item.get("desc", "")) graph.merge(disease_node, "疾病", "name") # 处理该疾病关联的症状 for symptom_name in item.get("symptoms", []): symptom_node = Node("症状", name=symptom_name) graph.merge(symptom_node, "症状", "name") rel = Relationship(disease_node, "有症状", symptom_node) graph.merge(rel, "有症状", "name")

这段代码里有几个参数要说明。Graph的第一个参数是连接URI，bolt://是Neo4j的二进制协议端口，默认7687；auth元组第一个元素是用户名，默认neo4j，第二个是安装时设置的密码。Node的第一个参数“疾病”是节点标签，构建图谱时所有疾病节点都带这个标签，查询时MATCH (d:疾病)就靠它定位。merge替代create的好处是幂等：重复运行构建脚本不会产生重复节点，它按第三个参数“name”做匹配，已有同名校验就不新建。Relationship的三个参数分别是头节点、关系类型、尾节点，方向用箭头表示，这里就是“疾病→症状”。

3.2 批量导入与索引约束：建图慢和数据一致性的解药

节点少的时候逐条merge没问题，但医疗图谱数据量一上来，跑build_medicalgraph.py会越来越慢。常见做法是事务分批提交，py2neo里可以这样控制：

tx = graph.begin() # 开启事务 for item in disease_list: # 节点创建逻辑同上，省略 tx.merge(disease_node, "疾病", "name") if count % 500 == 0: graph.commit(tx) # 每500条提交一次，减少事务开销 tx = graph.begin() graph.commit(tx)

参数方面要注意两点。其一，建图前在Neo4j里给节点加上唯一约束，可以大幅提升按name查询和去重的速度：

CREATE CONSTRAINT FOR (n:疾病) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT FOR (n:症状) REQUIRE n.name IS UNIQUE;

其二，如果数据量非常大，可以跳过py2neo直接用Neo4j的LOAD CSV导入，但前提是CSV文件格式干净，且需要把关系文件单独准备。毕业设计场景用py2neo就好，逻辑清晰、方便调试。此外还要把clear_graph.py重视起来，它不是摆设。调试期间我习惯每次重建图谱前先执行MATCH (n) DETACH DELETE n清空库，这个脚本就是在命令行里帮你执行这条Cypher的，避免手动打开Neo4j浏览器操作。注意这是不可逆操作，执行前确认你已经不需要当前图里的数据。

4. 从自然语言到Cypher：question_analysis.py的意图识别与get_cql.py的模板拼接

图谱建好了，接下来是这个项目的核心：怎么把一句中文问句变成一条能查出答案的Cypher。这部分拆成两步：先判断用户在问什么意图，再从问句里抽出实体，最后按模板拼CQL。

4.1 意图分类和关键词模板：先判断“问什么”再抽“实体”

用户不会按你预设的格式提问，同是“感冒”，可能问“感冒有什么症状”“感冒是什么引起的”“感冒吃什么药”“感冒挂什么科”。这四种问法对应的Cypher完全不同，所以question_analysis.py做意图分类是关键起点。这个项目采用关键词模板匹配而不是训练分类模型，是符合场景的务实选择：医疗数据量有限，规则模板可控，毕设答辩时能清楚解释每个分类的判定依据。keyword_template.py里维护的就是这样一个映射：

# keyword_template.py 简化示例：意图到关键词的映射 INTENT_TEMPLATES = { "disease_symptom": ["有什么症状", "症状是什么", "有哪些表现"], "disease_cause": ["病因", "是什么引起的", "为什么会得"], "disease_treatment": ["怎么治", "如何治疗", "怎么办", "吃什么药", "用什么药"], "disease_department": ["挂什么科", "哪个科", "去什么科室"] }

意图判断逻辑不复杂：对用户问句做遍历，看哪类模板里的关键词命中数量最多，就判定为哪个意图。这里有个坑，中文分词。默认的jieba词表不一定认识“高血压”“过敏性鼻炎”这类医疗词，可能在分词阶段就把实体切碎了。所以项目中dict自定义词典的作用就是给分词器补充医疗实体词。常见做法是用jieba.load_userdict把dict目录下的词表加载进去，这样“高血压”才能被识别成一个完整实体而不是“高/血压”。

4.2 从CQL生成到答案返回：get_cql.py和get_answer.py的配合

拿到意图和实体后，get_cql.py负责拼Cypher。下面是这个模块最核心的简化逻辑：

# get_cql.py 简化示例：按意图拼接Cypher def build_cql(intent, entity): if intent == "disease_symptom": return f"MATCH (d:疾病) WHERE d.name = '{entity}' " \ f"MATCH (d)-[:有症状]->(s:症状) RETURN s.name" elif intent == "disease_treatment": return f"MATCH (d:疾病) WHERE d.name = '{entity}' " \ f"MATCH (d)-[:推荐用药]->(m:药品) RETURN m.name" elif intent == "disease_department": return f"MATCH (d:疾病) WHERE d.name = '{entity}' " \ f"MATCH (d)-[:建议就诊科室]->(c:科室) RETURN c.name" elif intent == "disease_cause": return f"MATCH (d:疾病) WHERE d.name = '{entity}' " \ f"MATCH (d)-[:病因]->(r:病因) RETURN r.name" return None

注意，这段拼接用的是Python f-string，实体名直接嵌入Cypher。毕设项目这么写直观，但有两个隐含条件：第一，第3章建图时节点的name属性必须和问句抽取出的实体完全一致，“感冒”和“流行性感冒”是两个节点，匹配不上就返回空；第二，生产环境不建议这么拼，因为存在注入风险，但本地问答场景问题不大。更严谨的写法是把entity作为参数传递，像graph.run("MATCH (d:疾病) WHERE d.name = $name RETURN d", name=entity)，py2neo支持这种方式，如果你不想在答辩时被挑刺，建议改用参数化。

get_answer.py执行这条CQL后拿到的是节点属性列表，比如["感冒灵颗粒", "布洛芬"]，它需要把这些值组织成一句人话：“根据数据库查询，感冒的推荐用药有：感冒灵颗粒、布洛芬。”如果查询结果为空，要准备兜底文案，比如“抱歉，数据库中没有找到相关记录，请换个问法试试”。这个兜底机制很重要，否则用户问一个图谱里没有的疾病，程序直接抛异常。还需要说明一点，get_cql.py里没有覆盖到的意图，比如用户问“感冒能喝酒吗”，这在当前模板下会落到空分支，问答系统会返回兜底话术，这是规则模板方案的能力边界。

5. 避坑实录：Neo4j版本、中文分词与数据一致性，四条血泪经验

这个项目我在不同环境里跑过，也帮别人排查过问题，踩过的坑集中在环境版本、编码、分词和数据一致性四个方面。每条都按现象、原因、解决的顺序写，方便你对照排查。

5.1 环境与连接类问题：py2neo和Neo4j版本不匹配

现象：运行build_medicalgraph.py或chat_robot.py时，报ConnectionError: Unable to connect to Neo4j，或者Unauthorized认证失败，有些人还会遇到AttributeError: 'Graph' object has no attribute 'merge'。

原因：py2neo和Neo4j之间存在版本兼容性差异。py2neo较新版本对Neo4j 4.x、5.x的连接协议支持不同，旧版py2neo不带认证参数连不上需要密码的Neo4j 5.x；反过来，新版py2neo用了Neo4j 5.x丢弃的旧协议也可能连不上。绝大概率不是你代码的问题，是版本组合没对齐。

解决：先确认Neo4j版本，再安装匹配的py2neo。Neo4j社区版4.4搭配py2neo 2021.2.3是我验证过比较稳的组合；用Neo4j 5.x的话，注意连接URI用bolt://localhost:7687，auth参数格式为auth=("neo4j", "密码")。装依赖时指定版本，不要直接pip install py2neo装到最新版然后碰运气。另一个高发问题是在vscode里跑程序报ModuleNotFoundError: No module named 'py2neo'，多半是因为没在项目虚拟环境里安装依赖，先激活虚拟环境再装，不要全局装。

5.2 数据与查询类问题：中文乱码和实体匹配不上

现象：建图脚本跑完，打开Neo4j浏览器查症状节点，name属性显示头痛这类乱码；或者问答时问“感冒吃什么药”，返回空结果，但你直接在Neo4j浏览器里查MATCH (d:疾病 {name:'感冒'})却能查到节点。

原因：中文乱码是文件编码不一致。data目录里的CSV或JSON文件可能是GBK编码，而Python的open函数默认用UTF-8读取，中文字符就变成乱码写入图里。实体匹配不上是名称不一致：图谱里存的是“普通感冒”，问句抽取出来的是“感冒”，或者dict词典里的词和图谱实体名没有同步维护。

解决：编码问题统一在读取文件时指定编码，打开CSV用open(..., encoding="utf-8")，如果读出来乱码就换encoding="gbk"再试。实体匹配问题两条路：一是把dict自定义词典的每个词和data里的实体名对齐，确保分词结果能准确映射到图谱节点name；二是给问句实体做归一化，比如建一个“感冒”和“流行性感冒”的同义词映射表，查询前先转换。我习惯在question_analysis.py里加一个实体归一化函数，把抽出的实体过一遍映射表，这比反复去改图数据成本低。

5.3 数据一致性类问题：误跑clear_graph.py还是重建图不彻底

现象：调试时想重建图谱，先执行了clear_graph.py清空库，然后又跑build_medicalgraph.py，结果发现某些节点还在、某些旧关系没覆盖，或者报唯一约束冲突；更严重的是有人本想清空一个子图，结果一把梭把整个库的节点全删了。

原因：clear_graph.py默认执行的是MATCH (n) DETACH DELETE n，这是全库清空操作，没有节点类型过滤，没有确认机制。重建图不彻底则是因为约束和索引残留，或者数据文件里有重复条目，merge去重逻辑没覆盖到所有属性。

解决：把clear_graph.py别当成普通功能脚本，当成危险操作。我会在脚本里加一个环境变量或命令行确认参数，只有显式传入--yes才执行删除。重建图谱前，除了清空节点，还要确认唯一约束和索引是否生效，否则merge时可能因为缺少唯一约束而创建重复节点。

5.4 性能类问题：建图太慢和内存溢出

现象：数据文件有几万条记录时，build_medicalgraph.py越跑越慢，到后面甚至卡死或触发Java堆内存报错。

原因：逐条merge产生大量事务提交开销；Neo4j默认堆内存配置偏低，批量写入时承受不住。

解决：批量写入，我已经在第3章给了事务分批提交的写法，每500条一次commit。另外在Neo4j安装目录的neo4j.conf里调大内存，核心参数有两个：dbms.memory.heap.initial_size和dbms.memory.heap.max_size，毕设机器设置到512m到1g足够。改完配置重启Neo4j服务，再重新执行构建脚本。如果数据里存在大量重复，建议先对文件做去重，再进图。

6. 验证与调优：从“跑通”到“答得对”的三个检查项

代码能跑只是底线，问答系统真正麻烦的是“十个问题里答对八个，剩下两个要么答非所问要么查不到”。我每次拿到这类项目，都强制自己走一遍完整的验证流程。第一个检查项是回归测试：准备一份固定的问题清单，覆盖每个意图至少两条问法，比如“高血压有什么症状”“糖尿病吃什么药”“头疼挂什么科”，每次改完keyword_template.py或get_cql.py，就把这份清单从头到尾问一遍，记录答对的条目数。这比随手输几个问题有效得多。

第二个检查项是链路日志。在main.py的问答循环里加上四个打印点——原问句、判定意图、抽取实体、拼接出的CQL。这一套下来，问题出在哪一个环节几乎一眼就能定位：

# main.py 调试输出示例 print(f"原句: {question}") print(f"意图: {intent}") print(f"实体: {entity}") print(f"CQL: {cql}")

比如用户问“感冒吃什么药”，原句和CQL正常，但实体打印出来是“感冒灵颗粒”，说明分词环节把药品名当成了疾病名，问题出在dict词典或实体抽取规则上；如果意图是“disease_symptom”，说明“吃什么药”没被匹配到治疗意图，要回去改keyword_template.py里的关键词。第二个检查项是Cypher兑底。把程序打印出来的CQL原封不动粘到Neo4j浏览器里直接执行，能查出数据就不是图谱问题，查不出再回头看数据。

第三个检查项是边界条件。我会专门测几个图里没有的实体和模棱两可的问法，比如“癌症能治好吗”，确认get_answer.py的兜底文案正常返回而不是抛异常。

从那以后，我每改一次模板或查询逻辑，都会强制把回归清单完整跑一遍，这个习惯帮我避开了不少答辩现场翻车的事故。这种全流程的项目参数、坑点其实都藏在源码注释和问题里，建议你顺着我上面说的链条自己走一遍，比对着屏幕发呆有效得多。希望帮到你。

本文还有配套的精品资源，点击获取