招聘团队把简历筛选交给模型，工程师确认性别、年龄字段没有入模。上线后，反馈却指向某类候选人通过率偏低。排查发现，模型用到的“毕业院校所在地”“工作经历中断月数”与敏感属性相关。字段被删了，偏见没有消失，只是换了一个入口。
这类场景让算法公平变成一个工程问题，而不只是伦理口号。所谓算法公平，常被简化成“不直接使用敏感字段”。可现实中的特征彼此关联，代理变量会把被删除的信息重新带回来。更麻烦的是，历史数据本身记录了过去的筛选习惯，模型学到的“规律”可能只是旧偏好的延续。
公平没有单一开关
做招聘、内容分发、资源预约的人会碰到一组互相拉扯的指标：有的要求不同群体被分到正向结果的概率接近，有的要求在被预测为正向的人里，各群体的实际表现接近，还有的关注个体是否被同等对待。它们在不同数据分布下很难同时成立。选择哪一种，等于选择把哪种误差留给谁。这不是调参能解决的问题，需要业务、法务和产品一起定下可接受的边界。
另一个被低估的环节是反馈回路。模型给出结果，人根据结果行动，新的数据又回到训练集。比如内容推荐里，某类内容被少量曝光后互动偏低，系统减少曝光，后续数据更少，看起来像“用户不喜欢”。这时算法公平不只是离线指标，而是系统在时间里如何分配机会。
把检查写进流程
与其在上线前找一份万能公平定义，不如把检查拆成可执行的动作：
- 记录敏感属性及其代理变量，做去掉与保留两组对照，观察结果波动；
- 按业务相关的人群切片看误差，而不是只看总体均值；
- 保留人工复核与申诉入口，让被影响的人能说明具体情境；
- 定期回看模型输出如何改变后续数据，避免把反馈当成天然标签。
这些动作不华丽，却能让讨论从“模型有没有偏见”落到“哪一类错误可以被解释、被修正”。算法公平也因此不再是一次性验收，而是持续维护。它需要有人对指标冲突做决定，也需要有人对决定留下记录。
回到简历筛选的例子。删掉敏感字段只是起点，真正要回答的是：当模型把某类人挡在门外，企业能不能说清楚依据，能不能让当事人获得一次解释和复核。算法公平的难点，往往不在数学，而在组织愿不愿意承担定义公平的责任。