多语言质量悬崖：为什么你的 LLM 在英文中表现出色，却在其他语言中悄然失效

你的 LLM 通过了你投喂的所有评估。延迟很稳定，准确率看起来不错，团队充满信心。然后一个开罗的用户提交了一个 bug：结构化提取返回了格式错误的 JSON。首尔的一名开发者注意到，助手在几轮对话后就开始忽略复杂的指令。孟买的一名产品经理意识到，聊天机器人的摘要是完全错误的——虽然微妙，但始终是错误的。

这些都没有在你的基准测试中显现出来，因为你的基准测试是用英语进行的。

这就是多语言质量悬崖：一种剧烈的、系统性的性能下降，而且对于发布 AI 产品的团队来说，这种下降几乎普遍是不可见的。差距并不微小。在长多轮对话中，阿拉伯语和韩语用户在任务中的准确率约为 40.8%，而英语用户则为 54.8%——这 14 个百分点的差距会随着每一轮对话而叠加。对于结构化编辑任务，同样的差距会扩大到灾难性的程度：32–37% 的准确率，而英语表现则是可接受的。用户能感觉到这一点。你的仪表盘却感觉不到。

为什么英语占据主导地位而其他语言却受损

根本原因很简单：LLM 是在互联网上训练的，而互联网绝大部分是英语。GPT-3 的训练语料库中英语 token 占比为 92.65%。LLaMA 2 为 89.70%。即使模型扩大了语言覆盖范围，基础分布也从未发生足以消除差距的改变。

这种不平衡贯穿于模型开发的每一个阶段。预训练赋予了模型对语言模式、语法和世界知识的基础理解。当 90% 的信号是英语时，模型会为英语建立强大的内部表示，而为其他语言建立的表示则更弱、更脆弱。当用户用阿拉伯语写作时，模型是在一个稀疏得多的语言版图上运行的。

指令微调（Instruction-tuning）使情况变得更糟。即使是多语言指令数据集也表现出极端的英语偏差——不仅在数量上，而且在复杂性上。非英语示例往往更短、更简单，且不能代表用户在这些语言中实际运行的任务。模型学会了很好地遵循详细、细致的英语指令。它在其他语言中只是学会了模仿类似的行为。

分词器（Tokenizer）是另一个复合因素。在以英语为主的语料库上训练的子词分词器会剧烈地拆分非拉丁文字。表达相同的语义内容，阿拉伯语需要的 token 数量大约是英语的 3 倍。一些印度语系和东南亚文字的倍数甚至达到 12 倍。这不仅是成本问题——它直接降低了注意力机制的质量。更多的 token 意味着需要追踪更多的位置，模型也更有可能丢失三百个 token 前所述的约束条件。阿拉伯语的长对话会碎片化为数千个 token，而同等的英语对话只需几百个 token 即可表示。

最后一层是研究人员所说的“语义吸引子”（semantic attractor）效应。当多语言模型处理非英语输入时，它内部会翻译成英语，用英语推理，然后再将输出翻译回来。每一个翻译步骤都会引入损失。模型并非原生用地阿拉伯语或日语进行推理——它是在模拟英语推理的翻译，而这种模拟会随着任务复杂度的增加而退化。

评估盲点

大多数团队没有发现这一点的根本原因：他们的评估套件是由说英语的工程师为说英语的利益相关者用英语构建的。

超过 75% 的主要 LLM 基准测试是以英语优先设计的。非英语评估（如果存在的话）通常是通过翻译英语测试用例来处理的——这保留了语言标签，但丢弃了真正重要的文化背景、原生语言模式和特定任务的失败模式。一个要求“将你的回答限制在 15 个单词以内”的测试用例在西班牙语中变得更难，仅仅因为西班牙语单词更长。机器翻译的基准测试在各处都编码了这种人工痕迹。

生产评估中广泛使用的“LLM 作为评审”（LLM-as-Judge）模式在这里有一个特定的失效模式。在超过 50% 的情况下，当被评估内容是非英语语言时，部署的评估模型无法识别质量下降。评审模型是在英语性能数据上训练的；它对“这个答案是错误的”的校准在阿拉伯语或泰语输出中就会失效。你会同时得到绿色的评估结果和生产环境的失败。

安全评估也存在同样的问题。在英语数据上训练的护栏和对齐机制在其他语言中表现出性能下降，其差距与该语言在训练中代表性不足的程度直接相关。一个在英语中拒绝有害请求的模型可能不会在斯瓦希里语中拒绝它们——这不是因为安全功能被刻意禁用了，而是因为该语言的训练信号中根本不存在安全相关的模式。

这种失效模式是隐蔽的。输出看起来很合理。句子语法正确。模型没有胡言乱语；它产出了连贯的内容，但这些内容恰好是事实错误、带有微妙偏见或遗漏了关键约束的。这些失败不会触发错误率或延迟警报。它们表现为用户信任的侵蚀、支持工单和账户流失。

以语言为单位的基准测试作为基础设施

将多语言质量视为基础设施问题而非功能特性，会改变你处理它的方式。第一步是衡量：你无法修复你看不见的东西。

实际的做法是采用专门的多语言评估框架，并在任何模型变更前后对每种支持的语言运行这些框架。MMLU-ProX 覆盖了 29 种语言，每种语言包含超过 11,000 个问题，为通用知识和推理任务提供了广泛的覆盖。Microsoft 的 MEGA 框架在一组结构化的多语言任务中评估生成式 AI 的性能。BenchMAX (2025) 提供了一套专门为多语言系统的生产评估而设计的综合套件。

