DeepSeek私有化部署实战：电子病历分析中的LoRA微调与调优

简介：面向医疗行业AI工程师、数据科学家及医院信息化负责人，完整梳理DeepSeek在电子病历分析场景中的私有化部署与训练调优路径。文档从私有化部署的价值与安全合规需求切入，逐步讲解电子病历的数据清洗、转换与划分，模型架构选择、训练监控、超参数调优、正则化及模型融合策略，并延伸至评估指标、交叉验证、ROC曲线与临床数据验证，最后给出硬件选型、软件安装、模型服务化及系统集成的全流程实现方案。资源为1个PDF文档，共28页，压缩包大小1.86MB，内容包含目录框架、原理说明、训练调优步骤及实际应用案例，适合需要将大模型落地到医疗数据环境的研发人员参考。已有89人浏览学习，文档结构完整、图表正常，可直接按章节查阅。

1. 把 DeepSeek 装进医院内网：电子病历分析为什么要走私有化这条路

拿到“医疗行业私有化部署全流程：DeepSeek在电子病历分析中的训练与调优实战”这个方向，第一反应是：这不是模型选型问题，是数据能不能出院区的问题。电子病历里包含姓名、身份证号、完整诊疗过程，医院信息科不会允许把这些数据传到任何外部接口。云厂商的通用大模型 API 再强，病历数据过不了合规这一关，等于没用。所以私有化部署不是可选项，是先决条件。

DeepSeek 这类开源预训练语言模型正好卡在这个位置上：权重公开、可以完全跑在内网、不依赖外部服务，配合 LoRA 这类轻量微调方案，能把一个通用对话模型调成“懂病历”的领域模型。这篇文章面向的是医院信息科工程师、医疗 AI 公司的算法岗、以及想在校内复现这个流程的研究生。我按自己做过的一版落地路径来讲：从部署、数据准备、微调调优到避坑，每一步都给出能直接抄走的命令和参数。不可能所有医院环境都一样，但这条路线的主干是通用的。

2. 硬件选型与 vLLM 部署：让 DeepSeek 在病历分析场景先跑起来

2.1 先定参数量级：病历分析任务不需要追求顶配

电子病历分析并不是一个需要极致推理能力的任务。大部分落地场景可以拆成三类：信息抽取（诊断、用药、手术操作、主诉）、文本结构化（把一段病程记录转成 JSON）、辅助质控（病程记录缺不缺关键项）。这三类任务的共同特点是输入长、输出短、格式要求严格，对模型的“记忆能力”和“指令遵循能力”要求远高于“创造性推理能力”。所以部署时不需要追求最大参数量的版本，7B 到 14B 这个区间通常是性价比最好的选择。

参数量级的决策直接决定你要买什么样的卡。以我常用的 DeepSeek 系列为例，7B 模型在 BF16 精度下大约需要 15GB 显存，一张 24GB 的卡就能跑；14B 在 BF16 下接近 30GB，一张 4090 或 A5000 也能压住。如果预算有限，还可以用 INT8 或 INT4 量化把显存需求再砍一半，代价是生成质量有小幅下降。对于电子病历抽取场景，量化带来的损失远小于一个正则表达式写错的损失，所以不用太纠结精度。

我的建议是：如果团队刚起步，直接用 7B 的 INT8 版本跑通全流程，等数据积累到一定规模再升级 14B。因为部署和微调是两个独立的难点，先用小模型把数据管道跑通，比一步到位上大模型然后卡在显存问题上更实际。电子病历分析的业务瓶颈通常不在模型上限，而在数据质量和标注一致性。

2.2 用 vLLM 部署 DeepSeek 推理服务：最小可跑命令

部署推理服务我一般首选 vLLM，原因是它自带 OpenAI 兼容接口，后续微调完可以直接替换模型路径，业务代码不用改。vLLM 还支持 PagedAttention，长文本场景下显存利用率比原生 HuggingFace generate 高不少。电子病历的输入动不动就是几千字，这对推理框架的 long context 处理能力有硬要求。

