区域分层评估 (Locale-Stratified Evals)：如何捕捉英语测试集无法发现的非英语回归问题

在最近一次 prompt 变更后，你的综合评估分数上升了 1.2 个点。但在同一周，法语查询的 CSAT（客户满意度）下降了 4 个点。这两个数字都是正确的。它们之所以不一致，是因为评估集（eval set）中 88% 是英语，6% 是西班牙语，其余的是长尾语言，其中任何一种语言的流量都不足以触动汇总数据的变化。法语的性能回归就在你的数据中 —— 它只是恰好位于顶级指标（top-line metric）噪声基底以下三个小数点位。

这是我在生产级 AI 系统中看到的最常见的区域漂移（locale drift）形式：不是突然的崩溃，也不是翻译字符串的 bug，而是一种被汇总数据掩盖、并最终在支持队列中浮现的持续性能差距。当巴黎办公室的人转发一张截图时，你已经在那个回归之上又发布了两个 prompt 变更，而二分查找（bisect）的成本需要耗费三个工程师工作日。

修复方法并不是“翻译更多的评估案例”。这虽然有必要，但仅凭这一点只会让仪表盘看起来更好看，而不会让产品变得更好。因为翻译后的评估集继承了原有的所有以英语为中心的假设 —— 包括那些已经失效的假设。正确的做法是按区域对评估报告进行分层，为每种语言校准评审员（judge），按流量份额对回归进行加权，并将每个主要区域视为其独立的准入通道（gated channel）。本文的其余部分将详细介绍这些做法的含义以及它们通常在哪些地方容易失败。

为什么以英语为中心的评估会隐藏非英语的失败

以英语优先的评估集存在结构性盲区，这些盲区在四种独立的失败模式中叠加，其中任何一种都足以掩盖真实的回归。

第一种是 Tokenizer（分词器）不对称。英语中常见的 Latin-1 文本大约以每个单词 0.75 个 token 的速度进行分词；而日语、中文、韩语和阿拉伯语的分词密度通常是这个数字的 2 到 3 倍。逻辑相同的 prompt —— 相同的指令、相同的 few-shot 示例、相同的上下文预算 —— 留给日语查询的实际问题和实际回答的空间要小得多。在被压缩的工作空间内，注意力（attention）退化得更快，指令遵循（instruction-following）变得更嘈杂，你在英语中验证的长上下文行为无法迁移。你的英语评估案例永远不会揭示这一点，因为它们不是那些超出预算的案例。

第二种是 潜空间偏差（latent-space bias）。大多数生产级前沿模型都是在一个以英语（以及长尾的高资源语言）为主的语料库上训练的。其内部表示是英语形状的，非英语查询在进行推理之前通常会经过一个类似翻译的中间步骤。这一步会引入其自身的损失，特别是对于那些通过复合产生含义、而部分无法预测整体的语言 —— 例如日语地名、德语技术复合词、中文的“父母”（父母 = 父亲 + 母亲）。推理质量的下降看起来像是模型“变得更糟了”，但实际上是特定于语言的。

第三种是 指令保持力漂移（instruction-retention drift）。BenchMAX 风格的多语言评估研究中被广泛引用的发现是：英语表现在 6 到 10 轮对话中保持稳定，而非英语表现则会发生实质性退化。模型会更早地丢失约束，更早地忽略格式规则，更早地丢掉人设（persona）。几乎没有英语评估是针对捕捉第六轮指令保持失败而设计的，因为这种失败不会在英语中表现出来。

第四种是 文化和语法渗透。许多英语语境下的约束 —— “以第二人称回答”、“使用友好但不随意的语气”、“直呼用户的名字” —— 在不同语言之间并不能 1:1 映射。日语中“友好但不随意”的语气涉及 prompt 从未指定的敬语选择。韩语中礼貌的第二人称称呼涉及 prompt 从未提及的尊称。模型会选择一些东西，通常是最通用的选项，对于母语人士来说，答案读起来会显得异常僵硬或异常亲昵 —— 但英语评审员（judge）根本无法为此评分。

综合评估分数看不到其中的任何一个，因为它是在对以英语为主的样本进行平均。修复必须是结构性的，而不是统计性的。

区域分层评估集，而非翻译评估集

第一步是停止报告单一的综合得分，开始将每个区域的得分作为准入通道进行报告。这听起来显而易见，但更难的部分在于每个区域的评估集中包含什么。

