医疗多模态大模型训练实战：从数据工程到模型微调全攻略

1. 项目概述

1.1 核心需求解析

这个项目源于一次内部讨论：我们需要构建一个能同时理解医学影像和临床文本的模型，用于辅助医生做诊断决策、生成影像报告、以及回答患者咨询。在模型规模上，团队内部有一个明确的倾向——32B参数级别。为什么是32B？因为在2024年末这个节点，32B某种程度上是个平衡点：显存需求相对可控（用A100或H100可以做全参数微调，消费级硬件也能通过量化跑LoRA），性能又明显强于7B/14B级别的中小模型，在中文医疗领域的任务上能给出更可靠的结果。

“多模态医疗模型”这个提法包含两个核心点：第一是模态融合，我们不光要让模型看懂CT片子或者皮肤照片，还要让它结合病历文本、检验报告来做综合判断；第二是医疗领域的泛化能力，模型要能理解解剖位置、疾病名称、药物信息、手术方式这些专业概念，而不是简单地把图像映射到几个固定的疾病标签上。

从实际落地角度，这个模型要服务三个场景：

• 影像报告生成：输入CT/MRI图像，输出结构化的诊断描述
• 临床辅助问答：医生提问“这个病人的肺部结节需要随访还是手术？”，模型结合影像和病历给出建议
• 多模态检索：用自然语言在影像库中检索相似病例（这是后续加的需求，但影响训练数据的构建方式）

这篇文章先讲上半程，也就是从需求梳理到数据准备、模型选型和训练方案设计的过程，下一个部分再讲训练过程中的具体问题和调优细节。

1.2 技术路线与整体架构

很多人看到“训练一个大模型”就上来想直接下载权重、拼显存、跑训练脚本，这个路径在纯开源模型上可行，但在医疗领域走不通。原因很简单：通用基座模型在医学知识上的表现远不够用，你必须做领域适配。

我们的整体技术路线分四层：

1. 基座模型：选择支持图像和文本联合输入的开源多模态模型，我们在Qwen2-VL-7B和Qwen2.5-VL-7B之间做了长时间评估，最终选定了Qwen2.5-VL-7B作为基座，后续分布式扩展时升级到32B版本作对照实验

2. 数据层：医学影像数据（CT、MRI、X光、病理切片） + 医学文本数据（病历、报告、文献、指南），经过清洗去重、脱敏、结构化解析后，形成图像-文本对训练集

3. 训练层：两阶段策略——第一阶段用大规模医学图像-文本对做视觉语言预训练适配；第二阶段用任务特定的指令数据做监督微调，再配合RLHF类偏好对齐

4. 评估层：构建医学领域的专项评测集，覆盖分类、描述、推理、问答等多个子任务，不做量化指标对比就没有说服力

这四层是递进关系，每一层的问题都要在前一层解决，尽量不要跨层打补丁。

2. 数据工程：医疗模型训练的命门

2.1 数据来源与采集策略

医疗模型的数据获取和通用领域完全不是一个量级。通用模型可以用Common Crawl几亿网页随便筛，但医学影像数据受隐私保护、标注成本高、类目分布不均衡等因素制约，采集难度非常大。

我们实际用了三类数据源：

第一类是公开数据集。 这类数据集质量参差不齐，但作为冷启动是必需的。比如：

• 胸部X光：ChestX-ray14有超过10万张胸部X光片和14种疾病标签，虽然标签噪声不小，但胜在量大
• 皮肤病变：ISIC数据集（国际皮肤成像协作组），包含数万张皮肤镜图像，标注了良恶性
• 病理切片：TCGA（癌症基因组图谱），虽然以数据下载受限著称，但部分子集可用
• 医学影像分割：nnU-Net生态下的各种挑战赛数据集（LiTS肝脏、BraTS脑肿瘤等）

这些公开数据解决一个问题：让模型“见过”医学图像长什么样，学会基础的视觉特征——边缘、纹理、组织密度分布等。

第二类是合作医院的脱敏临床数据。 这是模型达到可用水平的关键。我们和两家三甲医院签了合作协议，拿到脱敏后的CT影像和对应报告文本。需要注意，脱敏不只是去掉姓名和ID那么简单，还包括：影像DICOM头文件里的患者姓名、年龄、设备型号等元信息，以及报告中可能出现的医生姓名、科室名称、住院号等。这些细节漏掉一个就出大问题。

