尧图网站建设 
简介本资源是一套基于Python的实体关系抽取系统源码面向从事自然语言处理、知识图谱构建的开发者与研究人员尤其适用于高端装备制造领域的知识图谱自动化构建场景。系统以BERT等预训练模型为核心实现从文本中提取结构化实体与关系信息并引入FGM对抗性训练与EMA参数平滑更新策略提升模型鲁棒性与稳定性。压缩包共22个文件约1.97MB包含8个Python脚本、12个JSON数据与配置、1个txt词表及1个md说明文档覆盖数据加载、数据集生成、模型定义、训练入口与预测等完整流程目录结构清晰便于按模块阅读与二次开发。目前已有208人学习下载适合具备一定深度学习基础、希望快速上手实体关系抽取实战的读者参考借鉴。1. 从一份 Python 实体关系抽取系统源码说起它到底能抽出什么很多人第一次拿到「基于 Python 的实体关系抽取系统」这类源码包第一反应是解压、找requirements.txt、pip install、python main.py然后发现跑不起来或者跑起来只输出一堆看不懂的 JSON。问题不在代码而在于没搞清楚这套系统到底在做什么。实体关系抽取Relation ExtractionRE解决的是给定一段文本先找出里面的实体人名、地名、机构、时间、数值等再判断两个实体之间是什么关系比如「张伟任职于某某科技」里「张伟」和「某某科技」之间是「任职于」关系。它和命名实体识别NER是上下游关系NER 只标实体RE 在实体基础上加关系标签。这套源码通常包含数据预处理、模型定义、训练、推理、评估几个模块适合三类人想入门 NLP 信息抽取的学生、需要从合同/新闻/工单里批量抽结构化字段的工程师、以及想拿现成代码改造成自己业务抽取器的人。它不解决「通用对话」也不解决「情感分析」只干一件事——把非结构化文本变成(头实体, 关系, 尾实体)三元组。下面按「先立住原理、再动手复现、最后讲坑」的顺序拆开讲。2. 实体关系抽取系统的技术选型为什么是 Python 这套架构2.1 关系抽取的两条主流路线Pipeline 与 Joint实体关系抽取在工程上分两大流派。Pipeline流水线做法是先跑 NER 模型抽实体再把实体两两配对送进关系分类模型判断每对实体属于哪种关系。优点是模块解耦NER 和 RE 可以分别换模型、分别调优调试时能清楚知道是实体抽错了还是关系判错了。缺点是误差累积NER 漏掉的实体RE 永远补不回来而且实体对数量是实体数的平方级长文本里配对爆炸。Joint联合做法是一个模型同时输出实体和关系共享编码器常见结构是「标注序列 关系矩阵」或者「Span 分类」。优点是避免误差传播推理一次出结果。缺点是训练数据标注要求高调参更玄学改一个损失权重可能整个模型崩掉。这套源码大概率走的是 Pipeline 路线因为它的模块划分清晰、依赖少、容易在单机上跑通。判断方法很简单看代码里有没有独立的ner和relation两个模型文件或者pipeline.py里是不是先调 NER 再调 RE。如果是那就是 Pipeline。2.2 编码器选型BERT 还是 BiLSTMCRF关系抽取的编码器决定上限。常见组合有三种方案编码器适用场景显存需求标注量要求经典方案BiLSTM CRF小数据、快速验证低2G 可跑几千条主流方案BERT 分类头通用领域、效果优先中6G 起上万条轻量方案TextCNN / FastText短文本、高吞吐极低几千条源码里如果出现transformers、BertModel、AutoTokenizer说明走的是 BERT 路线如果只有torch.nn.LSTM和CRF那是经典方案。BERT 路线的关键参数是max_length一般 128 或 256、batch_size8 或 16、learning_rate2e-5 到 5e-5。BiLSTM 路线的关键是hidden_dim128 或 256、dropout0.3 到 0.5、lr1e-3。选型理由很直接如果你的业务文本是新闻、合同、报告这类规范书面语且标注数据能到上万条直接上 BERT如果是工单、聊天记录这类短文本且标注少BiLSTMCRF 反而更稳不容易过拟合。我一般会先用 BiLSTM 跑通全流程确认数据格式和评估指标没问题再换 BERT 冲效果。2.3 数据格式从原始标注到模型输入关系抽取的数据格式是第一个卡点。常见标注格式有两种一种是 JSONL每行一个样本包含text、entities带起止位置和类型、relations头尾实体索引和关系类型另一种是 BIO 序列标注 关系表。源码里通常有个data/目录里面是train.json、dev.json、test.json。一个典型的 JSONL 样本长这样{text: 张伟于2019年加入北京某某科技有限公司, entities: [{id: 0, start: 0, end: 2, type: PER, text: 张伟}, {id: 1, start: 3, end: 7, type: TIME, text: 2019年}, {id: 2, start: 9, end: 17, type: ORG, text: 北京某某科技有限公司}], relations: [{head: 0, tail: 2, type: 任职于}, {head: 0, tail: 1, type: 加入时间}]}注意start和end是字符级索引end通常是不包含的左闭右开。很多源码在这里翻车因为标注工具导出的索引有的是闭区间有的是 token 级直接喂给模型会错位。处理办法是写一个校验脚本遍历所有样本检查text[start:end]是否等于entity[text]不等就报错。import json def validate_span(file_path): with open(file_path, r, encodingutf-8) as f: for line_no, line in enumerate(f, 1): sample json.loads(line) text sample[text] for ent in sample[entities]: span text[ent[start]:ent[end]] if span ! ent[text]: print(f第{line_no}行实体错位: 期望{ent[text]}, 实际{span}) return False return True # 参数说明file_path 指向 train.json / dev.json # 逻辑逐行解析用字符切片还原实体文本和标注文本比对 # 失败时优先检查标注工具是否用了 token 索引或闭区间这个校验脚本我每次拿到新数据都会先跑一遍能省掉后面几小时的「模型不收敛」排查。3. 把源码跑起来环境、训练、推理的最小闭环3.1 环境搭建与依赖安装的四个关键点拿到源码后不要急着pip install -r requirements.txt先看三样东西Python 版本、PyTorch 版本、有没有transformers。Python 建议 3.8 或 3.9太新的 3.12 有些老包编译不过。PyTorch 版本要和 CUDA 匹配如果源码里写的是torch1.8.0而你机器是 40 系显卡可能得升到 2.x但升完要注意torch.nn.CRF这类第三方包的兼容性。安装顺序建议# 1. 建虚拟环境避免污染全局 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 2. 先装 PyTorch按官网命令选对应 CUDA 版本 pip install torch2.0.1 torchvision --index-url https://download.pytorch.org/whl/cu118 # 3. 再装其余依赖 pip install -r requirements.txt # 4. 单独确认关键包版本 python -c import torch, transformers; print(torch.__version__, transformers.__version__)参数说明cu118对应 CUDA 11.8如果你只有 CPU把 index-url 换成 CPU 版本。requirements.txt里如果有pytorch-crf、seqeval、fastapi说明源码带评估和服务接口。装完先跑python -c import torch; print(torch.cuda.is_available())返回 False 就是没吃到 GPU后面训练会慢十倍。3.2 训练脚本的参数怎么改batch_size、lr、max_length训练入口一般是train.py或run_train.py。打开先找argparse部分重点看这几个参数parser.add_argument(--batch_size, typeint, default16) parser.add_argument(--learning_rate, typefloat, default3e-5) parser.add_argument(--max_length, typeint, default128) parser.add_argument(--epochs, typeint, default10) parser.add_argument(--data_dir, typestr, default./data) parser.add_argument(--save_dir, typestr, default./checkpoints)改法有讲究。batch_size先看显存8G 显存跑 BERT-base 一般能到 16跑不动就降到 8同时把learning_rate从 3e-5 降到 2e-5因为小 batch 梯度噪声大学习率太高会震荡。max_length要覆盖你数据里 95% 的文本长度短了截断丢关系长了浪费显存。统计方法import json lengths [] with open(data/train.json, r, encodingutf-8) as f: for line in f: lengths.append(len(json.loads(line)[text])) lengths.sort() print(f95分位长度: {lengths[int(len(lengths)*0.95)]}) # 参数说明输出值向上取整到 8 的倍数作为 max_length # 逻辑避免拍脑袋设 512 导致显存爆掉epochs不要设太大BERT 微调一般 3 到 5 轮就收敛10 轮大概率过拟合。判断过拟合看验证集 F1如果训练 loss 一直降但验证 F1 掉头向下就是过拟合提前停。3.3 推理与结果解析从模型输出到三元组推理脚本一般是predict.py或inference.py输入一段文本输出三元组。核心逻辑是先 NER 抽实体再对实体对做关系分类最后过滤掉「无关系」的配对。def extract_triples(text, ner_model, re_model, tokenizer, id2rel, threshold0.5): # 1. NER 抽实体 entities ner_model.predict(text) triples [] # 2. 实体两两配对 for i in range(len(entities)): for j in range(len(entities)): if i j: continue head, tail entities[i], entities[j] # 3. 构造关系分类输入 inputs tokenizer(text, head[text], tail[text], return_tensorspt, truncationTrue, max_length256) with torch.no_grad(): logits re_model(**inputs).logits prob torch.softmax(logits, dim-1) rel_id torch.argmax(prob, dim-1).item() # 4. 过滤无关系和低置信 if id2rel[rel_id] ! 无关系 and prob[0][rel_id] threshold: triples.append((head[text], id2rel[rel_id], tail[text])) return triples # 参数说明threshold 控制召回与精度平衡0.5 是起点 # 逻辑先抽实体再配对避免漏掉嵌套实体 # 失败时看 NER 是否漏实体或关系分类是否把「无关系」判成具体关系threshold这个参数很关键。调低到 0.3召回高但误报多调到 0.7精度高但漏抽。业务上如果下游有人工复核可以调低如果直接入库调高。我一般会在验证集上画一条 P-R 曲线选 F1 最高的点作为阈值。4. 避坑与排查实体关系抽取系统最常见的 5 个翻车点4.1 实体索引错位导致模型学不到关系现象训练 loss 正常下降但验证集 F1 一直在 0.1 左右模型好像只学会了预测「无关系」。原因标注数据里实体start/end是 token 级索引而代码按字符级切片导致实体文本全是乱码或空串。解决跑 2.3 节的校验脚本把所有错位样本找出来用text.find(entity_text)重新计算字符索引或者统一改成 token 级处理。这个坑我踩过两次血泪经验是拿到数据先校验别信标注工具。4.2 max_length 截断把关键关系截没了现象短文本抽得准长文本超过 200 字关系全丢。原因max_length设成 128长文本后半段的实体和关系被截断模型根本看不到。解决统计训练集长度分布把max_length设到 95 分位以上如果显存不够用滑动窗口切分文本每段保留重叠区域推理时合并结果。注意重叠区要够大至少覆盖一个完整句子否则关系会被切断。4.3 关系类别不平衡导致「无关系」一家独大现象模型把所有实体对都预测成「无关系」准确率看着很高因为负样本占 90%但召回率接近 0。原因实体对里绝大多数是无关的正负样本比例可能到 1:20。解决训练时对正样本加权或者用 focal loss也可以在构造负样本时做下采样让正负比控制在 1:3 左右。评估时不要只看 accuracy要看正类别的 F1。4.4 中文分词和 BERT tokenizer 不一致现象NER 抽出的实体边界和预期差一两个字比如「北京某某科技」抽成「京某某科技」。原因BERT 中文 tokenizer 是按字切分但后处理时用了 jieba 分词的结果去对齐两套边界对不上。解决统一用 tokenizer 的offset_mapping还原字符位置不要混用分词工具。如果必须用 jieba就在 jieba 分词结果上重新训练 NER保持训练和推理一致。4.5 保存的模型加载时报 key 不匹配现象训练完保存state_dict推理时load_state_dict报Missing key(s)或Unexpected key(s)。原因训练时用了DataParallel或多卡保存的 key 带module.前缀单卡加载对不上。解决保存时用model.module.state_dict()或者加载时用{k.replace(module., ): v for k, v in state_dict.items()}去掉前缀。这个坑在多卡训练转单卡推理时必现记住就行。5. 进阶技巧用规则兜底和主动学习把 F1 再拉 5 个点模型跑通只是起点真正上线还要解决「长尾关系抽不准」和「标注数据不够」两个问题。我一般会加两层规则兜底和主动学习。规则兜底针对高频、模式固定的关系。比如「任职于」「成立于」「位于」这类用正则或关键词模板直接抽置信度给满模型只负责抽规则覆盖不到的。做法是写一个rule_extractor.py和模型输出做融合import re RULES [ (re.compile(r(.{2,4})于(\d{4})年加入(.{2,20})), (任职于, 加入时间)), (re.compile(r(.{2,20})成立于(\d{4})年), (成立时间,)), ] def rule_extract(text): triples [] for pattern, rel_types in RULES: for match in pattern.finditer(text): groups match.groups() if len(groups) 2: triples.append((groups[0], rel_types[0], groups[-1])) return triples # 参数说明RULES 里每条规则对应一种关系模式 # 逻辑正则命中直接产出三元组不经过模型 # 注意规则要定期 review避免过拟合到某批数据融合策略是规则命中的三元组直接采纳模型输出的三元组如果和规则冲突以规则为准规则没覆盖的用模型结果。这样在固定模式的关系上F1 能直接拉到 0.95 以上。主动学习解决标注不够。流程是先用现有模型跑一遍未标注数据挑出模型置信度在 0.4 到 0.6 之间的样本模型最不确定的人工标注这批再混进训练集重训。每轮标注量不用大500 到 1000 条就够跑三轮通常能把 F1 从 0.7 拉到 0.8 以上。关键是选样策略不要随机选要选「模型分歧大」的信息量最高。验证方法上除了看整体 F1一定要分关系类型看。我习惯用seqeval或sklearn的classification_report输出每个关系类别的 P/R/F1找出最差的两三类针对性补数据或加规则。整体 F1 涨了但某个类别掉了说明模型在牺牲长尾换头部这种「假提升」上线后会翻车。最后说个习惯每次改完参数或数据先跑一个小规模实验比如 1000 条训练样本2 个 epoch确认流程通、指标动再上全量。全量跑一次几小时小实验几分钟能省下大量等待时间。这套源码的价值不在于它本身多完美而在于它给了你一个可改、可调、可验证的起点剩下的就是顺着数据把每个环节抠细。希望帮到你。本文还有配套的精品资源点击获取 Python实体关系抽取系统实战：从源码解析到F1提升的避坑指南
简介本资源是一套基于Python的实体关系抽取系统源码面向从事自然语言处理、知识图谱构建的开发者与研究人员尤其适用于高端装备制造领域的知识图谱自动化构建场景。系统以BERT等预训练模型为核心实现从文本中提取结构化实体与关系信息并引入FGM对抗性训练与EMA参数平滑更新策略提升模型鲁棒性与稳定性。压缩包共22个文件约1.97MB包含8个Python脚本、12个JSON数据与配置、1个txt词表及1个md说明文档覆盖数据加载、数据集生成、模型定义、训练入口与预测等完整流程目录结构清晰便于按模块阅读与二次开发。目前已有208人学习下载适合具备一定深度学习基础、希望快速上手实体关系抽取实战的读者参考借鉴。1. 从一份 Python 实体关系抽取系统源码说起它到底能抽出什么很多人第一次拿到「基于 Python 的实体关系抽取系统」这类源码包第一反应是解压、找requirements.txt、pip install、python main.py然后发现跑不起来或者跑起来只输出一堆看不懂的 JSON。问题不在代码而在于没搞清楚这套系统到底在做什么。实体关系抽取Relation ExtractionRE解决的是给定一段文本先找出里面的实体人名、地名、机构、时间、数值等再判断两个实体之间是什么关系比如「张伟任职于某某科技」里「张伟」和「某某科技」之间是「任职于」关系。它和命名实体识别NER是上下游关系NER 只标实体RE 在实体基础上加关系标签。这套源码通常包含数据预处理、模型定义、训练、推理、评估几个模块适合三类人想入门 NLP 信息抽取的学生、需要从合同/新闻/工单里批量抽结构化字段的工程师、以及想拿现成代码改造成自己业务抽取器的人。它不解决「通用对话」也不解决「情感分析」只干一件事——把非结构化文本变成(头实体, 关系, 尾实体)三元组。下面按「先立住原理、再动手复现、最后讲坑」的顺序拆开讲。2. 实体关系抽取系统的技术选型为什么是 Python 这套架构2.1 关系抽取的两条主流路线Pipeline 与 Joint实体关系抽取在工程上分两大流派。Pipeline流水线做法是先跑 NER 模型抽实体再把实体两两配对送进关系分类模型判断每对实体属于哪种关系。优点是模块解耦NER 和 RE 可以分别换模型、分别调优调试时能清楚知道是实体抽错了还是关系判错了。缺点是误差累积NER 漏掉的实体RE 永远补不回来而且实体对数量是实体数的平方级长文本里配对爆炸。Joint联合做法是一个模型同时输出实体和关系共享编码器常见结构是「标注序列 关系矩阵」或者「Span 分类」。优点是避免误差传播推理一次出结果。缺点是训练数据标注要求高调参更玄学改一个损失权重可能整个模型崩掉。这套源码大概率走的是 Pipeline 路线因为它的模块划分清晰、依赖少、容易在单机上跑通。判断方法很简单看代码里有没有独立的ner和relation两个模型文件或者pipeline.py里是不是先调 NER 再调 RE。如果是那就是 Pipeline。2.2 编码器选型BERT 还是 BiLSTMCRF关系抽取的编码器决定上限。常见组合有三种方案编码器适用场景显存需求标注量要求经典方案BiLSTM CRF小数据、快速验证低2G 可跑几千条主流方案BERT 分类头通用领域、效果优先中6G 起上万条轻量方案TextCNN / FastText短文本、高吞吐极低几千条源码里如果出现transformers、BertModel、AutoTokenizer说明走的是 BERT 路线如果只有torch.nn.LSTM和CRF那是经典方案。BERT 路线的关键参数是max_length一般 128 或 256、batch_size8 或 16、learning_rate2e-5 到 5e-5。BiLSTM 路线的关键是hidden_dim128 或 256、dropout0.3 到 0.5、lr1e-3。选型理由很直接如果你的业务文本是新闻、合同、报告这类规范书面语且标注数据能到上万条直接上 BERT如果是工单、聊天记录这类短文本且标注少BiLSTMCRF 反而更稳不容易过拟合。我一般会先用 BiLSTM 跑通全流程确认数据格式和评估指标没问题再换 BERT 冲效果。2.3 数据格式从原始标注到模型输入关系抽取的数据格式是第一个卡点。常见标注格式有两种一种是 JSONL每行一个样本包含text、entities带起止位置和类型、relations头尾实体索引和关系类型另一种是 BIO 序列标注 关系表。源码里通常有个data/目录里面是train.json、dev.json、test.json。一个典型的 JSONL 样本长这样{text: 张伟于2019年加入北京某某科技有限公司, entities: [{id: 0, start: 0, end: 2, type: PER, text: 张伟}, {id: 1, start: 3, end: 7, type: TIME, text: 2019年}, {id: 2, start: 9, end: 17, type: ORG, text: 北京某某科技有限公司}], relations: [{head: 0, tail: 2, type: 任职于}, {head: 0, tail: 1, type: 加入时间}]}注意start和end是字符级索引end通常是不包含的左闭右开。很多源码在这里翻车因为标注工具导出的索引有的是闭区间有的是 token 级直接喂给模型会错位。处理办法是写一个校验脚本遍历所有样本检查text[start:end]是否等于entity[text]不等就报错。import json def validate_span(file_path): with open(file_path, r, encodingutf-8) as f: for line_no, line in enumerate(f, 1): sample json.loads(line) text sample[text] for ent in sample[entities]: span text[ent[start]:ent[end]] if span ! ent[text]: print(f第{line_no}行实体错位: 期望{ent[text]}, 实际{span}) return False return True # 参数说明file_path 指向 train.json / dev.json # 逻辑逐行解析用字符切片还原实体文本和标注文本比对 # 失败时优先检查标注工具是否用了 token 索引或闭区间这个校验脚本我每次拿到新数据都会先跑一遍能省掉后面几小时的「模型不收敛」排查。3. 把源码跑起来环境、训练、推理的最小闭环3.1 环境搭建与依赖安装的四个关键点拿到源码后不要急着pip install -r requirements.txt先看三样东西Python 版本、PyTorch 版本、有没有transformers。Python 建议 3.8 或 3.9太新的 3.12 有些老包编译不过。PyTorch 版本要和 CUDA 匹配如果源码里写的是torch1.8.0而你机器是 40 系显卡可能得升到 2.x但升完要注意torch.nn.CRF这类第三方包的兼容性。安装顺序建议# 1. 建虚拟环境避免污染全局 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 2. 先装 PyTorch按官网命令选对应 CUDA 版本 pip install torch2.0.1 torchvision --index-url https://download.pytorch.org/whl/cu118 # 3. 再装其余依赖 pip install -r requirements.txt # 4. 单独确认关键包版本 python -c import torch, transformers; print(torch.__version__, transformers.__version__)参数说明cu118对应 CUDA 11.8如果你只有 CPU把 index-url 换成 CPU 版本。requirements.txt里如果有pytorch-crf、seqeval、fastapi说明源码带评估和服务接口。装完先跑python -c import torch; print(torch.cuda.is_available())返回 False 就是没吃到 GPU后面训练会慢十倍。3.2 训练脚本的参数怎么改batch_size、lr、max_length训练入口一般是train.py或run_train.py。打开先找argparse部分重点看这几个参数parser.add_argument(--batch_size, typeint, default16) parser.add_argument(--learning_rate, typefloat, default3e-5) parser.add_argument(--max_length, typeint, default128) parser.add_argument(--epochs, typeint, default10) parser.add_argument(--data_dir, typestr, default./data) parser.add_argument(--save_dir, typestr, default./checkpoints)改法有讲究。batch_size先看显存8G 显存跑 BERT-base 一般能到 16跑不动就降到 8同时把learning_rate从 3e-5 降到 2e-5因为小 batch 梯度噪声大学习率太高会震荡。max_length要覆盖你数据里 95% 的文本长度短了截断丢关系长了浪费显存。统计方法import json lengths [] with open(data/train.json, r, encodingutf-8) as f: for line in f: lengths.append(len(json.loads(line)[text])) lengths.sort() print(f95分位长度: {lengths[int(len(lengths)*0.95)]}) # 参数说明输出值向上取整到 8 的倍数作为 max_length # 逻辑避免拍脑袋设 512 导致显存爆掉epochs不要设太大BERT 微调一般 3 到 5 轮就收敛10 轮大概率过拟合。判断过拟合看验证集 F1如果训练 loss 一直降但验证 F1 掉头向下就是过拟合提前停。3.3 推理与结果解析从模型输出到三元组推理脚本一般是predict.py或inference.py输入一段文本输出三元组。核心逻辑是先 NER 抽实体再对实体对做关系分类最后过滤掉「无关系」的配对。def extract_triples(text, ner_model, re_model, tokenizer, id2rel, threshold0.5): # 1. NER 抽实体 entities ner_model.predict(text) triples [] # 2. 实体两两配对 for i in range(len(entities)): for j in range(len(entities)): if i j: continue head, tail entities[i], entities[j] # 3. 构造关系分类输入 inputs tokenizer(text, head[text], tail[text], return_tensorspt, truncationTrue, max_length256) with torch.no_grad(): logits re_model(**inputs).logits prob torch.softmax(logits, dim-1) rel_id torch.argmax(prob, dim-1).item() # 4. 过滤无关系和低置信 if id2rel[rel_id] ! 无关系 and prob[0][rel_id] threshold: triples.append((head[text], id2rel[rel_id], tail[text])) return triples # 参数说明threshold 控制召回与精度平衡0.5 是起点 # 逻辑先抽实体再配对避免漏掉嵌套实体 # 失败时看 NER 是否漏实体或关系分类是否把「无关系」判成具体关系threshold这个参数很关键。调低到 0.3召回高但误报多调到 0.7精度高但漏抽。业务上如果下游有人工复核可以调低如果直接入库调高。我一般会在验证集上画一条 P-R 曲线选 F1 最高的点作为阈值。4. 避坑与排查实体关系抽取系统最常见的 5 个翻车点4.1 实体索引错位导致模型学不到关系现象训练 loss 正常下降但验证集 F1 一直在 0.1 左右模型好像只学会了预测「无关系」。原因标注数据里实体start/end是 token 级索引而代码按字符级切片导致实体文本全是乱码或空串。解决跑 2.3 节的校验脚本把所有错位样本找出来用text.find(entity_text)重新计算字符索引或者统一改成 token 级处理。这个坑我踩过两次血泪经验是拿到数据先校验别信标注工具。4.2 max_length 截断把关键关系截没了现象短文本抽得准长文本超过 200 字关系全丢。原因max_length设成 128长文本后半段的实体和关系被截断模型根本看不到。解决统计训练集长度分布把max_length设到 95 分位以上如果显存不够用滑动窗口切分文本每段保留重叠区域推理时合并结果。注意重叠区要够大至少覆盖一个完整句子否则关系会被切断。4.3 关系类别不平衡导致「无关系」一家独大现象模型把所有实体对都预测成「无关系」准确率看着很高因为负样本占 90%但召回率接近 0。原因实体对里绝大多数是无关的正负样本比例可能到 1:20。解决训练时对正样本加权或者用 focal loss也可以在构造负样本时做下采样让正负比控制在 1:3 左右。评估时不要只看 accuracy要看正类别的 F1。4.4 中文分词和 BERT tokenizer 不一致现象NER 抽出的实体边界和预期差一两个字比如「北京某某科技」抽成「京某某科技」。原因BERT 中文 tokenizer 是按字切分但后处理时用了 jieba 分词的结果去对齐两套边界对不上。解决统一用 tokenizer 的offset_mapping还原字符位置不要混用分词工具。如果必须用 jieba就在 jieba 分词结果上重新训练 NER保持训练和推理一致。4.5 保存的模型加载时报 key 不匹配现象训练完保存state_dict推理时load_state_dict报Missing key(s)或Unexpected key(s)。原因训练时用了DataParallel或多卡保存的 key 带module.前缀单卡加载对不上。解决保存时用model.module.state_dict()或者加载时用{k.replace(module., ): v for k, v in state_dict.items()}去掉前缀。这个坑在多卡训练转单卡推理时必现记住就行。5. 进阶技巧用规则兜底和主动学习把 F1 再拉 5 个点模型跑通只是起点真正上线还要解决「长尾关系抽不准」和「标注数据不够」两个问题。我一般会加两层规则兜底和主动学习。规则兜底针对高频、模式固定的关系。比如「任职于」「成立于」「位于」这类用正则或关键词模板直接抽置信度给满模型只负责抽规则覆盖不到的。做法是写一个rule_extractor.py和模型输出做融合import re RULES [ (re.compile(r(.{2,4})于(\d{4})年加入(.{2,20})), (任职于, 加入时间)), (re.compile(r(.{2,20})成立于(\d{4})年), (成立时间,)), ] def rule_extract(text): triples [] for pattern, rel_types in RULES: for match in pattern.finditer(text): groups match.groups() if len(groups) 2: triples.append((groups[0], rel_types[0], groups[-1])) return triples # 参数说明RULES 里每条规则对应一种关系模式 # 逻辑正则命中直接产出三元组不经过模型 # 注意规则要定期 review避免过拟合到某批数据融合策略是规则命中的三元组直接采纳模型输出的三元组如果和规则冲突以规则为准规则没覆盖的用模型结果。这样在固定模式的关系上F1 能直接拉到 0.95 以上。主动学习解决标注不够。流程是先用现有模型跑一遍未标注数据挑出模型置信度在 0.4 到 0.6 之间的样本模型最不确定的人工标注这批再混进训练集重训。每轮标注量不用大500 到 1000 条就够跑三轮通常能把 F1 从 0.7 拉到 0.8 以上。关键是选样策略不要随机选要选「模型分歧大」的信息量最高。验证方法上除了看整体 F1一定要分关系类型看。我习惯用seqeval或sklearn的classification_report输出每个关系类别的 P/R/F1找出最差的两三类针对性补数据或加规则。整体 F1 涨了但某个类别掉了说明模型在牺牲长尾换头部这种「假提升」上线后会翻车。最后说个习惯每次改完参数或数据先跑一个小规模实验比如 1000 条训练样本2 个 epoch确认流程通、指标动再上全量。全量跑一次几小时小实验几分钟能省下大量等待时间。这套源码的价值不在于它本身多完美而在于它给了你一个可改、可调、可验证的起点剩下的就是顺着数据把每个环节抠细。希望帮到你。本文还有配套的精品资源点击获取