翻译后的评估案例既是起点也是陷阱。它们保留了英语的逻辑结构，这意味着它们保留了英语的失败模式，而遗漏了特定区域的失败模式。一个关于“预约周四下午 3 点会议”的翻译案例并不能测试模型是否正确处理日语中的“木曜日の午後三時”，因为潜在的歧义（“周四”是指本周还是下周？）是英语式的歧义。同一个问题的日语版本有不同的歧义 —— 绝对时间与相对时间的区别、正式与口语时间表达的选择 —— 翻译永远无法触及这些。

更有效的方法是为每个主要区域建立三层评估集：

• 翻译案例作为基础兜底：捕捉明显的回归和由于分词驱动的长度爆炸。维护成本低，信号弱。
• 母语人士编写的本地化案例：相同的产品领域，相同的任务形态，但用目标语言从零开始编写，以便出现实际的惯用模式、语气选择和文化参考。信号更强，成本更高。
• 从该区域真实用户流量中收集的失败模式案例：日语、法语、葡萄牙语等各个区域的支持票据、低评分对话、被放弃的会话。每个案例都标注了它所防范的失败模式，这样未来的 prompt 变更就不会意外地导致其再次回归。

比例取决于流量。对于占流量 15% 的区域，你可能需要几百个本地化案例加上收集的失败案例。对于占 1% 的长尾区域，翻译层可能是唯一划算的方案 —— 而你也应该坦诚地承认，你对该区域的信心较低。

值得捍卫的一个重大主张是：一个包含 200 个母语编写案例的区域分层评估集，比 2,000 个机器翻译的案例能捕捉到更多真实的回归。原因在于信号密度。翻译案例主要是在重新测试英语的失败模式；而母语编写的案例则测试特定语言的失败模式，这才是回归真正发生的地方。

针对语言区域的评判模型（及其自带的偏见）

评判模型（Judge）是评估流水线的另一半，也是一个更危险的语言区域盲点来源。有两种特定的失败模式会频繁出现。

第一种是翻译腔偏见（Translationese bias）。LLM 评判模型系统性地更偏好机器翻译的文本，而非原生撰写的文本——它们会奖励翻译输出的句法结构，这意味着，如果一个模型在目标语言中生成带有“翻译味”的文风，其得分会高于生成地道原生文风的模型。在低资源语言中，这种情况严重到足以颠覆排名。如果你使用的评判提示词是英文，而候选答案是日文，评判模型会隐式地将日文翻译成英文形式的表征来评分，并且会奖励那些看起来已经很像这种表征的输出。这与你的目标背道而驰。

第二种是跨语言的不一致性。在不同语言中，通过 Fleiss' Kappa 衡量的多语言评判模型一致性平均在 0.1–0.32 之间，其中低资源语言和重推理任务处于该范围的底部。这不只是“校准漂移”，而是评判模型在提供相同数字量表的同时，本质上对不同语言做出了不同的价值判断。你不能将英语中的 7.4 分与越南语中的 7.4 分进行比较，并将差距视为真实的质量差距——两者的量表根本不是同一把尺子。

有效对策：

• 使用目标语言编写的针对各语言区域的评判提示词，并明确基于该语言的语域（Register）和习语期望来制定标准。例如，英语中的“礼貌但不失正式”在日语中应转化为具体的语域指令，并指明具体的敬语级别。
• 针对各语言区域的校准集——每个语言区域包含 20–50 个带有专家评分的固定案例，用于计算评判模型与专家的相关性，并在量表发生偏移时重新校准。
• 分解式评判：将评分细则拆分为语言无关标准（事实准确性、指令遵循、格式） and 语言特定标准（语域、习语、母语自然度）。分别汇报并设立门控。仅通过带有明确标准的提示词脚手架（Scaffolding），就能让 Kappa 值提高约 0.05–0.10，当你的起点只有 0.2 时，这种提升意义重大。
• 母语人士抽样复核：以一定的采样率（例如每个语言区域 5%）对评判分进行人工复核，以便在偏差扩散前捕捉到评判模型的漂移。

一个微妙的观点：即使做了以上所有工作，也不应将不同语言的评判结果作为一个单一数字进行比较。正确的报告形式应该是“该语言区域是否相对于其自身的历史基准发生了退化”，而不是“该语言区域的分数是否低于英语”。

流量加权报告与分语言区域门控

一旦评估集完成了分层且评判模型完成了校准，报告层往往是大多数团队不小心毁掉前期工作的地方。

默认的“所有评估案例的平均值”汇总方式会让非英语区域的性能退化再次沉没于噪声之下，因为每个语言区域的信号会被规模大得多的英语信号所稀释。请用以下两种报告取而代之。

