简介：基于Python的医疗知识图谱问答系统毕业设计项目，适合计算机相关专业学生和自然语言处理入门开发者参考学习。系统采用Django开发Web端，MySQL管理原始数据，Neo4j构建知识图谱，完整覆盖数据抓取、数据清洗、知识存储、问答处理和可视化展示等模块，其中问答环节利用自然语言处理技术完成问题解析与图谱匹配，并以文本和图形两种方式呈现结果。资源包共280个文件，包含38个Python源码、38个pyc编译文件、41个JavaScript脚本、75个GIF演示动图，以及CSS样式、JSON配置、SQL脚本和项目文档等，整体约59MB，目录结构清晰。目前已有822人学习下载，可用于课程设计、毕业设计或知识图谱入门实战。包内附系统设计说明、数据库脚本和演示图，能帮助理解从爬虫采集到Neo4j查询、问答交互的完整流程，便于在此基础上扩展新功能、进行二次开发。 前阵子从某个课程群里拿到一个“基于Python的医疗知识图谱问答系统.zip”，解压之后发现代码量不大，目录结构也算清晰，但真正跑起来还是花了我一个下午。这个项目本质上是用Python完成了一个“医疗知识图谱 + 简单问答”的闭环：先构造医学实体和关系，存入Neo4j，再由问句解析模块把用户问题转成图查询，最后返回答案。特别适合正在做毕设、或者想快速入门知识图谱问答工程化的同学。这篇文章就按我从“拿到ZIP”到“跑通并改出毛病”的顺序，把整个系统的设计思路和代码细节拆开讲清楚。
1. 拿到ZIP之后先别急着运行：系统架构与依赖清单
1.1 一个医疗问答系统该有哪些模块
打开压缩包第一眼，别直接盯着一堆.py文件。先在脑子里建立一个完整链路：原始医疗数据 → 实体识别与关系构建 → 图数据库存储 → 问句意图理解 → 图谱查询 → 答案组织。
这个系统实际也是这么拆的，目录里基本能看到这样几类模块：
data/：存放原始csv、json或爬取下来的医疗数据；process/：负责清洗数据、构建实体字典、生成图谱节点和关系；kg/：连接Neo4j，执行节点、关系的批量导入；qa/：问句预处理、意图分类、实体识别、Cypher查询模板；web/：Flask或FastAPI提供的接口服务，前端用Vue展示。
很多初学者拿到代码后喜欢直接python main.py，结果报一堆ModuleNotFoundError。这个项目也不例外，我在第一次运行时就被迫装上了py2neo、pyahocorasick、jieba、flask等一堆依赖。所以第一步永远是先建虚拟环境，再安装依赖。
1.2 依赖安装与Python环境配置：版本比想象中更重要
医疗知识图谱问答系统里，跟AI相关的高深组件其实不多，最核心的就是图数据库驱动和中文分词库。依赖清单大致是这个级别：
pip install neo4j py2neo flask pyahocorasick jieba pandas这里要重点说Python版本坑。当时我的机器是Python 3.11，直接装最新版py2neo，跑from py2neo import Graph没问题，但好多旧代码里用的NodeMatcher方法已经变了。后来我退到Python 3.8 + py2neo 4.3.0，才和项目里的旧API完全兼容。建议有类似项目的同学先阅读requirements.txt，如果没写版本，就去看项目里调用的是graph.run("...")还是matcher.match()，据此反推py2neo主版本。
Neo4j版本也很关键，4.x和5.x的Cypher语法差异不大，但驱动认证方式有变化。如果本地端口连不上，先检查是否开启了bolt://localhost:7687，以及用户名密码是否正确。项目配置里默认地址十有八九是http://localhost:7474，但py2neo连接通常走Bolt协议。
2. 医疗知识图谱是怎么构建出来的：本体设计与数据清洗
2.1 四类实体和五类关系的本体定义
知识图谱不是把数据随便丢进图数据库就完事，先得有本体（Ontology）。医疗领域最经典的做法是定义疾病、症状、药物、科室四类实体，然后在它们之间定义关系。这个系统里我清理后一共保留了这样五类关系：
- 疾病 - 症状：
HAS_SYMPTOM - 疾病 - 药物：
USE_DRUG - 疾病 - 科室：
TREAT_IN_DEPT - 药物 - 疾病：
CONTRADICTION（禁忌） - 症状 - 疾病：
BELONGS_TO_DISEASE
一个容易忽略的点是：关系是有方向性的。比如“感冒”到“发热”可以用HAS_SYMPTOM，反过来“发热”到“感冒”用BELONGS_TO_DISEASE。在Cypher查询时，方向和关系类型必须严格匹配，不然查出来永远是空。
设计本体时还要考虑属性。比如疾病节点可以带name、alias、symptom_desc、drug_composition；药物节点带name、function、dosage、notice。这些属性会直接决定后面问答系统能不能返回有效答案。我看到有些ZIP包里的数据连字段都是空的，那就算图谱画得再漂亮，问它“阿莫西林怎么吃”也只能返回一个空节点。
2.2 从原始数据到CSV：清洗与去重的思路
原始数据可能来自公开医学百科，也可能来自课程配套的结构化SQL文件。不管来源是什么，第一步永远是转成统一的CSV。整个过程里最花时间的不是转换，而是去重和字段对齐。
比如同一个疾病在不同数据源里可能叫“慢性支气管炎”和“慢支炎”，如果直接当两个节点导入，就会在问答时出现问到“慢支炎”查不到“慢性支气管炎”的情况。我处理时用了两层策略：
- 先用字符串归一化把全角转半角、去掉特殊符号、统一括号；
- 再用编辑距离相似度和同名词表做合并，比如“阿斯匹灵”统一为“阿司匹林”。
这个环节没有现成的一键脚本，基本就是写一个pandas处理管道：
df 去重 -> 字段修剪 -> 别名映射 -> 丢弃缺name的行 -> 输出csv建议每次清洗后用df.duplicated(subset=['name']).sum()检查一下重复量，别等导入了Neo4j才发现数据垃圾。
2.3 实体对齐：为什么不能省掉同义词表
医疗领域的术语歧义特别严重，同一个概念可能有商品名、化学名、别名。系统里我维护了一个简单的同名词表，本质是Python字典：
entity_alias = { "阿司匹林": ["阿斯匹灵", "乙酰水杨酸", "Aspirin"], "感冒": ["普通感冒", "上呼吸道感染", "伤风"], "糖尿病": ["消渴症"], }在构建图谱节点时，每遇到一个实体名，先查表确认标准名。这个做法虽然土，但效果特别直接。问答系统里做实体链接时，也靠这张表把用户问题里的口语词转成图谱标准节点名。
3. Neo4j存储层：批量写入比逐条创建快一个数量级
3.1 为什么最终选择图数据库而不是MySQL
我之前也想过，就几十个实体几百条关系，放MySQL不是也行？但真做问答时你就会发现，关系型数据库处理“多跳查询”非常别扭。比如“感冒该去哪个科室”“发热和咳嗽同时出现可能是什么病”这类问题，天然就是图上的遍历。用SQL写JOIN又长又慢，换成Cypher两行就完事。
而且Neo4j还有一个优势：查询结果可以直接按关系图返回，给前端可视化提供天然支持。很多网上的知识图谱项目都搭配Vue3 + ECharts或AntV G6来展示图谱，后端返回节点和边的JSON列表，前端直接渲染。
3.2 py2neo批量导入的工程化写法
项目里常见做法是逐条graph.create()，数据量小没毛病，但实体上千后速度急剧下降。我重构后改成事务批量提交：
from py2neo import Graph, Node, Relationship graph = Graph("bolt://localhost:7687", auth=("neo4j", "123456"), name="medical") tx = graph.begin() for row in data: disease = Node("Disease", name=row["disease"], desc=row["desc"]) symptom = Node("Symptom", name=row["symptom"]) rel = Relationship(disease, "HAS_SYMPTOM", symptom) tx.create(rel) tx.commit()配合Cypher的UNWIND语法还能更快，但工程上事务分批提交已经够用。导入前强烈建议给节点建立唯一约束：
CREATE CONSTRAINT ON (d:Disease) ASSERT d.name IS UNIQUE;这样重复执行脚本时不会生成一堆重复节点。
3.3 导入过程最容易踩的两个坑
第一个坑是NodeAlreadyExists。因为我在导入前先创建了一条MERGE语句，但后面又用CREATE，结果重复执行直接报错。解决办法是把导入逻辑全部改成MERGE，或者每次都先清空库再导入。
第二个坑是中文索引。Neo4j默认的索引对中文不是特别友好，按中文名精确匹配时，需要确保节点属性的字符集没有乱码。CSV文件读取的时候一定要指定encoding='utf-8'，Windows下还常见utf-8-sig，不然第一行会出现看不见的\ufeff，导致按name根本查不到。
4. 问句解析与意图识别：医疗场景适合规则优先
4.1 意图分类：五种问法对应五种查询模板
问答系统最难的不是查询，而是把用户的自然语言映射成机器可执行的意图。这个系统里没有上大模型，原因很简单：医疗知识库是固定且有限的，用规则模板已经能覆盖大多数问题。我把问句按意图分成五类：
| 意图类型 | 触发词示例 | 查询模板 |
|---|---|---|
| 症状查疾病 | 什么病、是什么病、可能是什么 | MATCH (s:Symptom {name:$e})<-[:HAS_SYMPTOM]-(d:Disease) |
| 疾病查症状 | 有什么症状、表现 | MATCH (d:Disease {name:$e})-[:HAS_SYMPTOM]->(s:Symptom) |
| 疾病查药物 | 吃什么药、用什么药、推荐药物 | MATCH (d:Disease {name:$e})-[:USE_DRUG]->(drug:Drug) |
| 药物查说明 | 怎么吃、禁忌、用量 | MATCH (drug:Drug {name:$e}) RETURN drug.function, drug.dosage |
| 疾病查科室 | 挂什么科、哪个科室 | MATCH (d:Disease {name:$e})-[:TREAT_IN_DEPT]->(dept:Department) |
实际做的时候，我直接在代码里维护了一个intent_rules列表，每个元素包含正则表达式和意图名称。判断顺序从上往下，第一个命中的生效。
4.2 实体识别：AC自动机 + 自定义词典 + jieba兜底
意图识别解决“查什么类型”，实体识别解决“查哪个对象”。医疗实体识别我用了三层策略：
第一层是pyahocorasick构建的AC自动机，把实体字典里所有标准名和别名作为模式串，匹配问句里出现过的实体。AC自动机匹配长词效率很高，而且能一次找出多个实体，非常适合实体词典固定不变的情况。
第二层是相似度匹配，针对用户输入错别字或口语化表达的问题。比如用户输入“胃涨”，而系统字典里是“胃胀”，直接用difflib.get_close_matches或编辑距离找出相似实体。
第三层才是jieba分词兜底，因为有些问句里实体比较长，比如“冠状动脉粥样硬化性心脏病”，自定义词典没有完全覆盖，分词后可能被拆碎，这时需要用词性标注和领域词表再拼一次。
4.3 槽位填充和Cypher模板拼接：参数化永远优先
识别出意图和实体之后，最简单粗暴的方式是字符串拼接Cypher。但我强烈建议不要这么干，因为查询里如果有单引号或特殊字符，轻则查询失败，重则引发注入风险。正确做法是用Cypher的传参机制：
query = """ MATCH (d:Disease {name: $name})-[:USE_DRUG]->(drug:Drug) RETURN drug.name, drug.function """ result = graph.run(query, name=entity)对于多实体的情况，比如问题里同时出现“发热”和“咳嗽”，我会把两个症状都查出来，然后找到同时连接这两个症状的疾病集合，实现“多症状联合查询”。这比只匹配一个实体要精准得多。
5. 答疑全流程串起来：一个问句从输入到回答的完整链路
5.1 “感冒了应该吃什么药”的执行过程拆解
下面拿一个真实问句演示全流程。输入是：“感冒了应该吃什么药”。
- 问句预处理：把“感冒了”切分成“感冒”和“了”，去掉停用词“了”“应该”“什么”；
- 意图识别：触发词“吃什么药”命中“疾病查药物”，意图类型是
disease_to_drug； - 实体识别：AC自动机在“感冒”处命中，标准实体名是“感冒”；
- 槽位填充：得到结构化三元组
{disease: "感冒", intent: "disease_to_drug"}； - Cypher查询：执行
MATCH (d:Disease {name:'感冒'})-[:USE_DRUG]->(drug:Drug) RETURN drug.name, drug.function； - 答案生成：从结果里取出药物名称，按照“根据您查询的疾病‘感冒’，推荐以下药物：...”模板拼接成最终文本。
这个流程看似不难，但每一步都有细节。比如“感冒了”里的“了”很容易被误判成实体的一部分，所以停用词表必须放在实体识别之前处理。再比如“吃什么药”和“怎么吃药”看起来很像，但一个是查推荐药物，一个是查用法用量，如果意图规则写得不仔细，很容易混淆。
5.2 查不到答案时怎么办：多跳查询与提示语兜底
真实场景里，用户问的问题往往不在原始谓词范围内。比如用户问“感冒发烧应该吃什么药”，系统只识别出“感冒”和“发烧”两个实体，没有直接“感冒→药物”的关系？实际上有关系，那还好；但“发烧”是症状，“感冒”是疾病，这时就需要把“症状-疾病-药物”两个跳连起来：
MATCH (s:Symptom {name:$symptom})<-[:HAS_SYMPTOM]-(d:Disease)-[:USE_DRUG]->(drug:Drug) WHERE d.name = $disease RETURN drug.name, drug.function如果查询结果为空，系统不要直接返回“我没听懂”，而应该返回提示语，比如“暂时没有找到‘XX’的相关信息，您可以尝试换个说法，例如‘感冒有什么症状’”。我在项目里就写了一个no_answer_tips函数，把空结果、异常结果统一处理成友好文案，避免前端展示一个空页面。
5.3 返回结果给Vue3前端展示的接口设计
这个ZIP包自带一个简单的Web端，前端用的Vue3，页面里嵌入了ECharts关系图。后端接口返回的JSON结构是我设计过的：
{ "code": 0, "msg": "success", "data": { "answer": "推荐药物：复方氨酚烷胺胶囊...", "graph": { "nodes": [{"id": "感冒", "category": "Disease"}, {"id": "发热", "category": "Symptom"}], "edges": [{"source": "感冒", "target": "发热", "relation": "HAS_SYMPTOM"}] } } }前端拿到后，answer字段直接显示在文本对话区，graph字段丢给ECharts生成图谱。但这里有个经典问题，很多同学遇到“知识图谱只显示25个标签”的坑，其实是因为ECharts graph类型的label属性默认开启了show，并且当节点多时引擎会优化掉一些标签。解决方式是手动设置label: { show: true }，或者对图谱做首屏裁剪，只返回一级关系节点。
6. 实战跑通后的复盘：Bug清单与效果评测
6.1 问句评测：十个问题里能答对几个
我把自测问题分成三组：单实体问句、双实体问句、无标准答案问句。整体准确率在80%左右，大部分错误集中在实体别名覆盖不全和意图规则冲突上。
比如“高血压不能吃什么药”意图是“疾病查禁忌药物”，但如果规则表里“不能吃什么”排在“吃什么药”之后，就会被误判成“疾病查药物”，返回推荐药而非禁忌药。解决方法是把否定意图规则放在肯定规则之前，并且给每个意图增加否定词过滤。医疗问答的特殊性就在这里：一个“不”字，结论完全相反。
6.2 改代码时最容易翻车的三个点
第一个是py2neo新旧版本API变化。旧代码用graph.find_one('Disease', 'name', '感冒')，新版本里已经移除了这个方法，得用NodeMatcher的match("Disease", name="感冒").first()。很多人跑不起来都是卡在API迁移上。
第二个是中文编码问题。Windows终端输出中文乱码往往是因为没有设置sys.stdout.reconfigure(encoding='utf-8')，在读取CSV时也需要统一编码。这个问题在Linux服务器上很少见，但在本地跑项目时特别影响调试效率。
第三个是Neo4j配置问题。有些打包项目写的是连接localhost:7474，但py2neo的Graph默认走Bolt的7687端口。端口不对会导致连接超时，而且报错信息并不明显。检查方式很简单，用cypher-shell执行一条查询，看能不能通。
6.3 我对这类项目的总体判断
医疗知识图谱问答系统看起来是“知识图谱 + 问答”两个大词的组合，实际落地时核心难点不在模型，而在数据质量和规则设计。这个ZIP包适合作为学习起点，但不建议直接照搬到生产环境。医疗场景合规要求高，数据、模型、回答内容都需要人工审核，否则容易出风险。
如果让我重新做一遍，我会把重点放在实体对齐和图谱查询的扩展性上，同时把规则引擎改成可配置化的JSON，而不是把意图规则硬编码在Python代码里。这样后续增加新关系和新问法，就不用频繁改核心逻辑了。
最后再分享一个我自己的习惯：拿到这种开源项目包，先看图谱数据量和关系分布，再去看问答模块的规则表。数据不对，后面一切白搭。真正把知识图谱跑通之后，你再去问它“发热咳嗽可能是什么病”，看到它能准确返回多个候选疾病的时候，那种成就感还挺强的。
本文还有配套的精品资源，点击获取
