利益:
- モデルの劣化の隠れた原因 (データ ドリフト、コンセプト ドリフト、上流エラー) を認識し、3 層 (運用、入力、出力) モニタリングを確立する機能
- ルールチェック、LLM 審判および人間の評価を使用して複数のレイヤーで LLM システムを評価し、LLM 審判の人間アンカーを使用して調整する機能
- エッジ ケースとセキュリティ ケースを含む評価セットを設計し、検出された各エラーを永続的なテスト ケースに変える機能
モデルが実稼働に入ったら、作業は完了ではありません。本当の責任はこれから始まります。なぜなら、モデルは誰も見ていないときに静かに故障する可能性があるからです。この単元では、評価 (モデルの品質を体系的に測定する) とモニタリング (運用環境でのモデルの継続的なモニタリング) という 2 つの補完的な分野を取り上げます。特に LLM システムでは、eval は従来の ML よりも難しく、より注意が必要です。
なぜ量産モデルは静かに故障しつつあるのか
バグがクラッシュし、ログが出力され、アラームが鳴ります。一方、ML モデルは、エラーを引き起こさなくても、間違っている可能性があります。劣化の主な原因は次の 3 つです。
- データドリフト: 入力データの分布は時間の経過とともに変化します (新製品、ユーザー行動の変化、季節性)。モデルは同じままですが、世界は変わります。
- 概念ドリフト: 入出力関係が変化します。詐欺の手口とスパムのパターンは進化します。昨日正しかったことは今日は間違っているでしょう。
- 上流の破損: データ ソースの形式が変更され、領域が空きます。モデルは破損した入力を静かに垂れ流します。
トレースすると、これらの静かな歪みが聞こえるようになります。
注目すべきもの: 3 つのレイヤー
優れたモニタリングには次の 3 つの層が含まれます。
- 運用メトリクス: レイテンシ、エラー率、リクエスト量、リソース使用量。 「システムは正常ですか？」
- データ/入力メトリクス: 入力分布はトレーニング時の分布と似ていますか?欠損値率は増加しましたか?新しいカテゴリーが登場しましたか? 「モデルは見慣れたデータを参照していますか?」
- モデル/出力メトリクス: 予測分布ログ?自信スコアが低下しましたか?また、可能であれば、グラウンド トゥルースと比較した精度はどの程度ですか? 「モデルはまだ正確ですか？」
3 番目の層は最も価値がありますが、最も困難です。なぜなら、実際の結果は通常、遅れて現れるからです（ローンが返済されるかどうかは数か月後に明らかになります）。
ヒント: 実際の結果が遅れる場合は、まず入力と予測の分布を監視します。入力分布の変化は精度低下の初期の兆候であり、実際の結果を待たずに警告を発する可能性があります。
LLM システムの評価: 特別な課題
古典的な ML では、「正解」は明らかです (クラス 0 または 1)。一方、LLM の結果は無制限です。同じ質問に対して多くの正解が存在する可能性があり、「正しさ」は 1 つの数字には収まりません。 LLM 評価のアプローチは次のとおりです。
- 参照されるメトリクス: 出力と理想的な答えを比較します。限定;なぜなら、別の方法で表現された正解を「間違っている」とみなす可能性があるからです。
- ルールベースのチェック: 出力は有効な JSON ですか?禁止用語はありますか？必要なフィールドが含まれていますか?安くて、信頼性が高く、しっかりしています。
- LLM 判事 (LLM 判事として): モデルに「この基準によれば、この答えは良いですか?」と尋ねさせないでください。それはスケールしますが、審判自体を検証する必要があります。
- 人間によるレビュー: ゴールドスタンダードだが高価で遅い。サンプルで使用しております。
実際には、これらは一緒に使用されます。各出力に対する安価なルール チェック、大きなサンプルに対する LLM 判定、小さいが厳密なサンプルに対する人間による評価です。
弱いアプローチ / 強いアプローチ
弱者: 「LLM-審判に尋ねたところ、92% の答えが良好でした。システムは素晴らしいです。」
ギュシュル氏: 「私たちはまず、100 枚のプリントアウトに人間によるラベルを付けました。同じ 100 枚のプリントアウトに対して LLM 審査員を実行し、人間と審査員の一致度を測定しました。85% の一致、許容範囲内でした。私たちは、審査員が系統的に間違った箇所 (長答が不当に良いと判断する傾向) を文書化し、プロンプトを修正しました。そのとき初めて、審査員のスコアを信頼しました。」
違い: 強力なアプローチでは、盲目的にではなく、人間のアンカーを使用して審判を確認します。検証されていない LLM 審判は、見た目は良いが誤った自信を与えます。
注意: LLM 審判員もモデルです。幻覚性、偏見（長い答えや自信に満ちた答えを好む）、一貫性がない可能性があります。本番の決定を下す前に、人間のタグを使用して審判のスコアを調整します。
評価セット: 慎重に設計
優れた評価セットは、さまざまな実際の使用法と困難なケースを表します。簡単な例だけで満たされた評価では、誤った自信が残るでしょう。必ず eval クラスターに入れてください。
- エッジケース: 空の入力、非常に長い入力、異常な形式。
- 既知の困難なケース: モデルが過去に間違いを犯した例 (回帰テストとして)。
- セキュリティ インシデント: 即時インジェクションの試み、悪意のあるリクエスト、プライバシー侵害のトラップ。
評価クラスターは時間の経過とともに成長します。本番環境で発見した新しいバグはそれぞれ、次の評価のテスト ケースになります。
警報と介入
アラームがなければ監視は不完全なままです。 「入力ドリフトが X を超えた場合はエンジニアに通知する」、「エラー率が Y を超えた場合は自動ロールバックする」など、重要なメトリクスごとにしきい値と対応計画が必要です。アラームを意味のあるものに保ちます。誤ったアラームが多すぎると、チームの感覚が鈍くなり、本当のアラームを見逃してしまいます。
ミニケース3個
ケース 1 - 早期警告。需要予測モデルの真の精度が明らかになったのは、週末になってからです。チームはインプットの分布を監視しており、火曜日に新しい製品カテゴリが突然登場したことを確認しました。これは、このモデルではこれまでに見たことのないことでした。彼らは精度の低下を待たずにモデルを更新しました。入力監視により日数が節約されました。
ケース 2 - 未確認の審判。あるチームは、LLM レビューアに基づいて「当社の品質は優れている」と報告しました。顧客からの苦情が増えると、人間による監視が導入されました。審判は自信を持って間違った回答を「良い」とみなしました。審判が人間のタグで調整されると、真の品質が明らかになり、はるかに低くなりました。教訓：審判を確認せずに信用してはいけない。
ケース 3 - 回帰テスト。迅速な変更により 1 つの問題が解決されましたが、別の問題は静かに解決されました。しかし、チームは過去のバグを評価バケットに保存しました。このクラスターで新しい変更をテストすると、壊れたケースがすぐに検出され、変更が修正されました。教訓: 修正されたすべてのバグは永続的なテスト ケースになる必要があります。
コピー可能なテンプレート
この量産モデルの追跡計画を作成します。 3 つのレイヤーをカバーします:1) 運用 (レイテンシー、エラー率、ボリューム)2) 入力/データ (分布シフト、欠損値、新しいカテゴリ)3) モデル/出力 (予測分布、信頼性、可能であれば精度)モデル: [説明]。実際の結果が到着するまでにかかる時間: [期間] 各メトリクスのしきい値と介入の推奨事項を追加します。
この LLM システムの評価 (eval) 戦略を提案します。タスク: [説明] レイヤーを決定します:- 各出力でどのルールベースのチェックを実行する必要がありますか?- LLM アービトレータはどのような基準を評価し、どのように検証する必要がありますか (人間アンカー)?- どのサンプルで人間による評価を実行する必要がありますか?評価セットに含める必要があるエッジ ケースと安全ケースをリストします。
この LLM 審判プロンプトを確認してください:- 評価基準は明確ですか、それとも主観的ですか?- 長さ/信頼度バイアスが発生しやすいですか?- 人間のタグを使用して審判を調整するにはどうすればよいですか?審判プロンプト: [プロンプト]
この監視アラームの応答ランブックを作成します。アラーム: [例:入力ドリフトしきい値を超えました] 含める必要があります: 初期制御手順、考えられる原因、ロールバック基準、通知先。
劣化原因表
歪み
症状
早期発見への道
データドリフト
入力分布の変更
入力分布監視
コンセプトシフト
正義は静かに落ちる
予測+実際の比較
上流エラー
フィールドが空になる/フォーマットが変更される
スキーマ検証 + 欠損率
モデルの不一致
生産量分布の変化
出力分布監視
よくある間違い
- 監視を確立していない。モデルは静かに壊れ、誰もそれを見ません。
- 運用指標のみを追跡します。システムは稼働していますが、予測が間違っている可能性があります。
- 審判を確認せずに LLM を使用する。それは誤った自信を与えます。
- 簡単な例を含む評価。実際の難易度を示すものではありません。
- eval には過去のエラーは含まれません。同じエラーが再び返されます。
- 大音量のアラーム。チームは鈍感になり、本当の警報を見逃してしまいます。
要約すると
モデルが不正確であっても、本番環境でエラーが発生することはありません。したがって、評価と監視は開発と同じくらい重要です。 3 つの層 (運用、入力、出力) で監視を確立します。実際の結果が遅れる場合は、入力ドリフトを早期警告として使用します。 LLM システムでは、eval には制限がありません。ルールチェック、LLM 審判、および人間による評価を併用します。ただし、LLM 審判は必ず人間のアンカーで検証してください。 Eval クラスターをエッジ ケースとセキュリティ ケースで強化し、検出されたすべてのエラーを永続的なテスト ケースに変換します。
アプリケーションタスク
実稼働 (または実稼働に近い) モデルの 3 層監視計画を作成し、少なくとも 1 つの入力分布メトリックのしきい値とアラームを定義します。 LLM システムをお持ちの場合: 30 個の出力に人間がタグを付け、同じ出力に対して LLM 審判を実行し、人間と審判の一致を測定します。審判の系統的な偏見に注意してください。少なくとも 3 つのエッジと 2 つのセキュリティ ケースを評価クラスターに追加します。
チェックリスト
- [ ] モニタリングは 3 つの層 (運用、入力、出力) すべてをカバーします。
- [ ] 実際の結果が遅れた場合の早期警告として入力ドリフトを使用します。
- [ ] LLM アービトレータを人間のラベルで調整しました。
- [ ] Eval クラスターには、エッジ ケースとセキュリティ ケースが含まれています。
- [ ] 私は見つけたすべてのバグを永続的なテスト ケースに変えました。
- [ ] 重要なメトリックにはそれぞれ、しきい値と対応計画があります。