“每一家小诊所，抽屉里都压着一叠已经悄悄放弃的拒赔单。”这是 Overturn 项目开篇的一句话。它是一款面向小诊所的申诉代理工具：你把拒赔通知交给它，它会告诉你这份拒赔意味着什么、申诉大概有多大胜算、下一步该做什么，并且直接把申诉信起草出来。整套东西跑在诊所自己的机器上。
这笔账其实不难算。每一张被放弃的拒赔单背后都是真金白银，往往是几千美元；而一名账单人员要读懂、解码、核对并写出一份申诉，大约要花 20 分钟。一个月几百张拒赔单，大部分最后都被直接核销——因为处理它的成本高过了能拿回来的钱。
Overturn 想改的就是这道算术题。它把待处理的拒赔单按预期可回收金额排序，而不是按单据金额大小排序，让账单人员从最值得花时间的那几张开始。对每一张单子，它会给出明确判断：该申诉、该更正后重新提交，还是该直接核销。
谁来付钱？诊所本身，或者为多家诊所处理拒赔业务的账单服务商。按项目的说法，每一张因为这款应用而变得“值得处理”的拒赔单，都是被找回的收入。
正方：本地开源模型，隐私和成本都站得住
支持这套方案的理由有三条。第一条是隐私：一份拒赔通知上带着患者姓名、会员 ID 和诊断信息。用本地开源模型，就不必和 API 供应商谈商业伙伴协议，也没有数据可泄露。第二条是成本：按 token 计费的模式下，每一次通知、重试、重写都在吃掉一张价值 90 美元的理赔单的利润；本地模型是固定成本，于是每一张拒赔单都变得值得处理。第三条是控制权：开放权重让诊所可以用一个环境变量换模型，用自己打赢过的申诉做微调，在自己的数据上比较模型效果——换成闭源 API，这三件事每一件都得先跟供应商谈。
技术栈上，模型是 Ollama 本地服务的开放权重模型，当前跑的是 qwen2.5:7b-instruct，只负责写申诉的论证部分，信里其余内容都由通知上的事实拼出来。有一道事实核查关卡，把草稿里的每个代码、CPT 和金额与源通知逐一比对；草稿不过关重试一次，再不过就退回模板信，并把被拒的草稿展示出来。胜算由一个在理赔历史上训练的 scikit-learn 模型给出，配置 API key 后可切换到 TabPFN。过往胜诉案例用 BM25 关键词匹配加向量检索，经倒数排名融合后存在 Tiger Cloud 的 Postgres 加 pgvector 里。每个步骤都会存档，崩溃的运行可以按 run ID 续跑，失败步骤带退避重试。
反方：数据是合成的，草稿只是草稿
项目自己也把话说得很直。数据是合成的；胜算模型的上限取决于诊所自身的历史，而新诊所几乎没有历史。草稿就是草稿，不构成法律建议。申诉窗口和判定标准因付款方而异，最终以通知为准。
还有几处没有跑通：Temporal 的杀进程续跑演示和 Render 部署尚未完成；Tinker 的对比数字和 Backboard 竞技场的结果还有待测量。模型竞技场和 Tinker 采样器走的是云端路径，竞技场只接受合成通知，应用在运行前会给出警告；界面上的外部调用计数器目前只统计模型调用，还没覆盖所有出站路径。作者表示，在敢下结论之前会先把这块补上。
已经验证的部分是：在一次测试中，向 Mastra 上的 Denial Desk 代理询问队列，它调用了队列工具并返回排在最前的理赔单；随后要求分析 CLM-26009，它调用了分析工具，返回翻案概率 0.612、预期价值 3765.26 美元，最佳动作是申诉。代理的回答与应用自身仪表盘一致。
我的判断
这个项目的价值不在模型有多强，而在它把“值不值得干”这件事前置了。拒赔处理长期卡在人力成本上，谁先解决排序问题，谁就先拿回钱。至于它能不能真的变成生意，作者自己留了个观察点：第一位用户、在业内工作的 Manoj Pareek 用完之后很满意，请他吃了一顿肯德基作为答谢。他强调这是礼物而非授权付费，不计入收入。接下来他想看的，是这位用户或另一支账单团队愿不愿意付钱，以及付多少。
热门跟贴