翻译并非本地化：多语言 AI 正面临的文化校准债务违约

一个多语言发布版本，如果只是将英文提示词翻译成 N 种语言，并将英文评估集也翻译成同样的 N 种语言，那它并没有发布一个真正的多语言产品。它只是将同一个产品发布了 N 次，并让所有的失败模式在它自己的仪表盘上变得不可见。该系统虽然表达流畅，但在文化层面上显得格格不入，而团队优化的指标——翻译质量——并不是衡量用户反应的正确维度。

发布当天的明显缺陷通常很小。一位日本用户收到的回复虽然语法正确，但显得生硬无礼。一位印度尼西亚用户发现助手以一种欢快直接的语体说话，听起来却很不礼貌。一位韩国用户收到的建议是围绕个人选择展开的，而提示词其实是关于家庭决策的。这些都不是翻译错误。它们是文化语体（cultural-register）错误，翻译无法修复，且经过翻译的评估也无法检测出来。

必须落地的准则描述起来很简单，但实践起来却很陌生：由当地人员编写的区域原生评估，而不是从英文翻译过来的评估；特定区域的提示词变体，编码了不同于翻译的文化习俗；针对每个区域进行明确的礼貌与拒绝校准步骤，因为以英文为主的 RLHF 安全微调默认值并不能均匀转移；以及尊重当地敬语和姓名顺序惯例的命名实体处理。每一项都是可行的；陷阱在于，大多数团队衡量多语言推广的地方，都看不见这些工作。

翻译流水线隐藏的失败模式

在进行多语言发布时，本能反应是将翻译质量视为产品质量的代名词。这是一个令人欣慰的指标，因为它是可衡量的，BLEU 和 COMET 的数值会产生可预测的变化，而且本地化团队也有一套合情合理的工作流程。但这个代理指标是错误的，因为用户察觉到的失败存在于翻译系统明确试图不改变的语体和规范中。

考虑一个最简单的例子。一个英文银行助手被训练为用一种业务化、略微非正式的确认方式（“Sure, I can help you with that”）来回答电汇问题。翻译成日语后，字面对应的表达会变成一种随意的语体，日语用户绝不会对金融机构使用这种语体。翻译成德语后，同样的回复可能显得过于亲近。翻译成巴西葡萄牙语后，与当地服务互动中温暖的规范相比，同样的回复可能显得冷淡。翻译器没有错。错在原文不适合目标区域，而翻译忠实地保留了这一错误。

评估集也继承了同样的错误。翻译后的评估衡量的是模型是否忠实地呈现了以英文为基准的标准答案。它并不评估答案对于目标区域的原生用户来说是否得体。对翻译后的基准测试进行的审计显示，翻译痕迹——专有名词误译、成语流失以及缺乏文化适配——大约占了明显失败案例的 30% 到 60%，而且即使是忠实的翻译也无法捕捉到基准测试需要测试的文化细微差别。团队发布了，仪表盘是一片绿色，而支持邮箱是唯一知道产品表现得不合时宜的系统。

“文化校准”在提示词栈中的实际含义

解决方法并不是在系统提示词中增加一句关于保持礼貌的话。解决方法是将每个区域视为一等公民的部署表面，拥有其专属的提示词变体、评估集和质量标准。

特定区域的提示词变体编码了翻译无法从上下文中推断出的惯例。日语变体规定了敬语等级（通常服务场景默认为 teineigo，正式任务使用 sonkeigo）、姓名处理（姓在名前，不使用西式的“仅称呼名字”的亲昵感），以及比英文默认方式更具歉意和委婉的拒绝风格。韩国语变体在六个语体等级中进行选择，并匹配用户发出的正式度信号。德语变体选择 du/Sie 的界限。巴西葡萄牙语变体则增加了服务语体的温度。这些并不是彼此的翻译；它们是独立的提示词设计，恰好共存于同一个产品中。

