Llama-Factory能否用于电子病历结构化？三甲医院试点

在一家三甲医院的信息科办公室里，AI工程师正和临床医生围坐在屏幕前，讨论一份刚由系统自动解析的门诊记录。屏幕上，原本杂乱无章的“患者诉反复胸痛2年，加重伴气促1周”被精准拆解为结构化字段——主诉、现病史、初步诊断，准确率接近90%。这背后，没有依赖任何外部云服务，也没有庞大的算法团队支撑，而是一个名为 Llama-Factory 的开源框架，在单张24GB显卡上完成了对70亿参数大模型的本地微调。

这不是实验室里的概念验证，而是真实发生在我国某大型综合医院的AI落地场景。当智慧医疗进入深水区，如何让大语言模型真正理解医生的语言、贴合临床流程，并在严苛的数据安全要求下运行，成为决定成败的关键。传统方案往往受限于成本高、门槛高、风险高的“三高”困境，而 Llama-Factory 正在悄然改变这一局面。

---

电子病历的非结构化问题由来已久。医生书写习惯多样，术语表达复杂，“心梗”可能是“急性心肌梗死”的简称，也可能是“陈旧性心肌梗塞”的误写；一段病程记录中可能混杂着症状描述、检查结果、治疗反应与主观判断，机器难以分辨边界。过去，医院多采用规则引擎或小规模NLP模型进行信息抽取，但面对医学语言的高度灵活性，这些方法泛化能力差，维护成本极高。

大语言模型本应是破局利器，可现实却并不乐观。直接使用通义千问、ChatGLM等通用模型处理病历文本时，常常出现术语误解、字段遗漏甚至生成虚构诊断的问题。更关键的是，医疗数据不能出域，公有云API无法使用，本地部署又面临算力不足、技术栈断裂的难题。许多医院的AI项目因此停滞在POC阶段，迟迟无法上线。

正是在这种背景下，Llama-Factory 走进了我们的视野。它不是一个全新的模型，而是一个大模型微调的集成平台，目标很明确：把复杂的深度学习训练过程封装成普通人也能操作的工具链。你可以把它想象成一个“AI炼丹炉”，只要准备好药材（数据）、设定火候（参数），就能炼出适合特定任务的专属模型。

试点项目选择了最常见的任务——电子病历结构化提取。目标是从门诊记录、入院志、病程日志中自动识别并输出标准化字段，如主诉、诊断、用药、手术名称等，最终以JSON格式返回，供后续的临床决策支持系统调用。

整个系统部署在医院内网的一台GPU服务器上，配备两张NVIDIA A10G（24GB）。操作系统为Ubuntu 20.04，PyTorch 2.1 + CUDA 11.8环境，完全隔离于外网。基座模型选用 Qwen-7B，原因有三：一是其中文长文本建模能力强，适合处理动辄上千字的病历；二是阿里云已发布合规授权版本，可用于医疗场景；三是社区活跃，适配Llama-Factory无缝对接。

数据方面，从HIS系统导出500份脱敏后的门诊记录，涵盖心血管、呼吸、内分泌等多个科室。由两名主治医师交叉标注，确保一致性。每条样本转换为Alpaca风格指令格式：

{
  "instruction": "请从以下病历中提取【主诉】、【现病史】、【初步诊断】三个字段。",
  "input": "患者男性，68岁……",
  "output": "{\"主诉\": \"反复胸痛2年加重伴气促1周\", \"现病史\": \"……\", \"初步诊断\": \"冠状动脉粥样硬化性心脏病\"}"
}

这种“指令+输入+输出”的模式，正是当前大模型微调的标准范式。它教会模型不仅要看内容，还要理解任务意图——不是简单地复述，而是按指定结构组织信息。

训练环节采用了 QLoRA 技术，这是本次试点能成功的关键所在。全参数微调7B模型通常需要多张80GB显卡，而QLoRA通过4-bit量化（NF4）将原始权重压缩，再结合LoRA仅训练低秩适配层，使得总显存占用控制在20GB以内。我们设置 lora_rank=64，平衡了性能与资源消耗；batch size设为2，配合梯度累积达到等效16；学习率2e-4，训练3个epoch，全程耗时约6小时。

model_name_or_path: /models/Qwen-7B
finetuning_type: lora
lora_rank: 64
lora_alpha: 128
per_device_train_batch_size: 2
gradient_accumulation_steps: 8
learning_rate: 2e-4
fp16: true
do_train: true

整个过程通过Llama-Factory自带的WebUI完成。信息科的技术人员无需编写代码，只需上传数据集、选择模型、填写参数、点击“开始训练”，即可实时查看loss曲线和GPU状态。这种“点击式AI开发”极大降低了参与门槛，连非算法背景的医学信息员也能独立完成模型迭代。

