はじめに
※この記事はあくまでAI素人の個人的な意見で構成されています。
AIのエの字も知らなかった私が転職してAIプロダクトを1年間運用することになりました。
ソシャゲ業界から来た私は、汎用化こそ正義だ！を掲げて来ましたが、その結果紆余曲折ありました。
いい機会なので、その事を振り返ってみようと思います。
背景
社内では基本的に案件毎にスクラッチでAIを作成しているのですが、私が転職して引き継いだのは、社内で初めて汎用化を目指したプロダクトでした。
BtoBのプロダクトで、私がジョインする数ヶ月前からすでに運用を開始していました。
そのころは、ちょうど顧客の拡大をしている時期だったと思います。
AI の部分は AIを専門とするエンジニアが作ったものを使用するため、私はそれをプロダクトとして安定的かつ汎用的に運用することを目的としていました。
当時、ソーシャルゲーム業界から来た私はその意志を受け継いで、できる限りの機能を汎用化するぞ！と考えていました。
技術概要
今回携わったのは、売上を予測する 需要予測のサービスです。
サービスとして提供しているため、大きく分けると、操作を行う 「web画面」、その処理を行う 「APIサーバー」、そして学習処理を行う「バッチサーバー」 という構成でできています。
この構成図はすごくざっくりですがｗ
基本的には顧客が指定場所に連携してくれるデータを、バッチで週に一回取り込んで学習モデルを作成する。
そのモデルを使用して、APIサーバーでリアルタイム推論を行うイメージです。
もちろん、画面は統一されていて、できる事も全顧客共通です。
データに関しては、新しい顧客の導入時こそ統一フォーマットへの置換クエリを作る手間はありますが、一度置換クエリを作成してしまえば、以後毎週自動的に置換され、データが取り込まれまれ、学習モデルが作成されます。
そのため、顧客ごとに可変な部分は、「置換クエリ」 と AIに食わせる 「特徴量」 の選択だけになります。
はい！完璧です。
この時、私にとっては何の違和感もない完璧なプロダクトでした。
しかし
運用は当初から課題が山積みでした。
まず、顧客ごとの要望が絶えませんでした。
当時は営業の人が「この顧客の特殊仕様の要望に答えたい！」と言ってきたら、汎用的な範囲で対応可能なもの以外は拒否するというやり取りが続いていました。
「汎用化こそ正義！」であり、それを崩すような「特殊仕様は悪！！」です。
あくまでサービスの安定的な運用を崩さない範囲のみの対応を心がけていました。
しかし、結果的にそれらの要望を全て無下にできず、ズルズルと顧客対応を取り入れていくことになりました。
だって、お客様は神様だもの。
当時はエンジニア内で「営業のせいだ！」なんて陰口も言っていたものです。。。
結果
さて、最終的には、いたるところが if文 だらけになるという最悪な結果を迎えてしまいました。。。
運用コストは日に日に上がり、整備も難しくなっていきました。
顧客の要望にもだんだん応えられなくなり、結果的に顧客の業務にフィットしきれないサービスとなっていきました。
振り返り
今になって振り返ってみると 「汎用化おばけ」 に取り憑かれていたのかもしれません。
AI のサービスは通常のサービスとは違い AI特有の課題があることを理解するべきでした。
AI を運用するにあたって
AIの書籍や記事などを見てみると、よく 「解決したい課題があり、そこに対していかに AI で解決に取り組むのかを考える」 とあります。
みなさんもツールなどを導入する際に、自分が持っている課題に対してどんなツールで課題を解決するかを考えると思いますが、AIの場合は考慮すべき点が少し違っていました。
課題に対して、本当にAIでアプローチするべきなのか、そもそも可能なのか
「販売数の需要を予測する」と聞いたときに INPUT を渡せば決まったOUTPUT(予測結果)が出てくるサービスだと思いますよね。
ただ、実際は予測結果の精度にはブレがあり、INPUT となるデータの傾向毎にチューニングが必要になります。
そもそも、導入前に本当にAIの精度を出せるほどのデータが揃っているのかが重要になります。
AI は育てないといけない
これが一番考慮しないといけないことだったかなと思います。
普通のツールと一番違うところは AI は常に育てないといけないというところだと思います。
育て方によって精度も変わってしまいますので、常に精度の確認とチューニングが必要になります。
いかにして継続して AI を育てていくのか、この課題は顧客ごとに違っていて、汎用的な使い方が最も難しい部分だと思います。
業務にフィットさせることが可能かどうか
上記で上げたとおり、育てるために、定期的な再学習やメンテナンスが必要になります。
そのため、AI をうまく使うことができれば効率化が図れる一方、顧客自身にメンテナンス工数がかかってしまいます。
業務フローの中にそういった作業を取り入れることが可能かどうかも大きな問題点となってきます。
また、今回のように販売数の需要予測の場合、顧客ごとに「売り方」というものが違っていて、それぞれの売り方にフィットしたものじゃないと使い物にならないということが多々有りました。
自分の中の結論
当時はこれらの知識がなく、普通のツールを提供しているのと同じ考えでいたため、「提供しているサービスとフィットしていない顧客にサービスを売ってしまっているんじゃないか？」 や 「単純になにか足りない機能を見落としてるのではないか？」 などを常に考えていました。
しかし、AI は少し特殊なんだと理解した結果、問題点はもっと別のところにあり、運用コストが多少上がることになったとしても、あえて汎用性を捨てて顧客ごとに向き合いながら対応しなければいけないという考えに至りました。
じゃあ、どうするべきだったのか？
おそらく、 AI に関わる部分「学習アルゴリズム」や「推論」や、それに伴う「特徴量作成部分」は顧客ごとに作成し、それ以外の部分は機械的な処理として汎用的な機能を作ればいいのではないかな。と思います。
AIに関わる部分
上記で上げたように、AIに関わる部分は顧客ごとに作成するほうが良さそうだと思います。
- DB からデータを取得し、特徴量を作成する部分。
- 特徴量から学習を行う部分。
- 推論を行う部分。
これにより、アルゴリズムを変えたい場合や、単純な販売数予測ではない顧客毎に別の予測を行いたい場合などでも対応可能になります。
データの取り込みの自動化。
それ以外の部分として、顧客が連携してくれるデータを機械的にチェックし、DBへデータを取り込むところは自動化しておきたいところです。
この部分は 取り込み元、取り込み先、置換クエリさえ指定するように作ってしまえば、クライアントごとの差は殆どありません。
UI に関して
サービスとして提供する場合、UIは必要になってくると思いますが、ここに関しては、顧客ごとにするか汎用的にするかはケースバイケースかなと思います。
割り切って BI ツール的にデータを見せることだけに徹し、汎用的にするのも有りだと思います。
ただし、AIを育てるための精度評価のフィードバック方法などは考慮しておかないといけません。
まとめ
当然の話なのですが、 AI を運用する場合は、ちゃんとAIの特性を知っておかないとだめだなと反省しました。
AI のコア部分を専属の人が作るしても、プロダクト化する時に、普通のツールのようにはいかないことを十分理解したうえで設計しないといけません。
今回挙げた以外にも、どうやって顧客にAIの精度に対して採点(再学習のための教師データ)をしてもらえるようにするか、といったこともAIをプロダクト化する際の課題にになります。
今もまだまだ課題ばかりですが、そういったところがやっぱりAIだなって実感できる部分でもあり、やりがいのある部分なのかもしれません。
今後も伸び続ける業界だと思うのでこれからも試行錯誤していきたいなと思います。
さいごに
アドベントカレンダーのために無理やり記事にしましたが、まとまりが悪くてすみません。
当初は AIのコアの部分以外は 普通のWebサービスとかと同じでしょって考えてましたが、
結局AIはAI特有の大変さがあるんだなってことを、実感してはじめてわかったよって話です。笑
言葉にすると簡単なことに様に感じるのですが、これが意外に気づきにくい部分だったので記事にしてみました。