AI医学影像真正改变的不是判读本身而是科研工作流开始前移做医学影像科研原型时耗时的不一定是模型训练而是 DICOM 整理、预处理复用、标注版本管理、实验记录和结果回写。本文只讨论技术架构和工程流程示例不提供诊断、治疗、分诊或用药建议涉及自动标注、质量检查和升级规则的部分都应视为示例规则真实项目必须由医疗专业人员和机构规范确认。问题背景模型还没跑数据已经乱了我见过不少影像科研项目卡在同一类问题上同一批 DICOM 被复制到多个目录窗宽窗位、spacing、裁剪范围各自写在脚本里3D Slicer 里改过的标注没有统一版本号训练结果也无法回写到研究者熟悉的查看环境。这会带来三个直接后果实验难复现训练集到底用了哪个预处理版本说不清。标注难协作自动标注结果、人工修订结果、最终训练标签混在一起。工具链割裂MONAI、3D Slicer、后端任务队列各自运行缺少统一状态流转。本文给出一个端到端原型FastAPI 接收数据任务Celery 调度预处理和推理MONAI 完成训练或批量推理3D Slicer 负责人工校正与结果查看Redis 维护任务状态。技术目标与边界这个原型服务于科研流程不用于临床实时决策。目标不是替代人工判读而是把科研准备环节前移数据接入时就完成结构化、可追踪、可复用的处理。核心目标包括DICOM 接入后生成统一 study、series、sample 记录。预处理参数集中管理避免脚本散落。自动标注作为 pre-label等待人工确认。每次实验绑定数据版本、代码版本和模型版本。推理结果可导出为 3D Slicer 可读格式便于回看和修订。一个简化流程如下DICOM接入元数据索引预处理任务MONAI训练或推理自动标注结果3D Slicer人工修订版本化标签库实验复现与结果回写端到端架构拆分工程上建议把流程拆成四层。第一层是数据接入层。它只负责接收 DICOM、抽取必要元数据、计算文件哈希并写入索引库。不要在上传接口里直接做重采样或模型推理否则接口会变慢也不利于失败重试。第二层是异步任务层。Celery 负责把预处理、推理、格式转换放到后台执行Redis 存任务状态。这里要保证任务幂等例如同一个 sample_id 和 preprocess_version 已经生成过结果就不要重复覆盖。第三层是算法层。MONAI 负责 transform、dataset、训练和 inferer。科研团队经常调整 transform建议把参数写成 YAML 或数据库配置而不是散落在 notebook 中。第四层是交互层。3D Slicer 用来查看原始影像、自动标注和人工修订结果。自动标注不要直接进入最终标签库应进入待确认区。FastAPI Celery把任务状态先管起来下面是一个最小可运行的任务入口示例。真实项目中应把 DICOM 存储、权限、脱敏和审计补齐这里只演示任务编排。# app.pyfromfastapiimportFastAPIfrompydanticimportBaseModelfromceleryimportCeleryimporthashlibimportos appFastAPI(titlemedical-imaging-research-workflow)celery_appCelery(imaging_tasks,brokerredis://localhost:6379/0,backendredis://localhost:6379/1)classIngestRequest(BaseModel):sample_id:strdicom_dir:strpreprocess_version:strv1_spacing_1mmdefdir_hash(path:str)-str:hhashlib.sha256()forroot,_,filesinos.walk(path):fornameinsorted(files):file_pathos.path.join(root,name)h.update(file_path.encode())h.update(str(os.path.getsize(file_path)).encode())returnh.hexdigest()app.post(/research/imaging/ingest)defingest(req:IngestRequest):data_fingerprintdir_hash(req.dicom_dir)taskpreprocess_and_infer.delay(req.sample_id,req.dicom_dir,req.preprocess_version,data_fingerprint)return{sample_id:req.sample_id,task_id:task.id,data_fingerprint:data_fingerprint,status:queued}celery_app.task(namepreprocess_and_infer)defpreprocess_and_infer(sample_id,dicom_dir,preprocess_version,data_fingerprint):# 示例实际项目中这里应调用 DICOM 转换、MONAI transform、推理和结果导出output_dirf/data/research_outputs/{sample_id}/{preprocess_version}os.makedirs(output_dir,exist_okTrue)result{sample_id:sample_id,dicom_dir:dicom_dir,preprocess_version:preprocess_version,data_fingerprint:data_fingerprint,output_dir:output_dir,label_status:pre_label_waiting_review}returnresult启动方式pipinstallfastapi uvicorn celery redis pydantic redis-server celery-Aapp.celery_app worker--loglevelINFO uvicorn app:app--reload这个接口看起来很简单但它解决了一个关键问题从数据进入系统开始就给每次处理绑定 sample_id、preprocess_version 和 data_fingerprint。后面无论是训练失败、人工修订还是结果回写都能追踪到来源。MONAI 预处理参数要版本化MONAI 的 transform 很灵活但科研协作中最容易失控的也是 transform。建议把 spacing、resize、intensity normalize 等参数单独版本化。示例配置可以写成这样preprocess_version:v1_spacing_1mmspacing:pixdim:[1.0,1.0,1.0]intensity:normalize:trueclip_min:-1000clip_max:1000export:format:niftislicer_review:true注意这里的数值只是工程示例不表示任何通用医学规则。不同设备、部位、研究任务和机构规范都可能要求不同配置必须由项目负责人确认。MONAI 训练脚本中不要硬编码这些参数而应读取配置并写入实验记录。最少要记录数据指纹预处理版本标签版本训练代码提交号模型权重路径推理输出路径3D Slicer 回写自动标注只做待确认结果自动标注结果建议导出为 3D Slicer 可加载的 NIfTI、NRRD 或 segmentation 文件。人工修订后再生成新的 label_version例如label_v2_reviewer_a_20260512。一个常见目录结构如下/data/project_x/ raw_dicom/ index/ preprocessed/ sample_001/v1_spacing_1mm/image.nii.gz prelabels/ sample_001/model_20260512/pre_label.nii.gz reviewed_labels/ sample_001/label_v2_reviewer_a_20260512.nii.gz experiments/ exp_20260512_monai_unet/config.yaml exp_20260512_monai_unet/metrics.json这里最重要的是区分prelabels和reviewed_labels。前者是模型输出后者是经确认后的科研标签。不要让训练脚本默认读取最新文件否则一次人工修订就可能让历史实验无法复现。踩坑记录比模型更容易出问题的地方第一DICOM 序列选择要显式记录。一个 study 下可能有多个 series不能只按目录顺序读取。建议保存 series_uid、modality、instance_count 等字段。第二预处理输出不要覆盖。即使参数只改了一个 spacing也应该生成新的 preprocess_version。第三异步任务要支持重试和跳过。DICOM 文件缺失、转换失败、磁盘空间不足都很常见任务状态需要区分failed、retrying、skipped。第四自动标注结果不要直接合并到训练标签。可以把它作为 3D Slicer 的初始参考层由研究人员修订后再进入标签库。第五性能数据要按本地环境记录。比如单个样本预处理耗时、GPU 推理耗时、导出耗时都应随实验保存而不是只保存最终指标。取舍分析为什么把工作流前移把接入、预处理、标注流转和结果回写前移会增加一些工程复杂度例如需要维护任务队列、版本目录和配置管理。但它换来的是可复现性当实验结果异常时团队能定位到数据版本、预处理参数、标签来源和模型版本。对于科研工具开发者这类架构的价值不在于让某个模型指标立刻提高而在于减少重复劳动。数据一旦进入统一流程后续训练、推理、人工修订、复盘都可以复用同一套状态机。总结与下一步AI 医学影像项目落地时算法只是链路中的一环。更值得提前设计的是 DICOM 接入、预处理版本化、自动标注待确认、3D Slicer 回写和实验记录。下一步可以继续补齐三件事第一增加数据库表结构管理 sample、series、label 和 experiment第二接入对象存储保存大文件第三把 MONAI 训练配置、模型权重和推理结果纳入统一实验追踪。这样团队讨论模型效果时才能回到同一份可复现的工程事实。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。