奖金规范
目的。 本文档定义了 MT Eval Arena 的奖金池结构、阈值条件、领取流程和规则。它以可测量的术语精确定义了"能够进行机器翻译"的含义，以及在什么条件下释放奖金。本文档参考 SCORING_SPEC 了解指标定义和 BENCHMARK_SPEC 了解评估协议——它不重复这些内容。
状态： 实时。创始人奖（§2.1）已获得资金并处于活跃状态。
最后更新：2026-06-04
1. 理念
1.1 奖金奖励突破，而非参与
奖金仅在方法明确达到定义的能力阈值时才会释放。没有参与奖、亚军奖或安慰奖。如果没有人越过门槛，就没有人获得报酬。这是设计使然——这意味着赞助商只为真正有效的成果付费。
1.2 社区验证是不可协商的
自动化指标是代理（SCORING_SPEC §1.1）。一个方法可能在 chrF++ 和 FST 接受度上得分很高，但产生的输出没有任何使用者会接受。每项奖金申请都需要社区验证——双语使用者必须确认输出是可用的。这是人工验证门槛（BENCHMARK_SPEC §7）。
1.3 所有权转移是交易的一部分
申请奖金的方法受所有权转移条款的约束（BENCHMARK_SPEC §8.3）。开发者保留署名权和出版权。治理组织获得使用、修改、分发和商业化该方法的权利，用于其语言。这不是惩罚——这是重点。奖金资助创建属于语言社区的技术。
1.4 反作弊
奖金阈值是针对黄金标准评估定义的（秘密测试集，由治理组织在沙箱中运行）。开发者永远看不到测试数据。这在架构上是强制的——不是依赖于荣誉的政策。参见 BENCHMARK_SPEC §8.2。
1.5 语料库许可：非商业语料库不在奖金通道内
某些在方法开发期间使用的语料库带有非商业许可——例如，EdTeKLA 克里语教科书语料库是 CC BY-NC-SA 4.0。这些语料库是仅限研究/开发通道：
- 奖金黄金标准语料库不得嵌入 NC 许可的语料库内容。 黄金标准测试片段是社区委托的原创作品（参见语料库合作伙伴战略）——为奖金人工编写，从一开始就清除了评估和商业部署的权利。
- 申请奖金的方法不得嵌入 NC 许可的语料库内容（例如，作为教练数据、嵌入式示例或查找表）。转移的方法旨在由治理组织进行商业部署（BENCHMARK_SPEC §8.3、方法提交协议 §6）；其中的 NC 许可内容会污染该部署。
- 开发者可以自由使用 NC 许可的语料库进行开发和自我评估——这就是开发通道的用途。限制适用于提交的内容和部署的内容，而不是开发者如何学习。
1.6 依赖类别门槛奖金资格
所有奖金评估都在沙箱中进行（§1.4），获奖方法转移给治理组织（§1.3）。两个事实都施加了相同的约束：方法依赖的一切都必须是开发者有权放入沙箱并转让给社区的东西。 每项提交都声明一个依赖类别——在方法接口规范中定义，在方法提交协议 §2.6 中的可接纳性条款——资格遵循该类别：
| 依赖类别 | 奖金资格？ | 条件 |
|---|---|---|
| S — 自包含 | ✅ 是 | 仅限 §2 中的阈值条件 |
| O — 开放外部（例如，在提交时镜像的 AGPL FST） | ✅ 是 | 工件固定并供应到提交中；许可证允许社区转移；copyleft 条款保留（社区获得许可证授予所有人的相同权利） |
| A1 — 可替代的 LLM 推理 | ⚠️ 条件性 | 模型声明、固定和可替代（必须针对社区托管的开放权重模型运行）；评估通过沙箱 LLM 网关路由（🔲 计划中——在网关运行之前，A1 方法无法产生黄金标准分数）；转移传达完整配方（提示、教练、代码），而不是模型 |
| A2 — 不可替代的外部数据/服务 API | ❌ 尚未 | 在权利持有人授予沙箱包含和转移权限之前不符合条件。在开放排行榜上允许，带有可见的"外部依赖"标志 |
| X — 无权利的捆绑内容 | ❌ 永不 | 在每个通道中都不可接纳 |
方法的类别是其声明的依赖中最严格的类别。任何类别的未声明依赖都是取消资格的（§5）。
2. 活跃奖金池
2.1 创始人奖——英语→平原克里语（nêhiyawêwin）
| 字段 | 值 |
|---|---|
| 奖金池 | $10,000 加元 |
| 语言对 | 英语 → 平原克里语（EN→CRK） |
| 资金来源 | Champollion 项目创始人 |
| 状态 | 活跃——接受提交 |
| 开放时间 | 黄金标准语料库 + 治理组织就位时 |
| 过期时间 | 无过期。奖金保持活跃，直到被领取或明确撤回。 |
阈值条件
方法通过同时满足以下所有条件来申请创始人奖：
| # | 条件 | 指标 | 阈值 | 理由 |
|---|---|---|---|---|
| 1 | 综合分数 | composite（SCORING_SPEC §4） | ≥ 0.80 | 在可部署（0.70）和流畅（0.85）之间。要求所有指标维度的高质量——不仅仅是形态学有效性。 |
| 2 | FST 接受度 | fst_acceptance_rate（SCORING_SPEC §2.2） | ≥ 0.99（99%+） | 实际上所有输出词都必须是 GiellaLT FST 识别的形态学有效形式。1% 的容差考虑了 FST 可能合理不覆盖的边界情况（专有名词、新词、借词）。这是多综合语 MT 的定义质量门槛——如果 FST 拒绝超过 1% 的词，该方法正在产生语言中不存在的形式。这个奖金的全部要点是购买一个不会破坏语言的系统。 |
| 3 | chrF++ | chrf_plus_plus（SCORING_SPEC §2.1） | ≥ 55.0 | 字符 n-gram 重叠必须在 0–100 标度上超过 55。确保与参考翻译的表面相似性，而不仅仅是形态学有效性。 |
| 4 | 社区验证 | 人工审查（BENCHMARK_SPEC §7） | ≥ 70% "可接受"或"优秀" | 输出的分层样本（≥30 个条目，跨越难度等级 2–5）由 ≥2 名双语 CRK 使用者审查。至少 70% 的审查条目必须获得"可接受"或"优秀"评级。 |
| 5 | 黄金标准评估 | 沙箱执行（BENCHMARK_SPEC §8.2） | 必需 | 所有自动化指标必须针对 gold_standard 语料库片段计算，由治理组织在沙箱环境中运行。开发集分数不计数。 |
| 6 | 可重现性 | 指纹匹配（BENCHMARK_SPEC §3.8） | ±2% | 治理组织必须能够重新运行该方法并实现与提交的运行卡中的分数在 ±2% 内的分数。 |
为什么是 99+% FST？ 多综合语机器翻译的中心问题是幻觉——LLM 产生看起来像目标语言但形态学无效的字符串。产生 95% 有效输出的方法仍然有 5% 的虚构词——对任何生产使用都是不可接受的噪音。99%+ 阈值要求接近零的幻觉，同时允许罕见的边界情况（FST 不知道的专有名词、合法的新词）。如果一个方法无法达到 99%+ FST 接受度，它就没有解决问题。
为什么是 0.80 综合分数？ 这介于可部署（0.70）和流畅（0.85）之间。一个综合分数为 0.80、FST 接受度为 99%+ 的方法产生的输出中，几乎每个词都是真实的克里语词并且整体翻译质量在表面、结构和语义维度上都很高。社区验证门槛（条件 #4）确保这不仅仅是指标游戏——使用者必须确认输出是真正可用的。
这个阈值在实践中意味着什么
在综合分数 ≥ 0.80、FST ≥ 0.99 和 chrF++ ≥ 55 时，双语使用者通常会看到：
- 几乎每个输出词都是真实的克里语词（FST 验证 99%+——接近零的虚构形式）
- 主要语法类别（人称、数、时态）在大多数条目中是正确的
- 词序通常是自然的
- 意义得到可靠保留
- 剩余错误是真实语言错误（错误的屈折、不正确的显著性、动物性不匹配）——不是虚构词
- 流利的使用者可以将输出用作高质量草稿，并以比从头翻译快得多的速度进行更正
这是一个不会破坏语言的系统。它可能不完美，但它产生的每个词都是真实的词。这是对多综合语进行尊重的机器翻译的最低门槛。
3. 奖金申请流程
3.1 提交
-
开发者向治理组织提交其完整、可运行的方法：
- 所有源代码
- 所有依赖（教练数据、字典、FST 配置、提示）
- 安装和执行说明
- 描述方法方法的 README
- 显示近似分数的开发集运行卡（用于预筛选）
-
开发者签署参与条款，包括：
- 所有权转移条款（BENCHMARK_SPEC §8.3）
- 未在评估数据上训练的声明
- 可重现性承诺
3.2 评估
- 治理组织在沙箱工具中安装并针对
gold_standard语料库运行该方法 - 计算自动化指标（综合分数、FST、chrF++ 等）
- 如果满足自动化阈值（条件 1–3），治理组织继续进行社区审查
- 如果未满足自动化阈值，开发者收到分数和反馈。不触发社区审查。
3.3 社区审查
- 输出的分层样本（≥30 个条目，涵盖难度等级 2–5）呈现给双语使用者
- 至少 2 名独立审查者对每个条目进行评级
- 评级标度：拒绝 / 要点 / 可接受 / 优秀
- 如果 ≥70% 的条目从两名审查者那里获得"可接受"或"优秀"，社区验证通过
3.4 支付
- 满足所有 6 个条件
- 治理组织确认结果
- 奖金在确认后 30 天内支付
- 方法所有权按 BENCHMARK_SPEC §8.3 转移
- 结果在排行榜上发布，带有"社区验证"验证等级
3.5 多次提交
- 同一开发者/团队可以多次提交
- 每项提交独立评估
- 如果改进方法并重新提交，仅最新运行卡计数
- 奖金授予首个清除所有阈值的方法——不分割
3.6 团队提交
- 团队和长者-青年对符合条件
- 团队内的奖金分配是团队的责任
- 所有团队成员必须签署参与条款
- 排行榜上的署名列出所有团队成员
4. 未来奖金池
创始人奖是种子。额外的奖金池由赞助商资助。每个新奖金池都记录为 §2 的新小节，具有其自己的：
- 奖金金额和货币
- 语言对
- 赞助商署名
- 阈值条件（可能与创始人奖不同）
- 过期日期（如果有）
- 任何特殊条件
4.1 赞助商奖金模板
赞助商以任何金额资助奖金池。建议等级：
| 等级 | 金额 | 建议阈值 |
|---|---|---|
| 种子 | $5,000–$15,000 | 可部署（综合分数 ≥ 0.70）+ 社区验证 |
| 突破 | $25,000–$50,000 | 流畅（综合分数 ≥ 0.85）+ 社区验证 |
| 大奖 | $100,000+ | 流畅 + 多寄存器覆盖 + 部署集成 |
赞助商也可以资助：
- 改进赏金——每 5 点 chrF++ 改进超过当前最佳的固定支付
- 寄存器奖——特定寄存器的单独奖项（正式、仪式、教育）
- 速度奖——最佳成本调整分数（SCORING_SPEC §6.3）
4.2 奖金池托管
所有奖金都由托管方（由项目或指定受托人管理）托管，直到满足阈值条件。如果奖金在未被领取的情况下过期，资金将返还给赞助商或按赞助商的意愿重定向到新奖金池。
5. 取消资格
如果出现以下情况，提交将被取消资格：
- 在评估数据上训练。 方法暴露于
gold_standard或held_out语料库条目。（由沙箱执行在架构上防止——但如果发现污染证据，结果将被作废。） - 不可重现。 治理组织无法在 ±2% 内重现分数。
- 未声明或不符合条件的依赖。 该方法需要运行时访问其依赖清单之外的外部服务，或其有效依赖类别是 A2 或 X（§1.6）。通过评估网关路由的声明类别 A1 LLM 推理是允许的；任何其他运行时网络依赖——以及任何类别的任何未声明依赖——都是取消资格的。
- 未签署参与条款。 所有团队成员必须同意所有权转移。
- 检测到作弊。 输出针对指标而不是翻译质量进行了优化（由社区审查和/或 BENCHMARK_SPEC §9.3 中的反作弊检查捕获）。
6. 与其他规范的关系
| 本文档 | 参考 | 用于 |
|---|---|---|
| §2 阈值条件 | SCORING_SPEC §4（综合分数）、§2.1–2.2（指标）、§5（等级） | 指标定义和标度 |
| §2 社区验证 | BENCHMARK_SPEC §7 | 人工审查协议 |
| §3 沙箱执行 | BENCHMARK_SPEC §8.2 | 主权机制 |
| §3 所有权转移 | BENCHMARK_SPEC §8.3 | IP 转移条款 |
| §1.6 依赖类别 | 方法接口规范；方法提交协议 §2.6；BENCHMARK_SPEC §8.6 | 类别定义、可接纳性条款、沙箱网络政策 |
| §4 成本调整奖金 | SCORING_SPEC §6.3 | 成本调整公式 |
7. 代码–规范同步
7.1 规范源
本文档（arena/website/docs/specifications/prize-spec.md）是以下内容的规范源：
- 奖金池定义（§2）
- 阈值条件（§2.x）
- 申请流程（§3）
- 取消资格规则（§5）
7.2 实现要求
激活奖金池时：
- 排行榜 UI 必须显示活跃奖金及其阈值条件
- 满足自动化阈值（条件 1–3）的运行卡必须标记为社区审查
- 运行卡架构中的
quality_tier字段已捕获等级（"可部署"、"流畅"） - 工具中不需要新的代码更改——奖金规范是现有评分之上的政策层
奖金结构必须与所有权转移条款兼容。获胜者可以领取奖金，但如果方法达到可部署等级，该方法将成为治理组织的财产。这是设计使然——奖金资助创建属于语言社区的技术。