第三类是合成数据。 针对一些公开数据不足的场景（比如罕见病、特定造影剂过敏反应），我们尝试用生成模型构造一些合成影像样本。坦白说，合成数据在医疗领域只能作为数据增强的补充手段，不能作为核心训练数据——即使最逼真的合成影像，和真实病例仍有分布差异（domain shift），模型可能会学到不真实的纹理特征。

从数据量上看，最终用于预训练适配的图像-文本对大约有80万对，其中公开数据占60%，临床脱敏数据占30%，合成增强数据占10%；指令微调阶段用的是约15万条人工构造和半自动生成的指令数据。

2.2 数据清洗与结构化处理

医疗数据的清洗比通用文本清洗复杂得多。通用文本清理HTML标签、去重、过滤低质量内容就够了，医疗文本还要面对几个特有难题：

术语归一化。 同一个概念在报告里可能有多种写法。比如“肺腺癌”“肺腺Ca”“腺癌（肺）”指的是同一个东西，“右肺上叶”和“右上肺”也是同一个位置。我们维护了一个医学同义词表，结合规则匹配和embedding相似度做归一化。这个环节必须有临床医生参与审核，否则同义词表会引入错误映射。

影像和报告的配对质量。 从医院拿到的影像和报告，并不总是“这一张图对应这一段文字”。一份CT报告可能对应几十张序列帧，而关键病灶只在其中几帧上表现。我们的做法是：和放射科医生一起制定配对规则——选取病灶层面图像和报告的关键描述段做配对，而不是把整份报告和所有帧做配对，否则模型学到的关联关系会被大量无关信息稀释。

报告文本清洗。 影像报告有固定的书写格式，通常包括“影像所见”和“影像诊断”两部分，其中“影像诊断”部分还分主要诊断和次要诊断。我们用正则加规则模板把这两部分拆开，并将诊断结论从自然语言转成结构化的“疾病-部位-程度-建议”四元组。这个结构化的好处是后续构造指令数据时，可以自动生成大量QA对，不用纯靠人工写。

清洗完之后的数据长什么样？举一个典型样本：

code复制{
  "image": "chest_ct/patient_00321/slice_0142.png",
  "text": "右肺上叶后段见磨玻璃密度结节，大小约1.2cm×0.9cm，边界清楚，可见浅分叶。患者无吸烟史。",
  "diagnosis": "右肺上叶磨玻璃结节，建议3-6个月随访复查。"
}

2.3 医疗数据标注的实战经验

标注是医疗数据工程里最耗时、最容易出错的环节，也是外行最容易低估的部分。我分享一下我们踩过的坑和调整后的方案。

标注者结构。 刚开始我们想一步到位用高年资医生做全部标注，目标是高质量，但发现成本完全无法接受——一位三甲医院主治医生的时间成本非常昂贵，标注一张CT图像序列的病灶位置和描述通常需要15到30分钟。后来我们调整了策略，采用三级结构：

• 初级标注团队（医学背景研究生）：完成初步标注，包括定位病灶、勾画区域、填写结构化表格
• 中级审核（住院医师级别）：审核初标结果，修正不明确的边界和描述
• 终审（主治及以上）：主要抽查和高难度病例，不全员复核

这个结构可以把成本降低60%以上，质量靠交叉验证（两名初级标同一张图的同意率）来监控。

标注工具。 医疗图像标注对工具要求比较高——你要能直接读DICOM格式，能调整窗宽窗位，能切换序列，还要支持多边形、画笔、阈值分割等多种标注方式。我们对比过几个方案：

我们用了一个组合方案：DICOM序列预处理转成PNG后用自研Web平台标注，保留一个3D Slicer通道处理需要精细分割的病例。具体来说，写了个脚本，用pydicom库读取DICOM序列，根据窗宽窗位转成8位PNG，再配合Overlay工具叠加标注结果，导出时同时保存标注坐标和原图像元数据。这个流程虽然有点绕，但适配了团队协作和审核的需求。

