支持私有云部署
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


AI误诊,上海患者获赔127万?聊聊模型幻觉与信任危机

发布日期:2025-03-25 12:00:45 浏览次数: 1551 来源:叶小钗
推荐语

AI在医疗领域应用的误区与挑战,引发信任危机。

核心内容:
1. AI误诊事件背后的真相探讨与制度缺失
2. 医生对AI的复杂态度及AI在医疗领域的应用现状
3. CDSS系统的发展与挑战,以及医疗知识图谱的重要性

杨芳贤
53A创始人/腾讯云(TVP)最具价值专家

今年很多医院已经部署上了DeepSeek,甚至有医生真的使用它对患者进行诊断,但马上就出问题了:AI 误诊,上海患者获赔 127 万

不过,我去搜索详情的时候,却找不到细节信息了,包括使用的什么模型(R1还是V3),什么尺寸的(满血还是残血版),如何使用的(直接网页使用,还是被提示词工程包装过的)。

在上述信息没有确定之前,这个标题事件是难以被论证的,并且现在其实应该有明确制度,首诊必须医生进行的,所以该127万事件是假的感觉概率更高。

只不过,据丁香医生近期研究情况,医生对AI很有些又爱又恨的感觉

又爱又恨的AI

从AI在医疗领域的应用来说,他覆盖了从病例辅助分析报告解读,甚至逐渐在往辅助诊断和提供治疗建议扩展,只不过各个医院/医生具体使用情况有所不同。

已知医生有大量“文书性作业”要做,比如病历书写。特别是医保目录相关的动作,一旦出现错误医院将面临不小的惩罚,而AI在整个这块的防范功能又很强大。

另一方面,在擅长科室的知识范围内,医生的表现是很好的,但如果跨科室了,这里的诊断变开始变得复杂,而AI在这个领域有天生的优势

只不过,不管是由于系统的易用性还是医疗知识的有效性,多数医生对直接使用AI依旧持迟疑态度。

这可能与医生诊断习惯有关,他们会默认为来到自己科室的患者就是得了相关的疾病,而这已经对疾病的范围做出了巨大的收敛,而他在80%+的场景都是对的,所以医生的诊断行为会来得很快。

偶尔甚至有一言而定诊断的神乎其技,只不过这在严格的临床路径来说是不被倡导的,AI在算法规则上也不会那样做,因为医疗是严肃领域。

这就造成了一个结果(出自丁香园):AI 更像是一本字典、引导医生们拓宽诊疗思路,但对于在临床一线有几十年诊疗经验积累的成熟医生来说,参考实在有限。

最后就很尴尬了:不用效率提不起来,用的话总有不爽的地方,于是对产品体验适应度的打磨,尤其是医疗有效性和适应性的提升变得迫在眉睫。

从某些角度讲,Deepseek目前在医疗中的角色更像是『高级版的百度』,如果患者甚至医生过度依赖它,很可能导致误诊的发生。

体验打磨是个互相磨合的过程,而医疗有效性的提升才是是否问题,重中之重

医疗知识图谱在医疗有效性这块,一直扮演着重要角色,了解知识图谱,可以了解整个AI医疗的一段生命周期,比如我们可以从CDSS聊起。

老医疗AI:CDSS

CDSS(Clinical Decision Support System):临床决策支持系统,是一种为辅助医疗专业人员做出临床决策的AI技术产品。

因为AI辅助诊断的需求一直存在,所以这些年一直有机构在做CDSS的尝试,比如IBM Watson就投入了大量资源,但最终却以失败告终,现在回过头来看看其价值和失败的原因,可能为后续的AI应用研发提供一些中肯的建议

CDSS的核心原理

CDSS的核心原理之一是基于规则的推理,这种方法依赖于大量由领域专家(医生)手工输入的规则和知识库。

每条规则通常以“如果...则...”的形式存在,系统通过这些规则对患者的症状、检查结果等信息进行分析,给出相应的建议。例如:

  1. 如果患者有发热、咳嗽和气促的症状,那么该患者可能感染了呼吸道疾病
  2. 如果患者的血糖水平持续超过某个阈值,可能需要调整糖尿病治疗方案;

