当 AI 面对真实病历🏥：EHRBench 如何用近百万临床问题撕开 LLM 医疗能力的假象

论文元数据

🩺 1. 教科书上的满分考生，在真实病房里可能不及格

想象一位医学生，她在医学资格考试中拿了满分——诊断、治疗、预后，每个知识点都倒背如流。但当她第一次走进急诊室，面对一份没有主诉、没有鉴别诊断、没有现病史的原始电子病历，她愣住了。病历上只有一串串 ICD 编码、药物处方记录、实验室检查时间戳，以及无数看似无关的并发诊断。她需要从这些碎片化的结构化数据中，推断出患者当前最可能的诊断、下一步该用什么药、以及两周后可能出现什么并发症。

这不是虚构的场景。每年，数以万计的住院医师在培训初期经历类似的冲击。他们在医学院学会了从教科书案例中推理——案例被精心编辑，包含所有必要信息、排除所有干扰因素、遵循标准的鉴别诊断框架。但真实病历从不如此配合。真实病历是混乱的：患者同时患有七种慢性病，服用十二种药物，上周刚做完两项手术，而主治医生的诊断记录中可能遗漏了最关键的并发症。从这种 chaos 中提取临床意义，是人类医生花费数十年磨练的能力，也是当前 AI 系统最薄弱的环节。

这不是医学院的考题。这是真实临床工作的日常。而当前绝大多数评估 LLM 医疗能力的基准，都在让模型做第一类任务（标准答案明确的考试题），却鲜有基准测试模型做第二类任务（从真实病历中推断隐含临床逻辑）。

埃默里大学与斯坦福大学团队提出的 EHRBench，正是为了填补这个 gap。它从 MIMIC-III、MIMIC-IV 和 Emory Healthcare 的私有 EHR 数据库中提取真实患者轨迹，构建了近一百万（960,067）个临床决策 QA 项，覆盖诊断、治疗和预后三大核心任务，并系统评估了 31 个以上代表性 LLM。结果揭示了一个令人警醒的事实：许多在医学考试中表现优异的模型，在面对真实病历的推理任务时，能力并没有想象中可靠。

📋 2. 为什么现有医学基准测不出真实临床能力

现有医学 QA 基准大致可分为两类，而两者都存在根本性局限。

第一类：教科书与考试型基准（MedQA、MedMCQA、MedXpertQA 等）。这些数据源来自医学考试、教科书和临床指南，其特点是临床推理被显式陈述——题目直接给出症状、体征和鉴别诊断的框架，模型只需从选项中选择最匹配的答案。这类基准测试的是医学知识的记忆与匹配，而非临床推断的能力。真实临床工作中，医生面对的往往不是"以下哪项最符合该患者的诊断"这种结构良好的问题，而是需要在嘈杂、不完整、有时甚至矛盾的 EHR 数据中自行构建推理链条。

第二类：检索型 EHR 基准（EHRSQL、emrQA 等）。这些数据源确实来自真实 EHR，但任务设计偏向信息检索——"患者在该次就诊中接受了什么治疗？"答案可以直接从数据库中查找到。这类任务不需要临床推理，只需要准确的文本到 SQL 的解析能力。它们测试的是模型读取病历的能力，而非理解病历的能力。

EHRBench 的定位介于两者之间、又超越两者：它要求模型从纵向结构化 EHR 轨迹中进行条件推断——给定部分观察到的临床事件，预测缺失的诊断、选择合适的治疗、或预见下一次就诊的可能 outcome。这些任务需要的不是记忆教科书知识，也不是检索数据库条目，而是从隐含在时序事件中的临床逻辑进行推断。

🔧 3. EHR-LLM-KB 交互管道：自动化但不失控

构建近百万规模的临床基准，纯手工标注显然不现实。但完全由 LLM 自动生成又面临幻觉风险——模型可能捏造不存在的临床关系、生成模糊的多选题选项、或在答案中引入概念混淆。EHRBench 的解决方案是一个三阶段交互管道：EHR 数据提供真实基础，LLM 提供规模化生成能力，外部生物医学知识库（KB）提供验证与富化。这个设计的核心洞察是：规模化与可靠性不是零和博弈。传统的观点假设，自动化必然牺牲质量，手工标注必然限制规模。EHRBench 的管道通过"LLM 生成 + KB 验证"的互补分工，打破了这一假定的权衡——LLM 负责从 EHR 中提取和解释临床关系（需要语言理解和医学知识的灵活组合），KB 负责验证这些关系的临床有效性（需要基于文献和标准化术语库的确定性检查）。两者结合，既保留了自动化的规模优势，又守住了临床可靠性底线。