标注一致性问题。 医疗标注最大的坑是标注者之间存在较大的主观差异。同一张CT图，不同医生对“肺气肿”的边界界定可能相差很多。我们引入了一个一致性指标：每批次随机抽取10%的图像由两人独立标注，计算IoU（交并比），把IoU低于0.7的批次退回重标。这个机制简单有效，但也导致了一些批次反复返工。实践中建议在项目启动前就花一周时间做标注规范培训，把边界定义、命名约定、覆盖范围都明确写下来，比事后返工划算得多。

2.4 基于nnU-Net辅助的自动标注流水线

这里要具体讲一个我们用的自动标注技巧，也是热词里提到“nnU-Net训练自己的数据集”的实际应用。

nnU-Net是一套自动适配数据集的医学图像分割框架，在多个医学分割挑战赛里拿了冠军。它最大的价值是：你给它一套标准格式的数据集，它会自动配置网络架构、预处理方案、训练策略，不需要你手动调参。

我们的思路是：先人工标注约300例涵盖主要病灶类型的影像作为nnU-Net的种子训练集，训练出一个初版分割模型，然后用这个模型对剩下的图像做预标注（AI给出候选分割区域），最后由人工对预标注结果进行修正而不是从零开始画。

这个流程高效的核心在于：医生修正一个AI给的初步框，比从空白图像上手动画出边界快得多。实际效果上，对于肝脏、肺结节、肾脏这类边界相对清晰的器官，nnU-Net预标注的准确率能达到80%以上；但对于边界模糊的病灶（比如部分磨玻璃影）或者解剖结构变异的病例，还是需要人工大幅修正。

具体使用nnU-Net的经验：

bash复制# 数据集目录结构（nnUNet标准格式）
nnUNet_raw/nnUNet_raw_data/Task01_LungNodule/
├── imagesTr/          # 训练图像，命名格式：case_XXXX_0000.nii.gz
├── labelsTr/          # 训练标签，命名格式：case_XXXX.nii.gz
├── imagesTs/          # 测试图像
└── dataset.json       # 数据集配置文件

# 预处理
nnUNet_plan_and_preprocess -t 1 -pl3d None -pl2d None

# 训练（使用5折交叉验证和集成推断）
nnUNet_train 3d_fullres nnUNetTrainerV2 1 0
nnUNet_train 3d_fullres nnUNetTrainerV2 1 1

需要注意：nnU-Net对数据格式要求比较严格，特别是文件命名和后缀名（.nii.gz），以及所有图像和标签的空间尺寸一致性。我们刚开始直接在原始DICOM上跑，报了一堆错，后来用NiBabel统一转成NIfTI格式才解决。

3. 模型选型：为什么不从零训练，为什么要Qwen2.5-VL

3.1 基座模型评估与选型

医疗模型的训练路线，业界基本已经收敛到“在开源通用基座模型上做领域微调/继续预训练”，而不是从头训练。从头训练一个32B多模态模型需要数万张GPU小时、海量数据、以及雄厚的技术团队储备，对绝大多数团队来说既不现实也没有必要——已有开源基座模型的基础能力远超团队自己从零训练的产出。

在具体基座选型上，我们在2024年第四季度比对了三个候选：

最终选了Qwen2.5-VL-7B，原因如下：

• Qwen2.5-VL在视觉编码上做了优化，对高分辨率图像和视频/长序列有更好的支持。医学图像（尤其病理切片）分辨率非常高，有些是几千乘几千像素，Qwen2.5-VL原生支持了任意分辨率输入，这个特性对医学影像非常关键
• 中文能力上，Qwen系列本身就是中文社区里最强的开源模型之一，医疗领域涉及大量中文专有名词和表达习惯
• 响应格式上对JSON输出的支持比较好，方便我们后续做结构化的报告生成

那标题里的“32B”是怎么回事？这里要解释一下我们的路线：先用7B级别模型做路线验证和数据处理验证，确认方案可行并且损失曲线正常后，再用同一套数据管线扩展到32B模型做正式训练。这也是很多团队的实际做法——直接上32B，发现数据有问题或训练脚本有bug，调试成本会成倍上升。

具体的32B版本，我们用的是Qwen2.5-VL-32B（在内部预览阶段通过合作渠道获取的测试权重），用相同的训练脚本和超参配置做对照实验，验证数据和技术方案的规模扩展性。

