評価問題を追加学習に使っていなくても、開発者が失敗例と期待回答を見てプロンプトを直し続ければ、その問題での点数は未知の質問への性能を表しにくくなります。評価データを作るときは、問題の内容に加えて出所、派生ケース、閲覧者、利用先を管理します。

「汚染」で一括りにせず、三つの経路を区別する

公開ベンチマークの混入は、公開された問題や回答が基盤モデルの事前学習データに入った可能性です。GPT-3の技術論文は学習文書との重複を調べ、重複の疑いがある問題を除いた結果も比較しています。開発工程での漏洩は、評価問題や結果を見ながらプロンプト、検索、ルール、追加学習を調整することです。分割間の重複は、同じ会話や文書から作った近接ケースが開発用と最終確認用にまたがることです。基盤モデルの学習内容を確認できる範囲と、自社の作業履歴から確かめられる範囲は異なります。

評価ケースが開発へ入る場所を先に洗い出す

ファイルを学習用フォルダへ移さなくても、人が結果を見て特定のケース向けに手を加えれば評価への適応は起こります。Googleの機械学習教材も、テスト結果を繰り返し改善に使うとテストセットに合うようになり、未知データへの確認としての信頼性が下がると説明しています。

問題文だけでなく、元データと派生関係を台帳にする

問い合わせ一件から、原文、言い換え、条件変更、誤字を加えた質問を作れます。文字列が違っても同じ情報を問うなら、別々の分割に置くと独立した確認になりません。ケースを作る前に問い合わせ・会話・文書・画像の出所を特定し、次の台帳を持ちます。

分割単位は「未知の何に答えられるか」で決めます。同じ質問の言い換えや同じ会話の複数ターンは同じ分割へまとめます。規程の同じ条項から作る近接問題も、未知の文書を測るのか未知の質問を測るのかでまとめる範囲を決めます。話者や撮影対象への汎化を測るなら同一参加者の音声・画像、同じ商品・施設の画像群をまたがせない設計が考えられます。将来の問い合わせへの性能なら時期による分割も検討します。行を無作為に分けるだけでは、これらの関係を守れません。

用途と閲覧権を分け、使った後も更新する

開発用ケースは失敗内容まで開発者に示して改善に使います。評価者校正用ケースは例題と判定理由を人手評価者に提示し、研修・基準合わせに使います。ホールドアウトケースは変更の節目で実行し、問題と期待回答の閲覧者を必要な担当者に絞ります。重大変更時の確認に限る監査用ケースも別に設けられます。頻度は案件の評価計画で決めます。

ケース作成者は元資料と問題を、期待回答の確認者は根拠と正解を扱います。評価実行担当者には実行に必要な入力を渡し、人手評価者には判定に必要な資料と基準を渡します。開発担当者には開発用の結果を示し、ホールドアウトの個別正解は渡さない運用にできます。最終結果の承認者は集計と例外履歴を確認します。外部委託先へは委託する工程に必要な情報だけを示し、共有フォルダに加えてエクスポート、チャット、チケット、画面キャプチャも共有経路として記録します。

ホールドアウトの結果を見て繰り返し調整したケースは、実質的に開発へ使われています。そのcase_idとgroup_idを記録して用途を見直し、独立した最終確認が必要なら新しい出所のケースに入れ替えます。

重複検査は文字列、出所、意味の順に広げる

まず完全一致を調べ、次に空白・記号・表記を正規化した一致、部分一致やn-gramの重なりを調べます。その後、source_id、会話・文書・参加者・画像ID、同じテンプレートで変数だけ変えたケース、期待回答や正解ラベルの一致を照合します。最後に言い換えや意味的に近い候補を抽出し、人が同じ能力を測る近接ケースか確認します。正解ラベルだけが同じことは重複の証拠ではありません。

EleutherAIの評価フレームワークの資料には、学習文書と評価問題のn-gramを照合し、該当例を除いた指標を出す方法が記されています。案件の検査では、正規化の規則、類似度計算、しきい値、候補ID、人による確認結果、除外理由まで残します。機械的な一致だけで漏洩がないとは判定しません。

公開ベンチマークでは、確認できた重複と不明な範囲を分ける

基盤モデルの学習データが全面公開されていなければ、特定の問題を学んだか完全には照合できません。公開時期と公表された学習対象期間を比べ、問題文・正解が公開サイトやGitHubにあるか、作成者・モデル提供者が汚染分析を公開しているか確認します。学習データへアクセスできる場合は完全一致、部分一致、n-gramによる照合と目視確認を行い、公開問題と非公開問題の結果を分けます。アクセスできない場合も、派生問題や新しい出所のケースで再評価し、「重複を確認した」と「可能性を否定できない」を分けて報告します。

GPT-3論文では、原文の一部が重なっても質問と正解の組は含まれていなかった例が報告されています。重複の検出だけで暗記と決めず、高得点だけを根拠に学習済みとも断定しません。単語を少し置換した派生問題も、同じ答えを再現できるなら独立した新問題とは限りません。

発見後の処理と評価セットの版を先に決めておく

開発で使ったケースは開発用へ移し、分割間の重複はgroup_id単位で確認してホールドアウトから除外します。代替には別の出所から新規ケースを作ります。閲覧範囲が追えないケースは保留し、公開ベンチマークは参考値として別掲する選択もあります。旧版の評価結果に影響があれば、対象ケースと判明した理由を注記します。どの処理にも対象ID、判断者、処理日を残します。

評価セットは上書きせず、版ごとに追加・修正・除外したcase_idと理由、汚染・漏洩・重複の分類、適用日、承認者、再評価範囲を記録します。実行側もモデル、システム、プロンプト、検索対象文書の版を結び付けます。新版の点数は、旧版と共通するケースでの変化と、新規・置換ケースの結果を分けて示し、比較できない区分は明示します。OpenAIの評価設計ガイドが示す継続的な評価でも、各回に何を実行し、どのケースを改善に使ったかの履歴が判断の前提になります。