本番環境投入前の LLM 評価方法とベンチマークの限界について

言語モデルは、クリーンなベンチマークでは高い性能を発揮しても、本番環境で実際に重要なケースにおいては苦戦することがあります。

LLM を活用したシステムのプロトタイプ作成段階では、ベンチマークやキュレーションされたデータセットが有用です。これらはチーム間でモデルを比較したり、初期のプロンプトを検証したり、アイデアの技術的な実現可能性を確認したりする際に役立ちます。

しかし、システムが本番環境に近づくと、評価の問題は変化します。

実際の入力には曖昧さがつきものです。ラベルも一貫していないことがあり、重要な文脈が欠落していたり切り捨てられていたりすることもあります。評価セットが本番環境のデータ分布を反映していないケースも珍しくありません。ベンチマークではめったに出現しないエッジケースが、本番環境では頻繁な障害の原因となることがあります。オフラインでの指標が改善しても、その結果がそのまま本番環境での振る舞いに直結するとは限りません。

私たちは、GitHub のシークレットスキャンにおける偽陽性を減らすことを目的とした LLM ベースのシステムを評価する際、こうした課題に直面しました。

シークレットスキャンは、リポジトリに誤ってコミットされた可能性のあるトークンやキーなどの認証情報を検出します。候補となる文字列の中には、実際には認証情報ではないがシークレットと似たものも含まれるため、開発者が対応の必要がないアラートに対して調査時間を割いてしまうことがあります。

単に LLM が文字列を正しく分類できるかどうかを判断するのではなく、セキュリティワークフロー上で安全性を維持しつつ十分な検出率（リコール）を保ちながら、ノイズの多いアラートを減らせるシステムなのかを理解する必要がありました。

本稿では、有望なプロトタイプ段階の結果を実際の製品化へと導くために当社が実践した手法をご紹介します。この教訓は、コード解析、開発者向けツール、セキュリティ、データ分析など、LLM を活用する幅広いシステムの実運用ワークフローに適用可能です。

1. モデル選定よりもまず製品判断を

LLM システムが期待通りに動作しない場合、多くのチームはまず技術的な構成要素の調整を試みがちです。

プロンプトの書き換えやコンテキストの追加、推論ステップの増設、周辺パイプラインの見直し、あるいはモデルの切り替えなどが行われます。しかし、こうした変更を加える前に、評価によって下すべき判断を明確に定義する必要があります。

秘密鍵スキャン（secret scanning）のプロジェクトでは、私たちは以下のような問いを立てました。

「本番環境でのセキュリティワークフローにおいて安全性を担保しつつ、誤検知（false positives）を減らしつつも、必要な検出率（recall）を維持できるか？」

この問いに答えるためには、どの種類のミスを許容するか、製品判断の根拠となる指標は何か、そしてどのようなガードレールを定義された閾値内に保つ必要があるかをチームで決定しなければなりません。

秘密鍵スキャンにおいては、実際の認証情報を誤って抑制してしまうリスクは、開発者に追加のアラートを確認させる手間よりも重大です。そのため、精度（precision）と再現率（recall）を同等に扱える指標として扱うことはしませんでした。

私たちの主な目的は、誤検知（false positive）を減らし、精度（precision）を向上させることでした。再現率（recall）は安全上の制約として機能し、実験が次の段階に進むには、再現率が事前に設定された許容範囲内で低下しないことが条件となりました。これにより、トレードオフを明確に評価する方法が得られました。

私たちは評価基準を3つのレベルに整理しました。

主要な成果指標（Primary outcome）

これは、改善を目指していたユーザー価値を測定するものです：

• 誤検知の削減
• 精度

安全上の制約（Safety constraint）

これは、一見すると改善に見える変更が、許容できないセキュリティリスクをもたらすことを防ぐためのものです：

• 再現率

運用上のガードレール（Operational guardrails）

これは、結果を実際に導入可能かどうかを判断する基準です：

• レイテンシ（遅延）
• コスト
• 信頼性
• 本番環境との互換性

このように指標を区別することで、すべての数値が同等に扱われることを防ぎました。誤検知は減らしたものの再現率が大幅に低下する変更は、自動的に改善とはみなされません。同様に、品質は向上してもシステムが遅くなりすぎたり、コストが高くなったり、統合が困難になったりする変更も、改善とは見なされませんでした。

2 つの仮想的な実験結果を比較してみましょう：

• 実験：精度 / 再現率 / レイテンシ / 判断
• 実験 A：大幅に改善 / 安全ガードレールを下回る / 許容範囲内 / 進めない
• 実験 B：中程度の改善 / ガードレール内に収まる / 許容範囲内 / テストを継続する

