构建多语言 AI 产品：没人衡量的质量悬崖

你的 AI 产品在评估套件中获得了 82% 的分数。你向 40 个国家发布了产品。三个月后，法国和德国用户报告的质量与英语用户相似。印地语和阿拉伯语用户则悄悄停止了使用该功能。你的综合满意度评分几乎没有波动 —— 因为英语用户主导了指标池。悬崖一直都在。你只是没有测量它。

这是大多数发布多语言 AI 产品的团队都会遇到的典型情况。质量差距并非微乎其微。像 QwQ-32B 这样的最先进模型，在英语推理基准测试中分数为 70.7%，但在斯瓦希里语中则下降到 32.8% —— 这是 2025 年测试的最佳模型在性能上的 54% 相对崩溃。而且这还是 最佳 模型。这种差距并不会随着模型变大而消失。它在高资源语言中会缩小，但在其他语言中依然很大。

根本原因在于训练数据

预训练数据分布是原罪。英语在 Common Crawl（大多数大语言模型的主要数据源）中占据主导地位，约占所有爬取内容的 41%。俄语占 6.5%，德语占 6%，日语占 5.7%，中文占 5%。阿拉伯语低于 1%。印地语低于 0.5%。孟加拉语、斯瓦希里语和世界上大多数其他语言的占比仅为噪点级别。

模型训练直接反映了这种偏差。LLaMA 2 训练了大约 90% 的英语 Token。其他语言仅以微量存在：德语为 0.17%，法语为 0.16%，中文为 0.13%。LLaMA 3 略微改善了这一比例 —— 但 Meta 自己的文档指出，在 30 种语言中，只有 5% 的预训练 Token 是非英语的，并明确警告其性能 “无法与英语匹敌”。BLOOM（BigScience 模型）特意做了多语言设计选择，但即使是其平衡的 ROOTS 语料库，按 Token 计数最终也有 30% 是英语。

下游效应在模型内部层面是可测量的。研究分析了不同语言之间内部层表示的余弦相似度，发现 LLaMA 2 7B 对韩语的表示与英语表示的相似度分数为 0.2–0.5，而拥有 0.17% 训练数据的德语则在 0.58 左右。该指标与训练数据比例直接相关，这种模式在 LLaMA、Qwen、Mistral 和 Gemma 模型家族中都存在。这并非单个厂商的特有现象。这是模型大规模构建方式的结构性特征。

规模化并不能统一解决这个问题。更大的模型可以提高低资源语言的性能，但在某些能力维度上，相对于英语的差距往往会持续存在甚至扩大。

三种不同的失败模式 —— 而非一种

考虑多语言质量的团队通常将其定义为一个单一问题：“模型在其他语言中知道的较少”。这种框架忽略了两个同样重要的失败模式。

能力悬崖（Capability cliff）。 模型在非英语语言中确实知识较少且推理能力较弱，因为它在这些语言中看到的训练数据较少。这在基准测试中得到了体现：MMLU-ProX 测试了 29 种语言的 36 个模型，发现相同问题在资源丰富和资源匮乏语言之间存在 24 个百分点以上的差距。一项医疗聊天机器人研究测试了 ChatGPT-3.5 和针对西班牙语、中文和印地语的专业医疗模型 —— 结果发现，与英语相比，正确性降低了 18%，一致性降低了 29%，可验证性降低了 13%。一个专业模型对超过 67% 的非英语医疗查询给出了无关或矛盾的回答。

安全悬崖（Safety cliff）。 对齐训练（RLHF、宪法 AI、安全微调）绝大多数是用英语进行的。在英语中训练到模型中的约束往往无法迁移到其他语言层面。布朗大学的研究表明，GPT-4 的安全护栏在英语中拦截有害提示的成功率不足 1%，但如果将相同的提示翻译成祖鲁语、苏格兰盖尔语、苗语或瓜拉尼语，则可以被绕过约 79%。这并非理论发现。在研究公开后，OpenAI 修复了这个问题。从业者在 Gemini 中也独立确认了类似的差距，在同一会话中，当查询切换到某些非英语语言时，在英语中正常工作的安全拒绝会被绕过。

