同じ質問へのLLM回答を二つ並べて「どちらがよいか」と尋ねても、評価者が正確さを重視するのか、読みやすさを重視するのかが決まっていなければ、票の意味はそろいません。片方は詳しいが条件を一つ間違え、もう片方は短いが必要事項を省いている場合、何を選べばよいのでしょうか。

選好データを作る最初の仕事は、何についての好みを集めるか決めることです。製品の利用者が受け取りたい回答を比べるのか、資料に基づく正確性を優先するのか、安全上の失敗を見つけるのか。同じ回答ペアでも目的によって判定は変わります。この記事では、二つの回答を人に提示し、その判断を後から読み直せるデータとして残す工程を扱います。

InstructGPTの原論文では、人がモデルの出力を比較したデータをモデル改善に用いています。論文は、作業指示の改訂に加え、学習用の比較と最終評価で重視する観点が異なっていたことも記しています。「人の選好」という名前だけでは、何を優先して選んだ票なのかは決まりません。

二つの回答が同じ問いに答えていることを確認する

回答ペアを作るときは、両方が同じ質問、会話履歴、参照資料、システム条件に対して生成されたか確認します。片方だけが新しい資料を参照していたなら、その比較は回答品質だけでなく、提示条件の差も含みます。条件の異なるシステム全体を比べる目的なら、その差を比較条件として明記します。

評価画面には、判断に必要な情報をまとめて提示します。会話の最後の一問だけでは代名詞や依頼の目的が分からない場合、必要な会話履歴を含めます。資料に基づく回答を求めるなら、評価者にも該当資料とその版を示します。「箇条書きで」「推測せずに答える」といった、回答が守るべき指示も示します。長い履歴を省略するときは、どこを省略したか記録し、省略によって判定に必要な条件が失われていないか試行で確かめます。

一方、通常の回答品質を盲検で比べるなら、モデル名、開発元、生成時の内部設定、過去の勝率は評価画面から伏せます。評価者が知る必要がある利用者向けの条件と、管理者が記録する生成元の情報を分けるためです。モデル名による印象そのものを調べる研究なら、名称を見せる条件と見せない条件を設計し、結果を混ぜずに扱います。Chatbot Arenaの原論文でも、モデルの識別情報を投票前には伏せる設計が説明されています。

AとBだけに押し込まない

画面上の選択肢は、調査目的に合わせて定義します。たとえば「Aがよい」「Bがよい」に加えて、次の三つを別に設けます。

• 同程度：両方とも依頼を満たし、重要な品質差を判定できない。二つの回答が完全に同じ文章である必要はない。
• どちらも不適切：両方とも事実誤認、重要条件の欠落、不適切な拒否など、事前に決めた最低条件を満たさない。
• 判断不能：提示された資料や会話履歴が不足している、専門知識が必要で担当評価者には確認できない、画面の欠損で比較できない。

「同程度」は二つとも許容できる場合、「どちらも不適切」は二つとも最低条件に達しない場合です。「判断不能」は回答の品質ではなく、今回の担当者と提示情報では判定できない状態を表します。両方に問題があるものの一方が明らかにましな場合をどう記録するかも決めます。総合選好としてAまたはBを選び、両回答に不適切の印を付ける方法なら、「勝った回答＝使用可能な回答」という誤読を防げます。

Chatbot Arenaには、勝者を選ぶ票とは別に同点と「両方よくない」の選択肢があります。一方、AnthropicのHH-RLHFデータセットの配布形式は、選ばれた回答と選ばれなかった回答のペアです。後者のような形式へ書き出す場合でも、収集時に同点や保留を無理に勝敗へ変える必要はありません。書き出し対象の選別規則を別に定めます。

総合選好と観点別の判断を別々に記録する

二つの回答が競合する観点で優れていることがあります。たとえば、社内規程への質問でAは読みやすく簡潔ですが、適用条件を一つ落としています。Bは長いものの条件と根拠を正しく示しています。この業務で条件の誤りを重大と定めたなら、総合選好はBになり得ます。ただし、「Bを選んだ」だけでは、Aの簡潔さとBの正確さという差は残りません。

