1. 医学影像模型版本与发布工程导论

医学影像人工智能模型从论文走向临床，真正困难的往往不是把 Dice 系数提高一两个百分点，而是让一个已经训练好的模型在真实医院环境中可复现、可追溯、可回滚、可审计地运行。一个分割模型在实验室里表现优异，部署到影像科后却可能因为扫描协议变更、层厚差异、重建核不同而性能骤降；一次看似无害的权重更新，可能让原本稳定的肺结节检出率出现波动。版本与发布工程，正是为这类问题提供系统性答案的工程学科。

课程定位：从"训练出模型"到"交付可用的模型"

本课程聚焦医学影像模型全生命周期中"版本管理"与"发布交付"两个关键环节。它不重复讲解网络结构设计或损失函数推导，而是回答一个更贴近工程落地的问题：当模型、数据、预处理代码、推理配置、后处理规则都在持续变化时，如何保证每一次交付给临床的模型都是确定的、可解释的、可追溯的。

可以把一个医学影像模型理解为一个"复合制品"，它至少由以下要素共同决定最终行为：

• 模型权重：网络参数文件，决定核心推理能力；
• 网络结构定义：层数、通道、算子类型，权重必须与结构严格匹配；
• 预处理流水线：窗宽窗位、重采样间距、归一化方式、方向校正；
• 推理配置：输入尺寸、滑窗步长、批大小、混合精度开关；
• 后处理规则：连通域过滤、阈值、形态学操作、坐标还原；
• 运行环境：框架版本、CUDA、算子库、依赖包版本。

其中任何一项变化，都可能改变输出结果。版本工程的核心任务，就是把这些要素绑定成一个不可分割的版本单元，并让这个单元可以被唯一标识、被完整复现。

核心问题：为什么"模型文件"不等于"模型版本"

很多团队初期只用文件名区分模型，例如 model_v2_final_best.pth。这种方式在单人开发时勉强可用，一旦进入多人协作和临床试用就会迅速失效。典型问题包括：

• 同一个权重文件，在不同预处理下输出不同，但文件名无法体现；
• 回滚时只回滚了权重，却忘了回滚配套的后处理阈值；
• 临床反馈某次更新后假阳性增多，但无法定位是哪次数据或配置变更引入；
• 审计要求说明"当前线上模型由哪些数据训练、何时发布、谁批准"，却拿不出记录。

因此，一个合格的模型版本必须同时回答四个问题：它是什么（内容）、它从哪来（血缘）、它怎么跑（配置）、它是否被允许上线（状态）。这四者缺一不可。

工程化发布的价值与挑战

工程化发布的价值体现在三个层面。对研发团队，它把"能跑通"变成"可重复跑通"，减少环境漂移带来的返工；对临床使用方，它保证每次更新都有据可查、可回退，降低风险；对监管与质量体系，它提供完整的变更记录与审批链路，是合规的基础。

挑战同样明显。医学影像数据本身具有强隐私属性，版本库中不能随意存放原始影像；模型文件体积大，动辄数百 MB 到数 GB，普通 Git 仓库难以承载；推理环境涉及 GPU 驱动与算子库，跨机器复现成本高；此外，临床对"稳定"的诉求与算法迭代对"快速"的诉求天然存在张力，发布节奏需要被谨慎设计。

版本单元与发布链路的关系

下图展示了一个医学影像模型从训练产物到临床发布的版本化链路。左侧是构成版本的各类要素，它们被打包为一个带唯一标识的版本单元；中间经过验证与审批，形成发布候选；右侧是不同发布通道与对应的状态标记。图中同时标出了回滚路径，说明发布不是单向终点，而是可逆的状态迁移。

图中可以看到，版本单元是链路的中心：它把分散的要素收敛为一个不可变对象，再经过验证与审批进入发布通道。发布通道并非只有"上线"一条路，灰度、影子模式、临床试用都是降低风险的中间状态。而虚线回滚路径说明，一旦生产环境出现异常，系统应能快速切回上一个已验证版本，而不是临时重新训练。

一个可操作的版本标识示例

为了让版本可被机器解析和人工识别，建议采用语义化标识，并配套一份版本清单。下面给出一个示例结构，字段可根据团队实际调整，但核心是"标识 + 内容 + 血缘 + 状态"四类信息齐全。

{
  "model_id": "mdl-lungseg",
  "version": "1.4.2",
  "artifact_hash": "sha256:9f2c...a71d",
  "weights": "weights/lungseg_1.4.2.onnx",
  "preprocess": {
    "spacing": [1.0, 1.0, 1.0],
    "hu_window": [-1000, 400],
    "orientation": "LPS"
  },
  "inference": {
    "patch_size": [128, 128, 128],
    "stride": [64, 64, 64],
    "threshold": 0.5
  },
  "postprocess": {
    "min_component_voxels": 30,
    "morphology": "closing_r2"
  },
  "lineage": {
    "train_set": "ds-lung-2024q3",
    "train_code_commit": "a1b2c3d",
    "parent_version": "1.4.1"
  },
  "status": "validated",
  "approved_by": "qa-team",
  "approved_at": "2025-03-11T09:20:00+08:00"
}

这份清单的价值在于：任何人拿到 1.4.2 这个标识，都能还原出权重、预处理、推理参数、后处理和训练来源。当临床反馈问题时，可以先用 artifact_hash 确认线上运行的确实是该版本，再对比 parent_version 定位变更范围。示例中的数值均为合理假设，用于说明字段组织方式，不代表任何真实模型的实测结果。

本课程将覆盖的能力主线

围绕上述问题，后续章节会逐步展开：如何设计版本命名与存储策略，如何处理大模型文件与隐私数据，如何构建可复现的推理环境，如何设计发布通道与回滚机制，如何记录审批与审计信息，以及如何在多院区、多设备场景下保持版本一致。每一部分都尽量给出可落地的配置、清单或判断依据，而不是停留在概念层面。

医学影像模型的临床价值，最终取决于它能否被信任。而信任来自稳定、透明和可追溯。版本与发布工程，正是把这种信任从"个人经验"转化为"工程能力"的关键一步。