M2.08.2yes-no confirmation ASR riskdesignresearch

Yes and no get misheard too

Aliases: polarity error · false yes · yes-no misrecognition

What it is

Adding a “is that right?” turn does not lock uncertainty in a box: yes and no have to be recognized too. “That's wrong” heard as “that's right” wastes every earlier slot check and reverses it — a refusal is taken as approval. The confirm turn carries the highest decision weight and often the worst acoustics: short words, barge-in, a grunted reply in noise.

Why it happens

Polarity tokens are short, low-energy, and full of dialect and fillers (mm, yeah, nah, nope, 对, 嗯). They often land inside an interruption, with the first half-syllable cut off. The confirm turn then parks the right to execute the whole task on one low-quality binary. A false yes executes; a false no only asks again. The costs are asymmetric. A false yes on a transfer, a message, a door is unacceptable; a false no is another confirm. Tuning the threshold as if it were ordinary word error trades execution rights for smoothness.

A correction such as “no, the day after” can also be segmented at “no,” dropping the rest. The system thinks it heard only a refusal, and the true value already spoken is gone. Yes/no questions mishear polarity and swallow attached repairs.

Studying it

Measure confusion on polarity tokens in the target noise and device; do not substitute whole-utterance word error. Split dependents into false yes and false no, and weight them by action cost: false yes on irreversible acts is reported on its own. Compare three forms: one-syllable yes/no, mandatory repeat of a key slot, and a keypress or on-screen choice.

Look at barge-in rate and latency on the confirm turn: a very short “mm” is both a habit response and easy to mix with breath or a TV. In the corpus, label “no, it's X” as refuse-plus-repair, not as bare polarity.

Where it stops holding

On-screen yes/no, or phone keypad 1/2, takes polarity out of acoustics and the risk drops. A high-SNR headset and a required full phrase (“confirm send”) can make acoustics good enough. Children and older adults produce even shorter, vaguer polarity tokens; risk rises. Some languages separate yes and no by large syllables, others mostly by tone — a yes/no recognition rate does not travel. Where post-hoc undo has already replaced a confirm, the harm of a polarity miss depends on whether the undo window is still open.

Applying it

  • Do not use a one-syllable yes/no as the last gate on an irreversible act. Switch to repeating a key slot (amount, name), a designated verb (“send”), or a key/screen.
  • Accept “yes” at a stricter threshold than “no”: if unsure, ask again, and change the form to “say send or cancel” rather than replaying the same question.
  • Keep the confirm turn able to hear a full sentence. “No, send it to Dad” should record both the refusal and the repair, not cut at “no.”
  • How to check: in real noise, record “yes / no / mm / no, it's X.” Executions caused by a false yes should be zero. “No, it's X” should land on X, not merely cancel.

Related

  • Same group: M2.08.1 Confirmation can target the recognized string or the action about to run · M2.08.3 A confirm should echo only the risky slots
  • Nearby: C7.03 Types of recognition error · C7.12 Recognition degradation in noise · M3.09 Barge-in and interjection
  • Search terms: yes-no recognition · false accept · polarity error

Cards in the same group

Quick Actions

Share

Share this page

ios_share

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