3.1 关系提取：从结构化事件到临床逻辑

管道的第一步，是从预处理后的 EHR 轨迹中提取临床关系三元组（主体实体，关系谓词，客体实体）。例如，从一次就诊记录中，专门微调的医学 LLM（HuatuoGPT-o1-8B）可能被引导提取出：

• （高血糖，用...治疗，胰岛素）
• （2型糖尿病，导致，糖尿病肾病）
• （心房颤动，需要，抗凝治疗）

这些关系不是显式写在 EHR 中的——EHR 中只有"处方：胰岛素"和"诊断：高血糖"两个独立事件，临床逻辑需要被推断。LLM 的作用正是充当这个"推断者"，从结构化事件的并置中识别出隐含的临床关联。

3.2 知识库验证：三道防线过滤幻觉

提取出的关系进入验证阶段。EHRBench 整合了 UMLS、SemMedDB、DrugBank、PubMed 和 ICD 五个生物医学知识源，形成复合 KB。每个候选关系必须通过三道检查：

正向支持：SemMedDB 中必须存在支持该关系的文献证据。例如，（高血糖，用...治疗，胰岛素）必须在 SemMedDB 中有对应的"Treat-with"关系记录。

无负向证据：SemMedDB 中不能存在 contradict 该关系的记录。例如，若 SemMedDB 中有（胰岛素，负向导致，高血糖），则该关系被驳回——这虽然罕见，但对防止危险的临床错误至关重要。

无背景冲突：辅助上下文事件中不能存在与答案实体形成冲突关系的证据。例如，若患者的辅助诊断中包含"1型糖尿病"，而问题询问的是"2型糖尿病的治疗"，则需要确保选项不会被上下文中的其他诊断误导。

通过这三道防线的关系，才被保留进入下游的 QA 生成。这种"LLM 生成 + KB 验证"的设计，在规模化的同时守住了临床可靠性底线。

KB 验证的另一个重要功能是概念标准化。EHR 中的事件描述来自不同的编码系统（ICD-9、ICD-10、DrugBank 内部编码等），同一概念可能有数十种不同的文本表达。通过 UMLS 的概念唯一标识符（CUI）映射，EHRBench 将异源的描述统一到标准化概念框架下。这不仅消除了编码系统之间的语义壁垒，还使不同数据源（MIMIC-III、MIMIC-IV、PROMOTE）的患者记录可以在同一语义空间中进行比较和整合。

3.3 QA 生成：从模板到多样化的考题

每个验证通过的模板被实例化为多种 QA 形式：4/5/6 选项的多选题（每种有多个改写版本），以及开放式问答题。一个模板最多可生成 16 个不同的 QA 项，通过问题改写和选项排列增加多样性。

多选题的设计遵循严格的临床推理结构：

• 场景（Scenario）：将患者的部分临床事件自然语言化，作为推理背景
• 问题（Question）：根据任务类型询问缺失的诊断、治疗或预后
• 选项（Choices）：1 个正确答案 + 3-5 个干扰项
• 解释（Rationale）：整合 EHR 模式、LLM 知识和 KB 证据的解释

干扰项的生成尤其讲究。它们不是随机选取的医学术语，而是经过 KB 验证的"似是而非"选项——与问题情境存在某种临床关联，但并非最佳答案。例如，对于"高血糖的治疗"，干扰项可能包括"硫酸镁"和"呋塞米"——两者都是临床常用药物，但并非高血糖的首选治疗。这种设计使简单的关键词匹配策略失效，迫使模型进行真正的临床推理。

🎯 4. 三大临床决策任务：诊断、治疗与预后

EHRBench 的核心是三个需要实质性生物医学知识和临床推断的任务，每个任务对应不同的条件推断目标。

4.1 诊断决策：从并发诊断中补全拼图

给定一次就诊中的部分诊断集合，模型需要推断缺失的并发诊断。例如，患者就诊记录显示"2型糖尿病"和"糖尿病肾病"，模型需要推断出同时存在的"慢性肾病"。

