设想一个语音转写工具。它在标准普通话的测试集上表现稳定，团队据此认为可以上线。真正投入使用后，客服组里几位带口音的同事发现，自己说的话被转错的比例明显偏高，得反复手动修改。问题不在于模型“坏了”，而在于评估时看的那个数字——整体准确率——把差异抹平了。这就是算法公平最日常的出场方式：不是系统崩溃，而是某些人在系统里过得比别人费劲。
一个标量，藏住了一群人
工程上习惯用一个数字验收模型：准确率、召回率、误差均值。这类指标的好处是简洁，坏处也是简洁。它把分布压成一个点，于是“整体不错”和“某一部分人 consistently 出错”可以同时成立，而后者在报表上根本看不见。
所以讨论算法公平，第一步往往不是改模型，而是改评估方式：把结果按人群、场景、设备、时段拆开看，看误差是否在某些切片上聚集。分群评估听起来笨拙，却是最有效的一步——它不解决问题，但它让问题变得无法回避。
几种“公平”彼此打架
真正棘手的地方在于，公平不是一个能被优化的单一目标。常见的几种理解本身就互相冲突：
- 不同群体之间的错误率尽量接近；
- 相似的人得到相似的对待，不看群体标签；
- 历史处于不利位置的人获得一定补偿。
在数学上，这几条很难同时满足。你调整阈值让两组错误率靠拢，个体层面的处理就会变得不一致；你坚持对个体一视同仁，群体间的差距又可能原样保留。这不是工程师偷懒，而是目标本身存在张力。选择哪一条，本质上是价值判断，不是技术选型。
不写邮编，模型也会读邮编
很多团队会说：我们没有把敏感属性输进模型。但模型会自己找代理变量。住址、设备型号、输入法习惯、活跃时段，这些字段组合起来，往往足以还原出被刻意排除的那类信息。删掉一列特征，不等于删掉了那列特征承载的现实。
更麻烦的是数据来源。训练语料来自谁、标注由谁完成、标注规范默认了哪种“正常”，这些决定在模型训练之前就已经做出，事后很难纠正。所以事后补救的手段——重加权、调阈值、加约束——能挪动指标，却挪不动数据采集那一刻的选择。
把取舍写在明面上
实践层面，一些做法未必优雅但确实有用：在需求文档里写明系统会影响哪些人、哪些人可能受损；上线前做分群评估，并把切片结果一并存档；给用户留一条人工申诉的通道，而不是只提供“反馈”按钮；在模型卡里写清适用范围和已知失效场景。这些工作不产生漂亮的指标，但它们让算法公平从一句口号变成可追溯的记录。
需要承认边界：技术能做的，是让取舍可见、可讨论、可追责，而不是替人做出取舍。谁的错误更不可接受，谁的便利更值得优先，这类问题没有通用解，只能由具体场景里具体的人来回答。一个团队如果说不清自己的系统对谁更严、对谁更松，那它其实还没有开始处理算法公平，只是恰好还没被问到。