LLM性别偏见藏在prompt写法而非提问者身份

LLM 的性别偏见原来不在我们一直关注的地方。一篇 8 月 13 日发表在 arXiv 上的论文，It's How You Ask: Gender-Associated Linguistic Bias in LLMs，作者 Katherine Van Koevering 和 Anjalie Field，揭示了一个比名字替换测试更令人尴尬的事实：在提示词中放入女性名字什么也没改变，但以委婉、礼貌的语域来写作，却产生了大量且一致的差异。

我想论证，这一发现的意义远不止性别——如果你用 LLM 开发了任何产品，这个问题现在成了你必须修的 bug。

🔍 论文实际测量了什么

作者跨四个模型、三种文档类型测试了提示词，变化的是语言语域，而不是用户声明的身份。他们观察的特征是社会语言学家长期以来与女性英语 speech 相关的那些：

Hedges（模糊限制语） — "I think maybe"、"sort of"、"just wondering if"

Tag questions（附加疑问） — "…that would work, wouldn't it?"

Collective reference（集体指代） — "we should"、"our team needs"，而不是"write me"

带有这些特征的提示词得到的回复更短、更简单、更不正式，且在控制提示词复杂度后效果依然显著。所以这不是模型正确读取了一个更模糊的请求并给出了一个更模糊的回答。

核心结论：模型不是在身份层面做区分，而是在风格层面做区分——而风格与身份相关，产生了相同的结果，同时通过了你所运行的所有名字替换公平性测试。

🌐 为什么斯里兰卡英语直接处于冲击范围

这里是我停下来重写自己提示词模板的部分。

论文标记为会受到惩罚的语域，差不多就是斯里兰卡职业英语的默认礼貌语域。想象一封来自科伦坡办公室的典型邮件是如何开头的：

I was just wondering if you could kindly help me with a small thing.
We were hoping to maybe put together a short proposal, if that's okay?

两句话里就有三个模糊限制语、一个集体指代和一个软化词。没有人这样写是因为他们不确定。他们这样写是因为在斯里兰卡英语中，直接说"Write a proposal."读起来是不礼貌的。

论文本身的表述是，这些特征是文化嵌入的，且超出有意识的控制。这就是关键所在。如果 workaround 是"just write more assertively"，那这个 workaround 就是在要求人们转出他们自己的方言来获得其他人默认就能得到的服务。对于在康提写奖学金申请的学生，或向海外客户提案的自由职业者，这是一种真实存在却看不见的税。

我没有看到专门针对非母语或南亚英语语域的数据，论文也没有声称测试过这些。所以把这作为我的推断，而非他们的发现。但机制可以很好地泛化：如果礼貌标记会降低输出质量，那么每一种高礼貌度的英语变体都会受到影响。

⚡ 为什么"加一条 system prompt"解决不了问题

大多数基于 API 构建的人的本能是在指令层打补丁：在后面追加"regardless of phrasing，以同样的严谨态度对待所有请求"。

论文关上了这扇门。它报告这些语言特征编码在 transformer 早期层中，且与其他特征纠缠在一起。通俗地讲：

语域信号在很早的地方就被捕获了，远在你任何 system prompt 试图引导的方向之前。

它是纠缠的——你无法干净地隔离并压制"hedginess"，而不连带压制这些表示所携带的其他东西。

所以缓解必须发生在训练阶段，或者完全在模型之外——在你的应用层。

第三个选项是斯里兰卡小团队唯一能用的。这没问题，因为第三个选项也是最便宜的。

🛠️ 如果你用 LLM 开发功能，实际上要构建什么

具体来说，在用户文本和模型之间加一个提示词 normalization 步骤：

一个仅用 regex 的 normalizer 能让你出乎意料地走很远。 stripping 一个固定的 opener 列表（"I was just wondering if"、"would it be possible to"、"sorry to bother you but"），每个请求零成本，且完全可审计——在调试为什么某个用户的输出看起来很薄时，这比优雅更重要。

如果你想在接入任何东西之前 sanity-check 自己的措辞，我们的 AI Prompt Formatter 可以把粗糙或过度软化的笔记转成直接指令，Word Counter 足以测量同一请求两种措辞之间的回复长度差距。这就是完整的测试，而且零成本。

今天运行一次：拿一个你应用中的真实提示词。写两遍——一遍委婉，一遍直接。两个都发出去。数每个回复的词数。如果差距很大，你就已经把这个 bug 发版了。

💡 这对你意味着什么

如果你在工作中使用 LLM： 你可能仅仅因为礼貌就在丢弃质量。对模型直接，对人礼貌。它们是不同的受众。

如果你基于 API 构建： 名字替换公平性测试不再是你产品平等对待用户的充分证据。把语域加入你的 eval 集合。

如果你教课或带人： 告诉学生"prompt 更好"是公平的建议，但要诚实——你在教的是一种方言，不是一项技能。

这个结果令人不舒服的版本是：业界标准化的公平性检查测试的是那个最终证明无关的变量。名字容易测试，所以我们测了名字。语域难以测试，所以我们基本没测。

有用的版本是：修复在一个两人的团队、一张免费层 API key和一个下午的范围内。normalize 输入，测量输出，上线。你不需要等模型提供商替你解决。