评估集必须由当地母语人士编写，而不是从英文翻译而来。这是大多数团队会跳过的步骤，因为它的成本最高。成本是真实存在的，但替代方案更糟糕。较新的多语言基准测试如 SinhalaMMLU、TurkishMMLU 和 HKMMLU 已经摒弃了基于翻译的构建方式，正是因为经过翻译的评估会系统性地评分错误——它们奖励模型生成另一种语言的“英文式”答案，而不是适合当地情况的答案。区域原生评估将揭示翻译后的评估在物理上无法发现的失败，因为在模型看到这些失败模式之前，翻译流水线就已经把它们过滤掉了。

命名实体处理规则具有看似微小实则关键的支撑作用。一个称呼韩国用户为 “Min-jun” 而不是 “Park-ssi” 的模型，犯的不是翻译错误，而是关系错误。在约定俗成使用 “Tanaka-sama” 的日本商业环境中，使用 “Ms. Tanaka” 的模型刚刚传达了一些关于其来源和语体的信息，用户会准确地读出其中的含义，而团队却不会。这些都是本地化风格指南为人类作者编码的细节，它们需要在提示词栈中进行等效的编码——不是作为修饰，而是作为核心行为。

安全默认设置无法跨语言迁移

更难的问题在于，模型本身在它所支持的语言之间的训练并不均衡。生产模型的 RLHF 绝大多数以英语为主。最近的机械论（mechanistic）研究表明，拒绝行为锚定在那些在英语标记（token）序列上能清晰激活的表征上，而随着输入偏向低资源语言，这种表征就会退化。其实际后果令人不安。

在某些非英语语境下，拒绝率大幅下降 —— 关于西非语言的研究报告称，对于英语模型会可靠拒绝的提示词，其拒绝率下降到了 35-55%。同样的效果也催生了一类跨语言越狱（cross-lingual jailbreaks），攻击者将原本会被拒绝的提示词翻译成安全训练覆盖不足的语言。模型的拒绝方向在不同语言中大致是通用的，但它区分有害提示词与无害提示词的能力却并非如此，而差距正是失效产生的地方。

反过来看，同一个模型在某些语言中可能会出现过度拒绝的情况，因为训练数据促使它在目标文化中属于常规的话题上保持谨慎。如果一个模型因为其锚定英语的安全训练缺乏语境，而拒绝讨论某种文化上正常的做法并称其为“不安全”，这与越狱是不同类型的错误，但对用户来说同样显而易见。

这意味着，礼貌与拒绝的校准步骤必须成为每个地区发布的组成部分，而不是一次性的全球微调。团队需要根据本地原生的红队测试集测量每个地区的拒绝率，根据本地原生的良性测试集测量过度拒绝率，并将任何偏离英语基准的情况视为发布阻断因素（release blocker）—— 而不是被接受的退化。这不是一次性的审计。基础模型在变，安全微调在变，每季度重新校准一次比每年一次更接近正确的节奏。

组织失效模式：本地化归属职能错误

产生这种技术债的模式是结构性的，而非技术性的。本地化被视为一种内容职能 —— 字符串翻译、术语表维护、特定地区的文案审核 —— 并与市场营销或产品文案职能相邻。而 AI 提示词栈被视为一种工程职能，归属于模型团队。这两个群体都没有获得授权去编写本地原生评估集、校准每个地区的安全行为，或设计偏离翻译基准的特定地区提示词变体。

结果是显而易见的。AI 团队发布了一个以英语为中心的提示词栈，上面硬套了一个翻译流水线。本地化团队验证字符串翻译是否正确。国际版发布了。每个界面的原生用户很快就注意到了文化语域（cultural-register）的问题，但这些问题被当作零散的支持工单处理，而不是连贯的信号。因为单独阅读时，每个地区的投诉看起来都像是个人口味偏好。一年后，唯一拥有产品在五个地区表现不佳的确凿证据的职能部门是支持团队，而这些数据并不是评估流水线可以摄取的格式。

