向AI转型的程序员都关注公众号 机器学习AI算法工程
核心速览
电子病历不是一篇可以从头读到尾的病程摘要，而是一条不断延长、信息密度极高的时间线：化验、处方、转科、影像、诊断与出院记录会在不同时间留下痕迹。EHR-R1 想解决的，是让语言模型不只在病历里找关键词，而是能围绕具体临床问题筛出相关线索、组织它们，并给出面向任务的答案。
这篇工作把电子病历分析统一成一批可训练的生成任务，另外用医学知识图谱辅助合成推理轨迹，再以三阶段训练把这套能力写进模型。它的价值不在于再给一个通用大模型加几条医疗提示词，而在于试图把“怎样从纵向记录中形成判断”变成可规模化训练的数据与模型问题。
骨架透视
- 痛点
一份纵向病历常有大量异质事件，但临床问题需要模型识别哪些记录有关、它们在时间上怎样连起来。 - 灵感
把病历事件与目标医疗实体之间的统计关联和知识图谱关系组织成“thinking graph”，再据此构造推理监督。 - 方案
构建 EHR-Ins、EHR-Bench，并以领域适配、推理增强和 GRPO 训练 EHR-R1。 - 证据
论文在内部 EHR-Bench、MIMIC-IV-CDM 与 Stanford EHRSHOT 上报告了决策、风险预测及跨数据集迁移结果。
论文信息
如果问题是“这位患者下一步可能需要什么检查”或“未来一段时间会不会再入院”，答案很少藏在某一条记录里。它常常取决于此前的检验趋势、正在使用的药物、近期诊断、转诊过程，以及这些事件之间的先后关系。
这正是电子健康记录（EHR）与一般医学问答不同的地方。前者主要不是整齐的叙述文本，而是按照业务流程沉淀下来的纵向事件流。模型面对的既有实验室结果、处方与收费编码，既要从中取舍，也要判断事件发生的时间会不会改变其意义。
现有 EHR 模型常针对单一疾病、单一结局或单一预测任务设计。语言模型虽然能把结构化表格改写成文本后读进去，但要同时覆盖下一步临床操作、诊断、治疗建议、住院结局与再入院风险，任务形式和评价方式并不相同。
EHR-R1 的出发点是先把这个问题拆开。论文把任务分成两类：临床决策关注“根据已知病历，下一步可能出现什么医疗实体”；风险预测则判断指定时间窗内是否会发生某类结局。它们共享病历输入，却不能共用同一种指标和同一种输出约束。
论文构建的 EHR-Bench 覆盖 42 项任务，其中 24 项是临床决策任务，18 项是风险预测任务。前者以多标签实体预测衡量 F1，后者以二分类 AUROC 衡量区分能力。这个区分很基础，却决定了后面所有结果应该怎么读：F1 与 AUROC 回答的不是同一个问题，不能直接放在同一把尺子上比较。
论文从 MIMIC-IV 的多类记录出发，把同一患者的事件按时间组织，并转写成更适合语言模型处理的 Markdown 式自由文本。每个样本由“到当前时点为止的可观测历史”加上一条任务指令组成；模型输出相应的医疗实体集合，或回答某个风险结局是否发生。
这个环节看似只是格式转换，实际上处理了两个常被忽略的细节。
其一，数据切分按患者 subject_id 进行，避免同一患者同时出现在训练和测试中。论文报告的完整训练集与测试集分别包含 269，496 名和 30，216 名患者。
其二，作者把历史观察窗口限制在 24 小时，并仅保留含 10 至 100 个历史事件的样本。这样做会损失一部分更长或更短的轨迹，但能控制输入长度，也让任务中的时间上下文具有相近的尺度。
最终，EHR-Ins中有约 353 万条非推理样本和约 28.9 万条推理样本；EHR-Bench 则是由测试集抽取的 21，000 条样本。论文摘要中把前两项近似写作 350 万和 30 万，正文方法部分给出了更精确的计数。
很多推理式训练的难点，在于推理文本可以写得流畅，却未必真正由病历支持。EHR-R1 没有直接让 GPT-4o 对原始病历自由生成长链条，而是先试图构造一个受约束的中间结构。
作者先在同一任务内统计上下文实体与目标实体的共现关系，用 Lift 找出值得进一步追踪的实体对。为了抑制偶然共现，只有两端出现次数都大于 5、且 Lift 大于 5 的实体对才会进入下一步。
接着，系统把这些实体映射到 UMLS，在知识图谱中双向搜索可能的医学关系。得到的不是完整病历的知识图谱，而是围绕当前任务、从病历线索走向目标标签的一组候选路径。
最后才由 GPT-4o 基于历史事件、实体关系和目标标签生成三段式内容：Extraction、Reasoning 与 Final Result。为了避免模型为无法支撑的标签硬编解释，论文只保留可推理标签占原始标签至少 70% 的样本。
这套设计并不把每一条合成推理等同于医生的真实思考过程。它是在训练数据层面给模型增加一条约束：从病历里抽哪些事实、怎样把事实与目标联系起来、最终答案应落在哪里，都要有相对明确的结构。
论文还请医学专家对 8 类临床决策任务中的100 条合成推理链进行五分制评估，并与不使用 thinking graph 的直接蒸馏方式比较。这个实验支持作者对数据质量的判断，但它核验的是一小组抽样推理链，不应被延伸为对全部推理数据的逐条人工验证。
训练路径 · Domain Adaptation → Reasoning Enhancement → GRPO
EHR-R1 的训练顺序很清楚。
第一阶段用非推理问答样本做领域适配，让基座模型熟悉 EHR 的事件分布、文本格式和任务标签。论文并非只监督最终答案，也让模型学习输入序列本身，以期更好捕捉病历中的时间与共现结构。
第二阶段改用带推理链的样本。此时输出中既有<；think>；标签包裹的推理过程，也有最终结果；训练目标是让模型学会从可观测历史里提取与任务有关的内容，再形成答案。
第三阶段使用 Group Relative Policy Optimization（GRPO）。作者设置格式奖励与任务准确性奖励，并将 GRPO 更新限制在每项任务 500 个示例上。这里的强化学习并不是凭空生成临床知识，而是在前两阶段形成的 EHR 表达与合成推理基础上继续优化输出轨迹。
这种拆分使得“推理为什么有效”至少可以被分成两个问题：训练时是否看过 EHR 专属推理数据，以及推理时是否真的生成推理过程。论文后面的消融正是围绕这两个层面展开。
把任务统一为指令格式，还有一个容易被忽略的好处：模型不会只根据病历猜一个最可能的疾病名称。对于临床决策任务，指令会明确询问下一步的服务、检查、诊断、治疗或 ICU 事件；对于风险任务，指令则给出待预测结局及时间窗。输入的病历历史可以相似，目标答案却完全不同。
这种设计也让“推理”有了具体落点。它不是要求模型泛泛解释患者为什么复杂，而是要求模型围绕当前问题，在可观测历史中选择与目标相连的记录。论文的 thinking graph 因而按任务分别计算实体关联，而不是把所有出现过的医学概念塞进同一张大图。
单纯依赖共现，容易把经常同时出现的项目误当成有临床意义的证据；单纯查询知识图谱，又未必知道当前病例里哪条关系值得优先使用。本文把两者串联：Lift 先从真实训练样本中筛出与目标标签更可能有关的实体对，UMLS 再补上实体之间可能的医学关系。
这不是在病历中直接推断因果。作者将其定位为给后续推理生成提供候选参考，并且会丢弃无法映射到 UMLS 或无法建立有效关系的实体对。对读者而言，这条边界很重要：图谱在这里承担的是约束与检索作用，而不是取代临床判断的规则引擎。
从评测角度看，这也避免了把所有任务都压缩成一个“医学问答”分数。实体集合预测需要同时顾及预测是否准确和答案是否完整，风险预测则考察模型对正负结局的排序能力。论文分别报告 F1 与 AUROC，正是因为两类任务的输出空间不同。
在这套框架下，模型规模仍然重要，但不再是唯一变量。作者在 1.7B、8B 与 72B 三个规模上使用同一训练路径，试图检验的是数据与训练策略能否随着基座模型变化而保留作用，而非只在单一大模型上成立。
EHR-Bench 的 24 项临床决策任务要求模型输出医疗实体集合，使用 F1。论文报告 EHR-R1-72B 的平均 F1 为 0.6744；同一设置下，Qwen2.5-72B 为 0.3535，GPT-4o 为 0.3155。
这里“0.6744”不是一个笼统的医疗能力分数，而是这一批多标签决策任务的平均 F1。论文也为通用基线提供最多 100 个候选标签供选择，而 EHR-R1 可直接生成答案；因此比较应理解为作者定义的统一评测协议下的结果，不能外推成不同医院工作流中的实际临床效果。
风险预测部分则是另一种任务。18 项任务用 AUROC 评价，EHR-R1-72B 的平均 AUROC 为 0.9523，论文列出的第二高基线 Qwen3-235B 为 0.8245。
把决策任务和风险任务放在一起看，论文真正想展示的是任务覆盖：同一个模型家族可以处理多标签医疗实体预测，也可以处理二分类时间窗风险问题。至于某一项分数能否转化为临床价值，还取决于数据来源、任务定义、输出接口和后续临床验证，这些都不在本文实验范围内。
论文还在两个额外评测中观察迁移能力。
MIMIC-IV-CDM 同样基于 MIMIC-IV，但采用不同的数据整理和诊断任务设计。零样本设置下，EHR-R1-72B 在主疾病诊断与 ICD 级诊断上的 F1 分别为 0.8913 和 0.3501。这是同源数据资源下的任务形式变化，不是跨医疗系统外部验证。
EHRSHOT 则来自 Stanford Medicine，公开部分覆盖 14 项风险预测任务。论文将其格式化为更接近模型输入的自由文本后，分别进行零样本与小样本评估。零样本比较中，作者报告 EHR-R1-72B 在三个任务类别和总体平均 AUROC 上均高于所比较的约 70B 参数模型。
小样本部分更适合看“适应速度”。在每项任务最多使用 128 个示例的条件下，EHR-R1-1.7B 的平均 AUROC 为 0.7465，Qwen3-1.7B 为 0.5998。这个结果支撑的是在 EHRSHOT 所设定的任务与微调协议中，经过该训练流程的 1.7B 模型有更高的平均表现；它不等于模型在真实医院中已经完成快速上线或验证。
如果只看最终大模型，容易把增益全部归因于“更强的推理”。论文的消融实验提供了更细的拆分。
对于 72B 模型，直接回答时，加入推理数据训练后的平均 F1 从0.6039 提升到 0.6281。完成训练后，再使用推理式输出，平均 F1 进一步从 0.6039 提升至 0.6418。
相反，作者报告把一般推理提示直接加到未经过 EHR 推理训练的基座模型上，并没有稳定带来收益。至少在本文的决策任务设置里，推理形式本身不足以替代领域数据、任务定义和训练过程。
EHR-R1 最值得讨论的地方，是它把长病历中的信息选择问题放到训练数据中心。传统的上下文扩展会让模型看到更多事件，但“看得更多”不自动等于“知道哪些是诊断或预测所需的证据”。
Thinking graph 的做法提供了一条很具体的路线：先从任务内共现找候选线索，再以 UMLS 关系把线索与目标连接，最后再生成能被模型学习的推理文本。它把自由生成的解释压缩到病历事实、实体关系和任务标签共同约束的空间里。
这也解释了为什么本文同时建设数据集、模型和基准。若只有模型，很难分清收益来自模型规模、任务格式还是推理监督；若只有单项 benchmark，又难以观察不同任务类型是否共享同一种能力。EHR-Ins、EHR-R1 和 EHR-Bench 的组合，尝试把三者放进同一套实验语言里。
对医疗 AI 而言，一段顺畅的自然语言解释并不自动构成可靠依据。本文合成推理链的 Extraction 阶段要求指出相关事件及时间戳，Reasoning 阶段再连接证据与目标，Final Result 才输出答案。这个顺序并不能保证模型输出在临床上可直接采用，却明确了一个值得保留的工程方向：解释最好能回到实际记录，而不只是给结论配一段听上去合理的文字。
对于未来的 EHR Agent，这种“可追溯的线索选择”可能比单纯延长上下文更关键。它既关系到模型怎样从冗余记录中取信息，也关系到临床人员在需要时能否理解模型的答案从何而来，并决定后续的人机协作接口、审阅流程与责任边界应如何设计。
EHR-R1 试图回答的不是“医疗大模型是否懂医学”，而是更具体的问题：面对一条纵向、异质、充满冗余的电子病历，模型能否围绕任务形成一条有组织的证据路径。
论文给出的答案是一套组合式方案：用统一任务把病历变成训练问题，用 thinking graph 为推理数据增加结构约束，再用分阶段训练把领域表达、推理监督与后续优化连接起来。它的实验覆盖了内部基准、同源但不同任务设计的 MIMIC-IV-CDM，以及来自 Stanford 的 EHRSHOT；这些结果为该方案在所测任务上的表现提供了证据，也为后续讨论 EHR 模型的训练数据与评价方式留下了一个清晰的起点。
机器学习算法AI大数据技术
搜索公众号添加： datanlp
长按图片，识别二维码
阅读过本文的人还看了以下文章：
【模型高效部署】tensorrtx 深度解读，yolov11高性能推理实战案例
实时语义分割ENet算法，提取书本/票据边缘
整理开源的中文大语言模型，以规模较小、可私有化部署、训练成本较低的模型为主
《大语言模型》PDF下载
动手学深度学习-（李沐）PyTorch版本
基于40万表格数据集TableBank，用MaskRCNN做表格检测
《基于深度学习的自然语言处理》中/英PDF
Deep Learning 中文版初版-周志华团队
【全套视频课】最全的目标检测算法系列讲解，通俗易懂！
《深度学习入门：基于Python的理论与实现》高清中文PDF+源码
python就业班学习视频，从入门到实战项目
2019最新《PyTorch自然语言处理》英、中文版PDF+源码
《21个项目玩转深度学习：基于TensorFlow的实践详解》完整版PDF+附书代码
《深度学习之pytorch》pdf+附书源码
《Python数据分析与挖掘实战》PDF+完整源码
不断更新资源
深度学习、机器学习、数据分析、python
搜索公众号添加： datayx
