M2.07.4scrambled slot fillingdesignresearch

Slot filling should accept scrambled order

Aliases: mixed initiative · over-answering · unordered slots

What it is

When filling a spoken form, the order slots arrive need not match the designer's question order. “Book a window table for four tomorrow at seven” already hands over date, time, party size, and preference; a machine that still asks date then time is re-asking what it has heard. Scramble is about arrival order of several slots of one intent, not about packing several different jobs into one sentence.

Why it happens

Speech is organized by topic, not by form fields. Before opening their mouth people compress the whole goal in working memory and dump what they can in one go — over-answering. A sequential state machine encodes “now ask slot n”; tokens that belong to another slot are dropped or treated as a wrong answer. The two parties then hold different progress bars: the user thinks the form is done, the system thinks it is on field two.

Slots often have dependencies (a flight before a seat). That constrains which slots are legal now, not the order the user must speak. Writing the dependency as a linear questionnaire both asks “seat” before “flight” and re-asks a flight already given. Frame-based filling does the opposite: every turn harvests every slot it can parse; the next prompt targets only what is still empty and whose dependencies are met.

Studying it

On the same multi-slot form, compare fixed-order prompting with keep what was given, ask only empties. Independents: how many slots the first utterance supplies, whether their order is shuffled, whether a hard dependency exists. Dependents: turns to complete, times a filled slot is asked again, times the user says “I already told you.”

A corpus cut is first-utterance slot coverage: the share of live first turns that carry two or more slots. Lab scripts that say “answer one prompt at a time” design scramble out of existence. In annotation, keep “several slots of one intent” separate from “several intents”; only the former is fill order.

Where it stops holding

Compliance order (identity before account) cannot scramble; scramble applies to information slots after that gate. Hard dependencies remain: a via-point cannot be asked without a destination. For people new to the task, one question at a time can be easier; allowing scramble is not an invitation to cram. When an open slot (address) and a closed slot (party size) share a sentence, recognition may catch only the closed one — that looks like scramble failure but is incomplete parse; re-ask the still-empty open slot rather than restart.

Applying it

  • Parse the whole utterance each turn. Do not re-ask a slot that is filled at sufficient confidence. Prompt only for one currently empty slot whose dependencies are satisfied.
  • Write scrambled first utterances as cases: “four people, window, tomorrow evening,” not only “tomorrow.”
  • Encode dependencies as directed constraints (flight before seat), not as a fixed questionnaire order.
  • How to check: run a set of first utterances with shuffled slot order. After each, re-asks of already-filled slots should be zero. If the system kept only the first slot and discarded the rest, scramble is not actually allowed.

Related

  • Same group: M2.07.1 Happy-path-only flows leave failure and walk-away unspecified · M2.07.2 Every dialogue state needs a way out · M2.07.3 A flowchart is not a substitute for real utterances · M2.07.5 Cancel, restart, and help must work from every state · M2.07.6 State count grows past what you can test
  • Nearby: M1.09 Context retention and reference resolution · M2.13 Multi-intent and compound commands · M1.01 When voice-first is appropriate
  • Search terms: mixed-initiative filling · over-answering · scrambled slots

Cards in the same group

Quick Actions

Share

Share this page

ios_share

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