大模型多语言能力评估新范式：往返翻译与LiT基准的实践指南

1. 项目概述：为什么我们需要重新审视大模型的多语言评估？

如果你最近关注过大语言模型的评测榜单，可能会发现一个有趣的现象：一个在MT-AIME24（多语言数学推理基准）上得分极高的模型，在实际的跨语言对话或翻译任务中，表现可能并不如预期。我自己在尝试将一些前沿开源模型应用到非英语内容创作和本地化项目时，就曾深受其害——明明榜单成绩亮眼，但生成的日语营销文案却词不达意，或者将西班牙语的俚语翻译得僵硬无比。这促使我开始深入探究：我们用来衡量模型“多语言能力”的标尺，是不是本身就有问题？

当前主流的多语言评估，如MT-AIME24、PolyMath或INCLUDE，本质上是在用翻译后的数学题或知识问答来“考”模型。这就像用翻译成中文的GRE数学题来测试一个人的中文水平一样荒谬。模型答对了，只能证明它数学好或者知识面广，但无法证明它真正理解并掌握了中文的语法、语用和文化内涵。更糟糕的是，这些基准的评估结果与模型在真实多语言场景（如LMArena这类收集了海量真实用户查询和反馈的平台）中的表现，相关性极低，甚至呈负相关。这意味着，我们可能正在一个错误的方向上投入大量资源去“优化”模型，而忽略了其真正的多语言生成短板。

往返翻译（Round-Trip Translation）正是为了戳破这个“皇帝的新衣”而提出的一个朴素却有力的思想实验。它的核心逻辑非常简单：让模型将一段文本从源语言（如英语）翻译到目标语言（如斯瓦希里语），再翻译回源语言。然后，比较原始文本与回译文本之间的语义一致性。如果模型的多语言生成能力扎实，那么经过这一趟“语言之旅”，核心意思应当被完好无损地带回来。任何语义的丢失、扭曲或增添，都直接暴露了模型在跨语言理解和生成链条上的薄弱环节。这种方法不依赖昂贵的人工参考译文，也不需要比被测模型更强大的多语言法官模型，巧妙地绕开了当前评估体系中的两大瓶颈。

基于这一理念构建的LiT（Lost in Translation）基准，正是为了提供一个更贴近现实、更能反映模型真实跨语言生成能力的“试金石”。它不仅仅是一个测试集，更是一种评估范式的转变——从“模型知道什么”转向“模型能用不同语言做什么”。

2. 现有基准的困境：我们到底在评估什么？

在深入LiT方案之前，我们必须先搞清楚，现有的主流多语言基准到底出了什么问题。只有理解了病症，才能开出正确的药方。

2.1 数学推理基准的“障眼法”：MT-AIME24为例

MT-AIME24是一个典型的例子。它将著名的美国数学邀请赛（AIME）题目翻译成多种语言，用以评估模型的多语言数学推理能力。听起来很合理，对吧？但当我们把模型在MT-AIME24上的得分，与其在纯英文原版AIME25上的得分进行对比时，一个惊人的事实浮现了：两者的斯皮尔曼相关系数高达0.94。

注意：斯皮尔曼相关系数是一种衡量两个变量排名一致性的指标，值越接近1或-1，相关性越强。0.94意味着模型在MT-AIME24上的排名，几乎完全由它在英文数学题上的能力决定。

这个数字意味着什么？它意味着，一个模型在MT-AIME24上表现优异，很可能只是因为它的数学推理能力强，而非多语言理解能力强。我们团队在分析Qwen3-235B等模型在MT-AIME24上的错误时发现，超过90%的错误属于“逻辑错误”或“计算错误”，而真正因为误解了非英语题目表述（即“语义错误”）导致的失败，比例极低。模型实际上是用它强大的英语思维在“解”这些题，多语言环节仅仅是一个无关紧要的“输入解码”步骤。这种评估方式，完全混淆了“数学能力”和“语言能力”这两个截然不同的维度。

2.2 知识问答基准的“知识陷阱”：INCLUDE的局限性

那么，像INCLUDE这样，专门从各语言文化中搜集原生问题、避免简单翻译的基准，是否就更可靠呢？遗憾的是，它陷入了另一个陷阱：知识检索陷阱。

