AI病历三分之一有错：遗漏才是最致命的失败

当AI记录的问题不在于"写错"，而在于"没写"

一项针对三款已部署AI医疗记录工具（AI scribes）的审计揭示了一个令人警醒的结果：每三份病历中就有一份存在可验证的失败。而更关键的发现是，这些失败的主导类型并非记录错误，而是遗漏——临床诊疗过程中明确建立的信息，病历却从未记录下来。

这个结论对于任何依赖大语言模型（LLM）生成结构化内容的场景都具有普遍意义。我们习惯于关注模型"说错了什么"，却往往忽视了更隐蔽、也更危险的问题：模型"漏说了什么"。在医疗场景下，一条被遗漏的用药史、过敏信息或症状描述，其后果可能远比一处措辞错误严重得多。

为什么"LLM裁判"在检测遗漏上近乎抛硬币

业界应对AI生成内容质量问题的标准方案，是引入一个"LLM裁判"（LLM judge）——让另一个大模型阅读生成的病历，并对照原始诊疗转录（transcript）进行核对。这套方法在检测"写错"类错误时或许有效，但审计发现，它在检测遗漏类错误上的表现接近于抛硬币（near coin-flip）。

原因在于这类裁判机制的底层逻辑存在结构性缺陷：裁判验证的是"存在"，而非"缺失"。当裁判读到病历中的一句话，它可以去转录中核对这句话是否属实；但当某条信息压根没出现在病历里，裁判没有一个明确的"锚点"去触发核查。它无法凭空意识到"这里本该有一条信息，但它不见了"。

这揭示了一个深刻的认知偏差：验证存在的事物是自然而然的，而察觉不存在的事物则需要主动的、穷尽式的检索。人类如此，模型亦然。一个只会"读过去挑毛病"的裁判，本质上永远无法可靠地发现被沉默掉的信息。

这一现象在认知科学中有对应的理论基础。心理学研究中的"变化盲视"（change blindness）和"非注意性盲视"（inattentional blindness）均表明，人类和系统在面对连续信息流时，对"消失的事物"的感知能力天然弱于对"出现的事物"。LLM在预训练阶段学习的是语言的共现模式，其注意力机制本质上是被输入中"存在"的token所激活的——不存在的token不会产生任何激活信号，因此也不会触发任何推理过程。这意味着无论裁判模型规模多大，只要任务结构不变，这一盲点就不会消失。值得注意的是，"接近抛硬币"并非随机分布，而是系统性地偏向漏报（false negative）：裁判更容易误判"遗漏项其实存在"，而非误判"存在项其实遗漏"，这使得遗漏错误在统计上被持续低估。

真正的解法：重构任务，而非升级裁判

面对这一困境，直觉性的反应往往是"训练一个更强的裁判"。但审计给出的结论恰恰相反：问题不在裁判，而在任务结构。

提出的解决思路是将检测任务彻底重构：

第一步：枚举事实

不再让模型笼统地"读病历找问题"，而是先从原始转录中穷尽式地列举出所有应当被记录的事实。这一步把隐性的、分散在对话中的信息显式化、结构化，形成一份明确的清单。

这一步骤在技术上对应的是"信息抽取"（Information Extraction）任务，而非"质量评估"任务。两者对模型的要求截然不同：质量评估需要模型同时持有"期望状态"与"实际状态"并进行比对，认知负荷极高；而信息抽取只需模型从单一来源（转录文本）中识别并结构化输出事实条目，这是LLM在监督微调和指令跟随训练中被大量强化的能力。在实践中，这一步通常需要预先定义"事实类别"模板（如：主诉、现病史、用药史、过敏史、体征、诊断、医嘱等），引导模型按类别穷尽抽取，而不是自由生成，以减少类别级别的遗漏。这种结构化抽取的输出本身也可作为后续审计和溯源的依据。

第二步：逐条核查

拿着这份事实清单，逐一检查每一条是否在病历中得到体现。这样一来，遗漏不再是"无法被察觉的缺席"，而变成了清单上一个明确未被勾选的项目。

这种"先枚举、再核查"的范式，把"检测缺失"这个困难问题，转化为"检测每一项是否存在"这个模型本就擅长的问题。它没有对抗模型的能力边界，而是绕开了它——通过任务设计，让缺席变得可见。

对AI应用设计的启示

这个案例的价值远超医疗记录本身。它指向一个普遍的工程原则：当某类错误在现有评估框架下系统性地不可见时，答案往往是重新设计任务，而不是堆砌更强的模型。

无论是文档摘要、会议纪要、法律合同审阅还是数据提取，只要输出需要"完整覆盖"输入中的关键信息，遗漏就是一个天然的失败模式。而单纯依赖"读一遍输出挑错"的验证方式，都会在检测遗漏上失灵。

将验证过程结构化——先建立"应有内容"的完整清单，再逐项比对——是提升AI输出可靠性的一条务实路径。它承认了模型在"感知缺失"上的先天弱点，并用任务设计弥补了这一缺口。

缺席，才是真正的失败模式。 而对抗缺席的唯一办法，是让每一件本该存在的事物都被明确点名。

软件工程领域中有一个相近的概念可以参照：测试覆盖率（test coverage）。单元测试的价值不在于"运行程序看它坏没坏"，而在于预先定义每一个应当被满足的行为断言，再逐一验证。AI输出的质量保障在思路上需要完成同样的转变——从"运行后检查"走向"规格先行"。这也与形式化验证（formal verification）中的思路相呼应：先定义完整的规约（specification），再证明实现满足规约，而不是靠随机测试碰撞出问题。对于高风险AI应用（医疗、法律、金融合规等），这种"规格先行"的验证范式不只是工程最优实践，更可能成为监管合规的基本要求。