简介一份基于Python知识图谱的医疗领域问答系统毕业设计项目源自大四高分设计经导师指导并认可评审达99分完整代码与文档说明齐备确保可直接运行尤其适合计算机相关专业准备毕设的学生也可用于课程设计或期末大作业。资源共188个文件涵盖Python源码、TXT说明文档、HTML前端页面、JSON配置、SQLite/Neo4j数据库文件、CSS与JS脚本等包体约115.09MB从知识图谱构建、问句解析、实体识别到答案检索均有对应实现结构清晰便于二次开发与学习。已有78人学习下载内容包含完整项目代码、环境配置说明与文档资料可帮助初学者快速复现医疗问答流程也能作为毕业设计答辩与论文撰写的参照蓝本。1. 先别急着写代码这个医疗问答系统到底要交付什么毕业设计题目里写着“基于python知识图谱医疗领域问答系统实现项目完整代码文档说明”时多数人真正想要的是一个能跑通、能讲清楚、能在答辩时拿得出手的完整方案。这个项目的本质并不神秘用Python把医疗资料整理成一张图数据库里的实体关系网络用户用中文问一句系统把这句话解析成意图和实体再转成图查询最后把答案拼回自然语言返回前端。它解决的是传统关键词检索没法处理的关联问题比如“高血压有什么症状”“这个病该挂哪个科”这类需要多实体关联的提问。适合你有Python基础、学过一点数据库、想做全栈小系统但暂时不想碰深度学习。这个智能问答系统做完你收获的不只是一份代码还有一整套“数据→图谱→问答→展示”的工程链路。2. 从病历文本到知识图谱本体建模、实体识别与Neo4j导入整个项目最容易被低估的一步不是问答算法而是知识图谱构建。工业场景下的知识图谱设计通常先谈语义层再谈存储医疗领域也一样。你不先把实体、关系、属性定义清楚后面写多少问答逻辑都会卡在查不出数据上。2.1 先定本体再谈数据疾病、症状、药物、检查、科室的关系设计常见做法是先把医疗知识浓缩成五类实体疾病、症状、药物、检查项目、科室。属性方面疾病可以带简介、发病部位药物可以带用法、禁忌检查项目可以带检查说明。不追求医学级的完备够支撑问答即可。实体类型 | 关键属性 | 典型示例 疾病 | 名称、简介 | 高血压、糖尿病 症状 | 名称、部位 | 头晕、心悸 药物 | 名称、用法、禁忌 | 硝苯地平 检查项目 | 名称、检查说明 | 血压测量、空腹血糖 科室 | 名称 | 心血管内科关系类型用有向边表达比如疾病到症状用HAS_SYMPTOM疾病到药物用USE_DRUG疾病到检查用NEED_CHECK疾病到科室用VISIT_DEPARTMENT。这些关系名建议统一定成大写带下划线的形式后面写Cypher时不容易拼错。关系也可以带属性比如药物关系里的“用法用量”但毕业设计阶段可以暂时省略保持图结构简洁。我在搭这类知识图谱时的习惯是先把实体和关系画在一张纸上实体画方框关系画箭头。不要急着写代码先确认这些问题能回答高血压节点能不能通过一条路径关联到所有症状药物节点是不是被多个疾病共享如果答案是否定的说明本体设计可能有漏洞。医疗领域天然的复杂性是疾病与症状多对多必须允许一个症状被多个疾病引用姓名属性不能做唯一主键业务主键才是。2.2 数据处理清洗掉空行、合并同义词、统一编码数据规模不需要很大但质量要过得去。常见做法是准备一张CSV每行一个三元组列是head、relation、tail对应“实体-关系-实体”。我一般先用pandas把这份原始数据读进来做清洗处理掉空值、首尾空格、重复三元组。这里的关键点是用utf-8-sig编码读入因为从Excel导出的CSV通常带BOM头直接utf-8会在第一个列名里留下“\ufeff”。这一段逻辑不复杂但少做一步后面全是玄学报错。import pandas as pd # 读取三元组文件utf-8-sig兼容Excel导出的BOM头 df pd.read_csv(data/medical_triples.csv, encodingutf-8-sig) # 去掉头或尾为空的残缺三元组 df df.dropna(subset[head, relation, tail]) # 去除实体名和关系名两边的空白 df[head] df[head].astype(str).str.strip() df[tail] df[tail].astype(str).str.strip() df[relation] df[relation].astype(str).str.strip() # 去掉完全重复的三元组 df df.drop_duplicates(subset[head, relation, tail]) # 同义词映射先归一化再入库 SYNONYMS { 发烧: 发热, 高血压病: 高血压, 糖尿病病: 糖尿病, } df[head] df[head].replace(SYNONYMS) df[tail] df[tail].replace(SYNONYMS) print(df.shape)这段代码做了三件事剔除残缺三元组、规范化实体名、去重。参数说明里最值得注意是dropna(subset...)它只在指定列上检查空值而不是整行全查否则会误删掉那些tail为空但head还有用的行。replace(SYNONYMS)是原地替换式处理能让后续构建图谱时不会同时存在“发烧”和“发热”两个节点。至于数据量我建议最少准备500到1000条独立三元组覆盖40到80种疾病这样问答系统才有内容可以查答辩时也不会显得单薄。2.3 导入Neo4j用py2neo把三元组装进图并给查询入口建索引Neo4j构建知识图谱有两个常用姿势一种是用Cypher手写MERGE语句另一种是用py2neo的Python API操作。我推荐混用建索引用Cypher节点和关系的批量导入用Python循环搭好结构再一次性提交。注意py2neo对Neo4j版本很敏感Neo4j 4.x对应py2neo 2021.xNeo4j 5.x建议直接换官方neo4j驱动。别在这上面硬耗这是很多人第一个翻车点。from py2neo import Graph, Node, Relationship # 连接图数据库地址、账号、密码按实际情况改 graph Graph(bolt://localhost:7687, auth(neo4j, your_password), namemedical_kg) # 给实体类型建索引大部分查询都从疾病名开始必须在name上建索引 graph.run(CREATE INDEX IF NOT EXISTS FOR (d:Disease) ON (d.name)) # 按三元组批量创建节点和关系 for _, row in df.iterrows(): head_type, rel, tail_type row[head_type], row[relation], row[tail_type] head_node Node(head_type, namerow[head]) tail_node Node(tail_type, namerow[tail]) rel_obj Relationship(head_node, rel, tail_node) graph.merge(head_node, head_type, name) graph.merge(tail_node, tail_type, name) graph.merge(rel_obj)graph.merge(node, label, key)的三个参数分别是节点、标签、主键属性。这里用name做主键意味着同一个名字的疾病节点不会重复创建这是整个知识图谱构建里最重要的merge语义。如果写成graph.create()重复运行脚本会产生大量重复节点数据显示翻倍但你根本发现不了。关系对象用Relationship(head_node, rel, tail_node)构建时rel是一个字符串关系类型比如“HAS_SYMPTOM”之后在Cypher里就能用[:HAS_SYMPTOM]匹配。循环里每个三元组执行三次merge数据量到几千条时耗时几十秒这是正常现象别以为死循环了。3. 问答系统主链路把自然语言拆成实体、意图和查询图谱有了之后核心问题变成“怎么让计算机看懂中文问题”。不用引入BERT或大型模型基于实体词典和规则模板就能做出一个让答辩老师信服的问答链路。整条链路分三段实体识别、意图分类、Cypher生成。很多人一上来就写正则匹配问句结果“高血压有什么症状”能答“高血压的常见症状是什么”答不上原因就是忘记先把实体剥离出来再匹配意图。3.1 问句解析用实体词典做最长匹配别一上来就分词先做实体识别。医学名词长短不一像“高血压”和“高血压性心脏病”如果按普通方法分容易被短词抢走。常见做法是把知识库里所有实体名收集起来按长度从长到短排序再逐个去问句里做包含匹配命中的实体从问句里记录成功后保留它并用占位符替换避免后续意图正则把它当成干扰文本。class EntityRecognizer: def __init__(self, kg_entities): # kg_entities 是 dict: {实体名: 实体类型} self.names sorted(kg_entities.keys(), keylen, reverseTrue) def recognize(self, question): # 返回命中的实体列表以及去掉实体文本后的剩余问句 matched [] remain question for name in self.names: if name in remain: matched.append({name: name, type: self.entities[name]}) remain remain.replace(name, , 1) if len(matched) 2: break return matched, remainkeylen, reverseTrue是最关键的一个参数它让“高血压性心脏病”排在“高血压”前面保证长实体优先匹配。用占位符替换是有意保留疑问词部分比如“高血压有什么症状”替换后剩余“有什么症状”这比直接分词更干净。循环里设置最多匹配两个实体因为毕业设计问答系统里超过两个实体的问句往往是复杂联合用药或鉴别诊断类问题规则系统处理不好与其答错不如进兜底流程。3.2 意图分类与模板映射维护一张意图模板表按优先级匹配实体识别出来后看剩余文本落在哪个模板里。模板表可以直接做成Python列表每项包含意图名称和一个正则表达式。注意模板顺序很重要我一般把最具体的放前面比如“挂什么科/哪个科”要放在“什么/哪些”之前否则“高血压挂哪个科”会被“什么”类模板吞掉。import re INTENT_PATTERNS [ (department, re.compile(r挂(什么|哪个|啥)科)), (symptom, re.compile(r有(什么|哪些|啥)症状)), (drug, re.compile(r吃(什么|哪些|啥)药)), (check, re.compile(r做(什么|哪些|啥)检查)), (description, re.compile(r是(什么|怎么)(病|回事|引起的))), ] def parse_intent(remain_question): for intent, pattern in INTENT_PATTERNS: if pattern.search(remain_question): return intent return unknown正则里的(什么|哪些|啥)是模板变体层“啥”“哪些”都是口语问法不列全就会造成命中率起伏。我用search而不是match因为剩余问句里可能还夹杂着“这个病”“怎么办”这类前缀后缀。模板表设计好之后整套问答系统的意图覆盖全看你往这个表里加了多少规则。常见的数量是15到20个模板足以覆盖毕业设计需求。如果识别到“unknown”直接返回提示语不建议硬猜硬猜出来的答案往往是错的答辩时反而露怯。3.3 答案生成与兜底逻辑把查询结果拼成人话查不到就明说拿到实体和意图之后下一步是生成Cypher。这一步不要用字符串拼接来拼节点名必须用参数绑定否则中文实体名含有引号、括号时会导致查询报错也顺手解决了Cypher注入问题。def build_cypher(entity_name, entity_type, intent): # 按意图映射到不同的Cypher模板 if intent symptom: return ( MATCH (d:Disease {name:$name})-[:HAS_SYMPTOM]-(s:Symptom) RETURN s.name AS answer LIMIT 10 ) if intent drug: return ( MATCH (d:Disease {name:$name})-[:USE_DRUG]-(m:Drug) RETURN m.name AS answer LIMIT 10 ) if intent department: return ( MATCH (d:Disease {name:$name})-[:VISIT_DEPARTMENT]-(c:Department) RETURN c.name AS answer LIMIT 5 ) return None参数说明$name是Cypher里CQL的参数占位符实际值通过graph.run(cypher, nameentity_name)传入。这里把LIMIT 10写进模板是为了防止某个症状连了太多疾病导致返回超长列表。返回结果建议控制在5到10个以内答辩demo时展示太长反而像临时拼凑。最终答案组织根据实体名称拼接records graph.run(cypher, nameentity_name).data() if records: answers [r[answer] for r in records] return f{entity_name}常见的表现有 、.join(answers) else: return f知识库里暂时没有查到“{entity_name}”的相关{intent}信息。这段逻辑的亮点是答案模板和查询模板严格分开。查询模板负责从图里取数据答案模板负责把多条结果合成一句中文。答辩时老师问“如果没查到怎么办”这个兜底文案就是最好的回答——系统知道自己不知道。这里唯一值得留意的是返回的answer字段名要和Cypher里AS answer保持一致改错大小写时你会得到一条诡异的KeyError。4. 把整个项目跑起来工程目录、Flask后端与前端页面问答核心逻辑跑通后还要把它变成能演示的系统。这个阶段目标是前端输入一句话后端返回答案整个过程能在浏览器里完成。选Flask就够了它轻、文档多、答辩时也容易分块讲。工程目录不用追求复杂但一定要分层别把所有代码堆在一个main.py里。4.1 最小可运行的目录结构与配置文件我常用的目录结构如下它把数据、图谱初始化、问答解析、Web接口分成了四个独立模块medical_kg_qa/ ├── app.py ├── config.py ├── data/ │ └── medical_triples.csv ├── kg/ │ ├── __init__.py │ ├── neo4j_conn.py │ └── build_graph.py ├── qa/ │ ├── __init__.py │ ├── entity_recognizer.py │ ├── intent_parser.py │ └── answer_generator.py └── templates/ └── index.htmlconfig.py是所有环境配置的唯一入口不要在多个文件里各自写数据库密码改起来容易漏。一个够用的配置模块长这样# config.py集中管理图数据库连接信息 NEO4J_URI bolt://localhost:7687 NEO4J_USER neo4j NEO4J_PASSWORD your_password NEO4J_DATABASE medical_kg参数说明URI写成bolt://开头不是http://这一点经常有人搞混。密码不要用“123456”这种本地开发无所谓但答辩演示时如果数据库老是弹认证错误会非常尴尬。如果你还没装Neo4j先到官网下载社区版启动后用浏览器打开http://localhost:7474修改初始密码再跑项目。环境细节上建议用Python 3.8到3.11之间的版本太新的Python版本有时候会遇到依赖库还没跟上导致安装失败这是常见的环境坑。4.2 后端接口用Flask把问答链路暴露成HTTP服务后端只做一件事接收前端传来的question调用问答链路得到答案以JSON格式返回。这里需要注意请求和响应格式要固定我一般定义成{question: ..., answer: ..., hit: true}。hit字段表示是否命中知识库前端可以根据它决定要不要显示兜底提示。from flask import Flask, request, jsonify, render_template from qa.answer_generator import answer_question app Flask(__name__) app.route(/, methods[GET]) def index(): return render_template(index.html) app.route(/api/ask, methods[POST]) def ask(): # 前端传来的JSON必须包含question字段 data request.get_json(forceTrue) question (data.get(question) or ).strip() if not question: return jsonify({code: 400, msg: question不能为空}) result answer_question(question) return jsonify({code: 0, data: result})forceTrue的作用是即使请求头没写Content-Type: application/json也能强解析调试时非常省事但上线前建议去掉。answer_question是你在第3章实现的问答链路入口函数它内部依次调用实体识别、意图解析、Cypher查询。启动方式是在终端执行python app.pyFlask默认监听5000端口浏览器访问http://localhost:5000就能看到前端页面。如果你改了代码但页面没变化先看看终端里有没有报错再强制刷新浏览器缓存这个排查顺序能省掉很多瞎猜时间。4.3 前端页面一个不需要框架的问答题页面前端不需要搞Vue或React因为答辩demo重点在功能一个单页HTML加fetch就够。关键点有三个页面编码要utf-8、API路径要带/api前缀、按钮点击后要处理加载中的状态。!DOCTYPE html html langzh-CN head meta charsetutf-8 title医疗知识图谱问答系统/title /head body h1医疗知识图谱问答系统/h1 input idquestion typetext placeholder请输入问题如高血压有什么症状 stylewidth: 400px; button idaskBtn onclicksendQuestion()提问/button div idanswer/div script async function sendQuestion() { const q document.getElementById(question).value.trim(); if (!q) return; const resp await fetch(/api/ask, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({question: q}) }); const data await resp.json(); const answerDiv document.getElementById(answer); if (data.code 0) { answerDiv.textContent data.data.answer; } else { answerDiv.textContent 请求失败请稍后再试; } } /script /body /html这里的javascript代码里headers里的Content-Type必须和Flask端期望一致否则request.get_json()可能拿到None。textContent赋值方式比innerHTML更安全因为答案里可能包含像“”这样的特殊字符用innerHTML会被浏览器当成HTML解析轻则样式乱掉重则页面错乱。页面虽然简单但已经形成了完整的“输入→请求→问答→渲染”闭环。你可以在这个基础上去美化样式、加历史记录都是加分项。5. 医疗问答系统避坑实录从版本兼容到查询性能的5个坑这部分全是实践里踩出来的坑。数据、图谱、查询、前后端联调每一个环节都有足以让人卡一整天的刁钻问题。以下现象、原因、解决方式按真实排查顺序写你遇到类似情况可以直接照着查。5.1 py2neo连不上Neo4j版本匹配是第一道坎现象运行导入脚本时报ValueError: The database is not configured for Bolt或AuthorizationFailed而在Neo4j浏览器里能正常登录。原因Neo4j从4.0开始强化了数据库认证与协议版本py2neo 2021.2.3之前的版本无法和Neo4j 4.x正常建连。如果你装的是Neo4j 5.x同时还用py2neo协议完全不匹配是意料之中的。很多人第一反应是改密码、改URI实际都白费力气。解决先确认版本组合。Neo4j 4.x就装py2neo2021.2.3Neo4j 5.x直接改用官方驱动from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) with driver.session(databasemedical_kg) as session: result session.run(MATCH (n) RETURN count(n) AS cnt) print(result.single()[cnt])driver.session(database...)参数可以指定要访问的图数据库名。这里改用官方驱动后原先的graph.run()写法要替换成session.run()。我建议在项目一开始就决定用哪套驱动不要中途切换否则所有查询代码都要改。5.2 中文乱码与编码不一致CSV、Python脚本、数据库各说各话现象Neo4j浏览器里能查到中文但页面上返回的答案是乱码或者前端输入中文后Flask端收到的question变成一串问号。原因三个环节的编码不统一。CSV文件是GBK编码Python读取时用了utf-8HTML文件没有meta charsetutf-8浏览器默认按拉丁字符解析Neo4j导入时没有指定字符集。这三个里任何一个出错都会在链路末端表现成乱码。解决统一成utf-8一个环节都不要放过。CSV读取用encodingutf-8-sigPython文件保存时选UTF-8HTML加meta标签。如果数据库里已经导入了乱码数据先删除那些节点重新导入不要试图在查询里replace乱码字符那是治标不治本。排查顺序建议从前端到后端再到数据库浏览器开发者工具里看网络请求的响应体最快能定位是哪一层出的问题。5.3 同义词没有合并问“发烧”答不出“发热”是规则系统最大的漏洞现象用户问“发烧怎么办”系统返回“未命中知识库”但把问题换成“发热”答案马上出来了。原因实体识别阶段只匹配了知识库里已有的实体名。你导入了“发热”节点但没有告诉系统“发烧”就是“发热”。这类问题在医疗领域特别多高血压病和高血压、糖尿病和糖尿病病、心慌和心悸。规则系统没有词向量泛化能力同义词表就是它的记忆。解决把同义词表从数据清洗阶段挪到实体识别阶段识别时先做一次归一化替换。这里有一个实操细节不要在原始问句上直接替因为用户可能还是想看原词而是把匹配词归一化后去查图谱返回答案时再用原词组织语言。def normalize_question(question): for alias, std_name in SYNONYMS.items(): question question.replace(alias, std_name) return question这段替换逻辑要在EntityRecognizer之前执行才能保证“发烧有什么症状”变成“发热有什么症状”。同义词表的来源不用太复杂你只需要把所有实体名过一遍把常见的口语叫法、英文缩写、别名列出来就行50个左右就足够让命中率明显上升。5.4 Cypher查询超时图不大但不代表不会慢现象系统运行一段时间后某些问题点击后要卡十几秒才返回Neo4j控制台打出This query would be too large的警告。原因实体节点没有建索引每次查询都全表扫描。更隐蔽的一个原因是你在match时没有限制标签比如MATCH (d {name:$name})这种写法会让Neo4j在所有节点里找name属性即使只写MATCH (d:Disease {name:$name})如果没有对:Disease(name)建索引同样很慢。解决用Cypher给实体类型的name属性建索引CREATE INDEX IF NOT EXISTS FOR (d:Disease) ON (d.name); CREATE INDEX IF NOT EXISTS FOR (s:Symptom) ON (s.name);索引建完后绝大多数单实体查询应该毫秒级返回。如果某些查询仍然慢最可能是关系方向写反了导致候选集过大检查一下(:Disease)-[:HAS_SYMPTOM]-(:Symptom)和反方向查询的语义差别。在毕业设计数据量下没有任何查询需要超过3秒如果遇到优先怀疑是不是循环查询比如在Python里对每个结果又发起一次Neo4j查询这种N1写法必须改造成一次性MATCH加OPTIONAL MATCH。5.5 规则模板互相冲突多实体问题永远比想象的难现象“高血压和糖尿病吃什么药”这种问题系统返回的是高血压的药物列表完全没提糖尿病。用户觉得系统答非所问。原因实体识别阶段识别出了两个实体高血压和糖尿病但代码里谁先匹配到就只返回第一个实体的查询结果。这类多实体问题本质是联合用药禁忌规则系统很难完美处理但也不能直接忽略第二个实体。解决代码里加一个实体数量判断。小于等于1个实体走正常问答链路大于等于2个实体时不要直接处理返回“您可以分开询问比如先问高血压吃什么药”。这样虽然没能回答联合用药但系统给出了可操作的引导比答错强。实现方式是在answer_question入口处加一个分支def answer_question(question): entities, remain recognizer.recognize(question) if len(entities) 2: return { answer: 这个问题涉及多个疾病建议您换个问法例如高血压吃什么药, hit: False, } ...这个分支没有用任何高深技术但对体验提升非常明显。答辩时如果被问“能不能处理复杂问题”可以坦诚地说多实体联合查询是规则系统边界并指出未来的优化方向是引入句法依赖分析。诚实指出边界比硬吹系统能力更容易拿到认可。6. 从“能答”到“答得对”用回归集验收系统别再凭感觉调系统跑起来后最怕的是一遍遍手动测试“高血压有什么症状”“感冒吃什么药”测完感觉良好结果老师随手问一个“胃疼挂什么科”就卡壳。要避免这种尴尬就得建立一套可重复执行的回归评估集把测试从“手点”变成“脚本跑”。先造一个最小回归集每条数据除了问题还要写清楚期望输出里必须出现的词test_cases [ {question: 高血压有什么症状, should_contain: [头晕]}, {question: 感冒吃什么药, should_contain: [感冒灵]}, {question: 胃疼应该挂什么科, should_contain: [消化内科]}, {question: 发烧怎么办, should_contain: [发热]}, ]评估脚本就三件事遍历回归集调用answer_question、检查兜底、检查关键词。命中失败的打印出来写进failed.txt方便追踪。total len(test_cases) failed [] for case in test_cases: result answer_question(case[question]) if not result[hit]: failed.append((case[question], 未命中知识库)) continue if not any(word in result[answer] for word in case[should_contain]): failed.append((case[question], 答案缺少关键词)) print(f通过率: {total - len(failed)}/{total}) for q, reason in failed: print(f失败案例: {q} - {reason})每次调整同义词表、模板顺序、Cypher语句后跑一遍这个脚本通过率数字会告诉你改坏了没有。通过率低于70%说明知识库覆盖或模板覆盖有明显缺口先别急着优化答案措辞回头补数据和模板才对症。我的习惯是把回归集保存成test_cases.json放进项目里每改一行代码就跑一遍跑完再看失败案例属于哪一类实体没识别到还是意图没匹配还是图谱里没有关系。分门别类整理失败原因后你会发现自己系统的短板集中在某一种问法上这时再针对性补模板效率是最高的。这套方法不花哨但能把“我觉得它能答”变成“我知道它能答”如果你把回归集和测试脚本也写进说明文档里答辩时的说服力会明显上了一个台阶。希望这个方法也能帮到你。本文还有配套的精品资源点击获取