电子病历命名实体识别实战：BERT+CRF与BIOES标签体系

简介：面向医疗NLP研究与工程落地场景，这套基于BERT模型的电子病历命名实体识别源码，可帮助开发者与研究者从非结构化病历文本中抽取疾病、药物、诊疗手段等关键实体，为临床决策与医疗信息化提供基础能力。压缩包共38个文件，约395KB，涵盖21个Python源码文件（如模型定义、数据预处理、训练预测、评估等模块）、6个文本说明文件、2个Markdown文档、3个XML配置、1个Jupyter Notebook及许可证与Git忽略文件等，结构清晰，便于按模块复用与二次开发。目前已有320人学习下载，适合具备一定Python与NLP基础、希望快速上手医疗文本信息提取的中高级学习者。除完整可运行代码外，还附带BERT预训练相关脚本、临床NER任务示例数据及评估工具，可帮助读者理解数据格式、模型调参和效果验证流程，缩短项目落地周期。

1. 电子病历命名实体识别，为什么不能拿通用BERT直接跑

医生写病历和写论文是两套语言。一份真实的入院记录里会出现“患者因胸痛伴发热3天入院，查体：右下肺可闻及湿啰音”这样的句子，胸痛是症状，发热是症状，右下肺是部位，湿啰音是体征。如果只靠正则和词典去抽，面对“右肺上叶前段”这种嵌套式位置描述，规则几乎必然失效。这个项目标题给的解法，是用BERT把每个字打上标签，让模型自己学会区分实体边界和类型，这就是电子病历命名实体识别（NER）最主流的技术路径。

标题里带“设计源码”，说明它不是一个概念讲解，而是一套可以落到训练脚本和推理接口的东西。你要处理的对象不是新闻语料，也不是通用领域文本，而是电子病历里那些口语化、简写多、标点乱、实体嵌套严重的句子。用通用BERT权重直接做，症状和身体部位经常混在一起；换用医疗语料微调过的BERT权重，再配合BIO标签体系和正确的数据处理管线，F1值通常能从70%出头的水平拉到85%以上。

这条方向真正值得投入的地方在于：电子病历NER是后面所有结构化工作的入口。实体抽取出来，才能做症状-药物关联、知识图谱构建、临床辅助决策。哪怕你现在的数据只是几百份病历，先把标签体系和训练管线跑通，后面换大数据集只是换文件的问题。这篇文章就按这个思路，从模型选型、数据处理、训练配置、踩坑排错到评估落地，完整走一遍。

2. 中文医疗BERT的选型思路：从权重下载到标签体系设定

2.1 为什么序列标注要用BERT而不是BiLSTM

电子病历和新闻文本最大的差别，是实体边界极度依赖上下文。看这句话：“患者3年前因胃癌行胃大部切除术”。胃癌是疾病，胃大部切除术是手术。如果只看局部窗口，“胃”和“癌”连在一起确实容易当成一个词，但“胃大部切除术”里的“胃”属于手术名称的一部分。BiLSTM这类序列模型能建模上下文，但对这种长距离、跨窗口的依赖，能力有限。BERT用Transformer双向编码，每个位置的输出都融合了整个句子的信息，天然适合判断这种边界模糊的实体。

另一个现实原因是数据量。从零训练一套医疗NER的深度学习模型，你至少需要数万条标注样本。但电子病历的标注成本极高——得让懂医的人去看原始病历，标注一条复杂记录可能花掉十分钟。而BERT的预训练权重已经把大规模通用语料的语义知识压缩在参数里，你只需要几千条标注病历就能微调出一个能用的模型。这就是迁移学习的核心价值：标注数据不够，预训练来凑。

还有一点容易被忽略：电子病历里大量实体是多字词搭配，比如“肺功能检查”是一个检查项目，不是“肺”“功能”“检查”三个独立实体。BERT在中文上是字级切分的，它不依赖分词工具的词典，就避开了分词错误传导给实体识别的经典问题。后面我会在数据管线里看到，字级输入反而让边界识别更稳。

2.2 通用中文BERT和医疗BERT差在哪

直接使用bert-base-chinese做电子病历NER，等于让一个只在新闻、百科上读过中文的模型去读医生手记。它认识“疼痛”，但未必分得清“胸痛”和“腹痛”是不同部位的症状；它见过“手术”，但“胃大部切除术”这种复合术式名称，在通用语料里出现频率不高，边界识别就容易漂。