3.2 训练方式选择：LoRA还是全参数微调

这里直接说结论：我们的方案是混合模式——预训练适配阶段用全参数微调（small LR, short steps），任务对齐阶段用LoRA。

先解释为什么不全用LoRA。LoRA通过低秩分解把更新的参数压缩到很小的子空间里，对于输入输出分布接近的领域微调效果很好。但医疗领域的视觉特征和通用图像的差异比大多数人以为的大得多——CT图像的HU值分布、病理切片的染色差异、超声图像的低信噪比和伪影模式，这些是通用视觉编码器没有见过的。仅用LoRA只调整投影矩阵，视觉主干里的底层特征可能没被充分适配，导致“画虎不成反类犬”，语义理解偏差。

我们的策略是：

• 阶段一（领域预训练适配）：用80万医学图像-文本对整体继续预训练，采用全参数微调，学习率设为普通微调的1/5到1/10，只训练1个epoch。这个阶段的目的不是学新知识，而是把模型的视觉分布从自然场景拉向医学影像分布
• 阶段二（任务指令微调）：用15万条任务指令数据做LoRA微调，rank设64，alpha设128。这个阶段让模型学会具体任务的输入输出格式——如何根据CT图像生成诊断描述、如何回答医生的问题

这个两阶段方案在效果和成本之间取得了较好平衡。实测数据显示：相比直接只用LoRA做端到端微调，这个方案在医学影像描述生成任务上的BLEU和ROUGE分数提高约15-20%，在医学QA任务上的准确率提高约8-10%，模型幻觉率下降也很明显。

关于LoRA训练的具体操作，这里补充一些细节。我们在调试基于Qwen2-VL做图片到文本生成的代码时踩了不少坑，核心要点包括：

python复制# LoRA配置示例（基于PEFT库）
from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=64,                          # 秩
    lora_alpha=128,                # 缩放系数
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

# 注意：要让视觉编码器的一部分也可训练，否则图像特征适配会失败
# 常见做法：解冻视觉encoder的最后几层
for param in model.visual.parameters():
    param.requires_grad = False
for param in model.visual.encoder.layers[-4:].parameters():
    param.requires_grad = True

这里有个细节容易被忽视：默认LoRA只作用于语言模型部分，视觉编码器参数被冻结了。但医学图像的特征分布和自然图像差异较大，如果不解冻部分视觉层，无论你怎么调LoRA参数，模型始终“看不清”医学图像。我们必须至少解冻视觉编码器的部分层让它们参与梯度更新。

另外，训练时要注意学习率不要太大。很多初学者会直接用默认的1e-4或甚至1e-3学习率训练LoRA，这会导致灾难性遗忘——模型像新学了一遍聊天，把原本的医学知识全覆盖了。推荐先从1e-5左右开始，用一个小测试集监控医学任务的表现，如果损失下降但医学准确率也在下降，说明学习率偏高了，要及时调低或用层间差分学习率。

3.3 硬件环境与分布式训练配置

32B模型的全参数训练和7B完全不是一个量级。这里需要仔细算一笔账。

显存需求计算：

• 32B参数，BF16精度（2字节每参数），模型权重就占了64GB
• Adam优化器需要保存梯度、一阶动量、二阶动量：32B × 4字节 × 2 = 256GB（因为一阶二阶动量是FP32精度的）
• 加上激活值、CUDA context等开销，单卡至少128GB的GPU才可能部署推理，训练需要更大

于是我们用了DeepSpeed ZeRO Stage 3 + 多节点的方案。实际配置是8卡H800（80GB），分布式训练。ZeRO Stage 3会把优化器状态和梯度切分到所有GPU上，每张卡大概需要存1/8的优化器状态，这样算下来勉强够跑32B在有条件时（配合激活值检查点激活值重算）进行全参数微调。

如果你没有8卡H800/H100的配置，更现实的路线是：用4卡A100（80GB）×2节点，配合DeepSpeed Stage 3，并开启CPU offload。或者干脆用QLoRA——把基座模型量化到4-bit，可以显著降低显存。我们最终在32B上用的就是QLoRA + LoRA的微调策略（在指令微调阶段），效果和全参数LoRA在验证集上几乎没有显著差异，但显存和训练时间方面的开销小了很多。

