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

[＠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システム評価のチェックリストを提示している。本番環境の不確実性は避けられないものの、評価によってそれを可視化し、測定可能にし、管理できるようになると結論付けている。