Google 发布健康 AI 多方法评估框架白皮书

Google于2026年11月4日公布了一份白皮书，阐述了其如何评估健康领域的通用生成式AI。该框架结合封闭式问题基准测试、AI自动评分器和专家人工复核，从准确性、安全性和有用性三个维度评判模型在常见及高风险场景中的表现。

作者Sarah Montgomery-Taylor博士是Google for Health的临床评估负责人；Elizabeth McGlynn博士和Dana Gelb Safran博士共同参与了这项工作。Google表示，公司构建了这一方法，并持续用它来评估其模型是否能提供有用、准确的回答，从而支持安全的健康交互。公开该方法论旨在促进透明度，并帮助开发者、研究人员和临床医生构建人们可以信赖的工具。

作者认为，为孤立任务构建的评估方法不足以覆盖通用模型。他们举的例子是一个前生成式AI模型：它能在CT扫描中检测肺癌，却无法在乳腺X光片中检测乳腺癌，也无法将一段对话总结成笔记。当一个模型能够承担数百、数千甚至更多任务时，开发者和医疗机构需要一种方法来对交互和风险进行优先级排序。

在选择测试用例之前，评估者会梳理关键用户旅程：谁在使用系统、他们希望达成什么目标以及涉及哪些步骤。用户可能包括患者、家属、临床医生或管理人员。这一梳理指导代表性测试数据和指标的选取，同时也涵盖预期用途和常见误用形式，包括超适应症依赖以及试图绕过安全过滤器的行为。

随后，每个应用都会在三个维度上接受评估。准确性涵盖医学共识、证据支持、事实性、临床推理和情境适当性，对于医学摘要等任务还会增加来源依据。安全性不仅关注陈述是否正确，还关注当某人解读答案并据此采取行动、或未能采取行动时可能造成的伤害。评估会同时考虑该伤害的严重程度和发生可能性。有用性涉及健康素养、相关性、全面性以及用户能否根据回答采取行动。因此，一个回答可能准确但不安全，也可能既准确又安全，却过于复杂或无法操作而无法帮助用户。

白皮书中的示例展示了主要风险如何随任务而变化。对于自查症状的消费者而言，核心安全关切是未能突出需要紧急就医的危险信号症状；过度危言耸听的回答反而可能造成不必要的焦虑，而含糊不清的自我评估指导则可能妨碍采取适当的后续步骤。对于临床医生由AI起草的出院小结，幻觉、遗漏和事实错误会威胁准确性，遗漏过敏信息或禁忌用药会带来安全隐患，而混乱的格式或不一致的时间线则会降低有用性。

第一种评估方法依赖有确定答案的测试，例如多项选择题，这使得大量基线知识检查的成本相对较低。静态测试无法再现真实交互的复杂性和代表性。数据污染是另一个局限：当测试题目出现在训练数据中时，结果可能反映的是对测试的准备，而非泛化的医学推理能力。因此，该框架使用这些基准来建立基线并确定后续评估目标，同时还需要其他方法来验证真实世界表现。

第二种方法是将评分分配给另一个AI系统。这些自动评分器将书面评分标准应用于开放式回答，使得能够考察的场景数量远超专家评审者所能合理评分的范围。它们可以评估模拟的多轮对话，在这些对话中用户最初隐瞒临床细节，以此测试模型在提供指导前是否会提出澄清性问题。自动评判者仍需对照专家创建的参考数据进行验证，因为它们可能奖励冗长，偏好来自自身模型家族的回复，并传播带有噪声的人工标注。

随后，临床医生和其他领域专家会审查自动评分标准最薄弱的案例，包括复杂表现、边缘案例以及临床共识有限的议题。他们还会判断输出是否符合当地临床规范和不同患者群体的需求。另外，红队测试通过情感恳求、虚构框架或采用医疗专业人员人设等策略来测试安全边界，以诱导模型输出超出产品预期范围的内容。人工复核同样可能出错：作者指出，两名医生在同一评分任务上的差异可达30–40%或更多，因此有必要对评分者变异性进行控制并开展适当分析。

部署后监测持续进行

评估在产品存在之前就已开始，包括测试基础模型的通用能力和安全性。一旦模型被构建到应用中，评估就会针对该产品的用户和工作流程。临近发布时，受控部署可以包括静默影子试验、临床试点或分阶段推出，并在更广泛可用之前进行人因和可用性测试。

在每个产品关口，临床和开发团队必须共同设定通过阈值和评分标准权重，依据应用的临床风险特征，而非通用或任意的数值截断值。部署后，开发者跟踪算法漂移和系统稳定性。采用该技术的机构则针对专业工具监测临床工作流程安全，或针对消费级产品监测用户安全和使​​用模式。

作者指出，用户投诉和哨兵事件等被动信号本身无法承担部署后监测的任务。测试集与真实交互存在差异，而用户会随着经验积累改变其提示词和期望。监测发现必须反馈到需求、培训和后续评估优先级中。对交互和健康结果的长期监测面临数据孤岛以及隐私、技术和组织层面的障碍。该论文还指出，开发者与卫生系统共同承担的责任、实施成本、独立验证和科学共识仍是有待完成的治理工作。

对于开发者和卫生系统而言，该框架将问题从“模型是否通过了静态基准测试”转变为“能否在整个开发和部署过程中证明其准确性、安全性和有用性”。其核心挑战是实践性的：将监测与问责联系起来，同时分配责任、为相关工作提供资金，并跨越组织和数据边界独立验证结果。