常见的做法是使用医疗领域预训练语言模型。思路很简单：BERT的架构不变，但换用大规模的医学文献、电子病历、临床指南等语料重新做预训练或继续预训练，让模型先学会医学词汇的分布特征，再拿你的标注数据做微调。如果你英文数据为主，可以选用基于PubMed语料训练的BioBERT或PubMedBERT；如果处理中文病历，优先找中文医疗语料微调过的BERT权重。挑权重时我一般看两个标准：一是预训练语料是否包含电子病历文本——只有医学教材和论文也不理想，因为书面语和真实病历的口语化记录差异很大；二是看结构是否还是标准BERT——这决定下游代码能不能直接复用，不用改模型定义。

权重下载本身也有坑。BERT模型文件通常包含config.json、vocab.txt和pytorch_model.bin三件套，整个文件动辄几百兆。下载中断、文件名不对、和tokenizer版本不匹配，都会导致加载失败。用transformers库加载时，我建议显式指定本地目录而不是直接写模型名，这样权重文件一次到位，后续调试不用反复触发下载。下载前先确认磁盘空间和网络稳定性，避免跑到一半失败后留下一个残缺的bin文件。

2.3 标签体系：BIO还是BIOES

实体类型设计直接决定标注工作量，也是后面代码的根基。电子病历最常见的实体类型包括：疾病、症状、检查和治疗。如果细化，检查又可分为实验室检查和影像检查，治疗可分为药物和手术。对起步项目，我建议先定义6类：疾病、症状、身体部位、检查项目、治疗方式、时间描述。太大太小都不合适——太少，下游用起来不够；太多，标注一致性和模型准确率都会掉。

标签编码方式有两种主流方案。BIO是最常见的：B表示实体开头，I表示实体内部，O表示非实体。对应到具体类型，就是B-Symptom、I-Symptom、B-Disease、I-Disease这样的组合。BIOES在BIO基础上多了E（结尾）和S（单个字实体）。对电子病历来说，BIOES能更好处理“单字实体”和实体边界收束。比如“患者无发热”，其中“发热”是症状，BIOES会标成B-Symptom、E-Symptom，模型能明确知道到哪里结束；而BIO只会标B和I，边界定位反而模糊。

我的建议是：起步阶段用BIO，代码简单、标注好上手、评估函数也容易写；当你发现模型输出的实体总是多一个字或少一个字，再迁移到BIOES。不要一开始就两头兼顾，序列标注的标签空间越大，数据稀疏问题越严重。设计好标签后，立刻写一个label2id和id2label的映射字典并保存成json，这个文件后面训练和推理都要用，丢了就得重新对一遍标注文件里的标签名，非常麻烦。

3. 把电子病历文本格式化成BERT输入：数据处理的最小可跑管线

3.1 原始病历标注文件的接入方式

拿到一份电子病历标注数据，最常见的形式是每一行一个句子，每个字后面跟一个标签，用空格或Tab分隔。比如这样：

患 O 者 O 因 O 胸 B-Symptom 痛 I-Symptom 伴 O 发 B-Symptom 热 I-Symptom

读取时不要用简单的readlines然后split，因为病历文本里可能自带空格和特殊符号。我习惯用jsonl格式做中间介质：每一行是一个字典，包含text和label两个字段，label数组长度必须和text的字数一致。转换脚本也不复杂，核心是把原始的逐字标注行拼回完整句子，同时把标签序列保存下来。这里要留一个数据校验逻辑：如果text去掉空格后的长度和label列表长度不一致，直接抛异常，避免脏数据进入训练。

预处理还包括清洗。电子病历里有大量全角标点，还有“患者姓名：张三”这种键值结构。实体识别关注的是病情描述部分，键名本身不是实体，但键值里的人名可能被模型错误识别成实体。我有一个习惯：把“姓名、年龄、住院号、床号”这些字段在预处理阶段直接替换成特定占位符，比如把“张三”换成“PATIENT_NAME”。这样既避免模型对人名产生过拟合，又不会破坏句子结构。清洗规则要写在配置里，不要散落在代码各处，否则换一份数据时根本想不起来当时怎么处理的。

