10 篇博文 含有标签「multilingual」

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

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

你的团队发布了一项 AI 功能。你为本地化工作感到欢欣鼓舞：每个按钮标签、工具提示和错误消息都被翻译成了 12 种语言。产品经理签了字。该功能在全球上线。

然而，六周后，一位德国用户发布了一张截图。AI 的回答用词正确但语域（Register）不对 —— 在非正式的客服场景中显得过于生硬。一位日本用户反映，结构化输出中的日期格式为 MM/DD/YYYY，这导致他们的下游工具出现故障。一位巴西的支持工程师注意到，AI 在对复杂查询进行推理时，偶尔会在句子中途滑入英语。这些并不是基础设施故障。你的仪表盘显示一切正常。但对于非英语用户来说，产品正在悄无声息地变得更糟。

根本原因几乎总是一样的：团队翻译了 UI 字符串，但却让系统提示词保留为英文。这看起来像是本地化，但事实并非如此。

一个团队构建了一个 RAG 系统。英语检索召回率达到了 94%。他们发布了产品。三个月后，来自法国和德国用户的支持工单堆积如山——聊天机器人不断返回无关结果或根本没有结果。工程师们查看他们的监控仪表盘。整体召回率：91%。看起来一切正常。

语料库是英语。嵌入模型（Embedding model）仅支持英语。用户则不然。每一个法语查询都被嵌入到一个向量空间中，而这个空间的设计初衷从未考虑过与它所检索的英语文档共享坐标。余弦相似度并不低——但它们在几何上毫无意义。而且因为聚合指标掩盖了分布问题，在用户大声抱怨之前，这个问题是不可见的。

这就是多语言 RAG 检索差距，也是服务于非英语受众的生产级 AI 系统中最常见的静默失败模式之一。

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

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

你的模型在评测集上得分92%，但说法语的用户却不断抱怨它在胡说八道。这两件事可以同时为真——而它们之间的差距，是多语言AI系统在构建和评测方式上的结构性问题。

LLM在非英语语言中的幻觉率比英语高出15–35%。在斯瓦希里语或约鲁巴语等低资源语言中，针对同样的事实类问题，性能差距可扩大至38个百分点。然而，大多数团队在推出多语言AI功能时，只使用英语评测套件，汇报掩盖问题的聚合基准分数，直到巴黎或孟买的用户开始提交工单才发现问题。

跨语言幻觉问题本质上不是模型质量问题，而是一种测量与架构失误——团队将多语言AI视为"英语AI加上翻译模块"而一再延续这一失误。

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

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

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

你的产品路线图写着“进军日本和巴西市场”。你的财务模型显示 LLM API 支出项为每月 $X。这两个数字都是错的，而且你直到国际化推广前几周才会发现这一点。

Tokenization（分词）——将用户文本转换为模型可处理的整数的步骤——对英语有着深刻的偏向。一段日语文本所需的 Token 数量可能是同义英语句子的 2–8 倍。这个倍数直接影响到 API 成本、上下文窗口余量和响应延迟。那些根据英语基准测试来模拟 AI 预算，然后直接切换语言选项的团队，通常会被比预期高出 3–5 倍的账单吓一跳。

大多数构建 LLM 的工程师最终都会学到一个粗略的换算比例：1 个 Token 大约等于 0.75 个英文单词，因此 4,000 个 Token 的上下文窗口大约可以容纳 3,000 个单词。当你的输入是日常英文文本时，这个数字用于粗略估算还可以。但在其他任何地方，它都是悄无声息地错误——而事实证明，“其他任何地方”涵盖了大多数有趣的生产环境负载。

Token 计算错误不会大声报错。它们表现为与任何账单项目都不匹配的成本超支、上下文窗口悄悄截断了文档的最后几段，或者是多语言流水线在英文测试中表现良好，但在遇到真实流量的第一周就超出了 4 倍预算。当你追溯到 Tokenizer 分词问题时，损失已经造成。

你的 AI 功能上线时，任务成功率达到了 91%。你运行了评估，迭代了提示词，并不断调优，直到达到质量标准。然后你面向全球发布了——三个月后，一名东京的用户提交了一个支持工单，称你的 AI “不太理解”他们的输入。你的日本用户一直都在默默忍受一个比英语用户体验差 15–20 个百分点的功能。你的团队中没有人注意到这一点，因为没有人去衡量它。

这就是提示词本地化债务（Prompt Localization Debt）：你为之构建 AI 的语言与用户所使用的其他每种语言之间不断累积的性能差距。它不会在仪表盘上显现，也不会导致服务中断。它只是静悄悄地制造出二等公民用户。

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

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