# 以 7B 量级的 DeepSeek 模型为例启动推理服务 vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name medical-deepseek \ --gpu-memory-utilization 0.92 \ --max-model-len 8192 \ --tensor-parallel-size 1 \ --port 8000

这段命令里值得解释的几个参数。--served-model-name是给服务起一个业务别名，后面 API 调用时用这个名称，这样将来换模型时前端不用改字段。--gpu-memory-utilization 0.92表示允许 vLLM 占用 92% 的显存，剩下的留给 KV cache 之外的碎片和启动开销；如果显存本来就紧张，可以降到 0.85 换取稳定性。--max-model-len 8192是输入加输出的最大 token 数。电子病历单篇一般 2000 到 6000 字，8K 够用；设太长会让 KV cache 预留显存暴增，导致并发能力下降。

启动后服务默认监听 8000 端口，通过/v1/chat/completions暴露接口。可以先用 curl 验证服务是否正常：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "medical-deepseek", "messages": [ {"role": "user", "content": "从这段病历中抽取诊断结果：患者因胸痛3天入院，既往高血压病史5年。"} ], "max_tokens": 256, "temperature": 0.1 }'

注意推理阶段把temperature调到 0.1 甚至 0，病历抽取任务需要确定性输出，温度越高越容易产生幻觉字段。这也是私有化部署里最容易忽略的一个点：很多人把默认参数直接接到业务里，结果同一个病历每次抽出来的诊断都不一样，医生根本不敢用。

2.3 验证接口与并发：微调之前先把基线打牢

服务起来之后，不要急着做微调，先拿一批真实病历（脱敏后）跑一遍基线，记录三类数据：接口响应时间、是否出现 JSON 解析失败、抽取结果里有多少明显错误。这些数据是后面评估微调效果的基准。常见做法是准备 20 份病历，手动标注好标准答案，先让通用模型跑一遍，你会发现未微调的模型主要问题集中在：医学实体识别不全、输出格式不稳定、同一实体在不同病历里写法不一致。这些问题就是微调要解决的目标。

并发验证也要做。医院场景通常是科室并发调用，几十个医生同时操作或者批量跑历史病历，vLLM 默认的并发上限不一定够。可以通过--max-num-seqs参数控制最大并发序列数，但要注意这个参数受显存限制，开太高会把 KV cache 打爆。我一般会先用 16 并发压测，观察显存占用和响应延迟，再决定调多少。这一步是为了避免上线当天接口被挤爆。

2.4 版本锁定与依赖管理：私有化环境没有后悔药

私有化部署最麻烦的不是装环境，而是环境不可复现。医院内网往往不能联网拉包，所以部署前必须把依赖全部离线准备好。我的习惯是直接用 Docker 镜像锁版本，把 vLLM、torch、transformers 的版本号都固定好，导出镜像传到内网服务器。不要指望在目标机器上现场pip install，内网源的包版本经常不全，装到一半缺依赖的体验很痛苦。

模型权重也要提前下载好，放到内网本地路径，然后从本地路径加载。vLLM 支持从本地目录加载模型：把deepseek-ai/DeepSeek-R1-Distill-Qwen-7B换成实际的本地路径即可。这一步不能省，因为很多医院内网连 HuggingFace 的域名都访问不了，如果不提前把权重库准备好，部署流程会卡死在下载这一步。

3. 电子病历到训练集：脱敏、清洗与指令数据构建

3.1 电子病历的脏数据长什么样：脱敏是第一道闸

部署好推理服务只是第一步，真正决定模型效果的是训练数据。电子病历和普通文本数据最大的区别是它的“隐私密度”极高。一段几十字的病程记录里可能有患者姓名、住院号、身份证号、手机号、家庭住址，这些信息如果原样进入训练集，模型微调后可能把患者隐私“背”出来。医疗场景下这是绝对的红线，所以数据准备的第一道工序就是脱敏。

脱敏不能只在原始文本上做一次替换，因为病历里的写法五花八门：手机号可能写成138-1234-5678，身份证号可能少一位，日期有多种格式。我的做法是先用正则做粗筛，再人工抽检。正则覆盖常见模式，人工解决正则漏掉的边角情况。

