「ベンチマーク高得点」AIでも“本番”で障害頻発 GitHubがLLMの誤検知を「95％削減」した7つの教訓：LLMを本番に出す前にやるべきこと（2/2 ページ）

GitHubは、LLMを本番環境への展開前に評価する方法について解説したブログ記事を公開した。

[＠IT]

教訓4．本番データのラベルはシグナルとして扱う

　本番データを評価に使用すれば、評価データの代表性が高くなるが、本番データのラベルは、「信頼できる正解」というよりも、ワークフローの結果を反映していることが多い。例えば、解決済みのシークレットスキャンアラートは、誤検知だったとは限らない。「認証情報がローテーションされた」「リスクが許容された」「ワークフローのブロック解除のためにアラートを解消する必要があった」といった可能性がある。

　GitHubは、本番データのラベルを使用する前に、「各ラベルがどのように作成されたか」「ラベルは、評価によって解明しようとしている問題に当てはまるかどうか」などを確認することを勧めている。

　重要または曖昧なサブセットについては、手動によるレビューが必要になる場合があるとしている。

教訓5．合成データセットやオープンデータセットを活用する

　代表的な本番データが限られている場合や、それらの機密性が高い場合は、合成例、学術ベンチマーク、オープンデータセットでカバレッジを拡大できる。

　ただし、「これらは本番データに代わるものではなく、補完的なものとして使うべきだ」と、GitHubは指摘する。合成例は、発生頻度が低いか、収集が困難なテストケースのギャップを埋めるのに役立つ。

教訓6．集計指標では分からない問題点をエラー分析で発見する

　集計指標はシステムが全体として改善したかどうかを示すが、次に何を変えるべきかを示すのは、エラー分析だ。

　GitHubは誤検知と検知漏れのサンプルをレビューし、「モデル、プロンプト、入力、パイプライン、データセット、ラベルのうち、どれに起因するか」で分類した。カテゴリーごとに取るべき対処は異なる。こうした分類により、漠然とした品質問題が具体的なエンジニアリング課題へと変わる。

教訓7．LLM-as-judgeを活用し、人的レビューの対象を絞り込む

　全ての評価例を人が手作業でレビューするのは現実的ではない。そこでGitHubは、AIの出力を別のAIが評価する手法「LLM-as-judge」（ジャッジとしてのLLM）を活用し、人間によるレビューの対象を絞り込んだ。明確で低リスクなケースは自動処理し、信頼度が低いケース、判定が食い違うケース、影響が大きいケースは人間のレビュワーに回すとともに、信頼度が高いケースも定期的にサンプリングし、体系的なエラーがないかどうかを確認することを勧めている。

　ただし、ジャッジとの主体となるLLM自体も間違えることがあり得る。そのため、その出力は正解ではなく、「もう一つの予測」として扱い、ジャッジに対するプロンプトも、他のモデルコンポーネントと同様にバージョン管理すべきだ。

LLM-as-judgeを活用し、人間によるレビューの対象を絞り込むトリアージファネル：全ての評価例（モデルの出力と信頼できる正解のラベル）はファネル（じょうご）に入り、「明確な合意」「信頼度が低い」「モデルとラベルの不一致」「影響が大きいケース」の4グループに分類される。明確な合意がある評価例は自動処理に移行し、他の3グループは、結果決定とラベル修正のために人間によるレビューに回される。レビューされた例、修正されたラベル、新しいテストケースは、評価データセットにフィードバックされる（提供：GitHub）

オフラインデータセットで誤検知を95％削減

　評価と的を絞ったエラー分析を繰り返した結果、GitHubは、再現率を定義済みのガードレールの範囲内に維持したまま、評価対象のオフラインデータセットで誤検知を95％削減した。

　同社は、「この結果がどのように生み出されたか」を理解できたことが、より重要だったと強調する。評価は本番タスクをより忠実に反映するようになり、変更点は再現可能なベースラインに対して測定され、残る失敗パターンも文書化された。

　オフライン評価は「あらゆる本番シナリオでシステムがどのように動作するか」を証明したわけではないが、リスクとガードレールを明確に理解した上で、オンライン実験への移行を正当化するのに十分な、構造化された証拠を提供したとしている。

　GitHubは記事の最後で、プロダクト目標、データとラベル、評価の厳密さ、エラー分析と本番対応度をカバーした、LLMシステム評価のチェックリストを提示している。本番環境の不確実性は避けられないものの、評価によってそれを可視化し、測定可能にし、管理できるようになると結論付けている。