aptpod Tech Blog

株式会社アプトポッドのテクノロジーブログです

機械学習のシステム開発の難しさを独断でまとめてみた

aptpod Advent Calendar 2019 11日目 先日お菓子のデモの記事を投稿したキシダがまたお送りします。みなさま、ここ最近『機械学習』とか『AI』とか耳にすることが多くなってきていると思いますが、現実はどれくらいの導入率かご存知ですか?

なんと、14〜15% (※1)らしいです。
意外に導入まで成功しているプロジェクトはまだ増えてきていません。

そこで、『機械学習プロジェクトって具体的にどういうふうにすすめるの?』とか『普通のシステム開発と違って何が難しいの?』という疑問の声に勝手にお答えして、完全な独断と偏見ですが、一般的な機械学習案件に対してよくある困った事例のご紹介とそれに対して私個人が意識していることをこちらにまとめてみようかと思います。
技術的なところではなく、案件における考え方や進め方的なところを中心に掘り下げてます。

※この記事で出てくる事例は架空のものです。

※1 総務省・ICR・JCER「AI・IoTの取組みに関する調査 より引用

そもそも機械学習プロジェクトってどんなもの?

『AI的なやつが自動判定していろいろ運用が自動化するやつでしょ??』

うーん、はい、まあそんな感じです(雑)

wikipediaさんにも聞いて見ましょう。