import re # 电子病历常见隐私实体正则，按需扩展 PATTERNS = [ (re.compile(r'(?<!\d)1[3-9]\d{9}(?!\d)'), '[手机号]'), (re.compile(r'(?<!\d)\d{17}[\dX](?!\d)'), '[身份证号]'), (re.compile(r'20\d{2}[-/年]\d{1,2}[-/月]\d{1,2}日?'), '[日期]'), (re.compile(r'(?<=患者[:：])\s*[\u4e00-\u9fa5]{2,4}(?=\s*(,|，|。))'), '[姓名]'), ] def anonymize(text: str) -> str: for pattern, replacement in PATTERNS: text = pattern.sub(replacement, text) return text

这段代码的逻辑是：按顺序逐个正则替换，手机号和身份证号用负向前瞻避免误伤连续数字，日期把常见的几种分隔符都覆盖到。姓名脱敏是最难的一部分，因为病历里“患者：张三”和“患者李四”格式不一，正则有边界情况。所以我通常还会配合一个姓氏词典做二次替换，把“张”“李”“王”等高频姓氏后跟两到三字的组合整体替换为[姓名]。脱敏完成后，抽 10% 的数据人工检查一遍，确认没有漏网的隐私字段再进入下一步。这一步是整条流水线里唯一不能自动化兜底的环节。

3.2 构造指令数据集：把病历任务翻译成模型看得懂的话

脱敏完的数据还是长文本，不能直接扔给模型训练。需要把任务构造为“指令-输入-输出”的结构。电子病历分析的核心任务本质上是信息抽取和文本转换，所以指令设计要遵循一个原则：明确告诉模型输入是什么、输出什么格式、键名是什么。模型不是医生，它不知道“主诉”要抽取到什么粒度，指令里必须写清楚。

{ "instruction": "你是电子病历结构化助手。从下面的入院记录中抽取以下字段：主诉、现病史、既往史、初步诊断、用药记录、手术操作。输出JSON对象，键名严格使用中文，数组字段用列表表示。不要输出任何解释。", "input": "患者因反复胸闷气喘3年，加重3天入院。既往有高血压病史5年，规律服用氨氯地平。查体：BP 155/95mmHg，双肺呼吸音粗，可闻及哮鸣音。初步诊断：慢性阻塞性肺疾病急性加重。", "output": "{\"主诉\": \"反复胸闷气喘3年，加重3天\", \"现病史\": \"患者3年前开始出现胸闷气喘，近3天加重\", \"既往史\": \"高血压病史5年，规律服用氨氯地平\", \"初步诊断\": [\"慢性阻塞性肺疾病急性加重\"], \"用药记录\": [\"氨氯地平\"], \"手术操作\": []}" }

这个格式有讲究。instruction里我特意写了“键名严格使用中文”和“不要输出任何解释”，因为未微调的模型经常在 JSON 前后加一句“好的，根据您的要求……”，导致程序解析失败。训练数据里就按严格格式写，模型会学到这种输出习惯。output里所有字段必须完整，不能偷懒只给一部分，否则模型学到的是“缺字段也没关系”。

数据量方面，我一般建议从 500 到 2000 条人工标注数据起步。电子病历的实体类型有限，500 条已经能覆盖大部分常见表述。标注可以借助开源标注工具，但最终一定要有医生或者有医学背景的人审核一遍，因为病历里的诊断名词描述不规范，非专业人士很难判断对错。这个环节是整条流程里最耗时也最值钱的部分。

3.3 数据量不够？从自监督续训和同义改写两处补

很多团队卡在标注数据不够。一个科室能给的已脱敏病历可能只有两三百份，不够微调。我常用的补充思路有两个：一个是在原始病历文本上做自监督续训，让模型先熟悉本院的书写风格和术语习惯；另一个是规则化的同义改写，把已有的标注数据做数据增强。

自监督续训的做法很简单：把脱敏后的病历原文按 512 token 切段，直接构造“下一句预测”任务继续预训练。这一步不需要任何标注，纯无监督，几百份病历就能跑。它的作用是让模型习惯院内病历的用词：比如“TNM”“PCI”“COPD”这些缩写，通用模型并不是每次都认，但续训之后会稳定很多。续训完的模型再拿去跑基线，你会发现实体召回率有一定的提升，这是很正常的现象。