INCLUDE的设计初衷很好，旨在评估模型对不同文化和区域知识的掌握。然而，它的评估形式依然是多项选择题。这导致模型的表现，高度依赖于其知识库的覆盖范围和事实记忆的准确性。我们的分析显示，模型在INCLUDE上的错误，绝大多数是“事实性错误”（例如，记错了某个历史事件的日期），而非“语义理解错误”（例如，没看懂题目在问什么）。更关键的是，模型在INCLUDE上的表现，与它在英文通用知识基准MMLU-Pro上的表现，相关系数也达到了0.83。这再次说明，基准测量的主要是“知识量”，而不是“用该语言理解和表达知识的能力”。

2.3 思维链（CoT）带来的评估扭曲

一个更具迷惑性的现象是“思维链”（Chain-of-Thought）推理的引入。在许多基准测试中，开启思维链提示（即让模型“逐步思考”）能大幅提升分数。在MT-AIME24上，思维链版本模型相比指令版本，性能提升非常显著。然而，当我们将视线转向LMArena——一个反映真实用户对多语言生成内容喜好的平台——时，却发现思维链带来的优势消失了。模型在基准测试上的“炫技”，并没有转化为用户可感知的、更好的多语言生成质量。

这背后的原因在于，思维链极大地优化了数学推理和复杂逻辑的推导过程，但这恰恰是现有基准所侧重的。而对于真实的语言生成任务，如保持对话的流畅性、把握微妙的语体风格、处理文化特定的表达方式，逐步推理的“显式思考”有时甚至会破坏生成的直觉性和自然度。因此，一个在基准测试中因思维链而“封神”的模型，在实际应用中可能表现得平平无奇，甚至更差。

2.4 核心问题总结：评估目标的错位

综上所述，当前主流多语言基准存在三大根本性缺陷：

1. 评估目标混淆：它们测量的是模型在数学、逻辑、事实知识等“领域能力”上的表现，并将其错误地归因于“语言能力”。
2. 与真实效用脱节：基准分数与模型在真实多语言应用场景（如聊天、翻译、内容创作）中的用户体验相关性很弱，无法有效预测实际表现。
3. 对低资源语言不敏感：这些基准往往围绕高资源语言（如中、英、法、德）构建，难以有效揭示模型在低资源语言上的致命缺陷，而后者才是多语言能力真正的“试金石”。

我们需要一个能够直接、纯净地评估“跨语言语义保持能力”的工具，这就是LiT基准诞生的背景。

3. 往返翻译（RTT）的核心原理与优势

往返翻译并非一个新概念，它在机器翻译领域的历史可以追溯到几十年前，早期被用于验证翻译质量，后来成为神经机器翻译中一种重要的数据增强方法。其核心思想直击要害：如果一段文本在经过“出发→抵达→返回”的旅程后变得面目全非，那么中间的“抵达”步骤（即正向翻译）很可能就是不可靠的。

3.1 方法论拆解：一个优雅的“压力测试”

LiT基准所采用的往返翻译评估，可以分解为以下几个核心步骤：

1. 源文本选择：选取一段语义完整、内涵丰富的英文文本作为起点。LiT精心设计了三大类文本：

   • 摘要：涵盖人文与STEM领域，文本自包含、语义密度高，易于检测错误。
   • 语用文本：占总样本的60%，专门测试超越字面含义的语言能力，包括核心语义、话语连贯性、隐含内容、语用推理和社会交互五个子类。例如，测试模型能否处理“言外之意”或保持对话的礼貌层级。
   • 非正式文本：包含俚语、习语和语体转换，考验模型在保留语气和社会功能方面的能力。

2. 多语言序列翻译：这是LiT设计的精妙之处。它并非简单地进行英-中-英的往返，而是设计了8条复杂的语言序列路径，每条路径包含4种语言。例如，“东亚序列”是：英语 → 日语 → 韩语 → 中文 → 俄语 → 英语。这种设计极大地增加了评估的严苛度和覆盖面，能够暴露出在单一语言对翻译中可能被掩盖的误差累积效应。

3. 回译与比对：将经过多语言“旅行”后最终回到英文的文本，与原始英文文本进行比对。