这个任务测试的是模型对疾病共现模式的理解。某些诊断在统计学上频繁共现，因为它们共享病理生理机制（如糖尿病与肾病），或一个是另一个的并发症（如高血压与中风）。模型需要识别这些模式，而非仅仅记忆孤立疾病的定义。

诊断任务的复杂性还在于部分观察的挑战。EHRBench 不会把所有诊断都展示给模型——它会故意 withhold 一个目标诊断，只提供部分并发诊断作为线索。模型需要像临床侦探一样，从有限的线索中推断出"还缺了什么"。例如，给定"2型糖尿病"和"糖尿病肾病"，模型需要推断出"慢性肾病"——这不仅要求知道糖尿病与肾病的关系，还需要理解糖尿病肾病本身就是慢性肾病的一种表现形式。这种从部分信息补全整体的推理，远非简单的知识检索所能覆盖。

4.2 治疗决策：从诊断到处方的映射

给定一次就诊中的诊断集合，模型需要选择** appropriate 的治疗方案**。例如，患者诊断为"心房颤动"，模型需要选择"抗凝治疗"而非"胰岛素"。

这个任务测试的是模型对治疗指征的理解。同样的症状可能有不同的治疗方案，取决于病因、并发症和患者整体状况。模型需要综合考虑诊断信息，而非简单地做"症状→药物"的单向映射。

治疗选择的复杂性在于多目标权衡。一个患者可能同时患有心房颤动和胃溃疡——前者需要抗凝治疗以预防中风，后者则使抗凝治疗增加消化道出血风险。最佳治疗决策不是简单地列出所有适用药物，而是在相互冲突的治疗目标之间寻找平衡。EHRBench 的治疗任务虽然没有显式地引入这种极端冲突场景，但模型在选择治疗方案时，仍然需要隐式地考虑患者的整体诊断背景，避免推荐与并发疾病相冲突的药物。

4.3 预后决策：从当前就诊预见未来

给定当前就诊的诊断和治疗信息，模型需要预测下一次就诊的可能诊断。例如，患者当前有"高血压"和"高脂血症"，模型需要预见下一次就诊可能出现的"缺血性中风"。

这个任务测试的是模型对疾病进展和治疗效应的纵向理解。它要求模型不仅知道"高血压导致中风"这一静态知识，还需要理解"未经控制的高血压在多长时间窗口内增加中风风险"这一动态知识。这种时间维度的推理，是传统医学考试基准几乎不涉及的。

📊 5. 31 个 LLM 的临床大考：医学专用模型并未显著领先

EHRBench 评估了 31 个以上代表性 LLM，分为三类：开源通用 LLM（Llama、Qwen、GLM 等）、医学专用 LLM（Doctor-R1、Med42、UltraMedical 等）、以及 API 商业模型（GPT-4.1 系列、GPT-5 系列）。

5.1 整体表现：无人突破 70%

从已披露的部分结果看，表现最佳的模型在整体准确率上也未突破 70%。GLM-4-32B 以约 66% 的整体准确率位列前茅，Llama-3-70B 约为 63%，而更小规模的模型（如 Llama-3-8B 的 49%）与顶级模型之间存在显著差距。

这个结果的含义需要仔细解读。EHRBench 不是医学执照考试——在考试中，60% 可能意味着不及格；但在 EHRBench 中，60% 代表的是从真实病历中推断隐含临床逻辑的能力，这是一种远比考试答题复杂的认知任务。事实上，人类医生在面对不熟悉的病历系统和不完整数据时，也未必能达到 90% 以上的准确率。

5.2 医学专用模型的意外平庸

一个引人深思的发现是：医学专用 LLM 并未显著优于通用 LLM。Doctor-R1、Med42、UltraMedical 等经过医学语料预训练的模型，在 EHRBench 上的表现与规模相当的通用模型基本持平，甚至在某些任务上略逊一筹。

这一发现挑战了"医学预训练必然带来临床推理优势"的直觉。可能的原因是：现有医学预训练主要基于教科书、论文和临床笔记等叙事文本，而 EHRBench 的任务需要从结构化编码数据中推断临床逻辑——这是两种截然不同的能力。医学预训练增强了模型对医学术语和概念的理解，但未必增强了模型从 ICD 编码和处方记录中重建临床推理链的能力。

5.3 任务差异：预后最难，治疗最易

