ブラインド項目でLLMの提案によるアノテーターのアンカリングを測る

LLMが提案したラベルを見たアノテーターはそのラベルを付ける傾向があるため、人とモデルの一致度は、提案が画面に表示されているときのほうが表示されていないときより高くなります。項目のランダムサンプルで提案を伏せ、そのブラインド項目での一致度を測り、モデルをどこまで信頼するかの判断には全体の一致度ではなくブラインドでの一致度を使ってください。

*アンカリング*とは、最初に見た数値や答えが、後の判断をそちらに引き寄せる傾向のことです。アノテーションでは、事前ラベル、つまりアノテーターが受け入れるか修正するモデルの提案がアンカーになります。アンカリングは、アノテーターが提案を読まずに受け入れる追認とは異なります。すべての提案を読む注意深いアノテーターでもアンカリングは起こりえます。曖昧な項目では、提案された答えがすでにページ上にあるからです。一致度では追認を捉えられないで説明しているように、追認はタイミングのシグナルで捉えられます。しかし、アンカリングされたアノテーターは項目に通常どおりの時間をかけることがあるので、タイミングではアンカリングと独立した判断を区別できません。

提案がラベルを変えるという証拠

ある事前登録された実験（Schroeder et al., 2025）は、4つの条件、2つのモデル、2つのデータセットにわたり、350人のクラウドワーカーから主観的なタスクについて7,000件のアノテーションを集めました。LLMの提案を表示してもアノテーターは速くなりませんでしたが、自己申告の確信度は上がりました。アノテーターは提案をかなりの頻度で採用したため、提案を見なかったアノテーターと比べてラベル分布が有意に変わりました。LLMの支援を受けて付けたラベルでLLMを評価すると、報告される性能は有意に上がりました。

したがって、モデルとその提案を見たレビュアーとの一致度は、部分的にはモデルとモデル自身との一致度です。一致度が90%を超えたらコーパスの残りをモデルに任せる、といったその数値に基づく判断はどれも、水増しされた数値の上で下されることになります。

ブラインド項目とアンカリングの差

アノテーションを始める前に、アノテーターが提案なしでラベルを付ける項目をランダムに一定の割合だけ選びます。残りの項目では、提案は通常どおり表示されます。この2つを比較すると、次の3つの数値が得られます。

ブラインドでの一致度：モデルと、その提案なしで付けたラベルとの一致度で、モデルがどのくらいの頻度で正しいかを推定します。
表示時の一致度：モデルと、その提案が画面にある状態で付けたラベルとの一致度です。
アンカリングの差：表示時の一致度からブラインドでの一致度を引いたもので、提案が人をどの程度動かすかを推定します。

ブラインド項目はランダムに選び、研究の間は固定しなければなりません。最も難しい項目を選んだり、いつ提案を見るかをアノテーターに決めさせたりすると、ブラインドサンプルは代表性を失い、ブラインドでの一致度はコーパスの残りについて何も推定しなくなります。また、ラベルがブラインドとみなされるのは、アノテーターがその項目の提案を一度も見ていない場合だけです。そのため、不一致の後に付け直したラベルは表示時のラベルに含めます。

ブラインドの割合は、速さと証拠のトレードオフです。ブラインド項目はどれも、提案が節約してくれる時間なしでラベルを付けることになり、ブラインド項目が少なすぎるとブラインドでの一致度にノイズが多くなります。Potatoのデフォルトは、割合20%、ブラインド項目の下限20件です。この割合だと、20項目の研究ではブラインド項目が4件程度しかできないので、下限はコーパスが提供できる件数に合わせて設定してください。

Solo Modeのブラインド提案

Solo Modeは、1人の専門家がLLMと協働するためのPotatoの仕組みです。LLMがコーパスにラベルを付け、専門家もそれと並行してラベルを付け、専門家とLLMの一致度がend_human_annotation_agreementを超えると、Solo Modeは残りの項目をLLMに引き渡します。Potato 2.11より前は、この一致度は提案が見える状態で付けたラベルで測られていました。2.11からは、solo_mode.suggestionsで提案をいつ表示するかを制御できます。

