機械学習の力を引き出すための依存性管理

Copyright © 2017 TIS Inc. All rights reserved.
機械学習の力を引き出すための依存性管理
戦略技術センター
久保隆宏
Dependency management to overcome the high interest
credit card.

Copyright © 2017 TIS Inc. All rights reserved. 2
 システムの中で活用される機械学習
 機械学習を利用するメリット
 機械学習と既存プログラムとの差異(ギャップ)
 ギャップを埋める処理による影響
 機械学習の副作用
 モデルの利用を通じた依存関係
 データを通じた依存関係
 機械学習モデルの依存関係の管理方法
 開発面からのアプローチ
 運用面からのアプローチ
 メリット・デメリット
 実践
目次(1/2)

 今後の機械学習の活用領域
 現在の機械学習の活用領域
 機械学習エンジニアの果たす役割
 機械学習活用の次のステップへ
目次(2/2)

久保隆宏
TIS株式会社戦略技術センター
 化学系メーカーの業務コンサルタント出身
 既存の技術では業務改善を行える範囲に限界があるとの実感から、戦
略技術センターへと異動
 現在は機械学習や自然言語処理の研究・それらを用いたシステムのプ
ロトタイピングを行う
自己紹介
kintoneアプリ内にたまった
データを簡単に学習・活用
(@Cybozu Days 2016)
機械学習のビジネスへの適用/
音楽生成で同人誌ダブル出展
(@技術書典2 2017)
チュートリアル講演：深層学習
の判断根拠を理解するための研
究とその意義(@PRMU 2017)

所属するチームのミッション
すべての人が、ティータイムに帰れるようにする
すべての人が、ティータイム(15:00)に帰れる(茶帰)
社会の実現を目指します。
この実現には、既存の仕事を効率化するのでなく、
根本的に「仕事の仕方」を変える必要があります。
しかし、慣れた仕事の仕方というのは簡単には変わ
りません。だからこそ、実際に「体験」をし、効果
を「実感」してもらうことが重要になります。
そのため、私たちは先進的技術を用い、仕事の仕方
が変わる体験を提供していきます。
(1/3)

観点を指定した自然言語処理
観点単位にまとめることで、情報の欠落を
防ぐと共に図表化を行いやすくする。
モデルにお任せで「こんなん出ました」で
なく、利用者が出力をコントロールする。
ex: 観点要約
ペンギンのサイズは小さくて、手触りは冷たい。
 「サイズ」は「小さく」
 「手触り」は「冷たい」
サイズ手触り
ペンギン小さい冷たい
ライオン大きい温かい
ウサギ中くらい温かい
業務要件により観点は異なる。そして、観点の学習データは少ない。
⇒自然言語処理における転移学習に注力し、「少ないデータでカスタマ
イズ可能な分類/生成器の作成」を目指している。
(2/3)

(3/3)
 研究開発活動は基本オープンに行っている(GitHub★総計 728)。
 研究に関することであれば、個人のブログ/リポジトリも評価される。
機械学習関連の論文のまとめをGitHubのIssueを使って行っ
ています。月一での輪講も開催中です。

システムの中で活用される機械学習

機械学習という技術は、研究面だけでなくソフトウェア面でも大きな発展
を遂げている。
機械学習を利用するメリット(1/2)
各種機械学習関連のライブラリで実装されたコードは、論文の公開と同時
にアクセス可能になることも多い。また、データ分析のコンペティション
が開かれるKaggleでは、Kernelという形で様々な参加者のアプローチが
公開されている(ブログでのインタビューもある)。
これにより、システムへの組み込みが容易になっている。

機械学習を組み込むことで、認識機能を利用したアプリケーションが簡単
に作れるようになった。
機械学習を利用するメリット(2/2)
ビクトリア州で約一億円かけて作っ
た盗難車両の検知システムを、たっ
た57行のコードで実装した例。
from How I replicated an $86 million
project in 57 lines of code
名刺の画像から氏名や会社名を抽出
する、簡単名刺管理システムを自前
で作る。
from Vision APIとNatural Language APIを組
み合わせて名刺から情報抽出する

