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

TL;DR 让 LLM 写 Python 代码、由受限本地执行器做确定性计算，在 MedCalc-Bench Verified 上使 32B 模型临床计算器准确率提升 7.05 个百分点，但 7B 收益不明确，且不能替代公式验证与变量提取。

问题

问题背景

临床计算器依赖精确算术，单个数值错误会改变医疗建议。大语言模型在数学推理上不可靠，制约其在临床决策支持等高风险场景的应用。

现有方法局限

当前主流方案是将每个计算器硬编码为经过验证的函数，逐一定制。这种做法的局限：

• 扩展性差：每新增一个临床公式都需要人工编写、测试和部署代码，55 个计算器已是很大维护负担。
• 灵活性低：硬编码无法处理临床记录中的变量变化或公式版本更新，也不能适应未曾预见的计算需求。
• 模型直接算术不可靠：LLM 原生生成数值结果受 token 采样和上下文影响，缺少确定性保证。

为什么这个问题难/重要

LLM 的算术错误源于自回归生成机制：模型输出数字序列时没有显式的算术运算验证步骤，无法保证符号计算的正确性。临床场景要求零容错，任何一个小数点错位都可能导致错误剂量或风险分层。同时，变量提取（从非结构化病历中识别输入）和公式验证（确保计算逻辑符合当前指南）本身就是独立难点，即使算术交给确定性执行器，上游错误依然会导致整体失败。业界对医学 AI 的监管和可靠性要求不断提高，使得“如何让模型承担计算又不引入错误”成为核心挑战。

行业类比

这一思路类似于代码生成中使用沙箱执行器运行模型生成的代码，把不可靠的生成过程与确定性的运行时分离，但前提是模型能正确决定调用方式和变量来源。

核心洞察

• Program-Solve 范式将 LLM 的角色从“数值计算器”转为“代码生成与决策器”，通过受限本地执行器实现确定性求解，而非逐个硬编码临床公式。其独特之处在于与常见的“模型直接算数”或“手写验证函数库”都不同：它保留了按案例生成 Python 的动态灵活性，同时把不可靠的算术外包给沙箱执行，使模型只需专注于理解临床文本并决定调用哪个公式，从而解耦“语言理解”与“数值运算”。
• 执行器的增益并非模型无关，而是显著依赖模型规模：在 Qwen2.5-7B 上仅 +3.29 且置信区间跨零，而 Qwen2.5-32B-AWQ 上 +7.05 且显著大于零。这与“外部工具能普遍补偿小模型能力不足”的常见假设相悖，说明模型自身必须具备足够的代码生成和指令遵循能力，才能有效利用确定性求解器，否则交接过程本身引入的错误会抵消算术准确性提升。
• 论文对 MedCalc-Bench Verified 的公式审计发现 55 个计算器中有 16 个存在版本、用途或系数问题，且 gold 变量提取仍是瓶颈。这一洞察的独特性在于：即使执行器算术完全准确，整个临床计算管线的可靠性仍受制于基准公式的可信度和变量抽取的前置步骤。它提醒部署者在临床 AI 中，验证公式与稳定提取变量比单纯替换算术组件更关键，而执行器只是其中一个环节，不能替代端到端的质量保障。

方法

方法核心：Program-Solve 接口

核心思想：让模型放弃直接算术，改为生成针对当前病例的 Python 代码，由受限本地执行器以确定性方式求解，模型任务从“计算”降维为“决定如何使用求解器”。

输入：来自 MedCalc-Bench Verified 的临床病例（1,100 例，覆盖 55 个计算器），每个病例包含完整临床笔记、计算器所需公式、以及黄金变量（gold variables）。在部分实验臂中，公式和黄金变量显式提供给模型；在另一些臂中则仅提供笔记，让模型自行提取变量并写出公式。

关键模块：

• 受限本地执行器：在本地隔离环境运行模型生成的 Python 代码，保证算术步骤确定、可复现，避免 LLM 自身概率性算术错误。
• Program-Solve 接口：模型接收病例信息后，输出一段 Python 代码，该代码读取输入变量并完成计算，执行器运行后返回数值结果；模型还可选择弃权（abstain），例如当无法可靠提取变量时。
• 对照臂：直接模型算术（模型在输出中直接给出数值）、手写 22 计算器库（预先验证的硬编码函数，仅支持其覆盖的 440 例）。

输出：每个病例一个数值结果或弃权标记；评分基于与金标准答案的一致性和是否弃权。评估指标包括准确率、配对差异，并用计算器聚类的 95% 置信区间衡量不确定性。

实验设计：模型采用 Qwen2.5-7B 和 Qwen2.5-32B-AWQ，以比较模型规模的影响。公式和变量访问被严格控制以区分算术错误与变量提取错误。

