简介这份资源是一套基于neo4j的简易医疗问答知识图谱项目从ask120医疗问答平台爬取问题、答案、疾病、症状及治疗等数据完成清洗、建模与图谱查询适合入门知识图谱和Neo4j的开发者也可作为课程设计或毕业设计参考。压缩包共37个文件以Python脚本13个py、10个pyc为主负责爬虫、数据处理和Django后端逻辑另有7个xml配置、3个html页面、1个js脚本及图片等用于系统配置与前端展示整体大小仅78KB结构清晰。资源已有5457人学习下载口碑和实用性得到一定验证。通过源码可完整了解ask120数据采集、Neo4j节点与关系建模、Cypher查询以及Web问答交互的落地流程稍作调整即可扩展成更完善的领域问答系统。整体麻雀虽小五脏俱全对想快速跑通爬虫知识图谱问答链路的学习者很友好。 这个项目是我自己折腾出来的起因很简单——想搞清楚知识图谱到底在实际业务里怎么落地。市面上的教程大多停留在理论层面讲RDF、讲本体论洋洋洒洒几千字但真正把数据倒腾进图数据库、跑通一个问答案例的并不多。所以我直接拿了最熟悉的医疗领域开刀用Neo4j搭了一个简易的医疗问答知识图谱。这套东西做的事情很聚焦把疾病、症状、药物、科室这些实体塞进图数据库通过Cypher查询引擎实现头痛可能是什么病感冒挂哪个科阿司匹林谁不能吃这类常见问答。它不追求大而全核心目标是让一个新手在两天内把知识图谱从0到1跑通并且理解每个环节为什么这么做。适合想入门知识图谱的开发者、医疗信息化方向的学生以及所有被知识图谱这个概念困扰过的人。1. 项目整体设计与医疗本体建模1.1 为什么选Neo4j而不是用MySQL硬怼医疗数据天生就是一张巨大的关系网。一个疾病连着多个症状一个症状又对应多种疾病一个药物有适应症、禁忌症还牵扯到科室和检查项目。这种网状结构用关系型数据库建模最典型的问题就是表越建越多、join越写越长。比如想回答高血压患者合并糖尿病哪些药不能用在MySQL里需要至少关联疾病表、药物表、禁忌关系表、疾病关联表四五张表写出来的SQL又臭又长性能还扛不住多跳查询。Neo4j解决这个问题的思路完全不同。它的核心存储模型就是节点和关系查询时沿着关系边做遍历而不是做全表扫描和join。这就好比你在一个城市里找朋友的朋友图数据库直接沿着社交关系链走两步就到了关系型数据库则要把全城人的通讯录翻一遍再手动匹配。当时我对比过几款图数据库Neo4j胜在生态成熟、Cypher查询语言直观、社区版免费可用而且网上资料一抓一大把。对于简易项目来说它是最不需要纠结的选择。另一个触动我选Neo4j的点是Cypher的表述能力。它写起来非常接近自然语言比如查感冒的常见症状MATCH (d:Disease {name: 感冒})-[:HAS_SYMPTOM]-(s:Symptom) RETURN s.name这行查询几乎就是在说人话匹配名字为感冒的疾病节点沿着有症状的关系走到症状节点返回症状名称。这种表达方式大大降低了业务方理解查询逻辑的门槛也方便后续做问答系统的模板化生成。1.2 面向问答场景的本体建模知识图谱里的本体听起来高大上其实就是在定义两个事情有哪些类型的节点、有哪些类型的关系。刚开始我也想过把医院里的实体全部建模进去什么医生、护士、床位、检验报告后来冷静下来一问这个项目的目的是什么是问答。那就应该从问答出发倒推需要哪些实体和关系。我最终确定的节点类型有六种疾病、症状、药物、科室、检查项、人群。关系类型则根据问答需求设计成四条主链关系示例对应问答场景(疾病)-[:HAS_SYMPTOM]-(症状)感冒-头痛感冒有什么症状(疾病)-[:TREAT_WITH]-(药物)高血压-硝苯地平高血压吃什么药(药物)-[:FORBIDDEN_IN]-(人群)阿司匹林-孕妇孕妇不能吃什么药(疾病)-[:VISIT_DEPT]-(科室)肺炎-呼吸内科肺炎挂哪个科这套设计最核心的原则就是够用就好。我没有引入时间维度、没有做药物剂量的属性建模甚至连疾病本身的详细描述都只留了一个字段。因为问答系统需要的是快速命中查询路径而不是做医学诊断。真实的知识图谱工程里最忌讳的就是一开始就把模型设计得无比复杂最后数据填不满、查询走不通整个项目烂尾。先做减法把主链路跑通后续再加细节这是我的经验。1.3 多跳查询路径的预埋设计简易模型不代表只能做单跳查询。在设计时就预埋了两条多跳路径方便后面扩展。第一条是症状-疾病-药物能回答头痛可以吃什么药这种间接问题第二条是疾病-药物-人群能回答治疗胃病的药哪些人不适合吃。多跳路径的预埋方式其实就是保证关系方向一致、命名规范查询时直接用变长路径匹配就行。比如头痛可以吃什么药的查询MATCH (s:Symptom {name: 头痛})-[:HAS_SYMPTOM]-(d:Disease)-[:TREAT_WITH]-(m:Medicine) RETURN DISTINCT m.name这条查询一开始写的时候我担心性能不行实际跑下来数据量在几千节点的情况下响应时间基本在几十毫秒以内。这里也给大家一个参考图数据库的性能瓶颈主要出现在遍历路径过长和节点数据量巨大的场景几千到几万节点的中小型知识图谱Neo4j完全吃得消。2. 环境准备与数据导入实操2.1 Neo4j安装与配置几个容易踩的坑安装Neo4j社区版本身不复杂去官网下载对应操作系统的安装包就行。Windows用户建议直接下载安装版会帮你配好环境变量Linux用户用tar包解压后改一下配置文件里的监听地址就能跑起来。但有几个细节必须提醒你。第一个坑是JDK版本。Neo4j 4.x版本对JDK的要求比较严格我当时装了最新的JDK 17结果启动直接报错。后来换成JDK 11才正常。现在Neo4j 5.x虽然对JDK 17有了支持但为了避免折腾建议先查清楚你下载的Neo4j版本对应的JDK要求再装对应的JDK。第二个坑是配置文件。社区版默认只允许本机访问配置文件conf/neo4j.conf里有两行需要重点看# 允许远程HTTP访问开发环境可以打开 server.http.listen_address0.0.0.0:7474 # 允许远程Bolt访问应用连接用 server.bolt.listen_address0.0.0.0:7687如果不改这两个配置你在服务器上部署时前端应用根本连不上数据库。我第一次部署到服务器上就因为这个卡了半小时。第三个坑是内存配置。Neo4j默认的堆内存可能不够用导入数据量大或者查询复杂时容易报OutOfMemoryError。我用的配置是server.memory.heap.initial_size512m server.memory.heap.max_size1g server.memory.pagecache.size512m对于入门级项目这个配置已经够了。如果还觉得慢优先加pagecache不是heap这是很多人容易搞反的地方。2.2 医疗数据从哪里来如何整理成CSV这是个绕不开的问题。做知识图谱项目数据准备往往比技术实现耗时长得多。我的数据来源主要有两个一个是从公开的医学知识库整理的结构化数据另一个是从百科类网站抓取后人工校对的数据。这里有个原则必须强调不要使用含有患者隐私的数据不要从非正规渠道购买医疗数据。公开的疾病百科、药品说明书、医学教材附录都是可以用的合法来源。数据格式上我按Neo4j官方推荐的导入方式把数据拆成两类CSV实体表和关系表。实体表中的每一行代表一个节点关系表则指定了两个实体ID之间的关系。举个例子疾病实体表长这样disease_id,disease_name,department,description D001,感冒,呼吸内科,急性上呼吸道感染 D002,高血压,心血管内科,体循环动脉血压增高药物实体表medicine_id,medicine_name,indication M001,阿司匹林,解热镇痛 M002,硝苯地平,降血压关系表则保存节点之间的连接关系start_id,start_type,end_id,end_type,relation D001,Disease,M001,Medicine,TREAT_WITH D002,Disease,M002,Medicine,TREAT_WITH整理CSV的过程中最耗精力的其实是实体对齐。同一个药品可能有商品名和通用名比如泰诺和对乙酰氨基酚其实是同一个东西。医疗领域这种同义词特别多需要你事先准备一份别名映射表在生成CSV时统一替换。如果不做这步知识图谱里会出现大量其实指向同一实体的重复节点查询结果里就会出现明明是一种病却返回了好几个相似名字的尴尬情况。2.3 用LOAD CSV批量导入数据Neo4j的LOAD CSV命令比逐条插入高效太多但有几个前提。最重要的一点是CSV文件必须放在Neo4j安装目录的import文件夹下这是安全机制决定的。如果你的CSV在别的路径除非配置里显式允许否则会报错。导入之前先建好唯一性约束可以防止重复数据又能让后续查询走索引CREATE CONSTRAINT disease_name_unique IF NOT EXISTS ON (d:Disease) ASSERT d.name IS UNIQUE; CREATE CONSTRAINT medicine_name_unique IF NOT EXISTS ON (m:Medicine) ASSERT m.name IS UNIQUE;然后执行导入LOAD CSV WITH HEADERS FROM file:///diseases.csv AS row MERGE (d:Disease {id: row.disease_id}) SET d.name row.disease_name, d.department row.department, d.description row.description;注意我用了MERGE而不是CREATE。因为CSV里可能有重复行CREATE会无脑建节点导致大量重复数据MERGE会先检查这个ID的节点存不存在存在就不重复建。这个习惯养成之后导入数据基本不会出大问题。关系导入类似但要先保证起止节点都存在LOAD CSV WITH HEADERS FROM file:///relations.csv AS row MATCH (s {id: row.start_id}) // 这里可以加上具体的节点类型标签 MATCH (e {id: row.end_id}) CALL apoc.create.relationship(s, row.relation, {}, e) YIELD rel RETURN count(rel);这段代码里用到了APOC库的apoc.create.relationship因为关系类型是动态的。如果不想引入APOC也可以拆分成多条Cypher语句针对每种关系类型写一条固定的CREATE/MERGE语句。导入完成后跑一下MATCH (n) RETURN count(n)验证节点总数再抽几个典型的查询案例验证关系是否正确。3. 问答解析与Cypher查询生成3.1 问答意图拆解先搞清楚用户会问什么问答系统的第一步不是写代码而是把用户可能问什么问题穷举出来。我花了大概半天时间把期望覆盖的问答场景分成了五类每一类对应一种Cypher查询模式意图类型用户问法示例查询模式症状查疾病头痛可能是什么病(症状)-[:HAS_SYMPTOM]-(疾病)疾病查症状感冒有哪些症状(疾病)-[:HAS_SYMPTOM]-(症状)疾病查药物高血压吃什么药(疾病)-[:TREAT_WITH]-(药物)药物查禁忌阿司匹林谁不能吃(药物)-[:FORBIDDEN_IN]-(人群)疾病查科室肺炎挂哪个科(疾病)-[:VISIT_DEPT]-(科室)这样拆解之后整个问答系统的核心就变成了两件事识别用户问的是哪一类意图、从问句中抽取出关键的实体词。这两件事做完Cypher查询就是套模板的事。3.2 基于规则和词典的轻量实体识别做这个项目的时候我明确要求自己不引入复杂的NLP框架。不是NLP不好而是简易项目用不上。医疗问答的实体词高度集中完全可以用词典匹配的方式搞定。我准备了三样东西一套疾病名词典、一套症状名词典、一套药物名词典。词典的来源就是导入数据时用的那份实体表。匹配时从问句里直接遍历词典做包含匹配。比如高血压吃什么药遍历疾病词典发现高血压命中再根据后面跟着吃什么药触发意图词药就可以组合出意图类型疾病查药物和实体高血压。实体识别这块我也踩过坑。最大的坑是别名问题用户说阿司匹林词典里存的是乙酰水杨酸直接匹配不上。后来我在词典里加入了别名映射查询前先做一轮别名归一化把阿司匹林统一成乙酰水杨酸问题就解决了。另一个坑是匹配优先级比如感冒和胃肠感冒如果用户说胃肠感冒我先匹配到感冒就会抽取出错误实体。解决办法是先按词长降序排序优先匹配更长的词。3.3 模板化的Cypher生成与答案组装意图和实体都识别出来了Cypher查询就是模板拼接。我这里的做法是维护一个模板字典每个意图对应一个查询函数。比如疾病查症状的查询函数很简单def query_symptoms_by_disease(disease_name): cypher MATCH (d:Disease {name: $name})-[:HAS_SYMPTOM]-(s:Symptom) RETURN s.name AS symptom_name results session.run(cypher, namedisease_name) return [record[symptom_name] for record in results]查询结果组装成自然语言回答时我加了一点格式化的逻辑。比如结果为空就返回数据库里暂时没有找到关于xxx的信息结果只有一个就返回头痛可能是以下疾病的症状感冒。结果多个就枚举并用顿号分隔。这些细节很多教程不会提但对用户体验的影响非常直接。整个问答逻辑我用Python的Flask封装成了HTTP接口前端只需要传一句what字符串过去后端返回JSON格式答案。为了保证并发场景下数据库连接不被耗尽我设置了Neo4j连接池大小为50并启用了空闲回收。4. 知识图谱可视化与前端接入4.1 先学会用Neo4j Browser看数据很多人做知识图谱项目数据导入之后就急着写前端结果发现图里长什么样都没看过。Neo4j自带的可视化界面Neo4j Browser其实已经够用了输入查询语句就能看到节点和关系的图形化展示。在Neo4j Browser里我最常用的一个查询是MATCH (d:Disease {name: 感冒})-[r]-(n) RETURN d, r, n LIMIT 30这条查询会把感冒节点的一跳关系全部拉出来能直观看到这个疾病连了哪些症状、哪些药物、哪个科室。Browser还支持节点颜色和样式的自定义在设置里可以按照节点标签设置不同的颜色。这个功能用来调试数据关系非常方便我建议在做前端之前先用Browser把所有主流程数据验证一遍。4.2 用vue3搭建知识图谱可视化页面前端选型我用了Vue3这是目前前端圈子里用得最多的框架之一vue3 实现知识图谱也是身边朋友问得比较多的话题。可视化环节的方案不少我对比过ECharts Graph和AntV G6最后选了AntV G6原因是G6的交互能力更强拖拽、缩放、点击展开这些操作比ECharts顺手定制节点样式也更灵活。后端需要提供一个接口返回图数据。我的接口做法是传入一个实体名称后端执行一次两跳查询把节点和关系打包成JSON{ nodes: [ { id: D001, label: 感冒, type: disease }, { id: S001, label: 头痛, type: symptom } ], edges: [ { source: D001, target: S001, relation: HAS_SYMPTOM } ] }前端拿到数据后用G6实例化一个图按节点类型做颜色区分。这里有几个细节值得说节点大小我按照关系数量做了缩放被越多关系连接的节点显示得越大这样一眼就能看出哪些是核心实体边的颜色根据关系类型区分HAS_SYMPTOM用蓝色、TREAT_WITH用绿色、FORBIDDEN_IN用红色医疗场景里红色传递风险信息用户理解起来非常直观。4.3 交互体验优化的两个要点第一个要点是节点Hover展示详情。G6内置了tooltip插件直接把节点的详细信息比如疾病描述、药物说明展示在悬浮框里。第二个要点是点击节点做下钻。我在图配置里监听了节点点击事件点击一个疾病节点就动态请求后端把这个疾病的二跳邻居追加到当前图数据里并重新渲染。这样实现了一个渐进式探索的交互用户从感冒节点一路点下去可以慢慢展开整个知识图谱。这个交互上线之后演示效果比静态图好太多了。5. 踩坑实录与问题排查技巧5.1 CSV导入乱码和字段错位问题导入CSV乱码这个问题几乎是必现的。Windows下保存的CSV文件默认是GBK编码而Neo4j的LOAD CSV默认按UTF-8解析结果就是中文全部变成乱码。解决办法是按提示我建议在编辑数据时直接用UTF-8编码保存CSV文件如果已经生成了GBK文件用文本编辑器转存为UTF-8格式。另外如果你用的是Excel处理CSV一定要检查一下有没有多余的BOM头有时候BOM会导致第一列字段名变成\ufeffdisease_id导入时匹配不上。字段错位的问题则主要来自CSV里包含逗号内容。某一行数据里如果描述字段本身带了英文逗号又没有加引号包裹LOAD CSV就会把这一行拆成多列。排查起来非常恶心因为大部分行都对就只有个别行错位。我的解决办法是在导入前写个Python脚本对CSV做一次字段数校验逐行确认列数相等不一致的自动报警提示。5.2 查询性能突然变慢先看有没有索引知识图谱项目数据量小的时候有没有索引体感不明显。数据涨到几万节点后不带索引的查询经常要几秒钟这时候就不得不回头看索引设计。Cypher查询里的WHERE条件用到的属性以及MATCH模式里的起始节点定位属性都应该建索引。我最开始只给name建了索引后来发现id作为关联字段查询频率更高赶紧补了一个CREATE INDEX disease_id_index IF NOT EXISTS ON (d:Disease) ASSERT d.id IS NOT NULL;建完索引之后再跑查询性能提升了不止一个量级。如果你发现某些查询依然很慢可以用EXPLAIN先看执行计划再看PROFILE查看实际执行细节优先优化那些查询计划里没有走索引的节点查找。5.3 实体识别命中率低词典需要迭代问答系统上线后发现一个问题用户问孩子发烧怎么办我的症状词典里只有发烧没有孩子导致识别出症状却匹配不到人群最终回答不了。这个问题的根子在于词典覆盖不足。后来我维护了一个独立的词典迭代清单每次在测试集里发现识别失败的问句就人工判断是缺实体还是缺意图规则补进词典里再回归测试。跑了两个星期之后识别覆盖率从刚开始的70%左右提到了85%以上。这个工作没有什么捷径就是不停喂数据、看结果、补词典的死循环。5.4 前端可视化卡顿多层展开控制节点数G6在做大规模图渲染时几千个节点同时渲染必定卡顿。我做了一个限制策略前端只渲染两跳以内的节点点击展开时每次最多新增50个节点。同时关闭了G6的动画相关特性在数据量大的场景用静态布局替代力导向布局。这套优化之后图交互的流畅度提升非常明显。如果你后续的数据规模到了十万节点以上就建议在后端做图裁剪了前端只负责渲染这个方向的取舍要提前想好。最后再说两句这个项目做完我最深的一个体会是知识图谱难的不是技术选型也不是Cypher查询怎么写而是把业务问题翻译成图谱查询的能力。同样一句头痛可以吃什么药如果只在单跳范围内建模永远回答不了用药前应该注意什么。模型设计的每一条关系本质上都是在为未来的某个问题做准备。后续我想在这个框架上扩展两个方向一是把药物相互作用关系加入图谱让问答系统能回答高血压药和感冒药能一起吃吗这种合并用药问题二是引入大模型做意图解析的兜底把规则识别不出来的问句转给大模型来解析再落到图谱查询。这个葫芦已经画好了等下次有功夫再接着挖。本文还有配套的精品资源点击获取