企业官网建设流程全解析

医学大语言模型这两年从“论文里的概念”快速走到了“科室里的工具”。我身边不少做临床科研、医疗信息化、甚至药企医学事务的朋友，最近都在问同一个问题：到底有哪些模型是真能用的，哪些只是刷榜的？这个问题不好回答，因为医学大模型的“汇总”如果只列名字和参数量，基本等于没写。真正有价值的是搞清楚它们各自解决什么临床场景的问题、在什么数据上训练、有什么已知的短板，以及一个普通开发者或临床研究者想上手时，应该从哪个模型切进去。

我自己在过去一年多里，因为做医疗问答系统和病历结构化相关的项目，陆续跑过、调过、也踩过不少医学大模型的坑。从通用模型加医学微调，到专门用医学语料从头预训练的模型，再到多模态的医学视觉语言模型，基本都摸了一遍。这篇文章不打算写成论文综述，而是按“一个从业者真正会怎么选、怎么用、怎么避坑”的思路，把目前主流的医学大语言模型梳理一遍。适合临床信息化的工程师、做医学NLP的研究生、以及想评估模型落地可行性的产品经理参考。读完你至少能判断：手头这个任务，该用哪个模型，不该用哪个模型，以及为什么。

1. 先搞清楚医学大模型到底分几类，别一上来就选错方向

很多人一提到“医学大语言模型”，脑子里浮现的就是一个能回答医学问题的聊天框。但实际上这个领域内部的分化非常明显，不同类别的模型在训练方式、数据来源、适用任务上差别巨大。如果分类没搞对，后面选型基本就是碰运气。

1.1 通用基座加医学指令微调：最主流也最容易上手的一类

这类模型的做法是拿一个已经训练好的通用大语言模型（比如7B到70B参数级别的开源基座），再用医学问答、医学教材、临床指南等数据做指令微调。它的优势很直接：通用语言能力保留得比较好，医学知识通过微调注入，训练成本相对可控。代表性的思路包括用医学考试题、医学文献摘要、医患对话数据做监督微调。

我实际用下来，这类模型在医学知识问答上的表现，明显好于纯通用模型，但在需要严格遵循临床指南、或者处理罕见病细节时，仍然会出现“看起来很像但实际不对”的情况。原因也不难理解：微调数据里的医学知识密度再高，也很难覆盖基座预训练阶段形成的语言先验。所以这类模型适合做医学教育、患者科普、初步分诊辅助，但不适合直接用于临床决策支持。

1.2 医学语料从头预训练或继续预训练：知识密度更高但成本惊人

另一条路线是在通用模型的基础上，用大规模医学语料做继续预训练，或者干脆从零开始用医学文本预训练。继续预训练的好处是能让模型在医学领域的词分布、表达习惯上更贴合，比如对“主诉”“现病史”“鉴别诊断”这类术语的处理更自然。但代价是训练数据量要求极高，而且如果医学语料质量参差不齐，模型反而会学到很多噪声。

我参与过一个小规模的继续预训练实验，用的是公开的医学文献摘要和部分脱敏病历文本。实测发现，继续预训练之后模型在医学命名实体识别和关系抽取上的F1值确实有提升，但在开放式问答上的流畅度反而下降了。这说明继续预训练不是万能药，它更适合做下游特定任务的底座，而不是直接拿来当聊天模型用。

1.3 多模态医学模型：文本之外还要处理影像和结构化数据

严格来说，多模态医学模型已经超出了“大语言模型”的范畴，但在实际项目里，纯文本模型往往不够用。比如你要做一个能同时看化验单、看影像报告、看医嘱的辅助系统，就需要模型能处理图像和结构化表格。这类模型通常是在视觉语言模型的基础上，用医学影像-文本对做对齐训练。

我试过用这类模型做胸部X光报告的自动生成，效果在常见病上还可以，但遇到少见征象时，生成的描述会明显偏向训练集中高频出现的模板。所以多模态模型目前的定位，更像是“报告初稿生成器”，而不是“诊断者”。这一点在选型时一定要心里有数。

2. 主流医学大语言模型逐个拆：它们各自擅长什么，短板在哪

下面这部分是我自己实际接触过或深入调研过的模型，按类型和特点分开说。需要说明的是，模型迭代很快，具体版本号和性能指标会变，但每个模型的设计思路和适用边界相对稳定，这才是选型时真正要抓住的东西。

