简介基于Python实现的医疗知识图谱知识问答系统完整项目包面向Python学习者、知识图谱初学者以及需要课程设计参考的高校学生。项目从零构建医疗知识图谱并基于所建图谱实现无需训练、响应速度快的预设式对话系统同时详细说明这种方案难以分析任意输入、输出只能命中预设内容的局限为后续引入深度学习模型指明改进方向。资源共包含58个文件以Python源码、JSON/TXT数据、PNG/JPG截图、Word设计报告为主另有XML配置与依赖清单整体压缩包约20.13MB文件类型明确、目录分区清晰可对照设计报告与截图快速还原项目环境并理解各模块作用。目前已有2570人浏览学习适合用来掌握医疗知识图谱的构建流程、问答系统中的意图分类与问题解析逻辑以及规则式问答与深度学习方案的差异。资料内附完整设计报告文档、项目源码及运行数据可直接运行调试便于梳理疾病、药品、症状等实体关系也可作为课程设计或毕业设计的参考模板。1. 医疗知识图谱问答系统不训练模型也能跑出可用问答医疗领域的知识问答一直被误以为必须上深度学习模型可这份基于 Python 的医疗知识图谱问答系统走的是另一条路——用 Neo4j 图数据库加规则匹配就把问答跑通了。它的核心价值在于先构建医疗知识图谱再基于图谱实现对话系统整个过程不需要训练运行速度很快。适合正在做课程设计、毕业设计或想快速理解知识图谱落地流程的开发者。我在本地把它完整跑通后确认这套系统确实能回答“XX病该吃什么药”“XX症状怎么办”这类预定义问题但它也有明显边界输入不能太随意输出是预设好的灵活度有限。下面我按实际拆解的顺序从项目构成讲到知识图谱构建再到问答链路实现和踩坑记录。2. 先拆资源包三个模块各自负责什么拿到压缩包后先看整体目录结构再动手这步能省掉很多后面找文件的麻烦。这份资源的核心是三个 Python 模块加一份设计报告外加若干截图。我建议按编号顺序去读代码因为 1 和 2 是基础3 是上层应用。2.1 模块划分与文件清单解压后顶层目录有三块simpleKnowledgeGraph、medicalKnowledgeGraph、KGchatbot外加设计报告.docx和README.md。simpleKnowledgeGraph/simpleKG.py是一个极简的图构建示例适合先跑通图数据库的连接和节点关系写入规模很小作为热身正好。medicalKnowledgeGraph/buildKG.py是真正的重头戏它读取data/medical.json结构化医疗数据并写入图数据库。KGchatbot/则是问答端包含三个核心脚本question_classifier.py问题分类、question_parser.py查询语句解析、answer_search.py答案查询以及一个chatbot_graph.py把它们串起来。dict/目录下按词表类型拆分了drug.txt、check.txt、food.txt、symptoms.txt、producer.txt、disease.txt、department.txt、deny.txt。这里有个细节值得注意deny.txt是负向词表用于识别“不吃药”“不可以做检查”这类否定表达这在早期规则问答里非常关键。以下是我的阅读建议顺序先运行simpleKG.py确认 Neo4j 连接没问题。再运行buildKG.py把完整医疗图谱写入数据库。最后进KGchatbot目录依次读question_classifier.py、question_parser.py、answer_search.py再启动chatbot_graph.py。2.2 设计报告和 README 的查阅价值设计报告.docx不是摆设。它里面有系统架构图、核心流程说明和运行截图写课程设计文档时可以直接作为参考骨架。我建议先把报告里的“系统总体设计”和“核心功能实现”两章看完再去读代码这样每个函数在整体流程中的位置会更清楚。README 则是一个快速索引标注了各模块的启动顺序和环境要求照着走基本不会有前置性错误。有一点要特别注意压缩包内的__pycache__目录和.pyc文件是别人运行过的缓存产物不要依赖它们。你的 Python 版本如果不一致直接删掉这些缓存重新生成即可。.idea目录是 PyCharm 的项目配置文件与本项目逻辑无关可以忽略。3. 图谱构建medical.json 到 Neo4j 的完整写入知识图谱的构建是整个系统的地基。如果你的图谱数据没写对后面问答环节查不到任何东西。这部分我拆成两步来讲先看数据处理逻辑再看写入图数据库时的关键配置。3.1 buildKG.py 的数据处理逻辑buildKG.py的核心任务是解析data/medical.json提取实体和关系写入 Neo4j。它的代码结构大致如下import json from py2neo import Graph, Node, Relationship # 连接 Neo4j 图数据库默认密码为 neo4j注意按实际修改 graph Graph(http://localhost:7474, auth(neo4j, 123456)) # 读取原始医疗数据 with open(data/medical.json, r, encodingutf-8) as f: medical_data json.load(f) print(f共加载 {len(medical_data)} 条医疗记录)这段代码先建立与 Neo4j 的连接然后把整个medical.json读入内存。auth参数里的密码必须改成你本机 Neo4j 设置的密码否则后续全部操作都会报 401 认证错误。我一般会额外打印记录数确认 JSON 解析成功再继续。加载之后接下来是遍历每条记录抽取“疾病”节点和“症状”“药品”“检查项目”“科室”等关联节点for record in medical_data: disease_name record[name] disease_node Node(Disease, namedisease_name) graph.merge(disease_node, Disease, name) # 提取症状列表建立疾病指向症状的关系 for sympton in record.get(symptom, []): sympton_node Node(Symptom, namesympton) graph.merge(sympton_node, Symptom, name) rel Relationship(disease_node, HAS_SYMPTOM, sympton_node) graph.merge(rel)这段代码的理念是“实体存在则合并不存在则创建”graph.merge是幂等操作重复跑脚本不会制造重复节点。Relationship的类型用动词短语如HAS_SYMPTOM、DRUG_OF来表达语义直观也方便后面问答时根据关系类型定位答案。record[name]是疾病的名称在原始数据中每个记录都以疾病名称为主键所以我用name属性做 merge 时的唯一性依据。data/medical.json中真正可用的字段主要是name、symptom、drug、check、food、producer、department等构建时会按这些字段生成节点和关系。如果你想把词表扩充直接往dict/*.txt里追加词语即可图谱构建时不受影响。3.2 Neo4j 写入时的三个关键配置写入图数据库前有三个我需要重点确认的地方第一个是 Neo4j 版本兼容性。项目原生基于 Neo4j 3.x 和 4.x 开发py2neo的 API 在 4.x 与 5.x 之间有差异。我用的是py2neo5.x 配合 Neo4j 4.4比较稳。如果你装了 Neo4j 5.x建议把py2neo升级到匹配版本。第二个是节点合并策略。graph.merge(node, primary_label, primary_key)的第三个参数必须传name这是为了保证数据幂等。如果不指定主键重复执行脚本会生成大量重复节点问答结果会变成重复数据非常难排查。第三个是索引。数据量大的时候查询性能会明显下降但当前medical.json只有几千条实体不建索引也能跑加上 Neo4j 默认有 schema 索引优化这个体量不用担心性能瓶颈。执行完buildKG.py之后可以用 Neo4j 浏览器执行MATCH (n) RETURN n LIMIT 25验证节点是否正常写入。如果出现中文乱码或空白先检查 JSON 文件编码是否为 UTF-8以及终端控制台是否支持中文显示。4. 问答主流程分类、解析、查询三步各做什么图谱构建完成后问答系统的核心链路就集中在KGchatbot目录。chatbot_graph.py作为主入口按“问题分类 → 查询语句生成 → 图数据库查询 → 答案格式化”的顺序执行。我用实际运行过程来演示这三步到底做了什么。4.1 主控脚本 chatbot_graph.py 的调度逻辑chatbot_graph.py是整个问答流程的控制中心约几十行代码就把三个模块串了起来。运行方式非常简单python chatbot_graph.py启动后会进入一个交互式命令行输入“感冒了怎么办”这类问题系统就会调用全链路并返回答案。核心逻辑简化后如下所示from question_classifier import QuestionClassifier from question_parser import QuestionPaser from answer_search import AnswerSearcher # 构建分类器、解析器、搜索器三个核心组件 classifier QuestionClassifier() parser QuestionPaser() searcher AnswerSearcher() while True: question input(用户) if question exit: break # 第一步识别问题中的实体和意图 res_classify classifier.classify(question) # 第二步将意图和实体转换为 Cypher 查询语句 res_sql parser.parser_main(res_classify) # 第三步在知识图谱中执行查询组装最终答案 final_answers searcher.search_main(res_sql) # 输出答案 for answer in final_answers: print(小智, answer)主流程看起来很简单但真正的工作量都在被调用的三个模块里。classify()返回的是一个字典形如{args: {疾病: [感冒]}, question_types: [disease_symptom]}parser_main()根据这个字典拼接出对应的 Cypher 语句列表search_main()执行查询并把结果转成自然语言答案。4.2 question_classifier.py基于词表的问题意图识别这个模块不涉及任何机器学习。它做的事情可以概括为用词表匹配医疗实体用正则匹配问题意图。之所以能这么做是因为医疗问题的句式相对固定预定义意图足够覆盖日常查询。import re # 疾病词表、症状词表、药品词表等从 dict 目录加载 disease_wds [w.strip() for w in open(dict/disease.txt, encodingutf-8)] symptom_wds [w.strip() for w in open(dict/symptoms.txt, encodingutf-8)] def classify(self, question): # 保存用于后续查询的实体字典 self.ner_dict {} # 疾病实体识别常见做法是逐词匹配 for w in disease_wds: if w in question: self.ner_dict[疾病] w # 意图识别使用正则表达式匹配 if re.search(r什么症状, question): return {args: self.ner_dict, question_types: [disease_symptom]}注意它的匹配顺序先认实体再定意图。实体缺失的情况下意图再正确也无法生成查询语句因为 Cypher 里没有参数可用。意图类型与问题模版的对应关系是整个问答系统设计的核心。比如“XX病有什么症状”匹配到disease_symptom“XX病不能吃什么”会先识别出deny词表再进入disease_not_food意图。4.3 question_parser.py 与 answer_search.py生成并执行 Cypherquestion_parser.py里的核心是把意图映射到具体的 Cypher 模板。以下是一段真实存在的映射逻辑我做了简化# 意图对应不同的 Cypher 查询模板 if question_type disease_symptom: cypher MATCH (d:Disease)-[:HAS_SYMPTOM]-(s:Symptom) WHERE d.name{疾病} RETURN s.name elif question_type disease_drug: cypher MATCH (d:Disease)-[:DRUG_OF]-(m:Drug) WHERE d.name{疾病} RETURN m.name查询模板里的{疾病}会被question_classifier识别的实体替换。之后answer_search.py接收 Cypher 语句执行查询并把返回的节点属性整理成字符串。如果查不到结果它不会抛异常而是返回空列表此时chatbot_graph.py会回退到兜底话术“这个问题我暂时无法回答”这种兜底设计在规则型问答里很常见。这里要强调一个关键点意图映射表的质量决定了系统能回答什么、不能回答什么。原项目已经内置了约 10 种意图类型覆盖疾病症状、推荐药品、推荐食物、不能吃什么、推荐检查项目、推荐科室等。如果你要扩展新意图需要同时修改三个文件词表文件、question_classifier.py的正则规则、question_parser.py的意图映射表三者缺一不可。5. 避坑指南实体识别、依赖安装与中文编码的六个大坑这部分是我完整跑通资源后结合常见问题和原项目的代码实现总结出的踩坑记录。每一条都是实测遇到过的按“现象 → 原因 → 解决”的顺序写清楚。5.1 实体识别总是为空词表匹配顺序问题现象无论输入什么问题question_classifier返回的ner_dict都是空字典后续查询直接走兜底话术。原因question_classifier.py中实体匹配使用的是逐词遍历词表判断子串如果词表里没有这个疾病名就无法识别。另一个常见情况是输入“感冒了”而不是“感冒”词表里只有“感冒”因此“感冒了”能匹配成功但如果输入是“流行性感冒”词表没有这个词就会失败。解决优先使用词表内标准疾病名进行测试。若要扩大词表直接把新词追加到dict/disease.txt一个词占一行。注意不要包含空格或特殊字符否则匹配会失效。5.2 Neo4j 连接认证失败密码或地址不匹配现象运行buildKG.py提示Unauthorized或Authentication failed。原因py2neo.Graph初始化时使用了默认地址http://localhost:7474和密码但本机 Neo4j 的实际密码不是这个或者 Neo4j 服务还没启动。解决先确认 Neo4j 服务已启动浏览器能打开http://localhost:7474再修改buildKG.py里的auth参数。如果是 Neo4j 4.x 以上版本http://localhost:7474依然可用不必改成 bolt。5.3 中文乱码控制台显示为问号现象启动chatbot_graph.py后打印的中文内容变成???或乱码。原因Windows 下命令行默认编码不是 UTF-8而 Python 脚本里的字符串是 UTF-8 编码。解决在运行命令前设置环境变量或者直接把脚本头部加入编码声明。Windows 下推荐这样启动chcp 65001 python chatbot_graph.py5.4 py2neo 版本不兼容API 调用直接报错现象安装最新版py2neo后graph.merge或Relationship用法报出TypeError。原因项目基于较早的py2neo4.x 编写最新版 5.x 调整了部分 API 签名。解决建议锁定版本由项目依赖决定。我的实际环境是py2neo 5.0.1配合 Neo4j 4.4 运行无问题。在命令行执行pip install py2neo5.0.15.5 查询结果为空但图谱里明明有数据现象知识图谱里已有“感冒”相关节点但问答查不到答案。原因问题分类器识别出的实体有误或生成的 Cypher 语句关系类型与实际写入不符。比如buildKG.py里写的是HAS_SYMPTOM但question_parser.py使用的是SYMPTOM_OF对不上导致查询结果为空。解决先在question_classifier里打印识别出的实体和意图再打印生成的 Cypher 语句最后在 Neo4j 浏览器里手动执行这条 Cypher 验证关系是否存在。不一致就统一两处的关系类型名称。5.6 对话系统反复走兜底回答别急着改词表现象问题一旦偏离内置模板比如“我头疼该挂什么科”能答但“我头痛三天了”就答不出来。原因规则系统对句式和词形极其敏感。“头痛”可能不在症状词表里或者词表里有“头痛”但意图模板没有设计“症状推荐科室”这个类型。解决先不要盲目加词表而是把所有意图模板过一遍确认目前支持哪几类问题。原项目内置的问答类型有限只覆盖高频医疗查询如果你的场景需要更多类型就必须扩展意图映射表。这种情况正是该结合深度学习模型去做的方向后续想要更智能终究要引入深度学习模型分析输入原项目作者也在 README 中提到了这个局限。6. 进阶玩法自定义问答类型与验证图谱正确性的两个技巧到这步系统已经能跑了。如果想让项目更匹配自己的场景我建议做两件小事扩展自定义问答类型以及用批量测试验证图谱数据质量。6.1 扩展自定义问答类型三步完成新增意图以新增“XX病不能做什么检查”为例我需要同时修改三个地方。先在dict/deny.txt里确认含有“不能”“不可以”这类否定词然后在question_classifier.py中增加正则规则if re.search(r不能(做)?(什么)?检查, question): self.ner_dict[检查] self.check_wds return {args: self.ner_dict, question_types: [disease_not_check]}接着在question_parser.py的意图映射表中增加对应 Cypherif question_type disease_not_check: cypher MATCH (d:Disease)-[:CHECK_NOT]-(c:Check) WHERE d.name{疾病} RETURN c.name最后在answer_search.py里输出答案时拼接成自然语句。这里要特别提醒新增的关系类型必须在buildKG.py中同步写入否则图谱里根本没有CHECK_NOT关系查了也是空。整个扩展流程的改动点可以概括为词表定义 → 意图识别 → Cypher 生成 → 答案格式四层对齐才行。6.2 用 numcha 验证图谱覆盖率图谱构建完成后可以用 Neo4j 自带的查询来验证数据完整性。我通常会跑这几个 CypherMATCH (d:Disease) RETURN count(d); MATCH (d:Disease)-[:HAS_SYMPTOM]-(s:Symptom) RETURN d.name, collect(s.name) LIMIT 5; MATCH (d:Disease) WHERE NOT (d)-[:DRUG_OF]-() RETURN d.name LIMIT 10;第一条统计疾病节点总数第二条抽查疾病与症状关系是否建立第三条找出没有任何药品关系的疾病节点——这些节点可能是数据缺失也可能是该疾病在原始数据里就没有对应药品。在这个资源包的语料里第三条返回空是正常的因为medical.json中的记录相对完整。真正的价值在于把这三条语句固化成模板以后构建任何图谱都可以用一模一样的验证流程。而这也正是我从这个项目里学到最深刻的一点规则型问答的边界非常清晰它不需要训练响应极快但灵活度有限。如果你要把它接入真实业务必须接受一个事实——自然语言表达千变万化规则只能覆盖有限范围。许多场景下我习惯的做法是先用这份项目跑通基础链路把知识图谱和问答框架稳定下来再在意图识别层逐步引入深度学习模型做语义匹配这样图谱的价值能最大化问答也能逐步脱离模板限制。从那以后我每次做完图谱和问答系统都强制走一遍“实体识别打印 → Cypher 打印 → 图谱查询 → 答案输出”的四步验证确保每一环的数据都在链路上真实流动而不是某个环节静默返回空。希望这套拆解思路对你跑通这个项目也有帮助。本文还有配套的精品资源点击获取