简介围绕 Neo4j 构建医疗问答知识图谱的实践项目包面向希望掌握图数据库建模、医疗问答数据处理与简单问答检索的开发者及学习者。项目以 ask120 医疗问答数据为来源尝试把疾病、症状、治疗方式等要素组织为节点与关系便于进行关联查询与知识梳理。压缩包共 37 个文件约 78KB以 Python 脚本、XML 配置、HTML 页面模板为主另含图片、JS 等辅助文件整体呈现为带爬虫与 Web 界面的 Django 工程结构。已有 5463 人学习下载。读者可从中参考数据采集、预处理、Neo4j 导入、Cypher 查询及页面展示的实现思路也可借助现有模块理解医疗知识图谱从原始问答到应用展示的落地流程适合用作课程设计、入门练习或二次开发的基础样例。1. 医疗问答知识图谱落地这套 Neo4j 资源适合谁、能解决什么很多人做医疗问答第一反应是堆一个分类模型结果一问「胸痛可能挂哪个科」就露馅模型能背答案却说不清症状、疾病、科室之间的路径。这份基于 Neo4j 的简易医疗问答知识图谱走的不是生成路线而是把症状、疾病、药物、检查、科室拆成节点用关系把「为什么推荐这个科室」摊开给你看。它适合想快速跑通图谱问答闭环的开发者也适合拿来做课程设计或内部原型数据规模不大但约束、导入、查询、排错这条链路是完整的。2. 图谱建模先定骨架五类节点与四类关系的落地拆解2.1 为什么医疗问答要先做实体分层而不是先写查询医疗问答的难点不在把答案写得多顺而在答案背后的关系能不能被查出来。比如用户说「反复胸闷、心慌挂什么科」至少要能落到症状节点、疾病节点、科室节点再给出命中路径。若把所有内容塞进一张宽表查询只能做字符串匹配拆成图之后症状到疾病、疾病到科室、疾病到药物都是显式边排查时能看到是哪条边把结果带出来的。我一般先把实体压到五类不急着加更多标签。标签一多导入脚本、约束、查询模板都会膨胀课程设计还没跑通就先被维护成本拖住。五类节点够覆盖「症状查疾病、疾病查科室、疾病查药、药物反查疾病」这几条主链路。节点标签关键属性在问答里的作用容易踩的坑Diseaseid、name、aliases、category、severity、description主实体承接症状、科室、药物、检查用 name 当唯一键改名就断关系Symptomid、name、aliases、body_part召回入口用户最常从这里问别名不归一用户说法对不上Drugid、name、category、usage_note、contraindication药物反查与展示把剂量、疗程写进图谱越界Checkid、name、category检查项推荐和科室混在一起查询时互相污染Departmentid、name、parent导诊聚合多级科室没有 parent统计重复这张表里最关键的是 id 和 name 分开。id 用稳定编码比如疾病 D001、症状 S001、药物 DR001、检查 C001、科室 DEP001name 只负责展示和查询。很多模拟项目X 一开始图省事直接拿疾病名当唯一键后面遇到「高血压」和「原发性高血压」这种别名关系就挂不到同一个节点上查出来的结果一半对一半空。症状节点要留 body_part不是为了好看而是为了在召回太泛时做二次收敛。比如「疼痛」这种大词单靠 name 查会带出一堆疾病有了 body_part 就能先限定「胸部」「腹部」「头部」。药物节点只留通用名、分类和备注不要在图谱里写剂量和疗程医疗问答原型只做知识检索和关系展示不替代医生诊断。注意图谱里可以展示「某疾病常关联某类症状、某科室」但不要输出具体用药剂量、疗程和诊断结论。这个边界在建模阶段就要守住后面查询层才不会越写越偏。2.2 用 Cypher 建约束与索引先把唯一键钉死建图之前先跑约束不要等导入报错再回头清重复。约束的作用不是装饰它能让后续的MERGE真正按 id 匹配而不是每次插一条新节点。下面的约束和索引脚本我一般放在导入脚本最前面空库先跑一遍已有库也能补。// 五类节点分别建唯一约束id 是稳定编码不用 name CREATE CONSTRAINT disease_id IF NOT EXISTS FOR (d:Disease) REQUIRE d.id IS UNIQUE; CREATE CONSTRAINT symptom_id IF NOT EXISTS FOR (s:Symptom) REQUIRE s.id IS UNIQUE; CREATE CONSTRAINT drug_id IF NOT EXISTS FOR (d:Drug) REQUIRE d.id IS UNIQUE; CREATE CONSTRAINT check_id IF NOT EXISTS FOR (c:Check) REQUIRE c.id IS UNIQUE; CREATE CONSTRAINT department_id IF NOT EXISTS FOR (d:Department) REQUIRE d.id IS UNIQUE; // name 是高频查询字段单独建普通索引 CREATE INDEX disease_name IF NOT EXISTS FOR (d:Disease) ON (d.name); CREATE INDEX symptom_name IF NOT EXISTS FOR (s:Symptom) ON (s.name); CREATE INDEX drug_name IF NOT EXISTS FOR (d:Drug) ON (d.name); CREATE INDEX check_name IF NOT EXISTS FOR (c:Check) ON (c.name); CREATE INDEX department_name IF NOT EXISTS FOR (d:Department) ON (d.name); // 别名和名称检索可以走全文索引减少前缀匹配带来的全表扫描 CREATE FULLTEXT INDEX entity_name_ft IF NOT EXISTS FOR (n:Disease|Symptom|Drug|Check|Department) ON EACH [n.name];这段脚本先建唯一约束再建普通索引和全文索引。IF NOT EXISTS让脚本可以重复执行不用每次删库。旧一点的 Neo4j 版本如果不支持这个写法把IF NOT EXISTS去掉执行前先确认约束不存在。约束建不上时先查重复 idMATCH (d:Disease) WITH d.id AS id, count(*) AS cnt WHERE cnt 1 RETURN id, cnt;查出重复后先合并节点再建约束。血泪经验是不要在有重复 id 的库上硬建约束报错信息只会告诉你冲突不会告诉你哪条 CSV 行带进来的。导入前用脚本校验一遍 id 唯一性比导入后修图省时间。2.3 关系方向与属性把「推荐理由」留在边上关系只保留一个方向查询时用反向匹配。不要同时建Disease-Symptom和Symptom-Disease否则更新时两边不同步count也会翻倍。我一般把疾病作为主语症状、科室、药物、检查都从疾病指出去用户从症状入口问的时候用MATCH (s:Symptom)-[:HAS_SYMPTOM]-(d:Disease)反向走。关系方向属性用途HAS_SYMPTOMDisease - Symptomweight、frequency症状查疾病时排序BELONGS_TODisease - Departmentprimary疾病导诊、科室聚合RECOMMENDS_DRUGDisease - Drugnote药物反查疾病NEEDS_CHECKDisease - Checknote疾病关联检查项weight不是诊断概率只是排序分。我一般给 0.1 到 1.0常见症状 0.8偶见 0.3别把它写成「置信度」。用户输入两个症状一个权重 0.8、一个 0.3排序时自然会把更常见的组合往前推。frequency可以放「常见」「偶见」这种粗粒度描述不要把医学统计频率编进去资源里没有的数据不要硬造。药物关系只写通用名和备注不写剂量。检查关系也不要把「确诊」这种词写进属性改成「关联检查项」更稳妥。科室关系里的primary用来标记主科室查询时可以先返回主科室再返回相关科室避免一上来给用户一堆平级结果。3. 数据从 CSV 进 Neo4j导入脚本、字段清洗与幂等重跑3.1 先把 CSV 拆成节点表和关系表图谱建模定完接下来最耗时间的是数据。医疗数据常见问题是字段不齐、别名多、同一疾病多个写法。导入脚本要能重复跑否则每次改一点数据就删库重建时间全花在等。我的做法是节点和关系分开节点表只放实体属性关系表只放两端 id 和边属性别把症状名、科室名重复塞进关系表。数据表必需列说明疾病节点id、name、aliases、category、severity、descriptionaliases 用竖线分隔不用逗号症状节点id、name、aliases、body_partbody_part 用于二次收敛药物节点id、name、category、usage_note、contraindication不写剂量和疗程检查节点id、name、category分类可以为空科室节点id、name、parentparent 可空表示一级科室疾病-症状关系disease_id、symptom_id、weight、frequencyweight 控制在 0.1 到 1.0疾病-科室关系disease_id、department_id、primaryprimary 用 0/1疾病-药物关系disease_id、drug_id、notenote 只写展示备注疾病-检查关系disease_id、check_id、notenote 只写展示备注CSV 统一用 UTF-8别用 Excel 默认的 GBK 直接存。别名列用|分隔比如高血压|原发性高血压|血压高这样不会和 CSV 的逗号冲突。导入前我一般先用 pandas 做一次列数和空值检查尤其是 id 列空 id 进图之后很难定位。import pandas as pd files [ nodes_disease.csv, nodes_symptom.csv, rels_disease_symptom.csv, ] for path in files: df pd.read_csv(path, encodingutf-8-sig) # id 列不允许为空关系表检查两端 id id_cols [c for c in df.columns if c.endswith(_id) or c id] for col in id_cols: bad df[col].isna().sum() if bad: print(f{path} 的 {col} 有 {bad} 行空值) print(path, df.shape)这段检查不复杂但能提前拦住大部分导入失败。encodingutf-8-sig是为了处理带 BOM 的 CSV否则第一列列名可能变成\ufeffidLOAD CSV读出来对不上。id_cols同时覆盖节点表的id和关系表的disease_id、symptom_id空值直接打印文件行数方便回到源表修。3.2 LOAD CSV 导入节点MERGE 只认 idSET 负责更新节点导入的核心是MERGE只匹配 id属性用SET更新。不要把 name 写进MERGE模式里否则同一个疾病改个显示名就会多出一个节点。下面的疾病节点导入脚本可以直接抄症状、药物、检查、科室按同样结构改标签和字段即可。LOAD CSV WITH HEADERS FROM file:///nodes_disease.csv AS row WITH row WHERE row.id IS NOT NULL AND trim(row.id) MERGE (d:Disease {id: trim(row.id)}) SET d.name trim(row.name), d.aliases CASE WHEN row.aliases IS NULL OR trim(row.aliases) THEN [] ELSE split(row.aliases, |) END, d.category coalesce(trim(row.category), ), d.severity coalesce(trim(row.severity), ), d.description coalesce(trim(row.description), );MERGE (d:Disease {id: trim(row.id)})只按 id 匹配SET负责覆盖属性所以同一份 CSV 跑两遍不会多出节点。aliases用CASE处理空值空字符串变成空数组后面查询时不用再判null。coalesce把缺失的分类、严重程度、描述补成空字符串避免展示层出现null。数据量大时不要一条大语句硬跑用:auto加CALL {} IN TRANSACTIONS分批。:auto是 Neo4j Browser 的客户端命令不是 Cypher 语法用 cypher-shell 时改用 APOC 或手动拆文件。下面这段一次提交 1000 行适合几千到几万节点的课程设计数据。:auto LOAD CSV WITH HEADERS FROM file:///nodes_symptom.csv AS row CALL { WITH row MERGE (s:Symptom {id: trim(row.id)}) SET s.name trim(row.name), s.body_part coalesce(trim(row.body_part), ), s.aliases CASE WHEN row.aliases IS NULL OR trim(row.aliases) THEN [] ELSE split(row.aliases, |) END } IN TRANSACTIONS OF 1000 ROWS;IN TRANSACTIONS OF 1000 ROWS是批大小不是越大越好。批太大内存上去批太小事务开销多。我一般从 500 到 1000 行试导入时看 Browser 的响应和内存曲线报事务超时就减半。file:///指向 Neo4j 的 import 目录不是本地任意路径CSV 要放到 import 目录下否则会报找不到外部资源。3.3 关系导入与幂等重跑别把 weight 写进 MERGE 模式关系导入最容易翻车的地方是把边属性写进MERGE模式。比如MERGE (d)-[r:HAS_SYMPTOM {weight: toFloat(row.weight)}]-(s)weight 一变就会多一条边最后同一个疾病和症状之间挂了好几条关系count直接虚高。正确做法是MERGE只匹配两端和关系本文还有配套的精品资源点击获取