同じデータに二人が別のラベルを付けたとき、「三人目に決めてもらう」だけでは問題が残ることがあります。一人が根拠を見落としたのか、ラベルの境界が曖昧なのか、判断に必要な資料がそもそも渡されていないのかによって、直すべき場所が違うからです。
アジュディケーションは、複数人の判定が割れた項目を確認し、利用目的に照らして採用するラベルや次の処理を決め、その根拠を記録する工程です。対象は「AとBに票が割れた項目」だけではありません。判断不能、根拠不足、作業指示の解釈違い、専門家への確認が必要な項目、入力データの欠損も、確認待ちとして取り出します。最終的に一つのラベルが付かない場合もあります。
最多票と、原因を調べた後の判断を分ける
三人中二人が「該当」と答えたなら、最多票は「該当」です。しかし、二人が同じ欠けた資料を見ていた場合や、三人目だけが重要な条件に気づいた場合、票数だけでは妥当性を判断できません。一致率は、判断が割れやすい場所を探す手掛かりにはなりますが、不一致の理由や正解を示すものではありません。
評価者間の不一致を解消する手順を検討した原論文は、独立した注釈を比較した後、作業内容や指示の曖昧さ、専門知識の差、判定の不整合、解釈の違い、単純ミスなどを調べる工程を提案しています。ここで必要なのは、最多票を確定欄へ移す操作ではなく、票が割れた原因に応じて処理を選ぶことです。
不一致を一件ずつ原因に振り分ける
たとえば「検討します」という発話を「承諾」と「保留」に分ける作業では、前後の会話を見落とした人がいる場合と、会話を全部読んでも両方に解釈できる場合は異なります。確認時には、少なくとも次の原因を区別します。
- 根拠の見落とし:規程の但し書きや会話の前後に、判定を変える情報がある。
- 指示・定義の曖昧さ:「承諾」と「保留」の境界や優先規則が書かれていない。
- 複数ラベルが成立する境界例:同じ発話に二つの役割や感情が含まれる。
- 判断材料の不足:前の発話や参照文書がなく、情報を補わないと選べない。
- 専門知識・事実確認の不足:一般の評価者だけでは、専門用語や記述の真偽を確認できない。
- 入力・画面の不備:音声が途切れる、画像が欠ける、参照資料の表示が失敗している。
- 操作ミス:理由は「保留」を支持しているのに「承諾」のボタンを押している。
- 妥当な見方の相違:必要な情報を共有しても、自然さや好ましさへの判断が分かれる。
一件に原因が複数ある場合は、主因と副因を記録します。「評価者が違う答えを付けた」という結果だけで作業者の能力を評価すると、資料や画面の不備を見逃します。
原因に応じて、判断できる人へ回す
裁定の担当者を一人に固定せず、確認する内容で分けます。通常の評価者には根拠の再確認や操作ミスの確認を依頼できます。上位検品者は既存の指示と過去の類似例を照合します。ラベルの境界が決まっていなければ仕様設計者へ、研究目的や許容する解釈を決める必要があれば発注者・研究者へ、専門的な事実確認が必要ならその分野の専門家へ回します。
振り分けの時点で「通常の再確認で処理できる」「指示の変更を要する」「外部の根拠確認を要する」を区別しておくと、すべての不一致が責任者一人の確認待ちになることを防げます。複数ラベルを許すか、一つに絞るかも、検品者のその場の判断ではなく、データの使用目的を決める側と確認します。
裁定者には元の理由を渡し、票数の見せ方を決める
アジュディケーターには、対象データ、各評価者の元ラベルと理由、参照資料、ラベル定義、適用された仕様書の版、過去の類似例を渡します。元の理由がないと、根拠の見落としと、異なる根拠に基づく解釈の相違を分けにくくなります。
ただし最初から「三人中二人はA」と強調すると、票数に判断が引っ張られる可能性があります。難しい項目は、まず対象と現行の指示だけで独立に判定し、その後に元の票と理由を開いて相違を調べる方法があります。元の評価者同士で検討する場合も、最初の独立した回答を消さず、話し合い後の結論を別に残します。
最終判断には、ラベル以外の行き先も用意する
確認後の選択肢は、既存ラベルのAまたはBだけにしません。根拠が確認できれば一方を採用し、複数の意味を対象にする設計なら複数ラベルを許容します。判断材料が足りなければ保留し、元データが壊れていれば除外または再取得します。専門的な確認が必要なら担当者へ回し、定義の問題なら仕様書を修正して再判定します。
たとえば画像の一部が欠けて金額を読めない項目に、裁定者が推測で金額を付けても、データは改善しません。「判定不能として除外」と判断すること自体が、根拠を持った裁定です。一方、発話に喜びと安堵の両方が認められるなら、目的に応じて複数ラベルや票の分布を残す方が適切な場合があります。
元ラベルと裁定結果を別の記録にする
裁定後のラベルで評価者の元の回答を上書きすると、何が割れ、なぜ直したか追えなくなります。項目ごとの原判定と、裁定記録を結び付けて保存します。
| 記録項目 | 残す内容 |
|---|---|
| item_id | 元データと裁定記録を結ぶ、変更後も使える識別子 |
| 評価者ごとの元ラベル・判断理由 | 評価者IDとともに、独立判定時の回答と根拠をそのまま保持 |
| 仕様書バージョン | 各評価者が判定時に使用した版 |
| 不一致の原因分類 | 根拠の見落とし、定義の曖昧さ、入力不備などの主因・副因 |
| アジュディケーターID | 確認と最終判断を担当した人 |
| 最終判断・根拠 | 採用ラベルまたは複数ラベルと、その判断に使った資料・条項 |
| 保留・除外・再判定の別 | 確定できない項目の行き先と、次に確認する担当者 |
| 判断日時 | 裁定日、再判定日、変更があった場合の履歴 |
一つのitem_idに複数の評価者の記録と、必要なら複数回の裁定履歴を結び付けます。「最終判断」は原判定とは別の項目です。これにより、確定ラベルだけを使う納品形式と、票の分布や不一致理由まで調べる研究用の形式を、同じ記録から作れます。
仕様を直したら、すでに一致した項目も調べる
「検討します」を保留とする条件を新たに決めた場合、今回割れた一件だけを直して終わりにはできません。旧基準のまま処理された同種の発話には、評価者全員が同じ解釈で一致した項目も含まれるからです。不一致解消手順の原論文も、重要な用語の解釈を改めた場合、既存の注釈を見直す必要を具体例とともに論じています。
まず変更が影響するラベル、期間、作業者、資料、データ区分を特定します。通知だけで適用できる小さな明確化か、作業を止めて再説明・再試行すべき変更かを判断します。既処理分を全件直すか対象区分だけ再確認するか、発注者・研究者と範囲を決めます。新基準の適用開始日またはバッチ、仕様書の版、旧版で処理済みのitem_idを記録し、異なる基準のラベルが無区別に混ざらないようにします。
不一致を次の作業指示へ戻す
裁定記録を集計し、どのラベル、評価者、入力形式、データ区分で不一致や保留が多いか見ます。特定の境界で割れるなら対照的な例題を足し、定義が読みにくければ書き直し、画面の欠損が原因なら表示や入力検査を直します。根拠の見落としが続く場合は、対象者への追加研修も検討します。
ただし、不一致率だけで評価者を低品質と決めません。VariErr NLIの研究は、無効な理由による注釈の誤りと、妥当な理由に基づくラベルの違いを分けて調べています。感情、自然さ、好ましさ、倫理判断などでは、一つの確定ラベルだけにすると異なる見方を失うことがあります。判断の分布を扱うDisCoの研究が示すように、目的によっては個々の票とその分布を分析対象として残せます。
裁定工程の成果は、一件の「正解」を埋めることだけではありません。なぜ判断が割れたかを記録し、必要な人へ確認を回し、影響する既処理分まで含めて次の作業基準を整えることです。
RESEARCH DATA SUPPORT
評価者間の不一致確認とアジュディケーションをご相談いただけます
株式会社イングクラウドでは、評価者の募集、作業指示の設計、複数人によるアノテーション、不一致ケースの抽出と原因整理、裁定結果の記録を支援しています。仕様修正後の再判定範囲の整理から納品前の検品までご相談いただけます。