同义改写要谨慎，不能随便用 LLM 改写，因为电子病历是医学文本，改错一个诊断名词就要命。我的做法是只做结构层面的变换：比如把“患者因胸痛入院”改写成“因胸痛 3 天入院”，把“高血压病史 5 年”和“既往高血压 5 年”互换说法。这类改写基于模板而不是自由生成，安全系数高。如果只是格式统一，也可以不做增强先跑一轮小规模微调看效果，有时候标注质量比数量重要得多。

3.4 用脚本先检验数据质量再进训练

数据准备好之后，进训练之前一定要跑一遍质量校验脚本。电子病历数据常见的坑：JSON 里多了一个逗号、中英文冒号混用、label 字段漏给、instruction 和 output 对不上。这些问题训练时不会报错，但会让模型学到错误映射，后期排查非常痛苦。

import json with open("train.jsonl", "r", encoding="utf-8") as f: lines = f.readlines() bad_lines = [] for idx, line in enumerate(lines): try: item = json.loads(line) assert "instruction" in item and "input" in item and "output" in item, "字段缺失" json.loads(item["output"]) # 输出必须是合法 JSON except Exception as e: bad_lines.append((idx, str(e))) print(f"总行数: {len(lines)}, 异常行数: {len(bad_lines)}") for idx, err in bad_lines[:10]: print(f"行 {idx}: {err}")

这段脚本的核心就三个检查点：JSON 本身合法、三个必需字段都在、output 里嵌套的 JSON 也能被解析。第一个和第三个检查是重点，因为 output 里经常出现中文引号或全角冒号，json.loads解析失败就说明数据格式不一致。这类问题在训练阶段会表现为 loss 居高不下或者生成结果格式混乱。数据校验这一步不能省，跑一下只需要几十秒，但能省掉后面几小时的调参时间。

4. LoRA 微调与参数调优：把 DeepSeek 变成“懂病历”的模型

4.1 为什么选 LoRA：显存、成本与可回滚

微调路线主要有三条：全参微调（Full Fine-tuning）、LoRA、QLoRA。全参微调对显存和训练时间的要求很高，14B 模型全参微调至少要两张 80GB 卡，而且训练完的产物是一整套权重，出问题想回退很麻烦。LoRA 只训练一小部分低秩矩阵，显存占用小得多，训练产物是一个几十到几百 MB 的 adapter 文件，原始权重完全不动。这意味着你可以同时保留多个版本的 adapter，哪个效果好就用哪个，切换成本极低。QLoRA 是在 LoRA 基础上把基座模型量化到 4bit，进一步降低显存门槛，代价是训练速度稍慢、效果可能有轻微损失。

医疗私有化场景我优先推荐 LoRA，具体理由有两条：第一，医院不可能频繁做全参微调，一次训练可能就要跑一两天，LoRA 在单卡上几个小时能跑完；第二，病历数据量通常不大，几千条样本对全参微调来说反而容易过拟合，LoRA 的低秩约束天然自带正则化效果。调优阶段的“后悔药”也很重要——你可以在同一个基座上训好几个版本的 adapter，线上用了 A 版本，发现不好换回 B 版本，几秒钟就能完成。

4.2 训练脚本：SFTTrainer + LoRA 跑通最小流程

训练部分我用的是 HuggingFace PEFT 库加 TRL 的 SFTTrainer，这套组合是目前最成熟的路子。脚本分三部分：加载基座模型并注入 LoRA 配置、加载训练数据、配置训练参数并启动训练。