3.2 token化与标签对齐：做不对会直接报错

拿到text和label后，下一步是调用BERT的tokenizer。这里有一个关键认知：BERT的中文tokenizer是把每个字映射到一个token id，但会在句子首尾自动加上[CLS]和[SEP]。这意味着输入序列的长度是原文字数加2，标签序列也必须同步扩出来。很多第一次写BERT NER的人，直接把标签数组原封不动扔给模型，长度对不上，训练时直接报维度错误。

更隐蔽的问题是，某些中文tokenizer会把罕见字符拆成多个token。比如生僻字在bert-base-chinese的vocab里不存在，会变成两个甚至三个子词token。如果标签序列还按一个字一个标签来给，子词展开后标签数量就不够了。代码里处理方式是逐token对齐：对text做tokenize后，逐个检查每个token是否能对应回原文的一个字符，能对应就复制标签，不能对应就填充一个特殊的“X”标签并不参与损失计算。这一层逻辑是所有BERT序列标注源码里最容易出错的部分，没有之一。

下面这段是我常用的标签对齐函数，可以放在数据预处理模块里：

def align_label_with_tokens(raw_text, raw_labels, tokenizer, label_map): """把字级标签对齐到BERT token序列，处理[CLS]/[SEP]和子词被拆分的情况""" encoded = tokenizer(raw_text, truncation=False, return_offsets_mapping=True) offset_mapping = encoded["offset_mapping"] aligned_label_ids = [] char_index = 0 for offset in offset_mapping: start, end = offset # [CLS]和[SEP]对应的offset是(0,0) if start == 0 and end == 0: aligned_label_ids.append(label_map["O"]) continue # 当前token在原文里占一个或多个字符 if end > start: char_label = raw_labels[char_index] aligned_label_ids.append(label_map[char_label]) char_index += end - start else: # 理论不会走到，防御式编程 aligned_label_ids.append(label_map["O"]) return encoded["input_ids"], encoded["attention_mask"], aligned_label_ids

逻辑说明：return_offsets_mapping会返回每个token在原始文本里的起始和结束偏移量。遍历每个token的offset，如果是[CLS]或[SEP]就补O标签；如果是真实字符，取当前字符位置对应的标签，然后把char_index向后移动该token占用的字符数。这样一个token对应一个标签，长度天然一致。

参数说明：raw_labels必须是和raw_text字符数相同的字符串数组；label_map负责把“B-Symptom”这类标签名映射成数字id。使用这个函数时，建议先打印一两句样本的input_ids和label_ids长度做人工核对，确认对齐无误后再进行批量处理。

3.3 截断策略：长病历怎么处理而不丢实体

电子病历里的一段主诉可能超过200字，而BERT的最大序列长度通常是512个token。如果文本长度超过上限，不截断就直接报错，截断了又可能把句尾的实体切掉。首先要明确一点：BERT的512限制是预训练时的硬编码，输入超过512后位置编码不存在，直接炸。所以必须在预处理阶段决定截断方案。

最简单的方案是head-only截断：保留前510个字符加[CLS]加[SEP]。但电子病历的描述习惯是“先起病情况，后诊疗经过”，实体并非均匀分布。更稳的方案是按句切分：把整个病历按句号、逗号切成多个句子，然后以句子为单位拼接到不超过最大长度。这样单句实体完整，代价是跨句的上下文信息会丢。实际项目中，我见过效果最好的处理方式是按滑动窗口滑过整个文本，窗口大小设为256，步长设为128，让相邻窗口有重叠区域。

从工程实现角度来说，最简单可控的还是head-only + 合理清洗。先把“姓名、住址、电话”这类无关长字段删掉，然后把主诉和现病史优先保留在序列头部。实际统计一下实体分布，你会发现大多数实体确实集中在前半部分。这里有个强制要求：截断操作必须发生在标签对齐之前，而不是之后——先截原文和原始标签，再做tokenize和对齐，否则对不齐。

3.4 DataLoader和batch组成

数据处理的最后一步是把样本组织成batch。每个样本包含input_ids、attention_mask、token_type_ids和labels四个tensor。BERT的attention_mask用来区分真实token和padding位置，padding部分的标签要设为-100，这样在计算交叉熵损失时这些位置自动被忽略。这个细节很多源码都没写，但如果不做，padding处的O标签会拉低模型精度。

