任务式对话系统NLU核心：领域识别、意图识别与槽位填充实战

我先把这套任务式对话系统的系列笔记整理出来，第一篇就是最基础也最容易被忽视的自然语言理解（NLU）。用户随口一句“帮我订一个明天晚上火车站附近的酒店”，系统要听懂多少东西?它得知道用户说的是酒店业务而不是机票业务，得判断出用户是要订房而不是查价格，还得把“明天晚上”“火车站附近”这些信息拆成结构化的槽位字段。这一步没做好，后面的对话管理和回复生成全是空中楼阁。

这篇文章适合两类人：一类是刚接触对话系统、想系统了解NLU到底是什么的开发者；另一类是已经在做对话产品、但主要用的是大模型接口、没仔细梳理过传统NLU设计思路的工程师。我会把领域识别、意图识别、槽位填充这三个核心子任务讲清楚，再把技术路线从规则模板到预训练模型的演变过程捋一遍，最后结合我在实际项目里踩过的坑，分享一些可以直接用的经验。

1. 任务式对话和闲聊的本质差别，决定了NLU的职责边界

1.1 目的不同，整个技术栈就完全不同

闲聊式对话系统的目标是“把对话延续下去”。你说“今天天气不错”，它可以接“是啊，适合出去走走”；你说“我有点烦”，它可以陪你聊情绪。这类系统不需要把用户的话转成结构化指令，上下文情感和话题延续性反而是重点。

任务式对话系统恰好反过来。它的核心目标是让用户用最少的轮次完成一个具体任务，比如订酒店、查航班、买电影票、报修宽带。整个对话能否成功，可以用一个硬指标来衡量：用户需求是否被准确转换成系统可执行的指令，并且完成了实际操作。

这两种目标差异直接决定了NLU在设计上完全不同。闲聊系统只要理解话题倾向就够了，任务式系统的NLU必须输出机器能直接操作的结构化结果。用户说“帮我订一个明天晚上火车站附近的酒店”，闲聊系统可能回一句“好的呀，你打算住几晚”，而任务式系统会自动拆解成：领域是酒店，意图是订房，槽位包含入住日期=明天、位置=火车站附近。如果缺了“价格范围”这个槽位，系统会在下一轮主动追问。这个“追问”动作就是NLU下游的对话管理在做决策，而决策的输入恰恰来自NLU对当前句子的理解。

1.2 NLU在整体架构里的位置和输出形态

任务式对话系统的经典流水线大致是：语音识别（ASR）→ 自然语言理解（NLU）→ 对话管理（DM）→ 自然语言生成（NLG）→ 语音合成（TTS）。如果入口是纯文本，那ASR和TTS就去掉。NLU夹在最前面，负责把用户原始输入变成结构化表达。

我在项目里习惯把NLU的输出定义成两个部分：

第一是意图，用标签表示用户想让系统做什么。比如hotel_book、hotel_query、hotel_cancel。第二是槽位序列，表示完成这个操作的参数集合，比如date=2025-06-20、location=火车站区域、room_type=大床房。

在一些大型平台上还会先多一层领域（domain）识别。比如一个平台同时有酒店、机票、火车票三个业务线，NLU得先把用户句子分到对应领域，再进入该领域的意图和槽位体系。领域识别本质上是意图识别的粗粒度前置分类，很多工程实现里它和意图识别是一个整体。

这里我特别想强调一件事：NLU不是整个对话系统里“智能”的全部。它只是入口理解这个环节，但它的错误会被后面所有环节放大。意图识别错了，整个对话流程都会走错方向；槽位填错了，执行层可能直接订错日期。反过来，哪怕NLU全部正确，对话管理如果决策混乱，机器人照样表现得像个傻子。做NLU的人心里必须有下游，尤其在置信度输出、多轮槽位合并这些地方，不能只当一个单纯的文本分类任务来做。

2. 领域识别、意图识别、槽位填充：三个子任务的边界与配合

2.1 领域识别：先确定用户在哪张业务表上做操作

多业务平台上，领域识别是挡在最前面的粗筛。用户说“帮我订个酒店”，如果平台根本没有酒店业务，那后面意图识别再准也没有意义；如果平台既有酒店又有民宿，NLU就得判断“订个酒店”属于哪个领域，这需要事先把两个领域的边界定义清楚。