ただ、機械学習と既存のプログラムは判断の仕方が異なる。
機械学習の判断は確率的なものになる(xx%猫、など)。
機械学習と既存プログラムとの差異(ギャップ) (1/5)
機械学習モデル
Cloud Vision APIより
これに対し通常のプログラムではこうした半端な判断は扱えないので、判
断をどちらかに寄せる必要がある(猫なのか猫じゃないのか、など)。
これが、機械学習と既存プログラムのギャップを埋める処理となる。

ギャップを埋める手法として代表的な方法が2つある。
一つは、「これ以上の確率だったら次に進む」といった閾値を使った処理。
Cloud Vision APIより
もう一つが「確率が最大のもの(=argmax)」に寄せるという処理。こち
らの方がよく利用される印象がある。
ただ、後ろに続く処理が重要になるほど、「最大のものに寄せる」処理は
危険をはらむことになる。
>80%
cat?
Yes
No

Yes
No
画像：ポプテピピック(大川ぶくぶ著)より
max=
KIKEN?
例：ツイートが危険だったらツイッターアカウントを停止する処理
機械学習の判断が「危険」か「危険でない」かの場合、「最大のものに寄
せる」処理だと危険の確率が0.5を超えた瞬間にアカウントが停止される
ことになる。
このため、一定の責任がある処理を行う場合は、適切な閾値の設定が欠か
せない。

適切な閾値の設定には、単に精度上の指標だけでなく、ビジネス上の要件
もかかわってくる。
 判断をミスるとユーザーが
会社に乗り込んできたりす
る場合など
 なるべく判断を誤らないよ
うにしたい=閾値は高めに設
定する。
 ちょっとでも(パクリの)可能
性があればなるべく補足し
て制裁を加えたい場合など
 多少ノイズがあっても可能
性のあるものは捕捉したい=
閾値は低めに設定する。

「理論上」閾値として良いとされるポイントはあるが、それが「ビジネス
上」良いポイントとは限らない。
機械学習と既存プログラムとの差異(ギャップ)(5/5)
参考:より良いビジネス意思決定のために、機械学習の閾値を可視化する
この記事を元にしたKaggle Kernel: Make good threshold for telecom business
機械学習を組み込んだシステムのパフォーマンスは、
機械学習を「扱う側」の設定によっても大きく変動する
適合率/再現率をプロットし
て判断する。
また、ROC曲線の利用など

ギャップを埋める処理による影響(1/3)
つまり・・・

if model.predict(user).prob[“kiken”] > 0.81394:
user.account.stop()
よく考えられた閾値
これが機械学習モデルの力を引き出すコードだ！
画像：ＭＭＲ:マガジンミステリー調査班より
※(さすがに)閾値については、固定値ではなくバリデーションデータを使って自動調整する
手法がある。
Detecting Adversarial Advertisements in the Wild

機械学習モデルを既存システムに組み込む場合、「機械学習を利用する側
の設定」もビジネス上のパフォーマンスを最大化するのに重要になる。
これは、機械学習モデルを更新する際は「扱う側」にも連鎖的な更新が必
要なことを意味している。更新をミスると、モデルは更新したけど閾値は
そのまま、といったような事態が発生する。
よって、「連鎖範囲」の把握が重要になる。モデルと閾値が1:1の場合は
わかりやすいが、依存関係はそれだけなのか？

機械学習の副作用

機械学習モデルの「連鎖範囲」を把握するには、以下2つの依存関係を把
握する必要がある。
機械学習がもたらす不可視の依存関係

モデルの利用を通じた依存関係(1/4)
解約防止のクーポンを
送る処理で使用
20xx年1月3日
ユーザーの解約を
予測するモデルを作成
閾値

逆に、解約する確率が低い
ユーザーに、追加機能の案
内を送付する処理を追加
20xx年1月3日
20xx年5月3日
閾値閾値

逆に、解約する確率が低い
ユーザーに、追加機能の案
内を送付する処理を追加
20xx年1月3日
20xx年5月3日
解約するかだけでなく理由を予
測するために、解約予測モデル
をベースに解約理由の分類モデ
ルを作成(転移学習)
20xx年9月24日
閾値閾値新モデル

 作成したモデルが、当初の処理とは異なる場所でも使用される
 画像分類のモデルを、猫の判断だけでなく犬の判断にも使用する
 作成したモデルをベースに、別のモデルが作成される
 経済ニュースの分類を行うモデルを元に、政治ニュースの分類を行