機械学習(きかいがくしゅう、(英: Machine learning、略称: ML)は、明示的な指示を用いることなく、その代わりにパターンと推論に依存して、特定の課題を効率的に実行するためにコンピュータシステムが使用するアルゴリズムおよび統計モデルの科学研究である。

うーん、さすがwiki先生、頭がよすぎて凡人には全然わからないです。

私の理解では、機械学習はAI(人間並みの知能をコンピューターで実現するもの)のレベルではなく、あくまで「大量のデータを繰り返しコンピューターが計算し、パターンを見つけること」が機械学習という理解です。 このパターンの算出をアルゴリズムとして定義し、あるデータを入力値として、分類などの算出結果を出力するツールとなります。これを使用してお客様の課題を解決することが、いわゆる『機械学習プロジェクト』を指すと思っています。

もう少し掘り下げると、機械学習は以下の3種類があるそうです。

  1. 教師あり学習
  2. 教師なし学習
  3. 強化学習

私は『教師あり学習』の案件のみ経験があるので、本記事では『教師あり学習』にフォーカスした考察を記載します。  

ちなみに、機械学習自体の説明については以下のQiitaがとてもわかりやすかったので、機械学習をザクッと知りたい方はこちらをご参考にどうぞ。 qiita.com

そもそも機械学習案件ってどういう流れですすめるの?

機械学習のシステム開発は主に、以下の流れですすめることが多いです。

f:id:aptpod_tech-writer:20191207173045p:plain
機械学習のシステム開発の一般的なフロー

上記の流れをぱっとみると、データの前処理とモデルの開発を除けば普通のシステム開発と一緒だな、って感じがしますよね。ただ、機械学習案件では人間がすべて明確なアルゴリズムを仕様として決めているわけではないので、品質の不確実性が必ずつきまといます。それにより案件をすすめることがどれだけ大変になるか、それぞれにフォーカスしてみましょう。今回はすべて触れると長くなってしまうので、前半の3つをメインにフォーカスしてすすめたいと思います。

CASE 1:企画フェーズにありがちなこと

企画フェーズでは、実際にお客さん側に何かしら課題があって、AIを使ってこの課題を解決しよう!という流れが発端で企画されることがよくあります。その際は、以下のことを考えてすすめるケースがよくありますね。

  • AIを導入することでビジネス的にどんなインパクトがあるか
  • AIが何%くらいの正答率だったらビジネス的にうまくいくか

上記をみるだけだと、なんとなくすすめられそうです。

しかし、

お客様の上司『予算余ったし、ためしに今有り余ってるデータをAI使っていろいろ利用できるんじゃない?』

この上司の一言をそのままにしてすすめてしまうと、悪夢を呼び寄せてしまいます。

AI屋さん『データをつかって試しに簡単なモデルを作ったら、85%くらいの精度がでました!』

お客様『お、いいね!! だったら90%くらいの精度を目指して、モデル作ってみてよ!(これで上司になにか報告できそうだ!)』

AI屋さん『はい!!』

その後、AIベンダーは特定のデータに対して、ひたすら精度の高い90%のモデルを作り出し、早速そのモデルを使って運用することになりました。

お客様『あれ、90%の精度でも、実際に運用に乗せると意外に間違いが目立つよ?』

お客様『こんなに間違いが出ると修正が大変だよ。』

お客様『これ人間が手動でやってたほうが楽だったんじゃ。。。』

お客様『このモデル全然つかえないじゃん。。。どうゆうことだよ。。。』

AI屋さん『・・・・・(え、90%でいいって合意をとったはずなのに・・・。)』

お互い不幸になってしまいました。こういう例も少なからずあり、『なんとなく精度のいいモデルをつくってみてよ、データはあるからさ』から始まるプロジェクトでも、そのままなんとくですすめると『あれ、我々ってなにやりたいんだっけ』、『本当にモデルっているんだっけ』、となるわけです。

どうすればよいのでしょうか・・・。

考察:お客様のビジネスインパクトを評価できるKPIは事前に整合しておく

機械学習案件において、ここを握らなければお客さんとベンダー側のコミュケーションが成り立たないことがほとんどです。そもそもお客様の現状の運用における問題から、そこが改善できたと言えるKPIを予め共通認識としてもっておかなければ、AIつかってみたけどそこまで効果ないね、と残念なシステムができてしまいます。

私の場合は、以下の項目を明確化し、KPIを決めていくように心がけています。

  1. お客様の問題点を明確化する (Why)
  2. どの指標を改善すれば問題点が収束するかを明確化する (What)
  3. その指標の改善方法に、機械学習を使用する以外に方法はないか検討する (How)

指標がきまってもその時点で終わりではなく、お客様を含めたプロジェクトの参画者はプロジェクトの間は延々を意識し、そのKPIにこだわり続ける責務があります。  

また重要なのは、『整合したから大丈夫だよね!』ではなく、お客様周りの環境も必ず変わることを意識することです。そのためには、お互いの間で指標は常に可視化し、本当にその指標で正しいか定期的に議論することがベストです。指標がコロコロ変わることに戸惑うこともありますが、『変わること』より『変わることが可視化できていないこと』が問題だったりするので、開発側としてはアジャイル的な思想で柔軟に対応することも必要かもしれないですね。

CASE 2:データの前処理・精査にありがちなこと

ここでは、学習を行うために必要な『教師データ』の作成を行うため、お客様が持っているデータについて精査していきます。
精査した後は、実際にお客様のデータに対してタグ付けを行い(これをアノテーションといいます)、教師データを作成していくフェーズとなります。 このフェーズでは主に以下のようなことを考えます。

  • 学習できる量に相当するデータが揃っているか
  • データが構造化されているかどうか
  • セキュリティ的に問題があるかどうか
  • データの加工にコストがどれだけかかるか
  • アノテーションコストがどれだけかかるか

やはり、壁だらけですね。 上記の詳細は割愛しますが、仮に上記をクリアしても以下のような落とし穴があるのです。

あるプロジェクトで、提供している商品に対するお客様からいただいたコメントに対して、分類を自動化するツールを開発している会社さんがありました。 お客さんから受け取ったメッセージを『もう一度使いたい!最高!などのプラス評価のメッセージ』、『クレーム、いらつきなどのマイナス評価のメッセージ』、『どちらでもない無評価メッセージ』に分けようと試みています。メッセージの分類をタグ付けとして実際に行うのは、実際にメッセージに対して対応するオペレーターです。

リーダー『データも構造化してデータ収集も自動的にできて、かつオペレーターが正解データを付与してくれる仕組みをつくったぞ!!』

リーダー『よし、ある程度の教師データも揃ったし、モデル作って精度試してみよう!』

しかし、モデルを作った結果、ある出来事が起きます。

リーダー『あれ、、、これはクレームと判定してほしいのに、プラス評価で判定されてしまっている!』

リーダー『あれ、教師データを見てみると、明らかにクレームなのにどちらでもない無評価になってるし、カテゴリ分けが正しくできてないじゃないか!どういうことだ!』

実際にアノテーションしたオペレーターに聞いてみると

オペレーター A『僕はこれは褒めコメントだと思ってました』

オペレーター B『私はむしろ何がいいたいかよく分からなかったんでとりあえず無評価にしちゃいました』

リーダー『全然カテゴリ分けの判断基準が統一されていないじゃないか・・・!これじゃあモデルもちゃらんぽらんな判定になっちゃうよ。。。』

このケースは、データを分類する判断基準が曖昧で、正解データのタグ付けの基準がずれてしまい正しい教師データが作れないケースです。どんなにデータ収集の仕組みをシステム的に整えても、こちらを明確にしないと質の悪い教師データが作られてしまいます。

どうすればよいのでしょうか・・・。

考察:データの正解の条件を具体化し、事前に合意をとる

このフェーズでは、お客様との期待値調整の一貫として、AIがどのレベルまでのデータを検知すればよいか明確にする必要があります。 そのためには、以下のようなことを意識すると良いかもしれません。

  • 現状の運用方法を深く分析し、データのパターン化を行う
    • パターンを決めるときは、できる限りその境界線を明確にする
    • この境界線は一般的な事実を基準として考えるのではなく、プロジェクトのKPIからどう定義すべきか検討する
  • データのパターンに対して、AIが担保するべきレベルを決める
    • この際、企画フェーズで決めたKPIを元に、AIが提供すべきビジネスインパクトに基づき判断する
  • AIが検出するべき 正解データ のパターンを、関係者全員が理解できるようにする

ただこれは実際難易度が高く、データに詳しいクライアントがいないと実施が厳しいことが多いです。クライアント側でデータを一番良く見ている人、関わっている人は必ずプロジェクトに巻き込み、上記の議論を挟むようにすると良いかもしれません。

CASE 3:モデル開発・評価でありがちなこと

実際に企画内容も決まり、使用する教師データの作成も終了したら、いよいよモデルの作成です。 実際にモデルをトレーニングし、実際にできたモデルにたいして結果の正答率などを見てみます。 ここでよく陥りがちな事例とはなんでしょうか。

プロジェクトリーダー『絶対精度を90%にしたいぞ!』

AI屋さん『作成したモデルを評価したところ、今回用意したテストデータでは90%の正答率をクリアしました!』

プロジェクトリーダー『さすがじゃ!!これで大成功ですな!システム化しよう!』

実際システム化して新たなデータで検証したところ

プロジェクトリーダー『あれ、全然90%の精度になってないじゃないか!どういうことだ!』

AI屋さん『90%の結果はあくまで評価時に使用したデータの話であって、新たに投入したデータが90%を常に超えるとは限らないです』

プロジェクトリーダー『そんな...!それじゃあ本番では全然つかえないじゃないか!』

AI屋さん『・・・(うーん、データも生き物だから、常に評価時と同じような精度がでるとは限らないんだけどな)』

モデルを作って評価したときはすごいうまく行っているようにみえたけど、本番で動かしてみると全然精度が出ないお話、これもよくあります。

モデルの評価時では、評価向けのデータセットを作る際に精度がでるようにデータセットをコントロールしたりすることは可能で、それ自体も1サンプルのデータなので参考値としては有効な数字です。そのため、1サンプルのデータがうまくいったからすべてのデータがうまくいく!ということはありません。モデルは必ず目標精度を担保できるものではなく、それを前提としてプロジェクトをすすめる必要があります。さて、困りました。

どうすればよいのでしょうか・・・。

考察1:モデルの精度検証は事前に整合したKPIで評価する

モデルの評価では、基本お客様と事前に合意をとったKPIで評価し、お客様のビジネスインパクトがどの程度改善されるか計測した後、お客様に提示する必要があります。 最初にモデルの一般的な評価数値である 正答率 などをあげても、最終的にビジネスインパクトを満たす数値かどうか判定できないと意味がありません。

考察2:「がんばれば精度あがるでしょ!」から「精度が上がらないときどうしましょ」にシフトする

私自身、機械学習案件においては「予測誤りをなくすことはほぼ不可能」ということをプロジェクトメンバー全員が共通認識としてもっておく必要があるなと毎度強く感じます。

なぜかというと

  • 精度はデータセットによって変化するため、特定のデータセットの評価値はあくまで参考値にしかならず、その評価結果をモデルが常に担保する数値ではないこと
  • 追加学習を行えば、精度は必ずあがることはないということ

「いずれがんばりつづければ精度はあがるだろう」という空気感は、機械学習案件を泥沼化する考え方、と参考にしてた本やあらゆる有識者の話題にあがっていました。もしお客様にこの空気感があれば払拭しておく必要があり、以下のような精度が上がらなかったときの対応を事前に考え、共通認識として持っておく必要があります。  

【精度が上がらない時の対応例】

  • ある程度人手を使いミスを補填する
  • システムで事前に不正データを削減する
  • プロジェクトを撤退する

3点目については、『え、諦めちゃうの・・・?』という方も多いと思いますが、KPIに対して撤退ラインは必ず設けておく必要があるそうです。機械学習案件は基本ギャンブルという人もいるほど、確実性を担保することが難しい案件でもあります。

まとめ

いかがでしたでしょうか。今回は時間の都合上一部のフェーズしかご紹介できませんでしたが、上記以外にも機械学習案件にて難しい点は存在します。通常のシステムとは違い、テストにおける不確実性がどうしてもついてくるので、そのあたりをクライアントとどう握るかが鍵のようです。この点に関しては、弊社でも機械学習案件に関して議論をすすめ、模索しながらすすめているところです。もしこのような取り組みに興味がある方がいらっしゃいましたら、ぜひ以下の採用ページにアクセスをお願いします!

採用情報:https://www.aptpod.co.jp/recruit/

一部以下の書籍・資料参考:  
- 5Dヒアリングシート(https://note.com/yukimimu/n/n90b997c6deef)  
- 仕事で始める機械学習 -  O'Reilly Japan (https://www.oreilly.co.jp/books/9784873118215/)