MedCalc-Pro：使用LLM Agents解决复杂医疗计算

# MedCalc-Pro：使用 LLM 智能体解决复杂医学计算

来源：https://arxiv.org/html/2607.02879

Siran Zhao♢\diamondsuit, Ruihui Hou♢\diamondsuit11footnotemark:1, Ziyue Huai♢\diamondsuit, Chennuo Zhang♢\diamondsuit, Tong Ruan♢\diamondsuit
♢\diamondsuit华东理工大学，上海，中国

###### 摘要

目前用于评估大型语言模型（LLM）在医学计算方面能力的基准大多基于简化场景：每位患者病例对应单一计算器，且查询中明确指明了所需工具。然而，真实临床场景通常需要多个计算器联合评估、嵌套尺度计算，以及不直接指定目标计算器的模糊查询。为此，我们提出了一个新的医学计算基准 MedCalc-Pro，它涵盖三个难度递增的任务设定：单计算器、多计算器和嵌套计算器设定。MedCalc-Pro 包含 2,268 个真实临床病例，覆盖 14 个临床科室的 77 个医学计算器。同时，为解决现有框架和方法在复杂临床场景中性能有限的问题，我们进一步提出了一种泛化性更强的智能体框架，该框架支持多工具选择和嵌套工具调用，并通过结构化验证和证据审查来抑制参数错误传播。我们对开源、闭源和医学专用 LLM 进行了系统比较，结果表明我们的框架在所有三个任务设定中均取得了最佳性能。这项工作为在具有挑战性的医学计算场景中评估和应用 LLM 提供了新的基准和方法。

MedCalc-Pro：使用 LLM 智能体解决复杂医学计算

Siran Zhao♢\diamondsuit††thanks:同等贡献., Ruihui Hou♢\diamondsuit11footnotemark:1, Ziyue Huai♢\diamondsuit, Chennuo Zhang♢\diamondsuit, Tong Ruan♢\diamondsuit††thanks:通讯作者
♢\diamondsuit华东理工大学，上海，中国

## 1 引言

参见标题图1：三种医学计算场景的示例：单计算器、多计算器和嵌套计算器场景。

