你一直在忽略的偏见审计：如何为 LLM 流水线构建人口特征公平性

一个团队发布了一项由 LLM 驱动的功能。它通过了安全过滤器，通过了准确性评估。但用户开始投诉。六个月后，一名研究人员运行了一项包含 300 万次对比的研究，发现该系统在输入完全相同的情况下，有 85% 的时间选择了与白人相关的名字，而选择与黑人相关的名字仅占 9%。

这不是安全问题。这是一个公平性问题，两者需要完全不同的工程应对方案。安全过滤器防范伤害。公平性检查衡量你的系统是否能为每个人产生同样优质的输出。一个模型可以满足你所有的内容策略，但仍可能诊断出黑人患者的死亡风险高于同样患病的白人患者，或者为女性生成的简历比男性更单薄。这些差异对于拦截脏话的护栏来说是不可见的。

大多数团队从未构建过第二种检查。这篇文章将探讨你为什么要构建它，以及具体如何去做。

安全过滤器不是公平性检查

这种区分非常重要，有必要明确说明。安全过滤器是推理时的二元门控：根据输出内容决定允许或屏蔽。它针对的是对用户或第三方的伤害——暴力、仇恨言论、CSAM。你通过针对伤害分类法的精确率和召回率来衡量它。

公平性检查则提出了一个不同的问题：在产生输出的前提下，跨人口统计群体的输出质量、准确性和实用性是否相等？你通过比较同一基础任务在不同人口统计层级上的输出质量指标分布（如 BLEU 相似度、ROUGE-L、F1 分数、情感分数、结果率）来衡量它。

这里存在一个讽刺的重叠：安全过滤器本身可能会引入公平性差异。研究表明，内容过滤器对黑人/非洲裔和穆斯林身份信号的误报率增加了 0.45–0.49——这意味着来自这些群体的合法内容被屏蔽的概率更高。你最终可能会得到一个对某个群体过度拒绝而对另一个群体拒绝不足的系统。安全审计发现不了这一点，只有分层评估才能。

根本的工程区别在于：安全过滤器作为门控在请求时运行；公平性检查在离线环境中运行，在专门的评估套件中针对具有代表性的 Prompt 语料库进行。它们属于流水线的不同部分。

看起来像模型错误的失败

来自类生产环境审计研究的统计数据令人震惊。

华盛顿大学研究人员在 2024 年进行的一项研究，使用商用 LLM 对 500 个真实职位列表进行了超过 300 万次简历与职位描述的对比。在 85% 的对比中，系统选择了与白人相关的名字。黑人相关名字：9%。男性相关名字：52%。女性相关名字：11%。在测试的所有模型中，没有一个模型曾偏好黑人男性名字而非白人男性名字。一次也没有。这些是完全相同的简历，完全相同的职位描述，唯一的区别只有名字。

2025 年一项关于医疗背景下 LLM 的系统性回顾涵盖了 24 项研究。其中 22 项（91.7%）发现了可衡量的统计偏差。具体发现包括：GPT-4 为代表性不足的种族群体推荐高级影像检查的频率较低，以及 LGBTQIA+ 患者被转向心理健康评估的频率比临床需要的高出约 6–7 倍。临床细节保持一致，仅身份信号有所不同。

多语言差距甚至更加严重。ChatGPT 在安全基准测试中的无害化得分平均为 85.56%——但在孟加拉语中下降到 62.6%。Vicuna 的整体平均得分为 69.32%，但在孟加拉语中下降到 18.4%。整体表现与最差语言表现之间的差距，是你的全球化产品需要跟踪但几乎肯定没有跟踪的数字。

这些不是微妙的统计人为迹象。它们是大规模、系统性且在不同供应商之间表现一致的。简历研究中测试的每个模型都表现出相同的方向性差异。这不只是某个供应商的怪癖——它是整个行业训练数据和评估实践的信号。

分层评估方法论

核心技术是反事实配对测试。一次只更改一个属性——名字、人口统计信号、语言——同时保持所有其他 Prompt 内容完全一致。针对每个变体、每个 Prompt 收集 20–25 条回复（你需要的是分布，而不是单点估计），然后比较不同群体之间的分布。