import torch from torch.utils.data import Dataset class EMRDataset(Dataset): def __init__(self, data_list, tokenizer, label_map, max_len=256): self.data_list = data_list self.tokenizer = tokenizer self.label_map = label_map self.max_len = max_len def __len__(self): return len(self.data_list) def __getitem__(self, idx): item = self.data_list[idx] text = item["text"] labels = item["labels"] # 先截断原文，再对齐 text = text[:self.max_len - 2] labels = labels[:self.max_len - 2] input_ids, attention_mask, aligned_labels = align_label_with_tokens( text, labels, self.tokenizer, self.label_map ) # 补齐到max_len并设置padding标签为-100 pad_len = self.max_len - len(input_ids) input_ids += [self.tokenizer.pad_token_id] * pad_len attention_mask += [0] * pad_len aligned_labels += [-100] * pad_len return { "input_ids": torch.tensor(input_ids, dtype=torch.long), "attention_mask": torch.tensor(attention_mask, dtype=torch.long), "labels": torch.tensor(aligned_labels, dtype=torch.long), }

这段代码说明一个关键原则：一切操作都在token化之前完成截断，token化之后只做padding。如果先tokenize再截断，标签对齐会变得非常麻烦，而且截断位置可能落在某个token中间。这里我用了固定的max_len=256，对大多数门诊病历来说已经够用；如果做出院小结这类长文本，可以调大到384或512，但训练显存和时间会显著上升，需要同步评估。

4. BERT+CRF的模型结构：输出层设计和训练参数配置

4.1 为什么在BERT上面加CRF层

BERT本身输出每个token对每个标签的概率分布，直接取argmax就能得到标签序列。问题在于，这个独立的标签预测没有考虑标签之间的转移关系。比如B-Symptom后面跟着O，这在BIO规则里是合法的；但B-Disease后面直接跟I-Symptom，这种跨类型的边界转移，理论上不应该出现。CRF层的作用就是学习一个标签转移矩阵，对整条标签序列做全局建模，让不合法的转移被惩罚。

对电子病历来说，CRF带来的提升非常明显。原因是病历实体密度高，“肺气肿”“肺功能检查”“肺CT”这几个实体里都有“肺”，但分属不同类别，模型在局部位置可能摇摆，CRF会通过前后的标签约束把它拉回来。代价是训练慢一点，推理慢一点，源码复杂度高一点。如果你的数据量少于1000条标注句子，CRF收益很大；超过5000条句子后，单纯BERT+softmax也能学到大部分转移规则，两者的差距会缩小。

如果不想手写CRF，可以直接复用现成的序列建模库。典型的实现思路是把BERT输出经过一层线性变换映射到num_labels维，然后把logits输入CRF层，CRF内部维护一个可学习的转移矩阵。训练时计算的是整条路径的负对数似然损失，推理时用维特比算法解码最优路径。我建议在小数据集上先用无CRF版本跑通流程，确认数据和评估没问题，再叠加CRF，这样排错时更容易定位问题。

import torch import torch.nn as nn from transformers import BertModel from torchcrf import CRF class BertNER(nn.Module): def __init__(self, model_name, num_labels, use_crf=True): super().__init__() self.bert = BertModel.from_pretrained(model_name) self.dropout = nn.Dropout(0.1) self.classifier = nn.Linear(self.bert.config.hidden_size, num_labels) self.use_crf = use_crf if use_crf: self.crf = CRF(num_labels, batch_first=True) def forward(self, input_ids, attention_mask, labels=None): outputs = self.bert(input_ids=input_ids, attention_mask=attention_mask) sequence_output = outputs.last_hidden_state logits = self.classifier(self.dropout(sequence_output)) if labels is not None: if self.use_crf: # mask传CRF时要把padding位置置为False mask = attention_mask.bool() loss = -self.crf(logits, labels, mask=mask) return loss else: loss_fn = nn.CrossEntropyLoss(ignore_index=-100) loss = loss_fn(logits.view(-1, logits.shape[-1]), labels.view(-1)) return loss else: if self.use_crf: mask = attention_mask.bool() predictions = self.crf.decode(logits, mask=mask) return predictions else: return torch.argmax(logits, dim=-1)

