Answer length should track how certain the answer is

What it is

“Beijing weather tomorrow” has one safe answer; one sentence is enough: “clear, high twelve.” “Where is Yunhaiyao” with two shops in town is not certain enough for a paragraph of explanation, and not certain enough for a single confident pin — it wants a short fork: “two of them — Chaoyang or Haidian?” Answer length scaled to certainty: short when the grasp is high, and when it is low, spend the fewest syllables that lay the ambiguity open. Not always compressed, not always unfolded.

Why it happens

Auditory bandwidth is billed by the second. Extra syllables on a high-certainty proposition keep the line open on a closed question; people barge in or treat the tail as noise. A still-short answer on low certainty hides the ambiguity inside a confident contour and defers the cost of being wrong until execution. Length should track how many live paths remain in the answer space, not how much work the query did: the backend can have run twenty models; if one path remains, speech is still one sentence. Two live paths want a named choice of those two, not a readout of the twenty models.

Forks have a length cap too. Low certainty slides toward “I analysed the following possibilities…” — a monologue pretending to handle uncertainty, spending the seconds the user needed to pick a side. The right lengthening is an answerable structure (two named options, one clarifying question), not more adjectives.

Studying it

Manipulate the answer space: the same question with a unique high-confidence hit, two near-neighbour hits, and a low-confidence unique hit. System output in three length templates (one-shot result, short fork, long explanation). Dependent measures: where barge-in lands, final correct selection, whether people treat the low-confidence one-liner as settled. Independent variables also include whether the contour sounds certain (flat statement versus hedge).

In production, tag turns as unique / multi / low-confidence per skill and measure mean playback seconds. If the three classes last about the same, length is not tracking certainty. Satisfaction is the wrong primary: long explanations can sound thorough while barge-in and error both rise.

Where it stops holding

When the consequence is irreversible (a large transfer, a delete), even a one-path answer may need a confirmation beat — that is consequence, not uncertainty, and a longer explanation is not a confirmation. Entertainment questions are low-certainty by design and people want a stretch; this bill does not apply. “Tell me more” is a grant to lengthen, not the same as the system lengthening because it is unsure. Mapping model confidence straight onto sentence length lies when the model is miscalibrated: a short, overconfident wrong answer is worse than a fork.

Applying it

• Three templates per answering skill: single high grasp → one payload sentence; two or more live paths → a named fork; low grasp and only one path → say the grasp is low, give that path, leave a way to recant.
• Ban long monologue as the handler for uncertainty. Lengthen only by adding a structure the next turn can answer.
• If the fork would have more than two items, filter first; do not turn uncertainty into a spoken long list.
• How to check: the same skill with “one shop” and “two shops of that name.” The first should be too short to barge-in for content; the second should present a fork within two seconds, not a blurb. If the two last about as long, length is not tracking certainty.

Related

• Same group: M3.11.2 Trimmed information still needs a way back in · M3.11.3 Preamble spends the auditory budget before the payload
• Nearby: M2.03 Confirmation Strategies · M2.02 Open and Closed Questions · M3.08 Difficulty of Reading Long Lists Aloud
• Search terms: answer length scaled to certainty · Gricean quantity · uncertainty display