阈值选择是产品决定而非算法决定

概念解释

模型输出的是分数或概率，把它切成「触发 / 不触发」的那条线是工作点（operating point）。选在哪里，决定谁被打扰、谁被漏掉。这不是训练损失收敛出来的副产品，而是产品要承担的决策：哪一类用户、哪一种后果，被写进默认阈值。算法可以提供曲线，不能代替选择。

机制

交叉熵或 F1 的最优点，对应的是标注分布和对称代价下的统计折中，通常落在 0.5 附近或 Youden 指数最大处。产品面对的分布是现场基率，面对的代价是客服、伤害和卸载，两者都很少写进损失函数。于是出现分工：学习系统负责估计分数的排序质量；产品负责在这条排序上钉一颗钉子。把钉子交给「准确率最高的那个切分」，等于让标注集里的类别平衡替用户做主。阈值还会进入运营：调高可以降低客诉，调低可以声称更灵敏——这些都是产品权衡，会被包装成模型版本号，掩盖真正的决定者。

怎么研究

把同一模型的分数冻结，只扫阈值，画现场基率下的打扰次数与漏检次数。自变量：决策者（算法默认 / 临床专家 / 产品经理 / 终端用户）。因变量：选定工作点、事后后悔、以及跨团队是否能复述「为什么是这个数」。A/B 测试阈值比 A/B 测试模型结构更常被忽略，却更能暴露产品判断。用户是否被允许覆盖默认阈值，本身也是研究问题。

边界

安全认证过的医疗器械可能由标准规定工作点，产品不能自由下移。实时系统有时受延迟约束，只能用固定门限，来不及做代价敏感搜索。用户自设阈值在专家用户那里成立，在大多数消费场景会变成无人理解的滑杆。模型严重未校准（分数不是概率）时，谈「0.5」没有意义，要先校准再谈谁来选切分。

怎么落地

• 把默认阈值写进产品规格，和文案、权限一起评审，不和训练脚本放在同一处无人签字。
• 发布说明里写「灵敏度从 x 调到 y」这类工作点变化，不要只写「模型升级」。
• 给需要的用户一条有限的覆盖（更少打扰 / 更少漏报），并显示当前偏向哪一侧。
• 验证：问未参加训练的团队成员，这个触发门限是谁定的、依据哪一张损失表；答不上来就是算法在越权。

延伸

• 同组：C9.06.1 假阳性与假阴性的代价不对称 · C9.06.3 高后果动作不得由单一传感器判定 · C9.06.4 医疗警报场景通常宁可假阳性也要避免假阴性，消费场景常反之 · C9.06.5 代价不对称应体现为分类阈值的具体取值，而非仅停留在原则声明 · C9.06.6 同一传感器在不同功能上复用时，两个功能可能需要不同的误报容忍取向 · C9.06.7 误报代价的评估需要包含用户信任流失这类长期成本，不只是单次错误后果
• 相邻：C9.12 隐式交互与系统主动性 · C4.24 识别置信度与偏置方向
• 站内检索：operating point · decision threshold · cost-sensitive classification