Human annotation QA／disagreement adjudication for AI 評価

AI評価で人間注釈を使う場合、単一ラベルを「正解」として保存するだけでは評価品質を監査できません。rubricとannotator trainingを版管理し、複数annotatorの独立判断、agreement/disagreement、adjudication、rubric改訂、最終ラベルまでのprovenanceを残します。特に主観的・境界的な評価では、disagreementは単なる誤差ではなく、曖昧な指示、edge case、価値判断の差、評価対象の不確実性を示す信号になり得ます。

評価開始前に、評価目的、annotation unit、rubric version、label/score定義、必要な根拠、abstain/Unable-to-Determine条件、annotator要件、独立評価人数、calibration方法、agreement指標、adjudication条件、最終ラベルの決定規則を固定します。評価途中でrubricを変えた場合は同一条件の結果として混ぜず、revision境界を記録します。

重大な品質・安全性判断では、同一対象を複数annotatorが独立に評価できる設計を候補にします。先行annotatorのラベルやLLM judgeの結論を最初から見せるとanchoringが生じ得るため、独立判断と補助情報を見た後の再判断を区別して記録します。人数は固定の万能値ではなく、task subjectivity、risk、cost、必要なprecisionに応じて決めます。

inter-annotator agreementは「annotator同士がどの程度一致したか」を示しますが、真の正しさを直接証明しません。全員が同じ誤ったrubric解釈をすれば高agreementでも誤評価になり得ます。逆に、曖昧・主観的なtaskではdisagreementが対象の性質を反映する場合があります。agreement metricを使う場合は、categorical/ordinal/continuous、annotator数、missingness、class imbalanceなどmetricの前提をtaskへ合わせます。

NIST ARIA 0.1ではrisk assessment annotationを4名で実施し、pairwise calibration/adjudicationを通じてagreementとdisagreementの双方を信号として扱いました。267 annotated dialoguesの分析ではrisk violationとともに複数のdisagreementが記録され、mistake、edge case、instruction improvementを区別する材料として使われています。また、ARIA pilot全体では7名の訓練済みNIST staffが1,500件超のannotationを実施しました。

adjudicationでは、単に多数決で少数意見を消すのではなく、元ラベル、根拠、rubric clause、disagreement category、adjudicator、最終判断、rubric変更有無を保存します。高リスク項目、全員不一致、abstain集中、rubric外事例は専門reviewへ送る設計を候補にします。

繰り返し発生するdisagreementはrubric defect候補として扱います。曖昧な語、境界条件、例外、必要context、evidence requirementを特定し、calibration setへ追加します。ただしrubric改善後の結果を旧rubric結果へ無条件に上書きせず、rubric versionと再annotation範囲を記録します。

平均的なcaseだけでannotation品質を評価しません。通常caseに加え、edge case、high-impact failure、長文・多turn、tool-use、拒否、曖昧入力、文化・言語差、専門知識が必要なcaseを含めます。annotator単位・category単位・時間帯/sequence単位でdisagreementやabstentionの偏りを確認し、fatigueやrubric driftを疑える状態にします。

LLMをpre-label、explanation、adjudication補助へ使う場合、人間独立判断とLLM提示後判断を分離します。LLM judge/model/version、prompt、rubric、temperature等の条件、提示順序を記録し、LLMとの一致をhuman ground truthと同一視しません。human disagreementを学習・評価対象にするtaskでは、単一のLLM consensusへ潰すと情報を失う可能性があります。

単一annotatorをground truth化、rubric未版管理、calibration不足、majority voteで少数意見を消去、agreementをaccuracyと誤認、class imbalanceを無視したagreement metric、adjudication理由未保存、LLM pre-labelによるanchoring、専門知識不足、annotator fatigue、language/culture mismatch、gold set漏洩、rubric drift、再annotationの版混在、high-disagreement itemの除外、abstain強制排除、annotator個人差を品質不良と即断、privacy過収集を想定します。

複数annotatorやadjudicationは品質を自動保証せず、費用と時間を増やします。subjective taskでは完全一致を目標にすると本来の多様な判断を消す場合があります。agreement metricにはtask依存の前提があり、単一の閾値を全評価へ適用する根拠はありません。NIST ARIAの4名pairwise adjudicationは実例ですが、すべてのEnterprise AI評価に4名を要求する一般規則ではありません。

実装ではannotation recordとfinal labelを分離し、raw judgmentsを保持したままadjudicationを追記します。dashboardではfinal scoreだけでなく、disagreement rate、abstention、rubric version、adjudication volume、category別偏りを確認できるようにします。rubric変更を評価dataset revisionとして扱い、過去結果との比較可能性を明示します。

人間注釈を用いるAI評価では、rubricとannotator条件を版管理し、必要に応じて複数の独立判断とadjudicationを用い、agreementだけでなくdisagreement自体も記録・分析します。disagreementは誤りの場合も、曖昧なrubric、edge case、主観性を示す有用な信号の場合もあるため、最終ラベルだけに潰さずprovenanceを保持します。

対象組織の評価目的、risk tier、annotator人数、必要expertise、rubric、calibration set、agreement metric/threshold、adjudication owner、LLM補助有無、privacy/retention policy、再annotation条件、cost/SLAは未確認です。Enterprise AI評価全般に適用できるannotator人数やagreement閾値の単一標準値は確認できません。