2.1 以医学问答和考试为导向的模型：知识覆盖广，但临床推理弱

有一类模型的设计目标非常明确，就是刷医学考试题。它们的训练数据大量来自医学教材、考试题库和权威指南，因此在选择题、判断题上的准确率可以做到很高。我拿几个公开的医学考试数据集测过，这类模型在基础医学知识题上的表现确实亮眼，有些甚至能超过普通医学生的平均水平。

但问题在于，考试题和临床实际之间有一条很深的沟。考试题有明确的选项，模型只需要在有限空间里做选择；而临床场景是开放的，患者描述可能模糊、矛盾、甚至误导。我遇到过模型在考试题上答对率很高，但给它一段真实的门诊对话，它给出的鉴别诊断列表却漏掉了最关键的急症。所以这类模型适合做医学知识库的问答接口，不适合直接做临床推理。

2.2 以临床文本处理为核心的模型：病历结构化、编码、摘要

另一类模型更偏“工程向”，主要处理电子病历、出院小结、手术记录这类临床文本。它们的训练数据往往来自脱敏后的真实病历，任务包括命名实体识别、关系抽取、自动编码、文本摘要等。这类模型在特定任务上的表现，往往比通用医学问答模型更稳定，因为它们的目标函数就是针对这些任务设计的。

我在一个病历结构化项目里用过这类模型，主要做诊断实体和用药实体的抽取。实测下来，在常见病和标准术语上准确率不错，但遇到医生手写的简写、错别字、或者科室内部约定俗成的表达时，召回率会明显下降。解决办法通常是在后处理阶段加一层规则和词典映射，但这又增加了维护成本。所以这类模型的价值在于“把非结构化文本变成结构化字段”，而不是“理解医学”。

2.3 以对话和患者教育为目标的模型：语气友好，但边界要卡死

还有一类模型专门针对医患对话和患者教育场景设计，特点是输出语气更温和、更通俗，会主动避免过于专业的术语。这类模型在患者咨询、术后注意事项、慢病管理提醒等场景下体验很好，我见过一些产品用它们做患者端的健康助手，用户反馈普遍不错。

但这里有一个必须卡死的边界：这类模型绝对不能给出具体的诊断结论或用药建议。我在测试中试过诱导它们给出“我是不是得了XX病”的判断，有些模型会顺着用户的话往下说，这是非常危险的。所以实际部署时，必须在提示词层面和输出过滤层面做双重限制，把模型的能力严格限制在“解释医学概念”和“提供就医建议”上。

2.4 开源与闭源的选择：不是非此即彼，而是看数据能不能出去

选开源还是闭源，很多人第一反应是看性能。但在医学场景里，第一约束往往是数据合规。医院的病历数据、患者的个人信息，在很多情况下是不能传到外部接口的。这就决定了如果你要做的是真实临床数据的处理，开源模型本地部署几乎是唯一选择。

闭源模型在通用能力和多轮对话上通常更强，但如果你不能把数据发出去，再强也白搭。我的做法是：涉及真实患者数据的任务，一律用开源模型本地跑；涉及医学知识科普、公开文献问答的任务，可以用闭源模型做对比和补充。两者不是替代关系，而是分工关系。

3. 训练数据从哪来，直接决定了模型能干什么、不能干什么

医学大模型的能力边界，本质上是由训练数据划定的。很多人只看模型卡上的参数和评测分数，却忽略了数据来源这个更根本的问题。我在实际项目里踩过的坑，一大半都和“以为模型知道，其实它没见过”有关。

3.1 公开医学文献和指南：知识权威但更新慢

公开的医学文献摘要、临床指南、教科书是很多医学大模型的主要训练数据来源。这类数据的优点是权威性高、术语规范，模型学到的知识相对可靠。但缺点也很明显：更新周期长。一篇指南从发布到被模型“学会”，中间可能隔了几个月甚至更久，而临床实践中的新证据、新药物、新术式是持续出现的。

我遇到过模型在回答某个疾病的治疗推荐时，引用的是上一版指南的方案，而最新版已经做了调整。这不是模型的错，是数据时效性的问题。所以如果你的应用场景对时效性要求高，就必须在模型之外挂一个实时更新的知识库，用检索增强的方式补充最新信息。

3.2 脱敏病历和医患对话：贴近真实但噪声大

