一次内部评审会上，招聘团队把筛选模型的分群结果投到屏幕上。总体通过率看着正常，拆成两个群体之后就出现了差额。有人主张直接调阈值，把差额压平；有人反问：那些被压下去的人，是不是又成了新的不公平？会议室安静了几秒。这是算法公平最典型的开场——它不是一个算错的题，而是一场关于“谁该被补偿”的争论，只不过争论发生在代码里。
同一个词，几种彼此不兼容的解法
工程团队常用的做法有三种。第一种要求各组通过率相同，简单直接，代价是可能把明显合格的人挡在外面。第二种要求“在同样合格的人里，各组被选中的比例接近”，听起来更讲道理，但它依赖一个前提：我们知道谁真正合格。第三种要求预测分数在各组里的含义保持一致，分数高就是风险低，但对通过率的差额不做承诺。
问题在于，这几条目标在数学上往往无法同时满足。选哪一条，与其说是技术选型，不如说是价值判断——你更在意结果的平均，还是过程的对应，或者单个判断的准确性。这个选择没人能替业务方做。
还有个体公平：相似的人得到相似对待。它听起来最不容易被反驳，但“相似”由谁定义？用哪些特征衡量？把这两个问题摊开，又回到了人的判断。
偏差经常是学来的，不是写进去的
模型学的是历史决策。如果过去的筛选本身就带着倾斜，模型会把这套倾斜学得非常准，甚至比人更稳定地重复它。所以偏差很少是某行代码写错了，它更像是一段被压缩进参数里的旧习惯。
常见的应对是删掉敏感字段。这几乎没用：邮编、设备型号、工作年限的断档、投递时间，都可能成为代理变量，把被删掉的信息重新带回来。字段没了，相关性还在。
能做的，多半是流程上的事
- 先写清楚这个模型替谁做决定、影响哪些人，以及误判的代价由谁承担；
- 记录训练数据的来源与时间跨度，别让几年前的决策习惯继续决定今天的筛选；
- 评估时分组看指标，别用总体数字掩盖局部差异；
- 把阈值和取舍写成书面决定，由业务方确认，而不是留在工程师的默认参数里；
- 保留人工复核与申诉入口，让被拒的人有机会问一句为什么；
- 上线后持续监测数据漂移，因为人群和业务都在变。
关于算法公平的讨论常常停在指标层面，但真正决定结果的是这些琐碎动作有没有人负责。指标可以汇报，流程才需要维护。
有些事情，算法本身解决不了
即使定义清楚了，补偿也会制造新的争议：给某一组降低门槛，另一组会觉得被挤掉。公开评估口径之后，会有人针对口径优化。这些都不是技术缺陷，而是公平本身的成本，需要用沟通和制度去消化。
所以我不太相信“通过一次公平性检测”这种说法。模型上线只是开始，数据会漂，人群会变，一年前合理的取舍，一年后可能已经站不住。把算法公平当成一次验收，它很快会过期；当成一份需要定期重谈的约定，它才可能被守住。