Skip to content
Guides1 min read

キャリブレーション会議を計測する

アノテーションチームはすでにノーミングセッションをしていて、アノテーターが何を考えているのかも知りたいと思っています。Multiplayer Roomsはライブの一致度メーターでキャリブレーション会議を計測し、Think-Aloud モードは声に出された推論をローカルで記録します。どちらもLLMは要りません。

Potato Team

どのアノテーションチームもうまくやれていないことが2つあります。ツールが助けてくれないからです。1つは画面共有で行われて何も残らないキャリブレーション会議、もう1つはアノテーターがなぜそのラベルを選んだのかを理解することで、これはたいてい誰も書き込まない自由記述欄に落ち着きます。Potato 2.7はその両方を計測します。リアルタイムの一致度メーターを備えたライブのノーミングルームと、音声認識をローカルで動かすthink-aloudのレコーダーです。 どちらもLLMを必要としません。

証拠を何も残さない会議

3人以上でアノテーションプロジェクトを回したことがあるなら、ノーミングセッションもやったことがあるはずです。全員が同じ数件のアイテムにラベルを付け、通話をつなぎ、食い違いについて言い合い、やがてガイドラインが実際に何を意味するのかに収束していきます。

これは機能します。同時に、まったく計測されていません。議論のに各自が持っていた投票は残りません。誰が考えを変えたのか、そしてそれが説得されたからなのか、先輩が先に発言したからなのかも残りません。そもそもその会議で一致度が上がったのかどうかは、誰も測っていないので誰にも答えられません。

Multiplayer Roomsは、そのセッションをツールの中に移します。

ライブのノーミングルーム:公開されたブラインド投票、リアルタイムの一致度メーター、記録された同調の切り替えセッション進行中のノーミングルーム

yaml
rooms:
  enabled: true
  who_can_create: any
  persist_votes: true
  schema: sarcasm

/rooms を開いてルームを作ると、通話で読み上げられる6文字のコードが発行されます。流れは意図的にこうなっています。

  1. 全員がブラインドで投票する。 メンバーには誰が投票したかは見えますが、何に投票したかは決して見えません。これはサーバー側で強制されるので、第一印象は本当に独立しています。
  2. ホストが公開する。 この時点でブラインド投票は変更できなくなります。
  3. グループで議論する。 サイドチャットでも、通話でもかまいません。
  4. 誰でも投票を変えられる。 公開後の変更はすべて、変更前の値、変更後の値、その時点の多数派とともに記録されます。

面白いのは4番目です。公開後の投票変更は、投票と同じ出来事ではありません。それは多数派が分かっている状況での変更です。それを記録するとメンバーごとの同調の記録が手に入り、毎回きまって多数派に寄せるアノテーターがいることに気づけます。その人の一致を独立した証拠として扱う前に、知っておく価値のあることです。

一致度メーターが「やる価値はあったのか」に答える

Krippendorff's αは、公開済みのアイテムに対してライブで2回計算されます。ブラインド投票に対してと、現在の投票に対してです。その差がそのセッションのノーミングによる改善分で、セッションが進んでいる最中に画面に出ています。

これが、会議に説明責任を持たせる数字です。1時間の議論でαが0.61から0.78に動いたなら、その1時間は何かを買えたと分かります。0.61から0.62にしか動かなかったなら、その不一致は解釈の問題ではないと分かったことになります。それはガイドラインの問題で、いくら話しても直りません。ガイドラインを書き直しに行ってください。

覚えておく価値のある変種が2つあります。Huddleは、チームがいま実際に意見の割れているアイテムだけをルームに投入します。アノテーションの状態からその場で計算されるので、裁定の同期版と言えます。Shadowルームでは、研修中のアノテーターが先輩の作業をリアルタイムで、テキストのどこをハイライトしているかも含めて見られます。誰かの隣に座って作業を眺めるのにいちばん近い体験です。

ルームはJSONLのログにイベントソーシングされているので、進行中のルームはサーバーの再起動を乗り越えますし、ログはそのままセッションの監査証跡にもなります。WebSocketsは使いません。クライアントがカーソル付きでポーリングするので、ルームは任意のWSGIデプロイで動きます。

一度も捉えられなかった推論

もう1つの静かな失敗が、根拠です。多くのツールは自由記述欄を用意していて、多くのアノテーターはそこに「明らか」と書くか、何も書きません。

これは怠慢ではありません。自分の推論を書き出すのは、推論すること自体よりはっきり遅いですし、タスクが400件もあれば、根拠欄は真っ先に切り捨てられます。

Think-Aloud モードは、モダリティを変えることでこの摩擦をなくします。アノテーターは作業しながらただ話すだけです。

検出された音声ラベルとともに表示される、発話そのままの推論の文字起こしThink-Aloud、検出されたラベルつき

yaml
thinkaloud:
  enabled: true
  schema: politeness
  model: tiny.en

音声認識はfaster-whisperを通じてローカルで動き、39 MBの tiny.en モデルならCPUでリアルタイムです。音声は端末の外に出ず、呼び出すクラウドAPIもトークン単位の請求もありません。機微なデータの多くにとって、これが「使える」と「法務に止められた」の分かれ目になります。

think-aloudプロトコルは、この手の話が計算機の領域に入るずっと前から、人がどう判断するかを調べるための定番でした。それがアノテーションツールに入ってこなかったのは、録音機に向かって実況してもらい、それを手で書き起こす作業を続けられる人がいないからです。

あえて逐語で

文字起こしは話されたとおりに保存され、あえて要約されません。これは怠慢ではなく設計上の判断です。think-aloudプロトコルを言い換えると、資料そのものが汚染されます。ためらい、言い直し、"well, it could be sarcastic, but…" といったもの、それがデータです。それをきれいにまとめた要約は、別の、そしてずっと役に立たない代物です。

アノテーターは声でラベルを確定することもできます。ルールベースのパーサーが検出する、決まった言い回しを使います。

  • "I label this Polite"
  • "My answer is impolite"
  • "Final answer: neutral"

確定するのはその言い回しだけです。考えているあいだに口にしたことはすべて無視され、だからこそルールベースのパーサーで足ります。経路のどこにもLLMはいませんし、あなたの意図を推し量るモデルもいません。あとから新しい言い回しを口にすれば、最後の確定が勝ちます。

決定的なためらいのシグナル(無音チャンクの数、フィラー語の数)も手に入ります。モデルではなく算術で計算したものです。あるアイテムでの長い沈黙は難しさのそれなりの代理指標になりますし、集めるのにコストはかかりません。

根拠を超えて、なぜこれが効くのか

ここが、Potato 2.7の残りとつながる部分です。

Think-Aloudは人間の思考の連鎖のレコーダーです。人が実際にどうラベルへ推論していくかを、あとから整えて書いた正当化ではなく、起きているままの推論として、書き出しの失敗も含めて捉えます。

Potatoのプロセス報酬アノテーションは、モデルに対して同じ仕事をします。モデルの思考の連鎖をステップに切り分け、ステップごとに採点します。

同じアイテム、2つの思考の連鎖、片方は人間で片方はモデル。並べて置いて、推論がどこで分かれるかを見られます。これは本当に新しく手に入るもので、より良いプロセス報酬データの素材になります。「モデルが誤った理由で正解した」は、最終回答の採点ではまさに見えない失敗だからです。

Potatoは両方の記録面を提供します。その差分を計算してくれるわけではありません。それは機能というより研究上の問いで、こちらで勝手に作った指標を渡すより、資料そのものを渡すほうがいいと考えています。

参考資料