医疗大模型这两年从论文里的概念快速落到了工程现场身边不少做医疗信息化、临床科研甚至医院信息科的同行都在问同一个问题手里有脱敏病历、有指南文献、有科室积累的问答对怎么把它们真正喂进一个开源基座里做出一个能回答专科问题、能跟着最新指南走的模型MedicalGPT 这套流程就是冲着这个需求来的——它把增量预训练、监督微调、奖励建模、强化学习对齐这几段串成了一条可复现的流水线基座可以换数据可以换但骨架是稳定的。我前后用 Qwen-7B 做基座跑过两轮完整流程中间踩的坑比想象中多尤其是数据配比和显存这两块。下面这篇就把从零构建 MedicalGPT 的全流程拆开讲包括每一步为什么这么做、参数怎么算、哪些地方最容易翻车适合有一定 Python 和 PyTorch 基础、想自己动手做医疗领域微调的读者参考。1. 整体方案设计与技术选型思路1.1 为什么医疗领域不能直接拿通用大模型上通用大模型在开放域问答上表现不错但一进医疗场景就露怯。我拿同一个问题测过好几个通用模型问“二甲双胍在 eGFR 低于 45 的患者中如何使用”有的模型直接给出常规剂量完全忽略了肾功能不全的禁忌调整。这不是模型笨而是它的训练语料里医学科普和临床指南的密度太低模型学到的是“大众认知里的医疗”而不是“临床决策里的医疗”。医疗文本有几个很鲜明的特点。第一是术语密度高且缩写多像“NSCLC”“COPD”“eGFR”这类缩写在不同科室含义可能不同通用分词器切出来的 token 往往把缩写切碎语义就散了。第二是长尾分布严重罕见病、特定药物相互作用、最新指南更新这些内容在通用语料里几乎见不到。第三是容错率极低通用场景答错一句无伤大雅医疗场景答错一句可能涉及用药安全。这三点决定了医疗大模型必须经过领域数据的继续训练而不是靠 prompt 工程糊弄过去。MedicalGPT 的价值就在于它把这条领域适配路径标准化了。它不是某个具体的模型而是一套训练流程和代码框架核心思路是先用海量医疗文本做增量预训练让基座“补医学课”再用高质量的问答对做监督微调让它“学会按医生的方式回答”如果追求更高的一致性还可以继续做奖励建模和强化学习对齐。这套流程和通用大模型的训练范式是一致的只是数据换成了医疗领域。1.2 基座选型为什么我最终落在 Qwen-7B 上基座选择是第一个岔路口。市面上可选的中文基座不少我实际对比过 Qwen-7B、Baichuan2-7B、InternLM-7B 这几个同量级的。选 Qwen-7B 主要基于三点考虑。第一是中文医学语料的 token 效率。Qwen 的分词器对中文和常见英文医学术语的切分比较合理同样一段病历文本Qwen 切出来的 token 数通常比一些以英文为主的基座少 15% 到 25%。这意味着同样的显存能塞进更长的上下文对处理长病历和指南文档很关键。第二是生态成熟度。Qwen 系列的微调工具链、量化方案、推理部署支持都比较完整遇到问题容易找到参考。做医疗项目最怕的是卡在一个冷门基座的坑里没人踩过时间成本太高。第三是 7B 这个量级的性价比。13B 以上对显存要求陡增单卡 24G 很难舒服地跑全参数微调7B 配合 LoRA 或者 QLoRA单张 24G 卡就能跑起来对大多数团队和个人开发者更现实。如果你的场景对效果要求极高且有 A100 集群可以考虑 14B 或 32B但流程是一样的。提示基座选型不要只看榜单分数。医疗场景更看重领域 token 效率和长文本处理能力建议拿自己科室的真实文本做一次分词测试对比 token 数和切分质量比看排行榜靠谱。1.3 四阶段流程的分工与取舍MedicalGPT 的完整流程包含四个阶段增量预训练、监督微调、奖励建模、强化学习对齐。很多人一上来就想跑全流程我的建议是先想清楚自己的目标。增量预训练解决的是“知识注入”问题让模型见过足够多的医学文本建立领域语感。监督微调解决的是“指令跟随”问题让模型学会按问答格式输出。奖励建模和强化学习对齐解决的是“偏好对齐”问题让模型的回答更符合人类医生的偏好比如更严谨、更少幻觉。如果你的目标只是做一个能回答科室常见问题的助手增量预训练加监督微调基本够用。奖励建模和强化学习对齐对数据质量和算力要求都更高收益在医疗场景下不一定线性增长我建议先把前两阶段做扎实。下面重点讲前两阶段的完整实现后两阶段给出思路和关键点。2. 数据准备与增量预训练实操2.1 医疗语料的来源与清洗要点增量预训练的数据质量直接决定模型的知识底子。医疗语料大致分几类公开医学教材和指南、脱敏病历文本、医学文献摘要、药品说明书、科室积累的问答记录。我实际用下来教材和指南的性价比最高因为结构清晰、术语规范、错误率低病历文本信息密度高但噪声大需要重点清洗。清洗这一步我踩过最大的坑是“看起来干净其实有毒”。早期我直接拿一批病历文本去训练结果模型学会了一堆模板化的套话和重复表述因为病历里大量存在“患者一般情况可”“无特殊不适”这类高频重复句。后来我加了几道过滤按段落去重、过滤长度过短或过长的段落、过滤包含大量数字和符号的表格残留、用困惑度过滤掉语义混乱的文本。具体操作上我写了一个清洗脚本核心逻辑是分句、去重、长度过滤、困惑度打分。困惑度过滤用一个小的参考模型算把明显不通顺的句子筛掉。这一步会损失一部分数据量但留下来的质量明显更高。实测下来清洗后 10G 高质量文本的效果比 30G 未清洗文本要好。import re from collections import Counter def clean_medical_corpus(texts, min_len50, max_len2000): seen set() cleaned [] for t in texts: # 按句号、换行切分 sents re.split(r[。\n], t) for s in sents: s s.strip() if len(s) min_len or len(s) max_len: continue # 过滤数字符号占比过高的段落 digit_ratio sum(c.isdigit() for c in s) / max(len(s), 1) if digit_ratio 0.3: continue # 去重 key s[:50] if key in seen: continue seen.add(key) cleaned.append(s) return cleaned2.2 增量预训练的数据配比与打包策略数据配比是个经验活。纯医疗语料训练会让模型在通用能力上退化出现“只会说医学术语日常对话都不会了”的情况。我的做法是医疗语料和通用中文语料按 7:3 到 8:2 混合既保证领域知识注入又保留基座的通用语言能力。打包策略上增量预训练通常用固定长度拼接比如把多条短文本拼成 2048 或 4096 token 的序列减少 padding 浪费。这里要注意的是拼接时不要跨文档破坏语义边界我一般会在文档之间插入分隔符并在 attention mask 上做处理避免模型把两篇不相关的文档当成连续上下文。训练参数方面7B 模型增量预训练我用的配置是学习率 1e-5 到 2e-5cosine 衰减warmup 比例 0.03batch size 通过梯度累积凑到 128 左右训练 1 到 2 个 epoch。学习率不能太高否则容易把基座原有的能力冲垮epoch 也不能太多医疗语料重复训练容易过拟合。注意增量预训练阶段建议用全参数训练或者较大 rank 的 LoRA。小 rank 的 LoRA 在这个阶段注入知识的能力有限因为知识注入需要改动较多参数。如果显存实在不够可以先用 QLoRA 做一版但效果会打折扣。2.3 显存估算与训练加速技巧7B 模型全参数训练光模型权重加优化器状态就要 7B × (2 2 4 4) 字节左右粗算下来接近 80G单卡根本放不下。所以实际落地要么用多卡要么用 LoRA/QLoRA。我用的是 QLoRA 方案4-bit 量化后模型权重只占约 4G加上 LoRA 适配器和优化器状态单张 24G 卡能跑起来。关键参数是 LoRA rank 设 64、alpha 设 128、target modules 覆盖 q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj 这些线性层。rank 设大一点是因为增量预训练需要更强的表达能力。加速技巧上flash attention 2 一定要开长序列训练能省不少显存和时间。gradient checkpointing 也建议开用时间换显存。另外数据加载用多进程避免 GPU 等数据。我实测下来这些优化加起来能让训练速度提升 40% 以上。配置项全参数训练QLoRA 训练显存需求80G20G 左右单卡可行性不可行24G 卡可行知识注入效果最好良好训练速度快中等推荐场景多卡集群单卡/个人3. 监督微调与数据构造核心细节3.1 医疗问答对的质量标准监督微调的数据质量比数量重要得多。我见过太多人拿几万条粗糙问答去微调结果模型学会了胡说八道。医疗问答对有几条硬标准答案必须有依据不能是模型编的问题要覆盖真实场景不能全是教科书式的标准问法答案长度要适中太短信息不足太长模型学不会抓重点。我构造数据时遵循一个原则每条问答都要能追溯到来源。来源可以是临床指南、药品说明书、权威教材也可以是有经验的医生审核过的科室问答。没有来源的问答我宁可不用。另外我会刻意构造一些“边界问题”比如“这个药孕妇能不能用”“这个症状要不要立即就医”让模型学会在不确定时给出谨慎的回答而不是硬编一个答案。数据格式上MedicalGPT 用的是标准的指令格式包含 instruction、input、output 三个字段。对于纯问答input 可以留空对于带上下文的任务比如“根据以下病历回答问题”input 放病历文本。格式统一很重要否则模型学出来的输出格式会很乱。{ instruction: 患者男58岁2型糖尿病eGFR 38询问二甲双胍是否可用, input: , output: 根据患者 eGFR 38 的情况二甲双胍使用需谨慎。当 eGFR 低于 45 时不建议新启用二甲双胍若已在用需评估获益风险并考虑减量或换药。建议结合患者整体情况考虑改用对肾功能影响较小的降糖方案并密切监测肾功能。具体用药调整请遵医嘱。 }3.2 数据配比与多样性控制监督微调的数据配比同样讲究。全是问答对会让模型变得只会答题通用对话能力下降。我的配比是医疗问答占 70%通用指令数据占 20%剩下的 10% 放一些安全对齐数据比如拒绝回答超出能力范围的问题、提醒就医等。多样性控制上我会统计问题的类型分布确保覆盖问诊、用药、检查解读、健康科普、就医建议等不同类别。如果某一类占比过高模型就会偏科。我一般用简单的关键词分类做统计发现偏斜就补充数据。还有一个容易被忽略的点是答案的风格多样性。如果所有答案都是同一种句式模型输出会很死板。我会刻意保留不同医生的回答风格有的简洁直接有的详细解释让模型学到更自然的表达。3.3 LoRA 微调的关键参数设置监督微调阶段我用 LoRA 就够了不需要全参数。LoRA rank 设 32 到 64alpha 设 rank 的两倍dropout 设 0.05 到 0.1 防止过拟合。学习率比增量预训练高一些用 1e-4 到 2e-4cosine 衰减warmup 比例 0.03。target modules 的选择上我建议覆盖 attention 和 MLP 的所有线性层只调 attention 效果会差一些。batch size 根据显存尽量设大配合梯度累积。训练 epoch 一般 2 到 3 个医疗问答对数据量不大的话可以多跑几个 epoch但要盯着验证集 loss一旦回升就停。实操心得LoRA 微调时保存多个 checkpoint最后用验证集挑最好的那个不要只看最后一个。我遇到过最后一个 epoch 过拟合中间某个 checkpoint 效果反而更好。4. 奖励建模与强化学习对齐思路4.1 奖励建模的数据与训练要点奖励建模的目标是让模型学会判断哪个回答更好。数据形式是同一个问题的多个回答人工标注偏好排序。医疗场景下偏好维度包括准确性、安全性、完整性、表达清晰度。标注成本很高所以这一步通常只在有明确需求时才做。训练上奖励模型一般基于微调后的模型加一个打分头用 pairwise 的 ranking loss 训练。数据量不需要特别大几千到几万条高质量偏好对就能有不错的效果但标注质量必须高。我建议至少让有医学背景的人参与标注纯众包标注在医疗场景下风险太大。4.2 强化学习对齐的落地难点强化学习对齐常用 PPO 或 DPO。PPO 工程复杂度高需要同时维护策略模型、参考模型、奖励模型显存和调参难度都大。DPO 相对简单直接用偏好数据优化策略模型不需要单独的奖励模型在医疗场景下我更推荐 DPO。DPO 的关键是 beta 参数控制模型偏离参考模型的程度。beta 太小模型会过度优化偏好数据出现 reward hackingbeta 太大则对齐效果不明显。我一般从 0.1 开始试根据验证集表现调整。医疗场景下我倾向于保守一点宁可对齐弱一些也不要让模型为了迎合偏好而牺牲准确性。注意强化学习对齐阶段最容易出现的问题是模型学会“讨好”而不是“正确”。医疗场景下这个风险尤其高因为偏好标注本身可能有偏差。建议对齐后做一轮严格的事实性评估确认模型没有为了流畅而编造内容。5. 常见问题排查与避坑经验5.1 训练不收敛与 loss 异常排查训练不收敛最常见的原因是学习率太大或数据格式有问题。我遇到过 loss 一开始就飙到很高然后不降排查下来是数据里混入了大量空文本和乱码。所以训练前一定要抽样检查数据确认格式统一、内容干净。另一个常见问题是 loss 正常下降但模型输出乱码。这通常是 tokenizer 和模型不匹配或者保存模型时没保存 tokenizer。建议训练脚本里显式保存 tokenizer推理时用同一个。如果 loss 震荡厉害检查 batch size 是不是太小或者梯度累积设置有没有问题。医疗数据分布不均batch 里如果全是某一类样本梯度方向会偏适当 shuffle 能缓解。5.2 显存溢出与训练中断处理显存溢出是单卡训练的家常便饭。除了前面说的 QLoRA 和 gradient checkpointing还可以降低 max_seq_length、减小 batch size、用 8-bit 优化器。我一般先把 max_seq_length 从 4096 降到 2048 试试很多场景下 2048 够用了。训练中断后恢复要注意 checkpoint 的完整性。我习惯每几百步存一次并且存的时候同时保存优化器状态和 scheduler 状态这样恢复后能接着原来的学习率曲线走不会因为重启导致学习率跳变。5.3 模型幻觉与安全性问题医疗大模型最怕的就是幻觉。模型会用很自信的语气说出错误信息用户很难分辨。缓解幻觉有几个手段训练数据里加入“不知道就说不知道”的样本推理时用较低的温度参数对高风险问题加规则兜底比如涉及用药剂量、急症判断的问题强制模型给出就医建议而不是具体方案。我还会在部署时加一层输出审核用关键词匹配加小模型分类把明显有风险的输出拦下来。这层审核不能完全依赖大模型自己因为大模型可能被绕过。常见问题可能原因排查方向loss 不下降学习率过大、数据脏降学习率、抽样检查数据输出乱码tokenizer 不匹配确认保存和加载同一 tokenizer显存溢出序列过长、batch 过大降 max_seq_length、用 QLoRA模型幻觉严重数据质量差、温度过高清洗数据、降温度、加兜底规则通用能力退化医疗数据占比过高调整配比混入通用数据5.4 评估环节的实操建议评估是很多人偷懒的环节但医疗场景下评估比训练还重要。我建议至少做三层评估自动指标看 perplexity 和 BLEU/ROUGE只能作为参考人工评估抽一批真实问题让医生打分看准确性和安全性对抗评估专门构造边界问题看模型会不会胡说。评估集要独立于训练集而且要覆盖不同科室和问题类型。我一般留 500 到 1000 条高质量问答做评估每条都人工过一遍。评估结果要记录每次改数据或调参后重新跑对比看有没有提升。6. 部署与推理优化实践6.1 量化部署与推理加速训练完的模型要部署才有价值。7B 模型用 fp16 推理需要约 14G 显存用 int8 量化降到 7G 左右int4 量化能降到 4G 以内。我用的是 GPTQ 或 AWQ 量化4-bit 量化后效果损失很小推理速度也快。推理框架上vLLM 的吞吐量比 HuggingFace 原生推理高很多适合并发场景。如果只是本地测试transformers 加量化就够了。部署时注意设置合理的 max_new_tokens 和 temperature医疗场景温度建议设 0.1 到 0.3减少随机性。6.2 上线前的安全检查清单医疗模型上线前必须过一遍安全检查。我整理了一份清单涉及用药剂量的回答是否都带了“遵医嘱”急症相关的问题是否都建议立即就医模型是否会在不确定时承认不知道是否有输出审核层拦截高风险内容是否有日志记录所有问答便于追溯。这份清单不是走形式每一条都对应真实的风险。我见过模型给用户算出具体用药剂量然后用户真去执行的案例虽然模型加了免责声明但风险依然存在。医疗场景下宁可模型保守一点也不要它“大胆”回答。7. 个人实操体会与后续扩展方向跑完两轮完整流程我最大的体会是数据决定上限流程决定下限。MedicalGPT 这套流程本身是成熟的照着跑能出结果但结果好不好几乎完全取决于数据质量。我第一轮用了一批没怎么清洗的数据模型输出一堆套话第二轮认真做了清洗和配比效果提升非常明显。另一个体会是不要追求一步到位。很多人想直接跑完四个阶段结果每个阶段都做得不扎实。我的建议是先把增量预训练和监督微调做透把评估体系建起来再考虑要不要做对齐。医疗场景下一个知识扎实、回答谨慎的模型比一个对齐得很“讨喜”但会编内容的模型有价值得多。后续扩展上可以考虑几个方向接入 RAG 让模型能查最新指南弥补训练数据时效性的不足做多模态把影像报告和文本结合针对特定科室做垂直微调比如只做肿瘤或只做心血管。这些都是在现有流程基础上的自然延伸核心骨架不用变。最后分享一个小技巧训练日志一定要详细记录包括数据版本、超参、每步 loss、评估结果。我吃过亏改了一版数据后效果变差但没记录改了什么只能从头排查。后来我养成了用实验管理工具记录每次实验的习惯省了大量时间。医疗大模型是个长期工程可复现比跑得快重要得多。