4. 自动化评分：采用基于MQM（多维质量度量）框架的LLM-as-a-Judge进行评分。MQM将错误分为：

   • 轻微错误：不影响理解的轻微不流畅或 awkwardness。
   • 重大错误：导致语义改变、结构错误或误译。
   • 关键错误：完全丢失原意、幻觉或涉及安全的问题。 最终，我们关注的是MQM≥80的样本比例，即翻译质量达到“可用”水平的比例。

3.2 相比传统基准的压倒性优势

与现有基准相比，往返翻译评估范式具有多重优势，这些优势在LiT的设计中得到了集中体现：

最大的优势在于“无需参考译文”和“评判简单化”。传统翻译评估需要针对每种目标语言准备高质量的人工参考译文，成本极高，且对于低资源语言几乎不可能。而往返翻译的评判，只需要一个能较好理解英文的法官模型，比较两段英文文本的语义一致性即可。这打破了评估多语言能力必须依赖更强大多语言模型的悖论。

4. LiT基准的构建细节与实操考量

理解了“为什么”之后，我们来看看LiT基准具体是“怎么做”的。这部分内容对于想在自己的项目中借鉴此方法，或深入理解评估结果的同行尤为重要。

4.1 数据构建：追求多样性与真实性

为了避免数据污染，LiT团队完全从头创建了1600个评估样本（200个独特文本 x 8条语言序列）。这200个源文本的筛选是技术活，需要兼顾：

• 领域广度：不能全是新闻体或科技文献，必须包含日常对话、社交媒体风格、技术文档、文学性描述等。
• 语言现象密度：需要刻意包含歧义、指代、隐喻、文化负载词等挑战性结构。例如，包含“他踢了桶”这样的句子，测试模型能否正确翻译其“去世”的隐喻义，而不是字面意思。
• 长度适中：多为多句段落，既能构成连贯语境，又不会过长导致评估噪音。

实操心得：如果你要为自己的应用构建一个小型往返翻译测试集，不必追求1600的规模。可以从50-100个最能代表你业务场景的典型句子或段落开始。关键是覆盖你的核心用户可能遇到的语言现象，比如电商场景下的产品描述、客服对话、营销文案等。

4.2 语言序列设计：覆盖光谱与压力测试

LiT的8条语言序列是其核心创新之一，它们不是随机组合，而是精心设计来反映不同的资源水平和语言特性：

1. 高资源序列：如“东亚序列”（日→韩→中→俄）和“中欧序列”（罗→匈→德→波）。这些语言拥有丰富的预训练数据和研究成果，用于检验模型在理想条件下的“天花板”。
2. 中资源序列：如“北欧序列”（冰→瑞→芬→立）和“东南亚序列”（中→泰→越→他加禄语）。这些语言的资源相对有限，能测试模型的泛化能力。
3. 低资源序列：如“非洲序列”（斯瓦希里语→阿拉伯语→豪萨语→阿姆哈拉语）和“南美序列”（葡→克丘亚语→西→瓜拉尼语）。这是真正的“试金石”，能瞬间暴露模型在长尾语言上的脆弱性。

注意事项：选择语言序列时，必须考虑语言间的“语言距离”和现实中的翻译需求。LiT优先选择了地理或文化上交流频繁的地区之间的语言对，这使得评估更具现实意义。例如，测试日语到韩语的翻译，就比测试日语到冰岛语的翻译更贴近实际应用场景。

4.3 评估与评分：LLM作为法官的实践

LiT使用Grok 4.1 Fast作为主要的法官模型。选择它的原因是其在多语言LMArena上排名靠前，且推理速度快、成本低。评估采用MQM框架，这是一个在专业翻译评估中广泛使用的、基于错误分类和严重性权重的体系。

关键操作步骤：

1. 提示词工程：给法官模型的指令必须清晰、无歧义。需要明确告知它比较两段英文文本（原文和回译文），并按照MQM分类法找出并分类错误。通常会提供详细的错误类别定义和示例。
2. 分数聚合：对每个样本，法官模型会输出一个MQM分数（原始分或错误扣分后换算）。LiT最终报告的是MQM≥80的样本百分比。这是一个更直观的指标，直接告诉我们有多少比例的翻译是“可用”的。
3. 鲁棒性验证：为了确保评估方法本身可靠，LiT还进行了额外的鲁棒性测试，专门针对往返翻译的经典弱点设计挑战集，如多义词、句法歧义、习语等。结果显示，现代大模型对这些挑战具有相当的鲁棒性，往返翻译的评估结论是稳定的。