第一步：从生产流量中构建你的 Prompt 语料库。 像 BOLD 或 BBQ 这样的静态基准测试只能告诉你模型的一般属性。它们无法告诉你特定功能的失败模式。从你的使用场景中提取真实或接近真实的 Prompt 代表性样本。研究人员已经证明，基准测试结果“可能会高估或低估另一个 Prompt 群体的风险”——特定于你任务的风险特征只有通过你自己的 Prompt 分布才能看到。

第二步：标记具有人口统计敏感性的 Prompt。 并非每个 Prompt 都是公平性测试。要求总结新闻稿的请求可能是人口统计中性的；但要求评估候选人、编写患者评估或生成个性化推荐的请求则不然。将每个 Prompt 标记为高、中或低敏感度。将测量精力集中在高敏感度 Prompt 上。

第三步：生成反事实变体。 对于每个高敏感度 Prompt，创建交换人口统计信号的版本：

• 具有既定种族关联的名字（来自审计研究中使用的已发布名字列表）
• 性别代词和名字的性别关联
• 输入语言（针对多语言产品）
• 问题背景中的身份标记

关键原则：每个变体只更改一个属性。复合更改会干扰你的分析。

第四步：生成输出并测量分布。 通过模型运行每个变体，收集每个变体的多个回复，然后计算：

• 配对变体之间的余弦相似度和 ROUGE-L 分数（输出是否发生了偏离？）
• 情感分数（VADER 或类似工具）以检测语调变化
• 特定任务的质量指标（F1、精确率、BLEU——无论你主要评估使用的是哪种）
• 对于决策类功能：各群体之间的结果分布

第五步：应用五分之四原则。 借鉴自就业歧视法：如果任何人口统计群体的结果率（分数、质量指标、选择率）低于表现最高群体的 80%，这就是一个不公正影响（disparate impact）的警示信号。这是一个二元阈值，而不是梯度——它为工程师提供了一个具体的通过/失败标准。

第六步：统计测试。 对于群体间存在差异的任何指标，运行双样本 t 检验或置换检验（permutation test）。低于 p < 0.05 的差异应触发调查。目标约为 0.001 的情感偏差得分表示语气接近相等。记录效应量（effect sizes），而不仅仅是 p 值——统计学上显著的 1% 差异在操作上可能可以忽略不计；而一个不显著的 15% 差异则可能并非如此。

现有的工具生态

你不需要从零开始构建。目前已经有几个框架实现了上述方法论。

LangFair（开源 Python 库，由 CVS Health 开发）是目前针对 LLM 场景最专业、最对标的工具。它的核心设计原则是 BYOP —— 自带提示词（Bring Your Own Prompts）。你需要输入你的生产环境提示词语料库，而不是静态的基准测试。它提供五个评估类别：毒性（toxicity）、刻板印象（stereotyping）、反事实公平性（counterfactual fairness）、分配性损害（allocational harm）和刻板印象指标。关键类包括：ResponseGenerator、CounterfactualMetrics、StereotypeMetrics、ToxicityMetrics。其中的 AutoEval 类只需大约两行代码即可运行一个两阶段的流水线。此外，它还集成了 LangChain。

Giskard（开源 Python 库）在一个框架中同时处理 LLM 和传统机器学习。它的 LLM 扫描功能（LLM Scan）在检测幻觉、提示词注入和有害内容的同时，也能自动检测偏见。RAGET 功能可以为 RAG 流水线生成对抗性测试集。如果你希望在单一的 CI 步骤中统一公平性、安全性和鲁棒性测试，这是一个不错的选择。

DeepEval 提供了 BiasMetric，可以与 pytest 风格的测试运行器集成。你可以设置阈值、定义测试，并通过 deepeval test run 进行拦截。对于已经在使用 pytest 的团队来说，这是集成到 CI 的最快路径。

Fairlearn（微软开源）最初是为传统机器学习分类器设计的，但可以完美应用于任何产生数值评分或二元决策的 LLM 功能。它提供人口统计学平价（demographic parity）、等化几率（equalized odds）和有界群体损失（bounded group loss）指标。对于具有评分或排序功能的产品非常有用。

HELM（斯坦福 CRFM）是发布前模型级基准测试的标准。在决定使用新的基础模型或切换供应商之前，请运行它。它的刻板印象表征指标会给你一个基准线。

