意图不明确时怎么办：未知意图识别、拒识与澄清追问

意图识别器无法确定类别时，强行选择标签可能导致错误处理。用户问“开一张发票”，系统没有开票能力，却因为出现酒店相关词就把它送进订单查询；用户说“把那个取消”，系统没有确认是哪笔订单就继续操作。系统需要分别判断：请求是否超出业务范围，还是缺少确定目标所需的信息。

本文区分范围外请求、解释歧义、缺少参数与服务暂不可用，给出拒识和澄清的决策方法，并使用同一组教学数据实际选择阈值、观察覆盖率与错误。完整代码与数据可以下载复现。

一、区分不确定性的来源

最后一种不是意图未知。若把工具故障标成范围外，后续错误分析就无法分清理解失败与服务失败。

范围外也不等于没有意义。酒店开票是合理需求，只是可能不在当前能力目录。CLINC 将已知类别分类与范围外输入识别作为需要分别检查的问题，可作为评测设计的参考。CLINC 论文

二、理解候选分数

假设分类器只有查询、预订、取消三个类别。无论输入是什么，输出的最大值都必然属于其中之一。若没有范围外判断或拒识策略，模型无法通过“没有合适选项”表达问题。

不同分数的含义也不同：

概率校准研究的是预测分数与观察到的事件频率是否一致。校准效果依赖数据分布；当前输入与校准数据差异较大时，需要重新检查。scikit-learn 概率校准文档

三、最高分阈值与候选分差

一种简单策略是先检查最高分是否足够，再检查前两名是否太接近：

from batch2.policy import decide

print(decide({"order_query": 0.30, "cancel_booking": 0.20}, 0.50, 0.10))
print(decide({"order_query": 0.80, "cancel_booking": 0.79}, 0.50, 0.10))
print(decide({"order_query": 0.80, "cancel_booking": 0.50}, 0.50, 0.10))

在工程根目录运行，三个结果分别为 abstain、clarify、select。这组小数仅用于测试决策分支，不是推荐阈值。

最高分低意味着当前模型缺少足够支持，可能是范围外，也可能只是模型能力不足；前两名很接近意味着候选难以区分，但不一定存在真正的用户语义歧义。因此代码返回的是“拒绝选择候选”和“需要进一步区分”，不会直接将低分请求判定为范围外输入。

对于分数相同的并列候选，示例明确走澄清分支，避免标签顺序决定结果。非有限值也会被拒绝，防止 NaN 参与比较后意外通过。

四、根据错误代价选择阈值

本次教学实验在训练之外准备了 28 条验证样例：21 条属于 7 个已知类别，7 条属于当前范围外。用验证集搜索阈值和分差，然后将选定参数固定，在另外 21 条演示检查样例上运行。

为了展示取舍，预先使用如下损失：

损失 = 5 × 错误接收数 + 1 × 已知请求被拒绝选择的数量

错误接收包含两种：接收了范围外输入，或将已知输入选成错误标签。拒识和澄清都视为本次没有选择标签；已知请求因此增加一次代价，范围外请求不选标签则不增加代价。

这个 5:1 的设定表达一种偏好：宁可多问一次，也要减少错误接收。取消订单误判通常比查询菜单误判代价更高，因此真实业务可以按动作分别设置代价，同时考虑追问造成的流失和人工处理成本。

先在验证集选择参数，再用另一组数据检查固定方案，可以避免根据最终结果反复调整阈值。具体网格与结果见下载包。

最高分阈值选成 0，并不意味着无条件接受。规则仍会拒绝零命中和最高分并列；TF-IDF 还需要通过候选分差。两项条件要一起理解。

例如 TF-IDF 在这组输入上只接收了 6 条。较低的覆盖率意味着更多请求进入追问或其他处理路径。评价这套策略时，应同时考虑错分代价和后续处理成本，不能只看单个指标。

五、阈值方法的局限

