ザ・プリンス パークタワー東京で開催中の Google Cloud Next '17 in Tokyo に参加しています。
今回は機械学習周りのセッションを集中して選んでみましたのでそのメモです（裏番組になっていて残念ながら聴講できなかったセッションも多数）。ほとんど殴り書き＆一部不確かな記述があるかもしれませんがご容赦ください。
事例から学ぶ機械学習のいま ～ 専門家不要、自社独自の機械学習サービスを構築できる MAGELLAN BLOCKS の事例を元に、その方法と今起きている変革をご紹介します。
URL : Google Cloud Next | October 11-13, 2022
- 機械学習サービスを作るためには業務知識と機械学習の知識が必要
- 専門家に頼むと精度が出てもその後どうしたら良いかよくわからない
- 人の考えるをもっと自由に、誰もが使える機械学習に
- 業務知識とデータがあればそれで十分という世界を目指す
- 基本的な機能
- データを集める : IoT ボード
- 学習させる : Machine Learning ボード
- ブロックを繋いで結果を導く : BigData ボード
- ブロックをつなげてバッチ系の処理とかも表現できる
- フローに名前をつけて外部からも呼び出せる
- API ブロックで外部のプログラムからも呼び出せる
- 結果を Salesforce とかにセットできる
- 過去のデータをブロックに見せると予測を始める
- 数値データだと1,000件（３年分）もあれば精度は出る
- ML ボード : 数値回帰, 数値分類, 画像分類
- 電波強度をラズパイで計測して場所による人の密度を予測する回遊予測のデモ実演中
- 結果は緯度経度の二次元で出る
- 隠れ層の数や Learning モデルなどのハイパーパラメータの調整のために中と外の二段構えの機械学習
- トレーニングの最大施工数なども指定できる
- 画像分類の場合はカテゴリ名のフォルダの下に画像を入れるだけでラベルが振られる
- 事例紹介
- カイロの売上予測
- N日前の気温などの条件も一緒に入れて時系列の変化も考慮して予測した
- １店舗あたり１個程度の予測の差の精度で出た
- J リーグ観客動員数の予測
- 2012 - 2014年前半戦までのデータを学習して2014年後半を予測
- 少ない因子でかなり精度が高くでた
- 曜日やキックオフの時間などだけでわかるということは、スタジアムまで来るファンが固定化されてしまっているということ
- 株価予測
- 関連因子を元に翌日の株価を予測した結果、500円台の銘柄で誤差1.2円
- クライアントはドメイン知識があるのでそのクライアントにしかできない
- 節電効果予測
- 節電装置設置前に節電効果を予測
- 誤差0.03%
- 契約予測
- 金融商品のDMを送る前に契約しそうな人を予測
- 96%の予測を達成
- カイロの売上予測
- Google Assistant (api.ai) 連携
- 会話する BLOOKS
- どの項目があれば質問が確定するかを設定すると、足りない情報を会話で聞くことができる
Google におけるディープラーニングの活用と Google Cloud Platform の機械学習サービス
URL : Google Cloud Next | October 11-13, 2022
- Google が社内で使っている機械学習とディープラーニングの紹介
- @enakai00 さん
- 一昔前の Google のコンセプトであった One click で〜 というのはもう古い
- 音声入力、キーワードなしのクエリ（Search result query）の時代
- メディアで騒がれている AI は技術の話ではない
- 知性を持っているかのような機能を提供する製品・サービス
- いずれにせよ予測の機能が重要なのは間違いない
- 従来型の機械学習がまさにそれ
- ディープラーニングと機械学習の違い : 非構造型のデータに高い予測性能を発揮する
- 事例紹介
- DeepMind の音声合成技術（WaveNet）
- Dilated Causal Convolutional Neural Network を用いてデジタル音声データを０から作り上げる
- 音のつなぎ合わせではない
- 人間のアナウンサーの声に次いで次に自然だと評価を得ている
- 人間の声は体調的なコンディションにも左右されるので、将来的に合成音で安定的なアナウンスがされるようになるかもしれない
- 声質と色々なテキスト文の組み合わせを作ることができる
- 異種の言語を足し合わせてSFに出てくるような実在しない言語も生成できる
- Gmail Smart Reply
- メールの返答文を（３択くらい？）勝手に生成してくれる
- スマホの Gmail の２割で既に使われている
- データセンターの冷却設備の動作を改善
- （Google のエンジニアがチューニングしていた状態から）DeepMind のチームが深層学習を適用したところ冷却コストが40%低下
- データセンター電力効率（PUE）が15%改善
- DeepMind の音声合成技術（WaveNet）
- GCP が提供する機械学習サービス
- 独自モデルの学習
- TensorFlow
- Cloud Machine Learning Engine
- 学習済みモデルの API サービス
- Cloud Vision API
- 写真の中のテキストを認識
- 画像アップロードサービスで不適切かどうかの判別を自動化できる
- Cloud Speech API
- Cloud Jobs API
- Cloud Video Intelligence API
- まだベータ版だが、何が動画に現れているかを認識できる
- Shot 分析（シーン別分析）もできる（動画内の情報検索に活用できる）
- Cloud Natural Language API
- ocado （イギリスのオンラインスーパーマーケット）
- クレーム対応などの CS 業務を自然言語分析にかけて感情判定をしている
- ようやく実用レベルに達したという評価を得ることができた
- ocado （イギリスのオンラインスーパーマーケット）
- Cloud Vision API
- 独自モデルの学習
- CyberAgent アドテク本部 AI Lab が Vision API を活用
- 広告代理店でのデータ分析
- Versus
- 次世代ブランド戦略室 x AI Lab
- ブランドリフトに寄与するクリエイティブの構成要素を分析して動画制作の意思決定をサポートするサービス
- 動画・画像広告の持つ高次元な要素を効率的に抽出するために Cloud Vision API を使用
- 導入以前は Youtube Brand Lift Survey を使って、配信した動画広告について数百種類の要素を人出でタグ付けしていた
- 導入後は Cloud Vision API とのハイブリッドになり、人手でしか難しいタグ付けを手作業で処理
- Cloud Machine Learning Engine
- 事例紹介
- キューピー x ブレインパッド
- 製造ライン上の不良品を画像から検出
- オークネット x ブレインパッド
- 顧客が撮影した写真から自動車の車種・製造年を検出するシステム
- アクサ損害保険
- ニューラルネットの活用で重大事故を起こすドライバーの予測精度を78%に向上
- 従来型の機械学習は今までもやっていたはずだがニューラルネットで予想以上に予測精度を向上できた
- 構造化データにも効果を発揮したという事例にもなった
- キューピー x ブレインパッド
- 事例紹介
- フルサイクルの機械学習プラットフォーム
- GCP のサーバレス・データ分析基盤を活用したデータサイエンスの実践のセッションが明日開催される
No-Ops で大量データ処理基盤を簡単に構築する - Google Cloud Platform で実現する次世代データ処理基盤
URL : Google Cloud Next | October 11-13, 2022
BigData + No-Ops- Google では Big Data とは言わない。ただのデータ。
- Google には世界に10億人のユーザを抱えるサービスが８つある
- Flume Java と Millwheel は Dataflow として公開されている
- 基盤を作るとメンテナンスしなければいけないので No-Ops で分析に費やす時間を増やす
- データ処理基盤の要素 : 収集 / 保存 / 処理・分析 / 可視化
- Cloud 2.0 と 3.0
- Cloud 2.0 はパブリッククラウドの上に OSS を入れて自分で運用する
- Cloud 3.0 は No-Ops
- Cloud Spanner : NewSQL (OLTP において今までにない DB)
- まず BigQuery から始める
- GCP に手をつけるときに一番やりやすい、Google の特徴的なサービス
- フルマネージドの No-Ops データウェアハウス
- 1PBのデータに対して秒間５TBのスループットで処理が可能
- マルチゾーン・マルチリージョン
- データソース
- バッチロード
- Cloud Storage Transfer Service
- gsutil
- ストリーム API
- Google Analytics 360 suite
- Firebase
- Google Stackdriver
- システムログ
- アプリケーションログ
- BigQuery Data Transfer Service
- まだ Beta
- DoubleClick や Adwords などの広告系サービスのデータをインポート可能
- バッチロード
- 可視化
- Cloud Datalab
- Data Studio
データ処理エンジンとしての BigQuery
- 構造データ
- スキーマ定義されている
- 文字列を SQL や UDF で分解することは可能
- バッチ処理
- クエリ処理のトリガーは API でキックできる
- SQL
- UDF で JS を記述できるが本質的には SQL エンジン
- 構造データ
Cloud Dataflow
- ストリーム及びバッチの統合処理モデル
- OSS 実装もある（Apache Beam）
- 新たなデフォルト (MapReduce / FlumeJava / MillWheel が合わさって DataFlow を構成する)
Cloud Dataproc
- Hadoop, Spark のマネージドサービス
- BigQuery / Bigtable / Cloud Storage のコネクタ
- 必要なときに必要なだけ立ち上げるクラスタ
- 高速（90秒でクラスタが起動）
- 低コスト（分単位課金、プリエンティブル（最長24時間までしか動かない）VM）
Cloud PubSub
- スケーラブルで信頼性の高いメッセージングミドルウェア
- 多様な配信方式
- Push 配信及び Pull 配信
- グローバルリソース
リファレンスアーキテクチャ
- Cloud Dataflow はバッチでもストリームでも前処理できる
- No-Ops で自動的にスケールできる
リクルートテクノロジーズの事例紹介
- オンプレミス Hadoop 基盤の活用と課題
- スタック : Sqoop / Hbase / Impala / Hive / Hadoop / Python
- 活用シーン
- リクルートの Web サービスへのレコメンド機能の提供
- BI/分析
- 課題
- メンテナンスコスト
- Hadoop のバージョンアップ対応
- 既存ジョブのテストやその環境コスト（３万クエリのテストが必要）
- エコシステム間の依存関係で影響範囲が大きくなることも
- バージョンアップして Impala の関数を使いたいがために Hive も上げる必要があったりする
- インフラ運用の４割くらいの業務ボリュームを割いてしまっている
- パッチ適用対応
- 新規クエリや従来クエリのデータ量や質の変化で未知のバグを踏むこともある
- Hadoop のバージョンアップ対応
- スケーラビリティ
- 拡張リードアイム
- ノード追加やクラスタ増設
- サーバやラックの設置で２、３ヶ月かかることもある
- 用意さえされれば provisioning は自動化されているが、そもそも突然要求リソースが増えたりする
- 機械学習処理の拡張性
- Python の機械学習処理の複数サーバ分散の手動運用
- 主に多数のユーザやコンテンツに対する predict() が処理増大
- Python の機械学習処理の複数サーバ分散の手動運用
- 拡張リードアイム
- メンテナンスコスト
- Ops ばかりやっているが、本当であればデータ活用の方に回したい
- GCP 活用による課題解決
- ハイブリッド No-Ops クラウドサービス
- フラットな視点で最適なクラウドサービスを選択
- 以降コストが見合わないなどの環境はオンプレミス
- Hive + Impala -> BigQuery
- BigQuery と DataFlow 中心の構成に
- なぜ BigQuey なのか
- バージョンアップなどの大幅な仕様変更がなさそう。標準SQLで開発可能にもなった。
- データサイエンティストが使いやすくて何より速い
- Hive で１時間の処理が BigQuery で10分
- 本来処理したくて諦めていた５倍のデータ処理もいけるようになった
- なぜ DataFlow なのか
- 分散処理インフラの運用がほぼ不要
- リソースの起動・停止・拡張縮小・リソース使用量やログ収集管理など
- predict() のところを並列処理できる
- Python が GA になった
- 分散処理インフラの運用がほぼ不要
- ハイブリッド No-Ops クラウドサービス
- Hive -> BigQuery の書き換えはノウハウをパターン化
- Hive にしかない機能例 : Dynamic partition / STRUCT / LATERAL VIEW
- MapReduce や UDF は幸いほとんどクエリ化できた
- BigQuery の課題
- データの移行
- 大きめの CROSS JOIN
- Dataflow の課題
- データ量が増えた場合の拡張をどのように自動化するか
- 現在は worker 数を指定しているため要手動チューニング
- オンプレミス Hadoop 基盤の活用と課題
Google のデータサイエンティストが語る現場で使える機械学習入門
URL : Google Cloud Next | October 11-13, 2022
- 機械学習はこう動く
- ルールベースによる分類との違い
- 単純なルールで分けられないデータに弱い。例外が来るたびに書き直さなければいけない
- 機械学習はデータに合わせて自動的に改善する
- 自動的に縦横問わず線を引く（単純パーセプトロン）
- 曲線や縁で最適な線を引き直すこともできる（SVM など）
- 学習データをスキャンしていきながら分類器を学習させていき、テストデータで検証
- 誤判定が発生したときにフィードバックを与えてモデルパラメータを変更する
- ルールベースによる分類との違い
８つの機械学習のステップ
- 機械学習を使うかどうかの判断
- 例えばEC サイトのレコメンドシステムにディープラーニングを使う
- 毎日働いてくれるし売り上げも上がっていれば中身がブラックボックスでも許せる
- アプトプットが日次より頻繁というのも一つの判断要因
- 例えばEC サイトのレコメンドシステムにディープラーニングを使う
- 目的：機械学習に何をさせるのか？
- 解きたいパズルは何か : CPA の最小化、CVR の最大化など
- データを集める
- 十分な量のデータをできるだけ自動で集める
- 本当に必要なデータか厳選する
- データの前処理
- 一般的にデータはそのままではただのゴミの山、きちんと分類整理しなければ役に立たない
- 基本的にはどんなデータでも列指向に持ち直す必要がある
- 前処理は全リソースの８割以上を費やす
- モデル学習とその方法
- 機械学習も万能ではない
- モデルのチューニング
- チューニングしてこそのアウトプット
- 汎化性能
- 過去データにぴったり合わせ過ぎると未知のデータに合わなくなる
- ノイズに振り回されず真のシグナルにもっともよくフィットすることで未知データに対して高い精度を発揮する度合いが汎化性能
- 検証
- A/Bテスト、pre/post テストで効果を見る
- もちろん ROI も重要なので全体感に注意
- 改善サイクル
- 消費者心理の変化などでかつて有効だった機械学習モデルも割と簡単に使い物にならなくなる
- 改善サイクルを回し続けてこその機械学習
- 機械学習を使うかどうかの判断
GCP x ML for business
- 典型的な use case
- 新規見込みユーザ検出
- イメージ・ドキュメント認識・分類
- 2 を受けてのレコメンド
- 異常値検出
- 対戦ゲームの自動プレイ
- BigQuery x TensorFlow
- Datalab から BigQuery を呼ぶ
- シャッフルして最初の N 件を学習に使う
- tensorflow 1.2 が出てだいぶシンプルに記述できるようになった
- DNNClassifier
- hidden_units を空にすると単層パーセプトロン
- MLP : multi layer perceptron
- 典型的な use case
- IDOM (ガリバー) の ML プロジェクト
- GA 360 + CRM データ > BigQuery > Datalab
- 来店確率を予測して店舗訪問の可能性の高い顧客に優先的にリーチした
- RLS の CET (Capture Every Thing)
- GMO Ad Marketing など（裏のセッション）
顧客関心をより高める AI（機械学習）と API の活用
URL : Google Cloud Next | October 11-13, 2022
- AI or IA (Intelligence Amplification : 知能増幅)?
- 自動運転 vs ブレーキアシスト
- いずれにせよこれらを支えるのが機械学習
- 人工知能：物事を賢くする技術
- 機械学習：学べるコンピュータの作り方
- ニューラルネットワーク：機械学習の１手法
- 継続的な学習：強化学習
- AlphaGO も AlphaGO 同士が戦って強化している
- Street view の内部情報（看板の文字など）の認識にも使っている
- ロボットがものを掴む動作を繰り返し行って学習していく
- Google 翻訳もディープラーニングベースのものに変わった
- AI x API による機械学習の民主化
- 自分で作った AI と Google の AI を API でつなげる
- それをさらに世に出して他の人に使ってもらうこともできる
- AI は難解なアプリケーションのためだけにあるわけではない
- 全てのアプリケーションは将来的に学習するようになる
- 知性を全てのアプリケーションと API に組み込まなくてはいけない
- APigee
- いろんなサービスを API 化することを助けるサービス
- ボットからの攻撃（呼び出し）を防御してくれたりする
- 新しい API（エンゲージメント）層
- 利用するサービスの API 化だけでなく作り出した機能の提供のための API 生成にも使える
- いろんなサービスを API 化することを助けるサービス
- rMark Bio 社
- サイロ化されたヘルスケアデータへの API からのアクセスを実現
- デモ
- 300行のJSのコードでチャットのデモが作れる
- Firebase でログインなどの機能も実現
- 会話応答だけでなく Translation API を使って翻訳をしたり Vision API を使って OCR 的な認識による画像からの文字起こしもできる
- 技術は進化するほどユーザ視点では簡単になっていく
- ユーザ企業は顧客と組織にフォーカスしていくことができる
API.AI と Cloud Speech、チャットボットで実現する、会話型ユーザー エクスペリエンス
URL : Google Cloud Next | October 11-13, 2022
- conversation API と speech recognition についてのお話
- api.ai は Google に買収された会社
- 自然言語を構造化データに変換する
- Cloud function と組み合わせると強力
- Slack や LINE とも連携できるのでそれぞれのチャットボットを開発可能
- Agent をまず作る
- そして Entity (Synonym を適当にいくつか入れて単語の表現に幅を持たせられる)
- Intent : 対話制御
- Entity を勝手に判断してくれる
- 意味的に近い文章は（機械学習で）同じ文章として寄せてくれる
- 離れたやつは Training から history を開いて自分でチューニングできる
- プロンプトを出して質問の確定に足りない情報を聞くことができる
- 結果はJSON で吐き出せる
- Context を使って複数の応答を行う会話を生成可能
- 音声の文字起こしデモ
- meat と meet も文脈を判断して正しく書き分けられる
- 感情分析の API もあるのでその言葉がどれくらいポジティブ or ネガティブか判断可能
- つまらないセッションすぎて終わるまで待てない -> ネガティブなスコア
- このセッションすごい楽しい、特にデモ -> ポジティブなスコア
- api.ai も Speech Recognition API も今日から公式に日本語対応
