面向临床语言模型的确定性数学求解器

# 面向临床语言模型的确定性数学求解器
来源：https://arxiv.org/html/2609.10728
###### 摘要

大型语言模型在算术方面并不可靠，这对临床计算器而言是一个问题，因为单个数值错误就会改变建议。标准做法是将每个计算器硬编码为一个经过验证的函数，一次一个。我们测试了一种替代方案：模型不直接计算。相反，它生成针对特定病例的Python代码，由受限的本地执行器作为确定性求解器运行，而模型的任务简化为决定如何使用它。我们在MedCalc-Bench Verified（1,100个病例，55种计算器）上评估了这种“程序-求解”接口，并与直接模型算术和手写的22种计算器库进行了比较。我们使用Qwen2.5-7B和Qwen2.5-32B-AWQ模型，在根据当前临床指南审核基准的公式后，标记出55个公式中有16个存在版本、用途或系数问题。在提供公式和标准变量、且两种方法都读取完整病历的情况下，将任务移交给求解器在7B模型上并非可靠优势（75.31% 对比 72.02%，配对提升+3.29个百分点，95%计算器聚类置信区间为[-3.49, 10.38]），但在32B模型上则表现出优势（90.53% 对比 83.47%，+7.05个百分点 [0.47, 14.60]，明显高于零）。手写库在其支持的440个病例中结果精确，但在其他病例上选择不回答（整体40.0%）。因此，即使在公式、变量和病历访问匹配的情况下，添加执行器对某些开源权重模型的帮助也大于其他模型，而且无论哪种方式，它都不能替代经过验证的公式或可靠的变量提取。代码与数据：https://github.com/felipeocampoos/Towards-a-Deterministic-Math-Solver-for-Clinical-Language-Models。

## 1引言

使用语言模型自动化临床计算器（如APACHE II[1]）需要选择公式、从自由文本病历中提取变量并执行算术运算，MedCalc-Bench[2]显示模型在算术准确性上有所损失：Goodell及其同事在48个计算任务中报告，约三分之一未经辅助的ChatGPT试验给出了错误答案[3]。标准补救措施是为每个计算器编写一个手写函数，每个函数都经过编写、验证和维护，而不在集合内的每个病例都无法回答：评估的22计算器库实现了1,100个病例中的440个，在不回答的情况下获得40.0%的整体准确率。我们评估是否可以用通用接口替代特定计算器的执行：模型接收病例并编写一个简短的Python程序，受限的执行器运行它并返回一个数字、日期或孕龄元组。执行器不包含特定计算器的函数或常量；模型将提供的临床公式翻译成代码。在临床上，执行保真度是必要但不充分的：计算器编码的公式本身具有版本，几个常规使用的公式（免种族eGFR、MELD 3.0、PREVENT、Sampson LDL方程）已经取代了基准测试中可能仍在使用的前代版本。本地服务避免了外部API调用和数据传输；其未衡量的成本见第4节。

#### 相关工作与贡献。

程序辅助推理让模型为解释器生成代码[4,5]；思维链提示[6]是其上下文内的替代方案。执行这些代码所带来的安全风险与代码是否正确是不同的问题[7]。MedCalc-Bench将计算器调用形式化[2]；MedRaC将检索与Python执行配对，并分别评分公式选择、提取和算术[8]；RiskAgent在已验证的工具中进行选择[9]；一个临床计算器聊天机器人路由到可验证的计算器[10]；MeNTi通过嵌套工具调用连接计算器和代理[11]；可验证奖励训练提升了整体表现[12]；分解在提取不完整时增加了失败点[13]；大多数计算器选择错误是理解错误，而非算术错误[14]。一个代码解释器分支与特定任务计算器工具进行比较时，发现后者更准确[3]。AgentMD自动化了我们描述为维护负担的工具管理[15]，而部分库显示的覆盖-准确率权衡就是回避问题[16,17]。我们的贡献是在匹配公式、变量和病历访问的条件下，对特定病例的程序生成与直接算术以及手写替代方案进行受控比较。它在一个基准上确定了执行能解决什么和不能解决什么；推广到未见过的公式、语言或场景不在其范围内。