from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer from datasets import load_dataset model_path = "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) tokenizer.pad_token = tokenizer.eos_token lora_config = LoraConfig( r=32, lora_alpha=64, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], lora_dropout=0.05, task_type="CAUSAL_LM", ) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype="auto", device_map="auto", low_cpu_mem_usage=True, ) model = get_peft_model(model, lora_config) dataset = load_dataset("json", data_files="train.jsonl", split="train") training_args = TrainingArguments( output_dir="./medical_emr_lora", per_device_train_batch_size=2, gradient_accumulation_steps=8, learning_rate=2e-4, num_train_epochs=3, logging_steps=50, save_steps=500, fp16=True, gradient_checkpointing=True, lr_scheduler_type="cosine", warmup_ratio=0.05, save_total_limit=3, ) trainer = SFTTrainer( model=model, args=training_args, train_dataset=dataset, tokenizer=tokenizer, max_seq_length=4096, dataset_text_field="output", ) trainer.train()

关键配置逐个说明。lora_config里的r=32决定了 LoRA 矩阵的秩，秩越大模型能学到的模式越复杂，但参数量和过拟合风险也上升；32 是对 7B 模型比较保险的起点。target_modules把注意力层和前馈层的投影矩阵都覆盖了，这是目前主流做法，只动q_proj和v_proj的旧习惯已经不推荐了。训练侧per_device_train_batch_size=2加gradient_accumulation_steps=8，等效 batch size 是 16，对千条量级的数据集比较合适。fp16=True能省一半显存，但如果你用的是 40 系以后的卡，可以换成bf16=True，数值稳定性更好。

SFTTrainer里我传了max_seq_length=4096，这个要和你部署时的--max-model-len对齐，不然训练用了 4096 的上下文，部署时模型不支持，生成的截断位置会不一样。另一个值得注意的点是dataset_text_field="output"，SFTTrainer 默认会自动拼上 instruction 和 input，只需指定 output 字段作为监督标签，不要自己去手动拼接样本，否则模板格式容易出错。

4.3 参数怎么调：学习率、Rank、Epoch 的批量调优路线

训练跑通之后就是玄学最多的调优环节。我调参的顺序是固定的：先固定训练 3 个 epoch 跑通，然后调学习率，再调 rank，最后才动 epoch。学习率是最敏感的超参数，LoRA 常见的有效区间是 1e-4 到 5e-4。低于 1e-4 模型学不到东西，高于 5e-4 很容易在训练后期 loss 震荡。如果训练集只有几百条，我倾向用 1e-4 加 5 个 epoch，用小步长多走几步；如果训练集有两千条以上，2e-4 加 3 个 epoch 通常更稳。

r值的调整逻辑简单一些：先跑一个 r=16 的版本看效果，再跑 r=64 的版本，对比验证集上的实体准确率。如果 r=64 没有明显优势，就用 32 或 16，因为秩越低推理开销越小，也越不容易过拟合。lora_alpha的作用是缩放 LoRA 权重，一般取r的两倍，也就是alpha=2r，这个比例不用频繁动。Epoch 不是越多越好，病历数据重复度高，跑 5 个 epoch 以上很容易在验证集上观察到效果下降，表现为已经标注对的名字又抽错了。

批量调优的实用技巧是每次只改一个变量，把实验记录写到同一个表格里。我会记录这样几列：r、学习率、epoch、验证集实体准确率、JSON 解析失败率。没有这份记录，你会陷入“这次是学习率的问题还是数据的问题”的泥潭。另外一定不要只看训练 loss——LoRA 训练 loss 在 2 个 epoch 后通常会降得很低，但低 loss 不代表模型学会了病历字段的格式，有时候它只是学会了“复述”训练集里的 output。

4.4 训练产物管理与合并：给部署留一条退路

训练完的 LoRA adapter 默认存放在output_dir下，是一个完整的 checkpoint 目录。部署时有两种选择：一是直接让推理框架加载 adapter 和基座模型，vLLM 支持这种方式；二是把 LoRA 权重合并回基座模型，导出一个新的完整权重目录。我在实际项目里通常两种都用：测试阶段用 adapter 方式，因为切换方便；正式上线阶段用合并后的完整权重，因为加载速度更快、和现有部署脚本兼容性更好。

# 合并 LoRA adapter 到基座模型并导出 python - <<'EOF' from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base_model_path = "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B" adapter_path = "./medical_emr_lora/checkpoint-1000" model = AutoModelForCausalLM.from_pretrained(base_model_path, torch_dtype="auto") model = PeftModel.from_pretrained(model, adapter_path) merged = model.merge_and_unload() merged.save_pretrained("./medical_emr_final") tokenizer = AutoTokenizer.from_pretrained(base_model_path) tokenizer.save_pretrained("./medical_emr_final") EOF

