Sahaj Garg on Designing for Ambiguity in Human Input
Every system that takes human input, whether text or voice or both, receives input that has more than one correct reading. Sahaj and I go through where ambiguity comes from, what you can do about it at training time, how personalization changes the calculus, and how to tell whether any of it worked.
Three things worth keeping
The first cut is between ambiguity that is reducible and ambiguity that is inherent. Reducible ambiguity yields to more context, and the categories worth separating are lexical, syntactic, and pragmatic, with voice adding homophones and accent variation on top. Inherent ambiguity does not yield to any amount of context, and treating the two the same is how systems end up confidently guessing.
Personalization runs on revealed preferences rather than explicit feedback: what a user keeps, edits, or throws away says more than a thumbs-up they were never going to click. That behavioral signal is also the antidote to output that regresses to the mean, where a model tuned to be acceptable to everyone writes prose that sounds like nobody in particular.
Surfacing uncertainty is a product decision, not just a modeling one. Flagging every low-confidence span turns the interface into a proofreading assignment, so the useful question is which uncertainties are worth a user's attention. Evaluation follows the same split: offline sets for whether ambiguity was resolved correctly, online signals for whether the resolution held up in real use.