精度だけを切り離して見ると、実験 A の方が強く見えるかもしれません。しかし、開発者体験を向上させつつ、リコールのガードレールを破らない点で、実験 B は製品目標とより合致しています。

LLM システムを評価する前に、ユーザーにとっての成功とは何か、システムが守るべきガードレールは何かを明確に決める必要があります。これは、製品判断を支える根拠となる証拠を生み出すためです。

1. オフライン評価は統合テストのように扱う

LLM ベースのシステムは、最初の評価で成功した後も変化し続けます。そのため、評価は一度きりの作業にしてはいけません。チームはプロンプトを修正したり、新しいモデルを採用したり、入力やコンテキストの構築方法を変えたり、周囲のビジネスロジックを洗練させたりします。

これらの変更は、システムの改善につながることもあれば、回帰（性能低下）を引き起こすこともありますし、予期せぬ方向で挙動が変化する可能性もあります。

そのため、私たちはオフライン評価をエンドツーエンドの統合テストと同様に扱いました。プロンプト、モデル、入力の構築方法、あるいはより広範なシステムロジックに意味のある変更を加えるたびに、再実行しました。

また、新しい結果を既知のベンチマークと比較できるように、評価は繰り返し可能である必要がありました。各実行では、使用したプロンプト、モデル、データセットのバージョン、システムの構成を記録しました。

これにより、以下のような問いに答えることが可能になりました。

• 新しいプロンプトは、リコールを低下させることなく精度を向上させたか？
• モデルのアップグレードは、データセット全体で効果があったのか、それとも特定の分野に限られたのか？

入力やコンテキストの変更によって、あるエラーパターンが修正された一方で別のエラーが発生したことはありませんか？

周囲のロジックを変更したことで結果が一貫して改善されたのか、それとも単にエラーが発生する場所が移動しただけだったのでしょうか。

こうした検証を怠ると、チームは異なる条件下で生成された結果を比較し、誤った変更の結果を改善と見なしてしまうリスクがあります。

一度に変更するのは主要変数一つだけにする

再現性があるだけでは不十分です。実験結果の原因が明確になるよう、実験設計も工夫する必要があります。

私たちは一度に一つの主要変数を変更し、各実行結果を既知のベースラインと比較しました。例えば、プロンプトの改訂とモデルのアップグレードは別々に評価した上で、両方を組み合わせたテストを行いました。

これは重要な意味を持ちました。なぜなら、わずかなプロンプトの変更でもモデルの挙動が変化しうる一方、モデルのアップグレードは品質、コスト、レイテンシ、出力の一貫性のすべてに影響を与える可能性があるからです。もし一度に複数の要素を変更すれば、どの変更が改善や後退の原因だったのか特定できなくなります。

私たちはプロンプトと評価設定をコードと同様に扱いました。バージョン管理を行い、何を変更したかを記録し、過去の構成も再現可能に保ち、必要に応じてロールバックできるようにしました。

• Run ID：Prompt version / Model version / Precision / Recall / Latency / Notes
• R-001：v1 / Model A / 0.71 / 0.78 / 1.2s / Baseline
• R-002：v2 / Model A / 0.75 / 0.77 / 1.2s / Prompt-only change
• R-003：v1 / Model B / 0.74 / 0.80 / 1.0s / Model-only change

上記の評価実行追跡表の数値は架空のものであり、評価実行をどのように追跡・比較できるかを示すための例として含まれています。

モデルのアップグレードは定期的にテストする

LLM システムが期待通りの性能を発揮しない場合、開発者はプロンプトに指示を追加することで対応することがよくあります。それが有効なケースもあれば、そうでないケースもあります。例えば、複雑さの原因がモデル自体にある場合、プロンプトにその負荷がかかっている可能性があります。

より強力なモデルは、古いモデルを徹底的にチューニングするよりも、シンプルなプロンプトで高い性能を発揮することがあります。また、シンプルなプロンプトは理解しやすく、テストや保守も容易です。

ただし、モデルのアップグレードには慎重な評価が必要です。新しいモデルは特定の項目では性能が向上しても、別の箇所では後退を引き起こす可能性があります。コスト、レイテンシ、出力フォーマット、既存のパイプラインとの互換性などにも影響を及ぼすことがあります。

評価プロセスは安価で反復可能であるべきです。そうすることで、新しいモデルのテストが日常業務の一部となります。プロンプト、モデル、パイプラインのいずれかに意味のある変更を加える場合は、本番環境に展開する前に必ずオフライン評価を行う必要があります。

1. 本番環境に近い形でオフライン評価を行う

オフライン評価は、システムが本番で実行するタスクと類似している場合にのみ有用です。