常见实现有两种。一种是直接用文本分类器把整句分配到预定义领域集合，这种方法依赖标注数据，但覆盖好、扩展方便。另一种是先用特征词表和实体词典做召回，比如句子中出现“酒店、房、入住、退房”就命中酒店领域候选，再结合规则或者分类器确认。前者适合数据质量高的新项目，后者适合冷启动阶段快速上线一个可用的版本。

我自己在冷启动项目里经常先用第二种方案：维护每个领域的强特征词表，比如酒店领域的“入住”“退房”“标间”“大床房”，机票领域的“航班”“起飞”“经停”“值机”。用户说“从北京飞上海”，即使没有训练数据，也能通过“飞”这个动词召回机票领域。等到积累了一定量的线上日志和人工标注，再切换成模型分类。这个切换时机一般是在领域识别准确率达不到95%以上的时候，或者发现词表方式在相似领域之间反复混淆的时候。

领域识别有一个非常典型的坑：跨领域的边界词。比如“房间”在酒店领域是普通名词，在酒店行业的新媒体运营语境里可能完全无关。“改签”在机票领域是高频词，在酒店领域根本不适用。所以领域特征词表的维护需要业务人员参与，不能只靠算法工程师凭空拍脑袋。

2.2 意图识别：用户到底想让我执行什么动作

意图识别解决的是“用户想干什么”的问题。它不是开放域情感分类，而是映射到一个预定义的动作集合。这个动作集合和系统能力必须严格对齐。系统能下单付款，才需要定义“付款”这个意图；系统不能退款，就不应该定义“退款”意图。

我在设计意图体系时，通常会遵守几个原则：

每个意图必须对应一个系统操作或业务流程节点。比如酒店订房意图对应“创建订单”，取消意图对应“释放订单”。

意图之间尽量互斥，不要出现“模棱两可”的句子同时命中两个意图的情况。如果发现两个意图经常被同一句话触发，那可能不是模型问题，而是意图定义本身太模糊，需要合并或者重新划界。

意图粒度不追求绝对一致。核心动作类意图可以细化，比如“查询预订记录”和“修改预订”分开；而一些低频动作可以合并成“其他人工求助”意图。粒度要根据数据量和业务频次来定，而不是理论上越细越好的上帝视角。

真实用户说话通常非常省略。他不会说“我要执行酒店订单创建操作”，而是说“帮我随便订个能住的地方”“今晚还有房吗”“我想改到周五”。这些都是同一个意图的不同语言表达。意图识别模型要做的是跨过表面句式差异，理解背后的动作目标。

还有一点容易被忽略：用户会用否定句或间接表达触发操作需求。比如“我不是要取消，我是想改时间”，前半句出现了“取消”这个词，但最终意图是“改签”。如果只看关键词，意图冲突就来了。所以意图识别不能依赖简单的词命中，必须理解句子的语义重点。

2.3 槽位填充：把用户需求变成一张可以执行的信息表

槽位填充是NLU里最容易被低估的一环。意图识别好了，系统只知道用户要干什么，但不知道具体参数。比如“帮我订个酒店”，意图是订房，但住哪里、住几晚、住什么房型全部没有。系统必须靠追问来补齐这些槽位，而追问什么，完全取决于槽位状态。

从技术实现看，槽位填充通常建模成序列标注任务。对输入句子的每个token打一个标签，标签来自预定义的槽位集合，再加上O标签表示非槽位词。比如“帮我订明晚火车站附近的酒店”，标注结果大概是：明晚→checkin_date，火车站附近→location。标签体系是否合理，直接决定下游对话管理的复杂度。

在实际项目里，我建议把槽位分成两类来对待：普通槽位和约束槽位。普通槽位填入内容后直接使用，比如入住人姓名、联系电话；约束槽位还需要额外的有效性和边界校验，比如日期不能是过去日期，价格区间不能是“负数到正无穷”。NLU如果能在输出层就完成初步校验，下游对话管的判断逻辑会简单很多。

槽位还有一个语义重叠问题。同一个词在不同意图下可能属于不同槽位。比如“附近”这个词，在“订火车站附近的酒店”里是location槽，但在“查一下附近有什么景点”里又变成了POI类别。如果你把槽位体系做成全局统一而不结合意图上下文，这种歧义就会变成持续不断的线上badcase来源。

