IT業務効率化

社内向け機械学習サービス運用の失敗談と学び

トライアルと本番運用の区別を意識する

機械学習系の施策やサービスを社内に展開する場合、企業体質によりますが、多くの場合はまず効果を実証しなくては行けないと思います。そのため試験的にシステムを利用してもらうことがあると思います。

重要なことはトライアルで作ったシステムはあくまでトライアルだと自身が意識し、利用者や社内にもそれを意識させることです。

トライアルで作った機械学習サービスが仮に本運用に乗ってしまった時に以下のようなこと問題が顕著にダメージとなります。

  • 学習モデルを複数管理するつもりがなかったので、複数の学習モデルが乱立する(モデルの管理)
  • 精度向上の仕組みを意識していない(精度問題)
  • データリソースをシステム専用に組んでいない場合、データリソースの仕様に変更があると壊れてしまう(学習データの管理)
  • ドキュメントがなく保守・運用が困難(保守・運用)
  • インフラの管理が行き届かずマシンリソースを確保できず不安定(インフラ)

このような問題を避けるために試験的に作成したシステムは

  1. 他のシステムがそのシステムを活用しないようにする
  2. 利用者にはトライアルであることを伝えて横展開しないように伝える
  3. 消していいシステムであり続ける

モデルのチューニングが常に必要であることを訴求する

データサイエンティストの活用戦略にもあるように

例えば、需要予測モデルを構築したとしても、市場は時間とともに変化するため、モデルの予測精度は落ちて陳腐化する。モデルの精度を監視しメンテナンスする人材がいなければ、事業においての活用に不安が残る。

とあります。

実際に私自身も経験したことですが、モデルはチューニングを常に繰り返さないと劣化していきます。そもそもチューニングされた学習モデルは時系列的にも環境的にも変わっていく世の中の1点に合わせています。変わっていく環境に対して悪くなることがあってもよくなることはそうそうありません。

専門の部署があったとしても1つのシステムを放っておいては必ず劣化していきます。そのために人的リソースが必要となることを会社及び上長に周知することが必要です。

分析用のデータソースを1つにまとめる

分析を始めるころだと、無償のOSであるMySQL、MariaDB、Postgresから手をつけたり、BigQuery、TreasureDataなどSaaSを利用するかもしれません。

しかしこれらのデータソースは1つにま止めた方が良いです。また、可能であればテーブルレベルで管理できることが理想です。

理由は言うまでもないかと思いますが、データが煩雑になり管理できないこと、連携タイミングが異なりデータ同士のタイムラグが生じる、などです。

私は個人的にはMariaDBを推します。1年半データを見てわかったことは分析DBは細かなupdateやinsertは不要でした。そのため列指向データベースの方がクエリもデータの投入も速くて使いやすいです。さらにMariaDBはオープンソースです。

予測値に対する補正は簡潔に行う

トライアル期間だからこそよくあったことですが、小さな補正を入れてしまうことがあります。

たとえば某商品だけ予測がずれているから、アウトプットを0.8倍して欲しいなどです。

これだけならば専用の関数を設けて、チューニングデータテーブルを用意して実現できるかもしれません。

しかし、より多くのチューニングが増えていきました。

  • 専用の予測ロジックを別立てする
  • その新しい専用の予測ロジックを特定の商品にだけアンサンブルさせる

ドキュメントもないのにこんなことをしてしまうと、他の人が開発した時に意味がわからなくってしまいます。補正を行うなら専用の関数を設けて、あまり複雑な補正を行うよりは予測のモデルを根本から見直すなど、小手先の調整は最終手段にしましょう。

ABOUT ME
hirayuki
今年で社会人3年目になります。 日々体当たりで仕事を覚えています。 テーマはIT・教育です。 少しでも技術に親しんでもらえるよう、noteで4コマ漫画も書いています。 https://note.mu/hirayuki