假设一个招聘筛选模型上线三个月，业务方觉得效率不错，直到有候选人反馈：自己的简历似乎没被认真看过。团队复盘时发现，模型在历史录用数据上训练得很顺，但那些数据本身记录的是过去的偏好。模型没有恶意，它只是把旧秩序压缩成了分数。
这类问题常被归到「算法公平」名下。但真正棘手的不是给模型贴一个公平标签，而是回答：在这个场景里，谁承担了不利结果？什么程度的差异可以接受？由谁来判定？
公平不是一个指标，而是一组取舍
技术社区讨论算法公平，常会列出几种定义：有的要求不同群体获得相近的正向结果，有的要求条件相同时预测一致，还有的关注误差在群体间的分布。它们听上去都合理，却不一定能同时满足。想让通过率接近，可能会改变阈值；想保证条件一致，又可能对历史差异视而不见。
所以，算法公平更像一份需要签字的约定，而不是模型自带的属性。团队得先承认：选择哪种定义，背后是价值判断，不是纯粹的工程参数。把这件事藏进代码里，问题不会消失，只会在申诉出现时爆发。
删掉敏感字段，不等于问题解决
常见的直觉是：把性别、年龄、地域等字段从特征里删掉，模型就公平了。实际没这么简单。邮编可能指向地域，毕业年份可能暗示年龄，行为序列也可能携带群体差异。这些代理变量让敏感属性以间接方式回到模型里。
另一条路是在训练或输出阶段做调整，比如重加权、阈值移动或约束优化。它们有用，但都有代价：可能牺牲一部分预测精度，也可能把差异推到别的环节。公平不是免费的，问题在于代价由谁承担、是否被提前说明。
- 数据层：检查历史标签是否记录了旧偏好，而不是只做清洗。
- 训练层：明确约束目标，记录取舍，不把调参当作中立操作。
- 输出层：保留人工复核和申诉入口，尤其是影响个人机会的场景。
可解释性常被当作公平的搭档。它能帮人发现「为什么是我」的答案有多牵强，但解释本身也可能变成事后合理化。一个模型可以给出逻辑自洽的理由，却仍然建立在有偏差的数据上。解释是入口，不是结论。
把公平放进流程，而不是放进海报
我更愿意把算法公平看作一项持续的组织工作。上线前，明确受影响的人、可接受的差异范围和复核机制；上线后，监测结果分布和申诉内容，定期回头看。它不需要一次性的完美方案，但需要有人对「异常」负责。
回到那个招聘模型的假设场景。团队后来把公平评估和业务指标并列写进上线清单，也保留了候选人申诉通道。模型仍然不完美，但问题变得可见，可以被讨论、被修正。算法公平大概就是这样：不是宣布自己做到了，而是让不同意见有地方落脚。