最近在折腾一个开源项目名为QASystemOnMedicalKG-master简单说就是一套基于医疗知识图谱的问答系统。它做的事是把医学领域的知识整理成“实体-关系-实体”的三元组结构比如 “糖尿病 - 并发症 - 视网膜病变”然后让用户用自然语言提问比如“糖尿病的早期症状有哪些”系统通过实体识别和关系匹配到图数据库里把答案捞出来再返回给用户。这个方向我关注挺久了医疗信息检索一直有个痛点传统的关键词搜索只能返回一堆文档链接用户得自己翻找答案而知识图谱问答能直接给出精准答案体验完全不同。这篇记录适合三种人看一是正在做知识图谱项目的开发者想参考一套完整的落地流程二是对智能问诊、辅助诊断感兴趣的产品经理三是想找个实战项目入门NLP和图数据库的初学者。我会把这套系统的架构、核心模块、实操踩坑过程全部梳理出来尽量把关键细节讲透。1. 项目整体认知这个系统到底怎么工作1.1 医疗知识图谱的核心价值医疗知识图谱的本质是把散落在医学百科、临床指南、论文中的信息抽成结构化数据。为什么要这么做因为医学知识的关系极其复杂一个疾病往往关联多个症状、药物、检查项目和并发症这些关系用传统关系型数据库表达会很痛苦每次查询都要写多表关联SQL而且扩展性差。图数据库用节点和边直接建模天然贴合这种网状结构。我一开始也犹豫过直接用Elasticsearch全文搜索不就行了干吗非要图数据库实际对比下来就明白了。知识图谱能回答“A导致BB又引发C”这种多跳问题比如用户问“高血压患者长期吃某类药物可能出现什么并发症”搜索引擎只能匹配关键词图谱问答却可以沿着“高血压 - 用药 - 药物副作用 - 并发症”的路径逐层推理。这套系统选择Neo4j作为存储引擎看中的就是它的遍历能力和Cypher查询语言几行代码就能表达复杂关系。另一个价值在于数据复用。知识图谱构建好之后不只是问答系统可以用临床决策支持、科研检索、药物相互作用提醒都能复用同一份数据。我见过不少团队做了图谱只为了展示“看我们有个图”但真正把图谱用起来的第一站就是问答系统因为它最贴近用户也最容易验证图谱质量。1.2 问答系统的整体架构探索这个系统时我习惯先从整体架构入手避免一头扎进代码细节出不来。这套QA系统的流程可以概括为四步问题理解、实体识别、图谱查询、答案生成。具体拆开看用户输入自然语言问题系统先做预处理包括分词、去停用词、提取关键词。通过命名实体识别NER定位问题中的疾病、症状、药物、检查项目等实体。比如“感冒有哪些症状”里“感冒”就是疾病实体。根据识别出的实体和问题中的疑问词匹配预设的问答模板确定用户的意图是问“病因”“症状”“饮食”还是“药品”。把模板映射成Cypher查询语句到Neo4j图数据库里执行拿到结果后经过简单格式化返回。这套流程比纯端到端的深度问答模型更好落地。原因很实在医学领域标注数据贵医疗实体识别模型需要大量标注语料而基于规则和模板的方法在垂直领域里完全够用准确率还容易控制。系统作者把模板扩展做得比较轻量新增一种问题类型只需加模板和对应的Cypher语句这对我们二次开发非常友好。2. 核心技术模块拆解2.1 知识图谱构建从数据到三元组整个系统里投入工作量最大的部分就是图谱构建。我看了下项目的数据来源和构建脚本思路很清晰先准备医学词典和语料然后抽取实体和关系最后写入Neo4j。医学实体识别是第一步。系统没有直接用深度学习模型而是用基于词典的前向最大匹配算法来识别疾病、症状等实体。这种方案的优势是快、可解释、不依赖GPU。但缺点是词典覆盖直接决定了识别上限。项目自带了一个医学实体词典大概包含几万个实体词条覆盖常见内科、外科疾病和症状。我在探索时发现词典质量是整条链路的天花板如果实体覆盖率不够后面的问答效果会断崖式下跌。关系抽取则采用半自动方式。项目先定义了一组核心关系类型疾病_症状、疾病_并发症、疾病_常用药物、疾病_检查项目、疾病_所属科室、疾病_饮食建议等。然后从结构化数据源里直接解析字段比如从医学百科的“疾病信息卡”里抓取“症状”“常用药物”等字段再映射成图谱关系。我在实际复现时建议你先把数据清洗干净。原项目的数据已经整理过一轮但仍有重复和噪声。我写了个小脚本做实体对齐把“慢性阻塞性肺疾病”和“慢阻肺”合并成同一实体。这一步很关键否则图数据库里会出现两个看似独立实则同一个疾病节点问答时会返回重复结果。图谱最终以三元组形式导入Neo4j。我贴一部分导入的关键配置供参考from py2neo import Graph, Node, Relationship graph Graph(bolt://localhost:7687, auth(neo4j, your_password)) # 创建疾病节点 disease_node Node(Disease, name糖尿病) graph.create(disease_node) # 创建症状节点 symptom_node Node(Symptom, name多饮) graph.create(symptom_node) # 建立“临床表现”关系 rel Relationship(disease_node, 临床表现, symptom_node) graph.create(rel)这个系统里用的是py2neo库版本兼容很挑剔新版对Cypher参数传递有变化我后面在问题排查部分会专门讲。2.2 命名实体识别与关系抽取的取舍很多初学者一听到“命名实体识别”马上想到Bert-BiLSTM-CRF。但在这个项目里实际用的方案是更朴素的词典匹配加规则修正。为什么不追热点我分析下来有三个原因一是医学实体普遍较长比如“上呼吸道感染”BERT类模型如果训练语料不足反而容易把实体切碎二是词典匹配能保证实体边界稳定尤其是在用户口语化提问时比如“我最近老咳嗽是不是肺炎”用词典规则能稳定抽出“咳嗽”和“肺炎”三是效果好维护发现漏识别时只需往词典加词而调模型则要重新标注和训练。但词典匹配也有硬伤——歧义。比如“感冒”既是疾病名也可能是口语里的“着凉”。系统采用双向最大匹配加自定义词典权重来缓解优先匹配多字词匹配到疾病词库后再匹配症状词库。实际测试下来对医疗领域规范提问的识别准确率能到90%左右但问法太口语化时比如“嗓子疼怎么办”如果不把“嗓子疼”加入症状词典就识别不出来。关系抽取部分项目使用了基于依存句法的辅助规则。举个例子“糖尿病患者会出现多饮”这句话分词后“患者”和“出现”形成主谓关系“出现”和“多饮”形成动宾关系系统利用预先定义的依存关系规则抽取出“糖尿病 - 临床表现 - 多饮”三元组。这种半自动抽取在纯规则和全监督模型之间找到了平衡点。2.3 问答匹配与答案生成的设计思路问答模块是这个系统的“最后一公里”也是体现设计精细度的地方。项目没有用生成式大模型而是基于意图分类加模板匹配。核心设计分两层第一层是意图分类。系统定义了几种常见医疗意图寻找病因、寻找症状、寻找治疗方案、寻找用药建议、寻找检查项目、寻找科室。分类依据是问题里的疑问词和关键词。比如“原因”“引起”“导致”指向病因“什么药”“用什么”指向用药“挂什么科”“哪个科室”指向科室。第二层是模板到Cypher的映射。每个意图对应多类问题模板每个模板又绑定一组Cypher查询模板。拿“疾病症状查询”举例MATCH (d:Disease {name: $disease_name})-[:临床表现]-(s:Symptom) RETURN s.name模板规定了参数绑定方式识别到的疾病实体作为$disease_name查询结果就是症状列表。这种设计的好处是答案可控、可解释不会出现大模型那种一本正经胡说八道的情况。我在探索中发现问答效果差往往不是模板不够而是前面的实体识别错了。比如“阿司匹林能治头痛吗”系统先识别到药物实体“阿司匹林”和症状实体“头痛”但意图模板如果只设计了“疾病-药物”方向没有反向的“药物-适应症”查询就会答不出来。所以模板设计时不能只考虑正向要覆盖常见的反向问法。这也是我强烈建议二次开发者扩展的第一块。3. 实操记录从零跑通项目的完整过程3.1 环境准备与依赖安装我是在一台8GB内存的Ubuntu服务器上跑的系统整体对资源要求不高主要消耗在Neo4j和Python服务上。我用的版本组合是Python 3.8 Neo4j Community 4.4 py2neo 4.3.2。这里必须强调版本匹配问题原项目是在Python 3.6时代开发的新版py2neo的API变动不小照老代码直接跑必报错。我的安装过程记录如下# 安装neo4j用docker最省事 docker run -d --name neo4j -p 7474:7474 -p 7687:7687 \ -e NEO4J_AUTHneo4j/test_password \ neo4j:4.4-community # 安装Python依赖 pip install py2neo4.3.2 flask1.1.4 jieba0.42.1有几个依赖坑要提醒原项目可能要求tensorflow其实如果你不打算跑深度模型纯词典匹配模式完全不需要千万别装CPU版TF白白浪费几GB空间。flask版本不宜太高新版对JSON和请求解析改动较大项目老代码容易不兼容。如果使用Python 3.9以上要注意jieba初始化时的缓存目录权限问题加上--user安装通常能解决。Neo4j启动后访问http://localhost:7474用浏览器登录初始密码改成自己的。这一步不做的话Python连接时经常因为认证失败报错。3.2 数据准备与图谱构建数据是整个系统的燃料。项目自带了一份医疗知识数据但我建议你先看下目录结构再决定是否直接用。我把数据文件归类后发现主要包含三类实体词典、关系数据、问答语料。实体词典是纯文本文件每行一个词例如糖尿病 慢性阻塞性肺疾病 高血压 多饮 多尿 视网膜病变关系数据是CSV或JSON格式每个条目是“头实体-关系-尾实体”的映射。系统自带数据已经覆盖了几百种疾病但偏科明显有些疾病只覆盖了“症状”一个维度缺少“用药”和“饮食”信息。我做了一轮扩充从公开的医疗百科爬取结构化信息然后清洗对齐耗时大约两个晚上。扩充后的图谱节点数从原来的几千上升到两万多关系数翻了三倍。构建图谱时我专门写了一个去重校验函数导入前先查询Neo4j里是否已存在同名节点存在就跳过不存在则创建。否则重复导入会导致节点膨胀问答结果里出现重复答案。完整导入流程如下读取实体词典生成疾病和症状节点。读取关系数据建立节点间的有向关系。检查所有节点是否有孤立节点没有关系连接的多半是数据脏或词典误识别输出到日志。对孤儿节点做人工复核是脏数据的删除是漏关系的补充。这个过程里我踩的最大的坑是Neo4j连接超时。数据量大时逐条创建节点效率极低一天都导不完。后来我改成批量方式先在Python里把节点和关系整理成列表用graph.merge批量创建或者直接用Cypher的LOAD CSV导入。两个方案对比下来LOAD CSV明显更稳更块尤其适合已经整理好的结构化文件。3.3 启动问答服务与测试服务本身是个Flask应用启动入口非常简单python qa_system.py启动成功后服务默认跑在http://localhost:5000。我习惯用 curl 做快速验证避免被前端页面干扰curl -X POST http://localhost:5000/qa \ -H Content-Type: application/json \ -d {question: 糖尿病的症状有哪些}返回结果大概是这样的JSON{ question: 糖尿病的症状有哪些, answer: 多饮、多尿、体重减少、视力模糊, entities: [糖尿病] }这个结果说明整条链路已经打通问题分词识别出“糖尿病”意图分类归到“症状查询”Cypher查询返回了症状列表。如果返回为空多半是实体没识别出来或者图谱里没有对应关系。我建议你准备一个测试用例表覆盖各种意图跑一遍看看哪些通过哪些失败。我测试时用了大概20个问题覆盖症状、用药、科室、饮食、检查五大方向。初步跑下来规范提问的准确率不错但口语化提问比如“老犯困是血糖高吗”基本识别不了因为“犯困”没进词典“血糖高”也不是正规的症状实体。这个问题后面调优时再说。4. 常见问题与排查技巧实录4.1 环境与依赖问题这类问题最多我直接列一个速查表症状可能原因解决方案连接Neo4j报Authorization Required密码没改或认证参数错误检查auth(neo4j, 密码)确保密码正确py2neo报AttributeError: Graph object has no attribute findpy2neo版本过高降到4.3.2Flask启动报ImportError: No module named flask_cors缺少依赖pip install flask-cors中文分词结果混乱jieba没加载自定义词典初始化时jieba.initialize()并加载项目词典Neo4j启动后端口被占8080/7474被其他容器占用更换映射端口我特别想强调不要盲目使用项目环境配置。老项目依赖的某些库已经严重过时甚至存在安全隐患。我在搭建时直接摒弃了原版的requirements按自己的版本组合来。探索项目不是复刻项目用“最小可用”原则保留核心功能就好。4.2 数据与图谱导入问题图谱导入阶段最容易遇到的问题是“数量对了但关系不对”。比如疾病节点和症状节点都创建了但查询时返回空我遇到过的情况是关系数据里的尾部实体名和节点名称不一致因为一个叫“視力模糊”繁体一个叫“视力模糊”简体在浏览器里看不出来Cypher查询却精确匹配失败。解决办法是统一规范文本大小写统一、繁简转换、去掉全角空格。我写了个预处理函数对所有实体名做了标准化再入库从此这类问题再没出现过。另外一个常见问题是Neo4j导入时Relationship类型名大小写敏感。如果你在关系数据里写“属于_科室”而查询时写的“属于_科室”看似一样其实不一样。建议项目里所有关系类型用统一风格命名我这边统一用了“实体类型_关系域”的格式比如疾病_常见症状、疾病_常用药物这样查询时不容易出错。4.3 问答效果调优的独家技巧效果调优是探索这个项目最有价值的部分。我分享几个实战经验这些在原项目文档里不可能写。第一实体词典不能只在项目里加要让jieba真正用上。系统里的实体识别虽然是自写的最大匹配但分词阶段依赖jieba。如果jieba没加载项目词典分词就会把“慢性阻塞性肺疾病”切成“慢性/阻塞/性/肺/疾病”实体匹配直接失败。解决办法是在项目初始化代码里加入import jieba jieba.load_userdict(medical_dict.txt)第二问答模板要覆盖“否定问法”和“反问法”。比如“心脏病不能吃什么药”这种问题如果模板里没有“禁忌”这个意图系统会错误地匹配为“常见用药”给出一堆错误推荐。我在模板系统里新增了“禁忌”意图对应Cypher查询里用(禁忌)关系而不是(常用药物)。这类问题在真实的患者提问中占比不低请务必处理。第三多实体问题要设置优先级。用户可能会问“糖尿病患者出现视网膜病变该怎么治”这句话里有两个疾病实体“糖尿病”和“视网膜病变”系统如果随机选一个实体去查询答案就不可控。我建议设定规则优先匹配“疾病”实体如果是并发症问题则识别两个实体之间的路径。这个虽然需要更复杂的模板但值得做。第四验证图谱数据质量的一个简单方法随机抽几个疾病节点查它们的关联关系数。如果绝大多数疾病的关联关系数少于3条说明图谱太稀疏问答系统的召回率会很低。这时候不是急着调模板而是先补数据。5. 一些个人经验和本项目之后还能怎么玩先讲数据扩充的体会。这个项目的医疗知识图谱基于公开语料实体覆盖率有限尤其对中医类、罕见病类支持很弱。如果你要做的是面向大众的科普问答现有规模勉强能用如果想做辅助决策数据量至少要翻十倍而且必须引入临床指南和药品说明书这类更权威的数据源错一个关系就是医疗事故级别的风险。关于系统架构我的判断是模板匹配方案在封闭域下依然是最稳的选择。不要因为大模型火就什么都拿去套大模型在医疗领域有严重幻觉问题而且推理成本高。这套系统的价值在于“可控”你可以完全追踪到每个答案的图谱路径。如果想把大模型嵌入进来我建议只做“灵活问法转标准问题”这一步比如用大模型把“我老咳嗽该去哪个科室”改写为“咳嗽挂什么科”然后把规则问法交给模板系统这既能改善体验又能保证可解释性。最后说一个值得扩展的方向把对话升级成多轮。当前系统是单轮用户问“糖尿病有什么症状”之后追问“能治好吗”系统会完全当作新问题处理丢失了上下文。我在自己的分支里加了一个简单的上下文槽位记录上一轮提到的疾病实体当下一轮没有识别到新实体时自动复用上一轮的实体。这个改动不大但体验提升非常明显。还有一个更实用的扩展接入语音输入。医疗问答的场景很多在移动端老人不太会打字。语音识别转文字后再交给现在的问答管线基本不用改下游代码。我实测过用云端语音接口识别中文医学名词准确率还可以只是一些生僻药名会被转成同音错别字需要在接进来之前加一步“医学名词纠错”。整个项目探索下来我的整体感受是医疗知识图谱问答不是模型问题而是数据工程问题。图谱的质量、实体词典的覆盖、模板的完善程度每一项都远比模型选型影响大。如果你也想跑通甚至改进这个项目建议先花60%时间搞数据20%时间搞图谱构建最后20%去做问答层调优这个比例大概率不会错。