機械学習を搭載したシステム(MLシステム)やプロダクトの開発は、保守・運用フェーズが(PoCや開発フェーズに比べて)辛いです。その辛さを軽減しよう、すなわち、保守・運用をしやすいようにMLシステム開発をしようとする試みは、MLOpsと呼ばれています。
現行(2019年)で、MLOpsにベストプラクティスは存在していません。そのため、MLシステム開発に携わるエンジニアは日々同業者と勉強会で、自分がMLシステムを開発するにあたって、どういう課題があって、どう解決しようとしてるかを議論し、ナレッジを貯めています。
私もご多分に漏れず、MLシステムの保守・運用に苦しんでいるうちの一人です。ただ、今一度我が身を振り返ってみると、何が苦しいのかを言語化していませんでした。そこで、この記事では、課題を文字に起こすことで思考を整理したいと思います¹。

現時点での課題リスト

ML部隊とOps部隊の役割分担がアンバランス
- ML部隊がPoCをやって、いい精度が出るモデルができ次第、Ops側にモデルやコードを渡してスキルトランスファーが完了ということがあります。渡されたコードに説明はなく、readmeにモデル学習のさせ方だけが書いてあったりします。
- そうなると、MLシステムのMLモデル周りでなにか不具合が見つかった時、コードのデバッグをするのは運用側になります。
  - 保守対象のMLのコードというのは、アカデミアのリポジトリを引っ張ってきていることが多いため、コード品質はお世辞にも良いとは言えないことが多いです²。そのため、保守が大変になりがちです。
  - すると、ML側よりも、そのコードを理解する必要がでてきます。そうなると、MLモデルの選定はML側なのに、面倒を見るのはOps側というアンバランスさが発生します。
「MLシステムの運用・保守は辛い」という認識がされていない。
1. 良い精度 ≠ 良いシステム
  - 上のこととも関連しますが、モデルの精度を高めることで、保守性が悪化することもあります。手法をSotAなMLモデルに差し替えれば精度はあがるものの保守にコストが取られて旨味がないこともありえます。
  - 研究(PoC)のコードを、製品ver.に流用しようとするのはくれぐれもやめた方がいいと思います。
2. 人事評価でOpsが不当に低い
  - ML側とOps側で、どう評価を換算するかが整備されていないことが根本的な要因だと思います。
MLモデルの推論結果の(主に顧客への)説明責任が難しい。
1. 信頼度(事後確率)が正解・不正解と相関がない
  - 信頼度が低くても推論結果があっていることもあれば、信頼度が99%でも推論結果が間違っていることがあります。
2. 「説明可能なAI」自体がおかしな可視化結果を出す
  - DNNは基本的にブラックボックスですが、CAMやattentionなどの構造を取ると、推論の判断理由(どのような特徴を以て、答えを導いたか)を可視化することができます。
  - しかし、これも完全に使えるわけではなく、人間の直感に反するような結果がでることもあります。
  - そうすると、エンドユーザにそのような結果になった理由を聞かれた時に困ってしまいます。