うモデルを作る
こうした「モデルの利用」を通じた依存関係を把握しておく必要がある。
機械学習モデルの利用が増えるにつれ、更新対象も増えていく

データを通じた依存関係(1/6)
ユーザーの
契約情報データ
営業メール先予測モデル
なかなかサービス利用し
てくれない時期

テレビCM開始
解約防止メールモデル営業メール先予測モデル
解約防止しなくても割と
継続してくれる時期

テレビCM開始
競合サービスが
リリース
解約防止メールモデル営業メール先予測モデル解約理由判断モデル
ライバルの登場などで、
解約が増加している時期

データの傾向が変われば、機械学習モデルの判断も変わってくる。
そのため、出自となるデータソースが同じであっても、判断傾向が異なる
モデルが混在する可能性がある。
例：営業メールの予測はユーザーの反応が薄いことが前提だが(悲観的)、
解約予測のモデルはユーザーがあまり解約しないことを前提としているな
ど(楽観的)。
モデルが作成された時期によってデータの傾向が異なる
営業メール先予測モデル解約防止メールモデル
どんどんメールを
送らんと契約とれ
んで！
そんなアピールし
なくても継続して
使ってくれるよ！

「判断を行う」というのを一つの業務とすると、機械学習のモデルの作成
はその判断を行う部署を一つ作るのに似ている(その部署で使うデータが
学習データとなる)。
学習データ
判断
時間がたつにつれ、いろんな部署(=機械学習モデル)ができる。
ただ、それらの間で情報の共有は行われない。機械学習は、再学習しなけ
れば判断基準が変わることはない。

システム内で判断傾向が割れないようにするためには、同じデータソース
から生まれたモデルについては同期をとる必要がある。
つまり、あるモデルを再学習するなら、データソースを同じくする他のモ
デルもこれに追随させる。これが、データを通じた依存関係となる。

これらの依存関係を、どう把握するか？
 利用先で閾値が設定されている
 学習元のモデルとして使用されている
 同じデータソースを出自とするモデル
機械学習がもたらす不可視の依存関係

機械学習モデルの依存関係の管理方法

依存関係の管理には、開発面と運用面からのアプローチが考えられる。
 コードにおけるモジュール依存関係の文脈で管理する
 学習プロセスなど機械学習にまつわる処理をログとして管理してお
き、そこから依存関係をたどる。
これらは対立する対策ではないので、併用することが可能。
機械学習モデルの依存関係の管理方法

モデルの利用、データの使用、いずれもコード上の依存関係で表現する。
これにより、モジュール依存管理の文脈で追跡が可能。
開発面からのアプローチ(1/2)
from account_stop import model
from datasets import user_tweets
data = user_tweets.load()
model.fit(data)
from threshold import ThresholdEstimator
from api import AccountStopPredictor
threshold = ThresholdEstimator(model)
threshold.fit(user_tweets.validate.load())
threshold.save(AccountStopPredictor)
Model Data
Model Threshold

開発面からのアプローチ(2/2)
from account_stop import model
from threshold import Threshold
class AccountStopPredictor():
def predict(self, user):
model = model.load()
threshold = Threshold.load(model, self)
return threshold(model.predict(user))
api.py
(コードはイメージです)

運用面からのアプローチ
画面はCloud MLのもの
Cloud ML/Amazon Sage Makerと
いった機械学習の学習プロセスをサ
ポートしてくれるサービスは、学習
の記録がログとして残る。
このログには、学習時指定したパラ
メーター(使用したデータ、ハイパー
パラメーターなど)を記録できる。こ
のログを利用すればデータへの依存
を管理することができる。
ただ、モデル利用の依存関係につい
ては難しい。ジョブ管理ツールなど
との合わせ技が必要にある。

もう使ってほしくないデータにDeprecated Warningをつける/利用時に
例外を飛ばす、データを利用できるモデルを限定するなど(継承クラスの
チェックetc)、コード上で使えるチェック機能を活用できる。ただ、ハイ
パーパラメーターなどの記録はできない。
機械学習の学習プロセスの管理は、依存関係の把握以外の課題にとっても
必要になる(ハイパーパラメーターを残しておく、モデルのバージョン管
理etc)。つまりどのみち導入が必要になってくるので、その中に含んでし
まえば特別なコストなく対応できる。ただ、ログベースなのでそもそもど
うあるべきなのかといった管理はできない。
これらは対立する対策ではないので、併用して使用することも可能。
メリット・デメリット

