医疗知识图谱构建与KBQA问答系统实战：从实体识别到Neo4j查询

简介这是一套面向医疗领域知识图谱问答KBQA系统从零构建的完整资料包适合希望快速上手知识图谱与智能问答的AI开发者、算法工程师及高校学生。项目包含7类实体、约3.7万实体、21万实体关系的医疗知识图谱构建案例系统覆盖数据处理、实体抽取、图谱构建、意图分类、答案检索等KBQA标准工作流。整个压缩包共15个文件大小仅3.73MB以Python源码、txt词典疾病、症状、并发症、别名、停用词等、m模型文件、CSV数据及效果图为主源码负责build_graph、entity_extractor、search_answer等核心流程目录清晰便于对照学习。意图识别部分基于手工标注的210条训练数据经朴素贝叶斯与SVM效果对比后选用NB模型测试最佳F1值达到96.68%为读者提供了可复现的算法选型与调优参考词典与模型文件均可直接加载便于快速验证和二次开发。目前已有787人学习下载适合用较少时间理解KBQA全流程并完成一次完整的项目实践。1. 医疗知识图谱 KBQA当 3.7 万实体不再是演示项目一个真实的知识图谱问答系统和教材里画出来的那种“圆点连线图”是两回事。医疗场景里患者问“拉肚子该吃什么药”医生问“这个药和那个药能不能一起吃”系统要做的不是返回一串网页而是给出经过实体链接、关系查询和答案过滤之后的结构化结论。本标题指向的正是这样一套系统医疗领域的知识图谱7 类实体约 3.7 万实体节点21 万实体关系在这之上搭建 KBQA 智能问答系统。图为示意图不是项目的实际截图但规模值得认真对待——3.7 万实体意味着问答链路不能再靠人工维护映射21 万关系意味着查询路径可以有多跳。这套东西适合三类人想从 NLP 分类任务转向知识工程的工程师、医疗信息化方向的产品和技术负责人以及那些已经用 Neo4j 画过图但还没把问答链路串起来的人。下面按“数据怎么来 → 图怎么存 → 问句怎么变查询 → 坑在哪”的顺序拆开讲。2. 设计 7 类实体与 21 万实体关系先定 schema再写代码2.1 医疗领域 7 类实体怎么定从高频问题反推而不是从资料反推做医疗知识图谱的第一件事不是找数据而是定实体类型。很多项目上来就扒了一堆医学百科抽出来几十种实体结果在检索环节谁都用不上。我的做法是先列业务问题再反推实体类型。以医疗问答最常见的诉求为例患者想知道“得了什么病”“有什么症状”“吃啥药”“挂哪个科”“做什么检查”医生想知道“某药的适应症和禁忌”“某症状关联哪些病”。把这些问题里的名词归归类7 类实体就出来了疾病、症状、药物、检查项目、检验指标、手术操作、科室。实体类型典型示例在问答中的角色疾病2 型糖尿病、高血压、急性支气管炎问题主体答案核心症状腹泻、发热、干咳、乏力判断入口多为出发点药物二甲双胍、阿司匹林、布洛芬治疗方案用药查询目标检查项目血常规、胸部 CT、心电图诊断路径检验指标空腹血糖、糖化血红蛋白指标解读手术操作阑尾切除术、冠脉搭桥术治疗手段科室内分泌科、心内科、呼吸科就诊导引3.7 万实体不是均匀分布的疾病和症状这两类通常占一半以上药物次之。这个分布决定了后续关系抽取的优先级症状-疾病、疾病-药物这两类关系必须优先保证覆盖率。2.2 关系体系21 万关系不是“凑”出来的是 schema 推导的实体定了之后关系类型就要跟着设计。医疗领域的关系有一个特点同一对实体之间可能存在多种语义关系而且有的是正向、有的是负向。比如“药物-疾病”之间既有适应症正又有禁忌症负“疾病-症状”之间既有典型症状又有并发症导致的伴随症状。这些语义不能混成一条关系否则问答系统会给出误导性答案。我在这类项目里会维护一张关系 schema 表明确头实体类型、关系名、尾实体类型、允许出现的位置头实体关系尾实体说明疾病典型症状症状诊断依据药物适应症疾病正向用药关系药物禁忌症疾病负向关系必须与适应症隔离药物不良反应症状用药风险药物相互作用药物两药联用风险疾病就诊科室科室导诊症状建议检查检查项目检查推荐疾病确诊检查检查项目诊断金标准疾病并发症疾病疾病进展路径21 万关系从哪里来不是靠人工标注而是靠 schema 驱动抽取。你把上表里的关系类型定义清楚每种关系对应到可抽取的文本模式再对全部实体做笛卡尔积式校验最后得到的关系数量自然落在这个量级。粗略算一下3.7 万实体平均每个实体连接 5~6 条关系就是 20 万左右。这个数字可以被理解为图的平均度而不是一个需要精确对齐的 KPI。2.3 数据来源与清洗只用公开可转引的语料医疗知识图谱对数据来源的合法性要求天然就高。我一般只用三类公开资料药品说明书尤其是适应症、禁忌症、不良反应字段、公开出版的医学教材和临床指南、公开的疾病与症状术语表。这三类资料结构规整适合第一批数据落地。清洗阶段的三个原则值得写进工程规范。首先是实体名标准化同一实体只保留一个标准名其余作为别名单独存字段例如“拉肚子”的别名叫“腹泻”但图谱节点名必须是“腹泻”否则 KBQA 的实体链接会散掉。其次是全角半角、空格、括号统一转换中文语料里“糖尿病2 型”和“糖尿病(2型)”必须归一。第三是负向关系单独标注禁忌症关系字段里要带一个语义标签后续问答生成时不能被其他关系模板误用。提示不要为了追求关系数量把医院内部病历、未经授权的医患对话导进来数据合规问题足以让整个项目返工。公开语料加上明确的来源字段既够用也安全。3. 实体识别、关系抽取与 Neo4j 批量导入一条可复现的流水线3.1 用词典 正则完成第一版实体识别快而且可控医疗实体大多是规范名词而且术语表在公开渠道很容易拿到所以第一版实体识别不需要上 BERT 序列标注。词典匹配在 3.7 万实体这个量级上速度和准确率都能满足要求更重要的是它可解释每个实体命中结果都能回溯到来源条目。我用 AC 自动机做词典匹配一次扫描可以找出所有命中的实体import ahocorasick from typing import List, Tuple def build_entity_automaton(entities: List[str]) - ahocorasick.Automaton: automaton ahocorasick.Automaton() for idx, name in enumerate(set(entities)): # 实体名去重后加入自动机id 用于后续关联类别和别名 automaton.add_word(name, (idx, name)) automaton.make_automaton() return automaton def scan_entities(text: str, automaton: ahocorasick.Automaton) - List[Tuple[int, int, str]]: hits [] for end_pos, (idx, name) in automaton.iter(text): start end_pos - len(name) 1 hits.append((start, end_pos 1, name)) return hits逻辑说明build_entity_automaton把全部实体名加入自动机并构建失败指针后续iter遍历文本时每个位置只做一次状态转移匹配复杂度接近 O(n)3.7 万实体的词典对内存几乎没有压力。scan_entities返回的是每个命中的起止位置和实体名注意这里返回的是原始文本中的片段不要直接拿它当标准名用。参数说明entities列表在构建前必须去重否则自动机里同一个词对应多个 id后续回溯会乱文本建议先做全角转半角、去掉肉眼不可见的空格否则“潟”和“泻”这种形近字会敲掉一批命中。词典里建议把别名也一起加进去例如“二甲双胍片”“格华止”都要映射到“二甲双胍”这一步直接影响 4.2 节实体链接的召回。3.2 关系抽取用模式匹配先解决 80% 的显式三元组关系抽取是 21 万关系的产出环节。医疗文本的结构化程度比普通网页高很多说明书里“用于治疗”“禁忌用于”“不良反应包括”这些引导词非常固定用正则模式就能抽出一大批高质量三元组。以药品说明书的适应症为例import re # 限制抽取实体长度 2~20 个字避免把整段解释都吞进来 pattern re.compile(r用于(治疗|缓解|预防)([^。;,、]{2,20})) def extract_indication(text: str, drug_name: str) - list: triples [] for match in pattern.finditer(text): phrase match.group(2) # 命中片段必须能对齐到实体词典否则视为无效 for disease_name in align_to_entity(phrase): triples.append((drug_name, 适应症, disease_name)) return triples逻辑说明extract_indication先用正则定位“用于治疗/缓解/预防”后的文本片段再调用align_to_entity把片段切分并对齐到疾病实体词典。这一步极其关键没有词典校验的话“用于治疗2型糖尿病及其并发症”会被整段抽成实体产生一堆脏三元组。参数说明正则里{2,20}是边界约束2 个字以下太短20 个字以上说明模式吞掉了非实体内容align_to_entity的本质是用 3.1 节的自动机扫描片段再取最长匹配结果。抽取完之后做一步三元组级别的去重键是(head, relation, tail)这个三元组而不是文本句子。3.3 批量写入 Neo4jLOAD CSV 比逐条 CREATE 快一个量级以上实体和关系都落到 CSV 后写入 Neo4j 的方式直接决定导入耗时。逐条用 Python 驱动执行 CREATE 在 21 万关系这个量级上会慢到让人怀疑人生正确做法是导出 CSV再用LOAD CSV批量导入。实体表结构我一般定成两列name标准名和type实体类别关系表结构定成三列head、tail、rel。这里有个新手最容易踩的坑Neo4j 的 LOAD CSV 不支持用变量动态创建关系类型你不能写MERGE (h)-[r:{row.rel}]-(t)。解决办法是在导出 CSV 时按关系类型拆分成多个文件每种关系类型在导入语句里写死。先建立唯一约束防止重复实体节点CREATE CONSTRAINT entity_name IF NOT EXISTS FOR (e:Entity) REQUIRE e.name IS UNIQUE;再导入实体和关系USING PERIODIC COMMIT 500 LOAD CSV WITH HEADERS FROM file:///entities.csv AS row MERGE (e:Entity {name: row.name}) SET e.type row.type; USING PERIODIC COMMIT 500 LOAD CSV WITH HEADERS FROM file:///indication.csv AS row MATCH (h:Entity {name: row.head}) MATCH (t:Entity {name: row.tail}) MERGE (h)-[:适应症]-(t);逻辑说明MERGE而非CREATE是刻意的配合唯一约束保证同一实体不会因为重复导入产生多个副本USING PERIODIC COMMIT 500让每 500 行提交一次事务控制内存压力。参数说明实体导入里的SET e.type row.type是给节点打类别标签因为 7 类实体要在一个统一的 Entity 标签下管理查询时用WHERE e.type 药物过滤。关系导入的 MATCH 语句依赖实体唯一约束的性能所以约束必须在导入关系前建好。如果是从零重建图用neo4j-admin import做离线全量导入更快但它是整库级别的操作生产环境有存量数据时别用。4. KBQA 问答链路把自然语言问句翻译成 Cypher 查询4.1 意图识别与槽位填充先用模板别急着上模型知识图谱问答系统里意图识别决定走哪条查询路径槽位决定查询条件。医疗问句的表达相对收敛“吃什么药”“挂什么科”“有哪些症状”这类意图用关键词模板就能覆盖 80% 以上的线上请求。一上来就上分类模型反而要面对数据标注、模型迭代、badcase 回收一整条链路。INTENT_RULES { query_medicine: [吃什么药, 用什么药, 怎么办, 如何治疗], query_indication: [适应症, 治疗什么, 用于], query_symptom: [什么症状, 有哪些表现, 症状], query_department: [挂什么科, 哪个科, 就诊科室], } def detect_intent(question: str) - str: for intent, phrases in INTENT_RULES.items(): for phrase in phrases: if phrase in question: return intent return fallback逻辑说明遍历每个意图的关键词组命中即返回。模板顺序有讲究优先级高的意图排前面因为“治疗什么病”既可能被query_medicine命中也可能被query_indication命中这时候要看你的业务更侧重哪一边。参数说明关键词组不是拍脑袋写的要和第 2 章的关系 schema 一一对应。你的图里有“适应症”关系才需要query_indication这个意图图里没有“药品相互作用”关系就不要加对应的意图模板否则查询生成阶段会落空。模板维护是个增量过程每次从线上日志里捞未命中问句归类后补充关键词。4.2 实体链接问句里的词和图里的节点对不上是问答跑不动的头号原因槽位填充之后问句里的“拉肚子”要映射到图里的“腹泻”这一步叫实体链接。医疗场景里口语和书面语的差距很大靠字符串完全匹配会丢掉大量召回。我常用的方案是两级召回第一级用别名表精确匹配第二级用编辑距离兜底。别名的价值在医疗领域被严重低估一个“二甲双胍”至少有片剂名、商品名、通用名三种写法没有别名表后面的查询精度再高也是空转。def link_entity(span: str, entity_index: dict, topk: int 3) - list: candidates [] for std_name, meta in entity_index.items(): if span std_name or span in meta[aliases]: candidates.append((std_name, 1.0, meta[type])) else: # 编辑距离兜底处理错别字和省略写法 ratio levenshtein_ratio(span, std_name) if ratio 0.65: candidates.append((std_name, ratio, meta[type])) candidates.sort(keylambda x: -x[1]) return candidates[:topk]逻辑说明先走别名精确匹配命中的候选分数设为 1.0没命中再计算与标准名的编辑距离超过阈值放入候选池。entity_index的结构是标准名 - {aliases: [...], type: 症状}这个索引在系统启动时从 Neo4j 全量加载进内存3.7 万实体完全放得下。参数说明levenshtein_ratio返回 0~1 的相似度阈值 0.65 是根据中文医学术语的特点设定的——太低了会把“高血压”和“低血压”混在一起太高了又解决不了“胃镜”和“胃镜检查”这种简写差异。阈值要拿一批真实问句调建议至少准备 200 条带标准答案的问句做标注集。4.3 查询生成从槽位到 Cypher 模板实体链接完成后问答系统就把问句结构化成了三元组(意图, 槽位类型, 槽位值)。接下来要做的是把结构化信息翻译成 Cypher 查询。我维护一张模板表每个意图和槽位类型组合对应一段查询模板。TEMPLATES { (query_medicine, symptom): MATCH (s:Entity {name: $symptom})-[:典型症状]-(d:Entity {type: 疾病}) MATCH (d)-[:适应症]-(m:Entity {type: 药物}) RETURN DISTINCT m.name AS answer LIMIT 10 , (query_department, disease): MATCH (d:Entity {name: $disease})-[:就诊科室]-(dep:Entity {type: 科室}) RETURN DISTINCT dep.name AS answer LIMIT 5 , } def generate_query(intent: str, slot_type: str, slot_value: str) - str: template TEMPLATES[(intent, slot_type)] return template.replace($ slot_type, slot_value)逻辑说明第一个模板处理“症状反查药物”的场景问“拉肚子吃什么药”时$symptom会被替换成图谱里的标准实体名“腹泻”查询路径是 症状 - 疾病 - 药物两跳完成。第二个模板是“疾病查科室”一跳完成。参数说明模板是 schema 的镜像这一条务必记住。第 2 章定义了哪些关系、关系方向是什么模板里就必须严格对应。例如图中关系是(药物)-[:适应症]-(疾病)那问“什么药治糖尿病”就得从药物节点出发反着查如果当初建模时方向建反了这里所有模板都要跟着翻教训很深刻。多跳路径在这里已经出现了典型症状一跳、适应症一跳。后续要扩展到“腹泻可能是什么病这个病吃什么药”只需要把两个模板拼成三个 MATCH这个进阶放在第 6 章展开。5. 医疗 KBQA 常见问题与排查5 个高频坑按“现象-原因-解决”修5.1 带“不”的问句被识别成肯定意图现象用户问“我不发烧吃什么药”系统把“发烧”当成症状槽位检索出退烧药。原因意图识别和槽位抽取只做了正向关键词匹配对否定词没有感知。“不”“没”“无”这三个字在医疗问句里出现频率极高漏掉会直接给错误答案。解决在槽位抽取后加一个否定窗口过滤。取槽位前的 3 个字符窗口如果里面有否定词直接丢弃该槽位NEGATION_WORDS [不, 没, 无] def filter_negated_slot(question: str, span: str) - bool: start question.find(span) window question[max(0, start - 3):start] return any(w in window for w in NEGATION_WORDS)这个方法不完美但能把最容易误导患者的那批问句挡在问答链路之外宁可多返回“无法回答”也不要给错误用药建议。5.2 同名实体映射到了错误类型现象问“高血压挂什么科”实体链接把“高血压”匹配到了“疾病”和“检验指标”两个实体结果答案里混进了一个指标名。原因3.7 万实体里存在跨类型重名的情况纯字符串匹配无法区分。解决在实体链接阶段加入类型约束。问句里有“挂什么科”这样的意图词说明槽位实体大概率属于“疾病”类型其他类型的同名候选直接降权。具体做法是在link_entity返回候选列表后用意图对应的期望类型过滤一次只保留下类型匹配的高分候选。5.3 关系抽取把整个句子都吞进去了现象说明书里“用于治疗2型糖尿病及其并发症”被抽成一条(药物, 适应症, 2型糖尿病及其并发症)三元组查询时匹配不到任何疾病节点。原因关系抽取的正则没有约束实体长度也没有做词典对齐长文本片段被当成一个实体名。解决正则在引导词后限制 2~20 个字符抽取结果必须通过 3.1 节的词典校验。align_to_entity只返回能完整对齐到实体表的片段对齐不上就丢弃不将就。5.4 导入后查询匹配不到或实体重复现象图谱里已经导入了“腹泻”但问“腹泻”查不到节点用MATCH (e:Entity) RETURN count(e)一看数量比预期多出几百。原因实体表里有不可见字符或者全角空格“腹泻”和“腹泻 ”带空格被当成两个实体导入时用了 CREATE 而不是 MERGE重复执行脚本导致节点翻倍。解决导入前统一清洗实体名做strip()并替换全角空格导入语句全部用MERGE并配合唯一约束。查询时用WHERE e.name trim($name)做一层兜底。5.5 三元组去重不彻底关系总数虚高现象统计出来 25 万关系跟预期的 21 万对不上检查发现同一条适应症关系在多个来源文件里重复命中。原因抽取阶段按文本段落去重而不是按(head, relation, tail)三元组去重同一个实体对的同一条关系在不同说明书版本里各出现一次。解决抽取结果统一写入一个集合键是三元组本身写入 Neo4j 前按关系类型做一次分组统计数量和 source 字段维度必须对得上再导入。批量导入阶段用MERGE而不是CREATE从存储层挡住重复。6. 让问答系统可验证两跳查询与一组测试题的自动回归6.1 两跳查询模板把单条路径拼成完整问诊链多数线上问句用一跳模板就能答但“拉肚子可能是什么病这个病吃什么药”这类问句需要两跳甚至三跳。两跳查询不是简单拼接两个模板而是在中间节点上做去重和过滤否则同一疾病关联的多个症状会导致结果膨胀。MATCH (s:Entity {name: 腹泻})-[:典型症状]-(d:Entity {type: 疾病}) MATCH (d)-[:适应症]-(m:Entity {type: 药物}) RETURN DISTINCT d.name AS disease, collect(DISTINCT m.name)[..5] AS medicines LIMIT 10逻辑说明第一跳从症状反查疾病集合第二跳从疾病集合正向查药物。collect(DISTINCT m.name)[..5]把每种疾病对应的药物收敛成数组避免返回几十行重复的疾病名。这组模板维护起来比单跳麻烦因为每加一个关系类型所有依赖它的二级模板都要同步更新。我在项目里会把两跳模板的 Cypher 写进测试用例而不是放任它们躺在代码里。6.2 测试集驱动的自动回归用 top-k 命中率卡住每次改动我维护一个 100 条左右的人工标注测试集每条包含问句、预期答案集合、所属意图。任何模板改动、实体链接参数调整都要跑一遍回归脚本命中率下降超过两个点就得回滚。脚本逻辑很简单但它的存在让系统从“能跑”变成“可控”。def evaluate(test_set, ask_fn, topk5): hit 0 for question, gold_answers in test_set: answers ask_fn(question)[:topk] if any(a in gold_answers for a in answers): hit 1 return hit / len(test_set)测试集的价值不在数量在覆盖度。我规定每条测试问句必须至少配一条负例比如“我不发烧”和“发烧”各一条防止模板把否定语义和肯定语义混在一起。还有一点容易被忽略答案里要带关系限定词。比如“二甲双胍”在适应症和禁忌症里都出现你必须输出“适应症二甲双胍”而不是裸的“二甲双胍”否则用户分不清这是能吃还是不能吃。我最早做的版本跟很多入门项目一样图能查出来就觉得自己完成了后来用同一批测试问句换个说法再问答对率掉得没法看。那之后我把每个查询模板都配了至少两条反例才对“能上线”有了真正意义上的判断标准。知识图谱问答项目里“答得出来”是底线“答得对”才是验收线。希望帮到你。本文还有配套的精品资源点击获取