メインコンテンツへスキップ

よくある質問

要約。 MT Eval Arena に関するよくある質問への回答です。スコアリングの仕組み、失格となる条件、FST のない言語への対応方法、モデルとパラメータの推奨事項、および提出プロセスについて説明します。

スコアリングとメトリクス​

ハーネスはどのメトリクスを計算しますか？​

ハーネスは Plains Cree（現在のベンチマーク言語）に対して5つのメトリクスを計算します。そのうち3つは言語に依存せず、どの言語でも使用できます。残りの2つは現在 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メトリクスの全一覧については Scoring Specification §2 を参照してください。

複合スコアはどのように計算されますか？​

複合スコアは、利用可能なメトリクスの加重平均であり、0.0–1.0 のスケールに正規化されます。重みは2つのプロファイルで定義されています：

  • プロファイル A（FST のある言語）：9メトリクス、構造的メトリクス（FST + 形態的正確性）が複合スコアの重みの40%を占めます
  • プロファイル B（FST のない言語）：8メトリクス、意味スコアと chrF++ が同等の最高重みを持ちます

メトリクスが利用できない場合、その重みは残りのメトリクスに比例して再配分されます。つまり、初期段階のベンチマーク（chrF++ と完全一致のみが利用可能な場合）でも有効な複合スコアが生成されます — 実効的な重みは利用可能なものを反映するだけです。

重みの全テーブル、正規化ルール、および除外の根拠は Scoring Specification §4 に記載されています。 ハーネスのコードはこれらのテーブルを mt_eval_harness/scoring.py に反映しています。chrF++ は重み付け前に100で割って正規化されます。コードスイッチングと幻覚の発生率は反転されます（低いほど良い）。

品質ティアとは何ですか？​

品質ティアは、複合スコアの範囲にマッピングされたヒューリスティックなラベルです。スコアが実際に何を意味するかを伝えるために役立ちます：

ティア複合スコア範囲解釈
Baseline0.00 – 0.30実用的な品質に達していません。手法の大幅な改善が必要です。
Emerging0.30 – 0.50可能性を示しています。一部の翻訳は正確ですが、一貫性がありません。
Functional0.50 – 0.70人間によるレビューを前提とした参照用途に使用可能です。レビューなしでの展開には適していません。
Deployable0.70 – 0.85定期的なレビューを伴う本番環境での使用に対応しています。所有権移転の対象となります。
Fluent0.85 – 1.00ネイティブに近い品質です。監視なしでの展開に適しています。

品質ティアと検証ティアの違いは何ですか？​

品質ティアは自動スコアが何を意味するかを表します（Baseline → Fluent）。検証ティアは誰が結果を検証したかを表します：

検証ティア意味
Self-benchmarked提出者自身がハーネスを実行しました。スコアはもっともらしいですが、未検証です。
GDS Verifiedメンテナーが提出された手法の設定を使用して結果を再現しました。
Community Validatedバイリンガルの話者が翻訳をレビューし、品質を確認しました。

手法が「Deployable」品質でありながら「Self-benchmarked」検証にとどまる場合があります — これはスコアが優れているように見えても、誰も独立して確認していないことを意味します。

提出と失格​

提出が失格になる条件は何ですか？​

以下の場合、提出は拒否またはフラグが立てられます：

  1. 評価データに手法が露出していた場合。 評価データセットのエントリを使用してトレーニング、ファインチューニング、フューショットプロンプト、またはその他の方法で利用した場合、スコアは人為的に高くなります。プロンプトに参照訳を使用することも含まれます。
  2. ランカードの整合性チェックに失敗した場合。 フィンガープリントは設定と一致している必要があります。改ざんされたランカードは拒否されます。
  3. 手法が TranslationMethod プロトコルを実装していない場合。 ハーネスは translate(entries, config) → results を期待しています。ハーネスをバイパスするカスタム統合は受け付けられません。

複数回提出できますか？​

はい。リーダーボードはすべての提出を追跡します。繰り返し実行できます — 何十もの実験を行い、最良のものだけを提出することができます。各提出には一意のフィンガープリントが記録されるため、どの実行がどのスコアを生成したかについて曖昧さはありません。

スコアを検証してもらうにはどうすればよいですか？​

  1. Self-benchmarked（自動）： すべての提出はここから始まります。
  2. GDS Verified： 手法を再現可能なパッケージ（コード + 設定 + コーチングデータ）として提出してください。メンテナーが同じデータセットに対して再実行し、スコアが一致することを確認します。
  3. Community Validated： 先住民族の言語の場合、バイリンガルの話者が翻訳のサンプルをレビューする必要があります。これは自動化できません — コミュニティの関与が必要です。

提出 API は稼働していますか？​

まだです。https://mtevalarena.org/api/leaderboard/submit エンドポイントは将来的な目標です。現在の提出は、ランカード JSON を results/ ディレクトリに含めた上で、eval harness リポジトリ へのプルリクエストで行ってください。

モデルとパラメータ​

どのモデルを使用すればよいですか？​

単一の最良モデルはありません — 言語ペア、予算、アプローチによって異なります。一般的なガイダンス：

言語タイプ推奨される出発点理由
高リソース（フランス語、スペイン語、日本語）google/gemini-2.5-flash または gpt-4o-mini高速、低コスト、強力なベースライン
LLM カバレッジがある程度ある低リソース（Quechua、Yoruba）google/gemini-2.5-pro または anthropic/claude-sonnet-4大規模モデルはより優れた潜在的知識を持っています
多合成語 / 極低リソース（Plains Cree、Inuktitut）google/gemini-2.5-pro とコーチングコーチングデータはモデルの選択よりも重要です。OMT-1600 は一部の多合成語言語（例：R1 ティアの CRK）を含みますが、標準的な BPE トークナイゼーションを使用しています — Arena でベースラインとしてベンチマークしてください。