やってみた
実践(1/8)
icoxfog417/jetbull

 コード上でデータ、モデル間の依存を表現する
 クラウド上での実行を可能にし、ログを残す
実践(2/8)
cloud
local
Model
Pre-
Proc
Pre-
Proc
Pre-
Proc
Datasets
Pipeline base
Google Cloud
Storage
Google Cloud
DataFlow
Google Cloud
Machine Learning

 コード上でデータ、モデル間の依存を表現する
 クラウド上での実行を可能にし、ログを残す
実践(3/8)
cloud
local
Model
Pre-
Proc
Pre-
Proc
Pre-
Proc
Datasets
Pipeline base
Google Cloud
Storage
Google Cloud
DataFlow
Google Cloud
Machine Learning
Python2のみ(※3対応中)

 GCSとCloud MLのみ使用
実践(4/8)
cloud
local
Model
Pre-
Proc
Pre-
Proc
Pre-
Proc
Datasets
Pipeline base
Google Cloud
Storage
Google Cloud
Machine Learning

local
実践(5/8)
cloud
demo.trainer.task
 同一コードがlocal/cloudで動かせる
 データセットモジュールによるデー
タ管理

 コード上で依存性を表現すること自体は難しくない。ただ、コードは
「実行」と表裏一体であり、素直に行うと学習のたび毎回依存性に
沿った更新が行われることになる。これは現実的でない。
 開発・本番以外にステージングというステータスを設けると、学習と
デプロイを分割し、デプロイ時にだけチェックをかけられる。
実践(6/8)
dev
staging
release
release(deploy)を行うとき、依
存性のあるモデルのstagingが全
てそろっているかチェックして
リリース
学習は何度も実行可能で、ヨシ
となったらstagingに上げる。
モデルの使用先依存がある場合
(閾値など)は、相手先のstaging
を参照して学習する。

 クラウドストレージ(GCS)上のファイルは、簡単に上書きされる。
 学習時のソースも、学習モデルも・・・
 適切なネーミングルールで運用する必要がある。
 ログは残るが、ログとモデルの結び付けは自前で行う必要がある
 「このモデルの学習をしたJOBはどれだっけ？」「このモデルファ
イルを作ったソースはどれだっけ？」
 JOBIDをモデル名に含めるなどの工夫が必要
実践(7/8)
コーディング以外に各種ファイルの運用ルールを決めて、コード上
でチェックするのがかなり重要。

 データについては、バージョン管理も重要
 再学習のタイミングを把握するのにも必要：モデルが学習したデー
タと、現実のデータを比較して傾向に差異が出てくれば再学習のタ
イミング
 学習に使用したデータを残しておかないと、こうしたチェックはで
きない
実践(8/8)
あとはGCPの仕様についていろいろあるけど・・・
話すと長くなるのでカット
今後も実際の開発で使用する中でブラッシュアップしていきます
icoxfog417/jetbull

今後の機械学習の活用領域

本日のTL;DR
 機械学習の活用では、予測を行うAPIだけでなく、その予測を扱う側の
設定(閾値)も重要。そのため使用先の把握が必要。
 データは生き物なので時々で傾向は異なる。そのため、機械学習モデ
ルの作成時期によって判断傾向が割れることがある。判断の同期をと
るには、データソースを同じくするモデルの把握が必要。
 こうした依存性の管理には、開発・運用の両面からアプローチできる。
併用も可能。
こうしたケースは再学習が割と頻繁にあるケースを想定している。
ある判断だけに特化したモデル(閾値との関係が常に1:1)、またデータの
傾向がほぼ変わらないような場合は、こうした問題は顕在化しない。
現在の機械学習の活用領域(1/6)

データの変動少データの変動大
特化した判断
汎用性の高い判断
今回の問題が発生する領域

特化した判断
現在機械学習が
活躍している領域

特化した判断

現在は、データの変動がそれほど大きくない領域での活用事例が多い。
ただ、機械学習が扱える様々なフレームワークやサービスが登場するなか
で、いずれは機械学習の知識を要求しないレベルのサービスやライブラリ
が登場する。その際、こうした領域は真っ先にそうしたサービスに代替さ
れる可能性がある。
もう登場しとる

特化した判断
画像：ファイナルファンタジーⅥより
機械学習エンジニアが
AIにとってかわられる
(可能性がある)領域