图1：(a)模型根据病历、公式和变量编写程序，一个不含计算器代码的执行器运行它：尝试了所有55种计算器，库实现了22种。(b)在1,100个病例上的准确率；空心柱：盲目程序-求解。程序-求解 减去 开放式算术：计算器聚类置信区间在7B上跨越零，在32B上明显高于零。

## 2方法

#### 数据与模型。

MedCalc-Bench Verified，包含55种计算器的1,100个测试病例，按照基准定义的容差进行评分。两个开源权重模型，Qwen2.5-7B-Instruct (bf16) 和 Qwen2.5-32B-Instruct-AWQ (4-bit)，通过vLLM在云H100 GPU上提供服务（张量并行度为1，每个模型一个H100；其他检查点同样使用一个H100，或对于Mistral，在张量并行度为2的情况下使用两个H100），对所有1,100个病例使用五个随机种子（42到46）。精修的单次示例来自基准的单独单次分割；没有任何病例的黄金标准答案或解释进入任何提示。MedCalc-Bench Verified采用CC-BY-SA 4.0许可，两个模型采用Apache 2.0许可。

#### 执行器。

每个程序启动一个新子进程：允许的内置函数白名单不包括file、eval或exec原语；仅导入标准math、date、time和calendar模块；静态拒绝异步和生成器构造；256 MB和CPU限制，5秒实时限制，以及执行行数上限。执行器是受限的，但并非沙盒：没有容器或系统调用过滤器。

#### 实验组。

表1列出了每个实验组的公式访问权限、变量访问权限和执行方法。仅病历组只接收病历。无公式页面组额外接收计算器页面但公式被隐藏，而开放式算术组则接收公式，两者都提供变量，由模型执行算术。提取-求解库组提取变量并调用22个手写Python计算器之一；黄金-求解库组则将相同的计算器与黄金标准变量配合使用。这22个计算器并非按特定标准选择：全部是实验室、物理或日期计算器，没有一个是基于评分的，这是一个机会性集合而非原则性集合。因为基准在每个计算器上平衡了20个病例，所以库的覆盖率是其已实现计算器数量的固定函数，因此其在不回答情况下的整体准确率受该数量限制（图2）。程序-求解是我们的方法：给定公式文本和黄金标准变量（即开放式算术接收的输入），模型编写一个程序，由执行器运行；盲目程序-求解组则两者均不提供，自行提取变量。计算器支持率、尝试回答率、有效程序率和正确答案率是不同的指标；表1仅报告正确答案率。

#### 比较设计。

比较通过公式访问、变量访问和病历长度来区分。仅病历组（120词）和无公式页面组（250词）限制了病历长度；开放式算术、程序-求解、盲目程序-求解和提取-求解库组都读取完整病历，因此程序-求解与开放式算术在公式、变量和病历长度上是匹配的。一个不提供黄金变量的250词单次实验组（表20）区分了预算与访问：在变量访问固定的情况下，仅增加预算在每个系列中增加了4到12个百分点。程序-求解与提取-求解库组在输入上不匹配；匹配的配对是程序-求解/黄金-求解库和盲目程序-求解/提取-求解库。解码、token、病历预算和执行器设置见表16；每个实验组的协议见附录A.1。

#### 统计。

病例嵌套在55个计算器中并在五个种子中重复出现，因此主要不确定性是计算器上的聚类自举（10,000次抽取，95%百分位区间，种子保持在一起）；病例自举、精确McNemar检验和符号翻转置换检验作为次要检验，在附录中按系列进行Holm校正。聚类区间未进行多重性校正；Holm校正仅应用于病例级检验。病例在库比较中在计算器内强烈聚类（组内相关系数0.68到0.81），因此其有效样本量为67到79个病例，而算术比较为120到190个病例（表7）。

## 3结果

表1：准确率（%），五个种子。实现列：库实现的22个计算器的440个病例；全部列：所有1,100个病例。黄金-求解根据审核在所有440个病例上正确，在其他病例上选择不回答，因此结构上为40.00%；两个库行选择不回答而非猜测。现在，开放式算术和所有程序组都读取完整病历（仅病历组和无公式页面组仍限制在120和250词）。语法行是一个基准特定的消融研究。短横线：未提供公式。
### 3.1匹配执行与部分库比较