yaml

solo_mode:
  suggestions:
    display: blind_sample      # before_label | after_label | blind_sample
    blind_rate: 0.2
    minimum_blind_sample: 20

blind_sampleは、固定された20%の項目で提案を伏せます。項目は研究ごとに一度だけ選ばれるので、再読み込みや再起動をしても同じ項目がブラインドのままです。after_labelは提案を決して先に表示せず、専門家とLLMの意見が分かれたときには、解決ページにLLMのラベルとその理由を表示します。ブラインドの比較が20件そろうと、引き渡しの判定では全体の一致度ではなくブラインドでの一致度をしきい値と比較します。

ダッシュボードのBlind Agreementカードには、ブラインドでの一致度と表示時の一致度が並べて表示され、その差と、専門家がAcceptボタンで提案を採用した頻度も示されます。差は、両側にそれぞれ少なくとも5件の比較がそろった時点で報告されます。差が大きくプラスであれば、専門家はLLMの答えが見えているときのほうがLLMに同意しやすいということです。その場合は、ブラインドにする項目を増やすか、after_labelに切り替えてください。

ラベリングエンジンのブラインドキャリブレーション

同じく2.11で加わったPotatoのラベリングエンジンは、証拠として使うすべてのラベルに同じルールを適用します。キャリブレーション、証明、監査の依頼は包含確率を記録したうえでランダムに抽出され、人がそれを受け持っている間、サーバーはその項目に対する機械の答えをすべて伏せます。プレアノテーション、インラインの判定者、AIアシスタントはすべて無効になり、その人にとってこの項目は保存後もブラインドのままです。エンジンは、こうしたブラインドのラベルに対してのみ機械ラベルを証明します。

検証の依頼はその逆です。機械の答えを表示し、それをそのままにするか変更するかを人に求め、事前入力された答えを記録するので、人がそれをどのくらいの頻度で受け入れるかを測定できます。検証の答えはその仕組み上アンカリングされているため、エンジンがそれを証明に使うことはありません。humans.verify_visibility: blindを設定すると、検証の依頼も答えなしで提示されますが、提案が節約してくれる時間はその分失われます。

ブラインドサンプルの限界

ブラインドサンプルは支援を受けない人々を基準にモデルを測るもので、それが正しい基準になるのは、支援を受けない人々がそのタスクで信頼できる場合に限られます。注意深いアノテーター同士でも意見が分かれる主観的なタスクでは、ブラインドでの一致度の上限は100%を下回り、モデルがその上限に達していることもあります。低いブラインド一致度をモデルが弱い証拠と読む前に、LLM判定者と人の一致度で説明しているように、モデルと人の一致度を人同士の一致度と比較してください。

また、ブラインドサンプルは、提案を表示して付けたラベルには手を加えません。そうしたラベルはアンカリングされたままであり、主にそれらから作られたデータセットはモデルの好みを受け継ぎます。データセットとともにブラインドでの一致度とアンカリングの差を報告してください。そして、最初の項目にラベルが付く前にdisplay: blind_sampleを設定してください。提案が見える状態でラベルを付けた項目は、後からブラインドにすることができないからです。

参考資料

一致度では追認を捉えられない：読まずに受け入れるアノテーターを見つけるタイミングのシグナルについて
LLMによるプレアノテーション：レビュー済みの事前ラベルにおける自動化バイアスについて
ブラインドの人手サンプルでLLMラベルを証明する：ブラインドサンプルに対する機械ラベルの証明について

参考文献

Schroeder, H., Roy, D., and Kabbara, J. (2025). Just put a human in the loop? Investigating LLM-assisted annotation for subjective tasks. Findings of ACL 2025. https://doi.org/10.18653/v1/2025.findings-acl.1323