LLMの回答を評価しようとして、まず「質問と正解回答の一覧」を作ることがあります。しかし、正解文を一つ用意しただけでは、言い換えた回答をどう採点するか、資料に答えがないときは何を期待するか、モデルを改善した後も同じ点数を比較できるかが決まりません。

ゴールデンデータセットは、評価対象の入力と、期待する結果や判定基準を確認済みのケース集です。ここでいう「ゴールデン」は、どんなモデルや用途にも通用する絶対的な正解という意味ではありません。特定の利用場面について、何を良い結果と判定するかを人が確かめ、繰り返し評価できる形にしたものです。

LangSmithの評価チュートリアルは、入力と期待出力を持つ少数のケースから始め、実際の利用で見つかった問題を追加する方法を示しています。また、完全な期待文を定義できない場合があることも明記しています。制作の出発点は件数の目標ではなく、「今回の評価で何を見逃したくないか」です。

最初に評価対象と成功条件を一文にする

例として、社内規程を検索して従業員の質問に答えるシステムを考えます。「規程に沿って答える」だけでは評価項目を作れません。まず、「指定した版の規程から根拠を確認し、該当情報がない場合は推測して補わず、その旨を伝える」といった成功条件にします。

次に評価対象を固定します。同じ質問でも、検索対象の規程、検索結果の提示方法、システム指示、モデルが変われば回答は変わります。モデル単体の能力を測るのか、検索を含むシステム全体を測るのかを決め、各実行で何を入力したか記録します。OpenAIの評価設計ガイドも、目的を定めてからデータと評価指標を選び、変更を継続的に評価する順序を示しています。

初期ケースは頻出例と見逃せない失敗から選ぶ

初期セットには、実際の質問ログや問い合わせ担当者が経験した失敗に加え、業務上重要でも発生頻度の低いケースを入れます。たとえば次のように、先にケースの区分を作ってから例を選びます。

• 通常例：一つの規程に答えが明記され、根拠を示して回答できる。
• 失敗例：旧版の規程を参照する、条件を読み落とす、資料にない期限を作って答える。
• 境界例：似た制度が二つある、適用対象が文面だけでは決まらない、複数の条項を合わせて判断する。
• 回答不能例：検索対象に必要な情報がなく、確認先の案内または保留が適切である。
• 入力の揺れ：略称、誤字、短い質問、複数の質問を一度に含む入力。

頻出例ばかりを集めると平均的な回答の傾向は見えても、重大な誤回答を見逃します。逆に難例だけでは、通常の問い合わせに対する品質が分かりません。運用中に新しい失敗を見つけたら、その入力だけを追加するのではなく、同じ失敗類型の通常例や境界例も確認します。ケースの出所と選定理由を残しておけば、後から構成の偏りを点検できます。

正解文より先に「含めること・してはいけないこと」を決める

「出張精算の提出期限は？」という質問でも、参照資料に期限が書かれていなければ、流暢な期限の回答は失敗です。このケースの期待結果は特定の文章ではなく、「資料では期限を確認できないと伝える」「別制度の期限を流用しない」といった条件になります。一方、期限が明記されているケースなら、その日数、起算点、適用条件を必須要素として記録できます。

作業者には、質問だけでなく、評価に使う規程の版、参照できる範囲、想定する利用者、回答時に必要な形式を提示します。期待結果の記入欄は、用途に応じて次のように分けます。

商品コードや定型ラベルなら完全一致が役立ちます。一方、説明文を一つの模範解答と文字列で照合すると、意味は正しくても言い方が違う回答を不合格にします。必須事実と禁止事項を分けた判定や人による確認を選び、採点方法自体が期待結果を測れているか確かめます。OpenAIのガイドも、自動採点を人の判断と照らして調整することを勧めています。

意見が割れたケースを無理に「正解」にしない

作成者とは別の確認者に、同じ資料と指示を渡して期待結果を判定してもらいます。判断が割れたら、①根拠の見落とし、②作業指示の不足、③資料自体の曖昧さ、④複数の妥当な回答、を分けて調べます。

根拠が特定できれば期待結果を修正します。入力情報が足りないなら、「確認質問をする」を期待結果に変更することもあります。資料の解釈が決まらないケースは保留にし、資料の管理者へ確認するか、合否を一つに決める評価から外します。多数決で単一の正解を作る前に、なぜ割れたかを記録する方が、その後の判定基準を改善できます。

検品では、全ケースについて「提示資料から期待結果を導けるか」「必須要素と失敗条件が矛盾しないか」「別の評価者が同じ手順で判定できるか」を確認します。自動採点を使う場合も、合格と不合格の実例を人が見直し、誤判定が集中する区分を調べます。

改善に使うケースと、最後に確認するケースを分ける

失敗した質問を開発チームが見てプロンプトや検索方法を直すことは有用です。ただし、その質問で何度も改善と再評価を繰り返すと、点数の上昇が未知の質問への改善を意味するとは限りません。Googleの機械学習教材は、調整に使う検証セットと最終確認用のテストセットを分け、テストセットも繰り返し利用すると信頼性が下がると説明しています。

そのため、結果を見ながら改善に使う「開発用ケース」と、変更の節目で最終確認する「ホールドアウトケース」を区別します。ホールドアウトケースの結果を見て繰り返し調整すれば、そのケースも実質的に開発へ使われたことになります。その場合は必要に応じて新しいケースへ入れ替えます。ホールドアウトケースの期待結果をプロンプト例や追加学習データへ転用しないよう、利用先も記録します。同一質問の言い換え、同じ元文書から作った近接ケースも確認し、分割をまたぐ実質的な重複を減らします。基盤モデルが過去に何を学習したかまで完全に把握できない場合は、その限界と、自社で管理できる入力・資料・追加学習データの分離状況を区別して記載します。

追加・修正しても、過去の点数を読めるようにする

運用で新しい失敗が見つかればケースを追加します。制度が変われば期待結果や根拠も更新が必要です。ただし、以前の評価セットを上書きすると、点数の変化がシステムの改善によるものか、問題や採点基準の変更によるものか分からなくなります。

更新時にはケースIDを維持し、追加・修正・除外の別、理由、適用する資料の版、承認者、適用日を残します。旧版の評価結果は当時のケースと採点基準に結び付け、新版との比較では共通ケースの点数と新規ケースを分けて示します。LangSmithのデータセット管理資料にも、例の追加・更新・削除ごとに版を作り、特定の版を指定して評価する仕組みが示されています。

「ゴールデン」にする工程は、立派な模範解答を書くことだけではありません。業務で起こる入力を選び、期待する振る舞いを根拠とともに確定し、迷う例を保留できるようにし、改善に使ったケースと最終確認用のケースを管理することです。その記録があって初めて、次のモデルやシステム変更を同じ基準で確かめられます。