2.4 三个子任务如何协作

领域、意图、槽位不是三个孤立的分类任务。领域可以看成意图之上的粗粒度分组，意图又对槽位取值起到约束作用。经典流水线是：先分领域，再分意图，最后在意图约束下做槽位序列标注。这样同一个词在不同领域、不同意图下可以有不同含义。

但流水线有个明显问题：错误会被逐级放大。领域分错了，意图就没有可能在正确集合里选；意图分错了，槽位填充用的约束词典可能也错了。这也是为什么现在工业界更倾向把多个任务联合建模，共享底层的语义表示。这个思路我在后面第4节会展开讲。

为了方便理解，我把三者的差异用一个表格简单对照一下：

三者层层递进，又互相依赖。理解这个关系是设计整个NLU模块的关键。

3. NLU技术演进路线：从正则模板到预训练语言模型

3.1 规则模板时代：能解释一切，也让维护者崩溃

最早期、也是最直接的做法是正则表达式和关键词模板。系统里预先写好一堆模式，比如“我要订(.?)的酒店”“帮我查一下(.?)到(.*?)的机票”，然后用正则去抓取槽位。

这种方式的优点是解释性极好，出问题可以直接看到是哪条规则没覆盖到，改起来也快。在业务边界极其固定的场景里，规则模板可以做到相当高精度。我也确实在一些纯内部工具里见过完全靠规则跑了几年的对话功能，因为用户群体固定、问题模式固定，效果并不差。

但规则模板一旦面对真实用户，问题就来了。用户表达方式千奇百怪：有人会说“请问你们这里能订酒店吗”，有人会说“我想住一晚干净点的地方”，有人会在聊天里夹带口音和口语词。每条你没写进规则的新句式，都会变成漏报。维护者会在系统里不断堆新正则，直到规则数量多到自己都记不清，出现规则之间互相冲突的情况：一条规则命中A意图，另一条规则命中B意图，最后系统随机选一个。

我见过最典型的一个案例是某客服机器人，最开始几十条正则就能覆盖80%的提问，半年之后规则堆到上千条，覆盖率反而下降了，原因是新写的规则把旧规则的匹配范围打乱了。那次之后我彻底意识到，规则模板适合冷启动和快速验证，不适合规模化演进。

3.2 统计机器学习时代：特征工程换泛化

当标注数据积累到一定规模，大家开始把NLU当作标准机器学习任务来处理。意图识别退化成文本分类问题，常用线性支持向量机（SVM）、朴素贝叶斯、最大熵模型；槽位填充则变成序列标注问题，用得最多的是条件随机场（CRF）。

这个阶段的特征主要靠手工构造。词袋、TF-IDF、词性标签、实体词典命中、前后词、窗口特征都能派上用场。CRF的好处在于能把标签之间的转移关系学出来。比如订房场景下，checkin_date后面更可能出现stay_duration，而location不太可能紧跟在date后面。这种转移约束在纯文本分类模型里是不存在的。

统计模型在中小数据量下表现并不差。我到现在仍然坚持一个观点：在只有几千条标注数据的冷启动项目里，一个特征调好的线性模型，往往比一个没调好的深度学习模型更实用。深度学习吃数据，统计学习吃特征，而特征工程是可以在没有大量数据的情况下靠领域知识堆出来的。

但统计学习的瓶颈在于特征工程的上限。你亲手设计的特征只能捕捉你想到的信息，而自然语言里很多细微的语义关联，靠人工枚举永远枚举不完。

3.3 深度学习时代：从手工特征走向表示学习

深度学习普及后，NLU开始全面转向端到端范式。意图识别用卷积神经网络（CNN）、循环神经网络（RNN）、长短期记忆网络（LSTM）来做文本分类；槽位填充则普遍采用BiLSTM+CRF的经典结构，双向LSTM负责编码上下文，CRF负责在标签序列层做约束解码。

这个阶段最大的变化是，模型学会了从原始文本里自动提取语义特征，GloVe、word2vec这些预训练词向量开始成为标配。词向量本身携带了“含义相近的词在向量空间里距离也近”的信息，这对泛化帮助非常大。模型即使没见过“房间太吵”这个表达，只要它见过“太吵”而且认识“房间”，就可能识别出这是一条关于住宿体验的负面反馈。

