866ai

让大模型「出题」而不是「算题」:医疗计算器的确定性新解法

· 0 次浏览 ·来源: 866ai
大模型的算术能力不可靠,而临床计算器场景里一个数值错误就可能改变诊疗建议。常规做法是把每个计算器硬编码成经过验证的函数,逐个开发成本高昂。新方案调转分工:模型不亲自计算,而是针对具体病例生成一段 Python 代码,交给受限的本地执行器做确定性运算。在覆盖 55 类计算器、1100 个病例的 MedCalc-Bench Verified 上,这种程序求解接口显著优于直接计算,且全程可审计。

在医疗场景里,算术错误的代价被放大到了极致。一个肌酐清除率算错、一个化疗剂量偏了,下游的建议就全变了。大模型恰恰在这里有个出名的短板:语言能力越强,越容易在乘除之间自信地算错。行业里最稳妥的应对是把每个临床计算器都硬编码成经过验证的函数——但临床计算器成百上千,一个个开发、验证、维护,是笔沉重的事业成本。

换一种分工方式

一组新实验提出并验证了另一种思路:模型根本不该负责计算。它该做的是理解病例、选择正确的公式、然后写一段针对这个病例的 Python 代码;真正执行计算的是一个受限的本地执行器,输出完全确定、可以逐行审计。研究者在 MedCalc-Bench Verified 上测试这套程序求解接口——1100 个病例、覆盖 55 类临床计算器——结果显示,这种「模型出题、代码解题」的分工在准确率上明显优于让模型直接报数字。

这个方案妙在职责切分的刀法。语言模型真正擅长的是从病历文本里抽取变量、判断该用哪个公式、处理表述的千奇百怪;它不擅长的是多步算术。把两者拆开,各自的短板都不再致命。而且生成的是代码,出问题时可以复盘到底是变量抽错了、公式选错了还是代码写错了,错误归因清晰——这在需要向监管和质控交代医疗场景里,几乎和准确率同等重要。

可复制的工程范式

受限执行器是这套设计里容易被忽视的关键。允许模型生成任意代码再执行,等于把任意代码执行漏洞请进医院内网;对可调用的库、系统调用和运行时长做白名单约束,才让它真正可部署。这处理了「工具使用」范式里最现实的信任问题:模型只能在这个沙盒里表达它的意图。

同样的思路完全可以平移到金融估值、税务计算、工程测算这些数值敏感的领域——共同特征是公式明确、变量藏在非结构化文本里、错了要追责。语言模型负责读懂世界,确定性代码负责算准数字,这道分工线划清楚之后,大模型在专业场景里的可用性会上一个台阶。