合并这一步的逻辑是把 LoRA 低秩矩阵的权重加到基座模型的对应层上，得到一个独立完整的模型。注意merge_and_unload之后要把 tokenizer 也保存一份，不然加载时会缺 tokenizer 配置。合并完的模型直接替换 vLLM 启动命令里的模型路径。这里提醒一句：合并前的 adapter 目录先备份，不要合并完就把原始 checkpoint 删了。保持一个“能返回上一步”的流程习惯，在医疗项目里非常重要，因为你不知道下一个版本的模型什么时候会莫名其妙地变差。

5. 避坑：私有化部署与病历微调中常见的 5 个坑

5.1 显存翻车：长病历直接把上下文窗口打爆

现象：训练跑到一半报CUDA out of memory，有时候是启动部署服务时就报错，有时候是 batch 里混入一篇超长病历直接爆显存。

原因：电子病历长短差距悬殊，门诊记录几百字，大病历几千字，极少数转院记录能上万字。max_seq_length设成 8192 时，attention 的内存占用随序列长度平方增长；如果 batch 里恰好有两三篇长病历，显存峰值会远超平均值。

解决：先用脚本统计训练数据的 token 长度分布，按 90 分位设置max_seq_length，而不是按最大值。同时开启gradient_checkpointing和flash_attention，前者用计算换显存，后者大幅降低 attention 显存占用。我在 24GB 单卡上跑 7B LoRA 时，max_seq_length=4096、batch size 为 2 加上梯度累积，显存峰值能控制在 20GB 以内。

5.2 脱敏不彻底：模型把患者隐私“背”了出来

现象：微调后的模型在测试生成时，原样输出训练集里的患者姓名和身份证号。网上有人把这叫“训练数据记忆”，但在医疗场景这就是事故。

原因：正则脱敏覆盖不到非标准格式，比如“患者 张伟 男 62岁”这种没有冒号分隔的写法；或者病历里存在图片 OCR 识别来的错字，比如“张违”，正则匹配不到。

解决：脱敏之后加一道人工抽检流程，抽 5% 到 10% 的数据，直接搜索文本里是否还有身份证号正则能匹配的片段。更稳妥的做法是在脱敏基础上做字段屏蔽——把姓名、住院号、床号直接替换成[匿名化]等值的占位符，而不是保留姓氏。不要指望模型“不会记住”，只要训练数据里有，它就有概率记住。

5.3 医学缩写与口语化表述：模型输出格式乱掉

现象：病历里写“HTN 5y”“DM 2型”，模型要么不理解这个词，要么把缩写原样输出，导致下游解析逻辑拿不到标准诊断名。

原因：通用模型训练时接触的医学文本有限，对院内病历的缩略语、无标点长句、口语句式不敏感。另外电子病历里大量使用半角逗号、全角逗号混排，模型的分词策略会被带偏。

解决：在训练数据的instruction里注入一个术语表，让模型输出前做一次术语映射。术前告诉模型“HTN 代表高血压病，DM 代表 2 型糖尿病，按完整术语输出”，生成结果的规范性会明显提升。这块建议找科室医生要一份常用缩写表，比自己在网上找的全。另一个技巧是在训练数据里保留一部分原始书写风格样本，让模型见过“差数据”长什么样，而不是只喂标准样例，否则线上遇到非标准写法很容易崩溃。

5.4 单轮微调后多轮对话能力退化

现象：模型能正确抽取单段病历，但医生连续追问“那这个患者既往史再补充一下”的时候，模型直接给出通用回答，完全忘了上文。

原因：SFT 训练数据全是单轮指令-响应对，模型在微调过程中把“多轮对话”这个能力覆盖掉了。这是 SFT 的典型灾难性遗忘问题。

解决：训练数据里混入 20% 到 30% 的多轮对话样本。格式用 chat 模板，让模型看到 user 和 assistant 交替出现：

