エラーの報告と修正の所有権
立場について。 数千の言語に関する事実と評価を公開するプラットフォームにとって、誤りは避けられません。しかし、避けられるのは、エラーが報告されたときに誰の言葉が信頼され、誰が修正を所有するかという問題です。私たちの答えはこうです。流暢な話者による報告は自動化処理より優先され、すべての修正には「誰が何をなぜ変更したか」という出所情報が付与され、コミュニティは自言語のデータの使用を撤回または拒否できます。これは礼儀としてではなく、アーキテクチャによって強制される性質です。
ほとんどのデータプラットフォームはエラー報告をサポートチケットとして扱います。ユーザーが苦情を申し立て、メンテナーが判断し、記録が静かに変更されます。先住民族の言語データにとって、このモデルは逆さまです。エラーを報告する人物は、たいていプラットフォームよりも権威があります。ある単語が誤りだと指摘する話者は「ユーザー」ではなく、代理情報を修正する一次情報源です。以下の設計は、この事実を真剣に受け止めることから導かれています。
2種類のエラー、1つの原則
プラットフォームが公開する主張には、誤りうる2種類があります。
- 言語に関する事実 — 評価を駆動する言語カード:分類データ、正書法、言語的特徴、適用されるメトリクス。カードが話者数の推定値、方言関係、文字体系のステータスを誤って記載している場合があります。
- 翻訳に関する判断 — 話者が誤りまたは不自然と判断するコーパス内の参照翻訳、有効な単語を拒否または無効な単語を受け入れる自動メトリクス、話者が受け入れられない出力に付与された「Deployable」バッジ。
両方に適用される原則は、Scoring Specification および Benchmark Specification §7 ですでに拘束力を持っています。自動化された出力は代理情報であり、話者が一次情報源です。 Speaker Validation Protocol §6 に公開されたコミットメントは率直に述べています。話者がリンターの判断を誤りだと言えば、私たちはリンターを修正します。
報告の流れ
以下は報告が辿る経路です。正直なステータス表示付きで示します。一部は現在稼働中であり、一部は仕様策定済みで未実装です。
誤った翻訳またはメトリクス判断の報告(現在稼働中、直接チャンネル経由)。 誤った参照翻訳、不当に拒否された単語、または受け入れられない「同等」表現を見つけた話者は、プロジェクトの公開リポジトリのイシュートラッカーまたはプロジェクトへの直接連絡を通じて報告できます。これの構造化バージョン — reject / gist / acceptable / excellent オプションと自由記述メモを備えた評価画面 — はコミュニティレビューインターフェースであり、Benchmark Specification §7.3 で仕様化されていますが、まだ公開されていません。公開されるまでは、報告は個人間で処理され、バリデーションタスク自体(有償の構造化話者レビュー — How Speakers Get Paid を参照)が主な修正パイプラインとなります。
言語カードの誤った事実の報告(現在稼働中、同じチャンネル)。 カードの修正も同じ経路を辿ります。報告、レビュー、バージョン管理された変更。カードは評価の動作を駆動するため — どのメトリクスを読み込むか、どのモデルが推奨されるか — カードの修正はスコアを変更する可能性があります。そのため、修正は記録されたデータ変更として適用され、サイレント編集は行われません。
次に何が起こるか — 誰が決定するか:
- 言語的判断はその言語の話者に帰属します。 ある形式が有効かどうか、2つの表現が同等かどうか、レジスターが適切かどうか — プラットフォームは答えを実装しますが、答えを提供するのはプラットフォームではありません。話者間で意見が分かれる場合(方言、正書法の慣習)、答えは変異として記録され、私たちが裁定するのではありません。コーパスとリンターのスキーマは、方言的変異形を1つの正解に強制するのではなく、許容可能な代替形としてタグ付けすることをサポートしています。
- コミュニティのデータに関する決定は、そのガバナンス組織に帰属します。 ガバナンス組織を持つ言語については、評価コーパスへの変更、封印されたテストセットへの修正の受け入れ、デプロイメントの結果はすべてその組織を通じて処理されます。これは OCAP® のControl原則をポスターではなくプロセスとして実装したものです。
- 機械的なエラーは単純に修正されます。 タイポ、リンク切れ、フィールドの解析ミス — 報告、修正、ログ記録。すべてに審議会が必要なわけではありません。
修正には出所情報が付与される
追跡できない修正は、単に新しい意見に過ぎません。すべての事実とすべての修正に3つの出所情報ルールが適用されます。
- すべての事実はその出典を明記します。 言語カードとコーパスエントリは、各値の出典を記録します。公開データセット、コミュニティの貢献、話者のレビューなどです。
- 派生値はプラットフォームのものとして、上流のものとしてではなく、ラベル付けされます。 プラットフォームが何かを計算する場合 — 集計値、再コーディング、複合スコア — それは上流ソースの名前で記録されるのではなく、上流ソースからのプラットフォーム派生として記録されます。上流データセットが公開していない数値について、そのデータセットが責任を問われたり、功績を認められたりすることはありません。
- 修正は記録の一部になります。 話者による修正は、古い値に取って代わる新しい帰属付きアサーション(話者の選択により実名または匿名 — バリデーション作業と同じ条件)として記録され、変更の履歴は監査可能な状態で残ります。コーパスバージョンはハッシュマニフェスト化されており(Corpus Partnership §4.4)、修正されたコーパスは明示的に新しいバージョンとなり、すべてのランカードはスコアリングに使用された正確なバージョンを記録します。古いスコアは解釈可能なまま残り、新しいスコアは修正を反映します。
拒否権、具体的に
「コミュニティのコントロール」は主張するのは簡単です。公開されたアーキテクチャでそれが何を意味するかを示します。
- 話者は自分の貢献を撤回できます。 話者はいつでも自分の評価を取り下げることができ、撤回によりすべての分析からそれらが削除されます(Speaker Validation §5)。話者はまた、問題があると判断した結果の公開に対して拒否権を持ちます。
- コミュニティは評価を完全に停止できます。 封印されたテストセットは暗号化されており、プラットフォーム単独では再構築できないようにキーが保持されています。コミュニティはキーの再構築への参加を拒否することで評価アクセスを取り消すことができます(Corpus Partnership §4.3)。「停止したい場合はどうするか」には明確な答えがあります。封印されたデータは公開されず、評価は終了します。
- スコアはコミュニティの決定を覆しません。 リーダーボードのトップに立つ手法であっても、ガバナンス組織が承認した場合にのみデプロイされます(Ownership Transfer)。自言語にMTをデプロイすべきでないと決定したコミュニティは、システムを壊しているのではなく、設計通りにシステムを使用しています(Translation Is Not Revitalization を参照)。
まだ構築されていないもの
このドキュメント群の他のページと同様に、正直に述べます。コミュニティレビューインターフェースは計画中であり、まだ公開されていません。現在の言語のいずれについても、ガバナンス組織はまだ設立されていません。Plains Cree ベンチマークのコミュニティ管理者は確認中であり、同意を得る前に管理者を公開することはありません。これらの要素が整うまで、修正は直接的で帰属可能なチャンネルを通じて処理され、公開された仕様 — このページではなく — がプロセスの拘束力ある説明として残ります。このページと仕様が矛盾する場合、仕様が優先され、その矛盾自体も報告すべきバグと見なします。
あなたにとっての意味
:::info コミュニティメンバーの方へ このプラットフォームにある自言語に関する何か — 事実、翻訳、ラベル — が誤っている場合、あなたの報告は一次情報源からの証言であり、トリアージされる苦情ではありません。修正を実名で記録するかどうかはあなたが決めます。あなたの貢献は後から撤回できます。そして、あなたのコミュニティはそのデータの使用を完全に停止できます。For Language Communities から始めるか、公開リポジトリでイシューを開いてください。 :::
:::info 研究者の方へ ここでの修正はサイレント編集ではなく、出所情報を持つデータです。コーパスバージョンはハッシュ化され、ランカードはスコアリングに使用された正確なバージョンを固定し、派生値は派生として明示されます。Arena のスコアやコーパスを基に研究を行う場合は、バージョンを引用してください。また、話者主導の修正の波をメトリクスの妥当性に関する知見として扱ってください。実際にそういうものだからです。 :::
:::info 開発者の方へ あなたのコードが変わらなくても、手法のスコアが正当な理由で変わることがあります。不当に拒否された単語が許可リストに追加され、参照翻訳が修正され、変異形クラスが修正される場合です。それを前提に設計してください。ランカードでコーパスバージョンを固定し(Run Card spec)、データセットの変更履歴を確認し、話者による修正を無償で得られる最も信頼性の高いエラーシグナルとして扱ってください。 :::
関連情報
- How Speakers Get Paid — ベンチマーク段階における話者の同じ権威について
- From Benchmark to Daily Use — 修正が公開ワークフローと交わる場所
- Data Sovereignty — この設計の背景にある原則:OCAP®、CARE、Te Mana Raraunga