输出语言悬崖（Output language cliff）。 这是大多数团队最先发现并误诊的问题。模型收到阿拉伯语查询，却用英语回答。它理解了问题 —— 只是默认输出英语。经过指令微调的 LLaMA 2 模型在回答阿拉伯语查询时，单语言通过率仅为 0.3%。几乎每一个回答都忽略了查询语言。一个违反直觉的发现是：指令微调反而恶化了这个问题。基座模型在处理语言一致性方面表现更好。主要在英语数据上进行的指令微调放大了英语输出偏见。

这种输出语言悬崖在 RAG 系统中以更隐蔽的形式出现。当检索到的上下文是英语但用户用中文查询时，模型经常会 “漂移” 到生成英语。在一次系统研究中，当检索到的上下文是英语时，中文目标的语言一致性从 92% 下降到 68.4%。在跨语言的 70–98% 的漂移案例中，模型默认输出英语。

为什么仅限英语的评估无法捕捉到这些问题

标准评估流程：构建英语测试集，运行模型，衡量总体准确率。或许翻译一部分示例进行抽查。发布到生产环境。

问题会在每一步叠加。

基于翻译的基准测试会将原始的英语结构带入目标语言，从而扭曲结果。一项针对西班牙语 MMLU 的研究发现，翻译错误（术语翻译错误、专有名词处理不当、语义偏移）在某些类别中占到了表象失败的 30% 到 60%。人工修正这些翻译痕迹后，多达 63% 的失败项得以恢复。翻译内容的基准测试得分并不衡量模型在目标语言中的能力；它们衡量的是模型能力与翻译质量的混合。

文化偏见加剧了这一问题。对 MMLU 的分析发现，28% 的问题需要西方文化知识，84.9% 的地理问题集中在北美或欧洲地区。当你将文化敏感型问题与文化无关型问题分开时，模型排名会发生重大变化。针对完整 MMLU 优化的模型可能是在利用西方知识优势，而非通用推理能力。

总体得分掩盖了分布情况。一个声称“29 种语言平均分”为 75% 的模型，在英语和法语上可能达到 95%，但在斯瓦希里语和孟加拉语上仅为 40%。大多数模型卡片（Model cards）不显示每种语言的明细。声称支持 30 多种语言的模型厂商很少披露评估方法或每种语言的性能数据。

最终的失败在于生产环境的信号本身。非英语用户如果持续得到较差的回答，会悄然流失或停止使用该功能——但他们在总体满意度得分中的权重太小，短期内无法影响指标。你会看到总体 CSAT（客户满意度）保持平稳，而一个重要的用户群体却停止了互动。你需要按语言划分的 CSAT 检测手段才能发现这一点。几乎没有团队拥有这种能力。

真正有效的语言检测与路由

在进行语言路由之前，你首先需要可靠地检测语言——短文本语言检测比听起来要难。

生产标准是 FastText，它支持 176 种语言，每秒处理约 28,000 个样本，在准确率和吞吐量上都显著优于其他方案。但即使是 FastText 也会在以下可预见的情况下失败：

• 短字符串或歧义字符串（例如 "api" 在印度尼西亚语中意为“火”，同时也是英文缩写）
• 问候语，用户用一种语言书写但希望用另一种语言回复
• 语码转换（Code-switching），用户在句中混合使用多种语言
• 对没有清晰语言信号的字符串过度自信

生产系统使用特定领域微调（在客户服务对话而非通用网页文本上进行训练），并辅以问候语词典，将常见的多语言短语映射到预期的回复语言。

一旦你能可靠地检测语言，三种路由架构可以处理其余工作：

先翻译后处理（Translate-then-process）。 检测语言 → 将查询翻译成英语 → 运行针对英语优化的模型 → 将回复翻译回去。这对于知识检索任务效果很好。但在涉及文化背景的问题（英语知识库不适用）、正式语体（法律、医疗）以及翻译会丢失结构含义的黏着语中会失败。此外，你还在叠加两次翻译误差。