[ {"role": "user", "content": "抽取这段病历的初步诊断。"}, {"role": "assistant", "content": "{\"初步诊断\": [\"冠心病\"]}"}, {"role": "user", "content": "补充这个诊断对应的分型。"}, {"role": "assistant", "content": "{\"初步诊断\": [\"冠心病\", \"不稳定型心绞痛\"], \"分型\": \"不稳定型\"}"} ]

注意训练时SFTTrainer有内置的 chat 模板处理机制，多轮样本的字段名和单轮样本不同，要单独处理，不要混在一个字段里。混入多轮的另一个好处是，模型在应用中能更好地理解“承接上一轮”的意图，而不是把每次提问当新任务。

5.5 只看 Loss 调参数：验证集表现反而变差

现象：训练 loss 从 1.8 降到 0.2，曲线漂亮，但拿去测 20 份新病历，实体准确率不升反降，甚至 JSON 解析失败率升高。

原因：loss 下降有两种可能：真的学到了病历结构，或者只是过拟合了训练集。LoRA 秩设太高、epoch 跑太多、训练数据里相似样本重复过多，都会造成第二种情况。这时候训练集 loss 再低也没有意义。

解决：搭一个固定的验证集，每次训练完用同一个脚本跑评估，比较实体准确率和格式正确率，而不是盯着 loss 曲线。我一般把验证集设计成三个维度：已见科室的新病例、未见科室的病例、故意加入噪声的病例。第三个维度最容易暴露过拟合。调参时只参考验证集指标，不信训练 loss，这算是一条血泪经验。

6. 上线前的最后一步：用真实病历建一张评测表，别信 Loss

6.1 用 50 份真实病历搭一个固定评测集

微调完模型不要直接接业务，先建一个评测集，这个评测集在整个调优周期内保持不变。我从过往项目中总结的实践是：选 50 份脱敏后的真实病历，覆盖不同科室、不同书写风格、不同长度的文本，人工标注好答案。这些病历只在评测时使用，绝不进训练集。评测跑完后记录三个指标：实体抽取准确率、JSON 解析成功率和语义一致性评分。

每轮训练完跑一次评测，记录结果。你会发现模型在某一个科室的数据上表现变好了，但另一个科室的表现变差了。这正是评测集的价值：它能告诉你取舍的代价。比如我在一次迭代里发现，为了提升病历中“既往史”抽取的准确率，模型把“现病史”里的时间信息丢了，这种问题只看 loss 永远发现不了。

6.2 评测脚本和打分方式

评测不能全自动，格式合法性可以脚本判断，但实体准确率建议半人工复核。我通常先脚本把模型输出和标准答案做字符串匹配，输出差异列表，然后请临床背景的人复核差异项。完全自动化的评测在医疗场景不可靠，因为一个诊断名写错一个字，标准化匹配看不出来，但临床上是质控问题。复核这个过程比较费人，但这是上线前的底线。

import json, re def verify_output(text: str) -> dict: """检查模型输出能否被解析为合法 JSON，并统计字段完整性""" try: start = text.find("{") end = text.rfind("}") + 1 obj = json.loads(text[start:end]) required = ["主诉", "现病史", "初步诊断"] missing = [k for k in required if k not in obj] return {"valid": len(missing) == 0, "missing": missing} except json.JSONDecodeError: return {"valid": False, "missing": []}

这个函数只验证格式合法性和必需字段，真正的准确率还是靠人工。我自己的习惯是每次训练完找医生复核 50 份里的差异项，大约花一个小时，比系统上线后被临床科室投诉划算得多。有一次我贪方便只跑了自动化评估，觉得模型已经够好，结果上线第二天医生反馈“诊断抽出来的全是错的”，从那以后再也不敢省人工复核这一步。

调优模型这件事，说白了就是拿一份高质量的评测集当尺子，反复量、反复改。私有化部署的工程链路反而比微调本身更花时间。希望这篇笔记能把你在部署、数据、训练、调优路上可能踩的坑先标出来，让你少走几趟弯路。希望帮到你。

本文还有配套的精品资源，点击获取