逻辑说明：模型整体分三段，BERT取出每个位置的上下文表示，线性层映射到标签空间，CRF负责序列约束。训练阶段有labels传入时计算损失；推理阶段走decode路径。这里labels中的-100是给CrossEntropy用的padding遮罩，但CRF不能接收-100标签，所以走CRF分支时必须用mask标记有效位置。

参数说明：model_name传入本地权重路径或huggingface的模型名；num_labels由label_map字典长度决定；dropout设为0.1是BERT微调的常见选择，太高容易欠拟合，太低在小数据集上容易过拟合。注意torchcrf需要batch_first=True，如果你的BERT输出维度顺序是[seq_len, batch, hidden]，要把维度换回来。

4.2 训练参数：照着抄就能跑的一组配置

BERT微调不像从零训练CNN那样需要精细调参，但几组参数之间确实有天壤之别。最重要的三个：学习率、batch size、epoch数。BERT的下游微调学习率通常在1e-5到5e-5之间，2e-5是默认起点。batch size在BERT-base模型上，12GB显存用16或32没问题，显存小就降到8，配合梯度累积等效放大。epoch数看数据量，几千条标注句子时5到8个epoch就能收敛，再多就会过拟合。

warmup策略是必须做的。BERT在预训练阶段的优化器状态是特定的，微调一开始直接用大步长，容易把预训练学到的特征破坏。常见做法是前10%的训练步数做warmup，学习率从0线性升到目标值。配合AdamW优化器和线性衰减调度器，整体训练曲线会比较稳。权重衰减设0.01，这是BERT微调的标准值，不要随意加大。

我这边的推荐配置整理成一张表，方便对照检查：

这里有一个血泪经验：不要一上来就用BERT-base跑满512长度。电子病历句子参差不齐，平均可能就60个字符，但偶尔来一条500多字符的，导致batch里大部分样本被padding到512，训练速度直接慢四倍。正确做法是先统计训练集的长度分布，用95分位数作为max_len。多数情况下128或192就够，解码器速度和显存占用都会友好很多。

4.3 类别不平衡的处理

电子病历标注数据里，O标签的比例通常超过80%，甚至到90%。BERT的CrossEntropy是按batch计算的，O类样本远远多于实体类，模型会倾向于把所有位置都预测为O，这样loss也不高但实体全丢了。解决办法有三种，按效果排序。

第一种是给损失函数加权，根据训练集各类别频率的倒数设置class weight。这样做最直接，但需要把类别频率统计逻辑写进预处理脚本，换数据集时重新统计。第二种是Focal Loss，它会降低易分类样本的权重，让模型更关注难分的实体边界，实现稍复杂。第三种是我常用的混合方案：不调整权重，但把batch里的O样本占比控制在50%以内，做法是采样时按句子维度过滤——如果一整条句子没有任何实体，就随机丢掉一部分这类句子，同时保留纯O句子防止过拟合。

from collections import Counter def filter_data(data_list, keep_ratio=0.3): """把不含实体的样本降采样，缓解O标签过多的问题""" has_entity = [] no_entity = [] for item in data_list: labels = item["labels"] if any(label.startswith("B-") for label in labels): has_entity.append(item) else: no_entity.append(item) no_entity = no_entity[:int(len(no_entity) * keep_ratio)] return has_entity + no_entity

逻辑说明：这个函数按标签是否包含B-开头的实体来划分样本，无实体的样本保留三成，有实体的全部保留。效果是batch里O标签占比从90%降到60%左右，模型能更多看到实体样本。参数说明：keep_ratio太小会让模型对实体过于敏感，预测时会疯狂产出假实体；太大则类别不平衡依然严重。建议根据验证集F1来调，0.3是个不错的起点。注意要做分层抽样，实体的长尾类型如果本来就少，降采样时别把含这类实体的样本误删。

5. 从源码到可用模型：运行结果不理想时的五个排查点

5.1 标签错位：loss在降但验证F1一直不动

