评审会上，有人调出一张按人群切分的误差表。总体通过率看着正常，某个子群体的拒绝率却高出几个百分点。房间安静了一会儿，问题才被提出来：这算不算不公平？
没有人能立刻回答。不是能力问题，而是「算法公平」本身就不是一次测量就能填满的格子。
指标之间会互相拉扯
常见做法是挑一个量化口径，比如让不同群体的通过率接近，或者让错误率接近。麻烦在于这些口径往往不能同时满足：若各群体的真实标签分布本就不同，压平通过率差距，就会在错误率上留下新的差距；要求召回一致，样本基数小的那一边又会随阈值剧烈波动。
所以做这件事不是寻找一个正确指标，而是先承认取舍，再把取舍写清楚：这套系统服务谁、更容忍哪一类错误、为什么。写不清楚，后面的讨论只会绕回原点。
代理变量比显式字段更难处理
很多人以为把敏感字段从特征里删掉就干净了。可邮编、设备型号、使用时段、历史行为，都可能间接携带同样的信息。删字段只是让它变得不显眼，模型照样能从别处学到。更实际的做法，是在训练完成后按子群拆开看表现，而不是在特征列上做表面处理。
上线之后才是主要战场
一次性验收最容易给人安全感，也最容易失效。用户结构会变，业务规则会变，模型和它影响的人还会互相塑造——被拒的人不再回来，留下的样本越来越像“本来就该被通过的人”，误差表于是一年比一年好看。这种自我强化的循环，离线评估里看不见。
因此算法公平更接近一项运维工作：固定口径的定期切片、异常时能回滚的阈值、以及清楚知道什么时候该把判断交回给人。它需要的不是一次签字，而是有人长期负责。
也要承认它解决不了什么
公平不等于合理。一条规则本身有问题，把偏差磨平只是让错误分配得更均匀。有些决策不适合交给模型；有些适合，但需要人工复核兜底。给出一条可解释的申诉路径，有时比再调一版指标更有用。
回到那间会议室，比较务实的结论是：记录这次差距、写明当前口径、约定下次复核的时间。不漂亮，但可执行。算法公平不是发布前的那道章，而是一串需要持续有人回答的追问。