这里分享一段实际使用的配置文件（DeepSpeed ZeRO 3 + LoRA）：

json复制{
    "zero_optimization": {
        "stage": 3,
        "offload_optimizer": {
            "device": "cpu",
            "pin_memory": true
        },
        "overlap_comm": true,
        "contiguous_gradients": true,
        "stage3_max_live_parameters": 1e9,
        "stage3_max_reuse_distance": 1e9
    },
    "gradient_accumulation_steps": 4,
    "train_batch_size": 32,
    "train_micro_batch_size_per_gpu": 1,
    "fp16": {
        "enabled": true,
        "auto_cast": true,
        "loss_scale": 0,
        "initial_scale_power": 16
    }
}

如果检测到loss异常升高、NaN，建议优先检查fp16的loss scale设置和输入数据的数值范围，尤其是在处理医学图像时，归一化方式不对很容易让loss爆炸。

3.4 增量训练与多模态RAG的架构预留

在做模型方案设计的时候，我们提前考虑了后续的功能扩展——这可能是很多复盘文章容易忽略的点。如果你只盯着当前训练任务，后面再加功能很可能会推倒重来。

热词里提到的“多模态RAG”和“增量训练”是两个我们实际规划进架构的方向：

• 增量训练：模型的医学知识不能永远停留在训练数据截止日期。比如2025年更新的临床指南、新上市的靶向药物，这些知识需要及时更新。直接重新训练成本太高，我们的方案是预留了一个知识更新通道——用LoRA加少量新数据做持续微调，训练完替换掉旧的LoRA adapter，不需要重建整个模型。在模型架构上，我们把LoRA adapter和基座权重分离保存，部署时动态加载，这就让增量训练变得非常轻量
• 多模态RAG：纯参数化记忆（模型权重里存储的知识）有两个硬伤——容易幻觉（一本正经胡说八道）和无法溯源（医生不敢信没出处的结论）。我们计划在模型外面套一层检索增强生成框架：把医院的影像库和文献库向量化，收到问题时先用向量检索找到相关病例和文献，再把这些内容作为上下文喂给模型生成回答。这样的话，模型输出的每个结论都能指向具体的参考出处，在医疗场景中这点很重要。模型训练时会专门准备一批“带上下文推理”的指令数据，让模型学会如何利用外部检索结果而不是无视它们

4. 训练过程中的关键问题与排查技巧

4.1 医学图像预处理与数据加载的坑

在前期实验阶段，我们就遇到了一类数据管线问题。这批问题虽然不直接涉及模型训练，但解决不了后面根本跑不起来。

医学影像的输入格式五花八门：CT是DICOM（灰阶，16位深度）、病理切片是SVS/NDPI（金字塔式多分辨率）、皮肤照片是JPEG/PNG（RGB，8位）。我们统一转成了PNG（8位RGB）作为第一版输入，然后发现糟糕——CT图像的窗宽窗位信息全丢了。

CT图像本质上是16位的灰度数据，CT值范围约-1024到3071，医生阅读理解靠的是“窗宽窗位”（window width, window level）——也就是把你关心的CT值范围映射到0到255的灰度区间。不同部位、不同病灶类型需要不同的窗宽窗位：肺窗的窗宽约1500，窗位约-600；纵隔窗的窗宽约400，窗位约50。如果你不处理就直接转8位PNG，肿瘤和周边的密度差异可能完全看不出来。

我们的解决方案是：对同一张CT，生成多个窗宽窗位版本（肺窗、纵隔窗、骨窗、软组织窗），并把它作为一个图像序列输入模型。也就是模型看到的输入实际上是多通道或者说多帧的——这虽然增加了一些运算量，但效果提升非常明显。

具体代码参考：

python复制import pydicom
import numpy as np
import cv2