现象是训练输出里loss在正常下降，从3.0一路降到0.2，但验证集的F1却卡在50%出头，甚至比随机预测还差。这种情况十有八九是标签对齐在训练和验证阶段不一致。常见原因是在预处理脚本里对训练集做了清洗和降采样，却把原始的、未对齐的标签直接用在验证集上。还有一个原因是tokenizer的vocab版本不同——训练时用的一个vocab.txt，保存模型后推理时换了个版本，同一个字符被切成不同的子词，标签自然对不上。

解决方式是在数据管线的入口处加一个自检函数：随机抽三到五条样本，打印出原始文本、token序列、标签序列，人工对照一遍。不要嫌这个步骤笨，它能在五分钟内查出大多数对齐问题。另外要把分词器和模型权重绑定保存，用save_pretrained把config和tokenizer一并写入模型目录，推理时从同一目录加载，彻底杜绝配错版本的问题。

5.2 全预测成O：类别不平衡的典型翻车现场

模型训练结束后，推理结果里所有token都是O，一个实体都识别不出来。看loss曲线会发现它一直很低，因为模型找到了一个偷懒的解：全预测成O，损失照样能降到0.1以下。这正是前面说的类别不平衡问题，模型没有学到任何有效信息。检查方式很简单，统计一下验证集预测结果的标签分布，如果某个类别占了98%以上，就基本确认是这个原因。

解决路径有几条，按优先级使用。首先是做样本降采样，让含实体句子在训练数据里占更高比例。其次是给损失函数按类别频率加权，O类的权重压到0.2左右，实体类的权重放大2到5倍。最后再看训练轮数——如果epoch太少，模型还没见过足够多的正样本就被O类主导，可以适当增加epoch，并配合早停机制。这三条如果都做了还不行，检查一下标签映射字典有没有写错——有没有把I-Symptom错误的映射到和O同一个id上。

5.3 实体边界总差一个字：BIO和BIOES的取舍

模型能把“右下肺湿啰音”里的“湿啰音”识别出来，但把“右下肺”也当成一个实体类型的一部分，输出多了一个字或者少了一个字。典型情况是把“肺腺癌”预测成“腺癌”，或者把“胸骨后疼痛”的边界往左扩到“胸”。这类问题在电子病历里非常普遍，因为病历里的实体经常嵌套，“右肺上叶”既是位置又是实体的一部分。

这类情况我会先检查标签体系。BIO方案对实体内部标注只用B和I区分开头和内部，但缺少一个明确的结尾标记，模型在序列后半段容易把I误判成B从而提前开启新实体。换成BIOES后，边界清晰很多。另外一个提升点是给CRF层做定制——约束标签转移矩阵，比如禁止B-Disease直接转移到I-Symptom。如果数据里确实存在完全一样的嵌套模式，还可以考虑实体重叠的多任务方案，但那是进阶做法，先把边界错误解决再谈嵌套。

5.4 学习率太激进导致BERT灾难性遗忘

训练到第二个epoch时验证集F1突然大幅下降，甚至比第一个epoch低十几个点，多数情况不是随机波动，而是学习率设置过高导致BERT的底层语义被破坏。BERT的预训练权重是经过数月在大规模语料上优化出来的，微调时只需要轻微改动，如果学习率超过5e-5，更新步长太大，预训练学到的通用知识就会被冲掉。这种现象我称之为灾难性遗忘。

解决的第一个手段是降低学习率到2e-5或1e-5，第二个手段是冻结BERT底部若干层只训练顶部和CRF层，第三个手段是给BERT层设置一个比分类层更小的学习率。比如BERT层用5e-6，分类层用2e-5，这样既能微调语义特征，又不会破坏底部稳定的语言表示。在代码里实现并不复杂：把参数分成两组，分别设置不同的learning rate传入优化器，然后再拼接成一个param_groups列表即可。

5.5 推理速度慢到无法上线

模型训练好了，F1也不错，但输入一条200字的病历需要几百毫秒甚至一秒多才出结果。BERT-base本身有1.1亿参数，在CPU上跑序列标注，即使批量推理也难以达到实时要求。医院场景里如果是离线批量处理历史病案，慢一点可以接受；如果要嵌入临床系统实时返回，就需要做优化。

