简介基于PyTorch和CNN的关系抽取完整工程包面向NLP学习者和算法工程师以SemEval2010_task8为实验数据解决实体关系分类问题。工程涵盖数据预处理、词汇表构建、模型定义、训练评估和词嵌入加载等完整环节代码按data、embeddings、model、tools等目录清晰拆分包含原始语料、GloVe/Word2Vec向量处理脚本、net.py网络结构、train.py训练入口、evaluate.py评测模块及BiLSTM_CNN、BiLSTM_ATT结构示意图便于对照学习与二次开发。包内共43个文件以py源码、txt文本、pyc缓存为主辅以xml工程配置、json参数、jpeg可视化图、log训练记录和tar数据包整体大小36.95MB。当前已有741人学习下载适合希望从零搭建关系抽取模型、理解CNN在NLP中的局部特征提取能力或在此基础上扩展注意力机制、调整网络结构的开发者。1. CNN 关系抽取模型这份资源PyTorch 实现的基础关系抽取工程关系抽取是信息抽取里的老任务给定一句话和句中两个实体判断两者之间的关系。这份「CNN关系抽取模型.zip」是一套基于 PyTorch 的 CNN 关系抽取完整工程数据解析、模型定义、训练评估全链路都在这一个包里配套数据采用 SemEval-2010 格式的公开关系抽取数据集标签体系为 19 类——18 个有方向性的关系类外加 other 类。它的定位很清楚让没用 CNN 做过关系抽取的人也能在本地把模型跑起来稳定拿到 80 上下的宏平均 F1 基线已经跑过类似模型的熟手也可以直接拿里面的解析脚本和评估逻辑当底座去改自己的实验。这套东西最适合正在搭信息抽取、知识图谱或文本挖掘基线系统的从业者和研究生。2. 关系抽取与 CNN 选型为什么卷积结构能看出实体对关系2.1 输入和输出到底是什么句子、实体标注与 19 类标签关系抽取任务的标准输入是三样东西一句原文、实体 1 在句中的位置、实体 2 在句中的位置。输出则是一个关系类别标签。以 SemEval-2010 格式的数据为例一条样本长这样The e1company/e1 hired e2an engineer/e2 to lead the project.这里的 和 标记出了两个实体的边界。标签体系里关系被分成 9 个大类每个大类由于实体的先后顺序不同又分成两个方向比如 Cause-Effect 大类下面有Cause-Effect(e1,e2)和Cause-Effect(e2,e1)两种。再加上一个表示无关系的 other 类总共就是 19 类。9 个大类分别是Cause-Effect、Instrument-Agency、Product-Producer、Content-Container、Entity-Origin、Entity-Destination、Component-Whole、Member-Collection、Communication-Topic。所以从建模角度看这不是一个普通的 19 分类问题而是一个对实体方向高度敏感的分类问题。两个实体谁在前谁在后直接影响标签。很多刚上手的人在这里就翻车了我会在第 5 章详细展开。如果你要把这套模型用到自己的业务数据上最关键的一步不是调模型而是先想清楚你的标签体系里有没有方向性如果有就必须像原始数据集一样保留 e1/e2 顺序如果没有就得把 19 类合并成 10 类再训练。2.2 位置编码、多窗口卷积与 max-poolingCNN 的三个关键机制CNN 做句子级关系抽取核心不是看它把文本当图像处理而是靠三个机制的配合。第一个机制是位置编码Position Feature常见缩写 PF。卷积核在句子上滑动时本身是感知不到实体位置的而关系判断极度依赖实体位置——比如判断 the company hired an engineer 是雇佣关系需要知道 company 在 e1 位置、engineer 在 e2 位置。常见的做法是计算每个 token 到两个实体的相对距离然后把两个距离值拼进 token 的向量里。距离通常取绝对值后做截断比如只保留 [-30, 30] 的范围超出部分归到边界值。第二个机制是多窗口卷积。CNN 里的卷积核可以理解为一个 n-gram 扫描器窗口大小为 2 的卷积核抓二元词组特征窗口大小为 3 的抓三元词组特征窗口大小为 4 的抓四元局部搭配。关系抽取里 is caused by 这种跨词组合就是靠稍大一点的窗口抓到的。用多个不同大小的卷积核并行扫描相当于同时用多个粒度的 n-gram 特征来做判断。第三个机制是 max-pooling。卷积输出的向量长度随句子长度变化而全连接层需要定长输入。max-pooling 在每个特征通道上取最大值把长度不一的卷积结果压成定长向量同时保留每个特征在整个句子上最强烈的响应位置。这也解释了为什么 CNN 不像 RNN 那样需要严格按时间步处理——它天然不在乎词序的绝对位置只在乎局部组合是否出现。这个特性在关系抽取里反而成了优点句子的主干信息通常集中在实体周围的局部上下文里长距离依赖靠 pooling 从整句里挑最值得保留的特征。对比之下LSTM 能建模序列依赖但训练速度慢长句上还有梯度衰减的问题Transformer 效果好但需要预训练权重、显存开销大。用 CNN 做基线参数量小、训练快、可解释性还好——你可以直接把某个卷积核扫描出的特征图拉出来看。这份资源选 CNN本质上就是给「先跑通、再迭代」的工作流准备的。2.3 拿到 zip 先干三件事目录检查、依赖确认、脚本跑通解压之后不要急着开 train.py。我一般会先花五分钟把目录过一遍确认文件组织和依赖情况然后把数据解析脚本单独跑一遍确认原始数据格式和解析结果没脱节。一份典型的工程结构如下CNN关系抽取模型/ ├── data/ │ ├── train.xml │ ├── test.xml │ └── relations.json ├── src/ │ ├── parse_data.py │ ├── dataset.py │ ├── model.py │ ├── train.py │ └── evaluate.py ├── requirements.txt └── README.mdcd CNN关系抽取模型 python -m pip install -r requirements.txt python src/parse_data.py --input data/train.xml --output data/train.tsv第一行命令安装依赖requirements.txt 里一般就是 torch、numpy、scikit-learn 这几个基础库。第二行把 XML 解析成 TSV每行一条样本列分别是句子文本、实体 1 起始位置、实体 1 结束位置、实体 2 起始位置、实体 2 结束位置、关系标签。这一步跑通了说明你的环境没问题原始数据格式和解析脚本是对得上的。如果解析脚本报错先看是不是数据路径写死的问题——很多源码包里的路径都是作者本机的绝对路径需要改成相对路径。这个检查顺序能帮你把环境问题、数据问题、代码问题分层隔离开而不是一上来就训练然后对着一个莫名其妙的报错发呆。3. 把 XML 原始数据变成可训练的样本数据解析与预处理3.1 从 XML 里解析句子与实体标注SemEval-2010 格式的原始数据是 XML每条样本的结构大致是句子文本里嵌着 和 标记。用 Python 自带的 xml.etree.ElementTree 就能解析不需要额外装库。下面是一段常见做法的解析脚本核心逻辑import xml.etree.ElementTree as ET def parse_xml(file_path): tree ET.parse(file_path) root tree.getroot() samples [] for sentence_elem in root.iter(sentence): # 拿到包含实体标记的原始文本 raw_text sentence_elem.find(text).text # 直接通过标记切分出实体文本和实体位置 e1_start raw_text.find(e1) e1_end raw_text.find(/e1) - len(e1) e2_start raw_text.find(e2) e2_end raw_text.find(/e2) - len(e2) # 去掉标记得到纯文本 text (raw_text[:e1_start] raw_text[e1_start 4:e1_end 4] raw_text[e1_end 9:]) # 这里的 4 是 e1 的长度需要根据实际情况调整 label sentence_elem.find(pair).get(relation) samples.append({ text: text, e1_start: e1_start, e1_end: e1_end, e2_start: e2_start, e2_end: e2_end, label: label, }) return samples这段代码的逻辑是先在原文本里找到 和 的位置然后通过字符串偏移量计算出实体的起止坐标。需要特别留意的是 e1_end 的计算find 返回的是 四个字符的起始下标所以实体真正的结束位置要减去这四个字符的长度。我见过不少人在这里把结束位置多算几个字符导致后面实体边界不对模型怎么训都训不好。数据解析的坑往往不在 XML 结构本身而在这些偏移量的边界计算上。标签部分从 pair 节点的 relation 属性里取取出来是一个字符串比如Cause-Effect(e1,e2)。训练前需要把它映射成整数 ID映射表可以自己维护一个字典也可以直接写成 json 存到 relations.json 里这样训练和评估用同一套映射不会出现标签错位。3.2 实体替换与位置特征生成让模型知道实体在哪直接拿纯文本和实体坐标作为模型输入CNN 是感知不到实体在哪里的。业界通用的处理方式有两种一是把原句里的实体替换成[E1]和[E2]占位符让模型通过特殊 token 感知实体位置二是给每个 token 拼接一个位置向量向量的值是当前 token 到实体的相对距离。这份资源里两种策略都用上了具体代码如下def build_instance(text, e1_span, e2_span, vocab): # 用占位符替换原句中的实体文本 text_replaced ( text[:e1_span[0]] [E1] text[e1_span[1]:e2_span[0]] [E2] text[e2_span[1]:] ) tokens text_replaced.split() # 计算每个 token 到 e1 和 e2 的相对距离 e1_pos tokens.index([E1]) e2_pos tokens.index([E2]) pos_1, pos_2 [], [] for i in range(len(tokens)): dist_1 i - e1_pos dist_2 i - e2_pos # 距离做截断超出 [-30, 30] 的部分取边界值 pos_1.append(max(-30, min(30, dist_1)) 30) pos_2.append(max(-30, min(30, dist_2)) 30) token_ids [vocab.get(t, vocab[UNK]) for t in tokens] return { token_ids: token_ids, pos_1: pos_1, pos_2: pos_2, label: label_to_id[label], }这段代码做了三件事实体替换、相对距离计算、距离离散化。距离之所以要截断是因为离实体特别远的 token 对关系判断几乎没贡献保留较大的绝对值只会让 embedding 空间被稀疏值占满。这里把距离从 [-30, 30] 映射到 [0, 60]是为了方便直接用 nn.Embedding 查表不需要处理负数下标。vocab 字典在训练前需要单独构建常见做法是统计训练集里所有 token 的频率保留出现次数大于等于 2 的剩下的归入UNK。实体替换这步有个细节要注意替换后的句子要重新做分词如果原始文本里有标点与实体紧邻的情况split 之后 token 序列和位置编码的对应关系可能会错位排查时可以先打印一两条实例对照看。3.3 Dataset 与 DataLoaderpadding、batch 与 mask 的组织数据预处理到 token_ids 这一步之后还需要封装成 PyTorch 的 Dataset 和 DataLoader因为训练过程中要按 batch 取数据。由于句子的长度不统一同一个 batch 里的样本需要 padding 到一样长同时要记录每条样本的真实长度方便后面做 mask。Dataset 的常见写法如下import torch from torch.utils.data import Dataset class RelationDataset(Dataset): def __init__(self, samples, max_len128): self.samples samples self.max_len max_len def __len__(self): return len(self.samples) def __getitem__(self, idx): item self.samples[idx] seq_len min(len(item[token_ids]), self.max_len) # 长度不够 max_len 的用 0 补齐超过的截断 token_ids item[token_ids][:self.max_len] [0] * (self.max_len - seq_len) pos_1 item[pos_1][:self.max_len] [0] * (self.max_len - seq_len) pos_2 item[pos_2][:self.max_len] [0] * (self.max_len - seq_len) return { token_ids: torch.tensor(token_ids, dtypetorch.long), pos_1: torch.tensor(pos_1, dtypetorch.long), pos_2: torch.tensor(pos_2, dtypetorch.long), label: torch.tensor(item[label], dtypetorch.long), mask: torch.tensor([1] * seq_len [0] * (self.max_len - seq_len), dtypetorch.long), }这里把 max_len 默认设成 128实际使用时要先看一眼训练集句长的分布。SemEval-2010 格式的句子普遍不长128 基本够用如果是金融、法律或生物医学领域的句子动辄两三百 tokenmax_len 就要调大或者在预处理时就做句长过滤。padding 值选 0 是约定俗成的做法但必须保证后面的 Embedding 层把 padding_idx 也设为 0否则 padding 位置照样会参与训练和梯度计算。DataLoader 侧batch size 一般取 32 或 64显存有限就取 32。注意 DataLoader 默认会自己按 batch 取样本你不需要手动实现 collate_fn除非你的输入不是定长张量。4. 模型定义与训练流程从零实现一个可运行的 CNN4.1 Embedding 层随机初始化和预训练向量的取舍模型第一层是 embedding。常见做法是用 nn.Embedding 为每个 token 构造一个可训练向量同时把 padding_idx 固定为 0。具体实现如下embed_dim 300 self.token_embed nn.Embedding(vocab_size, embed_dim, padding_idx0) self.pos1_embed nn.Embedding(61, 30) # 距离范围 [0, 60] self.pos2_embed nn.Embedding(61, 30)位置向量的维度一般取 30比词向量维度小一个量级。这样每个 token 进入卷积层前拼接后的向量长度是 300 30 30 360。如果你想用预训练词向量比如 Word2Vec 或 GloVe 的产物就要在建 vocab 之后把预训练矩阵加载进来用self.token_embed.weight.data.copy_(pretrained_tensor)覆盖随机初始化的权重。这里有一个取舍预训练向量能提升 1 到 3 个点的 F1尤其是训练数据量不大的时候但需要额外维护一个几十 MB 到几百 MB 的向量文件而且 OOV 词的处理逻辑也要跟着变。我的建议是先随机初始化跑通训练流程拿到一个基线再决定要不要上预训练向量。随机初始化不是最优但能让你最快排除代码层面的问题。4.2 多窗口卷积与池化的 PyTorch 实现模型主体是一个多窗口的 CNN。所谓多窗口就是同时用多个不同尺寸的卷积核扫过句子然后把各自的输出拼接起来。下面是 model.py 里的关键代码import torch.nn as nn class PositionAwareCNN(nn.Module): def __init__(self, vocab_size, embed_dim300, num_filters100, kernel_sizes[2, 3, 4], num_classes19, dropout0.5): super().__init__() self.token_embed nn.Embedding(vocab_size, embed_dim, padding_idx0) self.pos1_embed nn.Embedding(61, 30) self.pos2_embed nn.Embedding(61, 30) input_dim embed_dim 30 30 # 每个卷积核尺寸对应一个 Conv1d 层 self.convs nn.ModuleList([ nn.Conv1d(input_dim, num_filters, k, paddingk - 1) for k in kernel_sizes ]) self.dropout nn.Dropout(dropout) self.fc nn.Linear(num_filters * len(kernel_sizes), num_classes) self.relu nn.ReLU() def forward(self, token_ids, pos_1, pos_2): # 分别查表再在最后一维上拼接 token_vec self.token_embed(token_ids) # [B, L, 300] pos1_vec self.pos1_embed(pos_1) # [B, L, 30] pos2_vec self.pos2_embed(pos_2) # [B, L, 30] x torch.cat([token_vec, pos1_vec, pos2_vec], dim-1) # [B, L, 360] # Conv1d 要求输入维度为 [B, C, L]做一次转置 x x.transpose(1, 2) # [B, 360, L] conv_out [] for conv in self.convs: c self.relu(conv(x)) # [B, 100, L] # 在长度维度上取最大值得到定长输出 pooled c.max(dim2).values # [B, 100] conv_out.append(pooled) feature torch.cat(conv_out, dim1) # [B, 300] feature self.dropout(feature) logits self.fc(feature) # [B, 19] return logits几个参数值得展开说一下。num_filters 是每个卷积核的输出通道数取 100 属于中庸配置太小特征不够用太大显存开销和过拟合风险都会涨。padding 的处理方式是 paddingk-1这样卷积输出长度和输入长度保持一致池化就不会受到句子长度波动的影响。Conv1d 的输入要求是 [B, C, L]而 embedding 输出是 [B, L, C]所以 forward 里必须做 transpose 操作这个顺序搞反是新手最常见的报错点。max pooling 用的是c.max(dim2)而不是F.max_pool1d省去了对输出形状的额外 reshape。Dropout 放在全连接之前训练时生效评估时自动关闭这是 PyTorch 的默认行为不需要额外处理。4.3 训练主循环优化器、学习率调度与早停模型定义好之后训练主循环才是决定最终 F1 的关键。优化器选 AdamW学习率从 1e-3 起步配合一个简单的线性衰减或 cosine 调度。训练循环的代码骨架如下optimizer torch.optim.AdamW(model.parameters(), lr1e-3, weight_decay1e-4) scheduler torch.optim.lr_scheduler.CosineAnnealingLR( optimizer, T_max10, eta_min1e-5 ) criterion torch.nn.CrossEntropyLoss() for epoch in range(30): model.train() for batch in train_loader: token_ids batch[token_ids].to(device) pos_1 batch[pos_1].to(device) pos_2 batch[pos_2].to(device) labels batch[label].to(device) mask batch[mask].to(device) logits model(token_ids, pos_1, pos_2) # 用 mask 过滤掉 padding 位置的影响 loss criterion(logits[mask.bool()], labels) optimizer.zero_grad() loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() scheduler.step() val_f1 evaluate(model, val_loader) print(fepoch {epoch}, loss {loss.item():.4f}, val_f1 {val_f1:.4f})这里有几个参数是我多次实验后固定的weight_decay 取 1e-4防止 embedding 层过拟合梯度裁剪 max_norm 取 5.0避免个别样本产生大梯度把参数冲飞epoch 上限设 30配合 early stopping 策略——验证集 F1 连续 5 个 epoch 不涨就停止训练并恢复最优权重。学习率调度选了 cosine它是一种做法你也可以用 step 衰减但 cosine 衰减更平稳。下面是全套超参数的参考表实测在这个数据集上稳定有效超参数推荐值说明batch size64显存小就降到 32max_len128超过句长分布 P95 即可embedding dim300与经典词向量维度对齐位置向量维度30不需要跟着词向量走卷积核数量100每个尺寸各 100 个通道卷积核尺寸2, 3, 4覆盖二元到四元局部特征dropout0.5全连接层之前learning rate1e-3AdamW 的合理起点weight decay1e-4主要约束全连接层梯度裁剪5.0防止梯度爆炸epoch30配合早停连续 5 轮不涨即停训练完第一轮如果 loss 没有明显下降优先排查的不是超参数而是数据流——打印一个 batch 的输入形状和 label 分布确认 padding 没有把所有样本都变成 0 长度确认 19 个类别在训练集里都出现过。这类数据问题比模型问题隐蔽得多而且报错往往特别晚等你发现 F1 低得离谱时已经白训了几个小时。5. 避坑排查复现 CNN 关系抽取最容易翻车的五个点5.1 关系方向全部反了e1/e2 顺序校验不做就一定错现象训练时 loss 正常下降验证集 F1 却卡在 30 以下跟随机猜测差不多。查看预测结果时发现模型把Cause-Effect(e1,e2)全预测成了Cause-Effect(e2,e1)方向整体反了。原因XML 解析时实体顺序和标签里的 e1/e2 没对齐。原始数据里标签是人工标注的语义上是 e1 对 e2 的关系你的解析脚本如果把实体位置搞反了模型学到的就是一个反方向的关系映射等于标签全错。解决在数据解析脚本里加一个校验函数对每条样本把 text 里 和 的实际内容和标签里的实体文本做比对顺序不一致就打印出来。如果用的是实体替换策略还要确认替换后 [E1] 和 [E2] 的位置和标签方向一致。这类问题通常不是模型的问题是预处理的问题排查优先级应该排在调模型之前。5.2 padding 之后位置编码漂移同一个句子训练和预测结果对不上现象训练日志里 F1 很高单独拿一条句子做预测时结果忽好忽坏同一个句子放训练集里测和放测试集里测结果不一样。原因位置向量在 padding 后算错了。常见的错误做法是先把整个 batch 统一 pad 到 max_len再去计算每个 token 到实体的相对距离。这样一句长度 20 的句子padding 后变成了 128后面的 108 个 padding token 距离不是 0 而是 108位置分布完全变了。解决位置编码必须在 padding 之前算好。正确流程是解析原始文本时就把 pos_1 和 pos_2 算好然后才做 paddingpadding 位置的距离补 0 即可。我在第 3 章的 build_instance 函数里已经是这个顺序了你如果自己改过代码务必检查位置向量和 token_ids 是不是同一套长度体系。5.3 不固定随机种子F1 上下浮动 2 个点复现全靠运气现象同一个训练脚本连跑三次F1 分别是 78.9、80.3、81.1差距接近 3 个点无法判断调参是不是真的有效。原因PyTorch 的随机种子、Python 的 random 模块、NumPy 的随机数都不是默认固定的。embedding 初始化、dropout 的 mask、数据集的 shuffle 顺序全部是随机的任何一步变了结果就变了。解决训练脚本开头固定三个种子——torch.manual_seed(42)、random.seed(42)、numpy.random.seed(42)如果用了 GPU 还要加torch.cuda.manual_seed_all(42)。另外把 DataLoader 的 shuffle 参数保持为 True但用固定种子初始化后shuffle 顺序也是可复现的。从那以后我每次跑实验都强制在脚本头部固定种子不然连自己调参有没有效果都说不清纯属给玄学送时间。5.4 评估直接用准确率或平均 F1不过滤 other 类分数虚高自己骗自己现象训练时 F1 越高越慌因为验证集的 other 类占比高模型只要把所有样本都预测成 other 类整体 F1 也能到 60 多。原因官方评测协议里 F1 是 18 类关系类的宏平均other 类不参与计算。很多人图省事直接对所有 19 类做宏平均other 类占了便宜关系类别本身却没人管。解决严格按官方协议算评估指标过滤掉预测为 other 或者标签为 other 的样本只对 18 个关系类算类别级 precision、recall、F1再取平均。计算脚本里加一句话过滤pred ! other_id且label ! other_id。这一步做对了基线分数会立刻掉下来但那个数字才是可信的。5.5 训练 loss 降了验证 F1 不涨学习率和梯度裁剪背锅现象训练损失从 2.0 一路降到 0.5验证 F1 纹丝不动甚至还在下降。原因模型在训练集上过拟合了或者是学习率太大导致后期在最优解附近反复横跳。深度学习模型的训练 loss 下降不代表泛化能力提升尤其是 CNN 这类容量不小的模型训练集上很容易做到 100% 准确率但对未见过的句子没有判断力。解决先做两组对照实验——把 dropout 从 0.5 提 0.6把学习率降到 3e-4 附近看验证 F1 是否跟着涨。如果还是不涨检查是否有梯度爆炸在 optimizer.step() 之前调用clip_grad_norm_max_norm 取 5.0。之后再考虑换卷积核尺寸组合或者加一层全连接但前两个条件是大多数过拟合场景的通用解。6. 类别级分析与阈值调整把 80 的 F1 再往上抠一点6.1 按类别拆解验证集结果找到最弱的三个类整体 F1 只是一个平均数掩盖了大量类别间的差异。我一般会在评估脚本里输出一张按类别 F1 降序排列的表格重点看排在最后三名的类是什么。常见的结果是 Member-Collection 和 Communication-Topic 这类语义抽象、正样本少的关系类垫底而 Content-Container、Entity-Origin 这类有明确空间指向的关系类最高。如果垫底的是某个方向性关系比如 Component-Whole(e2,e1)往往不是模型能力问题而是训练集里这个方向的正样本数太少数据不均衡导致的。6.2 对弱类做置信度阈值微调CNN 的 softmax 输出是 19 维概率分布默认取最大值作为预测。对于样本稀疏的类别即使模型学到了部分特征置信度也普遍偏低。一个有效的做法是在验证集上按类别微调阈值对每个弱类单独设置一个最低置信度低于阈值就判为 other 类宁可少召回也别错杀。这类操作属于后处理对框架没要求padding 和模型推理逻辑都不用动。如果某个类你用了阈值调整还是没起色建议回到数据层面看看这个类是不是存在标注不一致而不是继续压模型。6.3 用一条新句子做端到端验证训练和评估都通过后最后一步是用一条训练集和测试集之外的句子走一遍完整链路确认你的模型不是只在固定数据分布上有效。随便写一句话例如 an error in the software caused the server to crash实体是 software 和 server正确的标签应该是 Cause-Effect(e1,e2)。把这个句子丢进训练好的模型里看输出概率分布顺便检查位置特征有没有对齐、实体替换有没有出错。这一步花不了两分钟但它能把预处理、模型、推理链路全部串起来验证一遍。从那以后我每次训练完都强制走一遍这条端到端 demo至少能保证交付出去的模型不是一个喂了固定格式数据才能跑的黑匣子。希望这次拆包记录能帮你在关系抽取的基线上少走一段弯路快速拿到可信的 F1 数字。本文还有配套的精品资源点击获取
