一家公司在招聘后台接入简历筛选模型，原本是为了减少人工初筛的重复劳动。上线几周后，HR发现系统对某些简历的排序很稳定，却说不清理由。工程师查看特征，发现模型用了“通勤距离”“工作年限”“项目连续时长”等看似中性的字段。问题在于，这些字段可能间接携带与岗位无关的信息。算法公平的讨论，常常就是从这种“看起来没问题”的地方开始的。
很多团队把算法公平理解成一个可以在上线前打开的开关：跑一遍偏差检测，改几个阈值，就算完成。实际工作更琐碎。首先要把“公平”翻译成可操作的判断。是对不同群体保持相近的通过率，还是要求相似条件的人得到相似结果？两种目标在真实数据里经常不一致。前者关注群体层面的差距，后者关注个体之间的可比性。选择哪一种，不是公式能单独决定的。
代理变量藏在敏感字段之外
直接删除性别、年龄等字段，并不等于模型不再使用相关信息。地址、学校、消费记录、设备型号都可能成为代理变量。它们与敏感属性相关，又与业务结果相关，模型很容易把它们当作捷径。麻烦的地方在于，代理变量往往有业务解释：通勤距离影响到岗稳定性，设备型号影响内容加载体验。于是，公平性不是简单“删特征”，而是判断这个特征在当前场景里是否站得住脚。
另一个容易被忽略的问题是反馈循环。推荐系统用点击率训练模型，模型又决定用户能看到什么。如果早期流量集中在少数内容上，后续数据会继续强化这种分布。模型并没有主动制造偏好，但它把已有偏好固定下来。类似情况也出现在任务派单中：系统根据历史完成率分配订单，历史数据里的区域差异会被继承。算法公平需要把这种循环纳入评估，而不是只看一次离线指标。
指标冲突时，别急着找一个“正确答案”
在模型评估表里，准确率、召回率和公平性指标经常互相拉扯。提高某一类样本的通过率，可能降低整体校准程度；调整阈值，可能让另一类误判增加。这时常见的做法是寻找一个综合分数，把冲突压成一个数字。但综合分数会掩盖取舍。可行的做法，是把受影响的对象、误判的代价、可接受的误差范围写清楚，再决定阈值。公平不是追求一个抽象答案，而是在具体业务约束下做可解释的选择。
我倾向于把算法公平看作一项持续治理工作，而不是模型交付前的检查项。它至少包括：问题定义阶段明确谁可能被误伤；数据阶段记录敏感属性的代理风险；上线后监控不同群体的误判率变化；保留人工复核和申诉通道。这些动作不炫技，却能减少“事后才发现”的概率。技术团队不必独自承担全部判断，业务、法务和一线使用者都应该参与。
- 先问模型影响谁，再问指标怎么算。
- 把代理变量和反馈循环写进评估表，而不是只删敏感字段。
- 给误判留下可追溯的记录和可到达的人工入口。
回到简历筛选的场景，真正需要回答的不是“模型准不准”这一个问题，而是“被筛掉的人有没有机会知道原因、提出异议”。当系统越来越深地参与日常判断，算法公平就不只是论文里的定义，而是产品流程里那些具体、略显笨拙的安排。