外食のマーケティングを進化させる「外食データクラウド」とAIを活用した外食POSデータ「ラベリング技術」の業界を超えた戦略とMLOps活用
•
2 likes•1,953 views
DLLAB Engineer Days Day2: Conference Room1-1 株式会社トレタ 萩原 静厳 氏、吉村 広太 氏、佐藤 秋彦 氏
Recommended
More Related Content
What's hot
What's hot (20)
More from Deep Learning Lab（ディープラーニング・ラボ）
More from Deep Learning Lab（ディープラーニング・ラボ） (20)
Recently uploaded
Recently uploaded (14)
外食のマーケティングを進化させる「外食データクラウド」とAIを活用した外食POSデータ「ラベリング技術」の業界を超えた戦略とMLOps活用
- 2. 会社概要 社名 株式会社トレタ（Toreta,Inc.） 事業内容 飲食店向け予約／ 顧客台帳サービスの開発・販売 設立 2013年7月1日 資本金 15億9996万7千円 （累計調達額61.3億円） 代表者 代表取締役 中村 仁 正社員数 122名（2018年9月1日現在）
- 5. 外食データがワークしない要因 • 外食ビッグチェーンの規模は小売の1/10、マーケティング やデータ活用に(ヒトモノカネを)投資する力がない • リサーチ・分析に足るデータを集めるための相対的コスト が高い • 集客メディア依存により自社に顧客データが集まらない • (小売の) JANコードに準ずる規格化コードがなく、購買 データを正規化するコストが高い
- 11. POSデータを活用しよう① ◼ POS は店舗側がカスタマイズしていることを想定 • 必ずしも解析者の望み通りの分類ではない ◼ データサイエンスに活用するためにはラベル付けが必要 • しかし、一つ一つ手動分類では大変
- 13. 目標 ◼ 各メニューにラベルを付ける • 「どれか１つ」ではなく、複数のラベルを持ち得る 例： ミートソーススパゲッティ ⇒ 例： かつ丼 ⇒ ◼ 「分類問題」ではなく「マルチラベル問題」 • ニコニコ動画のタグみたいなもの 肉 パスタ 揚げ物肉 米 卵
- 14. 手順 1. メニューに使われる単語を数値ベクトル化 2. ラベルを付けたいメニュー名を数値ベクトル化 3. ニューラルネットワークの構築 • 構造 • コスト関数の定義 4. ニューラルネットワークの学習 5. 検証
- 15. 手順１ 単語のベクトル化① ◼ 各単語の使われ方の手本となる日本語の文章を用意する • この文章をワードコーパスと呼ぶ • ワードコーパスの選び方は重要 例： 生物学的文脈では「キノコ」と「大腸菌」は近い ⇔ 外食産業の文脈では遠い • 食レポ 4.4Gb + レシピ 3.2Gb
- 16. 手順１ 単語のベクトル化② ◼ ワードコーパスを単語ごとに分割（MeCab） • 活用語はすべて原型に変換 ◼ 「文字列の近似値」と「文脈上での近さ」をもとに、各単語を 300次元の数値ベクトルに変換（FastText） ◼ メニュー毎に含まれる単語をベクトルに変換できるようになる
- 17. 手順２ メニュー名の数値化 ◼ 入力された商品名を単語に分割して、 • 名詞・副詞・動詞のみを抽出 • 「クーポン」「大盛り」など、中身を表さない名詞を除外 例：「チキンの照り焼き定食」⇒「チキン」「照り焼き」「定食」 ◼ 各単語をベクトル化して、ベクトルの総和を商品のベクトルとする 例：「チキンの照り焼き定食」ベクトル ＝「チキン」ベクトル +「照り焼き」ベクトル +「定食」ベクトル
- 18. 手順３ NN構築① ◼ ニューラルネットワークで分類 • 入力レイヤー 300次元 メニュー名ベクトルを入力 • 中間層レイヤー 8 レイヤー • 出力レイヤー 肉／米／パスタ／チーズ／豆腐 の 5 次元に対して、 それぞれ 0 (False) ／1 (True) の出力をする
- 19. 手順３ NN構築②
- 20. 手順３ NN構築③ ◼ ロジスティック回帰 ◼ マルチラベルニューラルネット 例えて言えば・・・
- 21. 手順３ NN構築④ 参考https://qiita.com/koshian2/items/ab5e0c68a257585d7c6f 1つの画像が複数のクラスに属する場合（Multi-label）の画像分類 ◼ 誤差関数 • Binary cross entropy ◼ n 出力ベクトルの成分 (1～5) ◼ dn は教師データの非説明成分 ( T/F を 1/0 に変換したもの ) ◼ yn は N N の出力値 ◼ 要するに各ラベルにおける対数尤度の総和の -1倍
- 22. 手順４ 学習① ◼ 学習用教師データ • レシピ情報の材料一覧から自動的にラベル付け 例： レシピ名 「チーズハンバーグ」 材料 パン粉 1カップ ひき肉 300ｇ チーズ 2枚 ⇒ 肉＝1，米＝0，パスタ＝0，チーズ＝1，豆腐＝0
- 23. 手順４ 学習② ◼ 学習用教師データ • 説明変数 「チーズハンバーグ」ベクトル • 被説明変数 [1, 0, 0, 1, 0] • 50,000 件中 肉 米 パスタ チーズ 豆腐 件数 15,907 5,086 2,011 5,938 2,661
- 24. 手順５ 検証① ◼ いくつかの料理名で実験 • N N の予測したラベル
- 25. 手順５ 検証② ◼ 分散表現・特徴量抽出 の成功 • 「ハムカツ」「味噌カツ」 ⇒ 肉 • 「マグロカツ」 ⇒ 肉ではない ◼ 「ハムカツ」「味噌カツ」 はワードコーパ スで肉の文脈 ◼ 「カツ」そのものに肉要素はない
- 26. 手順５ 検証③（悪い点） ◼ 米ラベルの不良 • 原因は FastText ではなく N N か 牛丼とご飯のベクトルのcos類似度 は 牛丼と肉のcos類似度 と同程度
- 27. 手順５ 検証④ ◼ 「部分点方式」・・・正しく付けられたラベル数を調べる ◼ 「完答方式」 ・・・すべてのラベルを正しく付けられた メニュー数を調べる ◼ 正答率 肉 米 パスタ チーズ 豆腐 完答率 0.83 0.95 0.99 0.93 0.96 0.71
- 28. 分類にDLを用いてよかった点 ◼ 非線形分類 • 「カツ」はワードコーパス上では「肉」の傍で使われる カツ ⇒ 肉 だが、 マグロ ＋ カツ ⇒ not 肉 ◼ 回転・定数倍への頑強性 • 説明変数ベクトルを単語のベクトルの和にするか平均にする かで迷う必要はない
- 29. 質問 正答率 ◼ 誤ラベリングの内訳 • 教師データのエラー ・・・ レシピの材料の誤記載 • 名前からは分からないため仕方ないエラー 例：「オムレツ」と言っても肉が入っていたり入っていなかったりするので、 名前 だけでは判別できない • 外国語エラー ・・・ 対応しているのは日本語のみ • 改善可能エラー ・・・ 「できてほしかった」問題
- 30. 発表者について ◼ 氏名： 佐藤 秋彦 ◼ 経歴： • トレーディングカードショップ勤務 （通販サイト・POS管理・店頭業務など） • 東京大学大学院 総合文化研究科博士課程 中退 ◼ 所属 • 株式会社 トレタ • 株式会社 Monolith Works • 株式会社 すうがくぶんか（企業・社会人向け数学塾）
- 32. 発表者について 氏名：吉村 広太 所属：株式会社トレタ 株式会社Monolith Works Github: quetz-design 経歴： 以前は主にWeb・ios/androidアプリ開発中心だっ たが、データ分析に転身後は主に基盤エンジニ アとして活動中 個人でVR開発もやってる何でも屋
- 33. 今回のプロジェクトにあたっての課題 1. 毎日飲食に関する大量のPOSデータが収集されている • ビールや料理など商品単位に分解すると約10万件程 2. 他社の未活用POSデータもラベリングしていきたい • スケーリングしやすい設計に 3. チームメンバーのスキルがJupyter Notebook/R/BigQuery中心 • 既存スキルを再利用できるように 4. 精度向上のための定期的な評価・改善の仕組み作り • なるべく簡単にモデルの更新ができるように
- 34. モデルの継続的な評価と改善の課題 • 開発初期はスピード優先のため、ロジック開発者が自分の好きな環境で作 成したモデルをコピーして使用していた。 • 学習やバージョン管理に手間がかかり、開発サイクルの障害に • ラベル種別の増加に伴い、より多くのモデルが必要になった • チームで作業する時、開発環境や知見の共有が大変 • API型の推論サーバーを早く提供したい、というビジネス側の要望に開発 エンジニアのリソースを割り当てられなかった
- 35. 現在のアーキテクチャ Azure Data Factory その他協力会社 連携データ Data Warehouse Power Bi ダッシュボード・アプリ BI活用Users Azure databricks POSデータ レストラン マスタ 予約データ カスタマー マスタ MySQL 未活用のPOS データ POSデータ を活用したいUsers APIサーバー POSデータ ラベリング処理済みデータ 元データ 連携 ラベリング処理 パイプライン管理 MLロジック開発 モデルデプロイ 機械学習エンジニア Azure Azure Machine Learning
- 36. ワークフローはData Factory • GCPからの取り込みやバッチ起動などのワークフロー制御はData Factoryに全部任 せられたので実装の手間がだいぶ削減できた • 必要なコネクタはあらかじめ用意されていたのでGUIで組み合わせるだけ • 複雑な処理が必要ならdatabricksで柔軟なETLが可能
- 37. ラベリング処理・分析はdatabricks • ロジック開発がJupyter Notebookだったので移植は容易だった • ただしPandasのdataframeだと分散処理ができないので、sparkを理解しているエンジニ アが実装時にpysparkで書き直す必要があった。 • 処理済みデータをData Warehouseに格納したがsql serverの学習コストがかかるため databricksのdbに格納してspark SQLで分析を行ってもらっている
- 38. リソースやモデルの管理はAzureML • コマンドラインで簡単にクラウドリソースで開発 できるため、サイクルがより短くなった • VMでNotebookも動かせるので経験の浅いメンバーも導入 しやすい • 開発・学習環境をコードで管理できるので、チー ム内の環境整備が楽に • バージョン管理で最新版が把握しやすく • モデルをそのままデプロイできる仕組みがあるの で、リソースコストなく実装できた • 現在検証中
- 39. 全体的な感想と今後の課題について • 基盤の視点から見れば概ね満足 • 実装コストや安定性には大変満足している • 別件でCloud Composerでわちゃわちゃしてるのを見ると少し悲しい • GCP詳しい人がいたら是非！ • ラベリングの対応範囲の拡大していきたい • API型サービスも本番提供の準備を進めていく
- 41. POS活用領域に横展開するAIラベリング技術 外食 Product Algorithm Data 中食 内食 小売 流通 金融 … POSデータが絡む領域においてアルゴリズムで領域展開して行く戦略 すでに他領域のPOSデータホルダーと連携を推進中
- 43. ありがとうございました