任务边界模糊时用联合模型更稳，清晰时pipeline更轻；联合模型需手动加句子分类头、统一标签空间、重写compute_loss；pipeline需意图前置过滤、领域微调槽位模型、硬编码后处理规则；联合模型显存高、热更新难、监控复杂。
槽填充用联合模型还是 pipeline？看任务边界清不清楚
如果意图识别和槽位抽取的边界模糊（比如“订明天下午三点的会议室”里，“明天下午三点”既是时间意图，又得拆成 date 和 time 槽），联合模型更稳；边界清晰（如“播放周杰伦的歌”，意图是 play_music，槽只有 artist）时 pipeline 更轻、更好调。
transformers + TokenClassification 联合建模要注意标签对齐
联合模型常把意图当句子级标签、槽位当 token 级标签，但 Hugging Face 的 TokenClassification 默认只处理 token 级。容易踩的坑是：直接套用 AutoModelForTokenClassification 会丢掉意图预测——得手动加一个句子分类头，或改用 AutoModelForSequenceClassification + 自定义 loss 合并两个目标。
- 标签空间必须统一：比如用 BIO 标注槽位，同时用
INTENT:book_meeting作为额外 token 标签（首 token），否则对齐会错位 -
Trainer不支持多任务 loss 直接叠加，得重写compute_loss方法，分别算cross_entropy再加权求和 - 输入长度受限：联合模型对长句更敏感，
max_length=128时，“帮我查从北京到上海再转杭州的所有高铁班次”这种嵌套查询容易截断
pipeline 方式下 spaCy 或 flair 做槽填充，别漏掉意图前置过滤
pipeline 看似简单，但实际部署中，90% 的 bad case 来自“不该进槽填充模块的文本进了”。比如用户说“系统坏了”，意图是 report_bug，根本无槽可填——如果没在 pipeline 第一步用轻量分类器拦截，后续 ner.predict() 可能强行标出不存在的 ORG 或 DATE。
- 意图分类模型要足够快：推荐用
sklearn训练LinearSVC或蒸馏后的distil-bert-base-uncased，延迟控制在 50ms 内 - 槽位模型别复用通用 NER：通用模型把“微信”标成
ORG，但业务里它是app_name槽——必须用领域语料微调 - 后处理规则不能省：比如“取消今天所有会议”，
today被标为DATE，但需映射成{"date": "2024-06-12"}，这步得硬编码逻辑，模型学不会
线上服务时，联合模型显存涨得比 pipeline 快得多
一个 batch=16、seq_len=64 的联合模型，在 bert-base-chinese 上 GPU 显存占用约 3.2GB；同样配置下 pipeline（意图模型 + 槽位模型分两次 forward）只占 2.1GB。不是因为联合模型“更高级”，而是它强制让所有参数全程参与计算，中间激活值更多。
立即学习“Python免费学习笔记（深入）”；
- batch size 下降敏感：联合模型 batch=8 时显存只减 15%，pipeline 能减 40%
- 热更新困难：改一个槽类型就得重训整个联合模型；pipeline 可单独替换
slot_model_v2.bin - 监控更难：pipeline 每步输出可 log，联合模型只能 log 最终 logits，debug 时得靠 attention 可视化，成本高
真正卡住落地的，往往不是准确率差那 2%，而是联合模型改个 label_list 就要重新跑三天训练，而 pipeline 里换槽位模型只要替换一个文件、重启服务进程。