シークレットスキャンのワークフローでは、モデルが単一のクリーンな値を評価することはめったにありません。特定の候補を評価する際、関連する周囲のコードや不完全な情報、あるいは注意をそらす可能性のある他の情報を同時に考慮する必要があります。これらの情報がどのように提示されるかによって、結果が大きく異なる可能性があります。

そのため、オフライン評価では本番タスクの重要な特性を維持する必要がありました。具体的には以下の点です：

評価対象となる候補

モデルが利用可能な周囲の文脈

関連する補足情報

入力のフォーマットと制約方法

モデルを取り巻くより広範なシステムロジック

わずかな違いでも結果を歪める可能性があります。クリーンなデータセットは、曖昧なケースを除外したり、より完全な文脈を提供したり、モデルの注意を逸らす可能性のある近傍値を除去したりします。

単純化した例を考えてみましょう。

example_token = "sample_value_for_documentation"

production_api_key = get_secret_from_environment()

candidate_value = "flagged_value"

candidate_value がシステムが評価すべき値であると仮定します。しかし、モデルは変数名の方がセキュリティに関連して見えるため、例の example_token に注目し、誤った値についてもっともらしい説明を生成する可能性があります。

このような失敗は、評価例に明白な候補が一つしかない場合に見逃されやすいものです。今回のケースでは、オフライン評価で実際のシークレットスキャンワークフローで見られる曖昧さや注意散漫要素の一部が保持されていたため、この問題が表面化しました。

オフラインパイプラインが生産パイプラインに近いほど、評価の有用性は高まります。両者が異なる場合、優れたオフラインスコアは、単にデプロイされる問題よりも簡単な問題を解いているだけを示している可能性があります。

1. 生産ラベルを疑うべき真実ではなく、シグナルとして扱う

本番データは評価をより代表力のあるものにできますが、そのラベルはワークフローの結果を捉えているだけで、信頼できる正解（グランドトゥルース）を示しているとは限りません。例えば、シークレットスキャンの警告が「却下」または「解決」と表示されても、それが必ずしも誤検知（フェイクポジティブ）を意味するわけではありません。

開発者が警告を解決する理由は様々です。

• 認証情報をローテーションした
• リスクを受け入れた
• ワークフローをブロック解除するために警告をクリアする必要があった
• 警告の分類が誤っていた

これらの結果は製品データ上では似通って見えることがありますが、実際には異なる正解の状態を表しています。

本番ラベルを使用する前に、以下の点を自問してください。

• ラベルはどのように作成されたのか？
• そのラベルは、評価で答えようとしている問いに合致しているか？
• 異なるワークフローの結果が同じカテゴリにまとめられていないか？

重要または曖昧なサブセットについては、手動レビューを行う必要があるかもしれません。完璧でないラベルをすべて排除しようとするのではなく、意思決定を支えるのに十分な精度で評価データが正確であることを確保することが重要です。

1. 合成データやオープンデータセットを活用してカバレッジの隙間を埋める

開発初期段階では、代表力のある本番データが限られている場合や、機密性が高く利用できないこともあります。その際、合成例や学術ベンチマーク、オープンデータセットは、評価の基盤作りとカバー範囲の拡大に役立ちます。ただし、これらは本番に近いデータを代替するものではなく、補完するものとして活用すべきです。

その点を踏まえると、合成データは、曖昧な入力や文脈の欠如、特殊なフォーマット、そして十分に代表されていない失敗パターンなど、収集が困難または稀なテストケースを補う上で大きな役割を果たします。例えば、認証情報の文字列リストを作成すれば、モデルが一般的な形式を認識できるかを確認できますが、実際のコード内での候補に対する推論能力まで完全に評価することはできません。

私たちは外部の例を自社のタスクに合わせて調整し、製品定義と整合しないラベルを見直しました。また、近接する認証情報風の値、テストコード、プレースホルダー、間接的な参照、文脈の欠如などを含む、ターゲットを絞った合成ケースを作成するために、現実的な失敗パターンを利用しました。

1. エラー分析を用いて、集計指標が隠しているものを明らかにする

集計指標はシステム全体が改善されたかどうかを教えてくれます。一方、エラー分析は次に何を修正すべきかを教えてくれます。

精度スコアが高くなったとしても、残りのエラーが曖昧な入力、プロンプトの構成不良、文脈の欠如、ノイズの多いラベル、あるいは限定的なデータセットに起因するものなのかどうかは分かりません。

これらの問題を理解するには、失敗事例を精査する必要があります。

私たちは偽陽性と偽陰性のサンプルを見直し、それらの発生源として考えられるモデル、プロンプト、入力、パイプライン、データセット、ラベルのいずれかに分類しました。繰り返し見られた問題には、すでに議論した内容も含まれており、例えば候補に対する誤った推論、文脈の欠如、評価定義と一致しないラベルなどが挙げられます。

