2019/05/14に開催した白金鉱業 Meetup Vol.7 (https://brainpad-meetup.connpass.com/event/126945/)の発表資料です。 自然言語処理のバッチ予測システムを構築した際に取り組んだこと・反省などについてまとめています。

1. MLOps Yearning
~ 実運⽤システムを構築する前にデータサイエンティストが考えておきたいこと
May 14, 2019
Wataru Miura
Data Science Dept.
Rakuten, Inc.

2. 2
⾃⼰紹介
• ⽒名: 三浦 航
• 略歴:
• 2014/03: 東京⼯業⼤学⼤学院総合理⼯学研究科知能システム科学専攻
• ⽇本企業100万社の取引ネットワークの解析
• 2014/04 ~ 2018/06: 株式会社ブレインパッド
• 機械学習を⽤いた各種プロジェクトの推進
• 2018/07 ~ : 楽天株式会社
• 機械学習を⽤いた楽天における各種サービスの改善
最近の興味
• 機械学習を⽤いたシステムの開発・運⽤ (MLOps)
• 機械学習モデルの継続的な改善
お話しすること
• ⾃然⾔語処理のバッチ予測システムを構築した際に取り組んだこと・反省など
• 事業会社のデータサイエンティストの役割やワークスタイルなど

3. 3
機械学習システムの開発・運⽤における最近のナレッジ
MLOps, 機械学習プロジェクトのナレッジは蓄積されてきたものの、データサイエンスにおける継続的な
モデル改善部分のナレッジは薄い (という個⼈的な)印象。
Business
(機械学習
プロジェクト)
Analytics
(データサイエンス)
Engineering
(MLOps)
• 機械学習システム開発プロジェクトの予算・予定・⼈情
• 深層学習を実運⽤システムに組み込むということ
• 機械学習システムを受託開発する時に気をつけておきたい事
• 機械学習システム開発案件の事例紹介
• 機械学習システムのアーキテクチャアラカルト

4. 4
本⽇のアジェンダ
データサイエンスがメインフィールドのデータサイエンティストが、機械学習システムを構築する際に
考えておくべきことは何なのか︖
1. ⾃然⾔語処理タスクの紹介
2. データサイエンティストが考えておきたいこと
• MLOps
• データサイエンス
• 機械学習プロジェクト
3. まとめ

5. 5
⾃然⾔語処理タスクの紹介

6. 6
アイテム名, 店舗名に対する⾃然⾔語処理
アイテム名, 店舗名に対する⾃然⾔語処理は様々なタスクが考えられ、⼀般的にその需要も⾼いと考えられる。
• 家計簿アプリにおけるアイテム名, 店舗名の費⽬分類
→ OCRで読み込んだレシートを、⾃動で費⽬の登録まで完了してくれる
• ショッピング・オークションサイトにおける同⼀アイテムのマッチング1
→ ユーザが付与した同⼀のアイテム名称を認識できることで、価格を⽐較できるようになる
• アイテム名からの型番・ブランド名などの固有表現抽出2
→ 検索時に⾊やメーカーなど、属性を指定した検索が可能となる
• レシピサイトにおける材料名の正規化3
→ 材料名の表記ゆれに対する、カロリー登録のコストの削減
本⽇は店舗名のカテゴリ分類というタスクについて考え、その予測システムを構築する際の話をします。
店舗名のカテゴリ分類タスクのイメージ
様々な特徴量が存在するものの、基本的には店舗名のみから業種カテゴリを予測する。
店舗ID 店舗名称
100000 ミウラ薬局
100001 ミウラストア
カテゴリ スコア
ドラッグストア 0.8
スーパーマーケット 0.6
1. A. Kannan et al., Matching Unstructured Product Offers to Structured Product Specifications, KDD 2011
2. M. Joshi et al., Distributed Word Representations Improve NER for e-Commerce, NAACL-HLT 2015
3. Encoder-Decoder でレシピの材料名を正規化する - クックパッド開発者ブログ
https://techlife.cookpad.com/entry/2017/10/30/080102

7. 7
MLOps⾯で考えておきたいこと

8. 8
MLOps: 予測システムフローの概要
学習パート
予測パート
受領学習⽤
ファイル
機械学習⽤
データセット
機械学習⽤
データマート
作成
(⼀度のみ)
前処理
機械学習
モデル
各種ルール
連携学習⽤
追加ファイル
連携予測対象
ファイル
名称参照⽤
データセット
蓄積
更新
前処理
学習 (次回実⾏時に反映)
カテゴリ付与
ロジック
連携予測結果
ファイル
予測
適⽤
⼀致時参照
出⼒
各種レポート
通知
定期的にファイルが連携されて
データが更新され、カテゴリ
付与からモデルの学習/更新まで
を実⾏する。

9. 9
MLOps: 考えたことなど
1. 全体のワークフローは機械学習基盤上のAirflowで管理
• 前処理のパイプラインは学習・推論時で同⼀のコードを使⽤
2. 学習した機械学習モデルは次回実⾏時に更新させる
(予測時は前回学習時のモデルを⽤いる)
• 即時性が必要かどうかはケースバイケース
• 予測が⽉次なら1ヶ⽉、週次なら1週間の猶予ができる
3. 精度指標・集計結果をSlackに通知
4. 実際の実装はさておき、全体のフローはデータサイエンティスト
も考慮できると良いのでは
• どの段階でどの形式のデータを出⼒・保存すべきか︖
• 機械学習モデル以外の予測ロジックはどう追加/削除する︖
• 何をモニタリングするべきなのか︖
• 運⽤時に前処理⽅法を変えたくなった場合は︖
( )
( )

10. 10
データサイエンス⾯で考えておきたいこと

11. 11
データサイエンス: タスク及び機械学習システムの難しい点
そもそも店舗名のカテゴリ予測タスクは難しい。
• ナイーブな解釈としては、「ホテル」「薬局」などの単語から当てるが、ファッション系は特に難しい
• 固有名詞が多く、知識がないと⼈ですら当てられない
• 名称がカタカナ⼤⽂字表記の場合も多く、わかち書きが難しい
また機械学習システムとしては以下の問題も存在。
• 学習時と運⽤時のデータが異なる
• データ作成⽅法の違い
• 想定外のデータ
• アイテム、店舗トレンドの変化により、外界 (データ)の傾向が毎回変わる
• 新商品、新店舗
• 季節性の需要
→ タスク難易度の変化
→ カテゴリ⾃体の⾒直し
→ 毎回モデルの更新が必要

12. 12
データサイエンス: 何を評価すべきなのか
データの傾向が変わると、ラベル付けされたデータ数が増加
していても精度が減少するということが起こりうる。
考えられる理由
1. タスクの難化
2. 評価指標がロバストでない
3. 学習/検証/テストデータの分割が毎回異なる
2.に関してはF1値のカテゴリ平均など (scikit-learnにおける
macro系指標) を採⽤していると、データ数の少ない
カテゴリでの精度変化の影響を受けやすい。
→ 指標⾃体がある程度ロバストである必要性
3.はデータ数が少ないと影響を受けがち。
1.に関しては学習データ数を変化させて、既存傾向のデータ
数が増加した場合の精度を外挿で⾒積もる。
データ数がいくつになれば精度がおよそ何%など試算も可能。
各回における学習データ数と精度
学習データ数
精度
この回の説明に困る
学習データ数と精度の関係
既存のデータ数

13. 13
データサイエンス: 何をモニタリングすべきなのか
精度だけをトラッキングしていても、我々は⼀体何を観測しているのか…ということが起こる。
予測データの傾向の変化をどう把握するべきなのか︖
ü 定性的な把握
ü ラベル付けされたデータのカテゴリ分布変化
ü 予測されたデータのカテゴリ分布変化
ü 上記のスコアしきい値未満
ü 各カテゴリの精度変化
データを⼀つずつ丁寧に⾒ていくのがベストとは思うものの、教師データの分布が⼤幅に変化、予測スコアの
低いデータが特定カテゴリで増加、などの場合に何か発⽣していることが多い。
基本的にはデータ傾向の変化を把握するのは難しいので、模索中の領域。

14. 14
データサイエンス: 外界の変化にどう対応するか
データ傾向の変化にどう対応するべきなのか。
1. ラベル付けされたデータを増やしてモデル任せ
2. ルールを新たに設定し、モデルとハイブリッド
基本的には1.だが、影響を無視できない場合に2.を設定。
• 条件の部分はパターンマッチングやIDの指定などが⼊る
• ルールが適⽤されるデータは、モデル作成からは除去
• メンテナンスや将来の変更など考慮すると、ルールはあまり
増やしたくないし複雑にしたくもないが、モデルに回す
データは極⼒減らしたい…というジレンマ
• ルール作成にあまり⼯数をかけられないという事情も
カテゴリ付与ロジックフローの例
条件1
カテゴリA
条件2
カテゴリB 機械学習
モデル
Yes No
Yes No
モデルベースルールベース

15. 15
機械学習プロジェクト⾯で考えておきたいこと

16. 16
機械学習プロジェクト: 実運⽤のためのPoCとバックテスト
⼤抵の場合、タスクの精度指標だけではPoCとしては不⼗分。モデルの正解率が90%あったとしても、それがビジネス的に
役に⽴つのかは不明な場合が多い。
またone-shotのPoCで、運⽤時に起こり得ることを事前に全て⾒積もるのは難しい。運⽤を⾒据えてヒストリカルデータを
⽤いた複数回のバックテストをしておけば、話したような⼤抵の問題は事前に洗い出せる。
実運⽤のためのPoC
• 機械学習タスクとビジネスの⽬的は⼤抵異なる
• 分類した結果に対して、集計など別のタスクを実施
• ⽬的は正解率ではなくコストの削減
• ビジネス上やりたいことに対して事前にテスト
• KPI・削減コストの⾒積もり・シミュレーション
→ 業務フローを事前に明確にしておく必要性
ヒストリカルデータを⽤いたバックテスト
• 例えば⽉次の予測システムであれば、2⽉, 3⽉, 4⽉などのデータを⽤いてどのような問題が発⽣するかを事前に⾒積もる
• データの安定性
• データに対する前処理・処理フロー
• モデルの取捨選択と評価基準
• モデル更新頻度の把握
→ (データ取得環境が存在しない場合) 実データの準備が必要
つまりモデル構築よりも先に、システム上でデータを取得できるようになっていることが好ましい
というようなことを⾃分だけではなく、ステークホルダーも理解していることが重要。
•
•

17. 17
まとめ

18. 18
まとめ
• データサイエンティストが考慮すべき問題の多くは、one-shotのPoCという時間軸と業務オペレーション
(業務フロー、活⽤⽅法)の⽋如した状態で、機械学習システムを構築することに起因
• これらの問題は、ヒストリカルデータを⽤いたバックテストを複数回実施することで事前に洗い出せるはず
• データサイエンティストだけが考えてどうなるものでもなく、データサイエンティスト、機械学習
エンジニア、PMがお互いの領域をカバーしあえる、相談できるようなチームの構築も⼤事