简介一份面向自然语言处理学习者的三元组识别项目基于预训练语言模型与条件随机场实现从中文文本中自动抽取主体、谓词、客体结构。压缩包共十一个文件以六个Python脚本为骨架覆盖模型搭建、数据切分、训练、预测与参数配置等完整环节并附带说明文档、依赖清单和一张示意图片整体体积仅三十七KB代码精简、结构清晰。已有一百二十二人学习浏览。项目内置BERT中文预训练权重并完整串联了数据清洗、序列标注、模型训练、指标评估与结果预测流程可直观理解预训练模型与条件随机场层如何协作完成序列标注也适合作为知识图谱构建、信息抽取任务的快速上手模板。无论是准备毕业设计还是学习NLP工程实践都能从中获得可直接修改复用的参考代码。1. 拿到 “11-BertCRF 三元组识别.zip” 后我先告诉你它是什么一个命名带序号的压缩包基本就是课程或项目交付里的一个完整实验工程。拆开名字看Bert 负责把句子编码成带上下文的向量CRF 在解码端强制标签之间的转移约束两者拼在一起做三元组识别——也就是从非结构化文本里抽出 (实体头, 关系, 实体尾)。这个方案到今天仍是中文关系抽取里性价比最高的落地路径之一比生成式抽取容易控制格式比纯 BiLSTM 基线高 35 个点也不需要你从零训一个大模型。常见做法是序列标注路线把三元组转成 BIO 标签序列Bert 输出每个 token 的标签概率CRF 再补一层全局最优解码。读者里大概有三种人正在做知识图谱入库的算法工程师、接到信息抽取需求的学生、以及想把关系抽取能力塞进现有 NLP 管线的后端开发。如果你属于其中之一这篇文章把一个可交付的 zip 工程拆成五个部分——选型理由、数据预处理、训练命令、解码后处理、踩坑记录你照着复现就能在自己的数据上跑出可用模型。2. 三元组识别为什么要用 BertCRF选型理由与标签体系设计2.1 三元组识别不是“识别实体”而是联合做关系抽取三元组识别在工业界更常见的叫法是关系抽取或联合抽取目标是输出(head, relation, tail)这样的结构化事实。比如输入“字节跳动收购了 VR 创业公司 Pico”期望输出(字节跳动, 收购, Pico)。它和命名实体识别最大的差别在于实体识别只回答“哪些词是实体、属于哪类”而三元组识别要额外判断实体之间是否存在某种关系。关系抽取在工程实现上分两派。一派是生成式用 T5、BART 这类模型直接生成三元组文本好处是标签体系灵活坏处是推理慢、输出不好约束成严格的结构化字段上线前还要做一大堆格式校验。另一派就是本 zip 包的路线把关系抽取建模成序列标注。你先定义一组带关系语义的 BIO 标签比如B-H、I-H、B-T、I-T再让模型把每个 token 打到某个标签上最后把标签序列解码成三元组。这个路线的好处是解码逻辑可控标签转移矩阵本身就是最硬的一条规则约束。选 BertCRF 而不是 Bertsoftmax关键在标签的连贯性。序列标注里“B-H 后面不该直接跟 I-T”“I 类标签前面必须有一个 B 开头”这种约束用独立 softmax 是学不干净的模型可能对每个 token 的预测都正确但连在一起成了非法的标签序列。CRF 层能显式建模相邻标签的转移概率让解码结果在全局上合法。2.2 Bert 当编码器为什么不用 Word2Vec 或者直接上大模型Bert 在本方案里承担的是 Encoder 角色把每个 token 映射成包含上下文的向量再经过一个线性层投影到标签空间。和 Word2Vec 这类静态向量相比Bert 能解决一词多义——比如“苹果”在“苹果发布了新手机”和“他削了一个苹果”里语境不同向量也不同。在三元组识别里关系词往往高度依赖上下文静态向量基本很难做得准。中文场景下一般直接用bert-base-chinese或哈工大chinese-bert-wwm-ext作为初始化权重然后在你自己的域内数据上做微调。这个 zip 工程如果面向的是金融、医疗这种专业领域直接拿通用中文 BERT 微调也能出不错的效果但想要更高精度就需要先做领域预训练或者用 RoBERTa-wwm-ext 这类更强底座。选型对照如下编码器参数规模中文效果训练成本适合场景BERT-base-chinese约 1.1 亿通用场景够用单卡可训冷启动、通用文本RoBERTa-wwm-ext约 1.1 亿比 BERT-base 高 12 点单卡可训全词遮蔽中文更友好领域继续预训练版约 1.1 亿域内明显提升需要先做 MLM 再微调金融、医疗、法律等专业语料需要理解一点Ber t在输入侧用的是 WordPiece 分词中文字通常切成单字所以标签序列的长度必须和分词后的 token_ids 对齐。你拿到手的数据如果是“词 标签”的粗粒度标注预处理时要做一次词到 token 的映射这一步最容易出 bug后面第 3 章会专门写。2.3 CRF 解码端把“合法输出”作为模型的硬约束CRF条件随机场在命名实体识别和关系抽取里几乎是默认标配。它做的事情可以这样理解不只是让每个 token 的预测概率最大而是让整条标签序列的联合概率最大。具体公式里包含两部分——每个 token 的发射分数来自 Bert 的输出和标签之间的转移分数CRF 层自己学出来的矩阵。CRF 的转移矩阵是可训练的训练阶段模型会学到类似“B-H 后面大概率是 I-H 或 O不该是 B-T”这类模式。推理阶段用 Viterbi 解码在全局路径上找分数最高的合法序列。实际操作里不需要自己实现 Viterbi用torchcrf或pytorch-crf这类库即可它们会同时提供前向计算 loss 和解码函数。注意CRF 层的 mask 参数必须和 Bert 的 attention_mask 对齐padding 位置要排除在转移计算之外否则会出现长度不一致导致的维度报错——这条在我见过的项目里有个很反直觉的坑第 5 章会专门讲。提示本方案里 CRF 只负责标签序列的合法性不负责三元组的结构组装。后者是在解码后处理里完成的很多人误以为加了 CRF 三元组就自动能抽出来其实 CRF 只保证“打了合法标签”怎么拼成三元组还是你代码里的事。3. 把 zip 包改造成可训工程解压、目录结构与三元组转 BIO 的预处理3.1 先解决 zip 解压与项目目录结构别在这步浪费时间拿到11-BertCRF 三元组识别.zip第一件事不是看代码而是把压缩包安全解压。Windows 上直接右键“全部解压缩”通常能搞定但如果是从 Linux 服务器或课程平台下载的文件可能是 UTF-8 编码的 zipWindows 自带解压工具会把中文目录名解成乱码文件还是能用但路径里满是乱码很影响后续定位问题。常见做法是装一个 7-Zip 或者用 Python 的zipfile模块自己解后者还能顺手处理文件名编码import zipfile with zipfile.ZipFile(11-BertCRF 三元组识别.zip, r) as zf: for info in zf.infolist(): # 手动修正文件名编码优先尝试 cp437 - utf-8 转换 try: decoded_name info.filename.encode(cp437).decode(utf-8) except UnicodeDecodeError: decoded_name info.filename zf.extract(info, project_dir) if decoded_name ! info.filename: # 文件已解出来按正确名字重命名 import os old_path os.path.join(project_dir, info.filename) new_path os.path.join(project_dir, decoded_name) if os.path.exists(old_path) and not os.path.exists(new_path): os.rename(old_path, new_path)这段代码先把 zip 里的原始文件名按 cp437 编码重新转成 UTF-8绝大多数 Windows 端压出来的中文 zip 都会出现这种乱码问题。解出来的项目结构通常是data/原始语料、config/超参数配置、src/模型代码、output/checkpoint 和预测结果四个目录。如果解出来只有脚本和说明没有数据那这个 zip 大概率是课程代码你需要自己准备语料。在 Linux 服务端解压用unzip即可密码保护的压缩包用7z x会提示你输密码如果遇到“伪加密”的 zip——文件头标记了加密但实际数据没加密——可以用 7-Zip 打开若能看到内容就直接解压看不到内容就需要先用zip -s 0之类的工具清除加密标记再解遇到这种包的时候多是素材本身有二进制损坏别死磕解压工具优先检查 zip 是否下载完整。3.2 核心预处理把三元组转成 BIO 标签序列不管原始数据是 JSON、标注平台的导出格式还是类似(头实体, 关系, 尾实体)的三元组行文本训练前都要转成“token 标签”的序列标注格式。以最常见的数据形态为例一条样本是这样文本字节跳动收购了VR创业公司Pico。 三元组(字节跳动, 收购, Pico)这里只有一种关系“收购”所以标签体系里只需要一组实体头尾标签。更复杂的场景会混合多种关系比如“Pico属于字节跳动”和“字节跳动收购Pico”里的Pico在不同句子中承担不同角色。常见的做法是把实体角色也编码进标签比如用B-H/I-H表示头实体、B-T/I-T表示尾实体关系类型则作为模型的一个多分类输出或者把每种关系单独建一组标签。下面这段代码把三元组转成基于字符的 BIO 序列同时记录实体到 tag 的映射关系def make_bio_tags(text, triples): text: 原始句子 triples: [(head, relation, tail), ...] 返回 tags 列表长度等于 len(text)注意这里按字符粒度处理 tags [O] * len(text) span_tag_map {} # 用 (start, end, role) 存每个实体的角色 for head, relation, tail in triples: # 处理头实体 _match_spans(text, head, H, tags, span_tag_map) # 处理尾实体 _match_spans(text, tail, T, tags, span_tag_map) return tags, span_tag_map def _match_spans(text, entity, role, tags, tag_map): start 0 while True: idx text.find(entity, start) if idx -1: break # B 标签表示实体开头I 标签表示实体内部 if idx 0 or text[idx-1] ! entity[-1] or any(ch.isalnum() for ch in [text[idx-1], text[idxlen(entity)]]): tag_map[(idx, idxlen(entity))] role tags[idx] fB-{role} for j in range(idx1, idxlen(entity)): tags[j] fI-{role} start idx 1 return这段预处理有几个关键细节按字符粒度切分而不是按词是因为 Bert 中文分词会把词切成字字符级标签直接对应 token 序列省去词到字的映射。text.find查找实体时可能命中嵌套或歧义位置所以要用tag_map记录每次匹配结果并在解码阶段按位置排序后构造三元组。还要处理实体在句子中被切出多个责任区间的问题比如实体在句子中出现两次tag_map里会有两个区间两个都有效但对应不同的三元组位置需要后续对齐。3.3 数据划分与类别权重小数据量训练关系抽取最容易忽略的步骤序列标注数据集的构建往往比模型代码更花时间。一般建议至少准备 5000 条带三元组的句子太少容易过拟合太多人工标注成本高。数据按句子级别划分训练 / 验证 / 测试集比例常见做法是 8:1:1。但有一个非常关键的细节不要随机划分要用实体或关系类型做分层抽样保证验证集里每种关系都至少出现一次。否则你验证集里缺了一个关系类型模型在测试时会被低估。预处理最后一步是统计关系类别分布。如果某个关系的样本数极少训练时要在 loss 里给它加权重否则模型会直接放弃预测这个类别。下面这段是计算类别权重的代码from collections import Counter import math # label_counts 从训练集标注中统计 label_counts Counter(tag for seq_tags in train_data for tag in seq_tags) total sum(label_counts.values()) loss_weight {} for tag, cnt in label_counts.items(): # 罕见标签权重更高常见标签趋近 1 loss_weight[tag] math.log(total / cnt)权重计算公式默认用热度平滑后的逆文档频率思想实际幅度会在训练时用focal_loss或直接乘到CrossEntropyLoss的weight参数上。这一条在关系类别超过 10 类时会特别明显别等到模型训完才发现少数类全预测成 O。4. 训练一个可用的三元组识别模型最小工程代码与关键超参数4.1 最小训练骨架PyTorch Transformers CRF 的拼装方式标准的实现是继承BertPreTrainedModel或者直接在BertModel外面包一层得到 token 级别的 logits 后送入 CRF。这里给出一个可复用的训练骨架省略了数据加载器细节保留模型组装和 loss 计算的核心逻辑import torch from torch import nn from transformers import BertModel, BertConfig from torchcrf import CRF class BertCRFForTriplet(nn.Module): def __init__(self, model_namebert-base-chinese, num_tags5): 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_tags) self.crf CRF(num_tags, batch_firstTrue) self.num_tags num_tags def forward(self, input_ids, attention_mask, labelsNone): outputs self.bert(input_idsinput_ids, attention_maskattention_mask) sequence_output outputs.last_hidden_state logits self.dropout(self.classifier(sequence_output)) mask attention_mask.bool() if labels is not None: loss -self.crf(logits, labels, maskmask, reductionmean) return loss else: pred_tags self.crf.decode(logits, maskmask) return pred_tagstorchcrf的CRF类内部包含转移矩阵参数forward里直接把 Bert 的 logits 当发射分数传入即可。注意loss -self.crf(...)因为 CRF 计算的是对数似然要取负号才能梯度下降最小化。reductionmean在 batch 内做平均小 batch 下会更稳定如果你显存很充裕也可以把 batch 开到 32 以上这时用sum再除句子长度会收敛更平滑不过这属于调参偏好两种都常见。训练循环里还有两个细节容易踩一是 CRF 层的 learning_rate 建议比 Bert 主干大 10 倍因为 CRF 的转移矩阵是随机初始化的冷启动阶段需要更大的步长二是要把labels里的-100代表 padding 忽略位换成 0因为 CRF 的 mask 已经排除了 padding 位置但标签序列长度仍需和句子对齐。下面这段是优化器和训练循环的写法from transformers import get_linear_schedule_with_warmup optimizer torch.optim.AdamW([ {params: model.bert.parameters()}, {params: model.classifier.parameters(), lr: 3e-5}, {params: model.crf.parameters(), lr: 3e-4}, ], lr1e-5) total_steps len(train_loader) * epochs scheduler get_linear_schedule_with_warmup(optimizer, num_warmup_stepstotal_steps * 0.1, num_training_stepstotal_steps) for epoch in range(epochs): for batch in train_loader: loss model(**batch) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() scheduler.step() optimizer.zero_grad()这里把 Bert 参数和 CRF 参数分开设学习率是多数开源工程里隐藏的默认操作。clip_grad_norm_设为 1.0 能防止 CRF 在训练初期因随机转移矩阵导致梯度爆炸我见过不设这条导致 loss 直接变 NaN 的情况几乎成了 CRF 系模型的必加项。4.2 超参数默认值与调整方向抄作业的起点训练三元组识别模型不需要像预训练那样堆算力一张 12GB 显存的卡就够跑 Bert-base 的 batch_size 816但超参数的影响非常直接。给出一份基于常见工程经验的默认配置按这个配置起步再微调能避开大多数跑飞问题参数默认值调整说明max_length128超过 128 的句子截断容易丢失三元组业务长文本建议到 256batch_size16显存不够先降 batch别降 max_lengthlearning_rate2e-5主干用 2e-5CRF/分类头用 2e-4warmup_ratio0.1数据集小时 warmup 比例可以调到 0.2epochs5数据小于 1 万条时 5 轮足够再多容易过拟合gradient_clip1.0CRF 层必备别省冻结层数0数据量很少时可以冻结前 8 层 Transformer 只微调后 4 层max_length的选择有个权衡过长会让 batch 变小、训练变慢过短会截掉三元组的尾巴。中文场景下一句常见业务文本平均 3060 字128 基本够用但如果你的文本是动辄几百字的财报公告段落最好先做句子级切分再训练而不是直接塞长文本。句子切分的做法是先用标点符号把段落拆成子句每个子句单独作为一个样本这样既能保留max_length128的配置又能减少因截断导致的三元组丢失。4.3 解码与三元组组装从标签序列到结构化输出的最后一公里训练结束后模型输出的是每个 token 的标签但你要交付的是一条条(head, relation, tail)。这步的代码看起来简单实际问题却最多——标签序列里可能存在多个头实体或尾实体你要按标签里的角色把它们配对成三元组。一个稳妥的做法是先用 Viterbi 解出 token 级别的标签序列然后把连续B-*I-*合并成实体 span再按“每个头实体匹配离它最近的尾实体并复用关系类型”的规则组装。具体代码def decode_triplets(text, tag_ids, id2tag): text: 原始句子tag_ids: Viterbi 解码出的 tag 下标序列 tags [id2tag[i] for i in tag_ids] # 第一步把连续标签合并成 span entities [] # [(start, end, role, entity_text)] i 0 while i len(tags): if tags[i].startswith(B-): role tags[i][2:] j i 1 while j len(tags) and tags[j] fI-{role}: j 1 entity_text text[i:j] entities.append((i, j, role, entity_text)) i j else: i 1 # 第二步按位置配对头尾实体 triplets [] head_candidates [e for e in entities if e[2] H] tail_candidates [e for e in entities if e[2] T] for h in head_candidates: # 找句子中第一个在头实体之后的尾实体 best_tail None for t in tail_candidates: if t[0] h[1]: best_tail t break if best_tail: triplets.append((h[3], UNKNOWN_RELATION, best_tail[3])) return triplets这段代码里的配对策略是最简单的“最近匹配”在单关系场景下效果还不错多关系场景下就要升级为矩阵填表法或者把关系类型也作为标注的一部分。注意entity_text text[i:j]用的是字符级切分如果你的 Bert 分词是字粒度这里没问题如果是词粒度分词就要存 token 到字符的 offset 映射否则拼接出来的实体文本会缺字。最后这个函数返回的三元组里关系名是UNKNOWN_RELATION因为它完全由实体位置对决定。如果想要关系名需要在数据格式里让每种关系类别对应一组头尾标签或者在预处理阶段给每对头尾实体单独构造样本并把关系类型作为训练目标。5. 实操避坑记从解压到解码的 5 个典型异常排查5.1 zip 包解压后中文名乱码或提示文件损坏现象Windows 上解压 zip 后目录名成了__MACOSX或一串锟斤拷乱码或者解压到一半提示“文件已损坏”。原因有两类压缩包在 macOS 下生成会夹带__MACOSX元数据目录中文文件名被 zip 格式的老旧编码规则写成了 cp437Windows 解压工具用 ANSI 解码自然乱码。解决优先用 7-Zip 解压它会自动处理 UTF-8 中文名如果已经解压乱了用第 3 章的 Python 脚本重新解一次。至于“文件损坏”提示多数是下载过程中 zip 截断对比文件大小和源文件一致后再解别反复试解压工具。热词里搜得到的“zip 伪加密”也是同一类问题——文件头标记加密、数据未加密解压工具会要求输密码却没法输入7-Zip 打开能看到内容的话直接拖出来即可。5.2 CRF 解码结果里出现 B 后直接跟 I 的非法标签现象Viterbi 解码出的序列像[B-H, I-H, B-T, I-H]最后一个I-H前面一个标签是B-T肉眼明显不合法。原因你在用torchcrf的decode时传了maskNoneCRF 把 padding 位置也纳入转移计算padding 处乱跳的标签污染了真实标签的转移约束。解决decode 时显式传入mask并且检查 mask 的是否是attention_mask.bool()数值类型和形状都对齐。另外一个常见原因是你没用 CRF只用了BertForTokenClassification的softmax取 argmax这种独立分类天然没有转移约束序列不合法是常态。解决在项目中继续使用 CRF 层不要因为想省事退回纯 softmax。5.3 训练时 loss 正常但推理时结果全空或报错现象训练阶段 loss 稳步下降但加载 checkpoint 做推理时输出三元组列表是空的或者逻辑回归前向报维度不匹配。原因训练时标签里用了-100做 padding 忽略位但 CRF 的 mask 已经把 padding 位置排除掉了标签位却是-100CRF 内部会把-100当作合法标签索引参与转移计算导致训练和推理行为不一致。解决标签序列里不要用-100padding 位置的标签统一填 0用 mask 去控制哪些位置参与 loss。推理为空还有一个原因是 checkpoint 里只保存了 Bert 权重没保存 CRF 转移矩阵加载时CRF层重新初始化解码路径全乱。解决保存模型时用torch.save(model.state_dict())并且加载时用同一份代码构造模型不要单独 load Bert 权重。5.4 长文本被截断导致三元组凭空消失现象一段 200 字的文本模型对前半段抽出一个三元组后半段完全没反应单独把后半段拿来测又能抽出来。原因max_length128截断了后半段。解决按句子切分长文本是根治办法用[。]做切分点每句独立预测再汇总如果句子本身超过 128 字可以做一个滑窗窗口大小设为max_length // 2相邻窗口重叠一半最后对重叠区域的实体结果做去重合并。模型在窗口重叠处对同一实体的预测可能不一致保留置信度高或出现次数多的结果即可。这个现象在实战里最常见的出现场景是新闻标题很长且三元组在句子的最后半句很多人误以为是模型没学好其实是截断把答案丢了。5.5 验证集掉点却找不出原因训练集和验证集的标注风格不一致现象训练 loss 降到 0.05 以下验证 F1 却只有 0.4 甚至更低反复调学习率也没用。原因三元组数据的标注一致性本身容易出问题——同一关系在不同数据里被标成“收购”和“并购”同一个人名一个写“字节跳动”一个写“字节跳动有限公司”模型学到的是两套标签映射验证集上的表现自然被拉低。解决预处理阶段做实体标准化映射表把同义变体对照到同一标准名关系标签也要做一次合并检查。还有一个隐蔽情况训练集和验证集来自不同批次的人工标注标注规范表述有细微差别BIO 标签序列看起来一样但实体边界标注习惯不同有人把“字节跳动”整个标为实体有人只标“字节跳动”去掉后缀这种情况要把两个数据集的标签分布可视化对比看同一实体类型的平均长度差异再统一边界策略。这条属于“玄学掉点”里最容易被忽略的一种先查数据再调模型别上来就加 trick。6. 把模型部署成可用服务验证脚本与一个小习惯训练完成后你需要的不只是一个.pt文件而是一条“输入句子 → 输出三元组”的可验证链路。我会把第 4 章的解码函数封装成一个独立的predict()方法输入原始文本内部完成分词、token 化、Viterbi 解码和实体配对然后直接用这个函数在测试语料上跑一遍打印 5 条结果人工检查。这样做的价值在于模型是否真的可用肉眼扫一眼就知道不用等完整测试集指标算出来。部署时的常见做法是导出state_dict后在服务端重新实例化模型再加载权重而不是直接torch.save(model)整个对象后者遇到代码版本变动会加载失败。加载成功后再用一段ONNX导出或者TorchScript固化推理图能让显存占用降低 30% 左右服务端并发也安全得多。不过 ONNX 对 CRF 层的支持依赖具体算子版本先跑通预测函数再考虑加速不迟。我自己的一个习惯是每版模型训练完都挑 50 条“金句集”——覆盖所有关系类型且包含至少一个易混淆样本——每次迭代后在金句集上跑一遍predict()把输出 diff 出来看。这比看精确率召回率数值更能快速感知模型行为变化也是我判断回归是否可靠的第一道闸。最后说句实在话三元组识别项目里模型训练只占三成力气剩下的是数据清洗、边界规则和部署细节。希望这篇拆包笔记能帮你少走一段弯路。本文还有配套的精品资源点击获取