真实病历和医患对话数据，是让模型“接地气”的关键。这类数据里包含了大量口语化表达、简写、甚至错误，模型学了之后能更好地理解真实临床语言。但问题也很突出：脱敏是否彻底、标注是否一致、不同科室的表达差异如何统一，这些都是工程上的硬骨头。

我在处理一批脱敏门诊对话时发现，同一个症状在不同科室的记录方式完全不同，有的用标准术语，有的用俗称，有的直接写英文缩写。如果直接拿来做训练，模型会学到很多相互矛盾的表达。后来我们的做法是先做一轮术语归一化，把不同表达映射到标准医学术语上，再喂给模型。这一步很费人力，但效果提升明显。

3.3 合成数据：解决稀缺问题的双刃剑

医学领域的高质量标注数据永远稀缺，所以很多团队会用大模型生成合成数据来扩充训练集。这个方法在理论上很吸引人：让一个强模型生成医学问答对，再用这些数据去训练小模型。但实际操作中，合成数据的质量参差不齐，如果生成模型本身有知识错误，这些错误会被“蒸馏”到小模型里，而且很难排查。

我试过用合成数据做数据增强，在小规模测试里确实能提升模型在长尾问题上的表现。但一旦合成比例过高，模型就会开始输出一些“看起来很专业但实际不存在”的内容。所以我的经验是：合成数据可以用，但比例要控制，而且必须经过人工抽检和过滤，不能直接拿来就用。

4. 评测医学大模型，别只看准确率，这几个维度更关键

医学大模型的评测，比通用模型复杂得多。通用模型看几个基准分数就够了，但医学场景里，一个模型“答对”和“答得安全”是两回事。我在实际评测中总结了几条比准确率更重要的维度。

4.1 事实准确性：有没有编造不存在的医学知识

这是最基本的一条。医学领域对事实错误几乎是零容忍的，因为一个错误的药物剂量或禁忌症描述，可能带来严重后果。我在评测时会专门构造一批“陷阱问题”，比如问一个不存在的药物名称、一个被推翻的旧理论，看模型会不会顺着编下去。

实测发现，很多模型在面对不存在的事物时，会倾向于“编一个合理的答案”，而不是说“我不知道”。这在通用场景里可能只是体验问题，但在医学场景里是硬伤。所以评测时一定要把“拒答能力”作为一个独立指标来看。

4.2 安全性：会不会给出危险的医学建议

安全性评测比事实准确性更棘手，因为“危险”的边界有时候很模糊。我的做法是构造几类高风险场景：急症症状描述、药物过量、孕妇用药、儿童用药，看模型会不会给出可能延误就医或造成伤害的建议。

我试过给模型输入一段描述胸痛和呼吸困难的文本，有的模型会直接给出“可能是焦虑，建议休息”这类回答，这就是典型的安全性问题。好的模型应该识别出这是潜在急症，并明确建议立即就医。这个维度上，专门做过安全对齐的医学模型明显更好。

4.3 可解释性和引用来源：能不能说清楚依据是什么

在临床场景里，一个没有依据的答案，价值几乎为零。医生需要知道模型是基于什么指南、什么研究给出的建议。所以我在评测时会看模型能不能给出引用来源，以及这些来源是否真实存在。

有些模型会生成看起来很像论文引用的内容，但仔细一查，期刊名、作者、年份都是编的。这种“幻觉引用”在医学场景里特别危险，因为它会让不熟悉该领域的人误以为有证据支持。所以评测时一定要对引用做真实性核查。

4.4 中文医学场景的适配度：英文强不代表中文强

很多医学大模型是在英文语料上训练的，英文评测分数很高，但一到中文临床场景就露怯。中文医学文本有自己的特点：大量的缩写、不同的疾病命名习惯、以及中西医混合的表达方式。我在评测时会专门看模型对中文病历、中文指南、中文药品说明书的处理能力。

实测下来，专门用中文医学语料训练过的模型，在中文场景下的表现明显更稳。所以如果你的应用场景是中文的，不要只看英文榜单，一定要用中文数据自己测一遍。

5. 实际落地时，我踩过的坑和总结出的几条经验

前面讲了模型分类、具体模型和评测维度，这一部分说点更实操的。这些都是我在真实项目里踩过坑之后总结出来的，有些看起来是常识，但真到做的时候很容易忽略。

5.1 不要指望一个模型解决所有问题，组合使用才是常态

我一开始也想过找一个“全能”的医学大模型，既能做问答，又能做病历结构化，还能做患者教育。试了一圈之后发现，这种模型不存在。每个模型都有自己的强项和短板，强行用一个模型覆盖所有任务，结果就是每个任务都做得不够好。

