この記事は、機械学習工学／MLSE Advent Calendar 2019、14日目の投稿記事です。
問題設定
近年、各企業内で複数の機械学習関連のPoC（概念検証,Proof of Concept）の痕跡がシステム内に残り、運用効率を低下させる要因の一つとなっている事例を多く目にします。例えば、使いかけの実験用インスタンス、トライアル導入したままのツール、そして実運用されている基盤が組織ごとに乱立し、管理が放棄されている状況です。RPAなどの導入も相まって、各事業会社でこうした「野良AI」が、ちらほらあるという状態が生じつつあります。
これらの発生する原因は、PoC、システム実装した側において、初期計画としてのシステムの全体像が無かったからという他ありません。
このため、単発的なPoCを抑制し、環境の乱立を防ぐための手段を検討します。
モチベーション
筆者は統計モデルのアナリストとして、受託型データ分析、PoC、システム実装に長年取り組んできました。その中で、企業の独自環境でのモデル開発するタスクにも多く対応してきました。
独自環境では、ネットワーク上の制約などから、分析環境を必ずしも最適な状態では確保できないという問題が生じます。また、アプリケーションとの連携性の点から、各プロジェクトごとに環境構築、実装用の基盤を構築する対応を取らざるを得ないこともありました。
こうした取り組みが、上記の問題を発生させる原因となっている可能性を鑑み、自省的な面も含め、対策を検討します。
事業会社において、ありがちなPoC
一般的なシステム開発におけるPoCの目的としては、主として、
- 導入効果の検証
- 技術的実現可能性の検証
の２点が挙げられます。
その上で、筆者の主観において、
多くの事業会社での機械学習システム導入プロジェクトにおいては、それぞれ
- 導入効果の検証 → システム導入による削減効果の検証
- 技術的実現可能性の検証 → モデルとしての精度
などが重視される傾向があります。
この際、導入効果が具体的なフローとなっているため、PoC時点でも個別具体的なタスクに対して、固有のモデル構築による検証が求められます。特定のタスクに対して、様々な試行錯誤を経てデータパイプライン、モデル精度向上が試みられ、その成果として、一連の処理が構築されています。
これらのPoC結果を資産としてそのまま開発フェーズに持ち込むことで、
個別の分析環境が分散化、固有化するという状態が発生し、
野良AIが社内の様々なフローで稼働して続けている状況が発生しているのではないかと考えます。
望ましいシステムの在り方
19年12月に発表された早大の鷲崎教授らが手がけられた論文
Studying Software Engineering Patterns for Designing Machine Learning Systems
では、機械学習システムのアーキテクチャ・デザインパターンが整理されています。
この論文は、各文献から代表的なMLのアーキテクチャ・デザインパターンの分類を試みたものであり、上記の課題感に対応したアーキテクチャパターンも提案されています。
例えば、
- Design Holistically about Data Collection and Feature Extraction
データ収集と特徴量抽出を統合的に設計し、パイプラインジャングルを解消する。
- Data-Algorithm-Serving-Evaluator
機械学習のMVC（Model-View-Controller）として、データ、アルゴリズム、推論、評価を分離する。
こうしたアーキテクチャパターンは、PoC時点での複雑なパイプライン、モデルを整理し、統合的に処理することを志向しています。
実際に、これらの技術的担保として、各社のクラウドサービス上では、DL向けコンテナや、トレーニング、検証、デプロイのために機械学習のカスタムワークフローの構築を容易にするためのサービスも展開されています。PoC時点から、分析用コンテナで独立してモデル構築することで、システム上の多くの問題は解決できます。
ただし、コンテナとして各環境が分離していたとしても、その内部でのテスト状況、コードが管理されない状態が維持される可能性は残っています。この点で、本質的な解決にはなっていない可能性もあります。
遡って、そのPoC、本当に個別具体的にモデル構築する必要はあったのか？
身も蓋もないのですが、お読み頂いている方が従事されているプロジェクトにおいて、ふと、本当にPoCでそんなにモデルを作る必要があったのか、と感じることはないでしょうか。
PoCの目的は、主として、
- 導入効果の検証
- 技術的実現可能性の検証
の２点ですが、現状の機械学習プロジェクトにおいては、後者の技術的実現可能性の検証に注力されすぎているように感じます。
対象となるタスクフローにおいて、完全に自前でモデルを作りきらなければならない場面は、実際は少なく、汎用モデルでも代替出来るものも部分的に含まれています。特に音声認識、画像認識、各データの特徴量化などは汎用的なモデルが提案されています（Cloud Speech API等々）。
PoC実施者は、まずはこれらの組み合わせにおいてアルゴリズムを組み合わせ、タスクに対応するロジックを組むことからスタートすることが重要です。これらの汎用的なアルゴリズムの利用は、上記の後続での統合を親和性が高く、アプローチの検証を容易とします。
一方で、逆に導入効果の検証においては、運用過程でのエラー処理、データの生成分布の変化の可能性なども含めた効果検証が軽視されています。これらは逆に運用時を想定し、仮想的に検証しなければならず、経験値が発揮される領域です。
このように現状PoCにおいては重視されているポイントは、システム実装とズレがあり、それらを修正していくことで、「野良AI」の発生を抑制していくことが出来るのではないかと考えています。
PoC段階から出来ること
- 最新論文の利用以前に、共通化、汎用化が出来る部分を切り出す
- 統合を想定した分析基盤を構築し、PoCから利用
- 分析基盤の社内共有化
- 組み込みアプリケーションと疎結合を前提とし、各種コンテナを利用