简介这份PDF文档面向医疗信息化从业者、AI算法工程师及希望将大模型落地医疗场景的技术人员系统讲解基于DeepSeek构建三甲医院知识库问答系统的完整实战路径。内容涵盖医疗问答系统的背景与意义、三甲医院知识库的数据来源与特点、DeepSeek模型架构原理、微调流程与技术要点、模型评估与优化策略以及部署架构、技术挑战与解决方案、系统测试验证和实际应用案例等模块兼顾理论梳理与工程落地。资源包内含1个PDF文件大小约1.9MB共24页文档完整、条理清晰文字与图表均显示正常。目前已有121人学习下载。读者可从中获取医疗领域大模型微调的数据准备、环境搭建、训练与评估方法以及部署环节的架构设计与排错思路适合作为医疗问答系统建设的技术参考。1. 医疗问答系统落地为什么三甲知识库不能直接丢给通用大模型三甲医院信息科最近一年被问得最多的问题不是「要不要上大模型」而是「我们院内那套诊疗规范、药品说明书、科室SOP怎么让模型答得准」。通用大模型在开放域闲聊上表现不错但一碰到「我院心内科对ACS患者双抗疗程的具体建议」这类问题要么编要么答得似是而非。医疗问答系统的核心矛盾从来不是模型不够大而是知识不在模型里。这个标题讲的就是一条完整链路把三甲医院内部知识库整理成可训练语料用LoRA对DeepSeek系模型做微调再部署成能对内服务的问答接口。它解决的是「通用模型不懂我院规矩」的问题适合医院信息科工程师、医疗AI方向的后端开发以及想跑通第一个行业大模型微调的从业者。读完你应该能判断自己的知识库够不够、显卡够不够、微调到底值不值得做。2. 医疗知识库到微调语料清洗、脱敏与格式转换2.1 三甲知识库的真实形态与清洗优先级医院内部知识库的原始形态远比想象中杂乱。我见过最多的组合是PDF版诊疗指南、Word版科室SOP、Excel版药品目录、HIS系统导出的脱敏病历摘要还有一部分是内网Wiki上的问答对。这些材料直接喂给模型是灾难因为医疗文本有三个特殊问题一是大量表格和层级编号二是同一药物在不同科室叫法不同三是患者隐私字段混在正文里。清洗优先级我一般这样排先做隐私脱敏再做结构还原最后做去重。脱敏不能只靠正则匹配身份证和手机号医疗文本里真正的风险是「姓名床号诊断」的组合这类要靠NER模型先标出人名和具体日期再统一替换成占位符。结构还原指的是把PDF里的「【适应症】」「【用法用量】」这类标题还原成Markdown层级否则模型学到的是一坨连续文本推理时抓不住重点。import re from presidio_analyzer import AnalyzerEngine # 医疗文本脱敏先识别再替换避免正则误伤药品剂量 analyzer AnalyzerEngine() def deidentify_medical_text(text: str) - str: # 识别PERSON、PHONE_NUMBER、DATE_TIME等实体 results analyzer.analyze(texttext, languagezh, entities[PERSON, PHONE_NUMBER, DATE_TIME]) # 按位置倒序替换防止偏移错乱 for r in sorted(results, keylambda x: x.start, reverseTrue): placeholder f{r.entity_type} text text[:r.start] placeholder text[r.end:] return text # 结构还原把【xxx】转成## xxx保留层级 def restore_structure(text: str) - str: return re.sub(r【(.?)】, r\n## \1\n, text)这段代码的逻辑是先脱敏再还原结构顺序不能反。AnalyzerEngine默认对中文支持一般实际项目中我会换成专门的中文医疗NER模型但接口逻辑一致。参数上entities列表要按院内合规要求增减比如某些医院要求连医院名称也脱敏就加上ORG。替换用倒序是为了避免前面的替换导致后面位置偏移这是血泪经验正序替换十有八九会错位。2.2 把问答对转成DeepSeek微调格式清洗完的文本要转成模型能吃的格式。DeepSeek系模型微调常见两种格式Alpaca格式和ShareGPT格式。医疗问答场景我推荐ShareGPT因为多轮问诊的上下文关系能保留下来。一条典型的医疗微调样本长这样{ conversations: [ {from: human, value: 我院对社区获得性肺炎住院患者的初始抗菌方案是什么}, {from: gpt, value: 根据我院2024版呼吸科诊疗规范CAP住院患者初始方案为1. 轻症阿莫西林克拉维酸 1.2g q8h 静滴2. 重症头孢曲松 2g qd 联合阿奇霉素 0.5g qd。具体需结合患者肝肾功能调整。} ] }构造这类样本时答案部分必须来自知识库原文不能自己润色。我一般会写一个脚本从清洗后的Markdown里按标题切块每个「## 疾病名」下的内容作为一个知识块再用模板生成问答对。这里有个坑如果知识块太长答案会超出模型上下文需要先做摘要或分段。常见做法是控制单条答案在512 token以内超长的拆成多轮。import json def build_sharegpt_sample(question: str, answer: str) - dict: # 答案截断保护防止超长 if len(answer) 1500: answer answer[:1500] ... return { conversations: [ {from: human, value: question.strip()}, {from: gpt, value: answer.strip()} ] } samples [] for block in knowledge_blocks: q f我院对{block[title]}的诊疗建议是什么 samples.append(build_sharegpt_sample(q, block[content])) with open(medical_sft.json, w, encodingutf-8) as f: for s in samples: f.write(json.dumps(s, ensure_asciiFalse) \n)参数上1500这个截断阈值不是固定的取决于你选的基座模型上下文长度。如果用的是DeepSeek-R1-Distill-Qwen-7B上下文32K单条可以放宽到3000字。但医疗答案太长反而会让模型学到「啰嗦」的风格我一般控制在800字以内超出部分拆成「概述」和「详细方案」两条样本。3. LoRA微调DeepSeek显卡选型、参数配置与训练监控3.1 显卡与基座模型选型7B还是14B医疗问答系统微调第一个现实问题是显卡。三甲医院信息科常见的配置是单卡A100 40G或双卡RTX 4090 24G。如果是单卡40907B模型用LoRA可以跑14B就非常勉强。我的建议是知识库规模在5000条问答对以下7B足够超过2万条且问题复杂度高再考虑14B或32B。基座模型选择上DeepSeek-R1-Distill-Qwen-7B是目前医疗微调里比较稳的选择原因是它在中文医学考试题上的零样本表现已经不错LoRA只需要教它「我院的规矩」。如果院内要求必须用DeepSeek全系DeepSeek-V2-Lite也可以但MoE结构微调时要注意专家路由的稳定性新手容易翻车。配置7B LoRA14B LoRA32B LoRA显存需求16G28G48G训练速度快中慢医疗问答效果够用较好好推荐场景单科室多科室全院3.2 LoRA参数怎么设rank、alpha与学习率LoRA微调的核心参数就三个lora_rank、lora_alpha、learning_rate。医疗领域我一般用rank16、alpha32、lr1e-4起步。rank太小模型学不动专科知识太大又容易过拟合到训练集里的具体病例。alpha通常是rank的2倍这个比例在医疗文本上比较稳。from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments model_name deepseek-ai/DeepSeek-R1-Distill-Qwen-7B tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(model_name, trust_remote_codeTrue, device_mapauto) lora_config LoraConfig( r16, # rank医疗领域16起步 lora_alpha32, # 通常为rank的2倍 target_modules[q_proj, v_proj, k_proj, o_proj], # 注意力层全覆盖 lora_dropout0.05, # 小dropout防过拟合 biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./medical_lora, per_device_train_batch_size2, gradient_accumulation_steps8, # 等效batch size 16 learning_rate1e-4, num_train_epochs3, logging_steps10, save_strategyepoch, fp16True, report_tonone )target_modules我习惯把注意力层的四个投影全加上只加q和v在医疗长文本上效果会打折。gradient_accumulation_steps8配合batch_size2等效batch size 16这是单卡4090跑7B的常见配置。如果显存不够把per_device_train_batch_size降到1gradient_accumulation_steps升到16效果一样但慢一些。训练监控重点看loss曲线。医疗微调的loss通常在前100步快速下降然后进入平台期。如果loss降到0.5以下还在降大概率过拟合了需要提前停。我一般会在验证集上放200条真实科室问题每轮跑一次生成人工看答案是否还讲「人话」。3.3 训练数据配比与灾难性遗忘的规避医疗微调最容易踩的坑是灾难性遗忘模型学会了院内规范但连基本的医学常识都答错了。规避方法是在训练集里混入10%到20%的通用医学问答数据比如公开的医学考试题。这样模型在学「我院规矩」的同时不会丢掉基座的医学推理能力。# 混合数据集80%院内数据 20%通用医学数据 import random with open(medical_sft.json, r, encodingutf-8) as f: hospital_data [json.loads(line) for line in f] with open(general_medical.json, r, encodingutf-8) as f: general_data [json.loads(line) for line in f] # 按比例采样通用数据不超过20% n_general min(len(general_data), int(len(hospital_data) * 0.25)) mixed hospital_data random.sample(general_data, n_general) random.shuffle(mixed) with open(mixed_sft.json, w, encodingutf-8) as f: for item in mixed: f.write(json.dumps(item, ensure_asciiFalse) \n)这个配比不是绝对的。如果院内数据本身已经覆盖了常见病通用数据可以降到10%。判断标准是训练完后拿20个通用医学问题测一下如果答得离谱说明通用数据比例太低。4. 部署与推理从LoRA权重合并到内网API服务4.1 LoRA权重合并与量化部署训练完的LoRA权重是一个小文件部署时需要和基座模型合并或者用PEFT动态加载。内网部署我推荐合并后量化因为医院内网通常没有高端显卡量化能大幅降显存。合并用merge_and_unload量化用llama.cpp或GPTQ。from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base_model AutoModelForCausalLM.from_pretrained( deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, trust_remote_codeTrue, device_mapauto ) model PeftModel.from_pretrained(base_model, ./medical_lora) merged_model model.merge_and_unload() merged_model.save_pretrained(./medical_merged) tokenizer.save_pretrained(./medical_merged)合并后的模型可以用llama.cpp转成GGUF格式做4bit量化7B模型量化后大约4G单张RTX 3060 12G就能跑。量化会损失一点精度医疗场景我建议用Q5_K_M或Q6_K不要用Q4以下。4.2 用vLLM或Ollama搭内网问答API内网服务有两种常见做法vLLM做高并发APIOllama做轻量本地部署。如果医院信息科有K8s集群vLLM更合适如果只是科室内部几个人用Ollama足够。# Ollama部署先导入GGUF模型 echo FROM ./medical_merged.Q5_K_M.gguf Modelfile ollama create medical-qa -f Modelfile ollama run medical-qa # vLLM部署直接加载合并后的模型 python -m vllm.entrypoints.openai.api_server \ --model ./medical_merged \ --dtype float16 \ --max-model-len 4096 \ --port 8000vLLM的max-model-len要按实际问答长度设医疗问答一般2048够用设太大浪费显存。Ollama的Modelfile里可以加PARAMETER temperature 0.3医疗场景温度要低减少胡编。4.3 检索增强与微调的配合RAG知识库怎么接微调解决的是「模型懂不懂院内规矩」RAG解决的是「知识更新了怎么办」。两者不冲突我一般会同时上微调模型负责基础诊疗逻辑RAG负责最新药品目录和临时通知。知识库用Dify或FastGPT搭把清洗后的Markdown导入检索用bge-m3做embedding。# RAG检索示例用bge-m3做向量检索 from FlagEmbedding import FlagModel model FlagModel(BAAI/bge-m3, query_instruction_for_retrieval为这个医疗问题检索相关规范) query 我院对CAP住院患者的初始抗菌方案是什么 query_embedding model.encode(query) # 从向量库检索top3相关段落 results vector_store.search(query_embedding, top_k3) context \n.join([r[text] for r in results]) # 拼接到微调模型的prompt里 prompt f参考以下院内规范\n{context}\n\n问题{query}\n回答RAG的坑在于检索质量。医疗文本里「CAP」和「社区获得性肺炎」是同一个东西但embedding模型不一定能对上。常见做法是在检索前做同义词扩展把缩写和全称都查一遍。5. 医疗问答微调避坑5条血泪排查记录现象训练loss正常下降但推理时模型反复输出「根据我院规范」却不给具体内容。原因训练数据里答案部分被截断太多模型只学到了开头模板。 解决检查build_sharegpt_sample里的截断阈值确保答案完整。医疗答案宁可长一点也不要截在关键信息前。现象模型对训练集里的疾病答得很准但换个问法就答错。原因问答对构造时问题模板太单一模型过拟合到固定句式。 解决每个知识块生成3到5种不同问法比如「XX怎么治」「XX的诊疗方案」「我院对XX的建议」混入训练集。现象微调后模型开始胡编药品剂量。原因训练数据里混入了未脱敏的真实病例模型把个案当成了通用规范。 解决训练前必须做病例级脱敏把具体患者信息替换成占位符且个案数据不要超过训练集的5%。现象部署后并发一高就OOM。原因vLLM的max-model-len设太大或者gpu_memory_utilization没调。 解决max-model-len按实际问答长度设2048gpu_memory_utilization从0.8开始试逐步往上加。现象RAG检索出来的段落和问题不相关。原因知识库切块太粗一个块里混了多个疾病。 解决按Markdown标题切块每个「## 疾病名」独立成块块内再按段落细分检索粒度控制在300字左右。6. 效果验证与持续迭代用真实科室问题做回归测试微调完不是终点医疗问答系统最怕的是「上线后答错没人发现」。我一般会建一个回归测试集从各科室收集50到100条真实问题每条标注标准答案每次模型更新后跑一遍看准确率和幻觉率。# 回归测试批量跑测试集统计准确率 import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keynone) with open(regression_test.json, r, encodingutf-8) as f: test_cases [json.loads(line) for line in f] correct 0 hallucination 0 for case in test_cases: response client.chat.completions.create( modelmedical-merged, messages[{role: user, content: case[question]}], temperature0.3 ) answer response.choices[0].message.content # 简单关键词匹配实际项目用LLM做裁判 if case[keyword] in answer: correct 1 elif 根据我院 in answer and case[keyword] not in answer: hallucination 1 print(f准确率{correct/len(test_cases):.2%}幻觉率{hallucination/len(test_cases):.2%})这个脚本里用关键词匹配只是示意实际项目我会用另一个LLM做裁判判断答案是否和标准答案语义一致。温度设0.3是医疗场景的常用值再低会太死板再高会胡编。持续迭代的节奏我一般是一个月一次收集这一个月内用户点「不满意」的问题人工标注后加入训练集重新跑LoRA。注意不要每次全量重训用增量数据微调上一版模型即可这样既省显卡又不会遗忘。最后说个我自己的习惯每次微调前先拿基座模型跑一遍测试集记录基线。微调后如果准确率提升不到10%我会先怀疑数据质量而不是调参。医疗问答系统这件事数据清洗的功夫占七成微调参数只占三成。希望帮到你。本文还有配套的精品资源点击获取 三甲医院知识库微调DeepSeek：LoRA实战与医疗问答系统部署
简介这份PDF文档面向医疗信息化从业者、AI算法工程师及希望将大模型落地医疗场景的技术人员系统讲解基于DeepSeek构建三甲医院知识库问答系统的完整实战路径。内容涵盖医疗问答系统的背景与意义、三甲医院知识库的数据来源与特点、DeepSeek模型架构原理、微调流程与技术要点、模型评估与优化策略以及部署架构、技术挑战与解决方案、系统测试验证和实际应用案例等模块兼顾理论梳理与工程落地。资源包内含1个PDF文件大小约1.9MB共24页文档完整、条理清晰文字与图表均显示正常。目前已有121人学习下载。读者可从中获取医疗领域大模型微调的数据准备、环境搭建、训练与评估方法以及部署环节的架构设计与排错思路适合作为医疗问答系统建设的技术参考。1. 医疗问答系统落地为什么三甲知识库不能直接丢给通用大模型三甲医院信息科最近一年被问得最多的问题不是「要不要上大模型」而是「我们院内那套诊疗规范、药品说明书、科室SOP怎么让模型答得准」。通用大模型在开放域闲聊上表现不错但一碰到「我院心内科对ACS患者双抗疗程的具体建议」这类问题要么编要么答得似是而非。医疗问答系统的核心矛盾从来不是模型不够大而是知识不在模型里。这个标题讲的就是一条完整链路把三甲医院内部知识库整理成可训练语料用LoRA对DeepSeek系模型做微调再部署成能对内服务的问答接口。它解决的是「通用模型不懂我院规矩」的问题适合医院信息科工程师、医疗AI方向的后端开发以及想跑通第一个行业大模型微调的从业者。读完你应该能判断自己的知识库够不够、显卡够不够、微调到底值不值得做。2. 医疗知识库到微调语料清洗、脱敏与格式转换2.1 三甲知识库的真实形态与清洗优先级医院内部知识库的原始形态远比想象中杂乱。我见过最多的组合是PDF版诊疗指南、Word版科室SOP、Excel版药品目录、HIS系统导出的脱敏病历摘要还有一部分是内网Wiki上的问答对。这些材料直接喂给模型是灾难因为医疗文本有三个特殊问题一是大量表格和层级编号二是同一药物在不同科室叫法不同三是患者隐私字段混在正文里。清洗优先级我一般这样排先做隐私脱敏再做结构还原最后做去重。脱敏不能只靠正则匹配身份证和手机号医疗文本里真正的风险是「姓名床号诊断」的组合这类要靠NER模型先标出人名和具体日期再统一替换成占位符。结构还原指的是把PDF里的「【适应症】」「【用法用量】」这类标题还原成Markdown层级否则模型学到的是一坨连续文本推理时抓不住重点。import re from presidio_analyzer import AnalyzerEngine # 医疗文本脱敏先识别再替换避免正则误伤药品剂量 analyzer AnalyzerEngine() def deidentify_medical_text(text: str) - str: # 识别PERSON、PHONE_NUMBER、DATE_TIME等实体 results analyzer.analyze(texttext, languagezh, entities[PERSON, PHONE_NUMBER, DATE_TIME]) # 按位置倒序替换防止偏移错乱 for r in sorted(results, keylambda x: x.start, reverseTrue): placeholder f{r.entity_type} text text[:r.start] placeholder text[r.end:] return text # 结构还原把【xxx】转成## xxx保留层级 def restore_structure(text: str) - str: return re.sub(r【(.?)】, r\n## \1\n, text)这段代码的逻辑是先脱敏再还原结构顺序不能反。AnalyzerEngine默认对中文支持一般实际项目中我会换成专门的中文医疗NER模型但接口逻辑一致。参数上entities列表要按院内合规要求增减比如某些医院要求连医院名称也脱敏就加上ORG。替换用倒序是为了避免前面的替换导致后面位置偏移这是血泪经验正序替换十有八九会错位。2.2 把问答对转成DeepSeek微调格式清洗完的文本要转成模型能吃的格式。DeepSeek系模型微调常见两种格式Alpaca格式和ShareGPT格式。医疗问答场景我推荐ShareGPT因为多轮问诊的上下文关系能保留下来。一条典型的医疗微调样本长这样{ conversations: [ {from: human, value: 我院对社区获得性肺炎住院患者的初始抗菌方案是什么}, {from: gpt, value: 根据我院2024版呼吸科诊疗规范CAP住院患者初始方案为1. 轻症阿莫西林克拉维酸 1.2g q8h 静滴2. 重症头孢曲松 2g qd 联合阿奇霉素 0.5g qd。具体需结合患者肝肾功能调整。} ] }构造这类样本时答案部分必须来自知识库原文不能自己润色。我一般会写一个脚本从清洗后的Markdown里按标题切块每个「## 疾病名」下的内容作为一个知识块再用模板生成问答对。这里有个坑如果知识块太长答案会超出模型上下文需要先做摘要或分段。常见做法是控制单条答案在512 token以内超长的拆成多轮。import json def build_sharegpt_sample(question: str, answer: str) - dict: # 答案截断保护防止超长 if len(answer) 1500: answer answer[:1500] ... return { conversations: [ {from: human, value: question.strip()}, {from: gpt, value: answer.strip()} ] } samples [] for block in knowledge_blocks: q f我院对{block[title]}的诊疗建议是什么 samples.append(build_sharegpt_sample(q, block[content])) with open(medical_sft.json, w, encodingutf-8) as f: for s in samples: f.write(json.dumps(s, ensure_asciiFalse) \n)参数上1500这个截断阈值不是固定的取决于你选的基座模型上下文长度。如果用的是DeepSeek-R1-Distill-Qwen-7B上下文32K单条可以放宽到3000字。但医疗答案太长反而会让模型学到「啰嗦」的风格我一般控制在800字以内超出部分拆成「概述」和「详细方案」两条样本。3. LoRA微调DeepSeek显卡选型、参数配置与训练监控3.1 显卡与基座模型选型7B还是14B医疗问答系统微调第一个现实问题是显卡。三甲医院信息科常见的配置是单卡A100 40G或双卡RTX 4090 24G。如果是单卡40907B模型用LoRA可以跑14B就非常勉强。我的建议是知识库规模在5000条问答对以下7B足够超过2万条且问题复杂度高再考虑14B或32B。基座模型选择上DeepSeek-R1-Distill-Qwen-7B是目前医疗微调里比较稳的选择原因是它在中文医学考试题上的零样本表现已经不错LoRA只需要教它「我院的规矩」。如果院内要求必须用DeepSeek全系DeepSeek-V2-Lite也可以但MoE结构微调时要注意专家路由的稳定性新手容易翻车。配置7B LoRA14B LoRA32B LoRA显存需求16G28G48G训练速度快中慢医疗问答效果够用较好好推荐场景单科室多科室全院3.2 LoRA参数怎么设rank、alpha与学习率LoRA微调的核心参数就三个lora_rank、lora_alpha、learning_rate。医疗领域我一般用rank16、alpha32、lr1e-4起步。rank太小模型学不动专科知识太大又容易过拟合到训练集里的具体病例。alpha通常是rank的2倍这个比例在医疗文本上比较稳。from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments model_name deepseek-ai/DeepSeek-R1-Distill-Qwen-7B tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(model_name, trust_remote_codeTrue, device_mapauto) lora_config LoraConfig( r16, # rank医疗领域16起步 lora_alpha32, # 通常为rank的2倍 target_modules[q_proj, v_proj, k_proj, o_proj], # 注意力层全覆盖 lora_dropout0.05, # 小dropout防过拟合 biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./medical_lora, per_device_train_batch_size2, gradient_accumulation_steps8, # 等效batch size 16 learning_rate1e-4, num_train_epochs3, logging_steps10, save_strategyepoch, fp16True, report_tonone )target_modules我习惯把注意力层的四个投影全加上只加q和v在医疗长文本上效果会打折。gradient_accumulation_steps8配合batch_size2等效batch size 16这是单卡4090跑7B的常见配置。如果显存不够把per_device_train_batch_size降到1gradient_accumulation_steps升到16效果一样但慢一些。训练监控重点看loss曲线。医疗微调的loss通常在前100步快速下降然后进入平台期。如果loss降到0.5以下还在降大概率过拟合了需要提前停。我一般会在验证集上放200条真实科室问题每轮跑一次生成人工看答案是否还讲「人话」。3.3 训练数据配比与灾难性遗忘的规避医疗微调最容易踩的坑是灾难性遗忘模型学会了院内规范但连基本的医学常识都答错了。规避方法是在训练集里混入10%到20%的通用医学问答数据比如公开的医学考试题。这样模型在学「我院规矩」的同时不会丢掉基座的医学推理能力。# 混合数据集80%院内数据 20%通用医学数据 import random with open(medical_sft.json, r, encodingutf-8) as f: hospital_data [json.loads(line) for line in f] with open(general_medical.json, r, encodingutf-8) as f: general_data [json.loads(line) for line in f] # 按比例采样通用数据不超过20% n_general min(len(general_data), int(len(hospital_data) * 0.25)) mixed hospital_data random.sample(general_data, n_general) random.shuffle(mixed) with open(mixed_sft.json, w, encodingutf-8) as f: for item in mixed: f.write(json.dumps(item, ensure_asciiFalse) \n)这个配比不是绝对的。如果院内数据本身已经覆盖了常见病通用数据可以降到10%。判断标准是训练完后拿20个通用医学问题测一下如果答得离谱说明通用数据比例太低。4. 部署与推理从LoRA权重合并到内网API服务4.1 LoRA权重合并与量化部署训练完的LoRA权重是一个小文件部署时需要和基座模型合并或者用PEFT动态加载。内网部署我推荐合并后量化因为医院内网通常没有高端显卡量化能大幅降显存。合并用merge_and_unload量化用llama.cpp或GPTQ。from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base_model AutoModelForCausalLM.from_pretrained( deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, trust_remote_codeTrue, device_mapauto ) model PeftModel.from_pretrained(base_model, ./medical_lora) merged_model model.merge_and_unload() merged_model.save_pretrained(./medical_merged) tokenizer.save_pretrained(./medical_merged)合并后的模型可以用llama.cpp转成GGUF格式做4bit量化7B模型量化后大约4G单张RTX 3060 12G就能跑。量化会损失一点精度医疗场景我建议用Q5_K_M或Q6_K不要用Q4以下。4.2 用vLLM或Ollama搭内网问答API内网服务有两种常见做法vLLM做高并发APIOllama做轻量本地部署。如果医院信息科有K8s集群vLLM更合适如果只是科室内部几个人用Ollama足够。# Ollama部署先导入GGUF模型 echo FROM ./medical_merged.Q5_K_M.gguf Modelfile ollama create medical-qa -f Modelfile ollama run medical-qa # vLLM部署直接加载合并后的模型 python -m vllm.entrypoints.openai.api_server \ --model ./medical_merged \ --dtype float16 \ --max-model-len 4096 \ --port 8000vLLM的max-model-len要按实际问答长度设医疗问答一般2048够用设太大浪费显存。Ollama的Modelfile里可以加PARAMETER temperature 0.3医疗场景温度要低减少胡编。4.3 检索增强与微调的配合RAG知识库怎么接微调解决的是「模型懂不懂院内规矩」RAG解决的是「知识更新了怎么办」。两者不冲突我一般会同时上微调模型负责基础诊疗逻辑RAG负责最新药品目录和临时通知。知识库用Dify或FastGPT搭把清洗后的Markdown导入检索用bge-m3做embedding。# RAG检索示例用bge-m3做向量检索 from FlagEmbedding import FlagModel model FlagModel(BAAI/bge-m3, query_instruction_for_retrieval为这个医疗问题检索相关规范) query 我院对CAP住院患者的初始抗菌方案是什么 query_embedding model.encode(query) # 从向量库检索top3相关段落 results vector_store.search(query_embedding, top_k3) context \n.join([r[text] for r in results]) # 拼接到微调模型的prompt里 prompt f参考以下院内规范\n{context}\n\n问题{query}\n回答RAG的坑在于检索质量。医疗文本里「CAP」和「社区获得性肺炎」是同一个东西但embedding模型不一定能对上。常见做法是在检索前做同义词扩展把缩写和全称都查一遍。5. 医疗问答微调避坑5条血泪排查记录现象训练loss正常下降但推理时模型反复输出「根据我院规范」却不给具体内容。原因训练数据里答案部分被截断太多模型只学到了开头模板。 解决检查build_sharegpt_sample里的截断阈值确保答案完整。医疗答案宁可长一点也不要截在关键信息前。现象模型对训练集里的疾病答得很准但换个问法就答错。原因问答对构造时问题模板太单一模型过拟合到固定句式。 解决每个知识块生成3到5种不同问法比如「XX怎么治」「XX的诊疗方案」「我院对XX的建议」混入训练集。现象微调后模型开始胡编药品剂量。原因训练数据里混入了未脱敏的真实病例模型把个案当成了通用规范。 解决训练前必须做病例级脱敏把具体患者信息替换成占位符且个案数据不要超过训练集的5%。现象部署后并发一高就OOM。原因vLLM的max-model-len设太大或者gpu_memory_utilization没调。 解决max-model-len按实际问答长度设2048gpu_memory_utilization从0.8开始试逐步往上加。现象RAG检索出来的段落和问题不相关。原因知识库切块太粗一个块里混了多个疾病。 解决按Markdown标题切块每个「## 疾病名」独立成块块内再按段落细分检索粒度控制在300字左右。6. 效果验证与持续迭代用真实科室问题做回归测试微调完不是终点医疗问答系统最怕的是「上线后答错没人发现」。我一般会建一个回归测试集从各科室收集50到100条真实问题每条标注标准答案每次模型更新后跑一遍看准确率和幻觉率。# 回归测试批量跑测试集统计准确率 import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keynone) with open(regression_test.json, r, encodingutf-8) as f: test_cases [json.loads(line) for line in f] correct 0 hallucination 0 for case in test_cases: response client.chat.completions.create( modelmedical-merged, messages[{role: user, content: case[question]}], temperature0.3 ) answer response.choices[0].message.content # 简单关键词匹配实际项目用LLM做裁判 if case[keyword] in answer: correct 1 elif 根据我院 in answer and case[keyword] not in answer: hallucination 1 print(f准确率{correct/len(test_cases):.2%}幻觉率{hallucination/len(test_cases):.2%})这个脚本里用关键词匹配只是示意实际项目我会用另一个LLM做裁判判断答案是否和标准答案语义一致。温度设0.3是医疗场景的常用值再低会太死板再高会胡编。持续迭代的节奏我一般是一个月一次收集这一个月内用户点「不满意」的问题人工标注后加入训练集重新跑LoRA。注意不要每次全量重训用增量数据微调上一版模型即可这样既省显卡又不会遗忘。最后说个我自己的习惯每次微调前先拿基座模型跑一遍测试集记录基线。微调后如果准确率提升不到10%我会先怀疑数据质量而不是调参。医疗问答系统这件事数据清洗的功夫占七成微调参数只占三成。希望帮到你。本文还有配套的精品资源点击获取