以上的所有规则便形成了CDSS最核心的知识库,他是CDSS最重要的组件:存储着关于各种疾病、症状、治疗方法等的信息。

这些信息通常来自医学文献、临床经验以及专家的知识,通过不断更新知识库,CDSS可以适应最新的医学研究成果和临床实践。

最终CDSS利用知识库中的信息结合患者的临床数据,进行诊断和治疗推理。它可以根据患者的病史、体征、实验室检查结果等信息,自动生成诊断建议,并根据既有的治疗方案推荐治疗方法。

只不过这里有两个核心的问题也就暴露出来了:

第一,知识库不全

CDSS的效果依赖于知识库的完整性,而知识库的完整性依赖于专业人员的不断录入

且不论ICD11上的几万个疾病信息一次完整录入何其之高,一旦知识库中出现任何错误整个系统就会受到质疑,由此CDSS失败的罪魁祸首出现:

完整的知识库总是难以达成,包括知识的校准以及信息不断的更新,专业医生的时间成本极高。

第二,泛化能力不足

CDSS之所以是辅助系统,是因为其泛化能力不足,他无法从海量的患者语言中抽取出他需要的医学关键词,换句话说:真实世界的患者描述是很宽的,而CDSS的入口是很窄的,这导致了CDSS的适应性极差

比如患者的描述是:我感觉到胸口很沉,有时候呼吸急促,特别是晚上躺下时。

CDSS通常需要将这些信息转化为结构化的数据,如“胸痛”、“呼吸急促”等,才能对症下药。

“胸口很沉”这样的描述是非标准化的,且没有精确到医学术语,CDSS难以直接识别并匹配相关的疾病(如心脏病或呼吸系统问题)。

这里还产生了另一个问题,一旦CDSS的理解(关键词抽取)是错误的,那么整个诊断建议都是不可逆的错误。

这里虽然有些排除算法,但并不能从根本解决问题,因为没办法解决关键术语抽取能力的缺陷

下图应该能让大家直观的感受到泛化能力中宽窄的情况:

术语真实患者描述 (无法解析)潜在风险
头痛"太阳穴一跳一跳地疼"
"后脑勺像被锤子砸"
"一吹风就头胀"
"看电脑久了眼眶连着疼"
无法区分偏头痛/紧张性头痛/青光眼
胸痛"心脏位置像针扎"
"左胸有东西压着喘不过气"
"胸口火辣辣地烧"
"深呼吸肋骨下刺痛"
可能混淆心绞痛/胃食管反流/肋间神经痛
呼吸困难"喉咙被掐住的感觉"
"吸气吸不到底"
"睡觉躺不平会憋醒"
"走两步就要大喘气"
无法区分哮喘/心衰/COPD/焦虑症
铁摄入过量"最近补铁片后大便发黑"
"每天吃半斤菠菜+猪肝"
"孕期补铁后恶心加重"
可能忽略铁剂中毒风险

无非跨越这个泛化鸿沟问题,所以CDSS只能是辅助系统,由医生输入真实的症状信息。

但这里也导致了一个问题:好的医生不需要CDSS,水平不行的医生本身也抽取不准,一时之间,CDSS竟有鸡肋之感受!

所以,结论就是:CDSS没用咯?这可能也不至于,特别是大模型的AI时代。

CDSS的本质是医学知识库,更进一步可以衍生出一套医学知识图谱,这套图谱在之前由于泛化能力不足所以不好用,但在大模型时代技术鸿沟的问题被弥合了,所以知识图谱也就开始焕发新生了。

知识图谱

知识图谱和知识库非常相似,可以说知识图谱是知识库的一种有机表现形式。在逻辑上,知识库通过关系链的建立能够形成图谱结构。

具体来说,知识库是对各种知识的组织、存储和管理,而知识图谱则是在此基础上通过图的结构(实体、关系和属性)来呈现知识的内在联系和结构。

知识图谱通常包括三大元素:

  1. 实体(Entities):即图中的节点,代表真实世界中的事物、概念等(如人、地点、物品、概念、类别)。
  2. 关系(Relations):实体之间的连接或联系,描述实体之间的互动。
  3. 属性(Attributes):描述实体或关系的特征信息,如一个实体的具体属性值。

