## 定義 モデルの確実性検証とは、モデルの新しいバージョンを運用に投入する前に、そのモデルがシステムレベルの障害やクラッシュを引き起こさないかを確認する一連のチェックを指す。モデルの品質(予測が役に立つか)とは独立した評価軸であり、恐ろしく不正確でも安全に動くモデルと、オフラインでは高性能でも運用スタックを破壊するモデルの両方がありうることを前提に置く。検証項目は、(1) 提供しようとしているモデルのバージョンが実際に使用しているバージョンと一致しているかの確認、(2) 運用環境のコピーでモデルが実際にロードできるかの確認、(3) 最小限の1リクエストに対してモデルが環境を破壊せず結果を返せるかの確認(プラットフォームバージョンの非互換性・特徴量バージョンの非互換性・破損したモデル・パイプラインの欠如・範囲外の結果という5つの典型的失敗要因を含む)、(4) レイテンシ・メモリ・計算コストが許容範囲内かの確認、(5) 運用環境への段階的なカナリアリリースの5点に整理される。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 5 モデルの確実性と品質の評価]] §5.1) ## 横断的知見 - **同じ「訓練運用間のずれ」という失敗モードを、5章は事前のゲート(1回きりの確実性チェック)として、9章は継続的な監視対象として、それぞれ異なるライフサイクル段階で扱う**: 5章§5.1は、特徴量を生成するコードが訓練スタックと運用スタックで異なることに起因する「訓練運用のずれ」を、デプロイ前の最小リクエストテストで検出すべき失敗要因の1つとして位置づける。これに対し[[MLモデル監視]]が整理するとおり、[[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 9 モデルの監視と可観測性]] §9.2.1は同じ現象(訓練運用間スキュー)を「回避可能な機能停止の一般的な原因」として、デプロイ後も継続して監視すべき対象に位置づけ、[[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning]]の症状ベースアラーティングでも例外的にPriority 1へ格上げされる項目として扱われる。同一の失敗モードに対して、5章は「デプロイ前に一度だけ通過すればよい関門」、9章は「デプロイ後も繰り返し発生しうるため継続監視が要る対象」という異なる時間軸の対処を与えており、確実性検証と継続的監視は代替関係ではなく補完関係にあることが分かる。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 5 モデルの確実性と品質の評価]] §5.1, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 9 モデルの監視と可観測性]] §9.2.1) ## 未解決の問い - 確実性チェックの各項目(バージョン確認・ロード確認・最小リクエスト確認・計算性能確認・カナリアリリース)は、CI/CDパイプラインのどの段階にどう自動化して組み込むべきか。本ソースは自動化の重要性を述べるが具体的な実装方式には踏み込んでいない。 - モデルファイルのサイズとロード時のメモリ使用量が「緩やかにしか相関しない」と本ソースは述べるが、デプロイ前にメモリ使用量を見積もる具体的な方法は示されていない。 - 確実性チェックが失敗した場合にどの段階まで切り戻すべきか(モデルの定義まで戻るのか、訓練済みモデルの再選択で済むのか)は、[[モデルアーキテクチャ・定義・訓練済みモデル]]の3層区別とどう対応づけられるか、本ソースでは扱われていない。 ## 関連 - source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 5 モデルの確実性と品質の評価]] / [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 9 モデルの監視と可観測性]] - concept: [[モデルアーキテクチャ・定義・訓練済みモデル]](「正しいモデルか」の確認対象となるモデルバージョンの単位) / [[MLモデル監視]](訓練運用間スキューという同じ失敗モードを継続監視の観点から扱う) / [[カナリアテスト]](段階的カナリアリリースという確実性検証の最終段階) / [[評価データ分布の設計]](確実性検証を通過した後に行うモデル品質評価) ## 出典 - Cathy Chen ほか, 『信頼性の高い機械学習 ―SRE 原則を活用した MLOps』, オライリー・ジャパン, 2024, 5章, §5.1.