简介：面向人工智能与知识图谱方向学习者，提供基于Neo4j的肝病领域问答系统完整项目实践。该资源聚焦医疗知识图谱构建与规则匹配问答，包含疾病、症状、药物等实体关系建模，以及分词、实体识别等自然语言处理流程，适合希望掌握图谱落地与Cypher查询的中高级开发者。压缩包共26个文件，以9个Python脚本为主，涵盖数据爬取、知识图谱构建、问题分类与答案检索等核心模块；另含8个txt词典与实体文件、5个xml工程配置、3个json测试数据及1个iml工程描述，整体约15.76MB，结构清晰便于直接运行与二次开发。目前已有105人学习下载。通过源码可深入理解从医疗数据预处理到Neo4j图存储、再到规则匹配问答的完整链路，并获取预定义查询模板、动态索引与缓存策略等优化思路，为构建其他垂直领域问答系统提供可复用参考。
1. 从病历检索到知识问答：为什么肝病图谱选 Neo4j 落地
拿到一份关于肝病知识图谱问答系统的描述，大多数人的第一反应是“又要用关系型数据库做语义匹配”。但肝病领域的问题形态极其特殊：患者问“肝硬化并发腹水该挂哪个科”，医生问“拉米夫定耐药后换用替诺福韦的依据链”，这两类问题都依赖多跳关系推理，而非单表筛选。关系型数据库处理这类问题需要频繁的 JOIN，超过三层关联查询的响应时间就会让问答系统显得迟钝。Neo4j 的图遍历机制把关联查询的复杂度从表连接降为指针跳跃，在深度为 4 到 5 的常见肝病诊疗路径上，查询延迟可以稳定在毫秒级。另一方面，肝病知识本体本身是高度图结构的：疾病、症状、检查项、药物、手术方案互为节点，边上的“由…引起”“禁忌于”“需监测”等语义就是遍历路径。Neo4j 的标签属性图模型无需预先定义严格的表结构，对肝病这类还在持续增补临床指南的领域，迭代成本远低于传统数据库迁移。这篇文章从零搭建一套可运行的肝病问答系统，覆盖图谱建模、数据写入、问答链路实现到参数调优，所有命令都在 Neo4j 社区版 4.x 上验证过。
2. 肝病知识图谱的领域建模与数据入库
2.1 肝病实体的 5 类标签和 8 种核心关系
图谱的质量在建模时就已经定型，不要指望后续查询环节去修正缺失的语义。肝病领域实体建模建议收敛为五类核心标签，每类标签下用属性做细分，这样既保留图遍历的灵活性，又避免标签过散导致管理混乱。
| 标签 | 典型节点 | 关键属性 | 说明 |
|---|---|---|---|
Disease | 肝硬化、乙肝、脂肪肝 | name,icd10,department | 肝病核心节点，icd10用于对接临床数据 |
Symptom | 黄疸、腹水、肝区疼痛 | name,description | 描述性文本用于答案组装 |
Medicine | 恩替卡韦、替诺福韦 | name,dose,frequency | 剂量信息供用药建议 |
Examination | 肝功能检测、B超 | name,normal_range | 正常范围用于异常判断 |
Surgery | 肝移植、射频消融 | name,indication | 适应症属性辅助决策 |
关系类型不宜过多，八种基本够用：HAS_SYMPTOM（疾病到症状）、USES_MEDICINE（疾病到药物）、REQUIRES_EXAM（疾病到检查项）、SURGERY_FOR（手术到疾病）、CONTRAINDICATES（药物到药物或疾病）、CAUSES（疾病到并发症）、BELONGS_TO（子类型到父类型）、TREATS（药物到疾病）。这里的关键在于CONTRAINDICATES不是简单的是非边，可以附带severity属性表示禁忌等级，问答系统在装配答案时能依据该属性给出“禁用”或“慎用”的差异化回复。
2.2 用 LOAD CSV 批量写入肝病数据的命令模板
图谱数据量在医院场景下通常有数千到数万节点，逐条 CREATE 不现实。社区版最常见的高效方案是先将数据整理为 CSV 文件，再通过LOAD CSV命令批量导入。字段内不要出现逗号，统一用 UTF-8 编码保存，文件放到 Neo4j 的import目录下，否则会因权限限制报错。
以下是将肝病药物数据写入图谱的完整命令，假设 CSV 文件名为medicine.csv，包含name,dose,frequency,indications四列：
LOAD CSV WITH HEADERS FROM 'file:///medicine.csv' AS row FIELDTERMINATOR ',' CREATE (m:Medicine { name: row.name, dose: row.dose, frequency: row.frequency, indications: row.indications, created_at: datetime() })执行前建议先跑一次计数验证：
LOAD CSV WITH HEADERS FROM 'file:///medicine.csv' AS row RETURN count(row) AS totalcount(row)返回 CSV 中非空行数，如果跟你文件里的行数对不上，优先检查文件是否含 BOM 头或末尾多空行。写入时逐个创建节点的效率瓶颈在单次事务，大批量文件建议分批执行，每批五千行左右，避免内存溢出。FIELDTERMINATOR指令限定列分隔符，文件里如果用制表符就改成'\t'。
2.3 为问答场景创建联合索引和约束的唯一性防重
问答系统的前提是实体解析，而解析的第一步就是快速定位节点。Neo4j 的索引策略直接影响实体链接的响应速度，规则很简单：任何你会用来做查找的属性，都必须建索引。肝病图谱里name是最高频的检索键，数量级在万级时无索引的扫描耗时可达二百毫秒以上，建索引后可以降到个位数毫秒。
CREATE CONSTRAINT disease_name_unique IF NOT EXISTS FOR (d:Disease) REQUIRE d.name IS UNIQUE; CREATE INDEX medicine_name_idx IF NOT EXISTS FOR (m:Medicine) ON (m.name); CREATE INDEX symptom_name_idx IF NOT EXISTS FOR (s:Symptom) ON (s.name);IS UNIQUE约束在导入阶段起到数据质量闸门的作用，重复的疾病名会导致写入失败，这能及时发现 CSV 中未清洗干净的脏数据。后两个索引允许重复值存在，因为不同厂牌的药物可能同名但剂量不同。索引不建会导致问答链路中的实体解析慢一个数量级，但信息量不大的图谱里差异会被掩盖，到数据量增加到十万级再回头补索引，迁移成本就高了。
3. 问答系统的实体识别与意图意图转型
3.1 基于词典与规则的两级命名实体识别
问答系统的核心链路是“问题分析 — 图查询 — 答案组装”三段式。第一关是要从问句里把疾病、药物、症状这类实体名精确抽取出来，业界常用 BiLSTM-CRF 之类的序列标注模型，但对于领域覆盖面固定的肝病图谱，词典加规则的轻量方案成本更低、误报率也更容易控制。常见做法是维护一份词表文件，每行一个实体名，加载到内存后用最大匹配法扫描问句。注意用户的问法通常有很多变体，需要做词典的同义词扩展，比如“乙肝”和“乙型病毒性肝炎”指向同一实体。
from py2neo import Graph graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password")) def extract_entities(question): entities = {} for label in ["Disease", "Medicine", "Symptom", "Examination", "Surgery"]: query = f""" MATCH (n:{label}) WHERE $question CONTAINS n.name RETURN n.name AS name, labels(n) AS labels """ result = graph.run(query, question=question).data() for record in result: entities[record["labels"][0]] = record["name"] return entitiesCONTAINS是 Neo4j 4.x 内置的字符串匹配函数，不需要额外配置全文索引就能工作，但只适合十万级节点以下的小图谱。数据量上来之后要换db.index.fulltext.queryNodes做分词检索，社区版通常用analyzer: 'cjk'处理中文文本。图谱查询和实体提取是交替进行的，没有拿到实体就发 MATCH 语句的话，答案组装直接断链，需要在这里加上空值保护。
3.2 七类问句模板覆盖常见肝病咨询场景
用户问肝病问题时，看似五花八门，落到查询模式上就只有有限的几类。出“这个病有什么症状”是Disease → HAS_SYMPTOM → Symptom，问“什么药能治肝硬化”是Medicine → TREATS → Disease的反向查找，问“这个药跟那个药能一起吃吗”是查两个Medicine节点之间是否存在CONTRAINDICATES边。模板要覆盖七类主要场景：
| 模板ID | 问句模式 | Cypher 模式 | 返回内容 |
|---|---|---|---|
| T1 | 症状问询 | (d:Disease)-[:HAS_SYMPTOM]->(s:Symptom) | 症状列表 |
| T2 | 治疗药物 | (m:Medicine)-[:TREATS]->(d:Disease) | 药物列表 |
| T3 | 用药禁忌 | (m:Medicine)-[:CONTRAINDICATES]->(other) | 禁忌说明 |
| T4 | 所需检查 | (d:Disease)-[:REQUIRES_EXAM]->(e:Examination) | 检查项 |
| T5 | 手术方案 | (s:Surgery)-[:SURGERY_FOR]->(d:Disease) | 手术名 |
| T6 | 疾病病因 | (c:Disease)-[:CAUSES]->(d:Disease) | 并发症链 |
| T7 | 科室导诊 | (d:Disease)的department属性 | 科室名 |
模板匹配用正则表达式做意图分类，比如问句中同时出现“什么”和“症状”就归到 T1，出现“能不能吃”“禁忌”之类的词归到 T3，优先级从 T3 往下排，因为禁忌类问句的语义更具体，误判代价更高。意图判定后把实体和模板拼成最终 Cypher，这一步要特别注意 Cypher 注入问题，实体名必须通过参数传递而不能直接拼接字符串。
4. 用 Py2neo 实现 Cypher 图谱查询与答案生成链路
4.1 路径查询返回多跳关系并组装自然语言答案
拿到实体和意图后，真正执行图遍历的代码要封装成一个独立函数，便于复用和调试。下面代码实现了 T1 和 T2 两种模板的实际查询，并做了答案文本的拼接逻辑：
def query_answer(entities, intent): if intent == "T1" and "Disease" in entities: cypher = """ MATCH (d:Disease {name: $name})-[:HAS_SYMPTOM]->(s:Symptom) RETURN s.name AS symptom, s.description AS desc LIMIT 10 """ data = graph.run(cypher, name=entities["Disease"]).data() if not data: return "暂无该疾病的症状记录" parts = [f"{item['symptom']}（{item['desc']}）" for item in data] return "该疾病的常见症状包括：" + "；".join(parts) + "。" if intent == "T2" and "Disease" in entities: cypher = """ MATCH (m:Medicine)-[:TREATS]->(d:Disease {name: $name}) RETURN m.name AS med, m.dose AS dose, m.frequency AS freq LIMIT 20 """ data = graph.run(cypher, name=entities["Disease"]).data() if not data: return "暂无推荐药物记录" parts = [f"{item['med']}（{item['dose']}，{item['freq']}）" for item in data] return "常用治疗药物包括：" + "；".join(parts) + "。请遵医嘱使用。"为什么查询模板里不写死{name: '肝硬化'}而要传参数？一是避免特殊字符导致语法错误，二是参数化查询能让 Neo4j 的查询计划缓存复用，相同结构的语句第二次执行可以省掉编译时间。LIMIT 10不是随便写的，问答系统的答案需要控制篇幅，症状超过十个用户根本读不完，而且遍历深度过深会拖慢响应。
4.2 使用深度遍历处理“病因链/并发症路径”查询
肝病问答有一类常见但容易被忽略的问题：用户问“脂肪肝长期不治会怎么样”，这需要沿CAUSES边做多跳遍历，而不是简单的一层关系。路径查询在 Cypher 里用变长模式匹配实现，[:CAUSES*1..3]表示从当前疾病出发沿CAUSES遍历 1 到 3 层：
def query_complication_chain(entities): if "Disease" not in entities: return "未识别到疾病实体" cypher = """ MATCH path = (d:Disease {name: $name})-[:CAUSES*1..3]->(complication:Disease) RETURN [n IN nodes(path) | n.name] AS chain LIMIT 5 """ chains = graph.run(cypher, name=entities["Disease"]).data() if not chains: return "该疾病的并发症链路暂未收录" output = [] for item in chains: output.append(" → ".join(item["chain"])) return "可能的疾病演进路径为：" + "；".join(output) + "。"[n IN nodes(path) | n.name]是 Cypher 的列表推导式，把路径上的所有节点名称提取成数组，这样返回的就不再是分散的关系行，而是一条完整链路。深度上限设为 3 是出于两个考虑：医疗语义上超过三跳的因果链医学可信度大幅下降，性能上深度遍历随深度呈指数增长，5 跳以上普通配置的图数据库会开始吃紧。LIMIT 5分页了返回结果集，避免关联出几十条链把答案窗口撑爆。
4.3 答案兜底逻辑：知识缺失时的提示语设计
问答系统最怕的不是答错，而是答非所问。图数据库中查不到对应关系时，用户会得到一个空列表，直接把None或空数组返回给前端，体验很差。兜底逻辑要区分两种情况：实体存在但该类型边缺失，和实体本身不存在。前者说明图谱覆盖不全，后者通常是实体识别环节出了偏差。
def fallback_reply(entities, intent): if not entities: return "您的问题中未识别到肝病相关实体，请尝试提及具体疾病名或药物名。" if intent in ("T1", "T2") and "Disease" not in entities: return "未定位到该疾病节点，可能名称表达不一致，试试输入疾病的标准名称。" return "已找到实体信息，但暂未收录该问题的关联数据，图谱正在补充中。"兜底回复不一定要回到空话，可以引导用户换词表述，这能间接降低实体识别的失败率。生产环境建议把这部分回复文本放到配置表里，方便业务人员修改，不要在代码中硬编码。
5. 肝病图谱问答全流程启动与关联参数调整
5.1 本地搭建从安装到建库的完整命令链
在项目目录下用 Docker 拉取镜像是最干净的方式，社区版镜像自带 APOC 插件，对路径遍历和文本处理扩展很重要。先用 Docker 启动 Neo4j，再创建项目虚拟环境并安装 Py2neo。
docker run -d \ --name neo4j-liver \ -p 7474:7474 -p 7687:7687 \ -e NEO4J_AUTH=neo4j/liver_qa_2024 \ -e NEO4J_PLUGINS='["apoc"]' \ -v $PWD/import:/var/lib/neo4j/import \ neo4j:4.4-community启动后验证导入目录是否正确挂载，直接看容器内的同目录文件即确认挂载成功。接着把 CSV 文件放进宿主机./import，复跑第二章的 LOAD CSV 命令。然后建立 Python 虚拟环境：
python3 -m venv venv source venv/bin/activate pip install py2neo==2021.2.4Py2neo 版本锁到 2021.2.4 是有原因的，新版对 Neo4j 4.4 的认证方式做了调整，5.x 分支的 API 有破坏性变化，社区常见教程大多基于这个版本编写。
5.2 问答链路的延迟拆解与阈值设定
系统能跑不代表能上线，问答系统的性能要从两个维度压测：单条问句的端到端延迟，以及并发场景下的吞吐量。先用 50 个真实问句模拟循环调用，记录每个环节的耗时分布，重点观察实体识别和图查询的占比。实体识别如果跑 CONTAINS 匹配，耗时与节点数成正比，适合频次低、离线验证的场景。
Neo4j 侧的索引生效与否直接影响图查询耗时，可以用EXPLAIN前缀观察执行计划：
EXPLAIN MATCH (d:Disease {name: '肝硬化'})-[:HAS_SYMPTOM]->(s:Symptom) RETURN s.name输出计划中如果看到NodeByLabelScan而不是NodeIndexSeek，说明索引没有命中。这句话值得在代码注释中保留，排查性能问题时会反复用到。正常的响应链路应该符合以下阈值：实体识别 20 到 50 毫秒，图查询 5 到 30 毫秒，答案组装 1 到 5 毫秒，总耗时控制在 100 毫秒内。超过这个范围，优先检查网络延迟而不是图谱本身。
6. 让问答更准的深度遍历边界与结果验证法
6.1 可变长度关系的深度参数与剪枝条件
图数据库的深度遍历是把双刃剑。深度越大，查到的知识链越丰富，但无关路径带来的噪音也越多。在肝病场景中，CAUSES关系的遍历深度建议限制为 3，HAS_SYMPTOM不做深度扩展只用单层。修改深度不需要改代码逻辑，只需要调整 Cypher 里的*1..N参数。遇到版本兼容问题时要留意 Cypher 的列表推导语法[n IN nodes(path) | n.name]，Neo4j 4.4 明确支持，本地如果没生效，优先确认数据库版本。
剪枝条件也很关键，可以给CAUSES边加confidence属性表示临床指南的推荐强度，查询时只保留confidence > 0.6的路径本。这样深度从 3 放宽到 4 时，被剪枝掉的弱关联不会污染答案。
6.2 百问集评测与节点间最短路径验证
质量验证的可操作方案是预置一份百问集，分为四个难度档位：实体单跳查询、多跳路径链、否定类问题（问“不能用什么药”）、跨类型组合问题（症状加药物同时出现）。逐条运行问答系统绑定答案的临床知识库做全自动比对，统计准确率和完整率两个指标，全自动判定不方便做的场景用人工抽样 20 条做复核。
额外附一个值得测的边界场景：在两个看似无关的疾病节点之间跑最短路径，验证图谱是否存在意外的错误连边。用 Neo4j 内置算法：
MATCH (a:Disease {name: '自身免疫性肝炎'}), (b:Disease {name: '肝细胞癌'}) CALL apoc.algo.dijkstra(a, b, 'CAUSES|CAUSES', 'weight') YIELD path, weight RETURN path, weight返回的 path 如果超过两条边，需要人工核对每条边的语义是否合理。这叫路径审计，可以在图谱迭代过程中自动检测脏数据引入的语义断裂，比单点抽查的效率高得多。问答系统的质量底线不在于模型多花哨，而在于每一个返回给用户的路径都能在医学上自圆其说。
本文还有配套的精品资源，点击获取