避坑指南：在使用LLM作为法官时，最大的风险是法官模型本身的偏见或能力局限。因此，进行敏感性分析至关重要。LiT在附录中展示了使用不同法官模型（如GPT-4o）和不同评分方式（原始MQM分 vs. 0-100打分）时，模型排名的高度一致性，这增强了结果的可信度。在自己的项目中，如果条件允许，也应用不同的法官模型进行交叉验证。

5. LiT基准结果解读与行业启示

LiT的评估结果像一面镜子，清晰地映照出当前前沿大模型在多语言能力上的真实图景，其中不乏一些反直觉的发现。

5.1 性能分层：高资源与低资源之间的“断层”

结果中最触目惊心的，是模型在不同资源水平语言上的表现断层。从表3可以清晰地看到：

• 高资源序列：顶尖模型如Gemini-3-Flash，在东亚、中欧等序列上，MQM≥80通过率可达97%以上，表现非常稳健。大多数前沿模型在这里都能取得不错成绩。
• 低资源序列：情况急转直下。在非洲和南美序列上，除了Gemini-3-Flash还能维持59.2%的通过率，第二名Gemma-4-31B（Instruct）的通过率直接暴跌至32.0%。而像Qwen3-235B、Qwen3-30B等模型，通过率接近甚至为0。这意味着，对于这些低资源语言，模型产生的翻译基本不可用，充满了关键错误和幻觉。

这个断层揭示了当前多语言模型的本质：它们很大程度上是在高资源语言数据上训练出的“优等生”，其多语言能力是通过高资源语言到英语的隐式对齐来实现的，而非真正建立了所有语言间的通用语义空间。一旦涉及到训练数据极少、与英语语言距离遥远的低资源语言，模型的泛化能力便迅速崩溃。

5.2 思维链的“双刃剑”效应

另一个有趣的发现是关于思维链（Thinking）模式的影响。与在数学推理基准上的一边倒优势不同，在LiT的翻译任务中，思维链的作用复杂且不稳定。

• 整体上，思维链常损害翻译质量：尤其是在处理非正式文本时，思维链模型的表现普遍差于其指令（Instruct）版本。一个可能的解释是，思维链促使模型对简单的口语化输入进行过度复杂的“分析”，导致生成的翻译生硬、不自然，出现语体错配。
• 在低资源语言上，思维链或有微弱帮助：例如，DeepSeek-V3.2-Exp的思维链版本在低资源序列上得分为7.2，高于其指令版本的1.0。这表明，在面对陌生语言时，显式的推理过程可能有助于模型进行一些有限的猜测和逻辑补偿，但无法从根本上弥补词汇和语法知识的缺失。

核心结论是：思维链主要优化的是逻辑和推理过程，而非语言生成本身。对于以流畅、自然、贴切为目标的翻译任务，简单直接的生成模式往往更有效。

5.3 模型排名与真实世界的关联

LiT最有力的价值主张，在于其评估结果与真实世界用户偏好（以LMArena的Elo评分为代表）的高度相关性（ρ=0.94）。相比之下，MT-AIME24和INCLUDE与LMArena的相关性分别为-0.09和-0.26（见图1）。

这个数据意味着，一个模型在LiT上得分高，我们有极高的信心认为它在实际的多语言聊天、问答等生成任务中也会受到用户青睐。反之，一个只在MT-AIME24上成绩好的模型，其多语言生成能力可能是个“纸老虎”。对于开发者而言，这意味着LiT可以作为一个成本相对低廉、自动化程度高的代理指标，用于模型选型或迭代开发，其预测效果远好于传统基准。

6. 如何将往返翻译评估应用于你的项目

对于大多数AI应用开发者和研究者来说，可能不需要完全复现LiT这样大规模的基准，但完全可以借鉴其方法论，为自己的多语言模型或应用设计一个轻量级、定制化的评估方案。

6.1 设计你自己的“迷你LiT”

