LLMの本番品質はベンチマークでは測れない――モデル評価をプロダクト品質保証へ変える実践ガイド

ベンチマークの高スコアが本番品質を保証しない理由

LLMを使った機能を開発するとき、まずモデルのベンチマークスコアや、少数のサンプルに対する正解率を比較するケースは少なくありません。プロトタイプの段階では、モデルの候補を絞り込んだり、アイデアの技術的な実現可能性を確かめたりするうえで有効です。

しかし、システムが本番に近づくほど、評価すべき対象は「モデルが問題に正解できるか」から「そのシステムがユーザーや事業にとって安全に価値を提供できるか」へ変わります。

本番の入力には、次のような揺らぎがあります。

• 入力の意味が曖昧である
• 必要なコンテキストが欠落または切り詰められている
• 1つの入力に複数の候補が含まれている
• 実際の利用頻度と評価データの分布が異なる
• ラベルが人やワークフローによって一貫していない
• ベンチマークには少ないエッジケースが、本番では頻繁に発生する

そのため、オフライン評価のスコアが上がっても、本番でのユーザー体験や安全性が改善するとは限りません。GitHubが公開したシークレットスキャン向けLLMシステムの評価事例は、この問題を具体的に示しています。

まずモデルではなく「製品上の意思決定」を定義する

LLMの出力が期待どおりでないとき、プロンプトを修正する、モデルを変更する、コンテキストを追加する、といった技術的な対策にすぐ進みがちです。しかし、その前に決めるべきなのは、評価結果を使ってどのような製品上の判断を行うのかです。

シークレットスキャンでは、単純に文字列を正しく分類できるかが目的ではありません。重要なのは、実際の認証情報を見逃さずに、開発者が調査する不要なアラートを減らせるかどうかです。

この場合、評価指標をすべて同じ重みで扱うべきではありません。たとえば、次のように役割を分けられます。

たとえば、誤検知を大幅に減らせても、再現率が安全基準を下回るなら、その構成は採用すべきではありません。一方で、誤検知削減が中程度でも、安全性とレイテンシの条件を満たすなら、次の検証に進める価値があります。

LLM評価の目的は、最も高いスコアのモデルを選ぶことではなく、定義した制約の中で製品にとって最良の意思決定をすることです。

オフライン評価を「統合テスト」として扱う

LLMシステムは、一度評価して終わりではありません。プロンプト、モデル、入力の組み立て方、コンテキスト、周辺のビジネスロジックを変更するたびに、挙動が変わる可能性があります。

そこで、オフライン評価を単発の分析ではなく、LLMシステム全体に対する統合テストとして扱います。少なくとも次の変更を行った場合は、既知のベースラインと比較できる状態で再評価します。

• プロンプトを変更した
• モデルをアップグレードした
• 入力やコンテキストの構成を変更した
• 出力の後処理や判定ロジックを変更した
• 評価データやラベルの定義を更新した

評価結果には、スコアだけでなく実験条件を記録します。

run_id: R-002
prompt_version: v2
model_version: Model A
dataset_version: secrets-eval-2024-01
precision: 0.75
recall: 0.77
latency: 1.2s
notes: Prompt-only change

重要なのは、1回の実験で大きな変更をいくつも混ぜないことです。プロンプトとモデルを同時に変更すると、改善や劣化の原因を特定できません。まずプロンプトだけ、次にモデルだけというように、主要な変数を分離して比較します。

プロンプトや評価設定をコードと同じようにバージョン管理すれば、次のような運用が可能になります。

• 以前の評価結果を再現する
• 改善の原因を説明する
• 回帰が発生した変更を特定する
• 直前の構成へロールバックする
• モデル更新を定期的に比較する

モデル変更を「最後の手段」にしない

性能が不足すると、プロンプトに指示を追加し続けることがあります。しかし、複雑なプロンプトが必要なのは、モデル側の能力や挙動に起因している可能性もあります。より強いモデルであれば、簡潔なプロンプトの方が安定するケースもあります。

ただし、モデルを更新すれば必ず改善するわけではありません。カテゴリによって性能が変わったり、コスト、レイテンシ、出力形式に影響したりするため、モデル更新も定期的なオフライン評価の対象にします。

評価データを本番の入力条件に近づける

本番のLLMは、単独で整形された理想的な値だけを評価するとは限りません。コード解析であれば、対象候補の周囲に別の文字列やコメント、テストコード、関連する変数が存在します。

たとえば、次のようなコードを考えます。

example_token = "sample_value_for_documentation"
production_api_key = get_secret_from_environment()
candidate_value = "flagged_value"

評価対象が candidate_value であっても、モデルが変数名や値の見た目に引きずられ、example_token を判定してしまう可能性があります。入力に候補が1つしかない簡潔な評価データでは、この問題は見つかりません。

本番に近い評価では、次の要素をできるだけ保ちます。

• 実際に評価する候補
• 候補の周辺に存在するコードやテキスト
• 本番で利用可能な補足情報
• 入力のフォーマットと制約
• モデル出力を処理する後段のロジック

評価用にデータをきれいにしすぎると、実際より簡単な問題を測ることになります。特にコード分析やセキュリティ領域では、曖昧さやノイズを取り除くのではなく、適切な形で残すことが重要です。

本番ラベルを「絶対的な正解」とみなさない