为了监控不同人口统计背景下的毒性，Perspective API 提供了针对特定身份群体的毒性评分。请将其作为内容质量平价检查的一个组件层，而不是作为一个独立的公平性解决方案。

将偏见回归集成到 CI

CI 中偏见回归套件的架构与任何质量回归套件的结构相同，但有一个区别：你运行它时使用的是固定的、版本化的提示词语料库，该语料库在不同运行之间不会改变。这能为你提供可比的基准线。

一个依赖模型的机器学习功能的 CI 流水线应该如下所示：

1. 单元测试（功能正确性）
2. 偏见回归套件（在固定的金丝雀提示词语料库上运行公平性指标）
3. 安全扫描（提示词注入、有害内容）
4. 性能基准测试（延迟、吞吐量）
5. 发布门槛决策

每当模型版本升级、提示词更改和工具 Schema 更新时，都要运行偏见回归套件。存储每个群体的指标时间序列。如果任何指标相对于前一版本的基准线退化超过了配置的阈值，则发出警报。这能捕捉到一种典型模式：模型更新悄悄地改变了人口统计学表现，但并没有改变总体准确率。

在开始编写提示词之前，需定义的发布标准：

• 在所有你认为与使用场景相关的受保护群体中，差异性影响比率（Disparate Impact Ratio）≥ 0.80
• 在性别和种族的反事实配对中，情感偏见得分（Sentiment Bias score）≤ 0.05
• 对于多语言产品：最差情况下的语言质量得分在英语基准的可容忍范围内（根据产品风险而非方便程度来设定）
• 在主要任务指标上，各群体得分没有统计学上的显著差异

这些标准是发布拦截器（blockers），而不是奋斗目标。在部署开始前的功能规格说明书中就定义好它们。那些能尽早捕捉到偏见问题的团队，往往是将人口统计学平价作为发布门槛，而不是作为发布后的调查任务。

交叉性问题

汇总分析总是会漏掉一种失败模式：交叉性损害（intersectional harms）。华盛顿大学的简历研究发现，黑人女性候选人的表现显著好于黑人男性候选人（选择率为 67% 对 15%）。如果只看种族，就会掩盖这一重大差异；如果只看性别，也会从另一个维度漏掉它。

当你设计测试语料库时，要包含组合属性的变体——不仅仅是“黑人名字”和“女性名字”，还要将“黑人女性名字”和“黑人男性名字”作为独立类别。同样的提示词，根据同时出现的统计信号不同，可能会产生截然不同的输出。大多数偏见评估框架会独立运行每个属性的反事实测试。这很有必要，但还不够。

卡内基梅隆大学（CMU）的审计研究揭示了一个相关问题：“在没有场景和人格特质（persona）的情况下对 ChatGPT 进行审计，产生的明显种族偏见较少。” 上下文触发的偏见只出现在特定的提示词框架中。你的金丝雀语料库需要包含你的功能实际处理的高风险场景——如医疗分诊、招聘决策、财务建议——而不仅仅是通用的提示词。

“通过”到底意味着什么

通过你的偏见回归套件并不意味着你的模型是公平的。它只意味着它符合你定义的标准，在你构建的提示词语料库上，在你测量的那一刻是达标的。随着模型更新和生产流量的变化，人口统计学表现会发生漂移。回归套件捕捉的是退化，它并不能永久证明公平性。

每当模型版本变更时，运行完整的套件。每月针对当前的生产流量样本运行轻量级版本，以捕捉分布偏移（distribution shift）。当指标退化时，将其视为生产事故，而不是交给伦理团队研究的研究课题。

那些在生产环境中发现偏见问题的团队——无论是招聘、医疗还是内容生成——之所以失败，很大程度上不是因为缺乏技术方法，而是因为他们将“完成”定义为“通过安全审查”。安全审查是底线，公平性评估才是天花板。大多数已发布的功能目前都处于两者之间，而这个差距是可衡量的。

缩小这一差距的工具已经存在，可以在 CI 中运行，并且对于处于开发中的功能，只需几天时间即可完成设置。你一直在推迟的审计，其实是你一直在跳过的发布门槛。