从部分结果推断，三个任务的难度存在明显梯度。治疗选择的准确率通常最高（部分模型超过 75%），可能因为诊断到治疗的映射在医学知识中有较明确的指南支撑。诊断补全次之（约 55-70%），因为并发诊断的推断需要更灵活的模式识别。预后预测最具挑战性（约 45-60%），因为它不仅要求理解疾病机制，还需要把握时间动态和治疗效应的延迟。

这种任务差异对临床应用的启示是：当前 LLM 更适合作为治疗方案的参考工具（有较明确的指南支持），而非疾病进展的预测工具（涉及复杂的时间动态和个体差异）。

这个启示对于医疗 AI 的产品设计具有直接指导意义。如果一家医院计划部署 LLM 辅助临床决策系统，EHRBench 的结果建议：优先在药物治疗推荐场景中试点（模型表现相对较好，有明确的指南依据，风险相对可控），谨慎在疾病预测场景中依赖模型输出（模型表现最弱，涉及复杂的时间动态，错误预测可能导致过度治疗或治疗延误）。这种基于实证证据的场景选择，比"一刀切"地推广或拒绝医疗 AI 更为务实。

🔬 6. 可靠性的深层检验：数据泄漏与鲁棒性

EHRBench 的设计中包含多项对可靠性的主动检验，这些检验揭示了当前 LLM 评估中常被忽视的问题。

6.1 私有数据作为泄漏防火墙

除了公开的 MIMIC-III 和 MIMIC-IV，EHRBench 还纳入了 Emory Healthcare 的私有 EHR 数据集 PROMOTE。由于 PROMOTE 数据从未公开，任何 LLM 都不可能在其预训练语料中见过这些患者记录。如果模型在 PROMOTE 上的表现与在 MIMIC 上显著不同，就可能暗示其在 MIMIC 上的高分部分源于数据泄漏（如模型在预训练中见过 MIMIC 的病历文本）。

从实验结果的一致性来看，模型在三个数据源上的表现趋势大致相似，这在一定程度上缓解了数据泄漏的顾虑。但细微的差异仍然存在——某些模型在 MIMIC-IV 上的表现略优于 MIMIC-III，可能与 MIMIC-IV 较新的数据被更多模型在预训练中接触过有关。

6.2 选项数量作为推理鲁棒性探针

EHRBench 通过 4/5/6 选项的多选题测试模型的推理鲁棒性。一个仅依赖排除法的模型，在面对更多选项时表现不应显著下降；而一个真正进行临床推理的模型，面对更多干扰项时表现可能适度下降，因为更多干扰项增加了推理的复杂度。

实验结果显示，大多数模型随着选项数量增加而准确率下降，但下降幅度因模型而异。这一模式支持了"模型在进行某种形式的推理而非简单排除"的解释——若模型只是随机猜测，选项数量不应影响其表现。

6.3 开放式问答的诚实性测试

除了多选题，EHRBench 还包含开放式问答（OEQ），要求模型自由回答并给出解释。这不仅测试模型的知识广度，还测试其认知诚实性——模型是否会承认不确定性，是否会区分"我知道"和"我推测"。

初步分析显示，部分模型在开放式问答中存在过度自信问题：即使面对信息不充分的场景，也会给出确定性的诊断，而非指出需要进一步检查。这种过度自信在真实临床环境中尤其危险，因为它可能导致医生被误导而忽略必要的鉴别诊断。

过度自信的根源可能在于训练数据的偏差。LLM 的预训练语料主要来自教科书、论文和临床指南——这些文本通常以权威口吻陈述医学知识，很少表达不确定性。模型从这种语料中学到的，是"医生总是知道正确答案"的行为模式，而非"医生在面对不确定时会寻求更多信息"的职业素养。要改变这种行为，可能需要在训练或微调阶段引入不确定性建模的显式监督——奖励模型在信息不充分时表达"我需要更多检查"，而非强迫它给出一个可能错误的确定性答案。

⚠️ 7. 局限与未竟之路

论文坦诚地列出了 EHRBench 的若干局限。首先，基准主要基于住院患者的 EHR 数据，其疾病严重度和复杂性可能高于门诊患者。模型在该基准上的表现，未必能直接推广到门诊临床决策场景。

其次，EHRBench 目前聚焦于结构化编码数据（ICD 编码、处方记录等），而未充分利用 EHR 中的自由文本临床笔记。结构化数据更适合自动化处理，但临床笔记中蕴含的丰富信息（如医生的主观评估、患者的功能状态、家族史等）对临床决策同样重要。未来的版本可能需要整合多模态 EHR 数据。