機械学習エンジニアの果たす役割(1/8)
機械学習モデルの自動構築・チューニングは現在最も研究が盛んな領域の
一つであり、進歩も著しい。
Efficient Neural Architecture Search via Parameter
Sharing
ネットワークの自動構築に関する論文で、今まではGPUで
数百時間というのもざらだったが、16時間以内で画像で
も言語モデルでも高い精度を記録する(CIFAR-10はエラー
率2.89%、Penn Treebankはperplexity 55.8でSOTA)。
自動構築が可能なため、データが変動した場合でも対応を行うことができ
る。そのため、精度的にも、柔軟性的にも、高いレベルに達する可能性が
ある。

特化した判断
データの変動が少ないなら
一回作れば済む。
データが少ないケースは当
然難しいが、この場合人間
がやっても難しい。
データにあった構造を自動
で構築するため、柔軟性が
高い。

特化した判断
自動構築モデルは汎用モデルからスタート
するため、変動後の少ないデータだけでは
転移しきれないケースはありうる。
ImageNetや
Wikipediaで学習し
た汎用モデル
汎用性が高いモデルの場合はそれだけ
汎用モデルと共通する部分が大きくな
る(=転移がより容易)。

より柔軟
特化した判断
より特化
より汎用
自社用の
ベースモデル
これ自体は
AutoMLで作って
もよい

 より特化
 データの前処理、素のデータには「ない」特徴の追加など、よりド
メインに特化した処理を行うことで精度を上げていく。
 イメージとしては、Kaggleのコンペティションの領域に近い(自動
でKaggleのコンペでトップを取るのは、問題領域にもよるがおそら
く今後も難しい。)
Kaggle勝者の手法を見ると、データ
分析に基づく脱帽するような前処理や
問題の切り分けなどが目を引く。
モデル構築上の工夫というのはあまり
ない。

 より汎用
 より細かいカテゴリを持つモデルや、言語ではクロスリンガルなモ
デルなど。これは研究テーマとしても注目されている。
 汎用性の高いモデルは、柔軟性にもつながる(汎用的なほど色々な
状況に対応できるため)。
 より柔軟
 事前学習済みモデル(転移学習)を活用し、少ないデータしかない状
況(何かしらのビジネス変化が起きた直後など)でも対応する
 画像はもちろん、自然言語の分野でも盛んに研究が行われている。

現実には、ビジネス環境の変化によりデータに大きな変化が起こることが
多い。
 質問回答システム
 法令が変更された、新しい機種が出た
 画像からの異常検知モデル
 点検する場所が増えた・時間帯が変わった
 売上予測モデル
 近くに競合店ができた、今年からお祭りが中止になった
変更発生直後のデータは量がそれほどないため、おのずと既存のモデルを
ベースに学習する、転移学習などの技術が必要になってくる。
「柔軟性」は、変化が多い分野にも機械学習の活躍の場を広げるという面
でも重要。

より柔軟
特化した判断
より特化
より汎用
自社用の
ベースモデル
そのため
取り組む必要がある！

機械学習活用の次のステップへ(1/2)
 機械学習自体の自動化が進む中で、機械学習エンジニアという人間が
取り組むべき問題はどんどん変化してきている。
 より特化
 より汎用
 より柔軟
 これは強制スクロール型の進行なので、拒否権はない。
画像：ヨッシーアイランドより

機械学習活用の次のステップへ(2/2)
逆に考えれば、すでに解決された問題については自動的に処理してくれる
ありがたい状況とみることもできる。
 データがなければ力が出ない、という特性上データが十分ある(確保で
きる)領域が主戦場だったが、学習済みモデルの活用によりその前提は
崩れつつある。
 変化が大きい領域での活躍は、ビジネス的にも有用であるのと同時に、
研究面でも挑戦的なテーマ。
 そして、その際には依存性の問題が立ちはだかる。これは研究上の問
題というよりは、設計/開発/運用といったエンジニアリング面の問題。
機械学習の活用を次のステップに進めるためには、
研究面だけでなくエンジニアリング面での進化も必要

機械学習の力を引き出すための依存性管理

More Related Content

What's hot

Similar to 機械学習の力を引き出すための依存性管理

More from Takahiro Kubo

機械学習の力を引き出すための依存性管理