不确定性需被表达而非隐藏
别名: 不确定性表达 · 隐藏不确定 · displaying uncertainty
概念解释
模型对「明天会不会下雨」「这段话是不是同一作者」给出的是分布，界面却常给出一个点：下雨、是。点把其余质量抹掉了。不确定性需要被显示（uncertainty must be shown）说的是：决策用得上的那部分散布，必须作为一等公民出现在结果旁边，而不是等用户自己猜「这像不像在确定」。
隐藏不是中立。不画散布，等于声称散布为零。
机制
人把干净的陈述句读成高确信。这是语言默认，不是用户不理性。生成系统的解码可以在内部保留 logits、熵、集成分歧，但产品管道在最后一步做 argmax 或取众数，再把那一个值排版成答案。内部的不确定在出界时被扔掉。
扔掉之后，下游只能按「已决」来行动：排班、下单、引用。错误被发现时，没有人能指出当时系统其实在两种可能之间摇摆——摇摆从未离开过模型，只是没离开过服务器。Hullman 等人对不确定可视化的论证正是：不画，决策者会用自己的先验去填，而且通常填得过窄。
怎么研究
同一预测，点估计 vs. 带散布的显示（频率条、扇形、预测区间、集合小倍数）。决策任务要有真实损益：是否带伞、是否复核、是否提交。自变量：有无不确定编码、编码通道（位置/色/文字）。因变量：决策校准、过度自信、任务时间。
「用户说更喜欢确定答案」不能当作隐藏的理由。偏好常与校准相反。要报的是决策质量，不是满意度。
边界
散布相对于行动阈值可以忽略时（99% 对 1%，而行动在 50% 处翻转），强制显示会成噪声。娱乐性生成（写一句笑话）没有决策阈值，不确定不是必须编码的对象。安全场景里，把不确定画成「也许安全」可能比隐藏更危险，应改成保守点估计加明确的「未决则禁止」。这条只论证默认应显示；编码的粒度、以及数字精度的骗局，是同组另外两张。
怎么落地
- 凡是用户会拿来做是/否或选谁的输出，附上与该决策同级的不确定标记：可能/较可能/区间，而不是只给一个光秃秃的标签。
- 不要用更粗的描边、更满的进度条去暗示确定——那是在用视觉权重撒谎。
- 内部若根本没有可用的不确定信号，就写「无法估计把握」，不要伪造一条平滑的置信条。
- 验证：拿掉所有不确定编码，问人「系统有多有把握」。若答案集中在极端确定，而你们的模型在该题上熵很高，隐藏已经在制造假点估计。