第三，当前的任务设计主要评估单步临床决策（一次就诊内的诊断/治疗，或相邻两次就诊间的预后），而未涉及多步治疗策略的优化（如根据治疗反应动态调整用药方案）。这种动态决策能力是临床实践中更为复杂的挑战。

更深层的未解问题是因果推断与相关性的区分。EHRBench 的 QA 项基于真实患者中观察到的临床关系，但这些关系在统计学上的共现未必代表因果性。例如，"高血压"和"中风"在 EHR 中频繁共现，部分是因为高血压确实导致中风，部分是因为两者共享危险因素（如老龄化），还有部分是因为对高血压患者的筛查更可能发现中风。模型学习到的"预测能力"，在多大程度上对应于因果理解而非统计相关性？这是一个无法通过当前基准直接回答、但对临床应用至关重要的问题。

因果理解的缺失在特定场景中尤其危险。假设模型观察到"某种罕见药物 X 与某种并发症 Y 在 EHR 中频繁共现"，并学会了预测这种关系。但如果这种共现是因为"患有严重疾病的患者更可能被开具药物 X，同时也更可能出现并发症 Y"（共同原因偏倚），而非药物 X 导致并发症 Y，模型就会在临床上给出错误的预警。要区分这两种情况，需要超越统计共现的因果推断能力——例如，通过观察药物 X 停用后并发症 Y 的发生率变化，或通过比较接受和未接受药物 X 的相似患者群体。当前的 EHRBench 设计尚未纳入这种因果推断的检验，但这是未来版本值得探索的方向。

🎯 8. 结语：基准是镜子，照出的是差距而非终点

EHRBench 的价值不在于证明 LLM 已经准备好取代医生——恰恰相反，它通过近百万真实临床问题的系统评估，揭示了当前 LLM 在真实临床推理中的能力边界。没有模型突破 70% 的整体准确率，医学专用预训练并未带来预期优势，预后预测仍然是最薄弱的环节。这些不是失败的证据，而是诚实的诊断。

在 AI 医疗的狂热浪潮中，EHRBench 提供了一面冷静的镜子。它提醒我们：医学考试中的高分不等于临床实践的可靠，医学预训练不等于临床推理能力，检索病历信息不等于理解病历含义。真正的临床决策支持系统，需要能够从不完整的、 noisy 的、时序化的真实数据中，推断出隐含的临床逻辑——这是一种远比答题复杂的智能。

EHRBench 的另一个贡献在于其方法论。EHR-LLM-KB 交互管道展示了如何在自动化与可靠性之间取得平衡：LLM 提供规模和灵活性，KB 提供验证和约束，EHR 提供真实基础。这种"生成-验证-富化"的范式，不仅适用于临床基准构建，也可推广到其他需要大规模但高可靠性数据生成的领域。

最终，EHRBench 的意义超越了 LLM 评估本身。它提出了一个更根本的问题：当 AI 进入病房时，我们用什么标准判断它是否足够好？ 答案不应是教科书上的考试分数，而应是它在真实患者数据上的推理能力、它在不确定性面前的诚实度、以及它在复杂临床情境中的可靠性。EHRBench 为这个问题提供了第一个大规模的、系统的、扎根于真实世界的回答——而这个回答告诉我们，还有很长的路要走。

📚 参考文献

1. Xie, Y., Han, K., Xiao, Y., et al. (2026). EHRBench: An Automated and Reliable EHR-based Benchmark for Clinical Decision Making with LLMs. KDD 2026. arXiv:2605.30637 [cs.AI].

2. Jin, D., et al. (2021). What Disease Does This Patient Have? A Large-Scale Open Domain Question Answering Dataset from Medical Exams. ACL 2021.

3. Lee, J., et al. (2022). EHRSQL: A Practical Text-to-SQL Benchmark for Electronic Health Records. NeurIPS 2022 Datasets and Benchmarks.

4. Singhal, K., et al. (2023). Large Language Models Encode Clinical Knowledge. Nature.

5. Yang, Z., et al. (2023). PyHealth: A Deep Learning Toolkit for Healthcare Applications. ACM SIGKDD 2023.

#CrushAI #FeynmanLearning #智柴系统实验室🎙️