def dicom_to_windowed_png(dicom_path, output_prefix):
    """把DICOM转成多个窗宽窗位的PNG"""
    ds = pydicom.dcmread(dicom_path)
    image = ds.pixel_array.astype(np.float32)
    if ds.RescaleIntercept is not None:
        image = image * float(ds.RescaleSlope or 1) + float(ds.RescaleIntercept)
    
    # 各解剖部位的窗宽窗位（常用范围）
    windows = {
        "lung": (1500, -600),
        "mediastinum": (400, 50),
        "bone": (2000, 500),
        "brain": (80, 40),
    }
    for name, (width, level) in windows.items():
        lower = level - width / 2
        upper = level + width / 2
        # 裁剪到窗口范围，再归一化到 0-255
        clipped = np.clip(image, lower, upper)
        normalized = (clipped - lower) / (upper - lower) * 255
        cv2.imwrite(f"{output_prefix}_{name}.png", normalized.astype(np.uint8))

归一化错误会导致损失NaN。 这是一个让你排查到怀疑人生的问题。某些CT图像的像素值范围很大（比如16位图像的0~65535），当成8位图直接送进模型后，数值等于几千甚至几万，模型每次更新权重就产生巨大梯度，loss直接变成NaN。

这需要两步解决：一是执行上述的窗宽窗位裁剪，把数值压到0~255；二是数据加载时再做归一化，(x / 255 - mean) / std，mean和std从训练集统计得到。如果复现loss溢出的现象，优先检查这两处。

4.2 训练不收敛与过拟合的排查思路

7B模型的小规模实验阶段是排查训练问题的高发期，这里挑三个典型问题讲一下具体排查过程。

问题一：loss下降到一定程度后震荡不降

这个现象在处理医学图像时很典型——视觉编码器已经适配了大部分图像的分布，但少部分图像（比如低分辨率的X光片、有噪声的超声图像）一直没法拟合。我们的排查经验是：

1. 先把batch size加大（从2改成8），验证是不是单样本噪声太大导致的震荡
2. 打印每个batch的loss和梯度范数，看是否有个别样本梯度特别大——有的话用梯度裁剪（gradient clipping）限制最大值
3. 降低学习率（比如从5e-5降到2e-5）再训练几个epoch，看是否能继续下降

如果这些都不奏效，大概率是数据问题——某些图像对应的文本描述有误，模型学到冲突的映射关系。回头查数据，往往能找到问题。

问题二：训练loss正常下降，但验证指标上不去

这说明过拟合开始影响泛化性能。医学数据本来就少，很容易出现“背题”而不是“会做题”的现象。我用了两种手段：

一是数据增强。不仅做常规的随机裁剪、旋转、翻转，我们还针对医学图像做了灰度抖动和对比度调整（模拟不同设备、不同窗宽参数下的成像差异）。但在做增强时必须谨慎——胸部X光片如果做水平翻转，心脏的位置会跑到右边，跟正常解剖结构相反，这会给模型引入错误信息。对左右不对称的解剖结构，建议只做旋转和轻微缩放，不用翻转。

二是解冻层有限的方案。如果前面提到直接全参数微调导致过拟合，那么把训练分块（视觉编码器冻结/解冻交替）也是一种策略。但我们在7B实验上遇到过一个问题：视觉编码器完全冻结时loss下不去，完全解冻又过拟合。中间的平衡点是只解冻视觉编码器的最后几层，让高层视觉特征适应任务的同时，底层特征保持稳定。

问题三：模型产生的报告文本出现重复片段或“背诵式输出”

这个和训练数据里同类型报告太多有关。放射科报告有很强的模板化特征，比如一个医院的所有CT报告都长一个样——“扫描所见...扫描诊断...建议...”，模型学到的不是医学推理，而是“背模板”。更严重的是，如果某类疾病样本过多（比如肺结节占了50%），模型会倾向于把一切都描述成肺结节。

我们的对策是：对报告文本做句子级别的去重（similarity大于0.85的句子对只保留一条），然后按疾病类别做重采样，把模型压回去。这个操作做完之后，模型的输出多样性明显改善。

4.3 评估体系与结果分析

医疗模型评估是另一个大坑，简单算一个准确率就完事完全不够。偏瘫式评估在医疗领域会非常危险——模型可能在常见病上表现优秀，在罕见病上完全无法用。传统单一准确率指标会掩盖这个问题。

我们的评估体系分三层：

第一层：标准NLP指标。 针对报告生成任务，计算BLEU、ROUGE-L、METEOR；针对医学问答任务，计算准确率和F1。这一层快速、可自动重复，但指标好不代表模型好用——如果你生成的报告语言通顺但没有抓住关键病灶，这些指标可能依然是高分。