工程上常用的路径有三个，按投入从低到高排列。第一是批量推理，把多条病历pad成同一个batch，用GPU推理，吞吐量提升十倍以上。第二是模型量化，用动态量化把权重压到8bit整数，模型体积缩小四倍，推理速度提升两到三倍，精度损失通常不到一个点。第三是知识蒸馏，用训练好的BERT模型做教师，训练一个小的BiLSTM或小型Transformer学生模型。学术上这个方法效果不错，但工程成本最高，需要重新训练和调优。对于多数起步项目，先做批量推理和量化就足够撑住日处理万份病历的场景。

6. 评估与进阶：严格匹配指标、边界修正和模型落地习惯

6.1 实体级别的F1计算：为什么token级别指标会骗人

很多源码里直接计算每个token分类的准确率，然后当作模型指标汇报。这在电子病历NER里是误导性的——因为整个序列里O标签占绝大多数，预测准确率达到95%并不意味着实体识别做得好。真正要报告的是实体级别的精确率、召回率和F1：把预测的实体span和标注实体span做匹配，比的是实体作为一个整体是否被正确识别，而不是单个字是否正确。

def bio_to_entities(label_ids, id2label, text=None): """从标签序列还原实体列表，按BIO规则切分span""" entities = [] current_type = None start_pos = None for idx, label_id in enumerate(label_ids): if label_id == -100: continue label = id2label[label_id] if label.startswith("B-"): if current_type is not None: entities.append((current_type, start_pos, idx - 1)) current_type = label[2:] start_pos = idx elif label.startswith("I-"): if current_type is None: continue elif label == "O": if current_type is not None: entities.append((current_type, start_pos, idx - 1)) current_type = None start_pos = None if current_type is not None: entities.append((current_type, start_pos, len(label_ids) - 1)) return entities

这段代码从标签序列里还原出实体列表，返回的每个元素包含实体类型、起始位置和结束位置。评估时拿这个列表和标注的真实实体span列表做比对，只有类型和span完全一致才算一个正例。逻辑说明：B-开启一个新实体，I-延续当前实体，O或新的B-则关闭当前实体。这里对-100做了special case处理，因为padding位置不算实体的一部分。

6.2 严格匹配还是宽松匹配：不同阶段用不同标准

实体级别的F1有两种计算口径。严格匹配要求实体类型和字符span都完全一致才算对，宽松匹配只要span有重叠就认为正确，部分方案还要求类型一致但允许边界微小偏移。起步阶段我用宽松匹配，因为模型还在调试阶段，能识别出大概位置比纠结边界更重要；等模型稳定之后，切换到严格匹配并把它作为最终交付指标。

一个实用做法是把边界偏移量作为第二个报告维度。统计预测实体和标准实体边界偏移为0、1、2个字符的比例。如果大部分偏移量在1个字符以内，说明模型定位能力足够，差的是边界约束；如果偏移量分布很散，模型对实体定义本身就没学好。这两种情况对应的解决方案完全不同，前者优化CRF或BIOES，后者需要检查标注一致性和数据质量。

6.3 模型文件的组织：让推理时能正确加载

训练结束后保存模型时，不要只保存state_dict。BERT模型的推理依赖三个东西：模型权重、tokenizer配置、标签映射。我习惯用transformers的save_pretrained把模型和tokenizer都保存下来，另外单独把id2label和label2id两个映射存成json，整体放进同一个目录。推理脚本从目录加载时，才能保证和训练时完全一致的语义空间。

还有一个容易被忽略的细节：电子病历NER部署时经常遇到打印不出中文的问题，因为label名字是“B-Symptom”这类英文缩写，患者和医生看起来不方便。在推理接口输出时，要有一个从英文标签到中文显示的映射，同时把实体在原文里的字符位置也返回。这样前端可以直接把“症状：胸痛，位置：第3到第5个字”渲染成高亮文本，而不需要重新对齐一遍。

我自己的习惯是：每个项目保留一个model_card.json，记录训练数据的来源、切分方式、标签体系、超参数配置、验证指标。因为医疗数据标注很容易出现人员更换后的标注口径漂移，第一版和第二版数据可能对“症状”的定义有微妙差异。如果不记录这些信息，半年后回头调模型时，对这些数据做的一切分析都是黑匣子。模型可以重新训练，但数据口径一旦丢失，再想修正就难如大海捞针。希望这套流程和踩坑记录能帮你少走几条弯路。

本文还有配套的精品资源，点击获取