作業指示では、正確性、指示遵守、質問への関連性、安全性、簡潔さ、文体のうち、今回必要な観点を選びます。すべての観点を毎回必須にする必要はありません。総合判定では「根拠と矛盾する記述は、多少の読みやすさより重く扱う」のように優先順位を例題で示します。文体だけが違い、業務上の差がないなら同程度とできるようにします。観点別欄には「正確性はB、簡潔さはA」のような評価を残し、総合選好と同じ値を機械的に転記しません。

理由の収集には、集計しやすい理由コードと、判断の根拠を示す短い自由記述を組み合わせられます。理由コードを「事実誤認」「指示違反」「重要事項の欠落」「冗長」「不適切な拒否」などに分け、該当箇所の引用や「どの条件を落としたか」を自由記述に残します。単なる「Bの方が自然」だけでは、後から仕様を直したり、判断を検証したりしにくいためです。

回答ペアと評価者ごとの票を分けて保存する

一つの回答ペアを複数人が判定する場合、ペアそのものの情報と、一人ずつの判定記録を分けます。画面上のA・Bと生成元の回答IDを混同しないよう、表示位置との対応も残します。

ここでのresponse_a・response_bは保存時に固定した回答IDです。画面で左右を入れ替えても本文やIDを入れ替えず、表示順の欄に対応を記録します。これにより「Aを選んだ票」が、どちらの生成元への票だったか後から復元できます。

表示順と回答の見た目が票を動かしていないか調べる

提示時には回答A／Bの左右または上下をランダムに割り当て、回答IDと表示位置の対応を保存します。集計では、同じ生成元の回答が先に表示されたときと後に表示されたときの選好率を比べます。一部のペアを順序を替えて別の評価者にも割り当てれば、内容が同じでも位置によって判断が変わるか確認できます。同じ評価者へ直後に逆順の同一ペアを出すと記憶の影響を受けるため、割り当てにも配慮します。

また、Aの方が常に長い、特定モデルだけが定型の前置きを書くといった状態では、回答の中身と見た目の差を分けにくくなります。OpenAIの要約比較研究も、回答の長さが選好結果を左右し得るため、長さを考慮した分析を行っています。回答の長さの差、表示位置、定型的な文体を記録し、特定の条件で票が偏っていないか見ます。同じ評価者へ似た質問や同じモデルの組み合わせを集中させず、作業順も分散します。

評価者の訓練と不一致の確認を、作業開始後も続ける

評価者の募集では、対象分野の知識と言語能力を、比較する業務に合わせて確認します。事前に、明らかな勝敗、同程度、両方不適切、判断不能、観点が競合する例題を解いてもらい、答えだけでなく理由を説明します。OpenAIの要約比較研究では、共通ケースでの訓練と校正、評価者間の不一致の確認、作業者への継続的なフィードバックを行っています。

本作業でも共通の校正用ケースを混ぜ、理由とともに確認します。同じ評価者が短時間で大量の票を付けていないか、片側ばかりを選んでいないか、理由が回答内容と対応しているかを点検します。ただし、同点や判断不能の多さだけで不良作業と決めず、提示情報やペアの作り方に問題がないか先に調べます。

複数評価者が割れた場合は生の票を残し、相違の理由を分けます。資料の見落としなら再確認し、指示が曖昧なら仕様書を直して影響範囲を再判定します。専門的な事実確認が必要なら担当者へ回し、価値判断が分かれるケースは分布と理由を残す方法もあります。最終判定が必要な案件では裁定者と理由を別欄に記録し、多数決の結果だけを元の各票へ上書きしません。

学習用に使うか、比較評価に使うかで出口を変える

モデル改善用なら、勝敗が確認できたペアを採用対象にし、同点、両方不適切、判断不能、不一致の大きいペアをどう扱うか決めます。比較評価だけが目的なら、勝敗以外の票も、両モデルの弱点や評価者間の違いを読むために役立ちます。用途が違えば、必要な保存項目や除外規則も変わります。

データを分ける際は、同一質問の言い換えや同じ会話から作った複数ペアが、改善用と最終確認用にまたがらないか確認します。回答を再生成した場合は元のpair_idを上書きせず、新しいペアと生成条件を記録します。資料や作業指示を変更した場合も、その版以降の票を区別します。ケースの選定とホールドアウト管理については別に検討し、この比較作業では「評価者が何を見て、なぜその回答を選んだか」を失わないことが要点です。