データサイエンティストと営業担当者の溝をどう埋める?
機械学習を用いた“予測的”アプリケーションの作り方

機械学習、アナリティクス・クラウド、「予測的」アプリケーションの実現 #1/3

Oracle Code Tokyo 2017
に開催

世界中の技術者を対象に、最新技術動向やユースケース、トレンドに関するノウハウや技術情報が入手できる開発者のためのイベント「Oracle Code」。2017年5月18日に東京で開催された「Oracle Code Tokyo 2017」では国内エンジニアに向けた最新知識を共有する各種セミナーが行われました。セッション「機械学習、アナリティクス・クラウド、『予測的』アプリケーションの実現」では、機械学習を用いたデータ・サイエンス・プロジェクトを、単なるツールから予測的アプリケーションまでにステップアップする方法について、多くのコーディング・サンプルとユースケースを使って紹介しました。

提供:日本オラクル株式会社

機械学習とゲノム

山中遼太氏(以下、山中):それでは始めさせていただきます。はじめまして。日本オラクルの山中と申します。

このセッションは、もともとUS Oracleから1人来て、機械学習の話をするはずだったんですけれども、急遽来られなくなってしまいまして、申し訳ないんですけれども、私のお話でご勘弁いただければと思います。

自己紹介する時間があまりないと思うので、自己紹介ではないんですが、最近私がやっている取り組みを紹介させていただきたいと思います。

(スライドを指して)これは、クラウド上のデータを分析して市民科学者になろうという、ちょっとしたセミナーをやっています。ここに私のTwitterアカウントが書いてありますので、もしもご興味ある方がいらっしゃいましたら、ぜひ。

これは先々週にやったんですけれども、去年の10月ぐらいに日本オラクルのカフェができまして、そこで開催させていただいています。夜6時ぐらいからやっています。

この日は微生物のゲノムを収集して分析してみようというものでした。ゲノムというのは、人間だけではなくて、細菌などの微生物もそうですし、ニンジンなどの植物もみんなゲノム、DNAを持っているので、机の上からでもいろいろな生物が出てきたりするんですね。

それをこうやって採取するんですよという話をして、実際ネクタイを締めたサラリーマンが椅子の上から微生物を採取するというイベントをしました。

これをカフェでやりまして、50人ぐらいの方にたくさんの微生物を採取していただいて、ご自分のボトルに名前を書いて、どこから採取したかをパソコンで打ち込んでいただくということをやりました。ぜんぜん関係ないんですけど、もしよろしければチェックしていただければと思います。

6月21日にまた世界で一斉にサンプリングしようと思っています。本当はこういう会場で、みなさんいろんなところから集まってきたところでサンプリングするとすごくおもしろいと思うんですけれども、これに参加したいなと私たちも思っているので、もしよろしければアクセスいただいて。

また、このデータがすごくおもしろいんですね。みなさんにオープンにして、みんなで分析できたらおもしろいかなと思っています。

もう1つ、(スライドの)右側に書いてあるのが「オープンデータを分析する ~ミクロの世界編」というものです。これも友人がやっているんですけど。

これはクマムシなんですけど、顕微鏡でクマムシの写真を撮って、このクマムシの写真をそのまま横にある3Dプリンターで手で触れるくらいの大きさで出力しようという試みをしています。

なぜ私がこの話をしているかというと、これは機械学習がないとなかなか画像が……顕微鏡の画像は粗いので、そこをきれいにするために機械学習しないと、3Dプリンターで出してもおもしろいものは出てこいないんですね。なので、そういうところで一緒にやりたいなと思っています。

「機械学習とはなんだろう?」というところから、どなたにでもわかるように説明する市民講座ですので、ぜひみなさま、お友達・ご家族お誘いあわせの上、来ていただければと思います。

予測アプリケーションをどう作っていくか

あまり関係ない話ばかりしてると怒られてしまいますので、本題に入りたいと思います。

セッションの内容ですが、今日は午前中から機械学習のセッションがいくつかありました。キーノートのシバタさんはじめ、みなさまのご講演ございましたので、「いまさら機械学習とはなんぞや」という話は必要ないかなと思うんですけども、もう一度だけ手順を確認します。

予測モデルを作ったときに、システムのなかでどう活用していくかを、今回のこのセッションの主題にしたいと思っています。タイトルにもあったように、予測アプリケーションみたいなものをどう作っていくか。