高阈值可以减少部分弱匹配的误接收，却也会拒绝表达自然但与训练例句相距较远的正确请求。如果错误输入和正确输入的分数分布大量重叠，单个阈值无法同时保留高覆盖和低错误。

同理，候选分差只比较现有类别之间的相对关系。一个范围外请求可能与所有类别都不匹配，但仍然明显更像其中某一类；一个已知请求也可能因为标签定义重叠而分差很小。

遇到这些情况，应检查标签边界、困难负例、表示模型和训练数据，必要时增加范围判断模块或改变路由。反复细调阈值可能只会造成验证集过拟合。

六、设计具体的澄清问题

“你想干什么”通常浪费了已经获得的信息。澄清时应利用已经获得的信息，只询问仍未明确、且会影响后续处理的内容。

这些问题的具体选项必须来自当前状态或真实候选。模型如果编造了不存在的订单号，追问本身也会造成误导。

澄清还需要更新状态。例如用户选了订单 A，系统应将订单槽位绑定到当前取消任务，并使旧的候选问题失效。发出追问时应同时保存待回答问题，确保下一轮能够继续处理。

七、设置追问上限

连续两次没有解决同一个缺口，继续用同样的句子追问通常不会改善体验。附件提供一个小型策略函数，区分缺槽、歧义、低支持和不支持能力，并演示次数上限：

from batch2.policy import clarification_action

assert clarification_action("missing_slot", attempts=0) == "ask_specific_slot"
assert clarification_action("ambiguous", attempts=2) == "offer_handoff_or_stop"
assert clarification_action("ambiguous", attempts=2, user_cancelled=True) == "cancel_dialogue_task"

这里默认上限为 2 次，只用于展示策略分支。生产系统应按缺口或任务记录次数，在问题解决后重置，并结合用户状态决定是否提供人工入口或结束任务。该函数没有实现完整的会话计数器与人工系统。

用户明确放弃当前任务时，应优先尊重这一决定；应停止收集该任务的参数。“不订了”取消的是对话中的预订任务，不能自动转换成取消一笔真实订单。

八、评估拒识效果

只报告“被接收样本中的正确率”可能掩盖大量拒识。需要同时给出覆盖率、接收中的错误率，以及范围外输入被误接收的数量。

覆盖率 = 接收并选择标签的样本数 / 全部样本数
选择性错误率 = 错误接收数 / 接收样本数

当接收样本为零时，选择性错误率没有分母，应记为未定义，而不是 0%。一个全部拒绝的系统可以没有错误动作，却不代表提供了可用服务。

还应单独检查已知类别的误拒比例、每种高代价操作的误接收、澄清后的成功率和平均追问次数。单轮阈值实验无法回答完整多轮任务是否完成，这部分留给后续评测文章。

九、取消订单的澄清示例

用户说“把那个取消”，系统里有两笔订单。此时取消目标可能明确，但对象不唯一，应追问“你要取消 DEMO-A 还是 DEMO-B？”用户选择 A 后，系统还需核实取消费用。如果用户补充“收费就不取消”，要将条件写入任务，而不是继续沿用无条件取消。

若查询费用失败，问题转为服务不可用；若查询发现有费用，问题转为条件不成立。这两种情况都不应再次让用户解释自己的意图。每次追问只补充当前缺少的信息，系统再根据回复更新状态并选择后续流程。

例子也说明，澄清成功率不能只看用户有没有回复。更有用的判断是：回复是否消除了原来的歧义，是否正确更新了状态，是否减少了错误动作。

拒识表示当前无法可靠选择类别。系统应根据原因决定是继续追问、说明能力范围，还是转交其他服务。

继续阅读：基础方法实测、标签设计、多轮状态、系列总览。

进阶阅读

• 意图识别怎么评测：从分类准确率到多轮任务成功率。
• 意图识别服务上线：延迟、成本、监控与错误闭环。