简介一套基于PyTorch与BERT的意图识别与槽位填充联合训练实现代码包面向中文自然语言处理中的多任务理解场景适合对话系统、任务型问答等应用研发及教学实验。项目将文本分类与序列标注融入统一训练框架以chinese-bert-wwm-ext为预训练底座同时输出意图类别与实体槽位并借助多任务学习增强语义表示。zip压缩包共25个文件整体大小15KB代码主体是8个Python脚本覆盖数据预处理、模型定义、训练验证、测试预测全流程另有txt标签字典、json样本集、yaml配置与README说明整体结构精简清晰。运行环境需PyTorch不低于1.6及Transformers 4.5.0通过python main.py启动训练config.py集中管理超参数、数据路径等关键设置便于复现和二次开发。目前已有44人学习代码量虽小但覆盖面完整可作为中文意图识别与槽位填充联合建模的参考实现快速改造接入实际项目。1. 为什么意图识别和槽位填充要喂给同一个BERT做对话系统的人基本都撞过同一堵墙用户一句“帮我订明天从北京到上海的机票”系统不仅要判断这是“订机票”意图还得从这句话里抠出“明天出发时间”“北京出发城市”“上海到达城市”这些槽位。早年的做法是把意图分类和槽位抽取拆成两个独立模型先后串行跑意图错了槽位必错槽位错了意图也救不回来。后来大家发现与其让两个模型互相甩锅不如让它们共享同一个BERT编码器、在同一个前向过程里各出一个头这就是基于PyTorch的意图识别与槽位填充联合训练。这份实现把数据预处理、双头模型、多任务损失和推理对齐都串成了一条能直接改、直接跑的链路适合正在做任务型对话、智能客服或者语音助手底层NLU的从业者参考。2. 数据准备BERT分词器、BIO标签对齐与动态padding2.1 数据集选型与标注格式联合训练最常见的数据集是ATIS航班订票领域句子短、意图类别和槽位标签都比较规整适合拿来做基线。如果你手头没有现成数据也可以按同样格式整理自己的业务语料。标注格式长这样句子每个词对应一个槽位标签标签体系用BIOBegin/Inside/Outside标注意图标签给整个句子标一个分类。帮 我 订 明天 从 北京 到 上海 的 机票 O O O B-time O B-city O B-city O O intent: book_flight这里“明天”是出发时间“北京”和“上海”分别是出发地和到达地所以各用B开头标注。注意BIO里一个槽位跨多个词时第一个词是B后续词是I比如“浦东机场”可以标注为B-airport、I-airport。这种标注方式能直接套在序列标注上也是后面槽位头用序列分类任务的基础。环境上我一般先用conda建一个独立环境然后按官网对应CUDA版本装PyTorch和transformers库。步骤不复杂但版本坑多torch和CUDA版本不匹配时训练会静默地慢半拍不报错但折腾人。conda create -n joint_bert python3.9 -y conda activate joint_bert pip install torch transformers datasets scikit-learn提示transformers库版本建议4.x以上新版Tokenizer的word_ids接口对标签对齐很友好省掉很多自己写offset映射的苦工。2.2 用tokenizer把句子和标签切成BERT能吃的样本BERT用的是WordPiece分词一个词可能被切成多个subword比如“机票”可能切成“机”“##票”。槽位标签是按词标的所以要先把词级标签映射到token级标签这个过程最容易出错。常见做法是用tokenizer返回的word_ids它记录了每个subword属于句子里的第几个原始词。def align_labels_with_word_ids(text, word_labels, tokenizer, label2id): encoded tokenizer(text, add_special_tokensTrue) word_ids encoded.word_ids() input_ids encoded[input_ids] label_ids [] previous_word_idx None for word_idx in word_ids: if word_idx is None: # [CLS]和[SEP]不参与槽位预测槽位损失里要屏蔽掉 label_ids.append(-100) elif word_idx ! previous_word_idx: # 当前subword是新词的第一个片段继承原词标签 label_ids.append(label2id[word_labels[word_idx]]) else: # 同一个词被切成多个subword标签怎么处理取决于你的策略 label_ids.append(label2id[word_labels[word_idx]]) previous_word_idx word_idx return input_ids, label_ids逻辑上特殊token用-100填充后面在CrossEntropyLoss里设ignore_index-100就能自动跳过。对于同一个词被切出的后续subword最简单省事是直接复制原标签虽然B后接B在严格BIO上不算合法但配合CRF解码时会出问题我一般用I-Prefix策略即第一个subword保留原标签后面的subword如果原标签是B就改成对应的I标签。这样既符合BIO约束也不会丢信息。2.3 动态padding的关键代码与参数说明很多初版代码直接固定max_len128把所有样本pad到同一长度。这么做简单但短句多时浪费显存batch稍微大点就OOM。我习惯用动态padding每个batch内部只pad到当前batch最长长度。transformers的DataCollatorWithPadding能直接干这事但为了让你看清里面发生了什么我写一个轻量版。import torch from torch.nn.utils.rnn import pad_sequence def collate_fn(batch): input_ids [torch.tensor(item[input_ids]) for item in batch] label_ids [torch.tensor(item[label_ids]) for item in batch] # 按batch内最长序列统一长度 input_ids pad_sequence(input_ids, batch_firstTrue, padding_value0) label_ids pad_sequence(label_ids, batch_firstTrue, padding_value-100) attention_mask (input_ids ! 0).long() return { input_ids: input_ids, attention_mask: attention_mask, label_ids: label_ids, }padding_value0对应BERT的[PAD]tokenattention_mask里pad位置为0这样BERT的attention机制能自动忽略padding位置。label_ids里pad位置填-100损失函数里被屏蔽。整套逻辑下来train_loader就能直接供模型消费。注意token_type_ids在单句分类里可以省掉不传BERT会自动默认全0。如果你做的是句对任务才需要显式构造。3. 模型实现共享BERT编码器的双头结构3.1 意图头与槽位头的设计联合训练的核心是参数共享。BERT编码器把整句话编码成一组向量每个token位置对应一个向量同时[CLS]位置也能聚合成一个句向量。意图是一个句子级分类问题所以意图头接在[CLS]的输出上槽位是token级序列标注所以槽位头接在每个token的输出上。两个头共享同一个BERT编码器梯度回传时互相增强这是我选这个结构而不是两个独立模型的原因。import torch.nn as nn from transformers import AutoModel class JointBERT(nn.Module): def __init__(self, model_name, num_intents, num_slots, dropout0.1): super().__init__() self.bert AutoModel.from_pretrained(model_name) hidden_size self.bert.config.hidden_size # BERT-base是768 self.intent_head nn.Linear(hidden_size, num_intents) self.slot_head nn.Linear(hidden_size, num_slots) self.dropout nn.Dropout(dropout) def forward(self, input_ids, attention_mask, token_type_idsNone): outputs self.bert( input_idsinput_ids, attention_maskattention_mask, token_type_idstoken_type_ids, ) sequence_output outputs.last_hidden_state # [B, L, H] pooled_output outputs.pooler_output # [B, H] intent_logits self.intent_head(self.dropout(pooled_output)) slot_logits self.slot_head(self.dropout(sequence_output)) return intent_logits, slot_logits3.2 参数说明与默认值怎么定num_intents和num_slots需要根据你数据集的实际类别数配置ATIS大约是21个意图、120个槽位类型。dropout设0.1和BERT预训练时保持一致防止双头过拟合。这里我没有在slot_head后面接CRF先用LinearSoftmax把链路跑通模型更简单、训练更稳定CRF放到后面作为进阶选项原因在第五章展开。代码里pooler_output是BERT自带的句向量但它经过了一层tanh激活有些场景下直接取[CLS]位置的hidden_state反而更稳。我测试过不少业务数据pooler_output和CLS向量差距不大换哪个都行但如果你的分类头效果一直卡在某个准确率上不去可以把pooled_output换成CLS向量对比一下有时候能有1-2个点的提升属于小技巧。3.3 槽位头为什么要在hidden上再接全连接有人会问BERT输出的每个token向量已经是768维直接拿去做120分类不也挺好吗表面看可以但槽位分类是细粒度标签类别之间有强依赖关系比如“from_city”后面很少直接接“arrive_city”。Linear层的本质是把768维空间线性投影到类别空间训练过程中会强迫模型学到类别间的线性判别边界和BERT自身的语义表征互相解耦效果比直接取logits要干净。如果你打算上CRFslot_head的Linear层就是为CRF准备的发射概率emission score后面再接一个CRF层做标签转移约束。这样做的好处是显式建模“B后面不能接B”这类规则坏处是batch内每个序列都要单独decode速度会降一些。先跑通不带CRF的版本再决定要不要加这个顺序我比较推荐。4. 联合训练多任务损失、学习率分配与收敛判断4.1 多任务损失函数的设计联合训练要同时优化两个损失意图用交叉熵槽位用交叉熵区别是槽位要屏蔽padding位置。总损失是对两个损失加权求和常见做法是意图损失权重1.0槽位损失权重0.5到1.0之间这个比例需要根据你业务里哪个任务更重要调。有的项目槽位抽取难一些训练时损失降得慢权重可以给大一点。import torch.nn as nn criterion_intent nn.CrossEntropyLoss() criterion_slot nn.CrossEntropyLoss(ignore_index-100) intent_loss criterion_intent(intent_logits[0], intent_label) slot_loss criterion_slot(slot_logits.view(-1, num_slots), slot_label.view(-1)) loss intent_loss 0.8 * slot_loss参数说明intent_label是一个标量slot_label是[batch, seq_len]的标签矩阵。view(-1)这一步很关键把batch和seq_len合并让CrossEntropyLoss独立处理每个token的分类。ignore_index-100保证padding位置不贡献梯度。0.8我这里取的是槽位权重如果你发现槽位F1一直偏低可以提到1.0代价是意图准确率可能小幅回落。4.2 训练循环代码与关键参数设置训练这部分最大的坑是学习率。BERT是预训练模型微调时学习率要用低阶常见是2e-5到3e-5分类头是随机初始化的蹭BERT的梯度容易震荡所以单独给它配一个偏大的学习率。PyTorch里用AdamW参数组拆成两段。from transformers import AdamW, get_linear_schedule_with_warmup param_optimizer list(model.named_parameters()) no_decay [bias, LayerNorm.weight] optimizer_grouped_parameters [ {params: [p for n, p in param_optimizer if bert in n and not any(nd in n for nd in no_decay)], lr: 2e-5, weight_decay: 0.01}, {params: [p for n, p in param_optimizer if bert in n and any(nd in n for nd in no_decay)], lr: 2e-5, weight_decay: 0.0}, {params: [p for n, p in param_optimizer if bert not in n], lr: 1e-3, weight_decay: 0.0}, ] optimizer AdamW(optimizer_grouped_parameters, correct_biasFalse) total_steps len(train_loader) * epochs scheduler get_linear_schedule_with_warmup( optimizer, num_warmup_stepsint(total_steps * 0.1), num_training_stepstotal_steps, ) for epoch in range(epochs): for batch in train_loader: input_ids batch[input_ids].to(device) attention_mask batch[attention_mask].to(device) label_ids batch[label_ids].to(device) intent_label batch[intent_label].to(device) intent_logits, slot_logits model(input_ids, attention_mask) intent_loss criterion_intent(intent_logits, intent_label) slot_loss criterion_slot(slot_logits.view(-1, num_slots), label_ids.view(-1)) loss intent_loss 0.8 * slot_loss loss.backward() nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() scheduler.step() optimizer.zero_grad()几个参数值得展开说。clip_grad_norm1.0防止梯度爆炸BERT微调里比不设能多保住几次训练。warmup比例设0.1前10%的步数学习率从0线性爬升到峰值这让BERT在训练初期不会因为学习率骤增把预训练权重冲坏。epochs我在ATIS上一般跑3到5次BERT微调不建议多跑跑多了在验证集上容易先升后降严重的还会磨掉泛化能力。batch size方面显存允许就设32动态padding通常能把显存占用压下来。4.3 验证指标怎么算更稳意图准确率直接算就完事槽位则需要分两个层面看。一个是token级别的准确率和F1一个是句子级别的槽位完全匹配率。token级F1按BIO标签逐token算句子级要求整个序列的槽位预测全对才算对。实际业务里更看中句子级匹配率因为它直接和用户意图解析质量挂钩。from seqeval.metrics import classification_report, f1_score true_slots [] pred_slots [] for batch in valid_loader: intent_logits, slot_logits model(...) _, intent_pred torch.max(intent_logits, dim1) slot_pred torch.argmax(slot_logits, dim-1) for i in range(len(batch[input_ids])): label_ids batch[label_ids][i] mask label_ids ! -100 true_seq id2label[label_ids[mask].cpu().tolist()] pred_seq id2label[slot_pred[i][mask].cpu().tolist()] true_slots.append(true_seq) pred_slots.append(pred_seq) print(classification_report(true_slots, pred_slots))seqeval库按BIO标签解析序列能直接算出每个槽位类型的precision、recall、F1还会自动处理B和I的完整性。用id2label把数字标签映射回字符串再送进去这里注意别把-100和padding当作槽位标签参与评测。5. 避坑记录标签错位、NaN损失和模型不收敛5.1 tokenizer切词导致的标签错位现象验证集槽位F1始终上不去明明训练损失在降但预测出来的标签序列里同一个词被切分成的subword标签混乱有的标了B有的标了I毫无规律。原因这类翻车最常见就是标签对齐时没处理subword继承规则。我犯过直接用词列表逐token对位但BERT分词后token数量比词多标签索引全部偏位等于拿着错标签训练。还有一种情况是perl写法的复制策略不对同一个词切出的后续subword原样复制的B标签配合CRF后B后接B直接非法标签冲突。解决强制用word_ids接口对齐第一段subword保留原BIO标签后续subword统一改成对应槽位的I标签难例单独写一个校验函数打印几个样本人工检查。5.2 训练中损失变成NaN现象第几个iteration之后loss突然变NaN梯度爆炸或者遇到无效值重启训练可能复现也可能不复现。原因三个来源。第一是学习率设置太大BERT微调时特别容易发生有人直接用1e-3去微调BERT前向输出直接飞到无穷大第二是warmup没设初始学习率瞬间冲击第三是batch里出现空序列比如一个文本经过tokenizer后只剩[CLS]和[SEP]attention_mask全0BERT输出也无意义。解决把BERT参数组学习率压到2e-5分类头保持1e-3以下总损失里加一个梯度裁剪max_norm1.0数据预处理里把切完subword后token数量小于3的样本直接丢弃这是最容易被忽视的。5.3 槽位类别里B和I不一致导致F1虚胖现象用seqeval算出来的F1很高但人工看预测结果很多实体的B和I标签错位比如“北京 上海”被预测成B-city后跟着I-city但前一个实体没有B收尾。原因不做CRF的Linear层输出是逐token独立分类的模型没有显式学习标签转移约束所以会出现B后直接接另一个实体的B、或者实体中间漏了B这类看起来不合理的序列。解决如果对序列合法性要求高直接上CRF层它会给标签转移加约束如果不想加CRF在验证时用规则做后处理比如把没有B开头的I序列修正掉。这里的血泪经验是指标好看和实体完整是两回事报告指标前先对齐人工检查一遍。5.4 梯度回传时padding位置干扰意图头现象槽位损失很低但意图准确率到了某个点就再也不涨训练集上还能涨验证集开始震荡。原因padding位置虽然有mask语义上被attention忽略但槽位头的输出是一整根向量padding位置的logits仍在损耗里被屏蔽了这部分梯度没有干扰。真正的干扰来自batch多样性意图分类和槽位分类虽然共享编码器但槽位梯度占比大时BERT参数的更新方向会更偏向token级任务意图头的性能就明显被压缩。解决调整损失权重比例我见过把槽位权重降到0.3意图权重升到1.2的组合意图准确率能回涨2个点另外把意图头换成从[CLS]位置取hidden_state而非pooler_output两个做法叠加后跟单任务意图模型的准确率差距可以缩到0.5个点以内。5.5 GPU利用率低、显存不足和长文本截断现象训练时GPU利用率常年不超过40%显存看着没满但加载数据时CPU卡死训练速度慢得让人怀疑人生。另一个极端是一个batch里有几个超长文本直接把显存顶爆。原因DataLoader的num_workers默认是0数据加载和tokenize全在主进程里跑GPU一直在等CPU产数据而固定max_len128时batch内部短样本填充大量padding token显存白白浪费。解决num_workers调到4到8tokenize放到数据预处理阶段而不是训练循环里训练时只做张量索引和采样padding策略改成动态paddingbatch内按最长序列截断长度在96到160之间动态变化既省显存又利用率高。长文本处理上BERT上限是512超过512的句子我会按句号切分分别过模型再把槽位结果拼回去。6. 推理对齐与CRF进阶让输出变成可直接交付的结果6.1 推理时的标签对齐与解码训练和推理要保证同一个对齐逻辑否则预测出来的标签序列数值对但位置错。推理阶段没有真实标签需要自己构造label_ids的mask来区分可预测token和特殊token。我的做法比较简单推理时用和训练时一样的tokenizer取出word_ids预测结果里只保留非None位置的token预测再把subword级别标签合并成词级别标签。def decode_predictions(text, tokenizer, model, id2label, device): encoded tokenizer(text, add_special_tokensTrue) input_ids torch.tensor([encoded[input_ids]]).to(device) attention_mask (input_ids ! 0).long() model.eval() with torch.no_grad(): intent_logits, slot_logits model(input_ids, attention_mask) intent_id torch.argmax(intent_logits, dim-1).item() slot_ids torch.argmax(slot_logits, dim-1).squeeze(0).cpu().tolist() word_ids encoded.word_ids() word_slot_map {} prev_word_idx None for token_idx, word_idx in enumerate(word_ids): if word_idx is None: continue if word_idx ! prev_word_idx: word_slot_map[word_idx] id2label[slot_ids[token_idx]] prev_word_idx word_idx intent_label id2label_intent[intent_id] slots [] for word_idx, label in word_slot_map.items(): if label ! O: slots.append((label, word_idx)) return {intent: intent_label, slots: slots}这个decode函数里有两个容易踩的细节。第一是word_slot_map只取每个原始词的第一个subword预测作为该词标签因为后续subword的标签我们已经用复制策略和它保持一致了第二是对O标签的词不输出到slots里。实际部署时我会把这个函数包装成服务接口输入原始文本输出意图和槽位列表比如{intent: book_flight, slots: [(B_time, 2), (B_city, 3)]}然后交给下游的API参数映射逻辑。6.2 CRF层要不要加什么时候加先说结论如果你的业务对槽位完整性要求不高或者训练数据量大得足以掩盖标签转移约束的缺失Linear头就够了但如果交付给客服质检、语音助手这类的场景建议上CRF。CRF的一层转移矩阵能学到“B-time后面不能直接跟B-city”这种约束在数据量少时尤其管用。常见做法是直接使用pytorch-crf库也可以自己手写一个CRF类包含转移矩阵和维特比解码。加上CRF的代价是推理速度降低20%左右因为维特比解码是路径搜索每个序列都要单独算无法像Linear头那样整batch矩阵运算。我自己的习惯是先在开发集上跑一版Linear头确认数据没问题后再考虑加CRF对比。切换CRF后必须在同样的验证集上重测槽位F1和句子级准确率有提升才留没提升就撤。这属于玄学经验但CRF在大规模业务数据下的收益确实常常只有1-2个点不值得为它付出推理时延。把那一次训练损失怎么调都降不下来、最后发现是标签对齐错位的教训记下来以后我每次跑Joint模型前都强制先走一遍标签对齐校验流程打印5条样本检查词级标签和token级标签的对应关系再进训练循环这套习惯帮我省掉了无数个解Bug的周末。推理阶段也沿用同一套对齐逻辑保证训练和线上行为一致。希望这份实现和踩坑记录能帮你顺利跑通自己的意图识别与槽位填充模型。本文还有配套的精品资源点击获取