必须进行的重组是设立一个单一的负责人 —— 称之为 AI 本地化，或文化校准，名称并不重要，重要的是授权 —— 负责各地区的提示词栈、本地原生评估集以及各地区的安全校准。该负责人位于 AI 工程组织内部，并将本地化作为平级依赖项，而不是相反。在“翻译字符串”和“校准模型行为”之间的交接处正是债务积累的地方，它必须由能够兼顾两方的人负责。

分布偏移是该问题的持续版本

即使是一个在发布时做得很好的团队，也会面临该问题的持续版本。各地区的流量构成随时间而变化。发布时日本用户可能占流量的 10%，到第三季度可能达到 25%，随着采用深度的增加，中位数用户的提示词可能会从简短任务转向长对话。六个月前编写的地区评估集所评分的分布已经不复存在了。

处理这一问题的学科与机器学习团队处理任何生产模型偏移（drift）所使用的学科相同：进行生产队列采样（production-cohort sampling），以便评估针对实时分布而非冻结的标准参考集（gold set）进行评分；使用分布偏移检测器，当输入构成超出审计范围时发出警报；以及包含文化语域质量作为追踪维度（而非仅仅凭感觉）的各队列 SLO。架构上的认识是，文化契合度不是团队审计一次就能获得的属性。它是一个输入不断变化的系统的持续属性。

顺理成章的结论是，当各地区的评估集相对于输入分布已过期时，发布门禁（release gate）应阻断部署。目前大多数团队根据总体评估通过率来进行门禁控制；而具备地区意识的版本则会根据针对在一定有效期内更新过的地区评估集的地区通过率来进行门禁控制。如果没有这一点，评估结果可能依然显示为绿色，而底层用户现实已经偏移到了评估从未覆盖的区域，团队只能从流失数据而不是仪表盘中了解到这一差距。

针对下一个语区发布的实用流程

如果目标是在不背负本文所讨论的债务的情况下发布一个新的语区，那么操作顺序比单个步骤更为重要：

• 在提示词（prompt）工作开始之前，由当地母语人士编写一套语区原生的评估集（eval set）。评估集定义了什么是“好”；随后，提示词就有了优化的目标。
• 从零开始设计每个语区的提示词变体，将英文版的翻译仅视为起步参考，而非最终产出。
• 在语区原生的红队测试集和良性测试集上进行礼貌与拒绝（politeness-and-refusal）校准。将任何与英文基准的偏差视为发布阻碍项，并明确决定是修复提示词、更换模型，还是两者兼施。
• 在提示词栈中将姓名和敬语的处理规则规范化，并在评估集中进行验证，而不是在下游的内容审核中才去处理。
• 建立每个语区的遥测数据和 SLO（服务等级目标）。根据定义的有效期刷新评估集，并根据各语区评估集的新鲜度来把控发布闸门。

每个步骤都有一个主要靠翻译的“快速”版本和一个主要靠创作的“真实”版本。发布快速版本的诱惑很大，因为仪表盘（dashboard）的数据会给你反馈。但快速版本的代价最终会由支持团队和长尾流失率体现出来，到那时，修复成本会更高，用户信任也更难重建。

架构层面的认知

多语言 AI 是一个包含翻译子问题的文化校准问题。如果将其视为一个包含文化子问题的翻译问题，这种本末倒置就会产生债务——那些解决了翻译部分的团队会认为工作已经完成，而实际上工作才刚刚开始。

这种观念的重塑对组织架构有深远影响。语区的所有权应属于 AI 工程部门。评估集的编写应在当地完成。安全校准应针对每个语区进行。提示词在不同语区之间应有所演进，而不是简单地翻译。这些想法本身并不新奇；不寻常的举动是将它们视为必选项而非可选项，并建立起让这些要求得以强制执行的评估和发布闸门。

这样做在发布初期看似较慢——每个语区都要多出一轮评估编写周期、一轮校准环节，还要增加专人负责。但在六个月后，当各语区的仪表盘真实反映了用户的实际体验，且支持团队的收件箱不再成为记录文化契合度问题的系统时，这些团队会显得快得多。本文描述的债务是每个多语言 AI 产品默认都会积累的。解决办法就是拒绝这种“默认”。