さらに、これは私の取組みでもあるんですが、ビッグデータ。Hadoopにのるような大きなデータになった場合に、どういうアーキテクチャが考えられるかを見ていきたいと思います。

まず、基礎的な話になってしまって恐縮ですが、機械学習をもう一度おさらいしたいと思います。

今回は、保険を契約してくれるかどうかを営業マンが予測したいという話です。お客さんの情報があって、そのお客さんの年齢、性別、住所、家族構成、年収などの情報から、この人が今後うちの会社の保険に入ってくれる可能性を求めたい。

こういったとき、機械学習は、基本的に過去のデータが必要です。過去のデータを勉強して、このお客さんは契約するかどうかがわかる。

何度も何度も足繁くいろいろなお客さんのところに行ってきたキャリアのある営業マンであれば、すでにこの分類モデルを頭のなかに持っているわけです。ですので、ちょっとお客さんの顔を見ると「なんかこの人買ってくれそうだな」とわかる。

こういった知識を蓄積してモデルを作るということをコンピュータにやらせたいというのが機械学習のアルゴリズムになります。Support Vector Machineや決定木といったもの。ほかのセッションでもちょこちょこ出てきたかなと思います。

これを学習させるためには、過去データに、この保険を契約してくれたかどうか。つまり、今まで保険を契約してくれた人たちはどういう属性を持っていたのか、という過去の知識がなければいけません。このフラグがついていれば、これを学習データとして使うことができて、なんらかのアルゴリズムによって分類モデルを作ることができる。

このモデルができれば、新しいお客さんや今までのお客さんに対してそれを適用して「予測結果の何パーセントの確率で買ってくれるのではないでしょうか」と言えることになります。

この分類モデルというのは何者か。もう少しよく見てみます。

(スライドを指して)これが作成されるモデルのイメージなんですが、今まで私は5人のお客さんに会ったことがあって、2人「Yes」とここに書いてありますが、2人の人が買ってくれた場合ですね。

その場合は、例えばこの2人を見てみると、「両方女性だな」とか、「42歳の人も22歳の人も、教員の人も弁護士の人もいるけど、預金残高はそれなりに50万円以上あるのかな」とか、そんなふうに見るわけですね。なんらかのアルゴリズムを頭の中に作っていく。

「それなりに銀行預金の残高があって、それで女性の人が買ってくれるんじゃないか」と思うわけです。

この顧客データって、今の例では5人だったからすぐに作れたわけですが、これが500万行とかになってくると、人間が作るのは難しい。なので機械学習にやらせよう、コンピュータのアルゴリズムにやらせようというのが、この1つ目の矢印になります。

ここまではよくやることで、機械学習の研究においてはこの精度をどれだけ高くするかという話がされるわけですけれども。今後、この機械学習をビジネスに使っていくということになると、この次のステップが非常に重要です。

なにかというと、このモデルを使って、営業マンが次にどこか行くときに、「女性で55万の銀行預金のある美容師さんはおそらく買ってくれる」と。私ではないほかの人、例えば新人さんが営業に行くにしても、このモデルを使えるということが今のAIアプリケーションの基本になっています。

ですので、このモデルの生成をする、そしてモデルの適用をするという2ステップがあるということが基本の基本になるのかなと思います。

さまざまなデータをとってくる

それがどんなワークフローか、もう少しツール使って見てみたいと思います。「この保険、契約しませんか?」と営業マンが使うツールですね。

では、これをどうやって作っていくかというところです。(スライドを指して)解像度がちょっと見にくいんですけれども、これはオラクルの提供している機械学習、データ分析のワークフローを作るためのソフトウェアです。機械学習だけではないんですが。

なにができるかと言いますと、ここにいろいろなアイコンがあって「データ」というのがあるんですけど、「データソース」というテーブルを取ってくることができます。

そして、ここにはお客さんの情報が入っています。「Insurance Customer」という表です。ここから保険のお客さんの情報を取ってきます。

中身を見てみると、これはテーブルの情報です。こんな感じですね。これを列で見てみると、例えば年齢とか、銀行預金がどれぐらいかとか、車を持っている・持っていない。

