1. 项目概述当医疗问答遇上知识图谱与大模型最近在做一个挺有意思的项目核心目标是把医疗领域的公开资料、临床路径这些文本变成一个能“听懂人话”的智能问答系统。听起来是不是有点像给医院做个AI小助手但这事儿远没想象中那么简单。医疗信息太专业了一个术语理解偏差就可能出大问题而且很多医院项目现场都是严格的内网环境网都上不去更别说调用那些需要联网的GPT大模型了。资源也紧张动辄几十上百G参数的大模型根本跑不起来。所以我们的思路是“两条腿走路”。一方面我们利用ChatGPT、ChatGLM这类大语言模型强大的理解和生成能力去“阅读”海量的医疗文档从中抽丝剥茧构建出一个结构化的医疗知识图谱。这个图谱就像一张巨大的关系网把疾病、症状、药品、科室这些实体以及它们之间的关系都清晰地连接起来。另一方面我们把这个“固化”下来的知识图谱部署到内网环境中再结合一个轻量级的问答引擎。当用户提问时系统不是让大模型去“编”答案而是先去知识图谱里精准地检索出相关信息再组织成通顺的回答。这样一来既利用了前沿AI的能力又保证了答案的准确性、可控性还完美适配了内网、低资源的苛刻环境。这个项目本质上是在探索如何让“大力出奇迹”的大模型和“精准可靠”的传统知识工程在严肃的医疗领域实现优势互补。2. 核心思路拆解为什么是“大模型构建知识图谱问答”这个架构不是凭空想出来的而是针对医疗领域几个核心痛点“量身定制”的解决方案。理解了这个“为什么”你才能明白后续每一个技术选型背后的考量。2.1 直面医疗场景的三大核心约束首先我们必须承认医疗信息化环境的特殊性。第一是网络隔离。三甲医院的核心业务系统几乎百分之百运行在物理隔离的内网中这是安全红线。这意味着所有依赖公有云API如OpenAI的服务方案从起点就被否决了。第二是计算资源有限。医院的服务器资源通常优先保障HIS、PACS等核心生产系统留给这类创新应用的CPU和GPU资源非常拮据部署一个百亿参数的大模型进行实时推理几乎是天方夜谭。第三也是最重要的对准确性的极致要求。医疗容错率极低大语言模型众所周知的“幻觉”问题在闲聊场景可能无伤大雅但在医疗建议中就是致命缺陷。患者问“胸口疼怎么办”系统绝不能给出未经证实或模糊的用药建议。2.2 传统方法与纯大模型方案的局限性面对这些约束我们评估过几种方案。传统的基于规则或简单检索的问答系统虽然可控但泛化能力太差无法理解“我心窝子不舒服”和“胸骨后疼痛”其实是同一种症状描述开发和维护成本极高。而另一端如果纯粹部署一个开源的中等规模医疗大模型比如一些基于LLaMA微调的模型虽然理解能力强但在资源受限的内网中其响应速度和并发能力会成问题且同样无法根除“幻觉”需要极其复杂的后处理和校验流程。2.3 混合架构的优势与分工因此“大模型构建 知识图谱问答”的混合架构成为了一个优雅的折中。它将任务进行了清晰的切分构建阶段离线、可联网利用外部强大的大模型ChatGPT/ChatGLM在项目初期、允许联网的环境下执行知识抽取和图谱构建的繁重工作。大模型在这里扮演“超级实习生”的角色快速阅读文献、标注关系输出结构化的“草稿”。这个过程允许人工介入复查和修正确保图谱质量。服务阶段在线、内网将清洗、固化后的知识图谱Neo4j数据库和训练好的意图识别模型、词向量等整体打包部署到内网。在线服务时系统不调用任何大模型。用户提问后流程是意图识别 - 从问句中抽取关键实体 - 在图谱中查询关联路径 - 根据预定义的答案模板组装回答。整个过程轻量、快速、确定性强。这个架构的精妙之处在于它把大模型的“智能”沉淀为了知识图谱的“知识”把需要高资源的“训练/构建”过程与需要高稳定的“推理/服务”过程分离开完美匹配了医疗内网场景的需求。接下来我们就深入看看这个知识图谱到底是怎么被构建出来的。3. 医疗知识图谱的构建从非结构化文本到结构化网络知识图谱是本系统的基石它的质量直接决定了问答的准确性。我们的构建过程并非一蹴而就而是一个“机器自动抽取 - 人工校验 - 模型优化”的迭代过程。3.1 数据源的选择与处理我们主要整合了多源异构数据以确保知识的全面性和权威性39健康网等公众健康平台提供了丰富的疾病百科、症状描述、药品信息语言更贴近普通患者的查询习惯数据量大覆盖范围广。国家及各省卫健委公开文件包括诊疗指南、临床路径、质量控制指标等。这是权威性的核心来源确保了疾病的标准治疗方案、检查项目、所属科室等信息的准确性。医学教科书与学术文献用于补充和验证疾病的病理生理、并发症等深度知识。处理这些数据的第一步是清洗和标准化。比如从网页抓取的数据包含大量HTML标签和广告文本卫健委的PDF文件需要经过OCR和版面分析。我们使用Python的PyPDF2、pdfplumber库处理PDF用BeautifulSoup解析网页最终将所有资料转化为统一的纯文本格式为后续的信息抽取做好准备。注意数据清洗时要特别注意医学术语的归一化。例如“心肌梗塞”、“心肌梗死”、“MI”指代同一疾病必须在早期就建立同义词词典进行统一否则会在图谱中形成多个冗余实体严重影响查询效果。3.2 基于大模型的知识抽取实践这是整个构建流程中最关键、也最具创新性的一环。传统方法可能需要训练专门的命名实体识别和关系抽取模型成本高且泛化能力有限。我们则利用大语言模型强大的零样本/少样本学习能力。我们设计了一套结构化的提示词引导大模型进行“阅读理解”式的抽取。以下是一个模拟的提示词示例用于从一段疾病描述中抽取信息# 模拟的Prompt设计 prompt_template 你是一个资深的医疗信息抽取专家。请从下面的医学文本中严格按照JSON格式输出指定信息。 文本{medical_text} 请抽取以下信息 1. 疾病名称核心实体。 2. 该疾病的典型症状列表。 3. 该疾病的推荐治疗药物列表。 4. 该疾病所属的科室列表。 5. 该疾病可能引发的并发症列表。 输出要求 - 使用中文。 - 只输出JSON对象不要有任何额外解释。 - JSON格式如下{{ disease: 疾病名称, symptoms: [症状1, 症状2, ...], drugs: [药品1, 药品2, ...], departments: [科室1, 科室2, ...], complications: [并发症1, 并发症2, ...] }} 我们将清洗后的文本分批输入给大模型通过API调用ChatGPT或本地部署的ChatGLM获得初步的结构化数据。这个过程可以并行处理效率远高于人工标注。3.3 实体与关系的定义与存储根据大模型抽取的结果和医学逻辑我们定义了项目描述中的核心实体类型和关系类型并确定了它们的属性。实体类型就像是图谱中的“节点类型”疾病如糖尿病、高血压。是最核心的实体。症状如多饮、多尿、头晕。是疾病的表现。药品如二甲双胍、硝苯地平。用于治疗疾病。检查项目如血糖检测、血压测量。用于诊断。科室如内分泌科、心血管内科。是诊疗的责任部门。并发症如糖尿病肾病、高血压心脏病。是疾病可能引发的其他疾病。发病部位如胰腺、血管。是疾病发生的解剖学位置。关系类型则是连接这些节点的“边”定义了它们之间如何关联HAS_SYMPTOM疾病 - 症状 糖尿病 -[HAS_SYMPTOM]- 多饮HAS_DRUG疾病 - 药品 糖尿病 -[HAS_DRUG]- 二甲双胍BELONGS_TO_DEPARTMENT疾病 - 科室 糖尿病 -[BELONGS_TO_DEPARTMENT]- 内分泌科HAS_COMPLICATION疾病 - 并发症 糖尿病 -[HAS_COMPLICATION]- 糖尿病肾病REQUIRES_CHECK疾病 - 检查项目 糖尿病 -[REQUIRES_CHECK]- 血糖检测属性是附着在实体特别是疾病实体上的详细信息采用键值对存储治愈周期period: “终身控制”治愈率rate: “无法根治但可控”费用cost: “每月数百元”医保insurance: “是”我们选择Neo4j作为图谱数据库因为它原生支持图结构查询语言Cypher非常直观能高效处理“多跳查询”例如查询A疾病的所有并发症以及这些并发症的常用药。构建脚本build_graph.py的核心任务就是将清洗、对齐后的结构化数据通过Neo4j的Python驱动批量创建节点和关系。实操心得在向Neo4j批量导入数据时务必使用事务和批量提交。一次性提交几万条创建语句会导致内存溢出。我们的做法是每处理1000条实体或关系提交一次事务极大提升了构建过程的稳定性和速度。4. 离线问答系统核心引擎实现当知识图谱构建完毕并部署到内网后核心就是一个不依赖大模型的、轻量级的问答引擎。它的工作流程可以概括为“理解问题 - 查找知识 - 组织答案”。4.1 意图识别搞清楚用户想问什么用户的问题千变万化系统第一步是进行意图分类。我们采用了“关键词匹配 机器学习”的混合模型而非复杂的深度学习模型以追求速度和可解释性。特征词库构建我们根据医学领域特点为每种意图手工提炼了一批特征词。query_disease查询疾病【是什么病、什么是、诊断】query_symptom查询症状【症状、表现、有什么感觉】query_cureway查询治疗【怎么治、如何治疗、吃什么药、怎么办】query_department查询科室【挂什么科、看哪个科、去哪个科室】query_checklist查询检查【检查、查什么、做什么检测】disease_describe疾病详情【直接说疾病名如“糖尿病”】分类逻辑系统接收到用户问句后先进行分词然后与特征词库进行匹配。如果匹配到特定意图的特征词则直接归类。对于未匹配或模糊的情况我们使用一个简单的文本分类模型如用scikit-learn训练的SVM或朴素贝叶斯模型进行兜底。这个模型使用大量标注好的问句进行训练特征可以选用词袋模型或预训练词向量的浅层编码。# 简化的意图识别代码逻辑 def recognize_intent(question): # 1. 关键词快速匹配 if “怎么办” in question or “怎么治” in question: return “query_cureway” if “挂什么科” in question or “看哪个科” in question: return “query_department” # ... 其他关键词匹配 # 2. 若未匹配使用机器学习模型预测 # 这里需要对question进行特征提取如TF-IDF features vectorizer.transform([question]) intent classifier.predict(features)[0] return intent4.2 实体链接找到问题中的“主角”确定了意图接下来要找到问题中提到的具体实体主要是疾病名。这里最大的挑战是一词多义和别名问题。例如“打呼噜”是“睡眠呼吸暂停综合征”的俗称“心脏病”可能指代“冠心病”、“心肌炎”等多种具体疾病。我们的解决方案是结合预训练词向量和知识图谱中的别名库。分词与候选实体生成对问句分词取出所有名词性短语。将这些短语与知识图谱中所有疾病实体及其别名进行字面匹配生成候选实体列表。语义消歧如果候选实体多于一个则利用预训练的中文词向量如项目提到的Chinese Word Vectors。计算问句的整体语义向量通常取各词向量的平均然后计算该向量与每个候选疾病实体名称向量的余弦相似度选择相似度最高的作为最终链接实体。上下文辅助利用意图信息辅助消歧。例如当意图是query_department时如果候选实体有“高血压心血管内科”和“高血压肾病肾内科”系统可能会结合问句上下文如是否提到“腰酸”或直接选择最常见的那个。4.3 图查询与答案生成这是将意图和实体转化为最终答案的步骤。我们为每种意图预定义了对应的Cypher查询模板和答案模板。查询模板根据意图和链接到的实体组装出查询图谱的Cypher语句。答案模板一个带有占位符的文本模板用于将查询结果组织成通顺的回答。例如用户提问“糖尿病应该怎么治”意图识别query_cureway实体链接疾病糖尿病图查询执行Cypher查询MATCH (d:Disease{name:‘糖尿病’})-[:HAS_DRUG]-(dr:Drug) RETURN dr.name 返回[“二甲双胍” “胰岛素” ...]答案生成将结果填入答案模板“{disease}的治疗通常包括以下药物{drug_list}。此外还需要配合生活方式干预如{diet_advice}。具体方案请遵医嘱。”。其中diet_advice可能来自疾病节点的treatment属性。# 简化的答案组装逻辑 def answer_question(intent, entity, graph_data): templates { “query_cureway”: “{disease}的常用治疗方法包括{treatment}。主要用药有{drugs}。”, “query_department”: “{disease}通常需要去【{department}】就诊。”, “query_symptom”: “{disease}的常见症状有{symptoms}。”, “disease_describe”: “{disease} 主要症状{symptoms}。 常见治疗方式{treatment}。 所属科室{department}。 常用检查{checklist}。” } answer templates[intent].format( diseaseentity[‘name’], drugs‘、’.join(graph_data[‘drugs’]), symptoms‘、’.join(graph_data[‘symptoms’]), # ... 其他字段 ) return answer这套流程完全在本地运行无需网络仅依赖轻量级的模型意图分类模型、词向量文件和Neo4j数据库响应速度快答案精准可控彻底杜绝了“幻觉”。5. 大模型辅助图谱构建与优化的高级策略虽然基础流程已经能工作但要构建一个高质量、实用的医疗知识图谱还需要更精细的策略来处理大模型输出的不确定性和医学知识的复杂性。5.1 设计有效的Prompt工程直接让大模型“抽信息”效果并不稳定。我们通过迭代总结出医疗知识抽取Prompt的设计原则角色设定明确赋予大模型“资深医学专家”或“信息抽取专员”的角色提高其回答的权威性和规范性。结构化输出要求强制要求以JSON、XML或特定标记格式输出便于程序化解析减少后处理难度。分步指令对于复杂文本将任务分解。例如先指令“找出所有疾病名”再针对每个疾病名指令“抽取该疾病的症状和药品”。提供少样本示例在Prompt中提供1-2个格式正确的抽取示例Few-shot Learning能显著提升大模型输出的格式和内容一致性。不确定性处理在Prompt中要求模型对不确定的信息进行标注例如使用“可能”、“疑似”等标签或直接输出“未知”避免其强行编造。5.2 多模型协同与结果校验单一模型可能有偏见或错误。我们采用了两种协同策略投票机制将同一段文本同时发送给ChatGPTGPT-4和ChatGLM-4等不同模型进行抽取。对比它们的输出对于实体和关系采用“多数表决”原则对于存在冲突的结果标记出来供人工重点审核。知识图谱自校验利用已构建的部分图谱进行逻辑校验。例如新抽取出“疾病A -治疗- 药品B”但图谱中已有“药品B -用于- 疾病C”且疾病A和C在解剖部位上毫无关联如“脚气”和“胃药”这个关系就会被标记为高可疑度。5.3 人工复查流程的标准化人机结合是关键。我们设计了一个高效的复查平台高置信度自动入库对于多个模型一致、且通过基础逻辑校验的条目系统自动入库。中低置信度人工审核系统将存在冲突、模型不确定或置信度不高的条目以高亮对比的方式呈现给医学背景的审核人员。审核界面界面并列显示原文片段、不同模型的抽取结果、以及图谱现有相关知识的提示辅助审核人员快速决策。反馈闭环审核人员的修正决定会被记录并作为高质量样本用于后续对Prompt的优化甚至可以对一个小的校对模型进行微调形成持续改进的闭环。踩坑实录初期我们过于相信大模型的输出导致图谱中出现了“感冒 -可用药品- 手术刀”这样的荒谬关系。后来我们引入了“医疗知识三元组校验规则库”即一系列“IF-THEN”规则例如IF 关系是HAS_DRUG THEN 实体B的类型必须是Drug在入库前进行硬性过滤拦截了大部分明显错误。6. 系统部署、优化与效果评估将各个模块整合成一个稳定、可用的服务并持续优化其性能是项目落地的最后一步。6.1 内网环境下的技术栈部署整个系统被打包成一个Docker Compose集合方便在内网服务器上一键部署Neo4j以Docker容器运行承载知识图谱数据。Python后端基于Flask或FastAPI框架提供问答API。内部集成意图识别模型、词向量模块。前端界面一个简单的Vue或React页面用于输入问题和展示答案。Nginx作为反向代理处理请求路由。部署的关键在于资源的分配。由于内网服务器资源有限我们需要对Neo4j和Python服务进行内存限制。例如为Neo4j分配4GB堆内存为Python服务分配1GB内存。词向量文件如sgns.zhihu.char通常有几百MB到几GB我们采用内存映射的方式加载而不是全部读入RAM以节省宝贵的内存空间。6.2 性能优化技巧为了在有限资源下保证响应速度目标1秒我们做了以下优化Neo4j索引优化为所有实体的name属性创建索引这是实体链接查询中最频繁的操作。CREATE INDEX ON :Disease(name); CREATE INDEX ON :Symptom(name); CREATE INDEX ON :Drug(name);查询缓存对于高频、答案固定的查询例如“糖尿病是什么”在应用层使用Redis或内存字典进行缓存避免重复查询图谱。词向量加速实体链接时的语义相似度计算是性能瓶颈。我们将所有疾病实体名称的预计算向量存储在FAISSFacebook开源的相似性搜索库索引中可以实现百万级向量的毫秒级最近邻搜索。服务异步化将意图识别、实体链接、图谱查询等步骤设计成异步流水线充分利用I/O等待时间提高并发处理能力。6.3 效果评估与迭代方向如何衡量这个系统的成功我们设定了几个核心指标答案准确率随机抽取一批问题由医学专家判断答案是否正确。这是最重要的指标我们初期目标设定在95%以上。意图识别准确率评估系统是否能正确理解用户想问什么。响应时间P95响应时间控制在800毫秒内。覆盖率对于知识图谱内已知的疾病系统应能回答其核心属性症状、治疗等相关问题。根据上线后的用户反馈和数据监控我们规划了迭代方向问答能力扩展当前系统主要回答“是什么”的陈述性问题。下一步计划引入一个轻量级的开源小模型如ChatGLM-6B的INT4量化版在知识图谱检索结果的基础上进行答案的润色、总结或回答简单的推理问题如“为什么糖尿病会导致视力下降”但严格限制其仅能基于检索到的证据进行生成。图谱动态更新建立半自动化的图谱更新流程。当新的诊疗指南发布时能通过大模型辅助人工审核的方式快速将新知识融入图谱。多轮对话记录简单的对话上下文使得用户能进行追问如“这个药有什么副作用”提升交互体验。这个项目让我深刻体会到在严肃的工业场景中尤其是医疗这类高合规、高安全要求的领域技术的应用不在于追求最前沿的模型而在于构建一个可靠、可控、可解释的完整系统。将大模型的“广度”与知识图谱的“精度”结合用离线的、确定性的知识来约束在线服务是一条经过验证的、务实的技术路径。