顧客の問い合わせ傾向が変わり、分類モデルの見逃しが増えている。
モデルを再学習すべきか判断したい。
監視する情報として適切なものを2つ選べ。
本番では入力分布の変化と、ラベルが得られた後の実績性能を監視し、再評価や再学習の契機を判断する。
詳細解説
本番入力が訓練時の分布から変わると、性能低下の兆候になり得る。
問い合わせの種類や語彙、利用者構成の変化は、訓練や基準期間との違いを示す。データ変換やラベル定義の変更も確認し、入力が変わっただけで再学習が唯一の解決策だとは判断しない。
独立した正解ラベルを使わない自己照合では、実際の見逃しを測れない。
予測をそのまま正解ラベルにすると、モデルの誤りを外から検証できない。問い合わせの確認結果など、信頼できる実績と対応付けて評価する必要がある。
応答の成功と分類の正しさは異なるため、予測品質の代わりにはならない。
HTTP200の割合が高くても、誤ったクラスを返している場合がある。応答エラーや遅延は別に監視し、この問の見逃しや再学習の判断には、正解ラベルに基づく性能を用いる。
実際の結果が得られれば、精度や再現率などを継続評価できる。
対象クラス20件中18件を検出した場合の再現率は90%、8件なら40%となる。この例では残りが見逃しに当たる。全体の正解率だけでは、件数の少ないクラスで増えた見逃しを把握しにくい場合がある。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
Task 1.3のMLOps・監視・性能指標と、予測と正解ラベルを照合する公式説明を読む。仮想の問い合わせ分類で、実際の対象クラス20件のうち検出18件/見逃し2件だった期間と、検出8件/見逃し12件だった期間の再現率を比較する。
参考にした公式資料
確認できる内容
対象クラスの再現率は18/20=90%から8/20=40%になる。HTTP応答の成功やモデル自身の予測ラベルとは分け、ラベル定義・分類しきい値・評価期間を確認して再評価や再学習の必要性を判断できる。
理解のポイント
- データドリフト
- 性能監視
- 再評価
確認時の注意
- 確認環境: 公式資料と仮想の計算例による参照確認。AWSリソースの作成、推論の実行、実利用者データの取得は不要。
- 数値は仮想例。正解ラベルの対応、対象クラス、評価期間、分類しきい値をそろえ、再現率だけで誤検知や業務上の影響まで評価済みとはしない。
- 分類モデルの本番監視と再学習はTask 1.3に対応する。基盤モデルの性能評価方法を扱うTask 3.4を、一般的な運用監視のTask名として使わない。
- 参照したSageMaker Model Monitorの公式資料には、新規顧客への提供を終了し既存顧客は継続利用できると記載されている（2026-10-28確認）。監視の原理を学ぶ問題であり、新規アカウントで同サービスを必ず有効化できるという意味ではない。
基礎のおさらい
対象クラスの再現率
実際にそのクラスだった件数を分母に、正しく検出した件数の割合を求める。ここでは見逃しを直接確認する観点となる。
ラベルと分類条件の整合
モデルの予測とは独立した正解ラベルを対応付け、クラス定義や判定しきい値を記録する。条件が変わった差をモデルの劣化だけと決め付けない。
サービス成功と予測の正しさ
HTTP200などは処理が応答したことを示しても、問い合わせを正しいクラスへ分類したことを保証しない。運用の健全性と予測性能は別に測る。