これは非常に重要な列で、「BUY_INSURANCE」というのは、今までこの保険を買ってくれたか買ってくれなかったか、というフラグになるところですね。契約をしてくれたかどうか。ここは学習するところなので、これはすごく重要です。

そういった列がいろいろ並んでいて。1行見てみますと、例えばこの人は、結婚していて、男性で、ロサンゼルスに住んでいて……みたいなことが書いてあります。

作成されたモデルを見てみる

これを学習してみますが、その前に、データがどんなものかということをもう少しグラフで見てみたいと思います。「データの参照」を持ってきて、つないで、「編集」。このツールのお話は製品の紹介みたいになってしまっておもしろくないので、ご興味ある方は私のTwitterかどこかから辿っていただければと思います。

これを「実行」。中身になにが入っているかということをデータベースのなかで計算してもらいました。データの表示と統計を見てみましょう。これは保険を今まで買ってくれた人と買ってくれなかった人で色分けしています。黄色が買ってくれた人で、赤が買ってくれなかった人。

年齢の分布を見ていて、8.4歳以下の人は買ってくれていない、と。まあそうですね。幼すぎるからなのかもしれません。あとは車を持っている人・持っていない人だと、持っている人のほうがやっぱり買ってくれるんだな、とか。

じゃあ家はどうかというと、0個のハウスの人、1個持っている人、2個持っている人、みんなそれなりに買ってくれている。そういうふうに見るわけなんですけれども。

人間だと一つひとつの軸で見ざるを得ませんが、機械学習ならこれを全部一度に見て、「どれが判断基準になるの?」ということを持ってくることができる。それがモデルですね。「分類」モデルというものがここにありますので、これを持ってきます。これを接続します。

Decision Treeだとか、Support Vector Machineだとか、いろいろなアルゴリズムで見てくださいね、と。「なにを予測したいんですか?」と。保険を買ったかどうかなので「BUY_INSURANCE」という列ですね。それだけ設定して、「実行」。

こういうワークフローのエディタがあって、機械学習のアルゴリズムがあったり、データ設計したり、どこの製品を使ってもみんな同じようなUIかなと思います。

これが実行されましたので中身を見てみましょう。先ほど言っていたモデルができたはずですので、見てみます。

これを見ていただくと、先ほどのスライド(「作成されるモデルのイメージ」のスライド)で描いていたものですね。この右上にモデルみたいなものができていることがわかります。

よく見てみると、611人の人がいて、そのうち444人は買ってくれていなくて、167人は買ってくれているので、ランダムに営業に行くとおそらく72パーセントは失敗してしまう。これが元のデータです。

ですが、これを1回「BANK _FUNDS」で分割してみましょう。銀行預金が225.5ドル以下の人たちがここにいるんですが、この人たちは1人も買ってくれていないということがわかります。

逆に、167人全員がこちら側(225.5ドル以上)に入っている。買ってくれている人はこちら側に入っているわけですね。なので、そもそも銀行預金が225.5ドル以下の人のところに行ってもなかなか買ってくれないんじゃないかと。

そんなこんなでいろいろ分岐していって、最後にここまで来るとどうなるかというと、196人がここのノードに入りますが、そのうち136人は買ってくれると。69.39パーセントの確率で買ってくれる人たちがこういう条件の人たちですね。

このなかには、例えば銀行預金がどれぐらいとか、家が何個とか、年齢が何歳から何歳といった情報が入ってくることになります。これは一番簡単な決定木みたいな手法ですけれども、ここまでできると「ああ、なんとなく機械学習できたな」という気がするわけです。

データサイエンティストと営業担当者の溝をどう埋める?

ですが、今日のトピックは機械学習どうするかではなくて、この予測モデル、先ほどのスライドで「f(x)」と書いてあった部分をどう活用するかを考えてみたいと思っています。

従来、データベースなどはシステムのなかにあるわけなんですけれども、アプリケーションでそのデータ見てみましょうとなると、先ほどグラフで見たような感じで、Business Intelligenceですね。いろいろな軸で見てみましょうという話になるわけです。

最近は分析担当の方が「データサイエンスだ」と言って「機械学習なんかも使えるんじゃないか」とおっしゃっている。当然、この方々は業務を知ってることも多いですし、当然この力を借りて、このBusiness Intelligenceをさらに強いものにしていきたいわけです。