在相同的公式文本、黄金标准变量和病历访问条件下，程序-求解在7B上并未可靠地比开放式算术更准确，但在32B上则明显更准确，其区间不跨越零（表2）。程序-求解在6.7%和0.7%的病例-种子行上未返回有效答案，在18.0%和8.8%上返回错误答案，而开放式算术没有未回答的情况，错误率为28.0%和16.5%（表14）。

库比较与上述匹配比较的结果不同：差异主要来自覆盖范围而非执行。与在其实现的每个病例上都正确的黄金-求解库相比，程序-求解在完整集合上领先+35.31个百分点（7B）和+50.53个百分点（32B）（表2），因为库在未实现的660个病例上选择不回答；在它实现的440个病例上，它达到了100%的准确率，而程序-求解为84.20%和98.64%，回答其他660个病例将一些错误答案替换了回避（表8）。仅限于39个审核无误的计算器（表12），差距在7B上为+32.26个百分点（[15.51, 48.21]），在32B上为+47.59个百分点（[32.97, 61.79]）。黄金优先混合组（在其440个病例上使用库，其他使用程序-求解）达到81.64%和91.07%，高于任何单一实验组；以开放式算术作为备用方案时，达到78.56%和86.89%（+3.07 / +4.18个百分点用于程序路径，两个区间都跨越零），而提取优先混合组的程序备用方案更差（-26.44 / -25.84个百分点，两个区间都明显低于零；表15、23）。

向提示中添加的两行语法和日期（程序-求解 + 语法）是在测试集上选择的，具有探索性（表2，下半部分）。它们将7B提升至77.95%，比没有它们的程序-求解高+2.64个百分点（聚类置信区间[-0.64, 6.29]）；32B在已经明显的优势上变化不大（+0.44个百分点，[-1.38, 2.35]）。在来自三个模型系列的四个检查点上，它们对程序-求解/算术差距的影响从-4.5到+2.6个百分点不等（表5）。

表2：完整1,100个病例上的配对差异（百分点），五个种子，附95%计算器聚类自举区间（10,000次抽取），未经多重性校正。上半部分：原始提示。下半部分：添加语法的提示，在测试集上选择。跨越零的区间表明既无差异也无等效性；配对估计值可能与四舍五入的均值差异略有不同。
### 3.2移除公式和黄金标准变量访问

盲目程序-求解在7B上达到28.04%，在32B上达到44.71%，分别比程序-求解下降了47.27和45.82个百分点（表1）；公式和变量访问权限同时改变，因此该设计未能区分召回率和提取率。与提取-求解库相比，7B的点估计值较低，32B较高，但两个区间都跨越零（表2）。观察到的失败是公式和变量错误，从输出中读取而没有进行受控分解：例如Cockcroft-Gault中的理想体重惯例、纠正阴离子间隙中的钾、呼吸频率中的心率。

#### 其他系列。

表1包括Mistral和Phi的结果，完整集合，提供公式下的代码对比算术，两者都读取完整病历：次要置换检验p<0.001和p=0.010；两者方向相反，Mistral的代码路径比算术落后7.6个百分点，Phi-3.5的代码路径领先4.2个百分点。Mistral的提取-求解库达到34.89%，高于任一程序-求解组。

## 4局限性

#### 实验范围。

两个Qwen检查点未能建立扩展规律；Mistral和Phi-3.5彼此之间以及与两个Qwen检查点的移动方向相反。四个delta-gap计算器在程序审核发现之前一直使用普通阴离子间隙公式，另外两个（一个阴离子间隙变体和一个相关的渗透压计算器）在第二次审核中被发现对应了错误的量；公式读取组在每次修复后都重新运行。然后对所有55个提供的文本进行完整性审核（表21），发现28个错误或不完整，10个无法复现基准的数字；这次重新运行中的每个实验组，包括开放式算术和程序-求解，都读取相同的、完全修正的文本。重新审核修正后的运行（表18），没有抽样错误追溯到定义不明确的公式；剩余的失败是为提供的输入虚构的单位转换以及多频段评分表中的单层疏忽，因此程序-求解的失败在于算术规范性，而非临床知识。仅病历组读取120词，比预算匹配的基线低估了4到12个百分点，而比较对象是一个部分22-