Epic 的脓毒症警报引擎在 2021 年密歇根医学中心（Michigan Medicine）的一次验证中失败了。它漏掉了三分之二随后发展为脓毒症的患者，却为 18% 的所有入院病例发出了警报。这一失误可以追溯到一个经典的数据泄露错误：模型将医生的抗生素医嘱（这本身就是怀疑感染的迹象）作为预测因子，本质上是在重复临床医生已经做出的决定。
为什么模型会失败
密歇根团队检查了 38,455 例住院记录，这相当于一个典型的多年期质量改进项目的规模。Epic 的内部基准测试承诺了高准确率，但独立测试的结果却恰恰相反。该模型的“高风险”警报在近五分之一的患者身上触发，然而三分之二的真实脓毒症病例却被漏掉。在实践中，该系统在应该捕捉事件时却频繁发出“注意”的虚假警报，同时又错过了真正需要关注的情况。
根本原因不在于机器学习算法本身，而在于输入的数据。通过将抗生素医嘱的存在作为输入，模型学会了预测临床医生已经做出的选择。当算法标记一名患者时，通常是因为医生已经开了抗生素，而不是因为患者的生理指标显示即将发生脓毒症。
医院 AI 面临的更广泛问题
Epic 的脓毒症模型已在数百家医院部署多年，但这种泄露错误一直隐藏着，直到一次专注的验证工作将其暴露出来。这一事件说明了一个系统性弱点：大多数医疗系统 AI 项目都缺乏早期发现此类问题所需的运营检查。
- 缺乏外部测试 – 医院没有进行外部测试。
- 缺乏持续监测 – 他们没有进行监测。
- 责任归属不明 – 由于没有专门负责数据质量和模型性能的团队，问题往往会被忽视。
这些差距使得许多 AI 项目陷入“试点停滞期”，无法超越概念验证阶段。
碎片化数据的隐藏成本
脓毒症案例还展示了碎片化的医疗 IT 生态系统是如何破坏 AI 的。常见的障碍包括：
- 患者记录锁定在无法自动交换数据的旧有 EHR 模块中。
- 影像和实验室系统无法互通，被迫进行手动文件传输。
- 重复的患者标识符将同一个人的数据分散在多个病历中。
- 临床笔记和生命体征存储在各自的孤岛中，从未合并用于模型训练。
当模型在干净、精选的数据集上进行训练，随后却被喂入实时、混乱的数据时，性能会悄无声息地下降。临床医生会迅速失去信任；如果一名护士必须在多个屏幕间追踪警报，即使底层算法在技术上是完善的，她也会选择忽略它们。
可靠 AI 的四个“枯燥”基础
一个功能完备的 AI 部署依赖于四种很少成为头条新闻的实际能力：
- 互操作性 – 数据必须能够在 EHR、实验室、影像平台和决策支持工具之间流动，无需手动导出/导入步骤。
- 治理 – 必须有负责任的个人或团队来负责数据质量，并随时间监测模型输出。
- 工作流集成 – 警报需要出现在临床医生现有的工作队列中；额外的点击或屏幕会阻碍其应用。
- 可扩展的运营 – 在模型投入生产之前，自动化监测、警报疲劳分析和定期重新训练流水线是必不可少的。
跳过其中任何一步，都会使项目面临像 Epic 脓毒症模型那样的无声失败风险。
在购买 AI 解决方案之前要问的问题
医院可以通过要求具体的答案来避免代价高昂的失误：
- 您能否追踪单个患者在模型将使用的每个系统中的数据？
- 谁（具体到姓名）负责维护数据质量并监督模型性能？
- 警报是否在真实的轮班期间与临床医生进行了测试，而不仅仅是在沙盒环境中？
- 是否有记录在案的监测计划，明确规定如何识别和解决性能漂移？
如果供应商无法指出具体的人员、流程或监测仪表板，组织应当暂停并重新评估。
核心启示
Epic 的败血症模型之所以失败，并不是因为机器学习不适合医院，而是因为缺乏配套的数据流水线和治理结构。一个仅仅是在预测医生自身决策的模型，提醒我们真正需要改进的是数据工程层，而非算法本身。在医疗领域构建值得信赖的 AI，需要那些维持任何关键 IT 系统运行的“乏味”基础设施：干净且互联的数据、明确的问责机制、嵌入工作流的警报以及主动监控。缺乏这些基础，即使是最先进的模型，最终也只会向错误的人发出错误的警报。