BiLSTM+CRF在我的实际项目里用了很长时间，直到今天在一些算力受限的场景下仍然是我回头会选的方案。它比直接在每个token上独立做softmax要好，因为CRF保证了标签序列的合法性，不会出现“date标签后面紧跟着另一个没有含义的嵌套槽位内部标签”这种结构化错误。

不过深度学习的成本也很明确：需要更多数据、更长训练时间、推理时延更高。很多中小团队在第一个深度学习模型上线前，往往低估了数据标注和清洗工作量。

3.4 预训练模型时代：上限大幅提升，但不是银弹

BERT出现后，NLU的效果又上了一个大台阶。预训练模型在任务式对话里几乎是统治级别的提升，尤其是对中文这种缺乏天然词边界信息的语言来说，字符级编码的预训练模型天然就比传统词向量方案更有优势。模型不再需要词法切分工具辅助，对OOV（未登录词）的容忍度也大幅提升。

在实际工程里，BERT类模型既可以当作共享编码器输出整个句子的表示，供意图分类头使用；也可以对每个token输出表示，供槽位序列标注使用。更重要的是，一个句子只需要过一遍编码器，就能同时拿到意图分类和槽位标注需要的所有表示，这为联合建模提供了极好的基础。

但预训练模型并非没有代价。推理时延高、显存占用大、服务成本贵，这些都是真实约束。在一个每天要处理千万级请求的对话平台上，如果每个请求都过一次完整BERT，GPU开销会很惊人。我的经验是分情况处理：高并发、低延迟、强资源约束的场景，优先用蒸馏后的小模型，或者用更轻量的文本编码器；对效果极度敏感、用户容忍度低的复杂场景，再用大模型。这个取舍我在第4节会具体聊。

4. 生产环境里我更推荐的取舍：意图与槽位的联合建模

4.1 为什么不要各训练一个独立模型

很多初学同学会把意图识别和槽位填充分别跑两个模型。这当然能跑通，但在生产环境里会碰到三个实际问题：

第一，重复提取特征浪费资源。同一个句子被两个模型各编码一遍，推理时延和计算成本都增加，而它们提取的底层文本特征其实高度重叠。

第二，任务之间互相孤立，反而丢失关键信息。用户说“订火车站附近的酒店”，“火车站附近”这个词组单独看很模糊，但如果模型知道意图是订房，就会更有把握把它识别成location槽位。意图信息是槽位消歧的天然线索。

第三，维护成本翻倍。数据的标注、模型的版本更新、线上badcase的定位，全部都要在两套系统里各做一遍。做NLU的人应该体会到过这种双倍痛苦：一个badcase往往要排查是意图模型错了还是槽位模型错了，而很多时候二者都错了。

从人类理解语言的角度看，意图和槽位本来就是一个整体理解过程的产物。人听到“帮我订明晚的酒店”，不会先单独判断这是订房意图、再去逐词找槽位，而是一瞬间同时完成了整体理解和局部信息抽取。联合建模就是想模拟这个过程。

4.2 两种常见的联合建模设计

联合建模的方案大体可以分成两类，一类是结构化多头输出，一类是生成式输出。

结构化的思路是：共享一个文本编码器，比如BERT底座。编码器输出整句的[CLS]向量给意图分类头，输出每个token的向量给槽位标注头（通常是CRF层解码）。为了让意图信息辅助槽位，可以把意图分类头得到的意图表示向量拼接进每个token的槽位解码过程，或者用注意力机制让槽位解码时参考意图得分。这种设计的优点是可解释性好、工程成熟、效果稳定，是目前工业界最主流的做法。

生成式的思路是把整个NLU任务重新定义成一个文本到文本任务。输入还是用户句子，输出的目标文本统一拼成类似“intent: hotel_book slots: date=2025-06-20 location=火车站附近”这样的序列，然后用序列到序列模型端到端解码。优点是非常灵活，槽位嵌套和跨域扩展都不用改模型结构，适合多领域复杂任务；缺点是输出序列需要严格定义格式，还容易出现标签对不齐、解码串位的问题。另外生成式方案上线后不容易做逐项badcase解释，这对排障不太友好。

