简介这是一套基于 Python 的医疗知识图谱自动问答系统源码主要面向医疗信息化方向的学生、算法工程师以及自然语言处理爱好者以“医疗实体识别—图谱构建—问题匹配—答案生成”为主线解决用户在健康咨询中难以快速获取结构化医学知识的问题。压缩包共 26 个文件涵盖 8 个 Python 脚本、8 个 txt 医学语料、5 个 XML 配置、2 个 JSON 数据文件等包体大小约 15.54MB。py 脚本完整覆盖数据预处理、医疗图谱构建、问句分类、实体抽取、Cypher 查询和 Web 展示txt 与 JSON 文件提供症状、疾病、药物、科室、食物等实体关系数据可供二次扩展。目前已有 184 人学习浏览是知识图谱与医疗问答结合的典型实战项目。源码中使用了 NLTK、spaCy、Flask 等工具链开发者可以掌握从非结构化医疗文本到图数据库查询的完整链路理解意图识别、槽位填充和查询语句生成等关键算法并快速迁移到法律、农业等垂直领域的问答系统建设中附带的医学语料也可直接用于测试减少数据收集成本。1. 医疗知识图谱自动问答系统为什么说它比通用ChatBot更值得先落地一个能回答“高血压患者能不能吃柚子”的医疗问答机器人背后不是大模型而是一张把疾病、症状、药品、科室、禁忌症全部串起来的知识图谱外加一套把口语问句翻译成图谱查询的流水线。基于Python的医疗知识图谱自动问答系统源码正是把这套东西从论文里搬到工程里的完整实现。它的核心价值在于不依赖GPU、不烧接口费、回答可溯源每条答案都能拽出图谱里的实体关系链路。这个项目最适合两类人一类是正在做毕业设计或课程设计的学生需要一套能跑通、能讲清楚原理的完整系统另一类是医疗信息化或健康管理方向的开发者想用最小成本验证“知识图谱问答”在自己业务里的效果再决定要不要上大模型方案。读完这篇文章你会知道这套系统的骨架长什么样、用Python怎么把问句变成Cypher查询、以及哪些坑会让你的演示现场翻车。2. 系统拆解医疗问答不是“问一句答一句”而是“问句→图谱→答案”2.1 知识图谱问答的完整链路从用户输入到答案返回的五步管线医疗知识图谱自动问答系统的核心是一条五步管线理解了这条管线你拿到任何源码都能快速定位它的模块边界。第一步是问句预处理把用户输入“感冒了流鼻涕吃什么药”做分词、去停用词、词性标注第二步是意图识别判断用户是在问“吃什么药”还是在问“什么病不能吃这个药”业界最常见的做法是基于规则模板加轻量分类器而不是上深度学习第三步是实体抽取与链接从问句里找出“感冒”“流鼻涕”这些实体并映射到知识图谱里预先定义的标准实体名上这一步是整个系统的成败关键第四步是查询构建把“疾病→治疗→药品”这样的意图模板转成Cypher或SPARQL语句第五步是答案生成把查询结果组织成自然语言返回给用户。这五步里第三步“实体链接”的坑最深因为用户不会按图谱里的标准名说话。比如图谱里存的是“上呼吸道感染”用户说的是“感冒”还有“伤风”这种别名如果别名表没建好后面的查询直接就断掉。所以拿到一个医疗问答源码先别急着跑打开它的实体词典文件看看别名词条覆盖了多少、是同义词表还是简单的字符串包含匹配。2.2 为什么选Neo4j而不是MySQL关系查询的胜负手医疗知识图谱的存储选型常见有三个方向RDF三元组库如Apache Jena、图数据库如Neo4j、关系型数据库如MySQL。项目源码里绝大多数会选Neo4j原因很直接医疗问答的查询全是多跳关系比如“哪些药不能和降压药一起吃”需要查“药品-相互作用-药品”的关联路径这种查询在MySQL里要多次JOINSQL写得又长又难维护在Neo4j里一条Cypher就搞定。Neo4j的另一个优势是它的查询语言Cypher对新手友好可视化界面能直接看到查询路径。调试的时候你写一句MATCH (d:Disease)-[:HAS_SYMPTOM]-(s:Symptom) WHERE d.name 糖尿病 RETURN s.name在浏览器里马上能看到图谱路径这对排查“为什么没查出来”特别有用。MySQL方案也不是没有有些源码为了降低部署难度会提供MySQL版用关系表存三元组但你会发现查询代码里全是字符串拼接的SQL改起来很痛苦。2.3 源码工程里你会看到的目录结构拿到包先找这五个文件下载一个“基于python的医疗知识图谱自动问答系统源码.zip”解压之后先别急着运行按下面的目录清单核对一下工程完整性。一个规范的源码包通常包含这些部分。medical_qa_system/ ├── data/ # 原始数据与构建好的图谱数据 │ ├── disease.txt # 疾病实体表 │ ├── symptom.txt # 症状实体表 │ ├── drug.txt # 药品实体表 │ └── relation.txt # 实体关系表三元组 ├── kg/ # 知识图谱构建模块 │ ├── build_graph.py # 把三元组导入Neo4j │ └── entity_linking.py # 实体链接与别名归一化 ├── qa/ # 问答核心模块 │ ├── intent.py # 意图识别 │ ├── query_builder.py # Cypher查询构建 │ └── answer.py # 答案生成 ├── web/ # Web展示层 │ └── app.py # Flask或FastAPI入口 ├── requirements.txt # 依赖清单 └── README.md # 部署说明拿到源码后依次确认五个关键文件是否齐全requirements.txt决定你能不能装上依赖build_graph.py决定图谱能不能建起来entity_linking.py决定问答准不准query_builder.py决定查询能不能命中README.md决定你要踩多少坑。很多号称完整的源码包其实会故意删掉build_graph.py里的数据导入部分让你跑不起来这种包的价值就要打折扣了。3. 跑通这套医疗问答系统环境准备、图谱构建与服务启动3.1 Python环境与Neo4j安装版本匹配是第一道坎先把环境备齐。这个项目依赖Python 3.8以上版本Neo4j社区版4.x或5.x都可以但要注意py2neo库的版本必须和Neo4j版本匹配——py2neo 4.x对应Neo4j 3.x和4.xpy2neo 2021.2.3之后的版本才支持Neo4j 5.x。这里用conda创建一个独立环境避免把系统Python搞乱。# 创建Python虚拟环境 conda create -n medical_qa python3.9 conda activate medical_qa # 安装项目依赖 pip install -r requirements.txt # 如果requirements.txt缺失或不全手动安装核心依赖 pip install py2neo flask jieba逻辑说明conda create这里把Python版本锁在3.9是因为很多医疗问答源码用了较老的依赖库比如py2neo的某些版本在Python 3.10以上会有collections.Iterable导入报错。jieba是中文分词库医疗问句必须先分词才能做实体识别。如果你用的是macOS或Linux装完依赖后建议跑一下python -c import py2neo; print(py2neo.__version__)确认版本号这个动作能提前暴露80%的兼容性问题。参数说明Neo4j默认端口是7687Bolt协议和7474HTTP管理界面。如果本机装了多个Neo4j实例要检查conf/neo4j.conf里的server.bolt.listen_address和server.http.listen_address是否被占用。另外Neo4j 5.x默认开启了认证初始账号密码是neo4j/neo4j第一次登录会让你改密码这个密码后面要用Python代码连上去。3.2 把医疗三元组导入Neo4j构建图谱的两种方式图谱数据导入有两种常见方式。一种是源码包里直接带data/*.txt文件用Python脚本批量导入另一种是源码里只有build_graph.py但数据要自己准备。先看第一种也是最省事的。# kg/build_graph.py from py2neo import Graph, Node, Relationship # 连接Neo4j地址和密码改成你自己的 graph Graph(bolt://localhost:7687, auth(neo4j, your_password)) def import_entities(graph, entity_type, file_path): 从文本文件导入实体每行一个实体名 with open(file_path, r, encodingutf-8) as f: for line in f: name line.strip() if not name: continue node Node(entity_type, namename) graph.merge(node, entity_type, name) # merge而不是create避免重复导入 def import_relations(graph, relation_file): 从三元组文件导入关系每行格式头实体 关系 尾实体 with open(relation_file, r, encodingutf-8) as f: for line in f: head, rel, tail line.strip().split(\t) # 查找头尾实体节点 head_node graph.nodes.match(head_type, namehead).first() tail_node graph.nodes.match(tail_type, nametail).first() if head_node and tail_node: rel_obj Relationship(head_node, rel, tail_node) graph.merge(rel_obj, rel, name) if __name__ __main__: import_entities(graph, Disease, data/disease.txt) import_entities(graph, Symptom, data/symptom.txt) import_entities(graph, Drug, data/drug.txt) import_relations(graph, data/relation.txt)逻辑说明graph.merge(node, entity_type, name)这条语句是幂等操作意思是“如果name属性已存在就跳过否则新建”比graph.create安全得多——重复运行脚本不会把实体建两遍。import_relations里关键的一步是先用graph.nodes.match按名称找到头尾两个实体节点再创建关系。找不到节点就直接跳过这种数据容错在医疗数据里很有必要因为原始数据经常有实体名对不上号的情况。参数说明entity_type是Neo4j里的标签Label你可以理解成MySQL的表名。这里用Disease、Symptom、Drug做标签关系用字符串比如HAS_SYMPTOM、DRUG_FOR_DISEASE。关系类型命名建议用大写加下划线的形式HAS_SYMPTOM而不是has_symptom这样Cypher语句读起来更清楚也跟社区惯例一致。另一种方式是图中没有data目录只有几段建图SQL或一个JSON文件。这种情况你会需要写一个解析器把JSON里的嵌套结构拍平成三元组。核心思路是一样的先建实体再建关系。我遇到过一个源码包它把数据存在data.json里每个疾病节点底下挂着症状列表和药品列表我写了个二三十行的递归函数就把所有三元组提取出来了。注意导入数据前先在Neo4j里执行MATCH (n) DETACH DELETE n清空库不然反复调试会把图谱弄脏。3.3 启动Web服务Flask版问答接口的最小可运行demo图谱建好之后接着启动问答服务。大多数源码用Flask或FastAPI做Web层这里以Flask为例。# web/app.py from flask import Flask, request, jsonify from qa.intent import IntentClassifier from qa.entity_linking import EntityLinker from qa.query_builder import QueryBuilder from qa.answer import AnswerGenerator app Flask(__name__) # 初始化各模块加载词典和模型 intent_clf IntentClassifier() entity_linker EntityLinker() query_builder QueryBuilder() answer_gen AnswerGenerator() app.route(/qa, methods[POST]) def qa(): 问答接口接收JSON{question: 感冒了吃什么药} data request.get_json() question data.get(question, ) if not question: return jsonify({error: question is required}), 400 # 1. 意图识别 intent intent_clf.predict(question) # 2. 实体链接 entities entity_linker.link(question) # 3. 构建Cypher查询 cypher query_builder.build(intent, entities) # 4. 执行查询并生成答案 answer answer_gen.generate(cypher, entities) return jsonify({intent: intent, entities: entities, answer: answer}) if __name__ __main__: app.run(host0.0.0.0, port8080, debugTrue)逻辑说明这段代码展示了问答模块之间怎么协作。注意IntentClassifier和EntityLinker在服务启动时就完成了初始化——它们的词典文件在构造函数里加载如果放到每次请求里加载高频查询时磁盘IO会拖垮延迟。query_builder.build()返回的是一条Cypher语句字符串answer_gen.generate()里会执行这条语句并做结果包装。参数说明host0.0.0.0表示监听所有网卡这样同一局域网的其他人也能访问你的服务方便演示。debugTrue在开发期开着好用改代码自动重启但部署到生产环境必须改成False否则会暴露堆栈信息并且性能很差。端口选了8080是为了避开Neo4j的7474端口冲突。启动服务前先跑一个冒烟测试直接调一次问答接口。curl -X POST http://localhost:8080/qa \ -H Content-Type: application/json \ -d {question: 高血压患者可以吃柚子吗}如果返回里有answer字段并且内容不是“抱歉我不明白”之类的兜底话术说明整条链路通了。如果返回的是兜底话术大概率是实体链接没命中去检查实体词典里有没有“高血压”“柚子”这两个词条。4. 调优问答准确率的四个关键点意图识别、实体链接、查询构建与答案润色4.1 用规则加词典做意图识别为什么不用BERT也能有八十分医疗问答的意图集合是有限的求医问药疾病→治疗药品、症状查询疾病→症状、科室推荐疾病→科室、药品禁忌药品→禁忌症、检查项目疾病→检查。这些意图的区分度其实很高用关键词规则加词典就能覆盖大多数情况不需要上BERT。# qa/intent.py import jieba import re class IntentClassifier: def __init__(self): # 每个意图对应一组触发词 self.intent_patterns { treatment: [吃什么药, 怎么治, 用什么药, 治疗, 用药], symptom: [症状, 表现, 有什么感觉, 会怎么样], department: [挂什么科, 哪个科, 科室, 就诊], drug_contraindication: [不能吃, 禁忌, 忌口, 不能服用], check: [检查, 化验, 拍片, 检测], } def predict(self, question): 返回意图标签默认是treatment for intent, keywords in self.intent_patterns.items(): for kw in keywords: if kw in question: return intent return treatment逻辑说明这个分类器走的是“包含即命中”的路线代码很短但实用。先把三个高频意图治疗、症状、科室的触发词背熟你会注意到“高血压患者可以吃柚子吗”这句话里如果用户说的是“可以吃”你的drug_contraindication意图里的“不能吃”就匹配不上。所以调优时一定要看真实用户问句反向补充触发词。参数说明意图之间的顺序很关键drug_contraindication必须放在treatment前面判断因为“高血压不能吃柚子”里既包含“吃”又包含“不能吃”如果先命中treatment就错了。这个顺序本质上是你定义的业务优先级调试时别随意调换。触发词尽量用短词而不是整句比如“吃什么药”这个四字短语就比分词后的“吃”“什么”“药”三个词单独判断更稳定。实际项目中如果在这个规则分类器上叠加一个朴素贝叶斯或逻辑回归模型把规则分类的结果作为特征之一准确率还能再往上走一两个点。但别急着上深度学习先把词典和规则的边界做扎实——医疗问句的表达方式相对固定用户不会像闲聊那样天马行空。4.2 实体链接的别名表决定问答命中率的核心资产实体链接是医疗问答里最容易被低估的模块。你要把“高血压”“高血压病”“hypertension”“原发性高血压”全部映射到同一个标准实体节点上这是典型的“一词多义归一化”。常见做法是AC自动机做多模式匹配配合一个别名词典做归一化。# qa/entity_linking.py from ahocorasick import Automaton class EntityLinker: def __init__(self, alias_filedata/alias.txt): self.entity2alias {} # alias - 标准实体名 self.automaton Automaton() # 读取别名文件格式别名\t标准实体名 with open(alias_file, r, encodingutf-8) as f: for idx, line in enumerate(f): alias, entity line.strip().split(\t) self.entity2alias[alias] entity self.automaton.add_word(alias, (idx, alias)) self.automaton.make_automaton() def link(self, question): 返回问句里命中的标准实体名列表 entities [] for end_index, (idx, alias) in self.automaton.iter(question): entity self.entity2alias[alias] if entity not in entities: entities.append(entity) return entities逻辑说明AC自动机的好处是一次建树、多次匹配即使别名表里有几千个词条扫一遍问句就能找出所有命中的别名。automaton.add_word(alias, (idx, alias))里的idx是每个词条的编号用来自动去重。返回结果里entities就是归一化后的标准实体名列表直接传给后面的query_builder使用。参数说明alias.txt手工维护成本很高拿到源码后第一件事就是看这个文件里有多少条数据。只有几百条的话建议用爬虫从公开医学词库或药典附录里再扩充一批否则问答系统在演示时会频繁“翻车”。扩充别名词条时注意别把泛义词加进去比如“心脏”这个词在“心脏病”和“心脏搭桥”里都会出现不加限制会导致实体歧义。一个技巧是别名至少两个字符起步单字别名误匹配率太高不建议加。实体链接的另一个细节是在一句话里同时命中多个实体时要能区分哪些是主题实体、哪些是修饰实体。比如“糖尿病患者出现视力模糊应该挂什么科”这里“糖尿病”是主题疾病“视力模糊”是症状。源码里如果只返回实体列表而丢失位置信息后面的查询构建就只能靠猜。4.3 用模板把意图变成Cypher预编译模板比动态拼串好维护查询构建是整个系统里“黑匣子”味道最浓的部分。很多源码的翻车现场就是在这里——模板没覆盖到某种问法或者拼接语句时少了引号导致Neo4j报语法错误。成熟做法是给每个意图预定义好Cypher模板再把实体填充进去。# qa/query_builder.py class QueryBuilder: def __init__(self): self.templates { # 治疗意图疾病 - 推荐药品 treatment: MATCH (d:Disease)-[:DRUG_FOR_DISEASE]-(drug:Drug) WHERE d.name {entity} RETURN drug.name, # 症状意图疾病 - 症状 symptom: MATCH (d:Disease)-[:HAS_SYMPTOM]-(s:Symptom) WHERE d.name {entity} RETURN s.name, # 科室意图疾病 - 推荐科室 department: MATCH (d:Disease)-[:DEPARTMENT_OF]-(dep:Department) WHERE d.name {entity} RETURN dep.name, # 禁忌意图药品 - 禁忌人群/食物 drug_contraindication: MATCH (drug:Drug)-[:CONTRADICTS]-(item) WHERE drug.name {entity} RETURN item.name, } def build(self, intent, entities): if not entities: return None # 取第一个实体作为主题实体 entity entities[0] template self.templates.get(intent) if template is None: return None return template.format(entityentity)逻辑说明这个实现里有个简化处理——直接取entities[0]作为主题实体。如果问句里同时出现两个实体比如“糖尿病患者吃二甲双胍要注意什么”只取第一个“糖尿病”就会丢掉关键信息。更好的做法是让entity_linking按词性标注结果返回实体角色主题实体和修饰实体分开再传入query_builder。参数说明Cypher模板里的{entity}是Python的format占位符注意这里的name属性值如果包含特殊字符比如单引号会让Cypher语句报错。防注入的土办法在填入之前对实体名做一次entity.replace(, )把单引号剥掉。虽然是自己搭的本地服务但这个习惯能帮你避免很多反馈里说的“一查就报错”问题。另一个调优点CONTRADICTS关系在原始数据里往往没有如果你发现禁忌查询经常返回空去Neo4j浏览器里执行一下MATCH ()-[r:CONTRADICTS]-() RETURN count(r)看看这个关系到底有没有数据。4.4 让答案像人话答案模板和兜底策略怎么设计最后一步是把查询结果包装成自然语言。这里要处理两个问题结果是空列表时怎么办结果是单条时怎么组织语言。这两个问题都能用模板解决。# qa/answer.py from py2neo import Graph class AnswerGenerator: def __init__(self, graph): self.graph graph def generate(self, cypher, entities): if cypher is None: return 抱歉我没理解你的问题请换个方式描述。 try: result self.graph.run(cypher).data() except Exception as e: # 查询报错时返回兜底话术而不是让服务崩溃 return f系统开小差了请稍后再试。({str(e)}) if not result: # 空结果告诉用户没找到相关信息 return 知识库里暂时没有找到相关信息你可以试试问其他疾病。 # 把查询结果拼成答案 answers [list(item.values())[0] for item in result] if len(answers) 1: return f根据知识图谱{entities[0]}的建议如下{answers[0]}。 return f根据知识图谱{entities[0]}的推荐结果有{len(answers)}条 .join(answers) 。逻辑说明graph.run(cypher).data()返回一个字典列表每个字典是一行结果。代码里用list(item.values())[0]取出第一列的值——这个位置对应模板里RETURN后面的字段比如drug.name。如果源码里的查询返回多个字段比如同时返回药品名和用法用量就要再加工一下把字段拼成完整句子。参数说明兜底话术的质量会影响用户对系统的整体观感。这里用“知识库里暂时没有找到相关信息”比“我不明白”更专业因为它把问题归因到知识库覆盖度而不是系统能力。实际调优时还要处理一种情况结果很长时只返回前三条并提示“更多结果请查看完整报告”避免接口响应体过大。5. 避坑与排查医疗问答系统最常见的七个“演示现场翻车点”5.1 实体导入后查询为空关系方向搞反了现象图谱里节点都在但问“感冒吃什么药”返回空。 原因import_relations.py里创建关系时把头尾实体顺序写反了Disease-Drug写成了Drug-Disease。Cypher里关系是有方向的MATCH (d:Disease)-[:DRUG_FOR_DISEASE]-(drug:Drug)和MATCH (drug:Drug)-[:DRUG_FOR_DISEASE]-(d:Disease)查出的结果完全不同。 解决在Neo4j浏览器里执行MATCH p()-[r:DRUG_FOR_DISEASE]-() RETURN p LIMIT 5肉眼确认箭头方向。修正脚本后先执行MATCH (n) DETACH DELETE n清空再重新导入。5.2 py2neo连接报“Unauthorized”或“The client is unauthorized due to authentication failure”现象启动build_graph.py时连接Neo4j失败报401错误。 原因Neo4j设置了初始密码后项目代码里写的还是初始密码neo4j/neo4j或者密码里带了特殊字符没转义。 解决用Graph(bolt://localhost:7687, auth(neo4j, 你的实际密码))重新初始化。特殊字符建议提前改掉比如密码里的在某些老版本py2neo的URI解析里会出问题如果用URI方式传密码需要对特殊字符做URL编码。5.3 分词导致实体无法匹配自定义词典缺失现象问“高血压病人”时jieba把“高血压病人”切成“高血压/病人”匹配不上图谱里的“高血压”。 原因jieba的默认词典是通用语料训练的对医学术语支持不足。 解决在data/下建一个自定义词典文件比如medical_dict.txt每行一个词然后初始化jieba时加载它import jieba jieba.load_userdict(data/medical_dict.txt)把高频实体和别名都加进去比如“高血压”“高血压病”“上呼吸道感染”“股骨头坏死”。加载后可以用jieba.add_word(高血压, freq1000)单独强插防止被错误切分。5.4 查询语句没问题但结果不完整知识图谱数据稀疏现象问“糖尿病症状”只返回一条但真实症状明明有十几条。 原因三元组文件里的HAS_SYMPTOM关系不全或者导入时因实体名不一致跳过了大量关系。 解决先检查原始数据里relation.txt的行数。如果数据本身稀疏可以用公开医学数据补充比如CCKS评测发布过中文医学知识图谱数据集网上也能找到一些开放的中文医学概念关系数据。这类数据下载后需要转换格式走一遍import_relations即可注意别在正文里写具体数据集链接。5.5 接口响应太慢每次请求都重新加载词典现象第一次请求要等好几秒后续请求正常。 原因源码里把词典加载和AC自动机构建写在了qa()函数内部每次请求都重新执行一遍。 解决把IntentClassifier()、EntityLinker()等对象的初始化移到模块加载时只做一次。衡量标准如果内存允许服务启动时加载所有词典请求时只做匹配和查询这样单次响应能压到200ms以内。5.6 Neo4j内存溢出图谱节点太多但JVM堆没调现象导入大数据量时报Java heap space错误。 原因Neo4j的JVM堆默认值偏小当实体和关系总数超过几十万时容易触发。 解决修改Neo4j安装目录下conf/neo4j.conf里的server.memory.heap.initial_size和server.memory.heap.max_size一般设为1G到2G足够。改完重启Neo4j服务。注意云服务器内存不足时别硬调否则系统会OOM。5.7 浏览器页面可以打开但接口404Flask路由前缀不一致现象访问http://localhost:8080/qa返回404。 原因源码里app.route装饰器写的是/api/qa或者启动时用了蓝图且注册了前缀。 解决看Flask启动日志里打印的路由列表或者直接打开http://localhost:8080/看首页提示。如果源码用了蓝图访问路径可能是/api/qa把curl命令的路径改成对应的就行。这个问题在二次开发时特别常见改路由前先搜一下app.route或Blueprint注册代码。6. 把demo变成能用的系统数据扩充、答案溯源与性能验证6.1 从固定模板到可复用的医疗问答基座拿到这个源码一个很现实的问题是数据量太小。大多数开源医疗知识图谱问答源码自带的数据集只有几十种疾病、几百个关系演示有余、实用不足。你会需要两步走第一步扩充实体和关系数据第二步把问答系统的接口标准化方便接入前端或小程序。数据扩充的方向优先级是先补疾病-药品关系这是用户最常问的再补疾病-症状关系最后补别名词典。具体的扩充流程是整理现有图谱里已有的实体ID从公开医学数据源里找到这些实体的关联数据转成三元组格式跑一遍import_relations。这里会遇到一个数据质量问题不同来源对同一关系的表述不一样比如“禁忌”和“不宜服用”可能是同一个意思。建议在relation.txt里统一关系类型命名不要混用。6.2 让每条答案都可溯源追问路径的验证技巧医疗问答系统和通用闲聊最大的区别是答案必须有依据。做验证时可以用一个“追问”接口来验证答案的可靠性——用户问到某个答案后再问“为什么”系统返回图谱里的完整路径。MATCH (d:Disease)-[r]-(n) WHERE d.name 糖尿病 RETURN d.name, type(r), n.name LIMIT 10这条语句返回一个疾病节点的所有一跳关系你可以把它嵌进一个“溯源”接口每次生成答案时附带返回这条路径。验证时观察三点关系类型是否符合直觉、目标节点类型是否正确、路径是否有重复节点有重复说明图谱里有循环数据。我自己检查时习惯先跑一遍全量节点和关系的统计看看有没有孤立节点和自环关系这种数据会让“为什么”接口暴露奇怪的答案。6.3 压测与效果评估上线前的两个硬指标效果评估分成两部分图谱覆盖率评估和问答准确率评估。覆盖率看的是“用户问的实体图谱里有没有”做法是准备一百条真实医疗问句跑一遍实体链接统计命中率准确率看的是“推荐结果用户认不认”做法是对每一条问句人工判断答案是否符合常识和医学共识。压测就更直接了。用locust或wrk对/qa接口做并发测试重点观察两个指标P95延迟和错误率。如果P95超过1秒先查是不是Neo4j查询慢到Neo4j浏览器里跑一下同样的Cypher看执行计划里有没有全表扫描。热点查询要给关系建索引比如CREATE INDEX FOR (d:Disease) ON (d.name)这能解决90%的查询慢问题。最后说一个我自己的习惯跑通系统后我会把五十条测试问句连同期望答案存成一个JSON文件每次改动代码后跑一遍回归测试。医疗问答这种系统改了一个实体别名可能影响十几个问题的答案没有回归测试兜底很容易在演示时被一个之前能回答的问题卡住。这套源码值得投入前提是你把数据当资产来养而不是把代码跑通就万事大吉。希望帮到你。本文还有配套的精品资源点击获取