本番データは実際の利用状況を反映しやすい一方、付与されたラベルが真の正解を表しているとは限りません。

シークレットスキャンのアラートが却下または解決されたとしても、それだけで「誤検知」とは判断できません。認証情報がローテーションされた、リスクを受け入れた、ワークフローを進めるためにアラートを処理した、分類が誤っていた、といった異なる状況が同じ操作に集約される可能性があります。

本番ラベルを評価に利用する前に、少なくとも次を整理します。

• そのラベルは誰によって、どの操作をもとに作られたか
• ラベルが評価したい問いと一致しているか
• 複数の業務上の結果が同じカテゴリにまとめられていないか
• 重要または曖昧なデータに人手確認が必要か
• ラベルの定義変更が過去の評価結果に影響していないか

すべてのラベルを完全に正規化する必要はありません。しかし、ラベルの意味を理解しないまま適合率や再現率を計算すると、数値の解釈を誤ります。

合成データと公開データは「不足分を埋める」ために使う

開発初期には、本番データが少なかったり、機密性のために利用できなかったりします。その場合、合成データ、研究用ベンチマーク、公開データセットは有用です。

ただし、これらを本番データの代替として扱うのではなく、カバレッジの不足を補うために使います。たとえば、次のようなケースは実データだけでは集めにくく、意図的に作成する価値があります。

• 文脈が不足している入力
• 形式が通常と異なる入力
• プレースホルダーやサンプル値
• テストコード内の認証情報らしい文字列
• 近接した複数候補が存在する入力
• 間接参照や環境変数を含むコード
• ラベルの判断が分かれやすい曖昧な例

公開データを利用する場合も、自社の製品定義に合うように入力やラベルを見直します。文字列の形式を認識できることと、実際のコードの文脈で安全に判定できることは別の能力だからです。

平均スコアではなくエラーの種類を見る

集計指標は、システム全体が改善したかを確認するのに役立ちます。一方で、次に何を直すべきかは教えてくれません。改善につなげるには、誤判定をサンプリングし、原因別に分類します。

実務では、次のような分類が使えます。

たとえば、モデルが何度も隣接する別の値を判定しているなら、モデルの能力だけでなく、入力の境界やプロンプトの構造が問題かもしれません。特定の曖昧なパターンで判断が割れるなら、モデル改善より先に製品ポリシーを明確にする必要があります。

「なぜ間違えたか」を分類できると、品質問題は漠然としたモデル性能の課題から、修正可能なエンジニアリング課題に変わります。

LLM-as-a-judgeは判定者ではなくトリアージに使う

評価件数が増えると、すべてを人手で確認するのは困難です。LLM-as-a-judgeを使えば、明確なケースの分類、ラベルの不整合候補の抽出、人手確認が必要な例の優先順位付けを支援できます。

ただし、判定役のLLMも誤る可能性があります。評価対象のモデルと似た理由で誤ることや、もっともらしい説明を生成することもあるため、出力をグラウンドトゥルースとして扱うべきではありません。

安全な運用パターンは、最終判定を委ねるのではなく、レビュー対象を絞るトリアージに使うことです。

• 明確で影響の小さいケースは自動処理する
• 低信頼度や判定が衝突するケースを人手に回す
• 高信頼度とされたケースも定期的にサンプリングする
• judge、評価対象システム、人手レビューの不一致を記録する
• judge用プロンプトとモデルもバージョン管理する

人手レビューを減らすこと自体が目的ではありません。人間が、判断を変える可能性の高いケースに集中できるようにすることが目的です。

本番投入前の実務チェックリスト

製品目標

• 改善したいユーザー価値と主要指標が定義されている
• 許容できない失敗の種類が明確になっている
• 安全性と運用上のガードレールが数値または条件で定義されている

データとラベル

• 評価データが本番の入力形式と分布に近い
• 曖昧な入力やエッジケースが含まれている
• ラベルの作成方法と限界を説明できる
• 重要なケースを人手で再確認している

評価の再現性

• プロンプト、モデル、データセット、パイプラインのバージョンを記録している
• 既知のベースラインと比較できる
• 主要な変更を分離して評価している
• 過去の評価を再実行できる

エラー分析と本番準備

• 誤検知と見逃しを原因別に確認している
• オフライン評価と本番環境の違いを把握している
• レイテンシ、コスト、信頼性を測定している
• 本番では段階的に導入し、オンラインで検証できるガードレールがある

まとめ：LLM評価を開発工程に組み込む

GitHubのシークレットスキャン事例で示された重要な点は、単に高い精度を達成したことではありません。誤検知を減らすという目的に対して、再現率を安全制約として扱い、本番に近い入力で繰り返し評価し、残った失敗の原因を分析できる状態を作ったことです。

同事例では、評価対象のオフラインデータセット上で誤検知を95％削減し、定義した再現率のガードレール内に収めたとされています。ただし、オフライン評価だけで本番のすべての挙動を証明したわけではありません。リスクと不確実性を把握したうえで、オンライン実験へ進むための根拠を作ったという位置付けです。

LLMアプリケーションやAIエージェントでは、モデルを選ぶことよりも、何を成功とし、何を失敗として許容しないかを定義することが重要です。評価をリリース前の一度きりの確認ではなく、プロンプト、モデル、データ、パイプラインに対する継続的な品質保証として扱うことで、本番の不確実性を測定可能なリスクへ変えられます。

出典： GitHub Blog