我个人在大多数项目里优先用结构化方案。原因很朴素：可解释性对生产维护太重要了。线上意图错了还是槽位错了，能从中间结果里直接看出来，排障效率比黑盒强太多。

4.3 损失函数和训练细节

联合模型的损失一般是意图分类损失和槽位标注损失的加权和。公式可以写成：

L = α × L_intent + β × L_slot

其中L_intent是意图分类的交叉熵，L_slot是槽位标注的序列对数似然损失。α和β的配比需要根据两个任务的学习难度来调。大多数情况下这两个任务的loss量级不一样，不能直接拿默认值1:1就上。

我通常会先跑一次基线，观察两个loss的收敛情况。如果意图loss下降比槽位快很多，说明意图任务相对简单，可以适当加大槽位的权重，比如β调到1.2到1.5，让模型把更多容量分配给槽位。反过来也一样。这个经验比盲目套网络搜索靠谱，因为网络搜索的准确率变化经常被小波动噪音盖住，很难判断方向。

还有一个细节值得注意：如果意图信息要参与槽位解码，在训练阶段应该用真实的意图标签还是用意图分类头的预测结果来引导槽位训练？从效果看，用真实标签训练收敛更稳，但线上推理时只有预测意图可用，存在训练和推断不一致的问题。常见缓解做法是训练时以一定概率混入预测意图，类似计划采样（scheduled sampling）的思路，不过这会增加训练复杂度。业务团队对延迟和效果不是极端敏感时，我一般保持训练用真实标签，线上用预测结果，然后通过数据增强来弥补分布差距。

4.4 部署时的性能取舍

联合模型部署时最大的压力在线下层。一个完整BERT底座对中文句子做编码，在CPU上的时延可能达到几百毫秒，在GPU上也要几十毫秒。而对话服务通常对响应时延有严格预期，用户等不了两秒才收到一个“好的，正在为您查询”。

我在实际项目中常用两条缓解路径。一条是模型蒸馏，教师模型用完整BERT，学生模型用4层甚至2层的轻量Transformer，蒸馏后的意图和槽位准确率通常能保住教师模型的95%以上，时延却能压到原来的五分之一。另一条是对请求分档：简单句、命中高频模板的句子直接走规则或小模型通道，复杂句才送大模型。这种混合路由设计在工业项目里非常常见。

我不太建议一上来就把产品需求定义成“所有句子都必须用最大模型处理”。很多请求的句式都高度固定，小模型完全够用。做大模型通道成本高，留给真正解决不了的难句才有性价比。

5. 多轮对话和口语化场景：NLU真正掉坑的地方和对策

5.1 多轮指代消解：只看当前句根本做不了

对话的多轮性给NLU带来了一个单句模型解决不了的大问题：指代消解和信息补全。用户第一轮说“帮我订北京到上海的机票”，第二轮说“改成明天的”。如果NLU只编码第二轮这句“改成明天的”，意图可能都判断不清。因为在没有上文的情况下，“改了明天”连一个完整的宾语都缺。

现实项目的解法有两种。第一种是做轻量上下文拼接：把最近一两轮的用户输入拼接在当前句前面，作为当前句的扩展输入。比如“帮我订北京到上海的机票 [SEP] 改成明天的”，拼接后模型就有机会从第一轮里获取缺失的起点、终点和任务目标。这个方案简单直接，但拼接长度、轮数都需要控制，拼接太多会把有用信息淹没在噪声里。

第二种更系统化的做法是把多轮信息合并放到对话状态跟踪（DST）模块里去处理，NLU只负责从当前轮中抽取新增的槽位候选，由DST负责和历史的槽位值做合并、验证和冲突消解。“改成明天的”在NLU层的输出可能是slot_candidate=date=明天，再和历史的“北京到上海”整合成一个完整的出行意图表示。

我个人的建议是：在项目早期，先用上下文拼接让NLU能感知上文即可；到了用户对话轮次丰富、槽位更替频繁的中后期，再引入专门的DST机制。一下子追求过复杂的DST架构，代价不小且短期收益未必明显。

5.2 口语化、省略和ASR噪声：别让模型在脏数据上还做精确分类

