LLMの評価データセットをどう作る？実例・境界例・失敗例を同じ基準で測る
LLMの品質を測るには、いくつかの質問を試して印象を比べるだけでは足りない。必要なのは、実際の利用場面を代表する入力と、成功・失敗を判定する基準を組にした評価データセットである。
評価データセットは、難しい問題を無作為に集めた問題集ではない。製品が果たすべき役割を、繰り返し測れる形へ変換したものだ。通常の依頼、判断が難しい境界例、過去に起きた失敗を同じ形式で保存すれば、モデルやプロンプトを変更したときに、どこが良くなり、どこが悪くなったかを比較できる。
最初に成功条件を文章で決める
データを集める前に、対象機能の目的を一文で定義する。例えば「社内規程を根拠に質問へ回答し、資料に答えがない場合は推測しない」という目的なら、回答の正しさだけでなく、根拠との一致、回答不能時の振る舞いも評価対象になる。
目的が「役に立つ回答をする」のように広すぎると、採点者によって基準が変わる。対象利用者、入力の範囲、必須の振る舞い、してはいけない振る舞いを決める。OpenAIの評価設計資料でも、まず目的を定め、実際の分布を反映するタスク固有の評価を作る流れが示されている。
一件の評価例には、少なくとも次の情報を持たせる。
- 入力と、回答に必要な資料や状態
- 期待する事実、分類、操作、または振る舞い
- 出力してはいけない内容や操作
- 通常例、境界例、失敗再現例などの分類
- 自動判定、人手判定、モデル判定のどれを使うか
- データの作成元、作成日、対象となる構成の版
長文の模範回答を一つだけ正解として固定する必要はない。必要な事実と禁止事項を分ければ、表現が違っても正しく採点できる。
実際の利用例から中心を作る
最初の中心になるのは、実際に想定される依頼である。利用ログを使える場合は、個人情報や機密情報を除去し、利用目的と保存方針を確認してから評価例へ変換する。まだログが少なければ、業務担当者が代表的な依頼を書き、公開可能な過去の問い合わせや手順書から補う。
本番で多い簡単な依頼を省き、難問だけで評価すると、現実の品質を表さない。反対に、頻出例だけでは変更に弱い部分を見つけられない。利用頻度を反映する代表セットと、危険性や不確実性を調べる挑戦セットを分けて持つと目的が明確になる。
合成データは、足りない分類を増やす補助として使える。ただし、同じモデルに質問と正解を大量生成させると、似た言い回しや前提へ偏りやすい。人が重複、現実性、正解の妥当性を確認し、実例の代わりではなく拡張として扱う。
境界例と失敗例を意図して入れる
良い評価セットは、平均的な入力だけでなく、仕様の境界を含む。OpenAIの評価資料は、典型例、境界例、敵対的な例を含め、複数言語、誤字、複数の意図、長い文脈、出力形式、曖昧な道具の引数、競合する指示などを検討するよう勧めている。
対象機能に合わせて、次のような分類を用意する。
- 必要な情報が十分にある通常例
- 情報が不足し、質問し直す必要がある例
- 根拠に答えがなく、回答を控えるべき例
- 日付、単位、否定表現、固有名詞が紛らわしい例
- JSONや表など、厳密な形式が必要な例
- 長い文脈の中に重要な一文がある例
- 権限外の情報や操作を求める例
- 外部文書に不正な命令が混ざる例
過去の障害や利用者からの指摘は、修正後も回帰例として残す。評価点を上げるために失敗例を削除すると、同じ不具合が再発しても検出できない。
開発用と最終確認用を分ける
同じ評価例を見ながらプロンプトを何度も直すと、その例だけに合わせた改善になる。日常的な調整に使う開発セットと、公開判断に使う非公開の確認セットを分ける。確認セットの内容をモデルや実装担当者が繰り返し参照しない運用にすると、未知の入力へ対応できるかを測りやすい。
無作為に分割するだけでは、ほぼ同じ質問が両方へ入ることがある。元の問い合わせ、文書、利用者、時期などのまとまり単位で分け、言い換えによる漏れを防ぐ。時間で正解が変わる問題には基準日を記録し、古い正解を品質低下と誤認しないよう更新責任者を決める。
採点方法を出力に合わせる
分類ラベル、JSON Schema、道具の名前や引数、計算結果など、機械的に確認できるものは決定的な判定を優先する。文章の品質を評価するときも、事実の一致、根拠、禁止事項、形式を別々に採点すると原因を追いやすい。
自由記述の回答では、モデルによる採点が有効な場合がある。OpenAIの資料は、自由な点数付けより、二つの回答の比較、合否、明確な分類の方がモデル判定に向くとしている。一方で、モデル判定には回答の順番や長さへの偏りがある。人の判断を基準に採点例を調整し、比較する回答の順序を入れ替え、意見が割れる例は専門家が確認する。
評価基準には、各段階の具体例を付ける。「良い」「不十分」だけではなく、どの必須情報があれば合格か、何を含めば重大な失敗かを明記する。採点者同士の一致率が低い項目は、モデルより先に仕様を見直す必要がある。
平均点だけで判断しない
全体の平均点が上がっても、回答不能の判断や権限制御だけが悪化することがある。通常例、境界例、安全性、言語、出力形式などの分類ごとに結果を分け、件数の少ない重大失敗も個別に確認する。
公開条件には、総合点だけでなく、重要分類の最低水準と、発生してはいけない失敗を含める。新しいモデルが平均では優れていても、許可なしの外部操作が一件増えるなら、そのまま公開できない。
本番で見つかった新しい失敗は、機密情報を除去して評価データへ戻す。修正、回帰確認、限定公開、本番監視を一つの循環にすれば、評価セットは固定された試験ではなく、製品の失敗履歴を蓄積する資産になる。
評価データセットの価値は件数だけでは決まらない。利用場面を代表し、境界と失敗を含み、誰が採点しても同じ結論へ近づくことが重要である。まず少数でも判定根拠が明確な例を作り、本番で得た知見を版管理しながら追加する方が、曖昧な大量データより改善へつながる。