跳到主要内容

多语言评估成本放大效应:为什么七个语种的成本不只是 7 倍

· 阅读需 16 分钟
Tian Pan
Software Engineer

在国际化发布的财务规划电子表格中,有一个清晰的项目:“将评估覆盖范围扩展到七个新语言区域 —— 假设为当前评估成本的 7 倍。”英语评估套件耗时两周,花费 4 万美元构建,因此七个语言区域将花费 28 万美元和一个季度的工程时间。CFO 签字了。产品 VP 签字了。发布启动了。

六个月后,实际的评估账单已经突破 31 万美元,团队仍在搭建最后两个语言区域。标注供应商在葡萄牙语(巴西)人员库中已经换了三批人,因为前两批产生的人员间一致性(inter-rater agreement)分数,任何诚实的审查都会称其为随机。德语裁判模型(judge model)在相同内容上的评分比英语模型低 6% —— 团队最初将其解读为德语模型的退化(regression),直到人工审核发现裁判模型本身才是退化的根源。评估负责人每周要花 40% 的时间处理一个没人预算过的问题:我们如何知道语言区域 A 的通过率确实比语言区域 B 差,而不是因为跨语言区域的测量比差距本身的噪声更大?

电子表格使用的算法是:每次评估的 token 数 N × 语言区域数 L × 每个 token 的标注成本。实际适用的算法更接近 N × L1.3,再加上根本没有出现在曲线上的元评估(meta-eval)成本,因为没有人将其列入清单。这种放大效应是真实的、结构性的,如果一个组织在承诺本地化路线图之前没有对其建模,它发现这一点的路径将和发现其他未建模成本的方式一模一样:通过季度复盘页面,CFO 会问哪一项数据出错了。

翻译买不来你以为能买到的东西

获得 N 个语言区域评估覆盖的最便宜路径是翻译英语评估套件。供应商可以对提示词和评分量表(rubric)进行机器翻译(MT),人工审核员再进行清理,这样你就能以大约 30% 的从头编写成本获得 N 套评估套件。每个构建国际化 AI 功能的团队都会首先尝试这种方法。大多数团队在第一个月内就会发现,这条捷径买到的是数字,而不是信号。

核心问题在于,经过翻译的评估项评估的是错误的东西。一个从英语翻译成葡萄牙语(巴西)的选择题,主要衡量的是模型的翻译流畅度,而不是它处理巴西用户实际发送的查询的能力。这些问题的校准基于美国的教育框架,干扰项中蕴含的文化假设是美国的,而巴西重要的失败模式 —— 不同的正式语阶、不同的命名惯例、与欧洲葡萄牙语相异的地区词汇 —— 对于针对英语分布编写的评估项来说是不可见的。最近的基准测试(如 INCLUDE)通过采用本地编写的区域知识问题而非翻译来指出这一点:翻译基准与本地原生基准之间的差距不是几个百分点的噪声,而是本质上不同的信号。

更糟糕的是,翻译后的评估套件系统性地低估了你最需要捕获的失败模式。英语评估拥有一个越狱提示词、边缘情况格式化请求和对抗性输入语料库,这些都是几个月来从英语生产流量中收集的。这些都无法直接翻译。巴西用户有他们自己的越狱习语、他们自己的格式化预期(日期顺序、货币位置、地址格式),以及他们自己的礼貌式祈使句结构,模型需要理解这些仍然是祈使句。翻译英语对抗集给你的是披着葡萄牙语外壳的英语对抗样本 —— 这是一种有用的冒烟测试,但不是一种能捕捉到该语言区域实际挑战的评估。

经历过这种惨痛教训的团队会经过三个阶段。第一阶段:发布翻译后的评估,获得看起来合理的通过率,发布功能。第二阶段:本地原生支持开始反馈评估套件从未标记过的投诉。第三阶段:拆除翻译后的评估,从本地原生编写重新构建,每个语言区域的成本大约等同于原始英语套件的成本 —— 也就是电子表格原本试图避免的成本。捷径并不是捷径;它是一份延期账单,在第一波负面评论出现时到期了。

定向语言区域裁判与 Fleiss' Kappa 底线

LLM-as-judge 是英语评估的成本控制本能:与其支付标注员每项 4-12 美元来根据评分量表打分,不如支付每项几美分让 LLM 裁判来做,并根据一小部分人工标注的黄金标准集(gold set)进行校准。这种经济模式在英语中行得通,因为裁判模型已经看过了足够的英语指令遵循示例,可以进行合理的校准,而且校准集构建成本低廉。