通过这种标准化的表示形式,知识图谱不仅能够展示实体之间的关联,还能够进行语义分析,帮助计算机理解和推理这些关系。

它为我们提供了一种更加直观、结构化的方式来管理和呈现知识库中的信息。

更粗暴的理解可以是:图谱就是强制将知识库按照实体、关系、属性的标准做结构化,两者间界限很模糊

为方便理解给一个案例,首先是没有关系的知识库

疾病: {
  名称: "糖尿病",
  类型: "慢性疾病",
  并发症: ["心血管疾病""肾脏病""神经损伤"]
}

症状: [
  { 名称: "口渴", 常见疾病: "糖尿病" },
  { 名称: "频繁排尿", 常见疾病: "糖尿病" },
  { 名称: "体重下降", 常见疾病: "糖尿病" },
  { 名称: "疲劳", 常见疾病: "糖尿病" }
]

药物: {
  名称: "胰岛素",
  类型: "药物",
  用途: "控制血糖",
  使用方法: "注射"
}

然后是有关系的知识图谱:

实体: [
  疾病("糖尿病"): {
    类型: "慢性疾病"
  },
  并发症("心血管疾病"): {},
  并发症("肾脏病"): {},
  并发症("神经损伤"): {},
  症状("口渴"): {
    常见疾病: "糖尿病"
  },
  症状("频繁排尿"): {
    常见疾病: "糖尿病"
  },
  症状("体重下降"): {
    常见疾病: "糖尿病"
  },
  症状("疲劳"): {
    常见疾病: "糖尿病"
  },
  药物("胰岛素"): {
    类型: "药物",
    用途: "控制血糖",
    使用方法: "注射"
  }
]

关系: [
  (疾病("糖尿病") - 表现为 -> 症状("口渴")),
  (疾病("糖尿病") - 表现为 -> 症状("频繁排尿")),
  (疾病("糖尿病") - 表现为 -> 症状("体重下降")),
  (疾病("糖尿病") - 表现为 -> 症状("疲劳")),
  (疾病("糖尿病") - 引发 -> 并发症("心血管疾病")),
  (疾病("糖尿病") - 引发 -> 并发症("肾脏病")),
  (疾病("糖尿病") - 引发 -> 并发症("神经损伤")),
  (疾病("糖尿病") - 治疗 -> 药物("胰岛素"))
]

PS:上述只是为了便于各位理解图谱是什么,真实的情况会更复杂,但大体是这么个意思

比如常见的贝叶斯预测:P(糖尿病|多饮+多尿) = P(多饮|糖尿病) x P(多尿|糖尿病) x P(糖尿病) / P(多饮+多尿)

在大模型时代,当前模型对于根据症状推导常见疾病已经非常擅长,但是依旧会由于幻觉有各种问题,于是出现类RAG技术,比如:

输入:咳嗽 + 呼吸急促 + 发热 + 胸痛
图谱推理路径:
症状 → 咳嗽、呼吸急促、发热、胸痛
症状 → [常见疾病类别] → 呼吸系统疾病
可能的疾病:肺炎、支气管炎、慢性阻塞性肺疾病(COPD)
进一步筛查 → [检查指标] → 血氧饱和度、白细胞计数、胸部影像
如果胸部影像显示肺部浸润阴影,高度怀疑肺炎或肺结核
影像学特征差异 → [不同疾病影像学差异] → 肺炎(浸润阴影) vs 肺结核(钙化灶)
若影像学表现为浸润阴影,进一步考虑细菌性肺炎
最终诊断 → [关联知识库] → 确定细菌性肺炎可能性
若有相关临床史(如吸烟史、基础疾病),可能进一步确定为慢性阻塞性肺疾病合并肺炎。

综上,大模型其实就是我们所谓的快思考而知识图谱(知识库)就是我们所谓的慢思考了,在快慢结合下,医疗AI的答案将更为靠谱。

图谱 VS 知识库

从存储方式来说图谱区别于知识库的差异在于图结构 VS 表结构,其实更深一步来说,其差异是认知的差异,或者说点状或网状。

