让大模型不再算错药：临床计算的确定性求解方案

大模型的算术软肋在临床场景被无限放大

大语言模型在文本理解上表现惊艳，却在最基础的算术运算上频频翻车。在多数应用里，一次小数点错误无伤大雅；但在临床计算器场景中，单个数字算错就可能改变整个用药推荐或诊断建议——这是关乎患者安全的硬伤。

一篇发表于 arXiv 的研究（编号 arXiv:2609.10728）正面挑战了这一问题。论文指出，行业内应对模型算术不可靠的常规做法，是把每一个临床计算器都手工编码成经过验证的固定函数，逐个实现。这种方式虽然精确，却难以扩展——每新增一个计算器都需要人工开发和验证。

Program-Solve：让模型写代码，而不是自己算

研究团队提出了一个替代思路：模型不负责计算。取而代之，模型针对具体病例编写 Python 代码，交给一个受限的本地执行器（restricted local executor）作为确定性求解器运行。这样一来，模型的任务就从「算出正确答案」降维成「决定如何调用求解器」。

这个被称为 Program-Solve 的接口设计，核心在于职责分离：模型擅长的是理解病历、识别变量、选择公式这类语义任务，而把它不擅长的确定性数值计算交给真正可靠的代码执行环境。这与近年来「工具调用」和「代码解释器」的思路一脉相承，但被具体落地到了对精度要求极高的临床计算领域。

「工具调用」（Tool Use）与「代码解释器」（Code Interpreter）是近年来提升大语言模型可靠性的两条主流路径。前者让模型在推理过程中动态调用外部 API 或函数，后者则允许模型生成可执行代码并获取运行结果再继续推理。二者的共同出发点是：语言模型擅长语义理解和逻辑规划，但不擅长需要精确状态跟踪的符号运算。受限本地执行器（restricted local executor）相比通用代码解释器更进一步——它只允许运行特定的、经过沙盒隔离的代码，防止任意系统调用带来的安全风险，这在医疗等合规敏感场景中尤为关键。Program-Solve 的本质是把模型角色从「端到端的计算者」收窄为「计划生成者」，利用代码执行器的确定性弥补模型浮点运算的不可靠性。

在 MedCalc-Bench 上的严谨评测

研究在 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] 明确大于零。

换句话说，加装执行器对不同开源模型的帮助并不均等——更大的模型才能更充分地利用这套确定性求解机制。

MedCalc-Bench 是专为评估大语言模型在临床计算任务上的表现而设计的基准数据集，覆盖肾功能评分（如 eGFR）、心血管风险评分（如 CHA₂DS₂-VASc）、体液补充计算等多类常用医学评分工具。Verified 子集在原始数据集基础上经过人工核查，剔除了公式描述模糊或病历信息不完整的样本，以保证评测结论的可重复性。值得注意的是，临床计算器本身并非铁板一块——同一个评分系统（如 Glasgow Coma Scale）在不同版本指南中可能存在系数差异，而这类差异在自动化评测中极易被忽视，该团队对 16 个问题条目的人工审计正是针对这一盲区的补救措施。

「配对提升」与置信区间的表述方式来自配对统计检验框架：研究者对同一批病例同时运行两种方法，再比较每个计算器维度上的成对差值，用聚类区间（clustered confidence interval）校正同一计算器内部样本的相关性。这种做法比直接比较总体准确率更严格，因为不同计算器的难度差异悬殊，若不进行配对，容易因样本构成不同而产生误导性结论。7B 模型的区间跨越零点（[-3.49, 10.38]）意味着在统计上无法排除「执行器实际上没有帮助甚至有害」的可能，而 32B 模型的区间下界为正（[0.47, 14.60]）则提供了更强的统计保证。

手工库的精确与局限

作为对照，那个手工编写的库在其支持的 440 个病例上完全精确，但对其余病例选择「弃权」（abstain），整体覆盖率仅 40.0%。这清晰地揭示了传统方案的两难：要么精确但覆盖窄，要么覆盖广但精度存疑。

Program-Solve 的价值恰恰在于试图打破这个权衡——用模型的泛化能力换取更广的覆盖，同时用确定性执行器守住计算精度的底线。

一个务实的结论：执行器不是万能药

研究给出的结论相当克制。即便在公式、变量、病历访问都完全对齐的条件下，添加执行器对某些开源模型的帮助也大于其他模型，而且它既不能替代经过验证的公式，也不能替代可靠的变量提取。

这一点尤为重要：Program-Solve 解决的是「算得对不对」，但整个临床计算链条上，「用了哪个公式对不对」「从病历里抽取的变量对不对」这两个环节同样致命。确定性求解器只是把最后一块拼图补齐，而非包治百病的银弹。

对于正在探索 LLM 在医疗、金融等高精度需求领域落地的团队，这项工作提供了一个有参考价值的架构范式，也提醒大家：模型规模、公式验证、变量提取三者缺一不可。