上线评审会上，公平性检查那一栏被打了勾。模型在离线测试里表现稳定，业务指标也符合预期。团队决定先灰度一周。第三天，客服转来几条零散反馈：有用户说自己在某类内容里几乎看不到新功能，也有人觉得自己被反复推给同一类服务。工程侧查了总体点击率和转化率，数字没坏。争论却开始了——指标没坏，为什么感受变差？
这类场景并不罕见。算法公平常被当成上线前的一张检查表，勾完就归档。可模型真正影响人，是在它持续分配曝光、机会、提醒和资源的时候。灰度期尤其微妙：流量小、样本杂、策略还在调，总体均值容易掩盖分层后的差异。一个推荐位在全体用户上看起来均衡，切到新用户、低频用户或某个地域，分布可能已经偏了。
公平不是一个开关
把算法公平理解成“去掉敏感特征”远远不够。性别、年龄、地域这些字段可以直接删，但地址、设备、行为序列、社交关系仍可能间接携带相似信息。更麻烦的是，公平的定义本身会打架。有人希望不同群体的通过率接近，有人希望在被正确识别的人里误差接近，还有人关心最终机会是否均衡。这些目标在同一个模型里未必能同时满足。团队如果不在业务语境里说清楚“我们要防的是什么伤害”，评审就会退化成填表。
我的判断是，公平问题往往不是算法团队单独能解决的。它需要产品定义影响面，运营理解用户感受，合规判断边界，工程实现监测。缺了任何一角，最后都可能变成一句“模型效果还不错”。
灰度期要看分层，不只看大盘
灰度发布像一次小规模的社会实验。模型在真实流量里学习，用户也在对模型做出反应。被反复推荐的人会更活跃，没被曝光的人则缺少反馈数据，下一轮训练继续忽略他们。这种反馈回路不会在离线集里出现，却会在上线后慢慢放大。监测如果只盯总体转化，很难发现某个切片里的机会在收缩。
- 把评估拆到业务相关的分层：新老用户、活跃度、地域、设备能力，而不是只报一个总数。
- 看阈值附近的敏感度：分数微调一点，哪些人的结果会翻转，翻转是否集中。
- 保留可追溯记录：为什么这次灰度调整了策略，谁批准，预期影响哪些人群。
- 给用户留反馈和申诉入口，别把“没有投诉”当成公平的证明。
这些做法不新鲜，难在持续。算法公平更像一项维护工作，而不是一次验收。模型会漂移，业务目标会变，用户结构也会变。今天合理的差异，半年后可能不再合理。与其追求一张永远正确的评分表，不如建立能发现问题、解释问题、修正问题的机制。
差异不等于歧视
也要承认边界。不同群体的需求本来就可能不同，结果有差异不代表一定不公平。关键在于差异是否来自与任务无关的因素，是否被合理解释，是否有机会被纠正。把公平理解成“所有切片结果一样”，反而会逼团队去做表面平均，掩盖真实问题。更务实的做法是：先定义可接受的差异范围，再记录例外，定期回看。
回到那场灰度评审。团队后来补了一层按用户活跃度拆分的监测，也把客服反馈纳入每周复盘。问题没有立刻消失，但至少不再等到上线后靠零散抱怨才发现。算法公平不是让模型变得完美，而是让那些被模型改变的机会分布，始终有人看见、有人负责。