一次内部评审上，有人问：这个版本的效果算不算“够好”。工程师给出一组数字，会议室安静了几秒——因为所有人都清楚，平均数好看，不代表每个人都被照顾到。带口音的用户、用旧设备的用户、在嘈杂环境里说话的用户，他们的错误率并不在那张表里。
这就是算法公平常被讨论的起点：它很少表现为明目张胆的歧视，更多时候表现为“对某些人稍差一点”，而且差得不容易被看见。
公平不止一种写法
做过模型的人大概都遇到过这种僵局：两种同样被称作“公平”的约束，落到同一个模型上会互相冲突。一种思路要求相似的人得到相似的对待，另一种要求不同群体在错误率、通过率上大致持平。前者看重个体，后者看重统计。真要同时满足，往往得让出一部分准确率，甚至在某些情形下根本无解。这不是工程没做好，而是定义本身在冲突。
所以讨论算法公平，起点往往不是调参，而是先问：我们说的公平，是哪一种？由谁来定？
偏见会换个名字留下来
比较常见的做法，是把性别、年龄、地域这类属性从特征里删掉。但删掉之后，模型仍然可能通过邮编、设备型号、活跃时段、表单填写速度这些看似中性的字段，把被删掉的信息重新拼出来。这类字段叫代理变量。它不写在需求文档里，也不违反任何一条代码规范，却让“我们没有使用敏感字段”这句话变得没什么说服力。
更实在的做法，是把敏感属性保留在评估环节，只是不让它进入模型——用它来测量差距，而不是用它来做决定。
记录比承诺管用
算法公平很难靠一次审查解决，因为它会随着数据漂移、业务调整、用户结构变化而慢慢走样。如果只在立项时评估一遍，两年后大概率说不清当初的结论还成不成立。
- 把训练数据的来源、时间范围、已知缺口写清楚，别只写“经过清洗”；
- 把评估用的指标和分组方式固定下来，换指标要留痕；
- 给例外留一条审批路径——某些场景下按下不发布，需要有人签字；
- 定期重跑，而不是等出了问题再查。
这些做法听起来笨，也拿不出漂亮的成果，但它们能保证：问题被发现的时候，还有人愿意认账。
不是所有差距都该被抹平
也得承认另一面：差距不一定等于不公。如果两个群体的真实分布确实不同，强行把指标拉齐，可能反而扭曲结果。比如在内容推荐里，用户偏好本来就分散，把曝光比例调到一致，未必是想要的结果。
所以算法公平更像一个持续的协商过程，而不是一次交付的功能。它需要产品、法务、工程和业务坐到一起，把“我们能接受多大的差距”“这个差距由谁承担”讲明白。技术能提供测量手段和约束条件，但测量什么、容忍到什么程度，属于价值判断，得由人来做。
回到开头那场评审。真正难的不是把错误率降下来，而是决定降给谁、代价由谁付。这个问题没有标准答案，但把它写进流程、写进文档、写进每一次上线前的讨论，本身就是一种进展。