简介这是一份面向AI大模型应用开发者与自然语言处理学习者的中文医疗问答机器人项目资源围绕大模型微调在垂直场景中的落地展开解决医疗咨询中常见问题的自动应答需求。代码组织结构清晰覆盖交互应用、命令行工具与配置模块适合具备Python基础、希望系统了解大模型微调应用实践的开发者参考。压缩包共11个文件含4个Python脚本、4张界面示意与形象图片、1份README说明文档、1份requirements依赖清单以及.gitignore文件整体仅539KB轻量便于快速部署。目前已有176人学习浏览。借助该项目可以掌握中文医疗问答机器人的项目骨架、模块划分与依赖配置理解大模型微调后如何封装成可用应用附带的说明文档与依赖文件也可作为二次开发及迁移到其他问答领域的起点是AI大模型实战入门与方案复现的不错素材。1. 中文医疗问答为什么必须走微调这条路先说结论拿通用大模型直接做中文医疗问答效果看起来不错但一旦追问到具体用药剂量、禁忌症、术后护理它就开始“一本正经地胡说八道”而且很难通过提示词工程彻底修好。这个基于大模型微调的中文医疗问答机器人项目核心动作不是“调接口”而是用一批高质量的中文医疗问答对让基座模型在特定知识分布上重新学习一轮。它能解决的核心问题是让模型在医疗场景下说话更稳、更收敛减少幻觉同时保留通用对话能力。适合谁去复现两类人。一类是刚接触大模型微调、想在一个垂直领域里跑通全流程的从业者另一类是医院信息科、健康管理平台、医药公司的技术同学他们需要私有化部署一个能回答患者常见问题的机器人但又不想从头训练模型。全文会拆解数据准备、基座选型、微调参数、部署上线和效果验证这五段路每一步都给出可直接抄作业的命令和参数也会把最容易翻车的几个坑提前标出来。2. 准备中文医疗问答数据集格式、清洗与质检微调这件事数据质量直接决定模型上限。模型结构、训练参数解决的问题是“逼近数据分布”而数据本身对不对、全不全才是模型能不能用的前提。这一章从数据格式讲到质检流程属于整个项目里最耗时、也最值得花力气的一步。2.1 微调数据格式从JSON到ShareGPT结构的取舍常见的中文医疗问答微调数据有两条主流格式路线一是原生的[INST]指令格式二是 ShareGPT 多轮对话格式。对于问答机器人项目我一般直接选 ShareGPT 结构因为医疗问答天然是多轮场景——患者会补充症状描述医生会追问既往病史。用单轮指令微调出来的模型一旦用户连续追问两句就容易“失忆”。[ { conversations: [ { role: system, content: 你是专业的中文医疗问答助手。回答要严谨、克制不确定的信息必须说明。 }, { role: user, content: 我最近两周经常头晕特别是早上起床的时候血压测量在145/95左右需要吃药吗 }, { role: assistant, content: 根据你描述的症状和血压数值属于轻度高血压的范畴。是否需要立即用药取决于是否有靶器官损害、糖尿病等合并症。单次血压测量不足以决定用药方案建议连续监测一周晨起和睡前血压并记录心率。如果出现持续头痛、视物模糊需要尽快就诊。 } ] } ]上面这个结构里system角色负责设定模型在问答时的行为边界user是病史描述assistant是标准回答。需要说明的是医疗问答数据里assistant内容必须经过人工或权威信源校验不能直接从通用爬虫数据里抽。参数方面如果把system角色去掉模型在推理时就要靠用户输入来暗示“你是医生”稳定性会差不少所以我建议保留这个字段。2.2 数据来源与清洗从公开知识库到人工标注没有现成数据的话常见做法是从药品说明书、临床指南公开摘要、医院健康宣教材料里抽取问答对。具体操作上可以用pdfplumber把 PDF 转成文本再用规则或小模型做句对切分。但这一步切出来的东西非常脏必须有清洗步骤。import json import re def clean_medical_text(text): # 去掉参考文献标记、DOI、网址等非正文内容 text re.sub(r\[\d\], , text) text re.sub(rhttp\S, , text) text re.sub(rdoi:\S, , text) # 去掉PDF页眉页脚常见的孤立数字 text re.sub(r\n\d{1,3}\n, \n, text) # 全角括号统一为半角 text text.replace(, ().replace(, )) return text.strip() raw_lines open(medical_corpus.txt, encodingutf-8).readlines() cleaned_qa_pairs [] for line in raw_lines: line clean_medical_text(line) # 长度过滤过短的句子没有训练价值 if len(line) 20 or len(line) 512: continue # 简单粗暴的“问句/答句”拆法只作为初稿 if in line or ? in line: parts re.split(r[?], line, maxsplit1) if len(parts) 2 and len(parts[1]) 10: cleaned_qa_pairs.append({ user: parts[0] , assistant: parts[1].replace(答:, ).replace(答案:, ).strip() }) print(f初筛得到 {len(cleaned_qa_pairs)} 条问答对)这段代码的核心逻辑是先做格式和噪音清理再按问号切分问答对。切分之后必须有人工抽检一般按 10% 的比例抽发现错误率超过 5% 就必须调整清洗规则或换数据源。这里有个容易踩的坑如果原始语料本身就是“病历诊断结论”式的书面文本切出来的“问句”根本不是患者的真实口语模型学完会把用户当成医生、回答变成病历书写样式。2.3 数据量级与分布检查5000条不代表能用微调数据量不是越多越好而是越均衡越好。针对“中文医疗问答机器人”这个场景5000 条优质数据通常就能看到明显效果前提是覆盖内科、外科、妇科、儿科、皮肤科、用药咨询等常见子领域。如果 5000 条里 80% 都是感冒发烧模型对糖尿病、高血压的问题依然会瞎编。我一般会用简单的领域关键词做一次分布统计from collections import Counter def tag_domain(text): domain_keywords { 心血管: [高血压, 冠心病, 心律, 心绞痛], 消化: [胃炎, 腹泻, 便秘, 胃溃疡], 呼吸: [咳嗽, 哮喘, 肺炎, 支气管], 内分泌: [糖尿病, 甲状腺, 血糖], 皮肤: [湿疹, 痤疮, 皮炎, 荨麻疹], } for domain, words in domain_keywords.items(): for w in words: if w in text: return domain return 其他 domain_counter Counter() for pair in cleaned_qa_pairs: domain_counter.update([tag_domain(pair[user])]) print(domain_counter.most_common())输出结果如果某个领域占比超过 40%建议对多的领域做降采样对少的领域补充数据。补充数据没有捷径要么从更垂直的信源里抽取要么找医生团队人工写。顺带提醒医疗问答项目里“其他”类数据占比太低的话模型会对没见过的病名产生“强行归因”的倾向把不相关的症状关联起来。3. 基座模型选型为什么是Qwen2.5-7B而不是更大的模型基座模型的选择决定了微调成本、推理成本和效果上限。中文医疗问答这个场景里7B 左右的模型是目前性价比最稳的档位。参数再多单卡训练和线上推理的压力会成倍增加参数再少比如 1.5B医疗回答的完整性和逻辑性明显不够。这里以 Qwen2.5-7B 为例展开因为它对中文的支持、指令遵循能力和开源生态在国内环境里最省心。3.1 基座选择的核心指标中文能力、上下文长度、许可证选基座模型不是只看跑分。对医疗问答而言中文理解能力排在第一位。像 Qwen2.5-7B-Instruct 这种已经做过指令微调的版本直接拿来做医疗问答微调是可以的而且往往比用 Base 版本效果更好——因为 Base 版本在通用对话上不够“听话”微调时需要用大量指令数据去弥补浪费训练资源。上下文长度方面Qwen2.5-7B 支持 32K 以上足够容纳完整的多轮问诊对话。许可证也要看仔细。如果是商业项目必须确认基座模型的开源协议允许商用及其衍生品。Qwen 系列采用 Apache 2.0 协议商用和二次分发都比较宽松这也是我推荐它作为医疗问答基座的原因之一。另一个被低估的点是生态兼容性Qwen2.5 系列的模型和 Transformers、vLLM、LlamaFactory 这些常用工程栈兼容好踩坑时容易搜到解决方案。3.2 全参微调还是LoRA医疗场景选LoRA的理由全参微调Full Fine-tuning能让模型学得更彻底但 7B 模型的全参微调至少需要 3-4 张 24GB 显存的显卡而且训练出来的模型会覆盖掉基座原有的通用能力。对医疗问答机器人来说我们既要专业领域的准确性又不能丢掉日常寒暄能力——患者问一句“谢谢你”模型不能变成只会开药的机器。LoRALow-Rank Adaptation是目前这个场景的主流做法。它的思路是冻结基座模型全部参数只训练注入的少量低秩矩阵。实际训练时显存占用降到原来的三分之一左右一张 24GB 显卡就能跑 7B 模型而且可以通过调整r秩和alpha参数来控制适应强度。训练完后LoRA 权重是一个很小的文件通常几十到几百MB和基座模型解耦部署时随时可以卸载这就是所谓的“后悔药”。3.3 基于LlamaFactory的训练配置完整可跑的示例LlamaFactory 是目前国内社区最常用的大模型微调工具封装了数据格式转换、LoRA 训练、模型导出全流程。安装和启动命令如下# 创建虚拟环境Python 3.10 验证过比较稳 conda create -n llama_factory python3.10 -y conda activate llama_factory # 安装依赖 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install llama-factory[metrics] # 启动WebUI界面也支持命令行训练 CUDA_VISIBLE_DEVICES0 llamafactory-cli webui启动 WebUI 后在界面里按如下配置加载模型名称选择 Qwen2.5-7B-Instruct微调方法选 LoRA数据集选择你已经格式化为 ShareGPT 结构的医疗问答 JSON。训练参数方面几个关键值我建议这样设# 该配置用于LoRA微调基于单张RTX 4090 24G model_name_or_path: Qwen/Qwen2.5-7B-Instruct stage: sft finetuning_type: lora dataset: medical_qa_sharegpt template: qwen cutoff_len: 2048 learning_rate: 2.0e-5 num_train_epochs: 3 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 lr_scheduler_type: cosine warmup_ratio: 0.1 lora_rank: 32 lora_alpha: 64 lora_dropout: 0.05 logging_steps: 10 save_steps: 100 output_dir: outputs/medical_qwen_loracutoff_len设为 2048 而不是 8192因为医疗问答样本普遍不会太长太长的截断窗口只会浪费显存。learning_rate: 2.0e-5是 LoRA 微调的安全起点大于 5e-5 很容易让模型在几个 epoch 后过拟合表现为回答里反复出现训练集中的原句。per_device_train_batch_size设 2、梯度累积设 8等效 batch size 是 16这个量级对 5000 条数据来说足够稳定。训练时如果显存不足优先把cutoff_len降到 1536而不是调 batch size。4. 模型部署与机器人服务化从LoRA权重到可调用的API训练完成只是第一步。医疗问答机器人要做到可用必须把模型包装成服务接口供前端或业务系统调用。这里涉及两条路线一是把 LoRA 权重和基座模型合并导出成完整模型后用推理框架部署二是使用支持 LoRA 插件的推理服务在加载基座模型的同时动态加载 LoRA 权重。常见做法是合并且导出因为后续上线维护简单不容易出现框架版本不兼容的问题。4.1 合并LoRA权重并导出完整模型LlamaFactory 提供了模型导出脚本。合并的原理是把训练得到的低秩矩阵按公式加回原始权重矩阵W_new W_old (B × A) / alpha。合并一次之后LoRA 文件就可以不再依赖训练环境了。python src/llamafactory/export_model.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path outputs/medical_qwen_lora \ --template qwen \ --finetuning_type lora \ --export_dir models/medical_qwen_merged \ --export_size 4 \ --export_legacy_format false--export_size 4表示分片保存为 4GB 一个的权重文件便于后续拷贝和部署。--export_legacy_format false表示用新版safetensors格式导出不生成旧的bin权重。合并完成后建议检查一下models/medical_qwen_merged目录下是否生成了config.json、tokenizer.json和model-*.safetensors这些关键文件。缺文件的话多半是 LoRA 适配器的adapter_config.json里路径写错把model_name_or_path指到了训练时的临时目录。4.2 用vLLM部署API服务参数调优与并发控制vLLM 是目前工业界最常用的大模型推理服务框架支持 PagedAttention 连续批处理吞吐量比原生 Transformers 高数倍。这里给出一个面向医疗问答场景的 vLLM 部署配置CUDA_VISIBLE_DEVICES0 python -m vllm.entrypoints.openai.api_server \ --model models/medical_qwen_merged \ --tokenizer Qwen/Qwen2.5-7B-Instruct \ --served-model-name medical-qa \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 4 \ --temperature 0.3 \ --top-p 0.85--gpu-memory-utilization 0.9表示允许 vLLM 占用 90% 的显存用于 KV cache预留一部分给模型权重和中间计算。--max-num-seqs 4限制最大并发序列数避免多路请求同时打到显存溢出的临界点。--temperature 0.3和--top-p 0.85是医疗场景比较合适的生成参数——温度太高会“编”症状太低又会让回答变得机械。服务启动后通过 OpenAI 兼容接口进行验证from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) completion client.chat.completions.create( modelmedical-qa, messages[ {role: system, content: 你是专业的中文医疗问答助手。}, {role: user, content: 孩子发烧38.5度精神还可以要先吃药还是先物理降温} ], temperature0.3, max_tokens512 ) print(completion.choices[0].message.content)max_tokens建议控制在 512 以内。医疗问答的回答太长容易超出患者耐心也增加内容被断章取义的风险。服务端返回后应用层要做一层缓存同一个问题在短时间内重复请求时直接返回缓存结果减少 GPU 压力。vLLM 本身不提供业务缓存层这个逻辑应当写在调用方或网关里。4.3 前端接入与流式输出的异常处理患者问诊的体验要求首字响应快因此前端接入时要开启流式输出SSE。vLLM 原生支持 OpenAI 接口的streamTrue参数。前端用 EventSource 或 fetch 的 ReadableStream 接收增量 token。这一步容易出问题的点在于网络断开时的半截回答——患者看到的可能是“建议你去医院做……”就中断了。async function streamChat(messages) { const response await fetch(http://localhost:8000/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: medical-qa, messages: messages, stream: true, temperature: 0.3, max_tokens: 512 }) }); const reader response.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; let finalText ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { if (line.startsWith(data: )) { const payload line.slice(6); if (payload [DONE]) continue; const json JSON.parse(payload); const token json.choices[0]?.delta?.content || ; finalText token; renderStreamingText(finalText); } } } }这段代码里buffer的逐行拼接是为了处理 SSE 数据包在传输层被拆分的边界情况。如果不等data:开头的行结束就解析会把半截 JSON 传给JSON.parse导致报错。renderStreamingText是前端渲染函数每收到一段 token 就更新一次页面文本如果传输中断前端要基于finalText展示“回答不完整请重新提问”的提示而不是让患者看到一句断了半截的“医嘱”。5. 微调过程避坑与常见问题排查大模型微调不是交上去跑完就行的“黑匣子”训练过程会遇到各种奇奇怪怪的问题。这一章把最常翻车的 4 个点按“现象→原因→解决”的结构列出来每一行都是从实际跑训练的人那里验证过的血泪经验。5.1 训练Loss不降或者一开始就特别低现象loss 在第一个 step 就是 0.1或训练了 500 步还在 2.0 以上不动。原因loss 一开始就极低多半是数据标签泄漏——Assistant 的回答内容出现在了训练输入里模型根本没在学生成而是在背答案。loss 不降则大概率是学习率太小或数据长度被cutoff_len截断后导致大量样本不完整。解决先检查数据集确保 ShareGPT 结构里user字段和assistant字段没有内容重复。再把cutoff_len调大到 4096 看一眼是否改善如果训练集里 20% 以上的样本长度超过 2048必须增加长度而不是强行截断。5.2 微调后模型输出重复或“念经”现象回答生成三句话之后开始重复同一段话甚至输出无意义的“嗯嗯嗯”。原因num_train_epochs太大或learning_rate太高导致 LoRA 权重过拟合到了训练集的局部模式。另一个常见原因是生成参数里repeat_penalty没生效模型陷入重复采样循环。解决把learning_rate从 2e-5 降到 1e-5num_train_epochs从 3 降到 2。如果还没改善在 vLLM 部署参数里追加--repetition-penalty 1.05这个值对中文生成重复问题有实效。5.3 中文医疗术语被“拼音化”或乱码现象模型把“高血压”写成“gaoxueya”或者对话里出现“|im_end|”等特殊 token 标记。原因训练时template选错。Qwen2.5 系列必须用qwen模板如果误用了llama模板tokenizer 的 chat template 不匹配生成的文本就会出现特殊标记或拼音。解决在 LlamaFactory 里确认template: qwen且tokenizer_path和model_name_or_path指向同一个基座模型。合并导出后依然出现特殊标记就检查部署时的--tokenizer参数是否也指向同一个 tokenizer 目录。5.4 显存溢出OOM怎么调都炸现象训练刚开始就报CUDA out of memory或者在 eval 阶段炸掉。原因per_device_train_batch_size太大或cutoff_len太长。7B LoRA 微调在 24G 显存上batch size 为 2、序列长度 2048 时接近临界如果你开了 eval 且per_device_eval_batch_size等于 2两倍显存叠加就会在验证阶段崩。解决把per_device_train_batch_size设为 1、gradient_accumulation_steps设为 16等效 batch size 仍为 16同时设per_device_eval_batch_size: 1。留意机器上是否有其他进程占用显存用nvidia-smi确认可用显存再启动训练。提示以上四条只是高频坑。如果你训练时的报错信息跟“过拟合”“模板”“显存”三条主线都无关优先怀疑环境版本不匹配——transformers、peft、accelerate 三者版本需要同步升级不要只升级其中一个包。6. 进阶给微调后的模型做“医疗问答安全护栏”验证模型能回答问题了不等于可以放给患者用。我们做的是医疗问答回答错误造成的后果比其他领域严重得多。最后一章讲一个进阶方法在推理层加一套双层校验把“毒回答”拦截在输出之前。这里不讨论对抗攻击只讲常规的质量门禁。第一层是“领域识别”。有些用户问的根本不是医疗问题比如“今天天气怎么样”。与其让医疗模型硬答不如用意图分类或关键词规则把问题分流——非医疗问题直接回复“当前助手仅提供医疗健康知识其他问题请咨询相关平台”。这个逻辑可以做一个轻量级的规则函数def is_medical_related(text: str) - bool: medical_markers [药, 痛, 发烧, 咳嗽, 血压, 血糖, 手术, 挂号, 科室, 症状, 检查, 治疗, 饮食, 过敏] return any(marker in text for marker in medical_markers)这个函数在服务端作用效果是减少医疗模型在非专业领域的乱答。参数上关键词列表可以放到配置文件里运营人员随时增删不需要重新部署模型。第二层是“安全拒答”。模型在回答里如果出现绝对的用药剂量、明确的诊断结论系统要在前端给出免责提示或引导线下就诊。最简单的方式是让system提示词强制模型在回答末尾加上“以上信息仅供参考如症状持续请及时就医”。但这句提示不能让用户厌烦所以只在模型输出超过 80 字时触发一次。最后分享一个个人习惯每次微调完我都会把训练集里 100 条验证样本的预测结果单独导出成 JSON逐条核对模型的回答有没有照抄训练集原句。照抄率高过 20%说明模型是“背题”而不是“理解”我会立刻回退到旧权重并调高lora_dropout。这种检查看起来很原始但比任何评测分数都更能暴露模型的真实可用度。全文走完之后你的产出应该是一个已经跑通的 API 服务一个能够回答常见医疗问题、并且知道什么时候该说“不确定”的中文问答机器人。希望这篇笔记里的每一条踩坑记录都能帮你少走一个弯路。本文还有配套的精品资源点击获取