eval ハーネスは OpenRouter を使用しているため、OpenRouter で利用可能なモデルはすべてベンチマーク可能です。利用可能なモデルを確認するには champollion models --method llm を実行してください。

温度はどのように設定すればよいですか？​

翻訳には一般的に低い値が適しています：

温度効果推奨用途
0.0 – 0.2高度に決定論的で一貫した出力本番手法、最終ベンチマーク
0.3 – 0.5若干のバリエーション、時折より創造的探索、初期の反復
0.6+高いバリエーション、予測不可能MT ベンチマークには推奨しません

温度はランカードに記録されるため、異なる温度は異なるフィンガープリントを生成します — それぞれ異なる実験として扱われます。

コーチングデータは効果がありますか？​

はい、低リソース言語では大きな効果があります。コーチングデータ（文法規則、辞書エントリ、スタイルノート）は LLM のシステムプロンプトに注入されます。Plains Cree では、コーチングされた手法が多合成語言語に対して生の LLM 手法を一貫して上回ります。これは汎用 LLM が多合成語への露出が限られており、形態的な認識を持たないためです。CRK 向けに特別にトレーニングされた OMT-1600 でさえ、多合成語の形態論を構造的に表現できない標準的な BPE トークナイゼーションを使用しています。コーチングデータは、モデルが欠いている言語的コンテキストを提供します。

高リソース言語（フランス語、スペイン語）では、モデルがすでに強力なベースライン知識を持っているため、コーチングの効果は小さくなります。

詳細な仕様については Coaching Data を参照してください。

FST と形態的検証​

言語に FST がない場合はどうすればよいですか？​

多くの言語には有限状態トランスデューサーがありません。それでも問題ありません — ハーネスは FST なしでも動作します。複合スコアはプロファイル B の重みを使用し（Scoring Specification §4.3 を参照）、意味メトリクスと表層メトリクスに重みをシフトします。FST 受理率はランカードで null としてマークされます。

既存の FST の主なレジストリ：

レジストリカバレッジURL
GiellaLTSámi、Cree、Inuktitut、その他の北極圏・亜北極圏言語giellalt.uit.no
ALTLabPlains Cree、Woods Cree、Ojibwealtlab.artsrn.ualberta.ca
Apertium約60言語ペア、主にヨーロッパ言語apertium.org
UniMorph150以上の言語の形態的パラダイムunimorph.github.io

FST を構築できますか？​

はい、ただし容易ではありません。FST は言語の形態的規則 — すべての有効な語形 — をエンコードします。構築には言語の深い言語学的知識が必要です。形態的文法（例：言語学部からのもの）にアクセスできる場合、HFST や Foma などのツールを使用して FST にコンパイルできます。

FST ゲーティングは実際にどのように機能しますか？​

FST ゲーティングパイプラインは次のように動作します：

  1. LLM が翻訳を生成する
  2. 出力の各単語が FST に対してチェックされる
  3. FST が拒否した単語は形態的に無効としてフラグが立てられる
  4. 手法はフィードバックを使用して再試行できる（「単語 X は有効ではありません、もう一度試してください」）
  5. 再試行後も残った無効な単語はログに記録される

FST 受理率は、検証を通過した単語の割合を測定します。完全な実例については FST-Gated Pipeline チュートリアル を参照してください。

データとデータセット​

新しい言語のデータセットを提供できますか？​

はい。Benchmark Specification §11 の最低要件：

  • 50件のゴールドスタンダードエントリ（ソース + 検証済み参照訳）
  • 30件の開発エントリ（小規模コーパスの場合、ゴールドスタンダードと重複可）
  • コミュニティの同意（先住民族の言語の場合、ガバナンス機関からの明示的な承認）
  • 出所ドキュメント（データの出所、適用されるライセンス）

新しいデータセットは自動的に新しいリーダーボードトラックを開きます。コントリビューターガイドについては For Language Communities を参照してください。

データセットはどのような形式にすればよいですか？​

標準フィールド名を使用した 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"
    }
  ]
}

完全なスキーマと難易度ティアの定義については Datasets を参照してください。

主権と所有権​

先住民族の言語向けに構築された手法は誰が所有しますか？​

先住民族の言語の場合、Deployable ティア（複合スコア ≥ 0.70）に達し、かつコミュニティ検証に合格した手法は 所有権移転 プロセスを開始します。コードの所有権は研究者から言語コミュニティのガバナンス組織に移転されます。

研究者が保持するもの：

  • 出版権（手法に関する学術論文）
  • リーダーボード上のクレジット
  • 同じ技術を他の言語に適用する権利

ガバナンス組織が得るもの：

  • 手法コードとコーチングデータの完全な所有権
  • 展開に関する管理権（いつ、どこで、どのように）
  • API 使用からの収益（コミュニティ90%、インフラ10%）

先住民族以外の言語に champollion を使用する場合、主権に関する懸念はありますか？​

いいえ。標準的な言語（フランス語、日本語、スペイン語など）については、主権に関する考慮事項はありません。champollion を通常通り使用してください — 翻訳、同期、公開を自由に行えます。主権フレームワークは、データガバナンスの原則（OCAP®、CARE、Te Mana Raraunga）が特別な配慮を必要とする先住民族およびコミュニティ管理の言語に特化して適用されます。

関連情報​