1. 课程导入与验证工程定位

医学影像AI产品从算法研发走向临床落地，中间横亘着一道常被低估的鸿沟：算法在论文数据集上达到0.95的AUC，并不等于它在真实医院里能稳定支撑诊断决策。性能验证工程正是填补这道鸿沟的工程学科。它的核心目标不是"证明AI很准"，而是用可复现、可追溯、可审计的证据，量化AI系统在目标临床场景下的性能边界与失效风险，并回答三个问题：它在什么条件下可靠？它在什么条件下会出错？出错时后果是否可控？

一、验证工程的核心目标

性能验证工程追求的不是单一指标的高低，而是一组可交付的证据链。具体而言，它要产出四类结论：

• 性能量化：在明确的病例分布、设备条件、扫描协议下，给出灵敏度、特异度、AUC、Dice系数等指标的置信区间，而非点估计。
• 泛化边界：识别模型在跨中心、跨设备、跨人群时的性能衰减幅度，例如某肺结节检测模型在训练中心灵敏度为92%，换到另一品牌CT后降至78%，这个差值本身就是关键结论。
• 失效模式：定位系统性错误，如对磨玻璃结节漏检、对金属伪影区域误报，而非仅报告总体错误率。
• 风险可控性：验证在置信度阈值、人工复核等干预下，系统能否将临床风险压到可接受水平。

二、工程边界：验证工程不做什么

明确边界比罗列职责更重要。性能验证工程不负责算法架构创新、不负责临床有效性最终裁定、不负责产品注册申报的全部合规工作。它处在算法研发与临床评价之间，是一个独立的工程环节。

它与算法研发的关系是：研发关注"如何让模型更准"，验证关注"模型到底有多准、在哪儿不准"。验证团队需要独立于研发团队，使用研发未接触过的锁定测试集，避免信息泄漏。它与临床评价的关系是：临床评价回答"使用AI后患者结局是否改善"，而验证工程回答"AI本身的诊断输出是否可靠"。前者是临床终点，后者是技术性能，二者不可互相替代。

三、任务地图：从数据到结论的验证链

本课程的任务地图可概括为一条从原始数据到验证结论的工程链。下图展示了验证工程的核心结构与各环节的输入输出关系：

四、一个具体的验证场景示例

假设某团队开发了一个脑出血CT分割模型，在内部测试集上Dice为0.91。验证工程的任务不是复述这个数字，而是设计一套评估方案来回答：这个0.91在真实急诊场景下意味着什么？

验证团队会这样操作：首先，从三家医院收集独立数据，按出血类型（脑实质、蛛网膜下腔、硬膜下）和出血体积（<5mL、5-30mL、>30mL）分层。然后，固定模型版本和推理参数，在锁定测试集上运行，计算各亚组的Dice和95%置信区间。假设结果为：脑实质出血Dice 0.89（95%CI 0.86-0.92），蛛网膜下腔出血Dice 0.72（95%CI 0.65-0.79），小体积出血Dice 0.61。此时，总体0.91的乐观印象被打破，验证结论应明确指出：模型对蛛网膜下腔出血和小体积出血的性能显著下降，在急诊筛查场景中需人工重点复核这两类病例。

这个例子说明，验证工程的价值不在于给出一个漂亮数字，而在于把"模型能用"转化为"模型在什么条件下能用、什么条件下不能单独用"。后续章节将围绕数据治理、指标设计、分层评估、失效分析、报告输出等环节逐一展开，每个环节都会给出可操作的方法、参数和判断依据。