多语言环境打破了这两方面的平衡。最近的测量显示,多语言 LLM 裁判在 25 种语言的测试中,评分者间的一致性 Fleiss' Kappa 仅为 0.3 左右,这属于“仅比随机一致好一点点”的范畴。在低资源语言上性能急剧下降,即使在高资源语言上,裁判的失败模式也与人工标注员不同 —— 这意味着你的裁判不仅仅是人工标注员的噪声版本,它在不同语言区域、不同方向上的偏差也是不同的。一个在葡萄牙语中系统性地过度肯定流畅度,而在日语中又低估语义准确性的裁判,并不是一个带噪声的单一裁判;它是披着风衣的七个不同裁判,而你想要进行的跨语言区域比较在结构上是无效的。

缓解措施不是放弃 LLM 评判 —— 纯人工路径不符合预算 —— 而是接受裁判校准现在是一个特定于语言区域的工作流。每个语言区域都需要自己的黄金标准集、自己的每项评分量表校准测量、随着模型和提示词演进而更新的频率,以及在单一裁判方差过高而无法做出校准决策时的集成策略(ensemble strategy)。电子表格将其视为固定设置成本(构建一次裁判,随处运行)的支出,现在变成了随 L 规模化的特定语言区域变量成本,且是在标注成本本身之上的。

如果组织不将“裁判需要校准”与“裁判已校准”区分开来,就会通过一种看起来像模型改进的退化来发现这种差距。新模型上线,德语裁判说质量提升了,发布继续进行,三周后支持工单却显示质量下降了 —— 因为裁判的偏差在某个对德语用户无关紧要的维度上向新模型的风格习性发生了有利偏移,而它在某个至关重要的维度上却停止了对退化的察觉。

没人预料到的元评估 (Meta-Eval) 成本

这是成本曲线打破 N×LN \times L 线性关系的地方。你有七套评估套件。每套套件都是本地编写、本地评判、本地标注的。巴西的租户 A 达到了 87% 的通过率,德国的租户 B 达到了 81%,日本的租户 C 达到了 74%。产品经理会问一个显而易见的问题:是日本的用户体验更差,还是日本的评估更难?

这就是元评估(meta-eval)问题,从结构上讲,它是一个与各语言区域评估完全不同的问题。要回答这个问题,你需要一个校准层来比较这七个地区的评分标准,这意味着要么需要一个统一的人类专家小组对所有七个地区的样本进行评分(这需要聘请精通多种语言的标注员,而这类人才既稀缺又昂贵——“精通日语、葡萄牙语和德语的技术标注员”池子基本是空的),要么需要一套跨所有地区翻译的合成锚点集(synthetic anchor set),即使如前文所述,翻译后的评估项信号会有所损耗,它也能为你提供相对难度的信号。无论哪条路径都很昂贵,答案也只是近似值,而没有为此提供资金的组织最终会得到七个无法比较的计分板,以及一个倾向于关注哪个地区的数字恰好最高的一届领导团队。

元评估的成本扩展性比各语言区域评估更差,因为比较空间是 L 选 2,而不是 L。两个地区的发布只需要辩护一次比较;七个地区的发布则有 21 次比较,而忽略其中大部分比较的团队实际上是在默认一种“我们不比较各地区”的立场,而第一次跨区域高管审查就不会接受这种立场。元评估的诚实版本类似于“我们每季度针对一个多语言锚点小组对七个地区进行抽样,地区之间的校准偏差为 X%”。构建这种机制需要 6 个人周的初始设置,加上一笔没人列入清单的持续标注支出。

做得好的团队通常会建立一种规章,将元评估列为与各语言区域评估不同的预算类别:设立元评估工程师岗位,建立具有自身更新频率的元评估数据集,以及一种能够区分“地区 A 的表现不如地区 B”和“地区 A 的评估比地区 B 的评估更难”这两种主张的领导层决策仪式。不为这种仪式编列预算的组织最终会在产品评审中非正式地进行争论,元评估工程师每次都要扮演反面角色,并在两个季度内精疲力竭。

群体偏移是个别地区的,而非共享的

单语言生产中的评估更新频率大约是每季度一次:每季度,评估工程师都会审核线上分布,重新检查评估集是否仍然符合生产流量,并更新累积了偏移的项。更新成本大约是原始构建成本的 10-20%,并在全年内很好地摊销。

在多语言生产中,更新频率并不能简单地乘以 L,因为每个地区的群体偏移(cohort drift)是按不同步调发生的。日本的群体可能在三个季度内保持稳定,然后当一个主要的竞争对手在当地市场推出时发生剧烈变化。巴西的群体可能会随着新功能的推出而每个季度都发生波动。德国的群体可能会缓慢偏移,但其维度(正式程度、技术领域分布)与英语群体不同。每个地区都需要自己的偏移检测、自己的更新频率和自己的单次更新成本——而且偏移最快的地区恰恰是标注员池最小的地区,这意味着在最需要更新的地区,更新的边际成本最高。