大型语言模型（LLM）近年来在信息理解（Minaee 等人，2024 (https://arxiv.org/html/2607.02879#bib.bib29)）和复杂推理（Hao 等人，2024 (https://arxiv.org/html/2607.02879#bib.bib28)）方面取得了显著进展。然而，在需要精确执行外部工具的任务上，例如数值计算和基于规则的临床评分计算（Huang 等人，2024 (https://arxiv.org/html/2607.02879#bib.bib27)；Chen，2020 (https://arxiv.org/html/2607.02879#bib.bib31)），它们仍然表现出明显的局限性。这一问题在医学领域尤为突出。在临床实践中，医学计算器被广泛用于风险评估和预后预测（Moons 等人，2015 (https://arxiv.org/html/2607.02879#bib.bib9)）。因此，将 LLM 与医学计算器集成的研究兴趣日益增长。然而，现有的医学计算基准，包括 MedCalc-Bench（Khandekar 等人，2024 (https://arxiv.org/html/2607.02879#bib.bib26)）、CMedCalc-Bench（Zhang 等人，2025 (https://arxiv.org/html/2607.02879#bib.bib35)）、OpenMedCalc（Goodell 等人，2023 (https://arxiv.org/html/2607.02879#bib.bib25)）、CalcQA（Zhu 等人，2025 (https://arxiv.org/html/2607.02879#bib.bib32)）和 AgentMD（Jin 等人，2025 (https://arxiv.org/html/2607.02879#bib.bib2)），大多仍局限于简化设定。这些基准通常将明确的目标计算器查询与临床病例描述配对，且每个病例仅对应一个计算器。这种设定不足以捕捉更真实的医学计算场景。在实践应用中，通常需要联合使用多个计算器，并且一些复杂的计算器进一步依赖于子计算器的输出，形成嵌套的工具调用链。

表1：医学计算基准的比较。“模糊查询”表示基准是否包含不明确指定目标计算器的目标驱动查询。“过程评估”表示是否提供过程级评估。“多计算器”表示病例是否需要多个计算器，“嵌套计算器”表示病例是否涉及计算器之间的依赖关系。

为解决这些局限性，我们提出了一个新的医学计算基准 MedCalc-Pro，用于系统评估 LLM 在复杂医学计算场景中的表现。该基准涵盖三个难度递增的任务设定：单计算器、多计算器和嵌套计算器计算。具体来说，单计算器任务对应基本设定，即一个患者病例需要一个计算器；多计算器任务对应一个病例需要多个计算器进行联合评估的任务；嵌套计算器任务进一步要求模型识别计算器之间的依赖关系。图1 (https://arxiv.org/html/2607.02879#S1.F1) 展示了这三种任务设定。MedCalc-Pro 包含 2,268 个真实临床病例，覆盖 14 个临床科室的 77 个医学计算器。与现有基准相比，MedCalc-Pro 不仅涵盖了更接近真实临床使用的任务设定，而且更加强调临床目标驱动的查询，从而避免直接向模型暴露工具名称，并对查询理解、工具选择、参数提取和多步骤执行提出了更严格的要求。表1 (https://arxiv.org/html/2607.02879#S1.T1) 总结了现有医学计算基准与 MedCalc-Pro 的关键区别。同时，为解决现有方法和框架在复杂设定中泛化能力有限的问题，我们提出了一种泛化性更强的医学计算器智能体框架。该框架遵循真实的医学计算工作流程，由四个阶段组成：查询重写、检索与重排序、工具选择和工具执行。查询重写通过对原始查询进行多维重写来增强临床意图表示。检索与重排序从工具库中识别相关的候选计算器。工具选择使模型能够为临床任务选择合适的计算器。最后，工具执行执行依赖感知的嵌套计算器调用，同时引入结构化验证和证据审计以抑制错误传播并提高最终计算的鲁棒性。我们的主要贡献如下：

- •我们构建了一个新的医学计算基准 MedCalc-Pro，能够在单计算器、多计算器和嵌套计算器场景中更真实地评估 LLM。
- •我们提出了一种用于复杂医学计算的泛化智能体框架，通过查询重写、检索与重排序、工具选择以及带有结构化验证和证据审查的依赖感知工具执行，支持多计算器选择和嵌套计算器执行。
- •我们将我们的方法与代表框架在开源、闭源和医学专用模型上进行了比较。结果表明，它在所有三个任务设定中均取得了最佳性能，并在复杂场景中表现出强大的鲁棒性和泛化能力。

## 2 相关工作

### 2.1 医学计算器基准

近年来，随着 LLM 被应用于越来越广泛的现实任务（Morris 等人，2023a (https://arxiv.org/html/2607.02879#bib.bib5)；Nori 等人，2023 (https://arxiv.org/html/2607.02879#bib.bib33)），它们在特定领域应用中的性能引起了越来越多的关注（Singhal 等人，2023 (https://arxiv.org/html/2607.02879#bib.bib8)）。在医学领域，许多早期数据集，如 MedQA（Jin 等人，2021 (https://arxiv.org/html/2607.02879#bib.bib3)）、PubMedQA（Jin 等人，2019 (https://arxiv.org/html/2607.02879#bib.bib24)）、MedMCQA（Pal 等人，2022 (https://arxiv.org/html/2607.02879#bib.bib22)）和 MMLU 医学子领域（Hendrycks 等人，2021 (https://arxiv.org/html/2607.02879#bib.bib21)），主要采用多项选择和开放式问答格式，评估 LLM 是否能回忆并推理医学知识。此外，最近的一些研究提出了专门针对医学计算任务的基准，例如 CMedCalc-Bench、CalcQA 和 MedCalc-Bench。尽管做出了这些努力，现有基准通常假设单计算器设定，并且任务描述通常明确指定应使用哪个计算器。然而，在现实临床场景中，一个患者病例通常需要使用多个医学计算器进行评估，并且临床医生可能不会明确指示应应用哪些计算器。为了更好地反映真实的临床工作流程，我们构建了 MedCalc-Pro，它支持三种设定：单计算器、多计算器和嵌套计算器计算。

### 2.2 基于 LLM 的医学计算器执行方法

仅仅依赖模型完成整个计算过程存在显著局限性。模型的数值推理和计算性能通常不佳（Morris 等人，2023b (https://arxiv.org/html/2607.02879#bib.bib7)），降低了透明度，使得中间步骤难以验证，这在医学场景中尤其关键。为了提高可靠性和透明度，最近的研究探索了将 LLM 与外部工具集成（Schick 等人，2023b (https://arxiv.org/html/2607.02879#bib.bib6)），例如代码解释器（Gao 等人，2023 (https://arxiv.org/html/2607.02879#bib.bib16)；Chen 等人，2023 (https://arxiv.org/html/2607.02879#bib.bib17)）和外部 API（Schick 等人，2023a (https://arxiv.org/html/2607.02879#bib.bib15)）。这种方法在医学计算任务中也得到了广泛采用，例如 MeNTi（Zhu 等人，2025 (https://arxiv.org/html/2607.02879#bib.bib32)）和 AgentMD 使 LLM 能够与结构化医学计算器交互，允许确定性执行临床评分程序。然而，这些框架通常也假设每个患者病例对应单一计算器计算，限制了它们在现实临床场景中的适用性。这些挑战促使我们设计框架，通过结构化的智能体工作流程支持灵活的多计算器和嵌套计算器执行。

## 3 方法

### 3.1 任务定义

给定患者的电子病历（EMR）和查询 \(Q\)，任务旨在从候选集中选择合适的医学计算器，并根据患者的临床信息计算相应的答案。如图1 (https://arxiv.org/html/2607.02879#S1.F1) 所示，当查询为“应使用哪些工具来评估患者的卒中风险和出血风险以指导抗凝治疗？”时，模型首先选择相关计算器 CHA2DS2-VASc 评分和 HAS-BLED 评分。然后，它使用患者的临床信息应用这些计算器的评分规则，最终产生相应分数 6 和 3。

参见标题图2：我们框架的概览。该智能体包含四个阶段：查询重写、检索与重排序、工具选择和工具执行。

### 3.2 基准创建

为了评估 LLM 在医学计算任务中的能力，我们构建了 MedCalc-Pro，这是一个涵盖多种评估场景的基准。该基准包括三种类型的计算任务：单计算器、多计算器和嵌套计算器。对于单计算器任务，我们使用 MedRaC 作为原始数据集。它包含 1,048 个患者病例，涵盖 55 个医学计算器，包括 20 个基于规则的计算器和 35 个数值计算器。对于多计算器任务，我们首先从 MedCalc-Bench 构建病例，通过将具有相同患者病例的条目分组并仅合并其真实计算器标注，得到 1,066 个多计算器候选。然而，该数据集高度不平衡，基于规则的计算器出现频率远低于数值计算器。为了提高基于规则的计算器覆盖率，我们进一步从 PMC-Patients（Zhao 等人，2022 (https://arxiv.org/html/2607.02879#bib.bib30)）构建病例。具体来说，我们使用正则表达式匹配，从 180,142 个病例中识别出明确提及多个计算器名称和分数的临床记录，获得 3,517 个候选描述。在筛选出具有足够临床信息以计算所有所需计算器的病例后，我们获得了 92 个额外的多计算器病例，涵盖 33 个基于规则的计算器。对于所有多计算器病例，我们丢弃原始查询，并使用 GPT-5.1 根据相应的临床文本生成模糊的、目标导向的查询。这种设计更好地模拟了真实的医学计算请求，医生通常描述临床目标而不是明确命名所有目标计算器。详细提示见附录 B (https://arxiv.org/html/2607.02879#A2)。对于嵌套计算器任务，我们也从 PMC-Patients 构建数据，使用正则表达式匹配来识别提到具有依赖关系的计算器的临床记录。除了父计算器名称外，我们要求子计算器名称及其相应分数和支持性临床描述同时存在，确保父计算器和子计算器都可以从临床文本中推导出来。在筛选出具有足够信息以支持完整依赖链的病例后，我们获得了 62 个嵌套计算器病例。

质量控制。我们应用三阶段质量控制过程以确保构建的基准的可靠性和真实性。首先，为防止答案泄露，当临床文本中直接显示目标计算器或预期输出时，我们移除其中的计算器名称和最终分数的明确提及。其次，三名受过训练的研究生审查所有病例，以验证临床描述、所需参数值和预期输出之间的一致性，同时确保查询忠实于相应的临床文本且在临床上合理。第三，一名临床医生审核 20% 的病例以检查临床正确性和查询真实性。不合格的病例附上说明退回给学生评审员进行修改，并迭代重复审查过程，直到整体标注准确率超过 95%。

工具包构建。我们分两个阶段构建工具包。首先，我们重用 MedCalc-Bench 中 46 个计算器的经过验证的计算逻辑，并在统一的配置模式（schema）下重新组织它们，标准化参数定义，并补充来自权威临床参考（如 MSD 手册111https://www.msdmanuals.com/）的描述。其次，我们实现了 31 个额外的计算器，以扩展在代表性不足领域的覆盖范围，包括神经评估（例如 NIHSS）、功能评估（例如 ECOG）和精神科筛查（例如 PHQ-9）。所有计算器都作为智能体框架中可调用的工具。