M2.07.4scrambled slot filling设计研究

槽位填充顺序应允许乱序

别名: 乱序填槽 · mixed initiative · over-answering

概念解释

填一张语音表时,用户给出槽位的顺序不必等于设计师的提问顺序。「订明天晚上七点四人靠窗」已经把日期、时间、人数、偏好一次给齐;系统若仍按「先问日期、再问时间」往下问,就是在把已经听见的东西再问一遍。乱序指的是同一意图里多个槽的到达次序,不是一句话里塞了几件不同的事。

机制

口语按话题组织,不按表单字段组织。人开口前在工作记忆里压的是整件目标,能说的会一次性倒出,这叫过量回答。顺序状态机把「当前该问第 n 槽」写成节点,非当轮的词要么丢掉,要么当成答错。结果是系统与用户各拿一张不同的进度表:用户以为表已经填完,系统以为才填到第二格。

槽之间常有依赖(先有航班才有座位),这限制的是哪些槽现在合法,不是用户必须按你的顺序说。把依赖误写成线性问卷,会把「座位」问在「航班」之前,也会把已经说了的航班再问一次。帧驱动的做法相反:每句把能解析的槽都收进帧,下一问只针对仍空且已满足依赖的槽。

怎么研究

同一张多槽表,比较固定顺序追问收已给、只问空槽。自变量包括首句提供的槽数、槽的排列是否打乱、以及是否存在硬依赖。因变量是完成轮次、已被填充却被再问的次数、用户改口「我说过了」的次数。

语料切法是看首句的槽覆盖:真实日志里首句带出两个以上槽的比例。实验室脚本若规定「请按提示一项一项答」,会把乱序现象设计掉。标注时把「同一意图的多槽」和「多个意图」分开,前者才是填槽顺序问题。

边界

身份核对先于账户操作这类合规顺序不能乱,乱序只适用于合规已经满足之后的信息槽。硬依赖仍在:没有目的地就问不了途经点。对不熟悉任务的人,一次只问一个反而减轻负担,允许乱序不等于鼓励一句塞满。开放词表槽(地址)和封闭槽(人数)混在一句里时,识别可能只抓住封闭槽,看起来像乱序失败,其实是解析不完整,应再问空着的开放槽而不是从头来。

怎么落地

  • 每轮解析整句,已填且置信足够的槽不再问;提示只针对当前空着、依赖已满足的那一个。
  • 用乱序首句做用例:「四人、靠窗、明天晚上」,不要只用「明天」这一种开场。
  • 依赖写成有向约束(有航班才能问座位),不要写成固定问卷顺序。
  • 验证:准备打乱槽序的首句各若干条。每条跑完后,被再问的已填槽应为零;若系统把后半句丢掉只接了第一槽,乱序就还没被允许。

延伸

  • 同组M2.07.1 流程需覆盖成功、失败与中途退出 · M2.07.2 每个状态都需要退出路径 · M2.07.3 流程图不能替代真实语料验证 · M2.07.5 取消、重来与帮助在任何状态下可用 · M2.07.6 状态数量增长会超出可测试范围
  • 相邻M1.09 上下文保持与指代消解 · M2.13 多意图与复合指令 · M1.01 语音优先的适用场景
  • 站内检索mixed-initiative filling · over-answering · scrambled slots

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/M2.07.4