常见问题
执行摘要。 关于 MT Eval Arena 的常见问题解答 — 评分工作原理、哪些提交会被取消资格、如何处理没有 FST 的语言、模型和参数建议，以及提交流程。
评分与指标
工具包计算哪些指标？
工具包为平原克里语（当前基准语言）计算五个指标。其中三个与语言无关，适用于任何语言；两个目前依赖于 CRK 特定插件，随着我们扩展到更多语言，这两个也将被泛化。
| 指标 | 范围 | 测量内容 | 状态 |
|---|---|---|---|
| chrF++ | 0–100 | 预测翻译与参考翻译之间的字符 n-gram 重叠。对形态丰富的语言最佳的表面指标。使用 sacrebleu 的原生评分。 | ✅ 所有语言 |
| 精确匹配 | 0.0–1.0 | 规范化后预测与参考完全匹配的条目比例。 | ✅ 所有语言 |
| FST 接受度 | 0.0–1.0 | 有限状态转换器（形态分析器）接受的输出词的比例。仅在提供 FST 二进制文件时计算。 | ✅ 所有具有 FST 的语言 |
| 等价匹配 | 0.0–1.0 | 与参考或可接受变体匹配的条目分数 — 考虑词序、正字法约定和方言差异。 | ⚡ CRK（泛化中） |
| 语义分数 | 0.0–1.0 | 意义保留分数 — 翻译在多大程度上捕捉了预期含义，不考虑表面形式？ | ⚡ CRK（泛化中） |
计划增加更多指标：形态准确性、代码混用检测、术语遵循度和幻觉检测。完整的 19 个指标清单见 评分规范 §2。
综合分数如何计算？
综合分数是可用指标的加权平均值，归一化到 0.0–1.0 范围。权重在两个配置文件中定义：
- 配置文件 A（具有 FST 的语言）：9 个指标，结构指标（FST + 形态准确性）占综合权重的 40%
- 配置文件 B（没有 FST 的语言）：8 个指标，语义和 chrF++ 具有相等的最高权重
当指标不可用时，其权重按比例重新分配到其余指标。这意味着早期基准（仅有 chrF++ 和精确匹配可用）仍然产生有效的综合分数 — 有效权重只是反映可用的内容。
完整的权重表、规范化规则和排除理由见 评分规范 §4。 工具包代码在 mt_eval_harness/scoring.py 中镜像这些表。chrF++ 通过除以 100 进行规范化后再加权；代码混用和幻觉率被反转（越低越好）。
什么是质量等级？
质量等级是映射到综合分数范围的启发式标签。它们帮助传达分数在实践中的含义：
| 等级 | 综合范围 | 解释 |
|---|---|---|
| 基线 | 0.00 – 0.30 | 低于有用质量。方法需要显著改进。 |
| 新兴 | 0.30 – 0.50 | 显示前景。某些翻译正确但不一致。 |
| 功能性 | 0.50 – 0.70 | 可用于参考，需要人工审查。不适合未审查的部署。 |
| 可部署 | 0.70 – 0.85 | 准备好用于生产，需要定期审查。触发所有权转移资格。 |
| 流畅 | 0.85 – 1.00 | 接近母语质量。适合无监督部署。 |
质量等级和验证等级有什么区别？
质量等级描述自动化分数的含义（基线 → 流畅）。验证等级描述谁验证了结果：
| 验证等级 | 含义 |
|---|---|
| 自我基准测试 | 提交者自己运行了工具包。分数看起来合理但未验证。 |
| GDS 验证 | 维护者使用提交的方法配置重现了结果。 |
| 社区验证 | 双语使用者审查了翻译并确认了质量。 |
一个方法可以是"可部署"质量但仅"自我基准测试"验证 — 意味着分数看起来很好但没有人独立确认过。
提交与取消资格
什么会导致我的提交被取消资格？
如果出现以下情况，您的提交将被拒绝或标记：
- 您的方法接触过评估数据。 如果您训练、微调、少样本提示或以其他方式使用了评估数据集中的任何条目，您的分数被人为夸大。这包括在提示中使用参考翻译。
- 您的运行卡片未通过完整性检查。 指纹必须与配置匹配。篡改的运行卡片被拒绝。
- 您的方法未实现 TranslationMethod 协议。 工具包期望
translate(entries, config) → results。绕过工具包的自定义集成不被接受。
我可以多次提交吗？
可以。排行榜跟踪所有提交。您可以迭代 — 运行数十个实验，仅提交最佳结果。每个提交记录一个唯一指纹，因此不存在关于哪个运行产生哪个分数的歧义。
我如何获得分数验证？
- 自我基准测试（自动）： 每个提交都从这里开始。
- GDS 验证： 将您的方法作为可重现的包提交（代码 + 配置 + 教练数据）。维护者将针对相同数据集重新运行它并确认分数匹配。
- 社区验证： 对于土著语言，这需要双语使用者审查翻译样本。这无法自动化 — 需要社区参与。
提交 API 是否已上线？
还没有。https://mtevalarena.org/api/leaderboard/submit 端点是理想状态。当前提交应通过拉取请求提交到 eval 工具包仓库，将您的运行卡片 JSON 放在 results/ 目录中。
模型与参数
我应该使用什么模型？
没有单一的最佳模型 — 这取决于语言对、您的预算和您的方法。一般指导：
| 语言类型 | 推荐起点 | 原因 |
|---|---|---|
| 高资源 (法语、西班牙语、日语) | google/gemini-2.5-flash 或 gpt-4o-mini | 快速、便宜、强大的基线 |
| 低资源但有一定 LLM 覆盖 (克丘亚语、约鲁巴语) | google/gemini-2.5-pro 或 anthropic/claude-sonnet-4 | 更大的模型具有更好的潜在知识 |
| 多综合型 / 极低资源 (平原克里语、因纽克提图特语) | google/gemini-2.5-pro 配合教练数据 | 教练数据比模型选择更重要。OMT-1600 包括一些多综合型语言（例如 R1 等级的 CRK），但使用标准 BPE 分词 — 在 Arena 中将其作为基线进行基准测试。 |
评估工具包使用 OpenRouter，因此可以对 OpenRouter 上可用的任何模型进行基准测试。运行 champollion models --method llm 查看可用模型。
我应该使用什么温度？
通常越低越好用于翻译：
| 温度 | 效果 | 推荐用于 |
|---|---|---|
| 0.0 – 0.2 | 高度确定性、一致的输出 | 生产方法、最终基准 |
| 0.3 – 0.5 | 某些变化、偶尔更有创意 | 探索、早期迭代 |
| 0.6+ | 高度变化、不可预测 | 不推荐用于 MT 基准测试 |
温度记录在运行卡片中，因此不同的温度产生不同的指纹 — 它们被视为不同的实验。
教练数据有帮助吗？
是的，对于低资源语言特别有帮助。教练数据（语法规则、字典条目、风格说明）被注入到 LLM 系统提示中。对于平原克里语，教练方法对多综合型语言的性能一致优于原始 LLM 方法，因为通用 LLM 对多综合型的接触有限，且缺乏形态意识。即使是专门为 CRK 训练的 OMT-1600，也使用无法在结构上表示多综合型形态的标准 BPE 分词。教练数据提供了模型缺乏的语言学背景。
对于高资源语言（法语、西班牙语），教练的影响较小，因为模型已经具有强大的基线知识。
完整规范见 教练数据。
FST 与形态验证
如果我的语言没有 FST 怎么办？
许多语言没有有限状态转换器。这没关系 — 工具包在没有 FST 的情况下也能工作。综合分数使用配置文件 B 权重（见 评分规范 §4.3），将权重转移到语义和表面指标。FST 接受度在运行卡片中标记为 null。
现有 FST 的主要注册表：
| 注册表 | 覆盖范围 | URL |
|---|---|---|
| GiellaLT | 萨米语、克里语、因纽克提图特语和其他北极/亚北极语言 | giellalt.uit.no |
| ALTLab | 平原克里语、林地克里语、奥吉布瓦语 | altlab.artsrn.ualberta.ca |
| Apertium | ~60 个语言对，主要是欧洲语言 | apertium.org |
| UniMorph | 150+ 种语言的形态范式 | unimorph.github.io |
我可以构建 FST 吗？
可以，但这并非易事。FST 编码语言的形态规则 — 所有有效的词形。构建 FST 需要对语言有深入的语言学知识。如果您可以访问形态语法（例如来自语言学系），可以使用 HFST 或 Foma 等工具将其编译为 FST。
FST 门控在实践中如何工作？
FST 门控管道的工作方式如下：
- LLM 生成翻译
- 输出中的每个词都针对 FST 进行检查
- FST 拒绝的词被标记为形态无效
- 方法可以使用反馈重试（"词 X 无效，请重试"）
- 重试后，剩余的无效词被记录
FST 接受度测量有多少词通过验证。完整的工作示例见 FST 门控管道教程。
数据与数据集
我可以为新语言贡献数据集吗？
可以。来自 基准规范 §11 的最低要求：
- 50 个金标准条目（源 + 验证的参考翻译）
- 30 个开发条目（对于小型语料库可与金标准重叠）
- 社区同意（对于土著语言，需要来自治理机构的明确授权）
- 来源文档（数据来自何处、适用什么许可证）
新数据集自动打开新的排行榜轨道。贡献者指南见 面向语言社区。
我的数据集应该是什么格式？
具有规范字段名称的 JSON：
{
"name": "my-language-dev-v1",
"language_pair": "en-xxx",
"segment": "development",
"version": "1.0",
"entries": [
{
"id": 1,
"source": "Hello",
"reference": "[translation in target language]",
"difficulty": 1,
"domain": "general"
}
]
}
完整的模式和难度等级定义见 数据集。
主权与所有权
谁拥有为土著语言构建的方法？
对于土著语言，达到可部署等级（综合分数 ≥ 0.70）且通过社区验证的方法触发 所有权转移 流程。代码所有权从研究者转移到语言社区的治理组织。
研究者保留：
- 出版权（关于该方法的学术论文）
- 排行榜上的署名
- 将相同技术应用于其他语言的权利
治理组织获得：
- 方法代码和教练数据的完全所有权
- 部署控制权（何时、何地、如何）
- API 使用收入（90% 社区、10% 基础设施）
我可以在没有任何主权问题的情况下将 champollion 用于非土著语言吗？
可以。对于标准语言（法语、日语、西班牙语等），没有主权考虑。正常使用 champollion — 翻译、同步、发布随意。主权框架特别适用于土著和社区治理语言，其中数据治理原则（OCAP®、CARE、Te Mana Raraunga）需要特殊考虑。