简介面向知识图谱初学者与有Python课程设计、毕业设计需求的学生这份代码围绕医疗领域知识图谱构建展开先用Scrapy爬虫采集百度百科词条数据再以MongoDB保存结构化三元组最终在Neo4j中完成图谱建模与可视化。压缩包共25个文件约14KB以9个py源码文件为核心包含爬虫项目下的spiders、pipelines、middlewares、settings等模块以及create_KG.py构建脚本另有Scrapy配置、项目配置文件、README说明和依赖清单可视为一个能直接运行的迷你工程。资源目前已有429人学习下载项目结构清晰从数据采集、三元组存储到图谱构建均有独立文件对应适合边读边改。通过阅读代码读者可以掌握爬虫采集、三元组抽取与存储、知识图谱构建及可视化的完整链路理解ScrapyMongoDBNeo4j的组合用法由于项目规模紧凑也便于对照源码修改实体类别和关系快速迁移到其他领域作为课设或毕设的起点。1. 医疗知识图谱构建实战为什么我建议从最小可行本体起步当电子病历里的“阿司匹林”“拜阿司匹灵”“乙酰水杨酸”指向同一个药当“高血压”和“血压高”在检索系统里各算一类你手里的数据就开始失控了。医疗知识图谱构建实战要解决的就是这件事把散在病历、说明书、检验报告里的实体和关系整理成一张可查询、可推理的图。它能支撑病历结构化、辅助诊断提示、合理用药审查也能让科室在做统计时不再靠人在 Excel 里清洗别名。适合谁如果你已经在跟医疗文本、医学术语或医院数据打交道想从“存起来”走向“用起来”这篇内容就是按一线实施的路径写的。我们需要把目标收窄一点不是做一个全家桶级别的医学 KB而是先跑通一个能交付、能解释的医疗知识图谱。2. 医疗知识图谱的本体建模从语义层到底层标签的落地设计很多人一拿到“医疗知识图谱”就急着写爬虫、跑 NER结果抽出一堆实体连“药品治疗疾病”和“疾病需要用药”是不是同一种关系都说不清。我一般会先把本体建模放在最前面。本体建模不是学术任务它是给图数据库设计的一层语义约束哪些东西是节点哪些东西是关系关系有没有方向约束。没有这层设计后面每条 Cypher 都可能写不顺手。2.1 先定边界诊断、用药、检验还是全科做医疗知识图谱第一个要泼冷水的问题是“想做多大”。医疗体系极大常见做法是先圈定一个最小可行域比如围绕“诊断-用药”场景做。这个域里至少需要四类实体疾病、症状、药品、科室外加两类支撑实体检查项、手术。关系则围绕临床路径来定疾病有症状has_symptom、药品治疗疾病treats、药品有禁忌症contraindicates、疾病归科室管理belongs_to、检查确认疾病confirms。确定边界后我会写一份简单的实体-关系清单格式如下实体类型含义示例Disease疾病/诊断2型糖尿病、高血压Drug药品二甲双胍、阿卡波糖Symptom症状多饮、多尿Department科室内分泌科Exam检查项空腹血糖、糖化血红蛋白这份清单很重要它决定了后续知识抽取和导入的标签体系。不要试图一步到位覆盖 ICD-10 全表那样本体设计会变成一场持久战。先把 5 类实体、4 类关系做稳比做一个庞大但没人维护的图谱强。2.2 用 Protégé 建最小类层级和对象属性有了实体清单下一步是用本体工具把它变成形式化定义。常见做法是用 Protégé 建一个 OWL 本体但不建议直接在里面把所有实例都填上本体里只放类和属性约束。我通常建这几个类Thing - MedicalEntity - Disease / Drug / Symptom / Department / Exam。对象属性包括treats、has_symptom、contraindicates、belongs_to、confirms并为每个属性设置 domain 和 range。比如treats的 domain 是 Drugrange 是 Diseasehas_symptom的 domain 是 Diseaserange 是 Symptom。这一步能提前拦截很多脏数据某条信息说“科室治疗疾病”在关系上就不成立。下面是我常用的一段 OWL 片段只截取类和属性定义方便你在 Protégé 里对照DeclarationClass IRI#Disease//Declaration DeclarationClass IRI#Drug//Declaration DeclarationClass IRI#Symptom//Declaration DeclarationObjectProperty IRI#treats//Declaration SubClassOfClass IRI#Drug/ObjectSomeValuesFromObjectProperty IRI#treats/Class IRI#Disease//ObjectSomeValuesFrom/SubClassOf DeclarationObjectProperty IRI#has_symptom//Declaration SubClassOfClass IRI#Disease/ObjectSomeValuesFromObjectProperty IRI#has_symptom/Class IRI#Symptom//ObjectSomeValuesFrom/SubClassOf这里的关键是SubClassOf配合ObjectSomeValuesFrom它表示“每个 Drug 至少治疗一种 Disease”。这样的约束虽然不能强制每个实例都有关系但至少让本体在逻辑上自洽。Protégé 里跑一下 HermiT 推理机能查出不 satisfiable 的类定义。2.3 把 OWL 本体映射到 Neo4j 的标签、关系和约束OWL 本体重在逻辑Neo4j 重在存储和查询。落地时不需要把 OWL 原封不动搬过去而是做一层“语义层到底层”的映射。我的映射规则很直观OWL 类变成 Neo4j 的节点标签对象属性变成关系类型类的层级变成关系:IS_A数据属性变成节点属性。比如Disease和Drug之间的treats在 Neo4j 里就是(:Drug)-[:TREATS]-(:Disease)。映射表应该写到项目的 README 里后续抽数、导数据都按它执行OWL 要素Neo4j 对应说明owl:Class Disease:Disease节点标签owl:ObjectProperty treats:TREATS关系类型方向 Drug - Diseaserdfs:subClassOf:IS_A关系类型如 Drug - Medicineowl:DatatypeProperty name节点的name属性保留原始名称这一映射关系看起来简单但很多项目在这里踩坑把对象属性当成节点属性存或者把类层级直接丢进关系类型导致查询时无法利用节点标签。建议在动手导入前先把这段映射写进一页设计文档给团队做个评审。这一步想清楚了后面所有代码都只是翻译。3. 医疗文本实体关系抽取规则、BERT 与质检兜底本体建模解决“图长什么样”的问题知识抽取解决“图里填什么”的问题。医疗文本抽取不能完全交给模型我的经验是用规则打底用模型扩召回用人工质检兜底。尤其是西医药品说明书结构相对固定规则能拿到很高的准确率电子病历则要靠 NER 模型。3.1 从病历和药品说明书里抽实体基于词典和句法规则常见的做法是准备三份资源一份药品别名词典、一份疾病诊断词典、一份触发词表。药品说明书里“本品适用于治疗高血压”这样的句子用正则就能抽。先做术语归一把“阿司匹林肠溶片”归一为“阿司匹林”把“血压高”归一为“高血压”。下面是我写过的一个最小示例用 Python 实现说明书句子的关系抽取import re trigger_rules [ (r适用于治疗(?Pdisease[\u4e00-\u9fa5]), TREATS), (r禁用于(?Pdisease[\u4e00-\u9fa5]), CONTRAINDICATES), ] def extract_relations(sentence, drug_name, rulestrigger_rules): relations [] for pattern, rel_type in rules: for m in re.finditer(pattern, sentence): disease m.group(disease) # 关系类型固定方向是药品指向疾病 relations.append((drug_name, rel_type, disease)) return relations text 本品适用于治疗高血压禁用于脑出血急性期。 print(extract_relations(text, 硝苯地平))输出会得到两条三元组(硝苯地平, TREATS, 高血压)和(硝苯地平, CONTRAINDICATES, 脑出血急性期)。这段代码里的trigger_rules是可扩展的实际项目里我会根据药品说明书的结构加入“用于”“适用于”“不宜用于”等触发词。需要注意正则里[\u4e00-\u9fa5]对连续疾病名有效但如果疾病名里带括号、逗号会截断所以后续必须用词典最长匹配做一次修正。3.2 微调 NER 模型的显式参数batch size、学习率与序列长度说明书之外电子病历里的实体更散比如“患者因多饮多尿就诊空腹血糖 8.2 mmol/L考虑 2 型糖尿病”。这时就需要用 NER 模型。我常用的是基于预训练中文 BERT 的下游序列标注标注标签就五个Disease、Drug、Symptom、Exam、Department。微调时不要用默认参数直接跑先看三个参数batch_size医疗文本长度差异大一般取 8 或 16。取太大会显存溢出取太小则收敛慢。learning_rate微调 BERT 通常用 2e-5 到 5e-5超过 1e-4 容易让预训练权重被冲掉导致指标升得慢反而过拟合。max_seq_len一句话里常有好几个实体建议 128 或 256。太短会把后半句的实体截丢太长会拖慢训练。下面是基于 Hugging Face Trainer 的配置片段我用它跑出一个基线from transformers import BertForTokenClassification, BertTokenizerFast, Trainer, TrainingArguments model BertForTokenClassification.from_pretrained( bert-base-chinese, num_labels5, id2label{0: O, 1: Disease, 2: Drug, 3: Symptom, 4: Exam} ) training_args TrainingArguments( output_dir./ner_out, per_device_train_batch_size16, per_device_eval_batch_size16, learning_rate3e-5, max_seq_length256, num_train_epochs3, logging_steps100, save_steps500, )这里的max_seq_length在TrainingArguments里不是直接参数需要数据预处理时用 tokenizer 截断。实际项目我会在预处理函数里显式设置truncationTrue, max_length256。重点是保存每个 epoch 的 checkpoint做坏的时候可以直接回退到上一轮不用从头重训。3.3 关系抽取后的实体对齐与属性补全实体识别出来后最容易被忽视的是对齐。第一步是把同义实体合并通过 ICD-10 和 ATC 编码映射到标准编码。比如“盐酸二甲双胍”和“二甲双胍片”都对到 ATCA10BA02。这一步不完成后面导入 Neo4j 时会出现大量重复节点Cypher 查询结果会很难看。属性补全则常见做法是为每个实体补充来源字段和标准编码字段。我一般给节点加三个属性source来自说明书还是病历、codeICD/ATC编码、updated_at时间戳。后续增量导入也好做不然重跑一遍抽取图谱里全是旧数据。4. 把医疗知识图谱写进 Neo4jUNWIND、索引与诊断路径查询本体和抽取结果就绪接下来要面对的是一个更现实的问题几十万实体关系怎么快速、不重复地写进 Neo4j。很多初学者喜欢用一个 for 循环逐条CREATE跑了半小时告诉我说卡住了。这正是典型的低效导入场景解决思路是批量操作。4.1 用 Python driver 批量写入避免逐条 CREATE我推荐用官方neo4jPython driver配合UNWIND做批量节点创建。原因很简单UNWIND把一条 Cypher 变成一批操作网络往返次数从 N 次降到一次导入速度至少快一个量级。下面是一个创建药品和疾病节点的最小示例from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) drugs [ {name: 阿司匹林, code: B01AC06}, {name: 硝苯地平, code: C08CA05}, ] diseases [ {name: 高血压, code: I10}, {name: 心绞痛, code: I20}, ] with driver.session() as session: session.run( UNWIND $rows AS row MERGE (d:Drug {code: row.code}) SET d.name row.name , rowsdrugs) session.run( UNWIND $rows AS row MERGE (d:Disease {code: row.code}) SET d.name row.name , rowsdiseases)这里用了MERGE而不是CREATE它按code属性匹配已有节点存在就更新名称不存在就新建。UNWIND $rows AS row是批量导入的入口$rows是参数传入的列表。逻辑说明先把数据整理成字典列表再传给 Cypher避免直接拼接字符串。这样可以防止注入也更容易维护。4.2 约束和索引把重复实体挡在写入前导入之前我强烈建议先给节点建好唯一约束。很多人跳过这步到后期查出来几个重复节点才开始清数据那时就晚了。唯一约束本身会创建索引所以不需要再额外建同名索引。具体做法如下CREATE CONSTRAINT disease_code_unique IF NOT EXISTS FOR (d:Disease) REQUIRE d.code IS UNIQUE; CREATE CONSTRAINT drug_code_unique IF NOT EXISTS FOR (d:Drug) REQUIRE d.code IS UNIQUE;这段 Cypher 的意思是对Disease和Drug的code属性建立唯一约束。如果导入时遇到重复编码事务会直接报错提醒你上游的数据合并没做干净。关系导入也同理不要直接UNWIND从头跑到尾建议先做 1000 条的小批量验证再跑全量。4.3 一个真实的诊断路径 Cypher 查询知识图谱建好之后最常被问到的查询就是“这个患者可能的诊断方向是什么”。在图上它表达为“从症状节点出发经过关系到达疾病节点再找到对应科室”。下面是一条可以放在服务端作为视图的 CypherMATCH (s:Symptom {name: 多饮}) MATCH (d:Disease)-[:HAS_SYMPTOM]-(s) MATCH (d)-[:BELONGS_TO]-(dep:Department) RETURN d.name AS disease, dep.name AS department ORDER BY d.name DESC这条查询的路径是 Symptom - Disease - Department通过MATCH逐个绑定节点和关系。参数说明如果s:Symptom的 name 是中文别名建议先做别名表替换否则这里查不到。这个查询也可以封装成带参数的版本MATCH (s:Symptom {name: $symptom}) MATCH (d:Disease)-[:HAS_SYMPTOM]-(s) OPTIONAL MATCH (d)-[:BELONGS_TO]-(dep:Department) RETURN d.name AS disease, dep.name AS department使用OPTIONAL MATCH是避免有些疾病没有关联科室时整条记录被过滤掉。医疗知识图谱里数据不完整是常态查询要尽量容忍缺失。5. 医疗知识图谱构建避坑5 个让项目返工的真实问题这章写的是我在这类项目里反复遇到、几乎每次都让人翻车的坑。按“现象→原因→解决”的方式记录每一条都来自真实操作。5.1 实体名重复与唯一约束冲突现象导入完成度 90% 时 Neo4j 抛Unable to create constraint或Merge大量报错查库发现“高血压”和“高血压病”各有一个节点。原因抽取阶段没有做标准编码映射同一疾病被词典和模型分别识别成不同称号。解决先把实体统一到标准编码。疾病实体按 ICD-10 编码药品按 ATC 编码。如果项目没有编码表就用“中文名 别名表”的方式在入库前先做一轮归一化。5.2 中文分词把疾病名切碎现象NER 模型把“高血压性脑病”识别成“高血压”和“脑病”两个实体关系抽取跟着错。原因预训练分词器对医疗复合词不友好词典里没有覆盖长尾疾病名。解决在微调阶段给分词器添加自定义术语表或者在后处理里用最长匹配合并。我一般会维护一个“医学实体词典”在 NER 解码后做一次规则合并保证复合词不被拆碎。5.3 关系方向不一致现象关系导入后查“哪些药治疗高血压”时用(d)-[:TREATS]-(drug)一条都查不到但图里明明有关系。原因抽取代码里有的写(drug)-[:TREATS]-(disease)有的写反了。解决写入前对关系做方向校验。正向关系TREATS必须从 Drug 指向 Disease反向用REV_TREATS或直接不存。建议在导入脚本里加一行断言如果起始标签和结束标签不符合约束就抛错。这个约束要和本体定义保持一致不能靠自觉。5.4 大批量导入卡死和内存溢出现象用 for 循环一条条CREATE到几万条时写速度骤降Neo4j 内存吃满。原因每条语句都是独立事务提交频繁事务日志膨胀。解决改成UNWIND批量提交每批 5002000 条。批量太大也会导致单条事务过大反而慢。最佳批次可以根据机器内存调8G 内存的机器我一般控制在 1000 左右。5.5 概念层和数据层混在一起现象查询时发现有些Drug节点实际上代表药品品牌有些代表药品成分比如“拜阿司匹灵”和“阿司匹林”都放在一层。原因本体里没有区分品牌药和通用名。解决增加一个“成分”类或者用属性drug_type区分。常见做法是在 OWL 本体里加一个DrugIngredient类Drug通过has_ingredient指向它。这样未来做药品替代和相互作用推理时语义才不会混乱。6. 进阶在知识图谱上做推理和可视化一条捷径和一剂后悔药图谱不是建完就算能查只是第一步。真正能体现价值的是在图上做推理比如通过has_symptom和treats推断潜在诊断路径或者用contraindicates拦截不合理处方。我建议先别上复杂图算法从一个规则推理开始。Neo4j 的 Cypher 本身就能做广度路径搜索比如找“同时治疗两种疾病且其中一种是我的目标疾病”的药品用带可变长度的路径匹配就能解决MATCH (d:Disease {name: 高血压})-[:TREATS]-(drug:Drug) WHERE NOT (drug)-[:CONTRAINDICATES]-(d) RETURN drug.name这个查询把“可用药”直接筛选出来排除禁忌症比人工翻药品说明书快得多。推理规则先写死后再考虑装入前端做可视化。医疗图谱的前端插件常见做法是直接用 ECharts 关系图或 Cytoscape.js从 Neo4j 查出的结果转成nodes和links两个数组再渲染。如果你不想从零写也可以先用 Neo4j Bloom 做内部演示验证交互需求后再定制。最后说一条我的习惯每个项目我都会在交付包里留一个“后悔药”脚本里面包含constraint_drop.cypher和reimport.py。万一图谱里的编码规则要改或者本体要扩类不用手动清库一条命令回滚到空图再重导。数据导入流程反复跑几次是常事能快速重来比一次成功更值钱。医疗知识图谱构建的复杂度不在算法而在每一步是否留了修正余地。把这些边角收干净项目才算真正能交付。希望这套思路对你手里的构建实战有点帮助。本文还有配套的精品资源点击获取 医疗知识图谱构建实战：从最小可行本体到Neo4j
简介面向知识图谱初学者与有Python课程设计、毕业设计需求的学生这份代码围绕医疗领域知识图谱构建展开先用Scrapy爬虫采集百度百科词条数据再以MongoDB保存结构化三元组最终在Neo4j中完成图谱建模与可视化。压缩包共25个文件约14KB以9个py源码文件为核心包含爬虫项目下的spiders、pipelines、middlewares、settings等模块以及create_KG.py构建脚本另有Scrapy配置、项目配置文件、README说明和依赖清单可视为一个能直接运行的迷你工程。资源目前已有429人学习下载项目结构清晰从数据采集、三元组存储到图谱构建均有独立文件对应适合边读边改。通过阅读代码读者可以掌握爬虫采集、三元组抽取与存储、知识图谱构建及可视化的完整链路理解ScrapyMongoDBNeo4j的组合用法由于项目规模紧凑也便于对照源码修改实体类别和关系快速迁移到其他领域作为课设或毕设的起点。1. 医疗知识图谱构建实战为什么我建议从最小可行本体起步当电子病历里的“阿司匹林”“拜阿司匹灵”“乙酰水杨酸”指向同一个药当“高血压”和“血压高”在检索系统里各算一类你手里的数据就开始失控了。医疗知识图谱构建实战要解决的就是这件事把散在病历、说明书、检验报告里的实体和关系整理成一张可查询、可推理的图。它能支撑病历结构化、辅助诊断提示、合理用药审查也能让科室在做统计时不再靠人在 Excel 里清洗别名。适合谁如果你已经在跟医疗文本、医学术语或医院数据打交道想从“存起来”走向“用起来”这篇内容就是按一线实施的路径写的。我们需要把目标收窄一点不是做一个全家桶级别的医学 KB而是先跑通一个能交付、能解释的医疗知识图谱。2. 医疗知识图谱的本体建模从语义层到底层标签的落地设计很多人一拿到“医疗知识图谱”就急着写爬虫、跑 NER结果抽出一堆实体连“药品治疗疾病”和“疾病需要用药”是不是同一种关系都说不清。我一般会先把本体建模放在最前面。本体建模不是学术任务它是给图数据库设计的一层语义约束哪些东西是节点哪些东西是关系关系有没有方向约束。没有这层设计后面每条 Cypher 都可能写不顺手。2.1 先定边界诊断、用药、检验还是全科做医疗知识图谱第一个要泼冷水的问题是“想做多大”。医疗体系极大常见做法是先圈定一个最小可行域比如围绕“诊断-用药”场景做。这个域里至少需要四类实体疾病、症状、药品、科室外加两类支撑实体检查项、手术。关系则围绕临床路径来定疾病有症状has_symptom、药品治疗疾病treats、药品有禁忌症contraindicates、疾病归科室管理belongs_to、检查确认疾病confirms。确定边界后我会写一份简单的实体-关系清单格式如下实体类型含义示例Disease疾病/诊断2型糖尿病、高血压Drug药品二甲双胍、阿卡波糖Symptom症状多饮、多尿Department科室内分泌科Exam检查项空腹血糖、糖化血红蛋白这份清单很重要它决定了后续知识抽取和导入的标签体系。不要试图一步到位覆盖 ICD-10 全表那样本体设计会变成一场持久战。先把 5 类实体、4 类关系做稳比做一个庞大但没人维护的图谱强。2.2 用 Protégé 建最小类层级和对象属性有了实体清单下一步是用本体工具把它变成形式化定义。常见做法是用 Protégé 建一个 OWL 本体但不建议直接在里面把所有实例都填上本体里只放类和属性约束。我通常建这几个类Thing - MedicalEntity - Disease / Drug / Symptom / Department / Exam。对象属性包括treats、has_symptom、contraindicates、belongs_to、confirms并为每个属性设置 domain 和 range。比如treats的 domain 是 Drugrange 是 Diseasehas_symptom的 domain 是 Diseaserange 是 Symptom。这一步能提前拦截很多脏数据某条信息说“科室治疗疾病”在关系上就不成立。下面是我常用的一段 OWL 片段只截取类和属性定义方便你在 Protégé 里对照DeclarationClass IRI#Disease//Declaration DeclarationClass IRI#Drug//Declaration DeclarationClass IRI#Symptom//Declaration DeclarationObjectProperty IRI#treats//Declaration SubClassOfClass IRI#Drug/ObjectSomeValuesFromObjectProperty IRI#treats/Class IRI#Disease//ObjectSomeValuesFrom/SubClassOf DeclarationObjectProperty IRI#has_symptom//Declaration SubClassOfClass IRI#Disease/ObjectSomeValuesFromObjectProperty IRI#has_symptom/Class IRI#Symptom//ObjectSomeValuesFrom/SubClassOf这里的关键是SubClassOf配合ObjectSomeValuesFrom它表示“每个 Drug 至少治疗一种 Disease”。这样的约束虽然不能强制每个实例都有关系但至少让本体在逻辑上自洽。Protégé 里跑一下 HermiT 推理机能查出不 satisfiable 的类定义。2.3 把 OWL 本体映射到 Neo4j 的标签、关系和约束OWL 本体重在逻辑Neo4j 重在存储和查询。落地时不需要把 OWL 原封不动搬过去而是做一层“语义层到底层”的映射。我的映射规则很直观OWL 类变成 Neo4j 的节点标签对象属性变成关系类型类的层级变成关系:IS_A数据属性变成节点属性。比如Disease和Drug之间的treats在 Neo4j 里就是(:Drug)-[:TREATS]-(:Disease)。映射表应该写到项目的 README 里后续抽数、导数据都按它执行OWL 要素Neo4j 对应说明owl:Class Disease:Disease节点标签owl:ObjectProperty treats:TREATS关系类型方向 Drug - Diseaserdfs:subClassOf:IS_A关系类型如 Drug - Medicineowl:DatatypeProperty name节点的name属性保留原始名称这一映射关系看起来简单但很多项目在这里踩坑把对象属性当成节点属性存或者把类层级直接丢进关系类型导致查询时无法利用节点标签。建议在动手导入前先把这段映射写进一页设计文档给团队做个评审。这一步想清楚了后面所有代码都只是翻译。3. 医疗文本实体关系抽取规则、BERT 与质检兜底本体建模解决“图长什么样”的问题知识抽取解决“图里填什么”的问题。医疗文本抽取不能完全交给模型我的经验是用规则打底用模型扩召回用人工质检兜底。尤其是西医药品说明书结构相对固定规则能拿到很高的准确率电子病历则要靠 NER 模型。3.1 从病历和药品说明书里抽实体基于词典和句法规则常见的做法是准备三份资源一份药品别名词典、一份疾病诊断词典、一份触发词表。药品说明书里“本品适用于治疗高血压”这样的句子用正则就能抽。先做术语归一把“阿司匹林肠溶片”归一为“阿司匹林”把“血压高”归一为“高血压”。下面是我写过的一个最小示例用 Python 实现说明书句子的关系抽取import re trigger_rules [ (r适用于治疗(?Pdisease[\u4e00-\u9fa5]), TREATS), (r禁用于(?Pdisease[\u4e00-\u9fa5]), CONTRAINDICATES), ] def extract_relations(sentence, drug_name, rulestrigger_rules): relations [] for pattern, rel_type in rules: for m in re.finditer(pattern, sentence): disease m.group(disease) # 关系类型固定方向是药品指向疾病 relations.append((drug_name, rel_type, disease)) return relations text 本品适用于治疗高血压禁用于脑出血急性期。 print(extract_relations(text, 硝苯地平))输出会得到两条三元组(硝苯地平, TREATS, 高血压)和(硝苯地平, CONTRAINDICATES, 脑出血急性期)。这段代码里的trigger_rules是可扩展的实际项目里我会根据药品说明书的结构加入“用于”“适用于”“不宜用于”等触发词。需要注意正则里[\u4e00-\u9fa5]对连续疾病名有效但如果疾病名里带括号、逗号会截断所以后续必须用词典最长匹配做一次修正。3.2 微调 NER 模型的显式参数batch size、学习率与序列长度说明书之外电子病历里的实体更散比如“患者因多饮多尿就诊空腹血糖 8.2 mmol/L考虑 2 型糖尿病”。这时就需要用 NER 模型。我常用的是基于预训练中文 BERT 的下游序列标注标注标签就五个Disease、Drug、Symptom、Exam、Department。微调时不要用默认参数直接跑先看三个参数batch_size医疗文本长度差异大一般取 8 或 16。取太大会显存溢出取太小则收敛慢。learning_rate微调 BERT 通常用 2e-5 到 5e-5超过 1e-4 容易让预训练权重被冲掉导致指标升得慢反而过拟合。max_seq_len一句话里常有好几个实体建议 128 或 256。太短会把后半句的实体截丢太长会拖慢训练。下面是基于 Hugging Face Trainer 的配置片段我用它跑出一个基线from transformers import BertForTokenClassification, BertTokenizerFast, Trainer, TrainingArguments model BertForTokenClassification.from_pretrained( bert-base-chinese, num_labels5, id2label{0: O, 1: Disease, 2: Drug, 3: Symptom, 4: Exam} ) training_args TrainingArguments( output_dir./ner_out, per_device_train_batch_size16, per_device_eval_batch_size16, learning_rate3e-5, max_seq_length256, num_train_epochs3, logging_steps100, save_steps500, )这里的max_seq_length在TrainingArguments里不是直接参数需要数据预处理时用 tokenizer 截断。实际项目我会在预处理函数里显式设置truncationTrue, max_length256。重点是保存每个 epoch 的 checkpoint做坏的时候可以直接回退到上一轮不用从头重训。3.3 关系抽取后的实体对齐与属性补全实体识别出来后最容易被忽视的是对齐。第一步是把同义实体合并通过 ICD-10 和 ATC 编码映射到标准编码。比如“盐酸二甲双胍”和“二甲双胍片”都对到 ATCA10BA02。这一步不完成后面导入 Neo4j 时会出现大量重复节点Cypher 查询结果会很难看。属性补全则常见做法是为每个实体补充来源字段和标准编码字段。我一般给节点加三个属性source来自说明书还是病历、codeICD/ATC编码、updated_at时间戳。后续增量导入也好做不然重跑一遍抽取图谱里全是旧数据。4. 把医疗知识图谱写进 Neo4jUNWIND、索引与诊断路径查询本体和抽取结果就绪接下来要面对的是一个更现实的问题几十万实体关系怎么快速、不重复地写进 Neo4j。很多初学者喜欢用一个 for 循环逐条CREATE跑了半小时告诉我说卡住了。这正是典型的低效导入场景解决思路是批量操作。4.1 用 Python driver 批量写入避免逐条 CREATE我推荐用官方neo4jPython driver配合UNWIND做批量节点创建。原因很简单UNWIND把一条 Cypher 变成一批操作网络往返次数从 N 次降到一次导入速度至少快一个量级。下面是一个创建药品和疾病节点的最小示例from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) drugs [ {name: 阿司匹林, code: B01AC06}, {name: 硝苯地平, code: C08CA05}, ] diseases [ {name: 高血压, code: I10}, {name: 心绞痛, code: I20}, ] with driver.session() as session: session.run( UNWIND $rows AS row MERGE (d:Drug {code: row.code}) SET d.name row.name , rowsdrugs) session.run( UNWIND $rows AS row MERGE (d:Disease {code: row.code}) SET d.name row.name , rowsdiseases)这里用了MERGE而不是CREATE它按code属性匹配已有节点存在就更新名称不存在就新建。UNWIND $rows AS row是批量导入的入口$rows是参数传入的列表。逻辑说明先把数据整理成字典列表再传给 Cypher避免直接拼接字符串。这样可以防止注入也更容易维护。4.2 约束和索引把重复实体挡在写入前导入之前我强烈建议先给节点建好唯一约束。很多人跳过这步到后期查出来几个重复节点才开始清数据那时就晚了。唯一约束本身会创建索引所以不需要再额外建同名索引。具体做法如下CREATE CONSTRAINT disease_code_unique IF NOT EXISTS FOR (d:Disease) REQUIRE d.code IS UNIQUE; CREATE CONSTRAINT drug_code_unique IF NOT EXISTS FOR (d:Drug) REQUIRE d.code IS UNIQUE;这段 Cypher 的意思是对Disease和Drug的code属性建立唯一约束。如果导入时遇到重复编码事务会直接报错提醒你上游的数据合并没做干净。关系导入也同理不要直接UNWIND从头跑到尾建议先做 1000 条的小批量验证再跑全量。4.3 一个真实的诊断路径 Cypher 查询知识图谱建好之后最常被问到的查询就是“这个患者可能的诊断方向是什么”。在图上它表达为“从症状节点出发经过关系到达疾病节点再找到对应科室”。下面是一条可以放在服务端作为视图的 CypherMATCH (s:Symptom {name: 多饮}) MATCH (d:Disease)-[:HAS_SYMPTOM]-(s) MATCH (d)-[:BELONGS_TO]-(dep:Department) RETURN d.name AS disease, dep.name AS department ORDER BY d.name DESC这条查询的路径是 Symptom - Disease - Department通过MATCH逐个绑定节点和关系。参数说明如果s:Symptom的 name 是中文别名建议先做别名表替换否则这里查不到。这个查询也可以封装成带参数的版本MATCH (s:Symptom {name: $symptom}) MATCH (d:Disease)-[:HAS_SYMPTOM]-(s) OPTIONAL MATCH (d)-[:BELONGS_TO]-(dep:Department) RETURN d.name AS disease, dep.name AS department使用OPTIONAL MATCH是避免有些疾病没有关联科室时整条记录被过滤掉。医疗知识图谱里数据不完整是常态查询要尽量容忍缺失。5. 医疗知识图谱构建避坑5 个让项目返工的真实问题这章写的是我在这类项目里反复遇到、几乎每次都让人翻车的坑。按“现象→原因→解决”的方式记录每一条都来自真实操作。5.1 实体名重复与唯一约束冲突现象导入完成度 90% 时 Neo4j 抛Unable to create constraint或Merge大量报错查库发现“高血压”和“高血压病”各有一个节点。原因抽取阶段没有做标准编码映射同一疾病被词典和模型分别识别成不同称号。解决先把实体统一到标准编码。疾病实体按 ICD-10 编码药品按 ATC 编码。如果项目没有编码表就用“中文名 别名表”的方式在入库前先做一轮归一化。5.2 中文分词把疾病名切碎现象NER 模型把“高血压性脑病”识别成“高血压”和“脑病”两个实体关系抽取跟着错。原因预训练分词器对医疗复合词不友好词典里没有覆盖长尾疾病名。解决在微调阶段给分词器添加自定义术语表或者在后处理里用最长匹配合并。我一般会维护一个“医学实体词典”在 NER 解码后做一次规则合并保证复合词不被拆碎。5.3 关系方向不一致现象关系导入后查“哪些药治疗高血压”时用(d)-[:TREATS]-(drug)一条都查不到但图里明明有关系。原因抽取代码里有的写(drug)-[:TREATS]-(disease)有的写反了。解决写入前对关系做方向校验。正向关系TREATS必须从 Drug 指向 Disease反向用REV_TREATS或直接不存。建议在导入脚本里加一行断言如果起始标签和结束标签不符合约束就抛错。这个约束要和本体定义保持一致不能靠自觉。5.4 大批量导入卡死和内存溢出现象用 for 循环一条条CREATE到几万条时写速度骤降Neo4j 内存吃满。原因每条语句都是独立事务提交频繁事务日志膨胀。解决改成UNWIND批量提交每批 5002000 条。批量太大也会导致单条事务过大反而慢。最佳批次可以根据机器内存调8G 内存的机器我一般控制在 1000 左右。5.5 概念层和数据层混在一起现象查询时发现有些Drug节点实际上代表药品品牌有些代表药品成分比如“拜阿司匹灵”和“阿司匹林”都放在一层。原因本体里没有区分品牌药和通用名。解决增加一个“成分”类或者用属性drug_type区分。常见做法是在 OWL 本体里加一个DrugIngredient类Drug通过has_ingredient指向它。这样未来做药品替代和相互作用推理时语义才不会混乱。6. 进阶在知识图谱上做推理和可视化一条捷径和一剂后悔药图谱不是建完就算能查只是第一步。真正能体现价值的是在图上做推理比如通过has_symptom和treats推断潜在诊断路径或者用contraindicates拦截不合理处方。我建议先别上复杂图算法从一个规则推理开始。Neo4j 的 Cypher 本身就能做广度路径搜索比如找“同时治疗两种疾病且其中一种是我的目标疾病”的药品用带可变长度的路径匹配就能解决MATCH (d:Disease {name: 高血压})-[:TREATS]-(drug:Drug) WHERE NOT (drug)-[:CONTRAINDICATES]-(d) RETURN drug.name这个查询把“可用药”直接筛选出来排除禁忌症比人工翻药品说明书快得多。推理规则先写死后再考虑装入前端做可视化。医疗图谱的前端插件常见做法是直接用 ECharts 关系图或 Cytoscape.js从 Neo4j 查出的结果转成nodes和links两个数组再渲染。如果你不想从零写也可以先用 Neo4j Bloom 做内部演示验证交互需求后再定制。最后说一条我的习惯每个项目我都会在交付包里留一个“后悔药”脚本里面包含constraint_drop.cypher和reimport.py。万一图谱里的编码规则要改或者本体要扩类不用手动清库一条命令回滚到空图再重导。数据导入流程反复跑几次是常事能快速重来比一次成功更值钱。医疗知识图谱构建的复杂度不在算法而在每一步是否留了修正余地。把这些边角收干净项目才算真正能交付。希望这套思路对你手里的构建实战有点帮助。本文还有配套的精品资源点击获取