More Related Content Similar to 機械学習を使った「ビジネスになる」アプリケーションの作り方 V2
Similar to 機械学習を使った「ビジネスになる」アプリケーションの作り方 V2 (20) 機械学習を使った「ビジネスになる」アプリケーションの作り方 V24. 自己紹介
学生時代
大学でアメフト部で相手チームのデータ分析
大学、大学院で機械学習を専攻
研究テーマ :機械学習によるアメリカンフットボールの戦略推定
社会人
楽天でキャリアスタート
Hadoopを使ったビッグデータ処理、Webアプリケーション開発
機械学習を使う機会には恵まれず
cherry-pick入社
自社サービスの機械学習部分の開発
9DW CTO就任
受託開発の機械学習部分
注意
サッカー選手ではありません
データ!アメフト!
データ!データ!
中村俊輔
@shun_naka
9. はじめに
何故今注目されている?
コンピュータのほうが安く
よりよく課題を解く場面が増えた
何故そんな場面がふえたのか
人間 vs コンピュータ
人間の得意なこと
曖昧さを許容
多様な知識を自ら学習
コンピュータの得意なこと
大規模計算が正確、高速
不眠不休
コンピュータの性能上昇、データ量増加
コンピュータのほうが安く
よりよく課題を解く場面が増えた
今ある仕事のいくつかはコンピュータになる…
かも
実用例
スパムメール検知
カメラの顔検出 …等
15. 対称関係にあるビジネス
学習済みモデル販売
既にある学習済みモデルの利用に応じて課金する
例
IBM Watson
Visual Recognition
Language Translator
…
Google CLOUD MACHINE LEARNING
SPEECH API
VISION API
TRANSLATE API
…
Microsoft
Computer Vision API
Speaker Recognition API
Translator Text API
…
も○もボックス
(これがあればだいたいイケる的思想)
18. 具体的な行動、成果物 (詳細)
実際のビジネス課題を解く手順
問題設定
会議、営業
データ選定
会議、データベース操作
前処理
ETL(Extract/Transform/Load)処理スクリプト開発
データベース操作、統計処理
機械学習で分析
開発 (Pythonメイン)
結果確認、再処理
可視化、評価指標確認
既存システムとの繋ぎこみ
API化開発、インフラ構築
19. 難しいポイント
実際のビジネス課題を解く手順
問題設定
会議、営業
データ選定
会議、データベース操作
前処理
ETL(Extract/Transform/Load)処理スクリプト開発
データベース操作、統計処理
機械学習で分析
開発 (Pythonメイン)
結果確認、再処理
可視化、評価指標確認
既存システムとの繋ぎこみ
API化開発、インフラ構築
難しいポイントをメインで説明します
24. 現場でやること 営業というより…
契約をどうするか、ではなく
どんなものを作るか、を話す
もう少しいうと、初めに作るプロトタイプの形をどうするかを話す
例
クライアント「ECのデータをまとめて見れるようなサービスを作りたい」
こちら「持っているデータについて教えてもらえますか?」
クライアント「各プラットフォームで商品のコード(JANコード)の欄があるが
入力はユーザー任せなのでついているものとついていないものがある」
こちら「じゃぁJANコードに対して商品を名寄せするシステムにしましょう。」
「一部データを教師データに使えるので、
いったん今あるデータで1-2カ月やってみます。」
25. アンチパターン
“機械学習で解くべきではない問題”に挑戦するのは避けるべき
機械学習で解くべきもの
軽度な知的作業、データを集めればなんとかなるもの
先行研究などがあるもの
解くべきではないもの
高度な知的作業、あいまいさ、ノイズが大きいデータ
教師データの入手が困難
例 (Webマーケティング自動化ツール)
クライアント 「以下のどれかやりたいんだけど…」
①広告購入 検索クエリレコメンド
②検索クエリごとのランキング上位化施策レコメンド
③Webページ自動更新
こちら 「1が一番簡単で3が一番難しい」
難しさを分かったうえでチャレンジするならOK
難しさが分かっていないと
クライアント 「こんなこともできないのか」
29. vs 巨人 2
巨人たちとの差別化、使い方
巨人の力を使えるところは使って、使えない部分だけ作る
本当にまじめにやるなら独自開発のほうが良いが、
まじめにやらなくても良いと思っている人もいる
※とりあえずやってたらいい人 (これも割といる)
ビジネスだけでいえば、
つなぎこむだけで開発が終わるならそれはそれでよい
車輪の再発明をする必要はない
※楽しくは…ないかも
受託開発 クラウド
ほしいものが使える ○ △
財産が残るか ○ ×
利用開始までの時間 × ◎
31. その分野のプロの知識をいかに反映させられるか
バリューを出せるポイント
機械学習の専門家 x ビジネスの専門家が組むからよい
すべてデータドリブンでは良いアプリケーションは作れない
ビジネスをやっている人のドメイン知識が必要
機械学習の専門家
データを使ってどう価値を出すかを知っているが
そのビジネスを知っているわけではない
そのビジネスで得られたデータの特徴や、解きたい課題は
ビジネス側から教えてもらう必要がある
機械学習の専門家 ビジネスの専門家
データ利用 ○ ×
ビジネス知識 × ○
33. その分野のプロの知識をいかに反映させられるか – アンチパターン
アンチパターン
機械学習を分かっていない人がリードをして
我々がビジネス要求を想像する
※結構よく見ます
クライアント「こんな手法がいいって聞いたんだけど、使ってみて」
こちら「えっ… (的外れすぎ ワロスw)」
こちら「データ的にはここはこうなはず」
クライアント「そんなわけあるか (実際に仕事してないから仕方ねぇな…つっかえ)」
機械学習の専門家 ビジネスの専門家
データ利用 ○ ×
ビジネス知識 × ○
※「原因と結果の経済学」
(中室牧子、津川友介著、ダイヤモンド社)
38. もっと良いものを作りたいと思ったときに
識別性能などのモデルの性能を上昇させたいなら
理論が先ではもう追いつけない
特にニューラルネットワーク
サポートベクターマシンくらいまでは理論先行だった
理論(基礎) 研究 -> 応用研究を支える図式
Deep Learningを支えるDrop Out,
構造であるCNN, RNNは応用(実践) から誕生し、
性能のみで評価されている
※理論の数学的な証明はなく、おそらくそうだろう、というものが多い
やったもん勝ち、ためしたもん勝ち
開発スピードや計算機のパワーをいかに引き出すかが勝負
自社でサービスを使いたい人はいかに良質なデータを大量にあつめるかが勝負
Google 開発者「我々は博士で難しいことを勉強したり研究したが、我々はデータセット
を集めることやチューニング等のくだらないことに徹している」
もちろん、”現在”の話
汎用人工知能や新たな手法が考案されれば変わるが
ここ10-20年くらいはこうなるはず
41. マイクロサービスにする
単独で動作し、シンプル
RESTful APIが分かりやすい
APIクライアントも開発して渡すと○
データの受け渡しも相手にしてもらうのが理想
こちらが直接データにアクセスするのを避ける
巨人のAPIの作りはかなり参考になる
例) Google Cloud Vision APIでは
画像をbase64エンコードして文字列にしてリクエストする。
バイナリより容量が増える、エンコードとデコード処理が必要になるが
文字列なのでシンプル
簡単なチューニングは相手にできるように
説明変数の追加等
51. データサイエンティストに必要な要素3つが身に着く現場
大学、大学院
数学、機械学習を身に着ける
論文を読んだら実装できる
大企業、中企業
開発、運用の基礎を身に着ける
高速な開発と容易な運用、いわゆるきれいなコードを
書けるようになる
ベンチャー企業
自ら問題解決をする
自社、クライアントの問題をデータサイエンスでどう
解決するかを提案できる
九DW
多種多様なクライアントとすべてのことができる!
データサイエンティストのパイオニアになる
ビジネス力
データサイエ
ンス力
データエンジ
ニアリング力
ビジネス力
データサイエ
ンス力
データエンジ
ニアリング力
ビジネス力
データサイエ
ンス力
データエンジ
ニアリング力
ビジネス力
データサイエ
ンス力
データエンジ
ニアリング力
※個人の感想です