评审会快结束时，屏幕上的误差曲线还算平稳。有人忽然问：为什么这类用户被拒绝的比例明显偏高？房间里安静了几秒。不是没人关心这个问题，而是此前没人把“谁可能被误伤”写进需求文档。
公平不是模型自带的属性
很多团队把算法公平当成一个可以加装的技术指标，仿佛在损失函数后面补一项，问题就能缓解。实际更接近一组关于“相似的人是否被相似对待”的判断。判断需要上下文：业务场景是什么，错误落在谁身上，申诉渠道是否存在。离开这些，公平很容易退化成一句口号。
模型本身只负责优化被给定的目标。目标里只写准确率、点击率或转化率，差别对待就不会被主动看见。它可能藏在标签里，也可能藏在特征里，还可能藏在“平均表现不错”的汇总数字里。
问题常藏在三个地方
- 标签。历史决策被当作标准答案，模型便学会复制过去的偏好。看似客观的记录，未必是公正的参照。
- 特征。设备型号、使用频率、地区编码这类字段，单独看都合理，组合起来却可能成为身份的代理变量。
- 目标。平均误差下降，不代表每个群体都变好。尾部用户的错误被平均掉，报表上仍然风平浪静。
这三处不是简单的程序缺陷，而是取舍。删掉敏感字段，代理变量仍可能把信息带回来；只做整体评估，局部问题就会被掩盖。算法公平的讨论若停在“去掉某个字段”，往往解决不了真正的分歧。
两种公平会打架
个体公平关心相似个体是否得到相似结果，群体公平关心不同群体之间的错误率是否接近。落到工程上，常见的约束彼此冲突：让各组通过率接近，可能拉大错误率的差距；让错误率接近，又可能改变资源分配。不存在一套放之四海而皆准的配置。
因此，算法公平不是一次性认证，而是持续监测和公开取舍。团队需要说明选了哪条约束、牺牲了什么、由谁承担代价。上线后看分群错误率、申诉记录、人工复核的分布，比追求一个漂亮的汇总分数更有意义。
能提前做的，往往不复杂
在需求阶段写清受影响的人，在评估阶段保留分群切片，在上线后留出申诉和人工复核的入口。这些动作不华丽，却能把“事后追问”变成“事前讨论”。模型不可能完全消除差别对待，但团队可以决定哪些差别不可接受，以及发现后如何修正。
那次评审会没有给出标准答案，只留下一个更实际的问题：如果公平没有被写进目标，它凭什么在结果里出现？