跳到主要内容

7 篇博文 含有标签「multilingual」

查看所有标签

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

· 阅读需 13 分钟
Tian Pan
Software Engineer

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

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

跨语言幻觉:为什么你的大模型在它不擅长的语言中更容易撒谎

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

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

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

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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

多语言 Token 税:为非英语用户构建 AI 的实际成本

· 阅读需 13 分钟
Tian Pan
Software Engineer

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

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

破坏生产级 LLM 系统的分词器盲点

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

提示词本地化技术债:隐藏在多语言 AI 产品中的无声质量梯度

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

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

· 阅读需 13 分钟
Tian Pan
Software Engineer

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

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