传统的知识库以表分类知识:传统知识库如同中药房的百子柜,每个抽屉(数据库表)存放着严格分类的知识:

  1. 疾病表:ICD-11编码、标准名称、所属科室;
  2. 药品表:化学名、适应症、禁忌证;
  3. 症状表:标准化描述、关联器官;

这种结构的致命缺陷在2020年新冠疫情中暴露无遗:当患者同时出现发热、腹泻、味觉丧失时,系统无法自主发现这些跨科室症状的新型关联模式。

其实这里疾病和症状表之间可以通过多重关系表(如症状与疾病的“表现为”关系)建立更多动态的联接,这能更好地发现症状之间的组合关联模式。

但即便如此,这种关系依然是预先定义好的。这里的意思是:知识库 + 关系表在已知关系的场景中可以满足大部分需求,尤其是在数据结构比较明确且稳定的情况下。

而知识图谱的核心优势是开放系统的可扩展性,以及它能够应对更加动态、复杂和未知的情况。这里举个例子:

二甲双胍的案例

二甲双胍是治疗2型糖尿病的一线药物,但临床观察和部分研究显示:

  1. 患者长期服用后体重可能下降;
  2. 可能通过抑制肝糖异生、改善胰岛素敏感性间接影响脂肪代谢;
  3. 在非糖尿病人群中也可能产生代谢调节作用;

这类跨领域、非直接的关联关系在传统医学知识库中往往缺失,但知识图谱可以低成本扩展。

假设某医学数据库的结构如下:

药物表(ID, 名称, 适应症, 副作用...)
疾病表(ID, 名称, 治疗方法...)

当需要添加"二甲双胍→减肥"关系时:

  1. 需要修改数据库模式(新增字段或关联表);
  2. 需临床指南明确认可该用途才能入库;
  3. 无法表达间接作用机制(如通过AMPK通路影响代谢);

但以上问题在知识图谱规则中就比较简单了:

(二甲双胍, 治疗疾病, 2型糖尿病)
(二甲双胍, 可能影响, 体重)
(二甲双胍, 作用机制, AMPK通路激活)
(AMPK通路激活, 调节过程, 脂肪分解)
(体重减轻, 证据等级, IIb级临床证据)

二甲双胍 → 激活AMPK → 促进脂肪分解 → 导致体重下降

当新研究发现时,只需添加三元组:

(二甲双胍, 抑制, mTOR信号通路)
(mTOR信号通路抑制, 关联, 寿命延长)

以上算是产品视角层面图谱与知识库的核心差异。

生成手段

传统知识库通常由权威专家(至少会有专家校验)手工录入数据,所有信息都经过严格审核,确保每条记录都能追溯到权威文献或临床指南。

这种方式使得数据具有高度的准确性和权威性,便于医生查证数据的来源,提高医疗决策时的信心。

知识图谱的话除了从结构化的数据(比如知识图谱)生成外,还会从非结构化数据(比如文章、文献、网页甚至影像等)提取关系和实体。

意思是他可以通过一套程序自动生成,比如之前我们研究的阿里KAG框架,可以直接提取我文章形成图谱:

第一节:经理的能力模型

PS:实际提取的还不太好...

医疗置信度

在当前医疗大模型产品中,溯源(可追溯性)和医疗置信度是至关重要的,因为它们直接关系到诊断决策的安全性和可靠性。

指能够追踪每一条信息的来源,从原始文献、临床指南、专家共识到数据采集的具体过程。

溯源性越高,医生越能确信系统给出的结论有明确的依据,从而在临床决策中更有信心使用这些数据。

只要医疗信息可溯源,加之算法清晰合理,其医疗置信度自然就高了。

综上,图谱与知识库各有优劣但大家也不必纠结,一起使用就好,其实可以看出,图谱会更适应于大模型时代的搜索使用

至此进入今天的正题:知识图谱+大模型提升解决医疗幻觉问题

图谱+LLM

如上所述,AI1.0时代的CDSS根本无法满足医生的基本使用,而大模型时代的DeepSeek依旧在模型幻觉等问题上让医疗人员犹豫不决,比如以下案例:

输入:
65岁男性,持续胸痛伴随呼吸困难,症状加重,10分钟内没有缓解,既往有高血压和糖尿病病史,急诊就诊。

错误诊断:急性支气管炎
依据:胸痛和呼吸困难可能由气道感染引起,尤其是在有慢性呼吸道症状的患者中。
实际病因:急性心肌梗死
风险后果:延误紧急冠脉介入治疗,可能导致心脏骤停或大面积心肌坏死。

在急诊分诊、手术抢救等情境下,错误的诊断不仅会延误治疗,还可能使患者失去最佳抢救时机,极大地危及生命。

因此,降低大模型幻觉风险、提高生成答案的可信度成为关键任务。

而知识图谱结合大模型的使用会是解决模型幻觉乃至增强医疗置信度的有效手段

PS:这类应用其实有很多,比如前面所述的KAG乃至GraphRAG(由微软研究院开发的一种新型检索增强生成框架,它旨在利用知识图谱和大型语言模型来提升信息处理和问答能力)。

医疗置信度的四个维度

为了保证诊断建议的准确性和临床安全性,我们需要考虑四个维度:

  1. 数据溯源。每条诊断结论都应能追溯到权威指南、临床文献和历史病历数据。只有明确溯源,医生才能信任系统的判断。
  2. 多模态一致性。综合患者的主诉、检查数据、影像资料等多方面信息,确保不同数据源之间推理结果的一致性。多模态一致性有助于消除单一数据带来的偏差。
  3. 动态规则适配。系统必须能够实时更新,根据最新的医学研究和临床指南动态调整诊疗路径。动态适配确保了诊断建议始终反映最新临床证据。
  4. 可解释推理链。生成的答案应附带详细的推理链和证据来源,让医生了解每一步判断的依据,从而对系统的决策过程有充分信任。

医学知识结构化范式

医疗知识图谱可以形成一张庞大的知识网络。例如,对于2型糖尿病:

{
  "实体""2型糖尿病",
  "属性": {
    "诊断标准": ["空腹血糖≥7mmol/L""HbA1c≥6.5%"],
    "治疗路径": ["一线用药: 二甲双胍""二线加用: SGLT2抑制剂"]
  },
  "关系": [
    {"source""糖尿病""target""视网膜病变""type""并发症"},
    {"source""二甲双胍""target""维生素B12缺乏""type""副作用"}
  ]
}

通过这种结构化方式,系统可以明确展示各医学实体之间的因果和关联关系,形成完整的知识链条。

这样,在实际诊断过程中,知识图谱不仅能提供丰富的背景知识,还能对大模型的生成过程进行实时约束和验证,从而大幅降低幻觉风险。

并且,图谱的更新速度可以很快,一般3天就能做一次更新,以进一步保障医疗的及时性。

图谱+RAG

在实际应用中,将知识图谱与RAG技术结合,可以构建一个多层次的智能诊断体系。

该系统通过智能路由、查询规划和多模态整合,形成了一个自上而下的三层防御体系,确保生成答案具有高医疗置信度和充分可解释性:

A[用户输入] --> B{简单查询?}
B -->|是| C[RAG基础层]
B -->|否| D[图谱推理层]
C --> E[置信度验证]
D --> E
E -->|≥90%| F[直接输出]
E -->|<90%| G[专家复核]

subgraph 知识中枢
    H[症状库] --> I[疾病-症状矩阵]
    J[检查库] --> K[诊断决策树]
    L[治疗库] --> M[指南规则引擎]
end

D -->|实时调用| H
D -->|动态关联| J

在此架构中,系统首先对输入问题进行初步判断:对于简单、标准的查询直接由RAG基础层处理;

而对于复杂、多模态或涉及实体关系的问题,则交由图谱推理层进一步分析。

无论哪种路径,最终结果都经过置信度验证,当系统置信度超过预设阈值(如90%)时直接输出,否则提交专家复核。

以下是通过知识图谱实现对复杂问题的结构化推理案例:

步骤1: 症状解析 → 解析腹痛位置(上腹)、放射特征(向背部);  
步骤2: 图谱触发 → 根据症状匹配胰腺炎和胆囊炎的鉴别路径;  
步骤3: 检查建议 → 推荐淀粉酶检测(强制项)和腹部CT;  
步骤4: 动态排除 → 根据Murphy征结果,若阴性则排除胆囊炎;  
步骤5: 治疗规划 → 根据体重计算液体复苏方案及禁食时间;

为了更直观展示知识图谱+LLM对提高医疗置信度的效果,下面通过三个层次的案例进行对比分析,以下是基本输入:

{
  "主诉""突发撕裂样胸痛放射至背部,伴呼吸困难",
  "病史""高血压10年",
  "生命体征""血压180/110mmHg,双侧脉搏不对称",
  "实验室检查""D-二聚体 5.2mg/L",
  "心电图""无ST段抬高"
}

一、大模型(无RAG技术)

# 原始输入直接传递
prompt = f"""患者信息:{input_data}  
请给出诊断建议:"
""

{
  "诊断""高血压危象(置信度88%)",
  "建议": ["硝苯地平舌下含服""监测血压"],
  "遗漏风险": ["未识别主动脉夹层特征""忽视D-二聚体异常"]
}

二、大模型+RAG

# 向量检索结果
retrieved_context = [
  "文献1:D-二聚体>0.5mg/L需考虑血栓性疾病(NEJM 2023)",
  "文献2:双侧脉搏不对称提示主动脉病变(Circulation 2022)"
]

# 提示词组装
prompt = f"""临床数据:{input_data}  
相关医学证据:{retrieved_context}  
请结合证据生成诊断:"
""

# 模型输出
{
  "诊断": ["肺栓塞(概率45%)""主动脉夹层(概率38%)"],
  "建议": ["CT肺动脉造影""静脉肝素治疗"],
  "冲突项""肝素可能加重主动脉夹层出血"
}

这里的输出其实已经不错了,只不过组装的信息缺少逻辑性。

二、大模型+图谱+RAG

# 最终提示词
prompt = f"""【严格遵循临床推理规则】
患者数据:{input_data}  
图谱诊断路径:主动脉夹层(Stanford A型)  
必要检查:急诊主动脉CTA(依据:2023 ESC指南第8.2章)  
药物禁忌:β受体阻滞剂优先于硝普钠(心率>60次/分)  
请生成结构化诊断报告:"
""

# 模型输出
{
  "诊断""急性主动脉夹层(DeBakey I型)",
  "置信度": 97.3%,
  "核心证据链": [
    "高血压病史→血管内皮损伤风险↑",
    "撕裂痛+脉搏不对称→夹层特异性征象",
    "D-二聚体>5mg/L排除心梗(敏感性92%)"
  ],
  "处置方案": [
    "立即控制血压:艾司洛尔静脉泵入",
    "15分钟内完成主动脉CTA",
    "心血管外科急会诊"
  ],
  "绝对禁忌": [
    "禁用抗凝/抗血小板药物",
    "避免剧烈搬动患者"
  ]
}

这种在输出前结合CoT的功能,再集合溯源的功能,医生还不被“迷得死死的”...

结语

医疗AI的发展已迈入有效性驱动的新纪元,模型参数量级不再是唯一标尺,生成内容的临床可信度才是生死线

从CDSS的黯然退场到DeepSeek的争议,本质是技术路线对“有效性”的认知迭代:

  1. 1.0时代追求知识覆盖的完备性,最终困于人力构建知识库的局限性;
  2. 2.0时代沉迷参数规模的暴力美学,却因模型幻觉遭遇临床信任危机;
  3. 3.0时代正在开辟知识约束下的可控AI新范式:通过知识图谱定义医学逻辑的“轨道”,借助RAG技术注入循证医学的“刹车”,让大模型既保持“涌现”能力,又不偏离临床安全的边界。

只有当医生能清晰追溯每一条诊断建议的证据链(如指南依据、相似病例、影像特征),并实时验证其与患者个体特征的适配性(如基因类型、共病状态、用药史),AI才能真正从“高级版百度”进化为“超级临床助理”

有效性革命的核心命题,不仅是技术问题,更是对医疗本质的回归:用确定性对抗不确定性,以可解释性赢得信任,最终在效率与安全的平衡中重塑诊疗范式

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询