「良い回答を5点満点で評価してください」と評価者に依頼しても、何を良いとするかが人によって違えば点数は比較できません。社内規程の回答なら根拠と適用条件、要約なら原文の内容を保った短縮、顧客対応なら質問への対応と禁止事項、アイデア生成なら条件への適合や発想の幅が重要になります。

ルーブリックは、こうした利用場面ごとに「何を見て、どの状態なら何点か」を定める採点仕様です。最初に評価するシステム出力、利用者、利用目的、評価者へ見せる質問・会話履歴・参照資料を固定します。「役に立つ」「自然」だけを項目名にせず、回答のどの部分で判断できるかまで書きます。

総合点と観点別の点数を別々に設計する

総合評価は利用場面に照らした最終的な良し悪しを一つで表せますが、失敗の原因は分かりにくくなります。観点別評価なら、たとえば社内規程の回答について「提示資料との整合性」「適用条件の明示」「質問への関連性」「必要な確認質問」を別々に採点できます。FLASKの論文でも、回答全体への単一得点と、課題に関係する技能ごとの得点を区別しています。

正確性、指示遵守、網羅性、簡潔さ、読みやすさ、安全性、引用の正しさなどは候補であり、毎回すべてを採点する必要はありません。たとえば引用が不要な仕事に「出典の正確性」を置かず、引用必須の仕事では資料の内容との整合と、示した出典が実際に該当箇所を指すかを分けます。総合点を評価者が直接付ける場合も、観点別得点から計算する場合も、別項目として保存します。

「正確で、分かりやすく、簡潔」という一項目は、正しいが長い回答を採点できません。一つの観点は一つの品質に絞り、観点が重なる箇所は「どちらで減点するか」を先に決めます。たとえば適用条件の取り違えを資料整合性で減点するなら、同じ条件を網羅性でも重ねて減点しません。文体上の冗長さは簡潔さで扱います。

隣り合う点数を回答の状態で区別する

3段階なら良・境界・不良を分けやすく、4段階なら中立点なしの判断を促せます。5段階は軽微な不足と利用判断に影響する不足まで分けたい場合の選択肢ですが、段階を増やすほど精密になるわけではありません。試行で評価者が4点と5点などを区別できなければ、定義を直すか段階を減らします。OpenAIの評価ガイドも、人手評価の点数ごとに具体例を示し、数値とは別に合否基準を設けることを勧めています。

社内規程への回答で「提示資料と適用条件の整合性」を5段階にするなら、次のように書けます。これは案件用に調整する例であり、別の業務へそのまま転用する尺度ではありません。

採点表を画面と納品データの項目へ変える

仕様書には観点の名前だけでなく、採点時に見る情報、例外の扱い、保存する理由まで記入します。次は上の「資料と適用条件の整合性」を一観点として登録する例です。

評価画面では回答を読んだ後に観点別の点数または採点状態を選び、重大エラーフラグと理由を入力します。納品時は回答ID、観点名、点数、状態、重大エラー、理由コード、根拠箇所、評価者ID、評価日時、仕様書の版を一緒に出せるようにします。LONGEVALの原論文には、要約の主張が原文に支持されるかを判断するための注釈例と、評価者へ渡した指示・画面が公開されています。

重大エラーと採点不能を平均点に埋めない

個人情報の露出、危険な案内、重要な指示違反、根拠のない断定など、他の項目が高得点でも許容できない失敗は事前に列挙します。該当したら総合不合格とする、総合点に上限を設ける、専門確認に回すなどの処理を選び、重大エラーフラグを点数と別に残します。読みやすさの高得点で事実誤認が相殺される単純平均にはしません。

また、回答が誤っていることと、採点に必要な資料がないことは別です。採点状態は少なくとも「評価可能」「該当なし」「提示情報不足」「専門知識が必要」「入力・画面の不備」「判断保留」に分けます。後の五つは理由を残して点数を空欄にし、資料の再提示、専門確認、画面修正などへ回します。便宜的に1点を付けると、モデルの誤りと評価工程の不備が混ざります。FLASKの人手評価にも、その技能が回答に不要な場合のN/Aが設けられています。

例題で境界を合わせ、集計方法を先に決める

評価者には各点数の代表例と、隣り合う点数で迷う例を渡します。仮に規程が「研修補助は入社6か月以上、上長の事前承認が必要」と定める場合、次のような例題にします。4点の名称のずれをどこまで許すか、重要な条件を欠く3点を重大エラーにするかは、この案件の仕様で決めます。

最後の例のように誤った手続きを案内する回答は、点数に加えて重大エラーの判定も確認します。本作業前に同じ例題を複数人で試し、点数だけでなく根拠として指した箇所を比べます。ずれがあれば定義、例題、画面に表示する資料を見直します。

全件に長文の説明を求めず、「事実誤認」「根拠不足」「条件の欠落」「指示違反」「冗長」「不適切な拒否」「確認質問不足」などの理由コードと、必要時の短い記述を組み合わせます。問題のある回答箇所と参照条項を残せば、検品時に点数の根拠を追えます。

集計前に、観点別得点をそのまま示すのか、重み付き総合点や合否を作るのか、重み・合格点・重大エラーの優先規則を決めます。結果を見て都合よく変えません。平均だけでなく観点別の点数分布、重大エラー率、判断不能率、評価者間のばらつきも確認します。自然言語生成の評価尺度を調べた研究は、段階得点を等間隔の数値として扱う統計処理の根拠が十分に示されていない例を指摘しています。平均を出す場合も分布を併記し、解釈の前提を明らかにします。

採点中にルーブリックを変えたら、変更理由、変えた観点、適用開始日またはバッチ、再判定する範囲、承認者を記録します。旧版の点数を新版へ黙って移さず、どの回答がどの基準で採点されたか追跡します。こうして初めて、回答の品質差と採点基準の変更を分けて読めます。