差异点：与逐计算器硬编码的验证库不同，Program-Solve 不预存公式，而是让模型动态生成求解代码；但与直接生成答案相比，又将确定性算术委托给外部执行器，仅保留代码生成和提取决策的不确定性。

实验

实验设计

在 MedCalc-Bench Verified（1,100 病例, 55 个计算器）上对比三种路线: 直接模型算术（基线）、Program-Solve 接口（模型生成 case-specific Python, 由受限本地执行器运行）和 手写 22 计算器库。模型为 Qwen2.5-7B 与 Qwen2.5-32B-AWQ, 均提供公式与 gold 变量，且都读取完整病历笔记。

关键发现

• 7B: Program-Solve 75.31% vs 直接算术 72.02%，提升 +3.29 个百分点，95% CI 跨零（[-3.49, 10.38]），优势不可靠。
• 32B: Program-Solve 90.53% vs 直接算术 83.47%，提升 +7.05 个百分点, 95% CI [0.47, 14.60] 下限大于零，显著改善。
• 手写库: 在覆盖的 440 个病例上完全精确，但整体准确率仅 40.0%（其余弃权），显示其无法泛化到全部计算器。

与基线对比解读

Program-Solve 把算术步骤从模型内部转移至确定性执行器，消除了纯计算错误；但模型仍需正确编写 Python 代码并选择变量。32B 具备更强的代码生成与指令跟随能力，能充分利用求解器；7B 在编程上表现不稳定，导致提升不显著。手写库可视为上限基准，但手工硬编码无法覆盖所有计算器。核心结论: 执行器对较大开源模型帮助更大，但不能替代已验证的公式或可靠的变量提取。

行业影响

落地场景

Program-Solve 模式适用于任何需要 LLM 输出精确数值结果、且计算规则可表达为代码的业务。典型场景包括：

• 医疗 SaaS：临床计算器（如肌酐清除率、CHA₂DS₂-VASc 评分）集成到电子病历系统，LLM 从非结构化病历中提取变量并生成 Python 代码，沙箱执行器返回确定性结果。
• 金融科技：贷款还款计划、风险评分、合规指标计算，避免模型直接算术导致的金额错误。
• 电商平台：动态定价、优惠券叠加、税费计算，LLM 理解促销规则后生成计算代码，保证价格准确。

商业价值

核心价值在于降低风险成本与提升可扩展性。对于医疗、金融等高风险领域，单个数值错误可能引发法律或生命安全问题。Program-Solve 将计算委托给确定性执行器，使模型只需负责语义理解和任务规划，显著减少人工审核与纠错成本。同时，新计算器无需逐一硬编码，只需提供公式和变量描述，模型即可自动生成 solver，加快功能上线速度，提升长尾场景覆盖。体验层面，用户获得始终一致、可复现的计算结果，增强对 AI 系统的信任。

与现有工作流的接口

可作为 LLM 的 tool/function calling 扩展集成。执行器封装为轻量级 API 或本地沙箱，接收模型生成的代码字符串并返回结果。工程上：

1. 定义公式库与变量 schema，供模型参考；
2. 使用 restricted exec 环境（如 Python ast 白名单）执行代码；
3. 记录执行日志便于审计，支持公式版本管理。

与现有 RAG、规则引擎兼容，可作为 agent 工作流中的一个工具节点。注意模型规模影响可靠性，生产环境建议使用 ≥32B 模型或适配提示与微调。

局限

• **实验范围较窄**：论文仅在 **MedCalc-Bench Verified** 基准和 **Qwen2.5-7B**、**Qwen2.5-32B-AWQ** 两个模型上评估，未覆盖其他模型家族或更大规模模型。临床有效性方面，作者审计发现 55 个计算器中 16 个存在版本、使用或系数问题，但并未在真实临床环境中部署验证。受限本地执行器的安全假设（如代码沙箱、资源限制）也缺少实际部署的详细分析，限制了结论的外推性。
• **依赖完整公式与黄金变量**：实验设置中模型可获得标准公式和人工提取的变量，这在实际临床场景中很难满足。论文未评估变量提取错误对最终准确率的传播影响，也未测试在无公式或变量缺失情况下的性能。代码生成质量同样未被单独分析，模型可能生成错误代码导致 executor 输出错误结果，而该错误率未被解耦。
• **与手工函数库相比的优势有限**：尽管 **Program-Solve** 覆盖了 55 个计算器，而手工库仅 22 个，但手工库在支持的 440 例上完全精确且弃权机制明确，executor 方法仍可能因代码生成或变量理解失误而输出错误答案。论文未与更强大的闭源模型或具备原生代码解释能力的模型（如 GPT-4 with code interpreter）比较，无法判断该方法在 SOTA 模型上的增益是否依然显著。