L3.13.1thumbs measure satisfaction not correctness设计研究
点赞点踩收集到的是满意度，不是正确性
别名: 点赞不是正确 · 满意度反馈 · thumbs up
概念解释
一条事实错误的回复写得很好玩，被点赞。一条正确但啰嗦的回复被点踩。拇指收集的是「这趟体验好不好」，不是「这句话对不对」。满意度不是正确性（thumbs ≠ correctness）要求：把点赞点踩当质量信号时，必须当成偏好与情绪，不能当成事实验收。
没指明位置的负反馈无法定位，是粒度问题。这里连极性的含义都不是对错。
机制
拇指是极低成本的情感控件，调用的是「爽 / 不爽」。正确性是对照外部记录的判断，成本高，而且经常与爽相反：纠正性的、带保留的、拒绝回答的输出更正确，也更不讨喜。训练或产品指标若直接吃拇指，会强化讨喜、惩罚正确。
人也不会在拇指里做分解。一次踩可能是事实错、语气错、太长、不是自己想要的体裁。系统看到的只有 −1。把 −1 当错误标签，是把一束原因压成假的事实验收。
怎么研究
同一批输出，请人点拇指，另请人（或金标准）标对错。报两者相关。自变量：是否有趣、是否啰嗦、是否拒绝了不该答的问题。因变量：拇指与正确性的相关、被赞的错误率、被踩的正确率。
相关接近零或为负，是这条的签名。不要只用「用户更喜欢哪边」当模型选择依据而不拆开正确性。
边界
笑话、文案、旋律没有外部对错，拇指就是合适的目标。封闭对错题若把拇指换成「这对吗」并强制对照，收集的才是正确性——控件已经不是拇指了。专家审核队列可以同时收拇指和正确标签，但训练时必须分通道。这条不处理谁会来点（自选择）。
怎么落地
- 拇指不要直接当事实损失。事实任务用独立的对错通道或核验，不用赞踩去更新「正确性」。
- 界面上把拇指的含义写成人话：「有没有帮到你」，不要写「对不对」。
- 报表拆开：满意度、正确率。不要用一个「质量分」把它们加总。
- 验证：抽被赞和被踩的样本做事实核对。被赞里错误不低、被踩里正确不低，拇指就不是正确性。把损失改成只吃核验过的对错，再看错误率是否下降。