第二层：医学领域专项指标。 这个我们重点说三项：

• 实体覆盖度：从模型生成的报告里抽取疾病和部位实体，跟标准报告对比，看关键信息有没有漏掉
• 幻觉率：模型生成的实体在真实患者病历中找不到对应依据的比例
• 临床安全性指标：对“是否建议立即随访/手术”这类高风险结论，统计模型给出错误建议的案例数

第三层：医生主观评估。 请两位放射科医生对模型生成的报告进行盲评打分（1-5分），从准确性、可读性、临床可用性三个维度评价。这是最真实的检验。

在第一个完整版本训练完成后，我们在胸部X光报告生成任务上做了测试，结果出乎意料但也很有代表性：

可以看到32B版本相比7B在各项指标上都有显著提升，尤其幻觉率从12.4%降到8.7%。这不是因为参数多“更聪明”，而是更大模型的记忆容量更大，能从训练数据里提取更多有用的医学关联，同时维持更强的连贯性和泛化能力。

当然，评估过程中暴露的问题也很直白：医生反馈很多错误集中在“位置描述错了”（左右肺叶颠倒、上下叶混淆）和“病灶大小描述不准确”。这说明模型对医学空间关系和量化认知还不够精确，这是下一阶段要重点优化的方向。

5. 回望与经验沉淀

5.1 成本与时间大盘点

很多人好奇训练一个32B多模态模型到底要花多少钱。我们整理一下账本（以下按实际花费估算）：

数据工程环节：

• 公开数据下载、清洗、格式化：人力3人，耗时2个月
• 临床数据脱敏、授权、传输：流程耗时3个月（主要花在合同和审核）
• 标注团队（初级4人+中级1人+医生顾问兼职）：4个月，总费用按人天折算约18万
• 数据工具开发和标注平台搭建：2个工程师1.5个月

训练环节：

• 7B小规模实验：8卡A100，累计算力约1200 GPU小时
• 32B正式训练：8卡H800，训练2个epoch约7500 GPU小时（包含多次中断和重试），电费+云资源按市场价折算约13万
• 对比实验和调参：大概又消耗了训练计算量的一半

人工成本： 算法工程师3人、数据工程师2人、医学标注和评估2人，前后总投入约9个月，人力成本按平均30万年薪折算约70万左右。

总成本大概在100万级别。这个数字让很多想自己训练医疗模型的团队望而却步——实际上确实不是一个小数目，但如果你的场景足够明确（比如只做肺结节检测），用现成的开源模型+少量数据可以显著降低成本，并不需要完全照搬32B路线。

5.2 走完上半程的几点体会

复盘到这里，上半程的主要工作已经讲完了。说说我踩过这么多坑后的几个核心体会：

数据工程永远是训练项目中变动最大的部分。 我见过太多团队把时间都花在配训练脚本上，对数据处理的投入严重不足。实际上，训练卡住了首先应该怀疑的不是框架或算法，而是数据——尤其对医疗这种数据复杂度极高的领域更是如此。我们项目里耗费时间的比例大概是：数据相关60%，训练调试25%，模型评估15%，这个比例说明了很多问题。

基座模型选型直接影响训练成本的上限。 选好一个基座模型，等于决定了一半的成败。不要为了“大”而大，要看你的数据规模能不能撑起大模型的训练。如果你只有几万条数据，老老实实用7B或14B做LoRA；如果你有百万级的数据，全参数微调32B的价值就能体现出来。

先在小模型上验证，再上大模型。 这个原则帮我们节省了至少一倍的调参时间。很多训练问题是数据层面的，和数据规模无关，在7B模型上就能暴露；解决了这些问题再上32B，大模型训练就会顺利很多。反之，如果你拿着32B模型去试错，一次完整训练周期要好几天，一晚上就能试出好几个方案的节奏根本带不动。

“（上）”篇先到这里。 后半程的内容——包括完整训练过程中的loss曲线分析、指令数据构造细节、RLHF对齐实验、部署推理优化、以及在下游任务上的效果对比——我会在（下）篇里继续写。如果你正准备训练自己的医疗多模态模型，这篇的规划和避坑经验应该能帮你少走不少弯路。