真实用户的话和标注规范里的标准例句差距非常大。用户会说“你们那有双人标间没”“包早餐不”“火车站跟前那个店咋样”。这些句子里充满省略、倒装和口语词，如果NLU训练语料主要来自标准书面语，线上表现一定会崩。

口语场景里最残酷的是语音输入的ASR错误。用户对着手机说“火车站附近”，ASR可能识别成“火车占附近”甚至“货车站附近”。这种错误直接破坏了输入文本的完整性，任何文本分类模型都会受到负面影响。要对抗ASR噪声，我常用的做法有几个：

在训练预料中加入经过ASR干扰增强的样本，模拟识别错误。比如随机替换同音字、随机删除字、随机插入语气词。

线上接N-best结果而不是只拿第一候选。NLU同时对多个候选文本做理解，再根据置信度和语义一致性选择最优结果。

建立领域内的同音纠错词典。“火车站/货车占”这类错误在具体业务里其实比较固定，维护一个纠错表比期待通用模型更可靠。

用户的数量和迭代速度决定了，只要真实产品上线，就一定持续有“不按套路说话”的用户。所以NLU的数据团队必须建立线上的badcase回流机制，每周抽取新的失败案例补充到训练集里，这才有持续提升的可能。

5.3 否定句、隐含意图和条件偏好

“不要太吵的房间”这句话里，用户并不是在表达简单否定，而是在给出一个约束条件：朝向位置的房间不要。如果槽位标注的粒度不够，模型很可能只把“不要太吵”当成一句普通情绪，不会把它映射成一个条件槽。

我建议在槽位建模时不要回避否定结构，而是把否定词作为槽位的一个取值维度。比如“不要大床房”可以为room_type添加一个否定标记，实际上代表room_type≠大床房。同时对“不要”“除了”“避开”这类否定信号做特征强化，避免它们被语义编码器当成无关噪声。

还有一种更难的情况是隐含意图。用户不说“我要查酒店”，而是说“我周五到，那两天想在海边走走”。这句话的真实意图可能是“请推荐海边附近的酒店”。传统NLU如果只在给定的意图集合里选一个，很可能选成“闲聊”或“意图不明”。这时候要么在数据准备阶段刻意收集这类表达，要么设计一个“条件偏好”通道，把不满足标准动作意图、但包含关键信息的句子转成待定类型，交给下游对话管理进一步澄清。

5.4 槽位归一化：尽量在NLU内部做格式统一

用户说“明天”和“2025-06-20”表达的是同一个日期。NLU如果直接输出原始字符串，下游对话管理就要自己处理日期计算和格式转换，逻辑会越堆越乱。我倾向于把基础格式归一化放在NLU的后处理阶段完成，比如把“明天”“后天”“下周一”解析成标准日期，把“火车站附近”和“市中心”这样的地点描述解析成结构化地理位置标签。

这里有一个边界问题：格式归一化可以做，但业务语义的统一不能都塞给NLU。比如用户说“附近性价比高点的”和“附近便宜点的”，是否映射到同一个价格档位，这其实取决于业务策略，而不是语言理解问题。让NLU把“便宜”和“性价比高”识别成价格偏好标签是合理的，但把两者合并成同一个业务规则，应该交给对话管理或业务策略层。分清楚这个边界，NLU和下游职责才能清爽。

6. 数据、指标和我在实际项目中踩过的坑

6.1 标注方案决定模型上限，算法只是还原标注

每个NLU项目开始前，最容易“大条”的就是标注方案。大家聚在一起把意图列表定了就开始标数据，结果标到一半发现一堆句子不知道该归哪个意图，又回头改标注规范，再重新洗数据。反复多次之后，我总结出一套可供参考的做法：

先挑出1000条真实用户日志，人工通读一遍，归纳高频的业务需求点，再设计意图分类和槽位体系。不要拍脑袋先定意图再找数据支持。

每个意图至少给出5到10个不同的表达方式作为标注样例，供标注人员参考。比如“订房”意图要覆盖“帮我订个酒店”“我想住一晚”“给我找个能住的地方”“今晚有空房吗”等表达变体。

对于跨歧义句子要给出明确的标注指引。比如用户说“帮我取消订单，不是，我是想改时间”，这种句子最终意图应归为“改签”，而不是“取消”。

槽位边界做统一规则。比如“火车站附近”整体标为location，还是拆成“火车站”（POI）和“附近”（direction）两个槽位，必须提前定死。