第一种是随时间变化的各语言区域绝对分数。每个主要语言区域一张图表，独立设立门控。法语分数下降 2 分就是法语区域的回归，必须被标记为法语回归，无论英语表现如何。如果任何受监控的语言区域跌破阈值，即便总体指标上升，也不允许发布任何提示词变更。

第二种是流量加权影响。将每个语言区域的变化乘以该语言区域的流量份额。在仅占 1% 流量的语言区域下降 5 分，其影响远小于在占 20% 流量的语言区域下降 1 分。流量加权视图告诉你应该优先处理哪些回归，而分语言区域视图告诉你哪些变更根本不能发布。两者是互补关系，而非替代关系。

另一个值得采用的高阶模式是：生产环境中的特定语言区域金丝雀分片（Canary Slices）。当提示词变更发布时，将每个语言区域的一小部分流量路由到新提示词，持续观察一段时间（例如每个语言区域几小时），并将实时质量信号（重新生成率、点踩率、会话放弃率）与其自身的基准进行比较。某些回归只会在真实流量分布下显现，而金丝雀发布能在影响扩大到整个语言区域前捕捉到它们。

当触发特定语言区域的回归告警时，操作指南包含按顺序执行的三个步骤：首先，通过该语言区域的校准集进行确认，以排除评判模型漂移的可能性；其次，针对该语言区域的评估集（而非汇总集）对提示词或模型变更进行二分查找定位；最后，检查回归是否集中在特定的意图分类（长上下文、多轮对话、重指令）——大多数语言区域回归往往聚集在某一类意图上，而不是均匀分布。

这种规范在实践中容易失败的地方

在基础架构到位后，从业者往往会陷入以下几种模式：

• 各语言区域评估集腐化（Rot）：英语评估集因为每个人都在用而得到持续关注，而法语评估集在第一季度后就停止添加失败案例了。六个月后，法语评估集测试的已是过时的分布。解决方法是制度化各语言区域的失败案例收集节奏——每周安排半小时，由母语人士对该语言区域评分较低的对话进行分类，并将其中一些加入评估集。
• 评判模型升级的不对称性：模型迁移在英语中通过了验证并发布。英语评判模型能很好地处理新模型，但日语评判模型却不行，因为新模型的日语语域发生了偏移。如果每次更换评判模型或被评判模型时都重新运行各语言区域校准集，就能捕捉到这一点。
• 流量占比盲区：团队根据初始流量份额锁定了各语言区域的门控阈值，却忘记了份额本身也是该语言区域产品质量的函数。日语流量一直停留在 3%，是因为日语产品做得烂，这导致它一直处于门控阈值之下，从而使得回归问题始终未被阻断。应定期根据可触达的用户基数（而非仅根据当前流量）重新审视每个语言区域的门控层级。
• 指标聚合优先的文化：即使工程团队已经有了分层报告，领导层的仪表盘仍然只显示单一数字。聚合指标是阻力最小的路径，而一旦它成为核心指标，提示词变更就会再次开始针对它进行优化。最彻底的对策是从门控层完全移除聚合指标——报告中可以显示它，但不允许根据它做任何决策。

总结

区域文化漂移（Locale drift）不是一个翻译问题，而是一个可观测性问题。在可预见的未来，模型在非英语语言中的表现将继续逊于英语 —— 训练数据的不对称、分词器（tokenizer）的不对称以及潜空间（latent-space）的偏见是结构性的，且在目前的扩展轨迹下不会消失。问题的关键在于，你的评估（eval）系统能否在你的支持队列（support queue）爆满之前发现这些差距。

最小可行方案其实很精简：挑选出占流量 5% 以上的两到三个区域，分别为其构建由母语人士编写的、包含数百个案例的评估集，用目标语言编写带有少量校准集的判定提示词（judge prompt），并按区域而非按总体来对提示词的更改进行把控（gate）。这足以在特定区域的回归（regressions）影响到用户之前将其暴露出来。一旦这套架构搭建完成，后续的迭代 —— 失败案例收集（failure harvesting）、分区域金丝雀发布（canaries）、分解式判定（decomposed judging） —— 都将是渐进式的。

心智模型（mental model）的转变在于，不再将非英语视为长尾，而是开始将每个主要区域视为拥有独立质量通道的一等产品界面。英语评估集只是众多评估集中的一个，而不是唯一。总分只是一个参考，而不是准入关卡。