后来我们的架构变成了：用一个模型做医学知识问答，用另一个模型做病历实体抽取，再用规则和词典做后处理。虽然看起来复杂，但每个环节的准确率和稳定性都明显提升。所以我的建议是，先拆解任务，再为每个任务选最合适的模型，而不是反过来。

5.2 提示词工程在医学场景里比想象中更重要

医学场景对输出的格式和边界要求很严，所以提示词的设计非常关键。我试过同一个模型，用不同的提示词，输出质量差别巨大。比如做患者教育时，提示词里必须明确“不要给出诊断结论”“不要推荐具体药物”“建议就医的情况要单独列出”，否则模型很容易越界。

另外，医学场景里的提示词最好包含具体的输出结构，比如“请按以下格式回答：可能的解释、建议的下一步、需要警惕的情况”。这样不仅能提高输出的可用性，也方便后续做自动化处理。

5.3 本地部署的硬件成本要提前算清楚

如果你打算本地部署开源医学大模型，硬件成本是一个绕不开的问题。7B参数的模型在量化之后，消费级显卡还能跑；但13B以上的模型，尤其是要做微调的时候，对显存的要求就上来了。我在一个项目里一开始低估了这一点，后来不得不重新调整模型规模。

我的经验是：如果只是推理，7B到13B的量化模型在单张消费级显卡上基本够用；如果要微调，至少需要多张专业卡，而且训练时间要以天为单位计算。所以在项目规划阶段，一定要把硬件预算和训练周期算进去，不要等到模型选好了才发现跑不起来。

5.4 医学模型的更新和维护是一个持续过程

医学知识在更新，模型也需要跟着更新。但重新训练一个大模型的成本很高，所以更现实的做法是定期更新外挂的知识库，用检索增强的方式让模型获取最新信息。我在项目里用的是“模型不动、知识库定期更新”的策略，这样既能保证知识的时效性，又不用频繁重训模型。

另外，模型的输出监控也很重要。上线之后要持续收集bad case，定期分析是模型能力问题还是数据问题，然后有针对性地调整。医学场景里，一个没有被发现的错误输出，可能比没有模型更危险。

6. 如果你现在要上手，我的建议是从这三个方向切入

说了这么多，最后给几条具体的上手建议。不管你是做科研还是做产品，这三个方向是我觉得投入产出比比较高的。

6.1 从医学知识问答做起，验证模型的基础能力

如果你刚开始接触医学大模型，最稳妥的切入点是医学知识问答。找一个开源的中文医学微调模型，本地部署起来，用一批公开的医学考试题或者自己整理的问答对做测试。这一步的目的是建立对模型能力的直观感受：它知道什么、不知道什么、在什么情况下会出错。

这个阶段不要急着上真实临床数据，先用公开数据把流程跑通。等你对模型的脾气有了基本了解，再考虑接入更复杂的场景。

6.2 用检索增强解决知识时效性问题

医学知识更新快，单靠模型参数里的知识是不够的。检索增强是一个性价比很高的方案：把最新的指南、药品说明书、文献摘要做成向量库，模型回答时先检索再生成。这样既能保证知识的时效性，又能让输出有据可查。

我在项目里用这个方案处理药品信息查询，效果比纯模型回答好很多。关键是向量库的更新可以做到很及时，新发布的指南当天就能入库，第二天模型就能用上。

6.3 把安全边界写进系统设计，而不是只靠提示词

最后一条也是最重要的一条：安全边界不能只靠提示词来卡，要在系统层面做设计。比如输出过滤层、敏感词检测、高风险场景的强制转人工，这些都应该在架构里体现，而不是指望模型“自觉”。

我在项目里见过因为提示词被绕过而导致模型输出不当建议的情况。后来我们在输出层加了一道规则引擎，对涉及诊断、用药、急症的内容做强制检查，不符合安全规则的输出直接拦截。这道防线虽然增加了开发量，但在医学场景里是必须的。

医学大语言模型这个领域变化很快，今天好用的模型明天可能就被超越了。但底层的选型逻辑、评测方法和安全原则是相对稳定的。把这几条抓住了，不管模型怎么迭代，你都能快速判断它适不适合你的场景。我在实际项目里最大的体会是：不要被榜单分数牵着走，用自己的数据、自己的场景去测，才是唯一可靠的办法。