AI医疗器械注册审查实操手册（工程团队版）
第五章 核心矛盾与工程落地
这一章不对应原文的某个固定章节，而是把我们在阅读和写作过程中反复遇到的监管理想 vs 工程现实的矛盾拎出来，逐个给出落地策略。
5.1 版本控制：离散审批 vs 连续迭代
矛盾在哪 监管要求每次算法更新都归类为"重大"或"轻微"，重大需申请变更注册，轻微通过质量管理体系控制（第6页）。但现代AI开发是连续迭代：每天都有commit、每周都有数据增量、框架小版本静默升级。监管的二元切分跟工程的连续光谱根本对不上。
审评员的真实担忧 不是怕你更新太频繁，是怕你更新了什么自己都不知道，出了事找不到根因。NMPA的"重大/轻微"本质上是在问：这次更新如果出了问题，影响有多大？你能不能控制住？
工程团队怎么应对
正经方案
- 建立内部"预注册版本"机制：每3-6个月冻结一个候选版本，在此期间的所有迭代在内部走敏捷流程，冻结点后统一打包走变更注册或首次注册。
- 版本号显式区分算法版本和数据版本：
V2.1.0-ALG3-DATA2表示第二次算法迭代+第二次数据迭代。 - 每次候选版本发布前做完整的回归测试：用同一套测试集跑上一个冻结版本和当前候选版本，做McNemar检验确认性能无显著退化。
- 维护一份《版本差异日志》，记录每个commit的变更类型（算法结构/数据/框架/配置）、影响评估、测试结论。
交差版
- 版本号简单分：V1.0（注册版）、V1.1（轻微更新）、V2.0（重大更新）。
- 轻微更新内部评估后走质量管理体系记录，重大更新才申请变更注册。
- 日志写"本次更新仅增加训练数据量500例，算法结构未改变，经评估属于轻微更新"。
核心原则 监管的"离散"和工程的"连续"不可调和，但可以用"定期冻结"做缓冲。关键是让审评员相信：你虽然迭代频繁，但对外发布的每个版本都是经过完整验证的稳定快照。
5.2 数据质控：制药车间思维 vs 算法工程实践
矛盾在哪 文件要求标注场所记录温度、湿度、气压（第13页），但对半自动标注工具的seed、随机数状态、显示参数（CT窗宽窗位）基本没提。这是典型的"人用眼睛看东西所以需要环境稳定"的传统质控逻辑，但算法工程里真正影响复现的是软件版本和随机状态。
审评员的真实担忧 审评员不一定懂seed，但他懂"复现"。如果重新标一遍结果不一样，你的模型还可靠吗？温度湿度是传统经验里"确保复现"的代理变量，虽然粗糙，但至少能检查。
工程团队怎么应对
正经方案
- 温度湿度照测照记，附照片。这是给审评员的"合规信号"，成本低，别硬杠。
- 在标注操作规范里强制要求记录：
- 标注软件完整版本号
- 操作系统版本和显示器型号
- 半自动标注工具的seed和随机数状态
- 当前影像的显示参数（窗宽窗位）
- 标注protocol版本号
- 建立标注环境的标准化镜像：用Docker或虚拟机固化标注软件环境，确保不同时间、不同机器上打开的是同一套软件配置。
交差版
- 温湿度抄空调面板。
- seed和软件版本记在Excel备注栏。
- 写"标注环境已标准化，确保不同批次标注结果的一致性"。
核心原则 不要跟监管争辩"温度湿度没用"。把它当成入场券，真正的复现保障靠seed和版本控制。两张牌一起打，既合规又工程。
5.3 样本分布：均衡性 vs 真实性
矛盾在哪 文件要求"训练集原则上需保证样本分布具有均衡性，测试集、调优集原则上需保证样本分布符合真实情况"（第15页）。但在真实世界里，疾病本身就是偏态分布的。强行均衡训练集会让模型学到错误的先验，测试集保持真实又会导致某些类别样本极少、评估不准。
审评员的真实担忧 审评员怕你在训练集上"作弊"——把罕见病样本over-sample到和常见病一样多，模型在训练集上表现很好，但到真实医院一部署就崩。
工程团队怎么应对
正经方案
- 训练集保留真实分布，用类别权重（class weight）或 focal loss 处理类别不均衡，而不是人为oversample。
- 对训练集做离线扩增时，按类别分别记录扩增倍数，确保模型见过的每类样本总量接近，但原始样本分布仍如实记录。
- 测试集绝对不动，保持真实世界base rate。对于样本量过少的亚组，在报告中写明"该亚组测试样本仅XX例，评估结果置信区间较宽，后续将补充数据"。
- 提供"分层性能报告"：按样本量充足的类别分别报告指标，对样本量不足的类别标注"数据有限，结果仅供参考"。
交差版
- 训练集稍微做点扩增让各类别太悬殊（比如从1:100拉到1:10）。
- 测试集原封不动。
- 报告里写"训练集经适度扩增以平衡类别分布，测试集保持真实流行病学分布"。
核心原则 测试集是底线，绝对不能动。训练集怎么折腾是你的工程自由，但必须在报告里说清楚原始分布和处理方法，让审评员自己判断有没有过度操作。
5.4 安全级别判定：多维模糊 vs 落地需求
矛盾在哪 文件要求从预期用途、使用场景、核心功能"综合判定"软件安全性级别（第8页），但每个维度都是定性的，没有打分标准和权重。结果是企业自己说自己是"轻微"，审评员可能认为是"中等"，来回扯皮。
审评员的真实担忧 级别定低了，后续质控要求跟不上去，出了问题谁负责？所以审评员倾向于保守判定——拿不准就按高的来。
工程团队怎么应对
正经方案
- 不要自己拍脑袋定级别。先找同类已上市产品的注册信息（NMPA官网可查），看人家怎么定的。
- 准备一份《安全性级别判定论证报告》，逐条回应文件的判定维度：
- 预期用途：辅助决策 vs 非辅助决策（附定义和参考文献）
- 使用场景：门诊筛查 vs 急诊抢救（附场景描述和风险分析）
- 核心功能：是否直接影响治疗决策（附功能流程图）
- 参考FDA SaMD框架的二维矩阵，作为辅助论证
- 如果跟已上市同类产品一致，写明"参照XX产品（注册证号：国械注准20XXXXXXXX），其软件安全性级别为X级，本产品风险特征与之实质等同"。
交差版
- 直接按中等级别准备材料，轻微级别的简化好处不值得冒被退审的风险。
- 如果确实是非辅助决策的简单工具，写一页论证说明为什么风险较低。
核心原则 安全性级别判定的权力在审评员手里，不在你手里。你的目标是提供足够的证据让审评员容易接受你的判定，而不是说服他你是对的。
5.5 可追溯性：医疗器械QMS vs 敏捷开发
矛盾在哪 文件要求提供"算法需求、算法设计、源代码、算法测试、算法风险管理的关系表"（第32页）。这对传统软件是标准操作，但对AI团队来说是噩梦：需求每天都在变，模型结构实验了二十种才定下来，超参数调了上百组，怎么追溯？
审评员的真实担忧 审评员默认AI团队是"野路子"——没有文档、没有流程、没有版本控制。可追溯性分析是逼你证明：你虽然用了新技术，但管理上是正规的。
工程团队怎么应对
正经方案
- 采用"敏捷+QMS混合模式"：
- 开发阶段走敏捷：快速迭代、实验各种模型结构、调参
- 冻结阶段走QMS：选定候选模型后，补写需求规范、设计文档、测试用例，建立追溯链
- 追溯链只覆盖"候选版本"，不覆盖探索阶段的全部实验
- 用ALM工具（Jira、Polarion、Jama）或低成本替代（GitHub Issues + commit message约定）建立需求-代码-测试的自动关联。
- 风险管理用FMEA方法，在需求阶段就识别风险，后续设计、测试环节对应控制措施。
交差版
- 探索阶段随便折腾，不留文档。
- 确定要注册的版本后，花一周时间补需求规范、设计说明、测试报告。
- 可追溯性表格只填最终版本的关键需求（10-20条），不追溯实验过程。
核心原则 追溯不是要你记录每一次失败的实验，是要你证明"最终交付的版本是有意识的选择，不是拍脑袋的结果"。探索阶段的混沌可以接受，但交付阶段必须有序。
5.6 数据集资产化：公开数据库的边界与机会
矛盾在哪 文件规定"公开数据库因不具备封闭性而不能用作测评数据库"（第23页），但可以用于算法性能评估。这个模糊的边界让很多团队困惑：我可以用ImageNet预训练吗？可以用公开竞赛数据集做对比吗？我自己的数据集将来能不能卖？
审评员的真实担忧 审评员怕你用公开数据库"刷分"——提前看过测试集、针对公开数据集调过参，然后声称模型很牛。他也怕你的数据来源不合法（没伦理批件）。
工程团队怎么应对
正经方案
- 预训练权重：可以使用ImageNet、MoCo等公开预训练权重，但需在报告中写明：
- 预训练数据来源和规模
- 预训练任务与目标任务的差异
- 微调策略（冻结层数、学习率、epoch数）
- 预训练数据的伦理状态（ImageNet没问题，医疗数据集需确认）
- 公开数据库用于性能对比：在报告中单独一节写"公开数据库性能对比"，明确说明"仅用于横向参考，不作为安全有效性评价依据"。
- 自建数据集保护：训练过程中保留数据血缘记录（每个样本从哪来、谁标的、哪版protocol），为未来数据集授权或交易做准备。数据集本身可以考虑申请软件著作权或作为商业秘密保护。
交差版
- 预训练写"采用基于ImageNet的公开预训练权重，在自有数据集上微调"。
- 公开数据库对比写"在XX公开数据集上进行算法性能对比，结果仅供参考"。
核心原则 公开数据库是"外部参考"，不是"内部证据"。能用，但要明确区分它的角色。数据集作为资产的价值正在被监管文件变相抬高——谁有高质量、合规的医学数据集，谁就有壁垒。
5.7 框架更新：效率型 vs 非效率型的灰色地带
矛盾在哪 文件要求算法框架更新需区分"效率型"和"非效率型"，前者算轻微更新，后者算重大更新（第28页）。但现代框架升级往往伴随数值精度变化、API变动、算子实现差异，很难严格区分。
审评员的真实担忧 审评员怕你以为"只是升级了一下PyTorch版本"，结果模型输出偷偷变了，造成临床风险。他需要你证明：升级前后，输出是一致的（或至少变化在可控范围内）。
工程团队怎么应对
正经方案
- 框架升级前做"输出一致性测试"：用同一批测试样本，分别跑旧框架和新框架，比较输出概率（分类）或mask（分割）的分布差异。
- 分类任务：计算KL散度或输出概率的相关系数
- 分割任务：计算IoU变化
- 若差异<0.1%且临床意义可忽略，论证为效率型更新
- 保留旧框架的Docker镜像作为基准，新框架跑通后必须通过与旧框架的diff测试。
- 若框架升级伴随模型重训（如PyTorch 2.0的compile模式需要重新导出），按重大更新处理。
交差版
- 小版本升级（如PyTorch 1.12→1.13）且只改bug的，写"经测试，输出结果一致，属于效率型更新"。
- 大版本升级（如1.x→2.x）或不确定的，直接按重大更新走。
核心原则 效率型 vs 非效率型的判定标准不是"你觉得有没有改算法"，而是"输出变了没有"。用数据说话，别凭感觉。
5.8 持续学习：监管的"暂停键"与工程的现实
矛盾在哪 文件对持续学习/自适应学习的态度很明确：“自学习功能在当前法律法规体系下应关闭或虽开放但不得投入使用”（第27页）。但真实世界里，模型上线后面对的数据分布会漂移（covariate shift），理想情况下确实需要定期更新。
审评员的真实担忧 审评员怕的是"失控更新"——模型在医院里偷偷学了三个月，性能变好还是变坏都不知道，出了事找不到责任人。
工程团队怎么应对
正经方案
- 注册时明确关闭所有在线学习功能，模型权重冻结。
- 建立"离线重训+变更注册"的更新节奏：每6-12个月收集新数据，离线重训模型，走变更注册流程后替换线上版本。
- 若产品需要"热更新"能力（如联邦学习场景），在注册时提交《预先确定的变更控制计划》（借鉴FDA的Predetermined Change Control Plan思路），把未来允许的更新类型、边界条件、验证方法写清楚，获得预授权后可在框内自主更新。
交差版
- 写"本产品未启用自适应学习功能，模型权重固定不变"。
- 后续更新按"新增训练数据"或"算法优化"走变更注册。
**核心原则" 监管对持续学习按下暂停键，不是因为技术不行，是因为责任链还没理清。在现有的法律框架下，“冻结+定期离线更新"是唯一安全的落地方式。
5.9 回滚机制：从"写了就行"到"真的能回”
矛盾在哪 文件要求"算法更新、软件更新均需考虑引入回滚机制"（第19页），但AI的回滚比传统软件复杂得多：模型权重、数据预处理pipeline、训练环境（框架版本、CUDA版本、依赖库）三者必须同步回滚，任何一个对不上都会导致输出漂移。
审评员的真实担忧 审评员怕你嘴上写"支持回滚"，实际出了事发现回滚后模型跑不起来——因为PyTorch版本已经升级了，老权重不兼容。
工程团队怎么应对
正经方案
- 三维版本控制：
- 模型版本：每次训练保存checkpoint，至少保留最近3个稳定版本
- 数据版本：数据预处理脚本进git，每个注册版本对应一个git tag
- 环境版本：训练环境打包成Docker镜像，镜像ID写入版本日志
- 定期做回滚演练：每季度模拟一次"从最新版本回退到上一版本"的完整流程，记录回滚时间（RTO）和数据丢失量（RPO）。
- 线上部署时保留"蓝绿部署"能力：新版本上线后，旧版本保持 warm standby 至少48小时，确认无异常后才下线。
交差版
- 写"保留最近3个模型版本，支持一键回退"。
- 定期备份模型权重和配置文件。
**核心原则" 回滚机制的价值不在于"能不能回"，而在于"回完之后结果和原来一样"。只有Docker镜像能确保这一点，单纯备份权重文件是不够的。
5.10 算法文档：从"画示意图"到"交得了差"
矛盾在哪 文件要求提供算法流程图、算法结构说明（第29页），但AI工程师的日常工作不涉及画Visio图。很多团队被要求补材料时，临时画几张框图应付，既不好看也不准确。
审评员的真实担忧 审评员看流程图不是想知道你用了几层卷积，是想确认你的数据处理链路是完整的：输入有没有校验？异常数据有没有处理？输出有没有后处理？有没有反馈闭环？
工程团队怎么应对
正经方案
- 算法流程图标准化模板：
- 输入层：数据来源、格式校验、预处理步骤
- 推理层：模型结构（粗粒度，不用画每层细节）、推理引擎、硬件加速
- 输出层：结果格式化、置信度阈值、后处理（NMS、连通域分析）
- 反馈层：结果存储、日志记录、异常上报
- 用工具生成：Netron导出ONNX模型结构图、TensorBoard可视化计算图、或用draw.io画标准模板后复用。
- 算法结构说明表：列层名称、输入尺寸、输出尺寸、参数量、激活函数，不用贴代码。
交差版
- 画三个框：输入 → 深度学习模型 → 输出。
- 写"基于深度卷积神经网络，具体结构详见附件代码"。
核心原则 算法文档是给非AI背景的审评员看的。他不需要理解Transformer的注意力机制，他需要确认你的系统有没有明显的结构性漏洞（比如没有输入校验就直接进模型）。流程图的价值在"完整"不在"精细"。