如果你在医疗信息化、医学AI或者临床科研这条线上工作最近两年应该有一个明显感受医学大语言模型这个词出现的频率已经从偶尔听到变成了每周必刷。打开任何技术平台都是各种医学大模型的发布消息、榜单刷新、微调教程。这个领域热度高是好事但从业者真正的痛苦也随之而来——选择太多信息太碎每个项目都声称自己“医学能力全面领先”实际落下来差距却非常大。这篇文章我想把自己这段时间梳理医学大语言模型的经验完整整理一遍。不是给你堆一堆模型名就完事而是回答几个更实际的问题这些模型到底分成哪几类各自解决什么问题作为开发者、医生、医院信息科的人该怎么选、怎么落地、怎么避坑下文提到的所有模型均以匿名代称描述具体类别你可以根据自己的场景对号入座也可以拿着这个框架去评估任何新出现的模型。无论你是刚接触医学AI的初学者还是已经踩过坑的团队这篇都值得收藏后慢慢看。1. 医学大语言模型为什么值得单独梳理很多人会问一句通用大模型不是已经能问答了吗为什么还要单独搞一个“医学版”这个问题背后其实是医学场景特有的三个痛点。第一是术语幻觉。通用模型在医学知识问答上表现不差但一旦问到具体药名、剂量、诊断标准时非常容易出现“一本正经胡说八道”的情况。比如问某种药物的禁忌症它可能把两种结构相似的药搞混问某个罕见病的鉴别诊断它可能生成一个听起来专业、实际上不存在的合并症组合。医学是容错率极低的领域一个幻觉放在文案生成里无关痛痒放到辅诊场景里就是事故。第二是医学语料的结构特殊性。病历、检查报告、医嘱、护理记录这些文本和日常文本差异极大——大量缩写、表格化叙述、中西医混杂、前后文依赖强。通用模型没见过那么密集的医学语料直接做病历生成或结构化任务效果会明显打折。只有经过大规模医学语料继续训练的模型才能理解“T 39.2℃、WBC 12.8×10^9/L”这种句子的完整含义。第三是数据合规与部署边界。医院数据出不了院区这是硬约束。通用大模型基本都跑在云端API上数据要传到外部服务单这一条就卡死了绝大多数真实医学项目。所以医学大语言模型领域里开源权重模型和私有化部署方案的关注度远高于其他行业。再说说医学大语言模型实际在做什么。我梳理下来核心任务大致分六类医学问答与知识检索、病历文书生成与质控、辅助诊断与鉴别诊断、检查报告解读、医学文献分析与科研辅助、患者教育与随访对话。不同的模型在这些任务上的侧重点完全不同有的擅长答题有的擅长写病历有的擅长看影像报告。后面的分类和选型部分我会反复用这个任务框架作为衡量尺子。所以医学大语言模型不是一个可有可无的“行业版通用模型”而是为了解决真实医学场景中的知识准确性、数据合规性、专业文本处理能力而存在的专门模型族群。接下来的内容都是围绕这个定位展开的。2. 主流形态分类从通用基座到垂类微调要理解现在市面上形形色色的医学大模型首先要有一套分类框架。从技术路线和产品形态两个维度看我认为可以分成三组。2.1 按输入模态划分文本、影像、语音最直观的分类是按模态。文本类医学大模型是主力覆盖问答、病历生成、质控、文献处理。它们的基本能力来自通用文本理解再用医学语料进行增强。评估这类模型主要看医学知识问答准确率、病历生成合规率、指令遵循能力。多模态医学大模型这两年增量非常快。它们除了文本还能输入CT、MRI、X光、病理切片图像输出影像描述或报告。这类模型通常采用“视觉编码器语言模型”的结构但医学影像和自然图像差异很大训练时必须有大量配对医学影像-报告数据。看多模态模型时要注意它到底是真正理解影像特征还是仅靠影像附带文字信息“抄答案”这两者临床价值完全不同。语音类医学模型集中在门诊对话记录、语音查房等场景。目前大多还是“通用语音识别医学文本后处理”的组合方案端到端的医学语音大模型仍在探索期。2.2 按训练路线划分通用微调、领域增强、从头训练从技术路线上看医学大模型有三种诞生方式。第一种是通用模型做医学指令微调。这种方式成本最低、迭代最快把几十万条医学问答对、病历指令丢进去做LoRA或全参微调就能得到一个“医学版”。它的优点是对话流畅度有保障缺点是底层世界知识仍有通用模型的痕迹医学深层推理能力可能不足。第二种是通用模型继续预训练 医学微调。在微调之前先用几十亿到几百亿token的医学语料做领域继续预训练让模型先把医学词汇、句式、知识结构吃透再进入指令微调阶段。这条路是目前效果与成本平衡较好的主流方案。第三种是从零开始训练医学专项模型。理论上最干净不受通用模型先验影响但实际上需要超大规模医学语料和巨大算力单独搞医学从头训练性价比很低。当前真正从零训练的医学大模型很少即便有也多数会借用通用分词器和初始权重严格讲只能算“半从头”。从我的观察看第二条路“领域继续预训练指令微调”是最值得关注的它在医学专业性和通用能力之间取得了一个较好的平衡点。2.3 按部署方式划分公有API、私有化、边缘端医学项目选模型时部署方式往往比性能指标更早被确认。公有API适合非敏感数据场景比如医学文献问答、科研辅助、健康科普内容生成优点是不用管GPU缺点是数据出域风险和按量计费成本。私有化部署是医学项目的常态。医院或医疗AI公司买几块GPU把模型权重部署到内网数据完全留在本地。开源权重模型在这里优势巨大。需要考虑推理吞吐量、并发数、显存容量还涉及与医院现有系统的对接方式。边缘端部署适合病历录入辅助、门诊语音识别等对延迟敏感且网络受限的场景。目前医学大模型边缘端通常以量化到4-bit的7B-14B小模型为主能力上限有限更多是作为云端/私有化方案的补充而不是替代。三种训练路线和三种部署方式组合基本能覆盖市面上90%的医学大模型项目。做技术选型时先定位你要哪种训练路线再确认部署边界最后才是比较跑分和效果。3. 代表性模型盘点开源基座、医学问答、影像多模态、中文专科这一部分是对当前可获取的医学大模型做类别化盘点和能力对比。为了避免信息过时我不会给出具体的模型发布时间和绝对数值而是按四类来梳理脉络和代表特点。3.1 开源基座系医学能力需要自己打磨第一类是开源基座模型本身具备一定医学能力但并非医学专用。它们的特点是参数规模从7B到70B不等权重大部分开放社区生态完善。任何团队都可以拿它做医学微调或直接配合检索增强使用。这类模型最典型的应用方式是配合医学知识库做RAG问答。好处是数据可以持续更新、不会在医学知识上出现训练截止日期问题难点在于检索质量直接决定回答质量需要花大力气做医学文本的分块、向量化和重排。实测下来好的检索策略可以显著提升问答准确率但离“临床可用”的门槛仍有距离因为推理类问题即使检索到相关内容基座模型也不一定能正确推导。3.2 医学问答与医学推理系刷榜强、实用边界清晰第二类是经过大规模医学指令微调、以医学问答为核心能力的垂类模型。它们通常在某医学考试数据集上表现优秀在结构化医学问题、诊断推理、药物交互问答等任务上比通用基座高出一截。使用这类模型时要建立合理预期它们在“单体知识问答”上很稳比如“什么是房颤”“二甲双胍的主要不良反应有哪些”这类问题答案相对固定模型表现好。但一旦进入“开放病例推理”——给定复杂病史要求做出鉴别诊断和诊疗计划——就会出现稳定性问题同一个病例改改表述方式结论就可能飘移。这不是某个模型的缺陷而是大模型推理机制本身的边界。所以我的建议是把这类模型当作“知识问答引擎”和“医生的辅助参考”来用而不是当作诊断决策体。3.3 影像-报告多模态系从“看懂图”到“会写报告”第三类是医学影像多模态模型。它们能接受影像输入输出结构化描述或诊断意见文本。从研究热点看这类模型比较受关注因为它直接触及读片这种高价值场景。从实际产品成熟度看影像多模态模型仍处于“辅助草稿”阶段而不是独立诊断工具。一个比较稳妥的用法是模型先根据影像生成报告草稿医生在草稿基础上修改确认。关键是模型生成的草稿必须把“疑似、可能、建议进一步检查”这类不确定性表达清楚而不是直接给确定性结论。影像多模态模型的落地难点不在模型结构而在数据。医学影像数据的获取和标注成本远高于文本而且各家医院的影像设备和标注规范不一致导致一个数据集训出来的模型换到另一家医院效果下滑。做影像项目的团队一定要提前规划数据采集和标准化流程。3.4 中文医疗专项系病历、门诊、医保与合规第四类是中文医疗场景专项模型聚焦在病历生成与质控、门诊对话、医保合规、 ICD 编码辅助等任务上。这类模型最大的价值是理解中文医疗文书里的常见表达习惯和格式规范。举个例子一个病人说“昨天开始发烧、咳嗽咳黄痰没劲”病历专项模型需要把这段话转成规范的主诉 “患者昨日无明显诱因出现发热、咳嗽咳黄黏痰伴乏力无寒战。”这中间涉及口语转书面语、症状排序、医学术语映射和多轮追问逻辑通用模型很难一次做好。专项模型因为大量学习过门诊对话和病历配对数据在这类任务上的完成度要好很多。不过中文医疗专项模型有一个通病受训练语料地区医疗规范影响换一个区域就可能出现术语习惯不一致的问题。国内不同地区对不同诊断表述、手术名称的使用习惯存在差异部署前需要准备适量本地病历做二次微调。以匿名方式说结论这类模型适合做病历场景底座但“本地适配”几乎不可避免。下面是四类模型的能力概括对比匿名综合观察不代表任何单一模型类别优势任务相对短板适合场景典型代价开源基座系通用对话、RAG问答医学深层推理不足私有化知识库问答需要自行检索增强医学问答推理系医学FAQ、考试题复杂病例推理不稳定辅助问答、医学教育需设置答案边界影像-报告多模态系影像理解与报告草稿跨设备数据迁移性弱影像报告预生成高质量配对数据难找中文医疗专项系病历生成、门诊对话地域术语迁移需微调电子病历、门诊场景本地化二次训练成本这张表可以直接用于初期技术选型讨论。比任何单一模型榜单都有用因为它结合了能力维度和落地成本两个维度。4. 评估医学大模型刷分只是及格线盲测才是真标准医学大模型领域有一个不太好的风气看榜单选模型。某团队发一个“医学知识问答准确率达到新高度”的新闻大家就蜂拥而上。但做落地的人很快会发现刷分和临床可用之间隔着一条巨大的鸿沟。4.1 主流评测类型当前医学大模型评测主要分四类。第一类是题库型评测使用医学考试题或标准医学问答集。这类评测容易做也容易被“刷”——如果模型训练语料里包含了评测集题目结果几乎必然虚高。第二类是模拟病例评测从真实临床场景构造病案并设计推理链路。这个比题库难一些但仍然可能存在数据泄露和主观打分不一致的问题。第三类是生成任务评测评估病历生成、出院小结生成等任务的结构完整性和专业准确性。通常需要人工评分或与参考文本算相似度自动化程度低。第四类是安全对齐评测考察模型面对危险医学建议时的拒答能力比如“某种药吃多少会致命”这类问题。安全评测在医学场景中优先级极高但很多分享文章都把它放在最后一位这其实是不对的。4.2 核心指标医学大模型的评估指标能反映很多问题知识点准确率模型回答中医学事实性错误的密度。这是区分“知识型模型”和“幻觉型模型”的第一道门槛。幻觉率回答中不存在于可靠医学证据中的内容比例。注意准确率和幻觉率不是完全负相关有的模型保守得几乎不给出有价值答案准确率虽高但实用性低。指令遵循度是否按用户要求输出指定格式。病历生成场景里这个指标比准确率更重要。不确定性表达率当模型遇到不确定内容时是否主动使用“可能”“需进一步检查”等表述而不是硬给结论。这一点在医学场景里是“左右模型能否上线”的隐性指标。拒答与安全率对无依据、有害或超范围请求的正确拒答比例。4.3 真实落地时我建议多做“医生盲评”我在评估医学大模型能力时跑完公开评测集之后一定会加一轮医生盲评。做法是让临床医生各出几个自己科室的典型病例分别交给模型回答然后去掉模型名称信息让另外一组资深医生从专业性、可参考性、风险程度三个维度打分排序。这轮盲评的价值在于公开评测集测的是“知识覆盖”盲评测的是“临床可参考性”。有些模型在公开评测集上得分很高但临床医生一看答案就摇头——要么信息组织方式不符合实际工作习惯要么回答里有“看似合理、实则误导”的表述。这类问题只有通过医生盲评才能暴露。4.4 评测集污染问题最后提醒一个绕不开的话题评测集污染。很多医学大模型的训练语料里天然包含公开医学评测题模型可能已经“背下了答案”。区分方法是看模型在评测集变动时的稳定性——把选择题选项顺序打乱、把题干改写一遍如果是真理解成绩波动不会太大如果是背答案成绩会断崖式掉落。在同等条件下我会优先选择“改题干后成绩稳定”的模型。这种模型才是真学会了医学推理而不是刷了个分。5. 选型参考不同角色、不同场景怎么选这里直接说结论分角色给选型建议。5.1 医院信息化与医疗产品团队优先考虑私有化部署能力强的开源基座或可授权商用模型并在其上叠加本地医学知识库和医疗文书专项能力。选型流程我建议是先确认数据部署边界是纯内网还是允许专线云圈定2-3个候选模型要求必须支持私有化用本院近一年的脱敏病历跑病历生成与质控测试做并发压测确认单台GPU能支撑的护士站使用规模医生盲评后投票决定这个流程里最常被跳过的是第3步。很多团队拿公开数据集跑得挺好一换上本院病历就水土不服。医学大模型的选型不能用公开数据定稿本地数据验证是底线。5.2 医学与AI科研团队科研场景更看重可解释性、可复现性和可控性。优先选择开放权重且参数规模明确的模型尽量避免通过黑盒API做科研。科研团队要做的事情通常分两类一类是医学NLP研究本身比如训练自己的疾病专用模型这时选基座模型加LoRA微调是最常规的路径另一类是用大模型做辅助工具比如从文献中抽取结构化信息生成临床队列文本特征这时应该把重点放在提示词工程和知识增强上而不必追求微调模型。这里特别提醒做科研的同学论文里如果说“我们微调了模型”一定要写清楚训练数据规模、数据来源、训练轮次、评测集是训练前还是训练后获取的。医学领域审稿人对数据泄露和数据来源问题非常敏感含糊其辞很容易导致返工。5.3 个人学习与技术验证个人开发者想入坑建议先从API和量化小模型开始。目的不是验证模型上限而是以最低成本建立对医学大模型的体感。具体路径可以是先用某开放平台的医学问答API做20个临床问题的测试记录回答风格和幻觉率再本地部署一个7B-14B的量化开源基座配合LangChain和公开医学知识库做一套简易RAG问答最后尝试用公开医学指令数据集做一次LoRA微调把训练、部署、评测整个链路跑通。这套流程走完你对整个领域的理解会超过只看测评文章的90%的人。三类角色的选型参考汇总如下角色优先选型重点投入避免事项医院信息化/医疗产品私有化开源基座 专项微调本地病历适配、并发性能直接套用云端商用API处理患者数据科研团队开放权重模型 自建数据集实验可复现、数据隔离黑盒API做需要细节分析的实验个人学习验证API 量化小模型端到端流程走通一开始就追求大参数全参微调6. 落地部署与微调的关键经验选完模型之后真正的挑战才开始。医学大模型的私有化部署和微调与通用模型的流程一致但有几个医学场景特有的坑必须提前排掉。6.1 训练数据清洗的优先级医学文本做清洗时最优先的事情不是去噪声而是去隐私。姓名、身份证号、电话、住址、住院号、主治医生姓名、罕见病例的独特病程这些信息如果在数据阶段没处理好模型微调后可能被泄露这在合规上是不可接受的。实用的清洗流程是先正则匹配常见标识符再用命名实体识别模型扫描医学实体和人员实体最后人工抽检。抽检比例建议不低于数据总量的2%。这一步非常耗时但它决定了整个项目存不存在而不是性能好不好。6.2 LoRA 微调的重点大部分医学项目做到LoRA微调就足够了没必要全参微调。LoRA有几个天然优势训练成本低、可以快速切换多个疾病专科模型、同一基座模型可以挂多个低秩矩阵适配不同任务。实操上我有三个经验。第一医学指令数据的质量权重高于数量一万条手工精标病历指令的效果往往好于十万条网上爬来的问答对。第二学习率要比通用任务再低一点医学知识本身比较“脆”学习率太高容易把基座模型原有的世界知识和推理能力破坏掉这被称为“灾难性遗忘”。第三医学微调后一定要回到通用医学题库做回归测试防止模型只会在训练集分布内作答遇到稍微边缘的问题就崩。6.3 引入检索增强而不是频繁重训医学知识更新速度快疾病指南、药品说明、医保政策每年都在变化。如果每次知识更新都重训模型成本上完全不可接受。所以 RAG检索增强生成在医学场景里的地位比在通用场景里重要得多。实践中的做法是把最新版临床指南、药品说明书、医院规章制度切片向量化存入向量数据库模型回答问题时先检索相关片段再组织回答。为了压缩检索噪声可以引入医学词表扩展和基于规则的重排逻辑。一个要注意的问题是检索片段和模型回答之间的矛盾。当检索到的知识本身存在指南版本冲突时模型可能忽略检索结果而依赖自己的记忆。解决方法是编写更强的系统提示词要求模型优先遵循检索到的指南并在两者冲突时给出版本说明。6.4 评估闭环建议模型微调和部署完毕后评估环节不要只做一次。我建议做成三个层级的闭环第一层是自动化评测集每次模型更新都跑一遍第二层是典型病例回归测试选50-100个有代表性的病例人工判定答案质量第三层是线上运行监控随机抽取模型使用日志做抽样盲评。这三层闭环看起来繁琐但能帮你尽早发现微调引入的隐性退化。比如某个模型更新后整体准确率提升了但某个特定科室的问题突然变差如果没有分层回归测试这个问题可能要过很久才暴露。6.5 硬件配置参考最后给一个硬件参考区间。7B-14B量化模型做纯推理一张24GB显存的GPU可以跑起来并发量约在10-20左右。要跑更流畅的70B级模型至少需要多张高性能显卡配合张量并行。做LoRA微调时7B模型建议单张48GB显存或两张24GB14B模型建议四张24GB或两张48GB。追求更好的微调效果尽量使用比推理高一个档次的硬件配置训练速度和稳定性差距很大。7. 踩坑记录医学大模型项目最容易翻车的地方最后一个部分也是我最想分享的真实项目里的踩坑记录。这些坑我基本都踩过或者亲眼看过团队踩过写出来让大家少走弯路。7.1 病历数据清洗“翻车”有一个团队拿到某医院脱敏病历做微调以为已经做了匿名化结果跑了一轮生成测试模型在生成病历时“自动补全”出了一个疑似真实医生的姓名。后来定位发现脱敏工具只处理了主诉和现病史字段没有处理护士记录和手术记录里的签名区。这个案例告诉我们字段级别的脱敏不等于文本整体安全清洗脚本必须覆盖所有自由文本字段并且要做一轮模型生成测试验证。7.2 微调后的“知识坍塌”另一个团队用大型医学指令集微调某个开源基座微调后特定科室问题的准确率大幅提升团队很高兴。结果医生提问一个基础药理问题时模型给出了完全错误的回答而且回答的句型非常流畅一点也没有“不确定”的迹象——这是最危险的。原因是微调数据里缺乏这类基础问题LoRA参数覆盖了基座中原有的正确知识。排查之后他们在微调数据中补充了通用医学基础题库并且把学习率降了一半问题才缓解。7.3 忽略提示词边界还有一个坑是忽视提示词对安全边界的约束。同一个医学模型在“帮我读一下这份报告”和大段医生专用指令两种提示词下回答会呈现完全不同的风格。我看到过有产品团队做了一大堆评测却发现跑同一模型的两个医生得到的结果口碑截然不同——一个说“很聪明”一个说“胡扯”。后来调出对话记录发现差别主要在提示词设计上。医生使用场景里提示词必须把“你是一个辅助工具、不确定时明确说明、不提供确定性诊断”这几条写进去而不是指望模型自己保持谦逊。7.4 只重推理速度不重并发稳定性部署阶段最常见的坑是单条推理测得很流畅并发一上来就超时。医院门诊高峰期几十个护士同时用病历生成功能如果服务端没有做请求排队、模型服务没有配置连续批处理体验会瞬间崩塌。建议在上线前就用压测工具模拟真实并发场景而不是在演示环境里点几个按钮。7.5 产品没有“退出机制”最后分享一个产品层面的经验给医生用医学大模型工具最重要的功能不是生成结果有多准而是一键修改和一键弃用的顺畅度。医生面对AI生成的内容如果改起来很麻烦下一次就直接不用了。产品里病历生成功能要做得像“草稿插入”而非“自动完成”生成的内容放入编辑区医生可以自由增删可以快速回退甚至可以整段拒绝。很多团队的失败原因不是模型不够好而是交互设计没有尊重医生的控制权。最后分享一点个人体会做医学大语言模型相关的项目最怕的不是模型能力不足而是预期管理失败——团队以为换个更强的模型就能解决所有问题实际上医学AI落地的瓶颈往往在数据、工程和用户体验上。我个人的体会是先把一个最小场景完整跑通比如先做好一个病历生成功能从数据清洗、微调、部署到医生反馈形成闭环再图扩展。这个策略比一开始就铺开多个医学应用要稳妥得多。另外一个小建议如果你刚进入这个领域建议随手维护一张自己的评估表把看过的模型按“任务类型、数据边界、部署方式、实测印象”四列记录下来。几个月后你再看这张表会发现比任何汇总文章都有价值。毕竟医学大模型是一个月一变的地方别人的汇总只是参考你自己的实测才是决策依据。