训练结束后，使用内置脚本将LoRA权重合并回原模型，导出为标准Hugging Face格式。随后接入FastAPI服务，提供 /structurize/emr 接口，响应时间平均1.8秒/条（CPU推理），完全满足临床实时调用需求。

测试结果显示，字段提取的精确匹配率（Exact Match）达89.2%，JSON格式合法率达96.5%。相比未微调的原始Qwen-7B模型，F1值提升超过40个百分点。尤其在处理“急性ST段抬高型心肌梗死”这类长术语时，微调后模型能准确识别上下文关联，避免拆分错误。

更重要的是，这套方案解决了几个长期困扰医院AI落地的核心痛点：

首先是专业性问题。通用模型不懂医学逻辑，比如不知道“肌钙蛋白I升高”通常指向心肌损伤，而微调让模型学会了从本院真实语料中捕捉这些隐含规律。我们在prompt设计上也做了优化，指令不再机械地说“提取字段”，而是模拟医生真实提问：“请按JSON格式返回该患者的诊断、治疗方案和出院医嘱”，使输出更贴近临床思维。

其次是工程可持续性。以往每次更新模型都要重新写训练脚本、调试依赖库，而现在所有流程都被封装在统一界面中。信息科人员经过半天培训即可完成新版本训练，模型迭代周期从两周缩短至两天。当某个科室提出新增“过敏史”字段的需求时，我们能在24小时内完成数据补充、重新训练并上线。

第三是数据安全合规。全链路本地运行，训练数据、模型权重均不离开医院内网，符合《医疗卫生机构网络安全管理办法》要求。这一点对于三级等保评审至关重要，也是项目得以顺利推进的前提。

最后是硬件可行性。QLoRA让7B级别模型在消费级显卡上成为可能。即便未来要升级到13B模型，一张A100或H100也能胜任。这打破了“只有大厂才能玩转大模型”的迷思，让资源有限的医疗机构也能拥有定制化AI能力。

当然，实践中我们也总结了一些经验教训。比如，数据质量远比数量重要。最初尝试用1000条自动生成的伪标签数据训练，效果反而不如300条人工精标数据。医学标注必须建立统一规范，否则模型会学到矛盾逻辑。我们后来制定了《电子病历标注指南》，明确每个字段的定义边界和示例，显著提升了模型稳定性。

另一个关键是不要指望纯端到端输出。尽管大模型可以直接生成JSON，但我们仍建议增加一层规则校验后处理。例如，检测药物剂量是否超出合理范围（如“阿司匹林 1000mg”显然异常）、血压值是否符合单位规范（mmHg而非cmHg）、诊断编码是否存在于ICD-10列表中。这种“大模型+规则引擎”的混合架构，既保留了语义理解的灵活性，又增强了系统的鲁棒性。

此外，上线前必须建立双盲测试机制。我们将测试集交给不知情的第三方医生进行评估，避免内部偏差。同时保留历史模型版本，一旦新模型表现下降，可立即回滚，防止影响临床业务。

从技术角度看，Llama-Factory的成功并非源于某项突破性创新，而是胜在整合能力。它统一支持LLaMA、Qwen、ChatGLM、Baichuan等上百种主流模型，无需为不同架构重复开发训练流程；集成全参微调、LoRA、QLoRA等多种策略，适应不同硬件条件；提供从数据预处理、训练监控到模型导出的一站式工具链，减少模块间耦合带来的故障点。

对比传统方案，其优势一目了然：
- 不再需要手动编写tokenizer适配代码；
- 无需自行实现LoRA注入逻辑；
- 免去TensorBoard配置烦恼；
- 避免HF模型导出兼容性问题。

这一切都通过YAML配置文件或图形界面驱动，真正实现了“开箱即用”。

值得强调的是，Llama-Factory 并非要取代专业的AI团队，而是让更多机构具备基础的模型定制能力。对于三甲医院而言，它可以作为AI能力建设的第一步——先用低成本方式跑通闭环，验证价值，再逐步引入更复杂的知识图谱、检索增强生成（RAG）等进阶技术。我们下一步计划就是将结构化结果接入科研数据库，辅助流行病学分析与真实世界研究。

某种意义上，Llama-Factory 正在推动医疗AI从“外包依赖”向“自主可控”转型。过去，医院只能购买厂商打包好的黑盒系统，功能固定、更新缓慢；现在，借助这样的开源工具，医院可以用自己的数据、自己的节奏，训练出更懂自己医生的AI助手。

当越来越多的医疗机构掌握这种“自我进化”的能力，中国智慧医疗或将迎来一场静默的变革——不再是简单的系统数字化，而是真正迈向认知智能化的新阶段。