そうすると、まずは「データをお渡ししましょう」ということになるわけですが、そうするとデータサイエンティストの方が分析報告書を作ってくれるわけですね。先ほどのツリーみたいなものを作ってくれて、「こういうロジックがあるんだ、おもしろいな」となるわけです。

ですが、「データがあったらもっと精度が上がるね」となってくると、もともとシステムに入っていたものをどんどん出していって、「じゃあサーバがもう1つ必要だね」という話になる。分析をするとバンバン出てくるんだけれども、実は営業の人たちはこのことを知らなかったりする。

これはよくあるパターンです。というのは、よくあると言っても、ここが成熟してきたのはまだ最近の話なので、今、現実にここに直面してると思われます。おそらく今年とか。

では、これをどうするかという話なんですけれども、おそらくこの大量のデータを外に出してしまうというのはよくないかなと思います。それでもう1つサーバを持つとか、そこにセキュリティは本当にあるのかとか、いろいろ考えてしまうわけです。

1つの方法としては、これはオラクルに限りませんが、分析自体をこのフローのなかにどうにかして入れたいということになります。分析担当者がシステムの中身を覗けるようにしたい。そのシステムに対してフィードバックできたら最高ですね。

なので、こんな感じです。分析担当者はシステムの上でモデルを作って、モデルをシステムに格納して、そのシステムの上で動くような予測アプリケーションが出てくる。「68パーセントの確率できっとこのお客さんは買ってくれるよ」というのを営業部隊がiPadなどで見られる。

そういうふうに予測結果をここにどんどんフィードバックできる。分析担当者が1人で暮らしていた島から、分析担当者をこっちに持ってきてあげるということです。

予測の精度を上げるには

渡すデータはこういう感じです。営業さんには「予測結果で68パーセント」。誰かの情報を入れたらそういうふうに出てくる。その人が契約してくれたら、営業さんには「ここにチェックを入れておいてくださいね」と。

チェックを入れれば、次の分析のときには反映されるわけですよね。なので、このフィードバックを得るのは非常に大事です。

さらに、その営業活動のなかで、お客さんが何歳だとか、新しい情報がどんどん出てくると思いますので、それもシステムに入れてあげる。

そうするとこちらからフィードバックが得られます。システムはどんどん新しいデータを蓄えて、予測アプリケーションの精度がどんどん上がっていく。このサイクルを回すのがおそらくこれからやっていかなければいけないことなのかなと思います。

精度を上げるといったときに大切なのは、1つはアルゴリズムを増やす。いろいろなアルゴリズムを検討する。それも大切です。もう1つは、そのアルゴリズムに食わせるちゃんとしたデータを集めてくるというところです。

今、保険の話になっていますが、例えば保険のお客さんでどれだけのデータがあるかと考えた時に、おそらくいろいろなことをお客さんから聞いてる場合が多いかもしれないけれども、属性情報はそれほどたくさん得られていないと思います。

それが例えばコンビニのお客さんだったら、コンビニに入ってきたお客さんの情報をどれだけ知っていますか、と。やはりそこをどれだけ集めてくるかということがこれから大事になってきます。

さらに大量のデータの場合。今、コンビニの話をしましたが、じゃあコンビニのお客さんからどういうデータを取ってくるかというと、その人たちの年齢などはわかるはずがないので、なんとなく「今この陳列棚を通った」「このお客さんはこの時間帯に入ってきた」「この時間帯に入ってくるのは何十代っぽい人が多い」「今このお客さんはレジでこれを買ったから、それと一緒によく売れているもののクーポンをレシートに印字しよう」とか、そういう話になってくるわけですよね。

そうすると、今までは分析に使っていた顧客データはそれこそExcelで1枚で入るような話でしたが、そうではないと。

売上データで「この人は今までどれを買っていたか」といった大きなデータが必要になってくる。ここはよくデータベースに入っている話ですね。トランザクショナルなデータと言われるところです。誰かがなにかを買うと、それごとに1行入ってくる。

おそらくはさらにここが増えてきます。「誰かがここを通った」「ECサイトでこの商品のページを見た」とか、工場であれば工場のセンサーから、電圧だとか気温だとか温度だとか、いろいろなデータが出てくる。それが1秒おきに出てきたり。

そういうデータが出てきますので、ここはさらにデータが大きくなっていますね。顧客の行動ログや商品への評価など、トランザクショナルなデータとして今まで管理されていなかったようなデータが今後出てきます。