1. 明确评估目标：你的模型主要服务于什么场景？是客服对话、内容翻译、跨语言搜索还是代码注释？根据场景确定需要重点测试的语言对和文本类型。
2. 构建测试集：
   • 源文本：收集100-200条最能代表你业务场景的真实文本。确保包含不同难度和风格：简单指令、复杂描述、包含文化隐喻的句子、非正式用语等。
   • 语言路径：不必像LiT一样设计4语序列。可以从最简单的“英-中-英”开始。如果你的应用涉及多语种，可以增加“英-西-英”、“英-日-英”等关键路径。如果想增加难度，可以尝试“英-日-中-英”这样的三语序列。
3. 实施评估：
   • 自动化流水线：编写脚本，自动调用模型API，完成“翻译去->翻译回”的流程，并保存结果。
   • 选择法官模型：可以使用GPT-4、Claude-3或开源的强大模型作为法官。设计清晰的提示词，要求模型从“语义一致性”、“流畅度”、“风格保持”等几个维度进行评分（例如1-5分），或直接判断回译文是否忠实表达了原文核心意思（是/否）。
   • 计算通过率：统计语义一致性得分高于阈值（或判断为“是”）的样本比例。

6.2 常见问题与排查技巧

在实施往返翻译评估时，你可能会遇到以下典型问题：

• 问题1：法官模型评分不稳定，同一文本两次评分结果差异大。

  • 排查：检查提示词是否足够明确、无歧义。是否提供了清晰的评分标准和示例？尝试使用更稳定的法官模型（如最新版本的GPT），或采用多个法官模型取平均分的方式。
  • 技巧：可以让法官模型先进行错误分类（如：语义丢失、语义添加、语义扭曲），再根据错误严重性综合打分，这比直接要求一个总体分数更可控。

• 问题2：模型在简单句上表现良好，但在复杂句或段落上崩溃。

  • 排查：这很可能暴露了模型的长程依赖或复杂结构理解能力不足。检查是翻译到目标语言时出错，还是从目标语言译回时出错。可以分步截取中间译文进行分析。
  • 技巧：在测试集中刻意加入一些长难句、包含多个从句的句子，或需要跨句理解指代的段落，专门测试这方面的能力。

• 问题3：对于低资源语言，模型输出大量乱码或完全无关的内容。

  • 排查：这通常是模型对该语言词汇和语法几乎“一无所知”的表现。检查模型的官方文档，确认其是否声称支持该语言。
  • 技巧：对于低资源语言，评估重点不应再是“语义保持”，而是“基本可读性”。可以增加一个前置判断：输出是否为连贯的目标语言文本？如果不是，直接判定为失败。

• 问题4：往返翻译评估耗时较长，成本较高。

  • 技巧：可以采用分层抽样。先用一个更小的、更具代表性的核心测试集进行快速迭代评估。在模型有重大更新或需要发布最终报告时，再运行完整的测试集。此外，可以考虑使用批处理API来降低请求开销。

6.3 超越评估：用往返翻译进行数据增强与迭代

往返翻译不仅是一个评估工具，也可以成为一个强大的数据增强工具，尤其是在低资源语言场景下。

1. 生成合成数据：对于缺乏平行语料的低资源语言对，可以使用一个较强的“枢轴语言”（如英语），将高资源语言的单语数据，通过“高资源语→英语→低资源语”的路径，生成初步的低资源语数据。虽然质量需要严格过滤，但可以作为预训练或微调的补充。
2. 模型迭代的闭环：将往返翻译评估集成到你的模型开发流水线中。每次模型更新后，自动运行迷你测试集，监控MQM通过率的变化。如果发现针对某种语言的通过率下降，可以深入分析错误样本，定位是哪个环节（编码器、解码器、对齐）出了问题，从而进行有针对性的调整。

往返翻译评估和LiT基准的出现，为我们敲响了警钟：大模型的多语言能力，远不是解几道翻译后的数学题或回答几个文化知识问题就能衡量的。它关乎模型能否在真实的、复杂的、充满噪音和多样性的语言世界中，准确地传递意义、保持风格、连接文化。将评估的重点从“模型知道什么”重新拉回到“模型能用语言做什么”，是推动下一代真正全球化、实用化大模型发展的关键一步。对于我们从业者而言，在关注那些炫目的榜单分数之余，不妨亲手用往返翻译的方法测试一下你依赖的模型，看看它在你的目标语言和场景下，是否真的能“完璧归赵”。