简介命名实体识别NER是自然语言处理的基础任务旨在从非结构化文本中抽取实体边界与类型。在中文医学领域电子病历中的疾病、症状、检查等实体识别对临床决策支持具有重要意义。实践中文NER时常面临数据格式复杂、字符级标注、模型选择等挑战。基于BERT的预训练模型结合CRF条件随机场能有效建模标签转移约束成为中文NER的主流基线方案。针对CCKS2019中文电子病历命名实体识别任务从数据解压、BIO标注解析、预处理、模型训练到评测提交系统梳理流程中的常见问题与解决方案帮助读者快速跑通完整实验少走弯路。 第一次收到“CCKS2019中文命名实体识别任务.zip”这个文件是在2020年。当时我正准备从零开始做医疗文本的信息抽取这个压缩包几乎是我入门中文NER的第一个正式训练集。但直到实际打开它我才意识到“拿到数据”和“用上数据”之间隔着一整条沟解压报错、标注格式不直观、字符级预处理的细节、模型训练和评测脚本的差异每一步都能把人卡住很久。这篇文章写给三类人想找一份中文NER数据来练手的学生或新人准备参加CCKS系列评测、研究基线方案的参赛者以及和我一样打开压缩包就撞上各种解压报错的倒霉蛋。我会把从解压文件、读懂数据、跑通BERTCRF基线到提交评测的完整过程连同我踩过的坑一起写出来。1. 这个zip包里到底装的什么先搞清CCKS2019的NER任务背景1.1 CCKS是什么为什么值得拿它当练手集CCKS是国内知识图谱与语义计算领域的老牌会议每年都会发布一系列评测任务数据大多来自真实业务场景比普通公开的新闻语料更“脏”、更有挑战。对NLP从业者来说CCKS任务包比自己爬数据再手工标注干净得多而且有官方评测脚本和排行榜拿来当练手集再合适不过。2019年的评测任务里和中文命名实体直接相关的是“面向中文电子病历的命名实体识别”这一类。任务目标很明确给定一段电子病历文本把其中涉及医学概念的实体抽出来并分类。这类数据在医疗信息化、临床辅助决策、病历结构化等场景里都有直接应用价值是典型的“学完就能用上”的任务。不过这里有个容易混淆的点CCKS2019的评测任务不止一个不同任务的数据格式和实体定义不完全一样。网上流传的“CCKS2019中文命名实体识别任务.zip”可能有多个版本有的来自电子病历NER有的来自其他子任务。所以拿到包之后第一件事永远是打开README看清楚这个包到底是哪个任务的、标注了什么实体类型而不是直接上模型。1.2 中文NER任务的共同设定边界和类型缺一不可不管来自哪个子任务“中文命名实体识别”的核心定义都差不多给定一句中文文本输出所有命名实体的边界和类型。举个例子句子“患者因冠心病入院”里“冠心病”是一个实体类型是“疾病”模型不仅要认出“冠心”和“冠心病”的区别还得分对类型是疾病而不是症状。在电子病历这类医学场景里常见实体类型通常包括疾病、症状、检查、治疗、身体部位。不同任务包可能还会细分出药品、手术、检验指标等类型。标注粒度一般直接做到“字”级别也就是说每个汉字都会被赋予一个标签而不是像英文NE那样按词标注。这一点很关键直接决定了后续怎么做数据预处理。1.3 压缩包内的文件预期先看README再动代码一个标准的评测任务包里面通常会有这么几类文件README或任务说明文档说明数据来源、标注规范、实体类型、提交格式train集带标注的训练语料用于训练模型dev集带标注的验证语料用于调参和早停test集不带标注的测试语料用于最终提交评测评测脚本官方给出的打分脚本通常用Python或Perl写成。这里特别提醒一句测试集的标签可能是空的也可能放在另一个隐藏文件里。如果直接打开test发现一大片空白别慌这是正常现象。评测时你要根据训练集和验证集总结出的实体类型去预测test的标签交上去之后由官方脚本统一打分。有些包为了防作弊甚至会把test文件做特殊编码评测前还要先跑一个官方提供的“还原脚本”。2. 解压这个zip的完整排查手册从常规命令到EOCD异常2.1 常规解压Linux、Windows、macOS一条龙先讲正常路径。如果你用的是Linux服务器最直接的就是unzip CCKS2019中文命名实体识别任务.zip如果文件名包含中文建议先看看当前环境的locale是否支持UTF-8。Windows下右键“全部解压缩”基本够用但有些从网盘流出的包会被二次压缩解压完发现里面还是个zip那就继续解第二层。macOS直接双击或者用unzip -O gbk处理中文文件名乱码的问题。我自己习惯统一的目录结构CCKS2019_NER/ ├── README.md ├── data/ │ ├── train.txt │ ├── dev.txt │ └── test.txt ├── eval/ │ └── evaluate.py └── ccks2019_dataset.zip把原始zip归档保存再解压出一个干净的工作目录这样即使后面数据处理搞坏了也能随时从原始包里恢复。2.2 “file is not a zip file”的真正原因这是很多新人第一次撞上的报错。看到“file is not a zip file”第一反应往往是“文件坏了”但实际上更常见的原因是文件根本不是zip只是文件名带着.zip后缀。网络流传的压缩包经常被网盘改动或者被人二次封装。用Linux自带的file命令看一眼真实类型一切就清楚了file CCKS2019*.zip输出可能是CCKS2019.zip: gzip compressed data那说明它其实是个gzip压缩包把后缀改成.tar.gz再用tar -xzf解压就行。如果是RAR archive data需要unrar x如果是7-zip archive data用7z x。所以这个报错本质上是“扩展名与实际格式不匹配”不是玄学。还有一个场景文件明明就是zip但下载过程中被浏览器或下载工具改写成了非标准格式导致文件头损坏。这时先重新下载一遍用md5或sha256校验值和源头对比。如果源头没有校验值那就只能换个下载渠道。2.3 could not find EOCDzip的中央目录到底去哪了EOCD全称是End of Central Directory也就是zip文件的中央目录记录它位于zip文件末尾。解压工具先读文件末尾的EOCD才能定位整个zip的内部文件列表和压缩数据。如果报错“could not find EOCD”或“invalid zip archive: could not find eocd”基本可以锁定文件末尾被截断了或者文件根本没下载完整。这个报错在Java环境里也很常见尤其是用ZipInputStream读不完整的zip时会直接抛异常。报错信息里如果还带着“failed to copy spatial iop zip”之类的内容多半是从某个传输工具里拿到的压缩包本身不完整。处理办法按优先级排重新下载用支持断点续传的工具比如wget的-c参数或浏览器下载管理器下载后用zip -T测试文件的完整性如果系统提示“意外结尾”但文件能解出大部分内容可以用zip -FF尝试修复它会尽量重建中央目录。zip -FF damaged.zip --out repaired.zip unzip repaired.zipzip -FF不是万能的如果文件头尾都丢了它也无能为力。但从实际经验看它至少能救回一部分数据对于紧急拿到数据包却无法重新下载的场景值得一试。2.4 分卷压缩、中文乱码和“锟斤拷”如果你下载下来的是一堆z01、z02加一个.zip这是分卷压缩。z01必须和主zip放在同一个目录下用7-Zip或PeaZip选择第一个.zip文件解压工具会自动合并后续分卷。注意分卷文件不能单独解压也不能改名。另一个高频问题是Windows下压缩的zip到Linux下解压后文件名变成乱码。这是因为Windows的zip默认使用GBK编码保存文件名而Linux的unzip默认按UTF-8解码。当编码对不上时你会看到类似“锟斤拷”这种经典的“UTF-8被当GBK读”乱码。解决办法是让unzip按GBK解压unzip -O GBK CCKS2019*.zipmacOS上的unzip不一定支持-O可以用7z代替7z x CCKS2019*.zip -oCCKS2019_NER如果文件包里内容本身是中文这里还有个小坑解压出来文件名正常但打开文件后内容里的中文还是乱码那多半是文件内部编码问题需要用编辑器把数据的编码统一转成UTF-8。Windows记事本另存为UTF-8或者在Linux下用iconv批量转码后面NLP流程才不会出幺蛾子。2.5 遇到加密zip怎么办有的任务包因为涉及医疗数据隐私会被加密压缩。解压时提示输入密码全局方式位标记里的bit 0也会被置1表示“文件有加密”。这种情况下正确且合规的做法只有一种联系文件分享者或任务发布方索取密码。不要去尝试任何破解手段既不符合数据使用规范也不安全。如果密码是你自己设的但忘了可以找找历史聊天记录或邮件里有没有留存比折腾各种工具靠谱得多。3. 数据格式拆解把标注文本变成模型输入3.1 逐字的BIO/BIOES标注格式花大力气解开zip之后真正的活儿才刚开始。CCKS这类中文NER任务包里最常见的数据格式是BIO逐字标注每行一个字符字符和标签之间用空格或制表符分开空行表示一句话结束。BIO的含义是B-实体类型当前字符是某类实体的开头I-实体类型当前字符在同类实体内部O不属于任何实体。有些任务包会用BIOES多出E-结尾和S-单字实体两个标签。两种标注各有优劣BIOES在实体边界信息上更显式但标签数量更多。CCKS2019的电子病历任务里训练数据长下图这样冠 B-疾病 心 I-疾病 病 I-疾病 入 O 院 O 治 O 疗 O 患 O 者 O 出 O 现 O 胸 B-症状 闷 I-症状每一行对应一个字符空行切分句子。注意这里“冠心病”三个字被标成B-疾病、I-疾病、I-疾病而“胸闷”则是“胸”字开头加“闷”字接着。理解这个标注逻辑后再去构造训练集就有底了模型要预测的是每个字符的标签再把标签序列翻译回实体边界。3.2 为什么中文NER直接做字符级而不是先分词很多刚接触中文NLP的人会问为什么不先分词再对词做实体标注实际做下来你会发现分词本身就会引入错误而像“冠心病”“肺源性心脏病”这种医学词通用分词器根本切不对错误还会一路传播到实体识别里。字符级的做法等于绕开了分词这个易错环节让模型自己从上下文里学边界。BERT的双向注意力机制天然适合这种任务它能在字符级别捕捉到“冠心病”这个三字组合出现的上下文模式。所以在CCKS2019这类中文NER任务上几乎没有人会先分词再训NER都是直接做字符序列标注。3.3 构建字符级数据集的预处理Pipeline我自己写数据读取时会先做一个非常朴素的版本def load_bio_file(filepath): sentences [] labels [] sent_chars [] sent_tags [] with open(filepath, r, encodingutf-8) as f: for line in f: line line.strip() if not line: if sent_chars: sentences.append(sent_chars) labels.append(sent_tags) sent_chars [] sent_tags [] continue parts line.split() if len(parts) 2: char, tag parts sent_chars.append(char) sent_tags.append(tag) if sent_chars: sentences.append(sent_chars) labels.append(sent_tags) return sentences, labels这里有个细节用split()而不是手动按空格切能顺便过滤掉制表符和多余空格。电子病历文本里经常夹杂全角空格\u3000和半角空格读进来之后建议统一清洗否则字符标签对不上模型训练时直接报错。接着建立标签映射label_list [O, B-疾病, I-疾病, B-症状, I-症状, B-检查, I-检查, B-治疗, I-治疗, B-身体部位, I-身体部位] label2id {l: i for i, l in enumerate(label_list)} id2label {i: l for l, i in label2id.items()}如果是BIOES格式就把E-和S-补进去。这里的核心思路是先把数据变成“字符序列 标签序列”的二元组后续BERT的tokenizer也是按字符级别处理中文两者能直接对齐。4. 快速跑通一个中文NER基线BERTCRF的关键配置4.1 为什么基线不选BiLSTM直接上BERTCRF如果是三年前我会推荐BiLSTMCRF因为那时候BERT还没这么普及。但现在做中文NER尤其是电子病历这种领域性强、上下文依赖明显的任务BERTCRF几乎是性价比最高的起点。原因有三第一BERT的预训练表示已经包含大量中文通用语义迁移到医学领域后只需少量训练数据就能达到不错的泛化效果第二CRF层能显式建模标签之间的转移约束比如B-疾病后面可以接I-疾病但O后面不应该直接接I-疾病这类硬约束纯BERT的softmax输出学不会第三推理和实现都很成熟工程成本低。4.2 模型与超参配置我跑CCKS2019这类任务时常用的配置如下参数值说明预训练模型bert-base-chinese中文Bert词表覆盖常用汉字序列长度128或256电子病历文本通常不长但要注意截断策略batch_size16或32根据显存调整优化器AdamW配合线性warmup学习率5e-5BERT层常用CRF层可以略高到1e-4weight_decay0.01防止过拟合epoch5~10用dev集早停核心代码如下import torch from transformers import BertTokenizer, BertForTokenClassification from torchcrf import CRF class BertNER(torch.nn.Module): def __init__(self, num_labels): super().__init__() self.bert BertForTokenClassification.from_pretrained( bert-base-chinese, num_labelsnum_labels) self.crf CRF(num_labels, batch_firstTrue) def forward(self, input_ids, attention_mask, labelsNone): outputs self.bert( input_idsinput_ids, attention_maskattention_mask, return_dictFalse ) logits outputs[0] # [batch, seq_len, num_labels] if labels is not None: return -self.crf(logits, labels, maskattention_mask.bool()) else: return self.crf.decode(logits, maskattention_mask.bool())用pytorch-crf库时特别注意它要求标签必须是0到num_labels-1的连续整数如果数据里有不在映射表里的标签训练时会报越界错误。另外mask参数要传给CRF否则填充位置的标签也会参与损失计算模型会被带偏。4.3 训练时最容易翻车的三个坑第一个坑是loss不降。如果训练到第二个epoch还是居高不下先检查数据预处理BERT tokenizer会把中文切成一个个单字但英文和数字会被切成子词导致输入ids的长度和标签长度对不上。我的做法是构造input时强制用return_tensorspt并在一个数据集类里完成对齐而不是在循环里临时处理。第二个坑是CRF层和BertForTokenClassification的标签数量不匹配。很多新手会直接把BertForTokenClassification.from_pretrained(..., num_labelslen(label_list))的结果拿来算交叉熵再手动加CRF结果发现logits的维度对不上。我的实现里用self.bert只取logits不放损失CRF单独做解码逻辑更清晰。第三个坑是电子病历文本里的O标签占比极高。一份病历里可能90%以上的字符都是O模型容易“偷懒”全部预测成OF1看着还行但实体一个都抽不出来。发现这个问题后我会在训练时对非O标签的loss做加权或者用Focal Loss的思路压一压类别不平衡。CRF的转移矩阵本身也能缓解一部分问题但加权loss更快见效。5. 评测指标与提交阶段的隐蔽失分点5.1 实体级严格匹配类型和边界都不能错CCKS任务包自带的评测脚本通常计算的是实体级别的Precision、Recall和F1而且采用严格匹配预测实体的起止位置和类型必须和真实实体完全一致才算一个正确预测。举个具体例子真实实体模型预测是否算对冠心病/疾病冠心病/疾病对冠心病/疾病冠心病/症状错冠心病/疾病冠心/疾病错冠心病/疾病冠心病/身体部位错也就是说只预测对类型但边界偏移一位算错边界对但类型错也算错。很多人调模型时只看token-level的accuracy等提交后才发现实体级F1很低原因就在这。我在本地复现官方评测时会把预测的BIO标签序列还原成实体列表再逐条比较而不是简单比较标签序列。5.2 提交格式的坑多用一行都致命官方提交一般要求每行对应测试集的一个字符或一个实体具体格式以任务包内的README为准。常见的要求有几类提交字符 预测标签行数和test原始文件完全一致提交JSON格式每行是一个句子ID对应的实体列表提交实体列表格式为句子ID\t实体起始索引\t实体结束索引\t实体类型\t实体文本。第一种格式最常用但坑也最多。如果test里没有标签列你必须自己构造一个和test等长的输出文件。这里最容易犯的错误是处理过程中过滤了空行或特殊字符导致输出行数比test少了一行。官方脚本通常不兼容这种长度不匹配的提交直接报错或者把整份结果判为无效。我自己的做法是预处理时给每个句子一个唯一ID预测完再把标签写回原文件对应的行最后用一个脚本检查输出行数和test行数是否一致with open(test.txt) as f: orig_lines f.readlines() with open(pred.txt) as f: pred_lines f.readlines() assert len(orig_lines) len(pred_lines), fline count mismatch: {len(orig_lines)} vs {len(pred_lines)}5.3 我踩过的几个失分点第一个是把dev集当test集提交。这个失误听起来很低级但真发生过。dev集本身是有标签的如果你用dev集跑预测本地F1看起来会非常高但提交上去系统检测到预测结果和公开标签一致直接取消资格或者判违规。所以提交前一定要确认自己用的是test目录下的文件而不是dev。第二个是忘了加载best model。训练时用early stopping保存了best model但推理时不小心load了最后一个epoch的模型结果分数明显下滑。用PyTorch写推理脚本时务必显式指定加载那个best.pt或best_model_state.bin。第三个是全角字符和不可见字符。电子病历文本里经常有全角空格、全角括号、零宽字符。这些字符在分词时看起来无害但在字符级NER里它们会造成标签偏移。比如模型把“发热3天”里的“”当成一个字符输出O但原始标注数据集里可能把全角括号和半角括号视作不同字符。读数据时统一做一次全角转半角或剔除不可见字符能省不少麻烦。下面是一个简单清洗函数import unicodedata def clean_text(text): # 全角转半角保留中文 text unicodedata.normalize(NFKC, text) # 去掉零宽字符 text text.replace(\u200b, ).replace(\u200d, ).replace(\ufeff, ) return text注意全角转半角要保留中文的完整性NFKC会把中文全角标点转成半角但对汉字本身没有影响。跑评测前拿dev集对比“清洗前”和“清洗后”的分数能直观看到这类字符带来的损失。6. 跑完这个任务后我留下的工具箱6.1 代码结构怎么组织才不翻车CCKS任务包规模不大但代码一多也容易乱。我更推荐把数据、模型、工具拆开目录结构如下ccks2019_ner/ ├── data/ │ ├── raw/ # 原始zip解压后的文件 │ ├── processed/ # 清洗后的统一格式数据 │ └── cache/ # tokenizer缓存 ├── src/ │ ├── dataset.py │ ├── model.py │ ├── train.py │ ├── predict.py │ └── eval.py ├── scripts/ │ └── check_line_count.sh └── output/ ├── best_model/ └── prediction/这个结构最大的好处是raw永远只读不改processed可以随时重新生成。跑坏了一次直接从raw重新处理就好不用回头追查到底哪一步无意中改了源文件。6.2 提升分数的方向微调、数据增强与伪标签如果BERTCRF基线已经能跑到不错的F1还想再往上提可以按性价比排序尝试领域预训练用大量无标注电子病历或医疗文本对bert-base-chinese做一次MLM继续预训练。这一步能让模型理解“冠心病”“肺源性心脏病”这类医学表达效果通常比直接fine-tune更好数据增强在训练集上做同义替换比如“患者”和“病人”互换“胸闷”替换成“胸部闷胀感”。但医学实体替换要非常小心不能把一个疾病名替换成另一个不同的病多模型集成同一套数据训3个不同随机种子或不同预训练模型比如bert-base-chinese和MacBERT预测时投票。F1通常能提升0.5到1.5个百分点伪标签用当前模型预测无标注的test集挑高置信度的样本回填到训练集再训一轮。这个方法在数据量小的时候提分明显但要注意噪声累积。6.3 最后一个建议把评测脚本自动化我做这个项目时最大的一个习惯是把本地评测和提交都脚本化。每次训练完自动用best model跑dev集调用官方评测脚本计算F1并保存预测结果到带时间戳的目录。这样的话每次调参后的效果变化都一目了然不会出现“这版到底比上版提高了多少”的黑历史。另外如果你用的是多卡环境记得固定随机种子import random, numpy as np, torch seed 42 random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed)别小看这一步不固定种子的话同一份代码和超参两次训练可能差出0.5个点到时候连调参方向都看不清。跑完CCKS2019这个中文NER任务我对“命名实体识别”这件事的理解扎实了很多。它不像文本分类那么直给也不像文本生成那么开放它是一个“精确到字符”的任务任何误差都看得见摸得着。如果你手上也有这个zip或者准备参加下一届CCKS的评测任务希望这份从解压到调参的完整记录能帮你少走几段弯路。数据会脏代码会报错但只要把每一步的坑都看清中文NER的大门就算真正打开了。本文还有配套的精品资源点击获取