标注规范版本要纳入管理。每轮规范修订后，之前标过的数据都需要复核，否则新旧规范不统一会让模型学出一堆冲突模式。

没有好的标注，再先进的模型都是在垃圾数据上训出来的。这句话我平时常说，但做项目时最容易赶进度把它忘在脑后，等线上badcase潮水般涌来再去补标注，代价更大。

6.2 评估指标别只看准确率

意图识别常用accuracy来评估，但当一个数据集里某个意图占比超过80%时，全预测成这个类别准确率也有80%，表面好看却毫无用处。所以我更关注每个意图的精确率、召回率和F1，还特别在意混淆矩阵，这样才能看出是哪些意图两两之间经常发生混淆，比如“修改预订”和“取消预订”——它们经常被模型搞混，因为用户说得都太相似。

槽位填充以token级别的精确率、召回率、F1为主，但最好再加上一个样本级全对率（all-token-correct rate），因为如果一句里抽出一个槽位错了，下游对话状态跟踪就会错半轮甚至一整轮。我曾经有一个项目，槽位的token级F1在95%以上，看着挺不错，但样本级全对率只有70%多一点，这意味着三成句子里至少有一个槽是错的。后续对话追补的体验就很差。从那以后我养成了至少并行看这两个指标的习惯。

评估集不能和训练集来源完全一致。如果都从同一批标注数据里切分，模型过拟合会带着虚高指标好看。线下评估样本尽量来自线上真实用户的日志，而非仅用人工构造语料。每次模型更新前，都应该用同一份固定评估集回归，这个评估集要随时间扩充——加入新踩到的线上badcase。

6.3 坑1：线上用户和标注数据长得完全不像

我第一个正式NLU项目上线后，发现意图准确率比离线测试低了十几个百分点。最直接的原因就是线上用户的话和标注团队基于模板造出来的样本差距太大。标注员写的是“我要预订一个酒店房间”，真实用户说的是“明天有没有住的地方”。这提醒我：标注数据不能靠人坐在办公室里凭空造句，必须从真实对话日志里采样。

现在我做NLU项目，冷启动阶段宁可先用粗糙的规则顶上，也要花时间把真实日志里沉淀的典型表达捞出来，让标注团队基于这些真实句子去标，而不是先造一批漂亮句子。规则可以粗糙，但数据源方向不能反。

6.4 坑2：多领域意图标签冲突

当一个平台从单业务扩展到多业务，意图标签体系就容易出冲突。酒店领域的“query_price”是查询价格，机票领域的“query_price”也可能是查询价格，但语义字段差异很大。直接合到一起会让模型在跨领域句子上产生混乱，比如“这趟航班多少钱”不小心命中酒店领域的价格查询意图模板。

我现在的经验是多业务平台优先采用“领域+意图”联合标签，或者直接为每个领域建独立的意图体系和模型，而不是强行统一所有领域。独立模型会增加一些工程成本，但隔离性好，业务扩展时每次只需新增一个领域模块，不用反复回归旧领域。

6.5 坑3：长尾槽位值的假阳性和置信度阈值

槽位抽取总会出现假阳性。用户说“公司报销，所以选个中等价位的就行”，模型可能会把“公司报销”抽成一个奇怪的槽值字段。这类长尾表达如果没有出现在训练集里，模型很容易因为上下文的“报销”“中等价位”等词产生错误联想。

我的对策是给槽位输出设置置信度阈值，低于阈值的槽位宁可不要，让下游追问一次，也不能让错误槽位直接流到执行层。同时把线上高频假阳性槽值收集起来，加入标注集的负例，让模型学会“这个词不是槽值，只是普通上下文”。在模型迭代初期这个工作量不大，但收益非常直接。批量把假阳性压下去，槽F1会有明显提升。

做NLU这个模块，和做整个对话系统一样，数据、指标、模型、工程四处都要照顾。它没有太多炫技空间，真正的价值在于把每一个细节抠稳，把每个badcase扎扎实实改掉。这个系列后面继续更新对话管理部分时，我会再展开多轮状态跟踪和策略决策的细节。到时候你会发现，NLU埋下的每一个准确或不准确的坑，最后都会在对话管理里以更放大的形式浮现出来。