AIを業務でどう使うか？～AIを使おうとしたら困った～
どうも、Koheiです。
土曜日にジャンプが出てしまうと、翌週が辛くなりますね。
土曜日にジャンプが出てしまうと、翌週が辛くなりますね。
今日は依然話したAIのトピックに基づいて
自分の体験談を交えて、実際に業務でAIをどう使うか？を話したいと思います。
AIってなに？どうやって作ってるの？
という方は前回の記事を参照ください。
AI導入しましょう！やりましょう！…ところが
やっぱ、どこでもAIを使いましょう！という勢いがあります。
実際に自分もAI使って効率化したい！みたいな相談をたくさん受けます。
さて、ここであるサービス運用担当Aとの会話を再現してみます。
担当A「AI使ってサーバ故障の自動検知したいっす！」
Kohei「ok検討しましょう。材料となるデータってありますか？」
担当A「サーバのログとかセンサデータならたくさんありまっす！過去2年分くらい貯まってます。」
Kohei「（ログかあ…きれいに加工できるかわからんけど、データはたくさんありそうだな）
いいですね。じゃあそれを基に故障パターンを識別する統計モデル作ってみましょうか。
ちなみに統計モデルを作るうえで、検知したい故障パターンデータが必要なんですが、どれくらいあります？」
担当A「故障パターンありますよー。昨年は5件故障あったので」
Kohei「ホェｯ!? 5件!? 1年で？ 少なッ!?」
実業務において、正解データは少ない
ちゃんと安定的にサービスを提供しているサーバであれば当然故障も少ないです。
故障パターンを識別するAIを作ろうにも、肝心の故障パターンが数件しかありません。
おまけに、数少ない数件の故障パターンは、それぞれまったく別々の要因で故障を起こしていたりします。
故障パターンを識別するAIを作ろうにも、肝心の故障パターンが数件しかありません。
おまけに、数少ない数件の故障パターンは、それぞれまったく別々の要因で故障を起こしていたりします。
以前、「リンゴなら知ってる君」の作り方の記事でも紹介しましたが
より精度の高い識別を行うためには、正確な統計モデルを作る必要があり
たくさんの学習データが必要になります。
たくさんの学習データが必要になります。
このような数少ない、かつバラバラの故障パターンの正解ラベルだけでは正確な統計モデルは作れないのです。
この場合は、
そもそも年間5件しか故障していないサーバでAIモデルいるのか？
という話もありますし、
故障要因を解析して何を正解ラベルとすべきか？をもう少し掘り下げてみる
（例：実はサーバAのJVMヒープ値が急増すると故障に繋がっている、など）
（例：実はサーバAのJVMヒープ値が急増すると故障に繋がっている、など）
と、さらに別の要因が見えてくるようになり、
学習データを増やすきっかけに繋がることもあります。
学習データを増やすきっかけに繋がることもあります。
担当A「それでもAIを使いたいんだ！A! I ! A! I !」
もはや手段と目的が逆転している気がしますが、
やはりAIを使っていくということを主目的にするケースもあります。
AIを意識すると、
この業務はこのデータで自動判別できないかな？
とか、新しい視点が生まれるので、そういう意味ではとりあえず使ってみる
というのも一つの選択肢だとは思います。
この業務はこのデータで自動判別できないかな？
とか、新しい視点が生まれるので、そういう意味ではとりあえず使ってみる
というのも一つの選択肢だとは思います。
たくさん学習データになりそうなデータはある。
しかし、正解ラベルはない
しかし、正解ラベルはない
だけどAIは使いたいんだ！
そんな無茶振りを受けたあなた
方法はなくはないです。
そんな無茶振りを受けたあなた
方法はなくはないです。
教師無し学習というアプローチ
「リンゴなら知ってる君」の記事で紹介した際には、画像一つ一つに
これはリンゴ、これはnotリンゴというラベル付けをしました。
つまり、学習データに正解ラベルを付けてあげています。
これは教師有り学習と言われます。そのまんまですね。
一方、教師無し学習というアプローチもあります。
つまり、リンゴ、notリンゴのラベルを付けないパターンです。
「え、それじゃあ機械にどうやってリンゴだって理解させるんですが？」
という質問が出ると思います。ちょっと考え方を変えます。
コンピュータはリンゴを知りませんが、学習データをたくさん持っているので
似ている画像とそうでない画像は自分で判断することができます。
この画像とこの画像は統計学的に近い値を持つ
→似ている画像
この画像とこの画像は統計学的には離れた値を持つ
→似ていない画像
こうすることで、どれが何の画像かはわかりませんが
似ている/似ていないをコンピュータが判断することができます。
これも学習、特徴抽出、統計モデル構築のプロセスを踏んでおり
一種のAI(機械学習)となります。これを教師無し学習と呼んでいます。
教師無し学習のアプローチを使えば、たくさんのデータさえあれば、
よくあるパターンや通常とは違うパターンなどを自動的に抽出することができます。
よくあるパターンや通常とは違うパターンなどを自動的に抽出することができます。
教師無し学習の危うさ
正解データいらないし、教師無し学習最強じゃん！
と思ったあなた
大きな落とし穴があります。
教師無し学習でできることは、正解ラベルのないグループ化までです。
グループ化というのも、統計的に似ているものをピックアップするだけなので
と思ったあなた
大きな落とし穴があります。
教師無し学習でできることは、正解ラベルのないグループ化までです。
グループ化というのも、統計的に似ているものをピックアップするだけなので
リンゴ判別であれば、リンゴの画像がいい感じにグループ化される
サーバ故障であれば、サーバ故障のパターンだけいい感じにグループ化される
という保証はなく、本当に欲しいパターンが現れるとは限りません。
あくまで統計的に似ているかどうかでしか判断は行いません。
このためグループ化されたものの評価は人が行う必要があります。
ここがよく躓くところです。
このためグループ化されたものの評価は人が行う必要があります。
ここがよく躓くところです。
実際に先ほどのサーバ故障検知の例でも、故障パターンが少なかったので
教師無し学習のアプローチをとり、いつもと違うパターンをいくつか検出してみました。
しかし、統計的に算出されたいつもと違うパターンを調べても、故障との因果関係も見つからず、評価できないよくわからない結果になってしまいました。
AIを業務で活かすためには
AIをつかって何かしたい！というときには、必ず
「これをAIで判断させたい」というターゲットがあるはずです。
ただ、実際にはターゲットとなるデータが少ないことが多く、
「これをAIで判断させたい」というターゲットがあるはずです。
ただ、実際にはターゲットとなるデータが少ないことが多く、
教師無し学習のアプローチをとらざるを得ないケースが多々あります。
教師無し学習はデータの大枠を捉えるにはよい方法ですが、
誰がどうやってその結果を評価するか？を明確にすることが必須です。
そして、判別結果の評価は、教師データをつくることにもつながり、
より高精度なAIの生成に繋がります。
そして、判別結果の評価は、教師データをつくることにもつながり、
より高精度なAIの生成に繋がります。
AIをとりあえず業務で使ってみたい！という方には
ぜひ、この学習データはあるのか？判別結果は評価できるのか？
という観点をもって進めていくとうまくいくと思います。