近期基准测试研究的一个关键洞察是，翻译的测试用例是不够的。在翻译后的测试上的表现并不能预测模型在目标语言原生编写的内容上的表现。由母语使用者构建的基准测试——如 MultiNRC 和 MMLU-ProX 的原生构建部分——能够发现基于翻译的评估会完全遗漏的失效模式。如果你要认真支持一种语言，你需要由该语言的使用者编写或审校的原生语言测试用例。

设置特定语言的质量阈值与衡量本身同样重要。不要接受“在英语性能的 5% 以内”作为统一标准。有些任务在不同语言间迁移得很好；但结构化提取和复杂指令遵循则不然。为每个“语言-任务”组合建立单独的基准，并将低于这些基准的退化视为一种回归（Regression），在发布前需要修复。

生产日志中的分层采样能为你提供持续的信号。记录一定比例的非英语查询及其相关的质量信号——点赞/点踩、下游任务成功率、明确的用户纠正。按语言对这些数据进行拆解。目标是了解你在生产环境中的实际分语言质量，而不仅仅是在评估阶段。

语言路由与回退策略

一旦你能衡量差距，接下来的问题就是如何应对。对于许多团队来说，最容易实现的即时解决方案是路由：将查询引导至最适合检测到的语言的模型。

语言路由基础设施涉及检测传入查询的语言，然后根据该语言-任务组合的历史性能数据在可用模型中进行选择。像 RouteLLM 这样经过训练的路由框架可以将基础设施成本降低高达 85%，同时保留 95% 的高能力模型性能，方法是将简单的查询路由到更便宜的模型，而将复杂或低资源语言的查询路由到最强大的可用模型。

路由器的训练至关重要。在通用基准上训练的路由器对你特定任务分布的泛化效果较差。在与用户发送的实际查询高度相似的任务特定数据（且使用用户实际使用的语言）上训练的路由器，其准确性要高得多。基于偏好的训练（即路由器从人类对模型质量的评估中学习）会产生最好的结果。

对于即使是性能最强的模型也无法产生可接受质量的语言，“翻译-处理-翻译”架构可以作为一种回退方案。查询被翻译成英语，由英语表现最优的模型处理，然后将输出翻译回目标语言。这种方法有实际的代价：翻译会引入延迟，每个翻译步骤都会损失保真度，且模型的输出可能会带有无法翻译的英语特有假设。这是在原生性能确实不足时的回退方案，而不是原生语言质量的替代品。

特定语言的微调是高投入、高回报的路径。对于对你的产品至关重要的受支持语言，在原生语言任务数据上进行微调——即使是适量的高质量示例——也能弥合很大一部分质量差距。研究一致表明，数据质量比数量更重要：1,000 个由流利使用者编写的原生语言示例优于 10,000 个机器翻译的示例。LoRA 等参数高效的方法使微调成本保持在可控范围内，而无需进行完整的模型重训练。

2025–2026 年模型格局的得与失

最新一代模型在多语言覆盖方面取得了实实在在的进展。Qwen2.5 和 Qwen3 现在声称支持超过 200 种语言，并扩展了多语言预训练语料库。Gemini 覆盖了 140 多种语言，具备原生多模态能力。LLaMA 3.1 在 100 多种语言中扩展了强大的多语言指令遵循能力。

这种进步是真实的，但分布并不均匀。高资源语言——西班牙语、法语、德语、日语、普通话——得到了实质性的改进。这些语言与英语之间的差距已经缩小。但低资源语言的差距并未缩小。非洲语言、美洲原住民语言以及数字存在有限的地区性语言仍然严重服务不足。这些语言目前可用的最佳模型其性能水平仍处于在英语语境下不可接受的程度。

分词器（Tokenizer）的改进正在进行，但进展缓慢。混合分词方法和特定语言的词表扩展在研究中展现出前景，但大多数团队使用的商业部署模型在处理非拉丁脚本时仍然存在 Token 计数惩罚。在评估多语言产品的模型成本时，要考虑到由于分词器效率低下，某些语言的任务费率会显著提高。

在这一领域，评估质量的提升速度快于模型质量。母语使用者基准测试正成为标准做法。安全性评估正在获得多语言覆盖。但生产部署仍然显著滞后——大多数运行 AI 产品的团队尚未更新其评估基础设施，以匹配基准测试的发展速度。

运营清单

如果你交付一款多语言 AI 产品，负责任运营的最小可行配置是：

• 审计你的评估覆盖范围。 明确列出你的产品支持的每种语言，并验证你是否拥有针对每种语言的评估数据。“我们支持西班牙语”是对质量的承诺，而不只是指能检测出该语言。
• 在重大模型变更前运行各语言的基准测试。 提升了英语性能的模型升级有时会降低小众语言的性能。在这些问题触达用户之前将其拦截。
• 按语言监控生产环境的质量。 分解你的质量指标。如果你没有按语言追踪成功率、用户纠错率和错误率，你就是在盲目运行。
• 设置特定语言的阈值。 不同任务在不同语言中的性能衰减速度各异。将每一个“语言-任务”对视为其独立的质量 SLO。
• 实施语言路由。 即便是一个简单的基于规则的路由器，将低资源语言的查询发送给最强大的模型，也比无差别地处理所有查询要好。
• 记录你的语言质量承诺。 如果某种语言处于测试阶段或质量有所下降，请告知用户。沉默式的质量下降是信任问题；而坦诚局限性则是可控的。

那些处理得当的团队从一开始就将多语言质量视为一等公民的工程问题，而不是在出现客服投诉后才去补救。衡量基础设施、路由逻辑和针对各语言的评估是与英语基准线同步构建的，而不是在发布后才进行改造。在一个大多数 AI 产品都优先发布英语版本且其他语言版本永远无法赶上的世界里，这种纪律性就是真正的差异化优势。