说实话，我刚开始接触医疗文本理解这块的时候，脑子里其实只有一个模糊的概念——不就是让机器读懂病历和医学文献嘛。真动手做模型对比才发现，这个“读懂”二字的边界远比想象中复杂。你让模型从一段出院小结里找出所有的疾病名称，和让它判断这份病历该归入哪个科室，完全是两种能力。前者要求模型具备细粒度的序列标注能力，后者则更依赖对全文语义的聚合与抽象。我越来越觉得，做模型对比之前，得先把“比什么”这件事掰扯清楚，否则很容易陷入拿着锤子找钉子的窘境。
具体来说，我把医疗文本理解的任务大致分成几个层次。实体识别是最底层的基本功，药品名、检验指标、手术操作、解剖部位，这些实体是后续所有任务的基础构件。关系抽取往上走一层，要判断两个实体之间是否存在“药物-不良反应”或者“疾病-检查”这类语义关联。临床事件抽取更复杂一些，需要把时间、主体、行为、结果串成一个完整的事件链条，比如“患者入院后第三天开始发热，给予物理降温后缓解”这句话里就藏着好几个事件节点。病历分类和医学问答推理则站在更高的抽象层级上，前者考验模型对整份文档的主题归纳能力，后者要求模型在给定上下文里做多跳推理。这些任务之间的难度差异很大，用同一个模型去横向对比时，如果不在任务层面做区分，结论很容易失真。
对比目标这件事我也琢磨了很久。医疗场景和通用NLP场景有个根本区别——容错率极低。通用领域里模型把“苹果”识别成“水果”还是“公司”，顶多影响搜索排序，医疗领域里把“硝苯地平”错标成“地西泮”，那就是用药安全隐患。所以我在设计对比目标时，除了看常规的准确率、召回率、F1值，还会特别关注模型在关键实体上的漏检率和误检类型分布。有些模型表面指标很好看，但漏掉的偏偏是那些罕见病或者高危药品，这种模型放到临床上就是不合格的。对比目标得跟临床风险挂钩，不能只看排行榜上的数字。
聊到评测基准，中文医疗这块的情况有点特殊。英文有i2b2、n2c2这些老牌基准撑着，任务定义清晰、标注规范成熟、参与团队多，对比起来相对有据可依。中文医疗文本理解的评测基准起步晚一些，但这几年进展很快。我梳理了一下，目前能用的基准大致来自几个渠道：公开竞赛数据集、医院合作标注数据、以及从电子病历系统里脱敏后构建的评测集。不同来源的数据在标注质量、任务覆盖和领域分布上差异很大，直接混在一起比容易出问题。
数据来源的多样性带来一个现实问题——同一个模型在不同基准上的表现可能天差地别。我做过一个小实验，拿同一个中文医疗大模型分别在两个公开评测集上跑实体识别任务，一个集子的F1能到0.87，另一个只有0.72。后来分析发现，前者的标注规范更接近模型预训练时见过的数据分布，后者包含大量基层医院的简写和口语化表述，模型明显水土不服。这件事让我意识到，评测基准的“口径”比“分数”更重要。你得知道这个基准的数据从哪来、标注标准是什么、任务定义有没有歧义，否则对比就变成了关公战秦琼。
评价指标的设计也有讲究。实体识别用严格的span-level F1还是宽松的mention-level匹配，关系抽取算不算方向性，事件抽取是看触发词还是看论元完整度，这些选择都会显著影响模型排名。榜单口径不统一的时候，我一般会自己做一遍指标对齐，把不同来源的结果换算到同一套评价体系下再比。虽然费事，但比直接抄论文里的数字靠谱得多。任务覆盖面上，我倾向于选那些同时包含抽取类任务和生成类任务的基准，这样才能看出模型在判别式和生成式两种范式下的真实水平差异。
电子病历这块的评测，坑比公开数据集多得多。脱敏合规是第一道坎，真实病历里患者姓名、身份证号、住址、联系方式都得处理干净，但脱敏过度又会破坏文本的语义连贯性。我见过有些处理方式把所有人名统一替换成“某某”，结果模型在关系抽取时完全分不清“某某”和“某某”是不是同一个人。脱敏方案本身就会影响评测结果的可靠性，这一点在设计对比实验时必须纳入考量。
长文本是另一个绕不开的难点。一份完整的住院病历动辄几千字，涵盖入院记录、病程记录、手术记录、出院小结等多个模块，模型要么得支持超长上下文窗口，要么得做分段处理再聚合结果。分段策略不同，评测分数能差出好几个百分点。我试过按章节切、按段落切、按固定长度滑窗切，每种方式对模型的长程依赖能力要求不一样。时序信息更是电子病历的灵魂——检验指标的变化趋势、用药方案的调整节点、症状出现和缓解的时间关系，这些信息如果模型捕捉不到，临床推理任务基本就是瞎猜。可惜很多评测基准在构建时没有显式标注时序关系，模型对比时就容易漏掉这个维度。
多科室差异也值得单独拎出来说。心内科病历和儿科的书写风格、术语体系、关注重点完全不同，一个在心血管数据上微调过的模型拿到儿科病历上可能直接崩盘。我在设计对比实验时会尽量按科室分层采样，确保评测集覆盖内科、外科、儿科、妇产科等主要科室，同时控制各科室样本比例，避免某个科室的难样本把整体分数拉偏。结构化程度方面，有些医院的电子病历模板化程度很高，字段规整、术语标准，模型处理起来轻松；有些医院还是自由文本为主，简写、错别字、方言词汇混杂，模型得有一定的容错能力。评测集里这两种类型都得有，不然对比结论只适用于特定数据环境。
实验设计这块，我的经验是别贪多求全，先想清楚对比的目的是什么。如果是给某个具体应用场景选型，零样本和少样本的表现比微调后的上限更重要——你不可能每个科室都标注几千条数据再微调。零样本评测能看出模型的通用医疗知识储备和指令跟随能力，少样本评测则反映模型在有限标注条件下的快速适应能力。我一般会设置0-shot、1-shot、5-shot三档，观察模型性能随样本量增加的提升曲线，曲线陡峭的模型在小样本场景下更有优势。
微调设置的对比需要格外小心。学习率、批次大小、训练轮数、是否冻结底层参数，这些超参的选择对最终结果影响很大。我通常会做一轮超参搜索，给每个模型都找到相对最优的配置再比，避免因为某个模型没调好就下结论说它不行。公平性还体现在数据划分上——训练集、验证集、测试集必须严格隔离，同一患者的多次就诊记录不能跨集出现，否则模型可能通过患者身份特征作弊。鲁棒性评测我也很看重，往测试文本里加一点噪声（错别字、标点缺失、简写替换），看模型性能下降的幅度。临床真实数据永远比标注数据脏，鲁棒性差的模型上线就是灾难。
可解释性和推理效率在医疗场景里不是锦上添花的东西。医生需要知道模型为什么把某个实体标成药品而不是检验指标，是看到了“mg”这个剂量单位，还是匹配到了药名词典。注意力可视化、特征归因、置信度校准，这些手段能帮我们判断模型是不是学到了正确的医学逻辑。推理效率直接关系到部署可行性，一个需要八张A100才能跑的模型和一个单卡就能推理的模型，对比结论再漂亮也没法落地。最后是评测偏差控制——数据集本身的标注偏见、任务难度的不均衡、模型规模带来的不公平比较，这些因素在出对比报告时都得交代清楚。我习惯在报告里附一节“局限性说明”，把实验设计里没法完全控制的偏差变量列出来，让读者自己判断结论的可信区间。
上一章把评测的框架搭好之后，我就一头扎进了真实的模型对比工作里。说实话，这个阶段比设计评测方案还要磨人。公开榜单上的数字摆在那里，看着挺清晰，真把模型拉下来跑自己的病历数据，感觉完全是另一回事。我前后折腾了差不多两个月，试了十几款开源模型，从参数量级几亿的编码器一路测到百亿级的中文医疗大模型，硬盘里存的评测日志和对比表格堆了一堆。这一章我想把这些踩坑和发现原原本本讲出来，给同样在做选型的朋友省点时间。
2.1 电子病历文本理解模型开源对比：三类路线的真实差异
我先把手上测试的模型按技术路线分成三组。第一组是通用中文大模型做医疗微调的版本，像基于Qwen、ChatGLM、Baichuan这些底座，用医疗语料继续预训练或者指令微调出来的模型。第二组是医疗专用开源模型，从预训练阶段就聚焦医疗文本，比如华驼、本草系列、MedicalGPT这类。第三组是编码器类模型，典型的是基于BERT、RoBERTa、MacBERT架构在中文电子病历上做领域适应的模型，参数量一般在几亿级别。这三组模型在设计哲学上差异很大，放到具体任务上的表现也各有各的脾气。
通用大模型医疗微调版的优势在于语言理解和指令跟随能力。我拿一份包含大量简写和口语化表述的门诊病历去测，这类模型对“纳差”“乏力”“遵嘱”这些词的语义把握明显更稳，做病历分类和医学问答时给出的答案结构也更完整。短板在细粒度抽取任务上，实体边界经常标不准，药品剂量和单位有时候会拆错。我印象很深的一次，模型把“氨氯地平5mg qd”里的“5mg”整体标成了药品实体，把“qd”漏掉了，这种错误在结构化输出场景里很致命。
医疗专用开源模型在术语体系和领域知识上下了功夫，做实体识别和关系抽取的底子更扎实。我在一个包含一万多条标注样本的检验指标抽取任务上做过对比，医疗专用模型的F1比通用微调版高出四到五个百分点，尤其是在罕见检验项目和复合指标名称上优势明显。这类模型的弱点在生成式任务上，医学问答的答案有时候过于模板化，遇到需要跨段落整合信息的复杂问题容易卡壳。
编码器类模型是另一番景象。参数量小、推理快、微调成本低，在实体识别和病历分类这类判别式任务上性价比极高。我单卡跑一个RoBERTa-base级别的医疗编码器，吞吐量能到每秒几百条样本，延迟控制在毫秒级。它的天花板也很清楚——做不了生成式问答，长文本理解靠分段聚合，跨段落的推理能力有限。我一般把它定位成抽取管道的基座模型，复杂推理任务交给大模型兜底。
三组模型对比下来，我的感受是没有全能选手。选型时得先问自己：核心任务到底是抽取还是生成，标注数据够不够做微调，推理延迟的容忍度是多少。这几个问题的答案基本能把模型范围缩到一两类。
2.2 医疗大模型中文文本理解能力横向对比：五个维度的实测记录
信息抽取这个维度上，我设计了一组包含药品、疾病、手术、检验指标四类实体的测试集，共两千条样本，来源覆盖门诊病历和出院小结。通用大模型微调版在零样本设置下F1大概在0.65到0.72之间，给五个示例之后能爬到0.78左右。医疗专用模型零样本就有0.74上下，少样本提升幅度反而小一些，说明它的领域先验知识确实更厚。编码器模型在微调之后能到0.85以上，零样本基本没法用。这个结果跟我的预期基本吻合，抽取任务上领域预训练加微调的组合目前还是最稳的路线。
语义理解能力的对比我用了病历分类和语义相似度两个任务。病历分类上大模型组整体占优，尤其是主诉和现病史语义模糊、需要结合既往史判断科室归属的样本，大模型能把上下文串起来做判断，编码器模型容易只看局部特征。语义相似度任务里我拿同一患者不同就诊记录的段落做配对，看模型能不能判断两次描述的是同一症状。医疗专用模型在这个任务上表现很有意思，它对术语变体的敏感度很高，“心慌”和“心悸”能正确关联，通用模型反而有时候会被表面措辞带偏。
临床推理是拉开差距最大的维度。我构造了一组需要多跳推理的题目，比如给出患者的检验指标变化趋势和用药记录，让模型判断某个不良反应是否与特定药物相关。通用大模型微调版在这个任务上准确率不到五成，医疗专用模型在四成左右，编码器模型基本不具备这个能力。失败案例分析下来，主要问题出在时序关系的处理上——模型能看到所有信息，但没法把“第三天加药”和“第五天指标异常”这两件事在时间轴上对齐。长文本处理方面，支持32K上下文的模型明显占优，我把一份完整的住院病历直接塞进去，模型能定位到出院小结里的关键信息。上下文窗口小的模型得分段喂，段落之间的信息损失很严重，尤其是病程记录里那些跨天的病情演变描述。
幻觉表现这个维度我单独拎出来说，因为它直接关系到临床可用性。我让模型做开放式医学问答，问一些指南里有明确答案的问题。通用大模型微调版的幻觉率最高，大概三成左右的回答包含事实性错误或者编造的参考文献。医疗专用模型好一些，幻觉率在两成上下，但遇到训练数据里覆盖少的罕见病还是会胡诌。编码器模型做不了开放问答，但在抽取任务里会“脑补”实体——文本里没出现的药品名有时候会被标出来。幻觉这东西很难彻底消除，我的做法是在应用层加一道检索验证，模型输出的关键实体和结论必须能在原文或知识库里找到依据。
2.3 部署与治理对比：算力账单和合规红线
算力成本这块我算过一笔细账。一个百亿参数级别的医疗大模型，用FP16精度做推理，单张A100 80G勉强能跑起来，吞吐量大概每秒十几条样本。如果要做私有化部署还得留冗余，实际得上两张卡。编码器模型就轻量多了，一张T4或者消费级显卡就能跑，吞吐量是大模型的两个数量级。我见过有些团队一上来就奔着大模型去，结果预算全花在GPU上了，实际业务量根本喂不饱那些卡。我的建议是先按业务峰值估算QPS，再倒推需要的算力，别反过来。
私有化部署的复杂度差异也很大。编码器模型打包成Docker镜像，几百兆大小，扔到医院的服务器上就能跑。大模型动辄几十个G的权重文件，部署环境对CUDA版本、驱动版本、显存都有要求，医院信息科的人看到这一堆依赖头都大了。我现在的做法是优先选支持ONNX或者TensorRT导出的模型，推理框架统一用Triton或者vLLM，把部署门槛降下来。版本迭代方面，编码器模型微调一次几个小时就搞定，大模型全量微调没个几天下不来。我倾向于用LoRA或者Adapter做增量微调，迭代周期能压到一天以内。
数据合规是医疗场景的生命线。开源模型拿过来用，得先确认它的预训练语料里有没有包含患者隐私数据，许可证允不允许商用。我见过一些模型权重是从不明来源的语料上训出来的，这种在医疗场景里绝对不能用。私有化部署时要确保推理过程完全在内网完成，模型不对外发请求。日志里也不能留原始病历文本，我一般只记录脱敏后的统计指标。持续评测机制这块，我给自己定的规矩是每个月跑一遍回归测试集，监控模型在新数据上的性能漂移。医院的数据分布会变，新科室上线、新术语出现、病历模板改版，都可能让模型效果悄悄下滑。没有持续评测，等业务方反馈问题的时候往往已经积累了一堆bad case。
2.4 面向应用场景的选型建议与对比结论输出
走到选型这一步，我的做法是先搭一个评测矩阵，行是候选模型，列是核心能力维度，每个格子填实测分数。矩阵出来之后，权重设定才是真正体现业务判断的地方。做临床辅助决策支持的系统，临床推理和幻觉控制的权重就得拉高，抽取精度可以适当让位。做病历质控的系统，实体识别和关系抽取是核心，生成能力权重可以降到很低。做患者服务的问答机器人，语义理解和响应延迟更关键。我给每个维度设权重时会拉上业务方一起讨论，把技术指标翻译成他们能理解的业务语言，比如“幻觉率降低五个点”对应“减少多少条错误用药建议”。
场景适配还得考虑数据环境。三甲医院的病历结构化程度高、术语规范，模型选型可以偏向大模型路线，追求更强的语义理解。基层医疗机构病历自由文本多、简写和错别字混杂，编码器模型加规则后处理的组合反而更稳。我做过一个社区卫生服务中心的场景，病历里“高血压”写成“高血”“高压”的特别多，大模型的表现并不比微调过的编码器模型好，后者配上同义词归一化规则，F1能到0.9以上。落地路线我一般分三步走：先用编码器模型搭抽取管道，解决结构化需求；再用医疗专用大模型做语义理解和推理增强，处理复杂问答和质控场景；最后引入持续评测和反馈闭环，把线上bad case回流到训练集里做迭代。这个路线的好处是每一步都有可交付的成果，不用等大模型调好才上线。
对比结论输出的时候，我习惯附一份“不推荐清单”，把测试过但没选上的模型和原因列清楚。有些模型是许可证问题，有些是指标不达标，有些是部署成本过高。这份清单能给后续换型或者扩容提供参照，避免重复踩坑。评测矩阵、权重表、场景适配说明、落地路线图，这四样东西凑齐了，选型报告基本就能拿给决策层看了。我自己的经验是，报告里多放实测案例和失败分析，少放排行榜截图，决策者更信那些能对应到具体业务场景的数据。