一个遇到重大偏移事件并需要在季度周期之外进行全面更新的地区,会导致构建成本激增。没有为这种激增预留预算的团队,要么基于过时的评估进行交付——这是导致未察觉的回归(regressions)的必经之路——要么从另一个地区的周期中挪用预算,打破了国际发布本应遵循的公平对待承诺。

这里的规章是将每个地区的评估新鲜度作为一个跟踪指标,设立关于每个地区“自上次偏移审计以来的周数”的 SLO,并为非计划内的更新设立预算储备。将更新视为统一频率的组织会在一年内发现,用户抱怨最响亮的地区,恰恰也是评估集已经过时 12 个月的地区。

电子表格遗漏的人力模型

标注成本是大多数电子表格能算对或接近算对的项目。电子表格几乎总是算错的成本是标注员管理成本。通过一个供应商管理一个由 50 人组成的单一英语标注员池是一个项目经理的兼职工作。通过三到五个供应商(因为没有一家供应商能在所有七个地区都有良好的覆盖,特别是在亚洲市场)管理七个由 50 人组成的本地原生标注员池,则是一个项目经理的全职工作加上一个标注质量工程师的半职工作。

电子表格视为零的各地区成本包括:主要供应商缺乏标注员池时的供应商入驻、时区感知的 QA 调度(以便在没有 24 小时延迟的情况下回答标注员池的问题)、供应商质量监控(在产生一个季度不可用的标签之前发现标注员池在评分者间一致性方面的偏差),以及特定地区的隐私审查——GDPR 对德国用户数据标注的规定与 LGPD 对巴西数据的规定不同,也与 APPI 对日本数据的规定不同,标注员合同必须体现这一点。

这些成本随着 L 的增加大致呈线性增长,直到你遇到监管复杂性边界,之后它们将呈超线性增长。第七个地区的成本不是第六个地区的 7/6;而是 7/6 的成本加上第七个隐私制度增加的任何成本,根据地区的不同,这部分成本本身可能会超过标注成本。一个进入具有严格数据驻留要求的市场(欧盟部分地区、拉美部分地区、以及团队必须完全使用本地驻留标注员池的中国)的团队会发现,每个地区的成本主要由合规和运营主导,而非标注本身。

在本地化路线图承诺之前必须落地的人力模型规章不是“我们将为每个地区增加一名评估工程师”——那是过度配置——而是一个分层模型:一名横向跨地区扩展的评估项目经理,各地区特定的评估质量负责人(通常是每个地区 0.5 个 FTE,从内部支持或 i18n 团队中寻找),一名作为单一共享角色的元评估工程师,以及一个介于工程和采购之间的供应商管理职能。该人力模型的成本是真实且持续存在的,并且不在发布电子表格中,因为发布电子表格将评估视为一次性构建成本,而不是稳态运营成本。

架构层面的认知

在承诺国际化上线之前,AI 功能团队必须意识到:多语言生产环境中的评估成本 (eval cost) 并不是一个简单的按语区重复的问题。它实际上是三条相互叠加的不同成本曲线:随语区数量 L 呈近线性增长的各语区标注与评判成本;在对比空间内随 L2 增长的跨语区元评估 (meta-eval) 成本;以及随 L 线性增长、直到触及监管边界并发生跳变的运维复杂度。电子表格中那项 “7 倍” 的预算大约只涵盖了第一条曲线的一半,而完全忽略了另外两条。

那些在国际化上线中幸存下来且没有发生评估债 (eval-debt) 爆炸的团队,在做法上有三点不同。首先,他们从第一天起就将元评估作为一个独立的预算项,指派专门的元评估工程师,并在规划阶段确保每季度的执行频率。其次,他们将标注员池 (labeler-pool) 的健康状况建模为带有 SLO 的各语区运维指标,而不是简单地假设 “标注员正在工作” —— 一个悄然失效的标注员池的代价并不是标注费用的损失,而是因为评估漏掉而上线的回归 (regression) 问题。最后,即使面临上线压力,他们也拒绝在各语区评判器 (judge) 未经本地编写的黄金数据集 (gold set) 校准前上线新语区。一个配置了未经校准的语区评判器的功能,其质量基准是处于未受监控状态的,而生产环境中未受监控的功能会向团队无法察觉的方向漂移,直到客户支持的收件箱被投诉填满。

在能够准确预测账单的版本中,国际化上线电子表格中那行 “7 倍评估成本” 应该被改写为:“L1.3 的标注成本,加上各语区校准支出,再加上元评估项目和监管储备金。” 如果电子表格没有这样写,那么这次上线就等同于背负了评估债,其增长速度将在四个季度内超过评估团队的人员增长速度 —— 率先撞上这面墙的团队,会通过那些无法解释的支持工单以及无法再自圆其说的跨语区对比,意识到那一刻的到来。

References:Let's stay in touch and Follow me for more thoughts and updates