各カテゴリは異なる対応策を示唆します。誤った値への推論はプロンプトや入力の枠組みに問題があることを示し、証拠の欠如は文脈構築の不備を意味し、ラベルの誤りはデータクレンジングが必要であることを示します。ドメイン固有の曖昧さが繰り返される場合は、より明確な製品ポリシーや専用の評価カテゴリの導入を検討すべきです。

数十から数百の事例を手動でレビューするには時間がかかりますが、これにより迅速な改善につながることが多いです。繰り返し発生する失敗パターンが明確になれば、チームは特定の対策を講じ、その効果を検証できます。

各エラーに対して問うべき有用な質問があります。「この失敗はモデル自体、プロンプト、入力、パイプライン、データセット、それともラベルに起因するのか？」という問いです。

この分類により、漠然とした品質の問題を具体的なエンジニアリングタスクへと変換できます。

1. LLM-as-judge を活用して人間のレビューに集中する

すべての評価事例を手動でレビューすることはスケーラブルではありません。LLM-as-judge（LLM による判定）を活用することで、明確なケースの分類や誤ってラベル付けされた可能性のある事例の特定を行い、人間がレビューすべき曖昧なケースを優先順位付けできます。ただし、判別者も誤りを犯すことがあり、別のモデルと間違った理由で合意することもあるため、その出力は正解（ground truth）ではなく、一つの予測結果として扱うべきです。

より安全な運用パターンとしては、判別者をトリアージ（選別）に活用することが挙げられます：

• 明確でリスクの低いケースを自動的に処理する
• 信頼度が低い、矛盾がある、または影響が大きいケースは人間レビュー担当者に振り分ける
• 定期的に高信頼度のケースをサンプリングし、体系的な誤りがないか確認する

評価者（ジャッジ）、評価対象システム、人間レビューヤーの間の不一致を追跡する。

評価用プロンプトは他のモデルコンポーネントと同様にバージョン管理し、評価を行う。

このように活用することで、評価者の判断が結果を大きく変える可能性が高いケースに人間の注力を集中させることができる。

1. シークレットスキャンから得た教訓

私たちの目標は、セキュリティに敏感なワークフローにおいて、偽陽性を減らしつつ再検出率（リコール）を維持することでした。オフライン評価により、オンライン実験を開始する前に、プロンプトやモデル、入力データ、パイプラインの変更点を比較・検証できる統制的な環境が得られました。

反復的な評価とターゲットを絞ったエラー分析を通じて、評価用オフラインデータセット上で偽陽性を 95% 削減することに成功し、かつ再検出率は事前に定義したガードレール内に維持できました。さらに重要なのは、結果がどのように導き出されたかを理解できた点です。評価は本番タスクをより忠実に反映しており、変更点は再現可能なベースラインに対して測定され、残存する失敗パターンも文書化されました。

オフライン評価が、すべての本番シナリオにおけるシステムの挙動を保証するものではありませんでした。しかし、明確に理解されたリスクとガードレールのもとでオンライン実験へ移行することを正当化する十分な構造化された証拠を提供しました。

チェックリスト：LLM システムを本番環境へ移行する前に確認すべき事項

本チェックリストを用いて、評価結果がシステムを次の段階へ進めるに十分な根拠を持っているかを確認してください。各項目を順に確認し、目標・データ・実験内容、そして残る生産リスクが明確に理解できているかを検証しましょう。

製品目標

製品の判断基準と主要な成功指標は明確ですか？

安全性や運用上のガードレールは定義されていますか？

データとラベル

評価用データは実際の運用ワークフローを反映しており、困難なケースも含まれていますか？

ラベル作成のプロセスを理解し、どこで人のレビューが必要かを把握していますか？

評価の厳密性

プロンプト、モデル、データセット、パイプラインのバージョンは記録されていますか？

主要な変更点は単独で検証され、既知のベースラインと比較されていますか？

エラー分析と生産準備

偽陽性と偽陰性はカテゴリ別にレビュー済みですか？

評価を再実行でき、オフライン結果が実際の運用環境とどこで異なるかを説明できますか？

信頼する前に評価を

LLM を活用したシステムが生産環境へ移行するにつれ、評価は通常のエンジニアリングワークフローの一部として組み込まれるべきです。堅牢なオフライン評価によって、代表的な条件下で製品目標が達成されたかどうか、不確実性がどこに残っているか、そして制御された生産展開の準備ができているかを明らかにできます。

生産環境における不確実性は避けられません。評価を行うことで、それを可視化し、測定可能にし、管理可能なものにできるのです。

シークレットスキャンに関するドキュメントを探索する >

本記事「How to evaluate LLMs before production」は、The GitHub Blog に初出されました。