評価コーパス設計フレームワーク
バージョン: 1.0 ステータス: ドラフト 目的: 有効で信頼性が高く、言語的に意味のある翻訳品質評価を生み出す評価コーパスを構築するための体系的な方法論。Champollion 評価データセットの設計・構築・保守方法に関する唯一の信頼できる情報源です。
1. 設計原則
1.1 — 公開ベンチマークを使用しない理由
公開並列コーパス（FLORES+、Tatoeba、WMT テストセット、OPUS）は開発およびデバッグ目的で利用可能ですが、公式リーダーボード評価からは除外されています。理由は明確です。
汚染（Contamination）の問題です。 フロンティア LLM は膨大なウェブスクレイピングデータで学習されています。公開されている並列テキスト、特に精選された広く引用されているベンチマークデータセットに含まれるものは、学習データに含まれている可能性が高いです。GPT-4o を FLORES+ で評価して 85 chrF++ というスコアが出た場合、「モデルが翻訳を得意としている」のか「モデルがこれらの特定の文ペアを記憶している」のかを区別することができません。これは理論上の懸念ではなく、MT ベンチマークにおける汚染効果が測定可能であることが研究によって実証されています。
Champollion においてこの問題が特に重要な理由：
- リーダーボードは主に LLM ベースの手法を比較している
- 私たちの価値提案は誠実で厳密な評価である
- ターゲットユーザー（言語コミュニティ）はこれらのスコアに基づいて導入の意思決定を行う
1.2 — 基本要件
すべての Champollion 評価コーパスは以下の要件を満たす必要があります。
| 要件 | 根拠 |
|---|---|
| 人間が執筆したもの | 合成データは不可。すべてのソーステキストおよびリファレンス翻訳は人間が執筆したものでなければなりません。LLM はアライメントや書式整形の補助には使用できますが、コンテンツの生成には使用できません。 |
| 並列形式で公開されていないもの | ソーステキストは公開されていてもよく、リファレンス翻訳も公開されていてもよいですが、特定のペアリングがダウンロード可能な並列コーパスとして存在してはなりません。 |
| 出所の追跡 | すべてのエントリに、ソース文書・翻訳者・ライセンス・日付を含む出所の記録が必要です。 |
| 言語学的根拠に基づくもの | カバレッジはランダムサンプリングではなく、類型論的特徴によって導かれなければなりません。 |
| ドメイン層別化 | エントリは定義されたテキストドメインにわたって、制御された代表性をもって分布していなければなりません。 |
| 難易度の段階付け | エントリは構造的複雑さに基づいて難易度ティア（1〜5）を割り当てられなければなりません。 |
| バージョン管理 | コーパスのバージョンはコンテンツハッシュで管理されます。スコアは同一バージョン内でのみ比較可能です。 |
| コミュニティによるレビュー可能性 | リファレンス翻訳は言語コミュニティのメンバーがレビューできなければなりません。 |
2. ソーステキストの選定
2.1 — ドメイン分類体系
Champollion は学術的な演習ではなく、実際の導入コンテキストにおける翻訳を評価します。ドメイン分類体系は、翻訳ユーザーが実際に遭遇するテキストタイプを反映しています。
| ドメイン | コード | 説明 | ソース例 |
|---|---|---|---|
| ソフトウェア UI | ui | ボタンラベル、メニュー項目、エラーメッセージ、ツールチップ、オンボーディングフロー | オープンソースアプリの文字列、ドキュメントポータル |
| 公式・行政 | admin | 政府文書、法的通知、フォーム、政策声明 | 政府の公開刊行物、自治体文書 |
| 教育 | edu | 教科書コンテンツ、授業教材、説明文 | 出版された教育教材、指導ガイド |
| 物語・文学 | lit | 物語、文化的テキスト、口承史の書き起こし | 出版書籍、文化アーカイブ（許可を得たもの） |
| 会話 | conv | 対話、チャット形式のやり取り、インフォーマルな書き言葉 | 公開対話コーパス、脚本、インタビュー書き起こし |
| 技術 | tech | API ドキュメント、README ファイル、技術仕様書 | オープンソースプロジェクトのドキュメント |
| 健康・医療 | health | 患者向け医療情報、公衆衛生メッセージ | 政府の健康関連刊行物 |
| ニュース・ジャーナリズム | news | ニュース記事、プレスリリース、時事問題 | 地域新聞、先住民族メディア |
2.2 — ドメイン分布
標準的な評価コーパスは以下の分布を目標とすべきです。正確なパーセンテージは、対象コミュニティにとって最も関連性の高いテキストタイプに基づいて言語ペアごとに異なる場合があります。
| ドメイン | 目標 % | 根拠 |
|---|---|---|
| ソフトウェア UI | 25% | champollion CLI ユーザーにとっての主要な導入コンテキスト |
| 公式・行政 | 15% | 法的影響を伴う重要度の高い翻訳 |
| 教育 | 15% | 言語復興における中核的なユースケース |
| 物語・文学 | 10% | 文化的ニュアンスと文学的レジスターをテスト |
| 会話 | 10% | インフォーマルなレジスターと自然な話し言葉パターンをテスト |
| 技術 | 10% | 精度と用語の一貫性をテスト |
| 健康・医療 | 10% | 重要度が高く、ドメイン固有の語彙をテスト |
| ニュース・ジャーナリズム | 5% | 現代的な語彙と中立的なレジスターをテスト |
2.3 — ソース選定基準
新しいコーパスのソーステキストを選定する際：
-
ライセンスの適合性。 ソーステキストは評価コーパスでの使用を許可するライセンスのもとにある必要があります。CC BY、CC BY-SA、またはパブリックドメインを優先してください。ライセンスを記録してください。
-
新しさ。 過去 10 年以内に公開されたテキストを優先してください。言語は進化します。特にテクノロジー、ガバナンス、医療に関する語彙は変化が著しいです。
-
レジストの多様性。 各ドメイン内で、異なるフォーマリティレベルのテキストを求めてください。政府のプレスリリース（フォーマル）と政府のソーシャルメディア投稿（インフォーマル）はどちらも
adminドメインですが、レジストが異なります。 -
文化的関連性。 先住民族言語および少数言語については、たまたま並列で存在するテキストよりも、コミュニティにとって重要なテキスト（土地管理文書、その言語による教育教材、文化保存テキストなど）を優先してください。
-
機械翻訳されたソースは不可。 「並列」文書が元のテキストを Google 翻訳にかけてポストエディットすることで作成されたものである場合、リファレンス翻訳として受け入れられません。リファレンスは独立した人間による翻訳でなければなりません。
3. 難易度ティアシステム
3.1 — ティアの定義
すべてのエントリは、翻訳難易度（手法によって異なる）ではなく、ソーステキストの構造的複雑さに基づいて難易度ティア（1〜5）が割り当てられます。
| ティア | ラベル | 構造的特徴 |
|---|---|---|
| 1 | 初級 | 単純な文。単一節。現在時制。一般的な語彙。慣用句なし。埋め込み構造なし。 |
| 2 | 中級 | 重文。接続詞で結ばれた 2 つの節。過去・未来時制。一部のドメイン語彙。 |
| 3 | 上級 | 複文。従属節、関係節。混合時制。ドメイン固有の専門用語。受動態。 |
| 4 | 専門家 | 複数の埋め込み節。法律・技術的レジスト。条件構造。抽象的概念。文化的参照。 |
| 5 | 最高難度 | 複数の課題が同時に存在する密度の高い文章：入れ子状の従属、曖昧な代名詞参照、文化的慣用句、混合レジスト、希少語彙。 |
3.2 — 言語学的根拠に基づく難易度要因
構造的複雑さに加えて、難易度はソース言語とターゲット言語の類型論的距離によって調整されます。これらの要因は WALS の類型論的特徴と言語カードの分類データから導かれています。
| 要因 | 低難易度 | 高難易度 |
|---|---|---|
| 語順 | 同じ基本語順（例：SVO→SVO） | 異なる基本語順（例：SVO→SOV） |
| 形態論的タイプ | 類似したタイプ（例：分析的→分析的） | 異なるタイプ（例：分析的→多統合的） |
| 文法的性 | 同じ体系または性なし | ソースに性なし、ターゲットに複雑な性体系あり |
| 敬語・レジスト | レジストマーキングなし | ターゲットに複雑なレジスト体系あり（例：日本語、韓国語） |
| 文字 | 同じ文字 | 異なる文字（音訳が必要） |
| 有生性 | 有生性の区別なし | ターゲットに有生性に基づく一致あり（例：クリー語） |
| 証拠性 | 証拠性なし | ターゲットが情報源を文法的にマークする |
3.3 — ティア分布
標準的なコーパスはおおよそ以下の分布を持つべきです。
| ティア | 目標 % | 根拠 |
|---|---|---|
| 1 | 15% | ベースラインの確立 — 質の低い手法でもこれらは処理できるはず |
| 2 | 25% | 実用的な翻訳の中核 |
| 3 | 30% | 手法の品質差が顕在化する領域 |
| 4 | 20% | 良い手法と優れた手法を区別する |
| 5 | 10% | 上限テスト — ほとんどの手法はうまく処理できない |
4. リファレンス翻訳の品質
4.1 — 翻訳者の要件
リファレンス翻訳は以下の条件を満たす人間が作成しなければなりません。
- ターゲット言語の流暢な話者（L1 または同等レベル）
- ソース言語とターゲット言語の両方で読み書きができる
- テキストのドメインに精通している（医療テキストには医療翻訳者など）
- 独立している — 翻訳者は翻訳中に同じテキストの MT 出力にアクセスしてはなりません
4.2 — 翻訳ブリーフ
すべての翻訳者は以下を含むブリーフを受け取ります。
- 使用するレジスト（フォーマル、会話的など）
- 対象読者（一般市民、専門家、子どもなど）
- 言語コミュニティ固有の用語規則
- 明示的な指示：「言葉ではなく意味を翻訳してください。自然に聞こえる翻訳は逐語訳よりも価値があります。」
4.3 — 品質保証
-
二重翻訳。 理想的には、各エントリに異なる翻訳者による 2 つの独立したリファレンス翻訳があります。これが実現できない場合は、ティア 4〜5 の二重翻訳を優先してください。
-
コミュニティレビュー。 リファレンス翻訳は、その翻訳を作成していない少なくとも 1 名の追加話者によってレビューされるべきです。
-
許容可能なバリアント。 各リファレンスについて、既知の許容可能なバリアント（語順、正書法の慣習、方言形式）を記録してください。これらは
equivalent_match_rateメトリクスに反映されます。
4.4 — 不良なリファレンスの条件
| 問題 | 評価を無効にする理由 |
|---|---|
| 機械翻訳後にポストエディットされたもの | ポストエディットは MT の構造を保持するため、より自然な翻訳を生成する手法にペナルティを与える |
| 流暢な話者ではなく学習者が翻訳したもの | リファレンスに誤りが含まれる可能性があり、正しい MT 出力にペナルティを与える |
| 過度に逐語的なもの | 自然な翻訳は逐語的なリファレンスに対して低いスコアになる |
| 曖昧なソースに対して単一の有効な解釈のみ | 有効な代替解釈にペナルティを与える |
5. 汚染防止
5.1 — 汚染の脅威モデル
| 脅威 | 説明 | 緩和策 |
|---|---|---|
| 学習データの重複 | LLM が並列コーパスで学習されている | 並列コーパスを公開しない |
| フューショットリーク | 手法の作者が評価エントリをフューショット例として使用する | フィンガープリントチェック：プロンプト内のエントリを検出してフラグを立てる |
| 間接的汚染 | ソーステキストが LLM の学習データに存在する（単言語） | 許容範囲 — 単言語ソーステキストは想定内。ペアリングが新規であることが必要。 |
| クラウド汚染 | コミュニティレビュアーがエントリを公開共有する | ライセンス条件により並列コーパスの再配布を禁止 |
5.2 — コーパスの秘密保持ティア
| ティア | 可視性 | 用途 |
|---|---|---|
| 公開開発セット | 完全公開 | 手法の開発、デバッグ、回帰テスト。スコアはリーダーボードに公開されない。 |
| ホールドアウト評価セット | ソーステキストは公開、リファレンスは非公開 | 公式リーダーボード評価。手法はソーステキストを受け取り翻訳を返す。スコアリングはサーバーサイドで実施。リファレンスは手法に公開されない。 |
| ゴールドスタンダードセット | 完全非公開、コミュニティ管理 | コミュニティ検証済み評価。ガバナンス組織が管理。「Community Validated」検証ティアに使用。 |
5.3 — ローテーションポリシー
評価コーパスは定期的にローテーションされるべきです。
- コーパスが 12 ヶ月使用された後、代替コーパスの構築を開始する
- 旧コーパスを「開発セット」ステータス（公開）に移行する
- 新コーパスを「ホールドアウト評価セット」に昇格させる
- これにより、固定されたターゲットに対する反復的な最適化による段階的な汚染を防止する
6. コーパス構築ワークフロー
6.1 — ステップバイステップのプロセス
Step 1: Language Pair Selection
└─ Identify target language, read language card
└─ Review typological features (WALS), contact influences, scripts
└─ Identify which difficulty factors apply
Step 2: Source Text Curation
└─ Identify candidate source documents per domain
└─ Verify licenses
└─ Extract candidate sentences/segments
└─ Classify by domain and preliminary difficulty tier
Step 3: Segment Selection
└─ Sample segments to match domain distribution (§2.2)
└─ Sample segments to match difficulty distribution (§3.3)
└─ Ensure linguistic phenomenon coverage (§6.2)
└─ Target minimum corpus size (§6.3)
Step 4: Reference Translation
└─ Assign segments to qualified translators
└─ Provide translation brief
└─ Collect translations
└─ Dual-translate Tier 4–5 entries
Step 5: Quality Assurance
└─ Community review of references
└─ Document acceptable variants
└─ Flag and resolve disagreements
Step 6: Metadata & Packaging
└─ Assign final difficulty tiers
└─ Add provenance metadata per entry
└─ Content-hash the corpus for versioning
└─ Package as corpus JSON per harness spec
Step 7: Registration
└─ Register in Supabase datasets table
└─ Add to ATTRIBUTION.md if new sources used
└─ Document in arena website
6.2 — 言語現象のカバレッジ
すべてのコーパスには、言語ペアに関連する特定の言語現象をテストするエントリを含める必要があります。これらは言語カードの linguisticChallenges および contactInfluences フィールドから導かれます。
普遍的な現象（すべての言語ペア）：
- 代名詞解決（曖昧な先行詞）
- 否定（単一、二重、スコープ）
- 量化詞（all、some、none、most）
- 時間表現（相対的な日付、期間）
- 固有表現（人名、地名、組織名）
- 数値と計量
- リストと列挙
ペア固有の現象（言語カードより）：
- 多統合的ターゲットの場合：複雑な動詞形態論、組み込み
- 性を持つターゲットの場合：性の一致、中立・包括的な参照
- SOV ターゲットの場合：節末動詞、後置詞
- 声調言語の場合：声調に依存する意味の区別
- 敬語言語の場合：レジストマーカー、社会的文脈
- 接触言語の場合：コードスイッチングの境界、借用語の統合
6.3 — コーパスの最小サイズ
統計的信頼性には最小エントリ数が必要です。これらは対応ブートストラップ信頼区間の要件（significance.py より）に基づいています。
| 目的 | 最小エントリ数 | 推奨 |
|---|---|---|
| 開発セット | 50 | 100〜200 |
| ホールドアウト評価セット | 100 | 200〜500 |
| ゴールドスタンダードセット | 200 | 500+ |
| ドメインごとの最小 | 10 | 25+ |
| ティアごとの最小 | 10 | 20+ |
評価に最低 100 エントリが必要な理由は？ 約 100 エントリ未満では、対応ブートストラップ有意性検定（1,000 リサンプル）は chrF++ で約 5 ポイント未満の差を信頼性をもって検出できません。200 エントリ以上あれば、p<0.05 で約 2 ポイントの差を検出できます。
7. コーパス JSON フォーマット
すべてのコーパスエントリはハーネス仕様に従います。
{
"id": "edtekla-dev-v1-042",
"source": "The school board will meet on Tuesday to discuss the new curriculum.",
"reference": "ᑭᓯᑭᓄᐦᐊᒫᑐᐏᓐ ᑲ ᐃᔑ ᐱᒥᐸᔨᐦᑕᐦᒃ ᑭᔅᑭᓄᐦᐊᒫᑐᐏᓇ ᐁ ᐃᔑ ᒫᒥᑐᓀᔨᐦᑕᐦᒃ ᐅᔥᑭ ᑭᔅᑭᓄᐦᐊᒫᑫᐏᓂᔭ ᓂᔓ ᑭᔑᑲᐤ",
"acceptable_variants": [
"ᑭᔅᑭᓄᐦᐊᒫᑐᐏᓐ ᓂᔓ ᑭᔑᑲᐤ ᑲ ᐃᔑ ᒫᒥᑐᓀᔨᐦᑕᐦᒃ ᐅᔥᑭ ᑭᔅᑭᓄᐦᐊᒫᑫᐏᓂᔭ"
],
"domain": "edu",
"difficulty": 3,
"phenomena": ["temporal_expression", "named_entity", "future_tense"],
"provenance": {
"source_doc": "EdTeKLA Module 4, Unit 7",
"source_license": "CC BY-NC-SA 4.0",
"translator": "anonymous-speaker-001",
"translator_qualification": "L1 Plains Cree, certified translator",
"translation_date": "2025-11-15",
"reviewer": "anonymous-speaker-002",
"review_date": "2025-12-01"
}
}
8. ゲーミング対策
8.1 — コーパスの完全性
| 対策 | 実装 |
|---|---|
| コンテンツハッシュ | コーパスバージョン = ソートされたエントリ ID とリファレンスの SHA-256。変更があれば新しいバージョンが生成される。 |
| エントリフィンガープリント | 各エントリにはコンテンツ由来の ID がある。変更されたコーパスに対して結果を提出した場合、フィンガープリントが一致しない。 |
| ホールドアウトの強制 | 公式評価では、手法はソーステキストのみを受け取る。リファレンスは公開されない。スコアリングはサーバーサイドで実施。 |
| ローテーションスケジュール | 固定されたターゲットに対する長期的な最適化を防ぐため、コーパスは年次でローテーションされる。 |
8.2 — 提出の完全性
| 対策 | 実装 |
|---|---|
| 決定論的フィンガープリント | 実行設定（モデル、温度、プロンプト、コーパスバージョン）がハッシュ化される。同一の設定は同一のフィンガープリントを生成する。 |
| チェリーピック検出 | 提出者は最良の結果だけでなく、すべての実行を開示しなければならない。同一フィンガープリントの複数提出はフラグが立てられる。 |
| 汚染チェック | 評価エントリが手法のプロンプトやコーチングデータにそのまま含まれている場合、提出は失格となる。 |
9. 既存コーパス
9.1 — EDTeKLA 開発セット v1
| プロパティ | 値 |
|---|---|
| ID | edtekla-dev-v1 |
| 言語ペア | EN → CRK（平原クリー語、SRO） |
| エントリ数 | 404（master_corpus.json：62 ゴールド + 342 教科書）；利用可能な合計 548 |
| ドメイン | 教育（100%） |
| ティア | 1〜5（エントリ監査ごとに分布は TBD） |
| ライセンス | CC BY-NC-SA 4.0 |
| ステータス | 開発セット（公開） |
制限事項： 単一ドメイン（教育のみ）。ドメイン層別化なし。ティア割り当ては監査が必要な場合があります。コーパスサイズが小さいため、有意性検定の統計的検出力が限られます。
9.2 — 計画中のコーパス
| コーパス | 言語ペア | ステータス | オーナー |
|---|---|---|---|
| EN → TL（フィリピン語）カスタムコーパス | EN → TL | 計画中 | プロジェクトオーナー |
| EN → CRK ホールドアウトセット | EN → CRK | 将来（コミュニティパートナーが必要） | コミュニティガバナンス組織 |
10. 言語カードとの統合
コーパスフレームワークは言語カードシステムと統合されています。
-
ドメイン選定はカードの
linguisticChallengesを参照します。言語に固有の課題（多統合性、声調、有生性）がある場合、コーパスにはそれらをテストするエントリを含める必要があります。 -
難易度の調整はカードの
classificationを使用します。ソース言語とターゲット言語の語族間の類型論的距離が、何が「難しい」かに影響します。 -
レジストのカバレッジはカードの
registersを使用します。言語に定義されたレジストがある場合（formal-filipino、taglish-professional、taglish-casual など）、コーパスには各レジストレベルのエントリを含めるべきです。 -
接触影響のテストはカードの
contactInfluencesを使用します。重い借用層を持つ言語（フィリピン語：スペイン語 + 英語 + アラビア語）については、手法が借用語を正しく処理するか、過剰翻訳するかをテストするエントリを含めてください。 -
文字処理はカードの
scripts[]を使用します。複数文字を持つ言語（セルビア語：キリル文字 + ラテン文字）については、正しい文字選択をテストするエントリを含めてください。
参考文献
- Champollion スコアリング仕様 — すべてのメトリクス、複合ウェイト、品質ティアを定義
- Champollion ベンチマーク仕様 — 評価プロトコル、コーパスフォーマット、データ主権
- WALS（World Atlas of Language Structures）— 類型論的特徴データベース
- Glottolog — 言語分類の信頼できる情報源
- ISO 639-3 — 言語識別標準
- EdTeKLA — 最初の評価コーパスのソース
このドキュメントは生きた仕様書です。新しいコーパスが構築され、知見が得られるたびに更新してください。