もともと機械学習はここで適用しようという話ではなかったわけですね。先ほどdecision tree、あの分岐のツリーを描きました。あれは1950年代にもうすでにあるアルゴリズムですが、データベースがBIを進化させていく過程で使っていましたかと言われると、使っていなかったわけです。

データベースにデータを入れるのはコストがかかる

ではなぜ機械学習アルゴリズムが今必要になったかというと、ログデータが出てきたからです。

今までBIで見ればある程度わかってきたデータ、先ほどのデータもそうですね。男性・女性のどちらが多いかはある程度は見ればわかるわけですね。それを助けてくれる人工知能もおもしろいし、役に立つけれども、ただ絶対に人工知能や機械学習が必要になるのはここ(ログデータ)です。こうなってくるとデータベースに入れることさえしなくなってくる。

なぜかというと、データベースに入れるというのはけっこうコストがかかります。

例えばCSVデータみたいなものがバンバン出てくるような機器があったとすると、それを日本全国のコンビニ、もしくは工場のいろいろなセンサーから集めて、(データが)どんどん入ってきます。

それをデータベースのテーブルに入れようとすると、ご存知の方が多いかと思いますが、そこでパースをしなきゃいけないとか、1回正規化をしてバラバラの表に入れなきゃいけない、ということをやります。

一度そういうふうにやったあと、今度BIで見るためにはなにかしらインデックスをつけておいてあげたりしないと、いろいろな角度で見ましょうなんて言っても、そんなに簡単には動かないわけですね。

なので、パースしてデータを入れたあと、データベースの内部で「そこに索引をつけましょう」といった内部処理が起きる。つまり、データを入れるときにいろいろなコストがかかって、CPUが回るということになります。

これがビッグデータになってきてしまうと、追いつかなくなります。追いつくようなデータベースを構築しようと思うとすごく高くついて、ばかばかしいということですね。その場合にHadoopを使うということになります。Hadoopの場合はデータをぼーんと入れておくだけです。パースしない。インデックスも作らない。

もしそれを分析するときには、ここから必ず全量取ってきて、それを見るときにフィルタリングして、パースして、それで必要なデータだけフィルタリングして、機械学習のあとに使うということになります。

ただ、けっこう親和性は高くて。機械学習って、やはり全量を見たい。しかも夜の間とか何日かかけて学習すればいい場合が多いので、BIみたいにポチポチ経営者の方がクリックしながら「遅いよ!」なんてことはないわけですね。

なので、これはわりと親和性の高い技術だということになります。機械学習とビッグデータというのはよく一緒に使われてきた技術だということです。

もう1つのアーキテクチャとしてありうるなと思うのは、一度(データを)Hadoopには入れてしまうんですけれども、全部Hadoopでやるのは大変ですよね。先ほどみたいにデータベースのデータと一緒に結合することは非常に多いですし、データベースのエンジンでできることも多い。

つまりここで一度フィルタしてしまえば、学習するデータは、「昨日なにがたくさん売れていたか」「どういう売れた傾向があったか」というものと今日はどう違うかということを見たいのであれば、昨日だけフィルタリングすればいいわけですね。もしくは「雨が降ってる地域ではどうだったか」とか。

そういうことはフィルタリングしてから学習しますので、そういう場合には、一度フィルタをかけてから学習するということも1つの方法ではあります。

Occurred on , Published at

Oracle Code Tokyo

Oracle Code Tokyoに関するログをまとめています。コミュニティをフォローすることで、Oracle Code Tokyoに関する新着ログが公開された際に、通知を受け取ることができます。

このログの連載記事

1 データサイエンティストと営業担当者の溝をどう埋める? 機械学習を用いた“予測的”アプリケーションの作り方
2 要注意人物をAIで判定 テロ対策にも活用できる予測アプリケーションの実例
3 近日公開予定

スピーカーをフォロー

関連タグ

人気ログ

人気スピーカー

人気コミュニティ

ピックアップ

編集部のオススメ

ログミーBizをフォローして最新情報をチェックしよう!

人気ログ

人気スピーカー

人気コミュニティ

ピックアップ

編集部のオススメ

そのイベント、ログしないなんて
もったいない!
苦労して企画や集客したイベント「その場限り」になっていませんか?