语言专家路由（Language-specialist routing）。 针对检测到的每种语言，路由到特定语言微调后的模型。每种语言的质量上限最高；运营成本也最高。只有当你每种语言的流量足以支撑维护单独的模型变体时，这才是可行的。

带有语言感知提示词的统一模型（Unified model with language-aware prompting）。 检测语言 → 在系统提示词中注入显式的语言指令（”请用 {detected_language} 回复”） → 使用单个多语言模型。研究表明，在大多数语言中，完全翻译过的系统提示词可以达到 95% 以上的语言生成正确率。操作更简单；质量上限由基础模型的多语言能力决定。

大多数生产系统从方案 3 开始，随着质量要求的提高，再针对流量最高的非英语语言增加特定语言的微调。

在上线前暴露“悬崖”的评估设计

最重要的转变是：在了解各语言间的差异之前，停止对不同语言进行聚合统计。

使用原生编写的测试集。 INCLUDE 基准测试提供了 197,000 多个问答对，取自 52 个国家 44 种语言的当地考试资料——这些问题是由母语人士为母语人士编写的，而非从英语翻译而来。这些测试能暴露被翻译基准测试遗漏的失败点。如果你的团队无法获取原生编写的问题，请使用回译（back-translation）作为质量检查：将你的英语示例翻译成目标语言，再翻译回英语，并标记任何含义发生重大偏离的项目。

将能力准确率与语言一致性分开。 模型可能用错误的语言给出了正确的回答。独立衡量“正确语言率”（回复是否匹配查询语言？）和内容准确率。你可能拥有 90% 的能力上限，但语言一致率只有 60% —— 这是两个需要不同修复方案的不同问题。

在低资源语言中显式测试安全护栏。 这是几乎没有团队会做的评估步骤。在向新的语言市场发布之前，将你的安全测试套件翻译成 5 种以上不属于你主要训练分布的非英语语言进行测试。布朗大学关于 79% 绕过率的发现并非个例——当你仅在英语中训练安全能力并推向全球，却不测试安全能力是否已成功迁移的假设时，就会发生这种情况。

为每个生产请求标记检测到的语言。 这是最小可行性的监控变更。一旦有了每种语言的标签，你就可以分别计算每种语言的准确率、延迟和满意度信号。设置针对特定语言的漂移告警，而不是全局告警——英语的 P95 延迟为 400ms，印地语的 P95 为 550ms，可能都是可以接受的，但应适用不同的告警阈值。

在每次模型更新后运行针对各语言的回归测试。 英语能力的提升并不保证非英语能力的提升。当模型更新改变了数据分布或调整了对齐训练时，某一种语言的能力实际上可能会发生退化。你的上线前检查清单应该包含针对各语言的测试集，而不仅仅是总体性能。

关于衡量的承诺

质量悬崖是无声的，因为大多数团队从未建立起能发现它的监测手段。在综合 CSAT 中，非英语用户只占少数。针对每种语言的满意度信号并不存在。评估套件（Eval suites）仅支持英语。模型卡（Model cards）不披露分语言的详细数据。直到用户不再出现，这个悬崖都是隐形的。

解决办法不是等待模型来弥补差距 —— 自从首批大规模模型发布以来，这种差距就一直存在。虽然在高资源语言中这种差距正在缩小，但在世界上大多数语言中，它依然顽固存在。解决办法是去衡量它。

在你的请求日志中添加语言检测标签。在你的评估套件中添加分语言的能力基准 —— 即使只是针对目标市场的一个简化的 200 题子集，也比什么都没有强。在任何发布之前，至少使用 5 种非英语语言运行你的安全测试。构建分语言的监控仪表板，并设置独立的报警阈值。

那些将要构建出最可靠多语言 AI 产品的工程师们，并不会等待模型供应商在底层解决这个问题。他们会自己进行衡量，绕过这些缺陷，并根据对比基准提交错误报告，以此精准展示班加罗尔或卡萨布兰卡的用户体验比旧金山的用户体验到底差了多少。

这种对比基准必须先存在，才能驱动决策。目前，对于大多数团队来说，它并不存在。