現場で使える機械学習活用 ~その②仮想プロジェクトを題材にしたプロジェクトのコツ解説~
はじめに
このブログは、「現場で使える機械学習活用」をテーマにした4部作のうち2作目です。これらの4部作では「いかにして機械学習を使って現実世界の問題を解決するか」を軸に、陥りやすいポイントやコツを解説していきます。
第2回目は、仮想プロジェクトを題材にして、第1回目で解説したプロジェクト成功のため留意すべきことをどのように活用するかを見ていきます。
仮想プロジェクトを題材にしたプロジェクトのコツ解説 ←イマココ！
機械学習プロジェクトの流れ
第1回目に掲載したプロジェクトの流れを再掲します。仮想プロジェクトはPoCであるので、下記1~4「課題が機械学習で解決できるかを検証する」という部分のみを題材にします。
課題から機械学習で解決できそうな部分を見つけ、実現性を探る
機械学習で解けるように問題を設定する
必要なデータを集め、前処理をする
機械学習で学習・モデルの改善を行う
機械学習を実務に組み込む
仮想プロジェクト
「チェーン店の各店舗で数日おきに発生する商品の発注数予測が難しい」という問題を解決する仮想的な機械学習プロジェクトを題材にします。この問題を解決するために、他社がすでに取り組んでいる機械学習技術の導入を検討している、という状況です。
1. 課題から機械学習で解決できそうな部分を見つけ、実現性を探る
まず、解きたい課題から機械学習を活用できそうな部分を探すというプロセスについてみていきます。まずは「チェーン店の各店舗で数日おきに発生する商品の発注数予測が難しい」という問題を、もう少し具体化してみます。関係者にヒアリングしたところ、以下２つの課題に集約できるとことがわかりました。
①商品の種類が多く、全商品の発注業務の作業負担が大きすぎる
②発注処理は慣れが必要なので、店舗によって予測精度のばらつきが大きく、廃棄や機会損失が大きくなるリスクがある
これらの課題に対して、第 1 回目で解説した【「機械学習を使うこと」ではなく「課題を解決すること」を考える】を使って、問題を再考してみます。ここでは、機械学習を使わないアプローチとして「人間が定めたルールで機械的に発注処理を行う」というルールベースのアプローチと機械学習を比較します。
機械学習を用いたアプローチと手動でルールを作るアプローチ両方を検討した結果をまとめたのが下表です。以下詳細にみていきます。
まず、ルールベース手法を検討します。この２つの課題を一挙に解決するためには、発注作業のエキスパートがしていることと同じことを自動的に実施するシステムを作れば何とかなりそうです。これを実現する一番単純な方法は、エキスパート発注者の考え方を反映したルールを作ってシステムに組み込むことです。
しかし②の課題感で発注には慣れが必要だということから分かるように、これを数値的な処理ルールに落とし込むことは非常に困難です。例えば、台風が直撃する日では売上が下がるのは素人でも何となくわかりますが、数値的に何％下がるのかと言われると、エキスパートでも完全に数値化するというのは難しい作業でしょう。さらに考慮しないといけない要素は台風だけでなく地域のイベント、テレビ CM や SNS の影響など多岐に渡ります。また、様々な商品を発注する必要があるので、影響を数値化する作業を全ての商品群に対して行わなくてはなりません。例えば「商品の分類がおにぎり、かつ台風がくる、かつイベントがない、かつテレビ CM がない場合は、売上 xx% 低下」などのルールを作る必要があります。組み合わせのパターンが膨大であるため、これらのルール全てを作る作業量も膨大です。さらに、正しく数値化することも難しいため、それらを作ったからといって本当にうまく動作するのかも不透明です。
次に機械学習手法を検討してみます。ここでの前提条件は、商品毎の売上とそれに影響しそうな要素のデータが十分に存在していることですが、この案件では幸いにも大量のデータが蓄積されているとします。
まず課題①「作業負担が大きく業務を圧迫する」に関して、いったんモデルを学習すれば、繰り返し発生する発注作業を自動化でき、課題①を解決できます。
次に課題②「発注処理は慣れが必要なので、店舗によって予測精度のばらつきが大きく、廃棄や機会損失が大きくなるリスクがある」に関してですが、機械学習モデル自体は使う人によって出力が変化することはないので、エキスパートの作業を再現するモデルを作れば、初心者でもエキスパート並みの予測精度で発注をすることができます。そして最後に実現可能性ですが、他社実績（コンビニの発注自動化のニュースなど）があるので、実現可能性も十分ありそうです。
以上より、この仮想プロジェクトでは機械学習を用いてプロジェクトを進めます。
2. 機械学習で解けるように問題を設定する
機械学習を使うことが決まったら、具体的な問題設定を決めなければなりません。この問題設定はプロジェクトの成否を分けると言っていいほど重要な要素です。ここで機械学習に解かせる問題をうまく簡単化すれば高い精度のモデルを学習・運用できますが、うまく問題設定を練られないと機械学習で問題を解けずにプロジェクトが頓挫してしまいます。
この段階で決めなければならないことは以下の4つです。それぞれ順番に決めていきます。
何をモデルの出力とするか
何をモデルの入力とするか
どの程度の精度を目指すか
計算資源はどの程度使うか
何をモデルの出力とするか
ここでは、第 1 回目で解説した【ドメイン知識を駆使して解くべき問題を簡単にする】を活用します。核となる問いは「本当に発注数を直接予測すべきなのか」です。そのためにまずは、発注数予測で何をしたいのかを再考します（下図）。
発注が必要ということはすなわち、売り場に陳列されている商品（ドーナツ）が売れて、このままでは売り場に商品がなくなってしまう状況にあるということです。それを防ぐために発注をして売り場に商品を補充します。
では、売り場にどれだけの商品を補充、すなわち発注する必要があるでしょうか？上の例では 4 日ごとに発注と前回の発注品の納品が同時に行われています。そのため、今回の発注では、次回の発注が納品される 8 日後まで品切れを防げる量を発注すべきです。簡単のため予備在庫確保などを無視すると、
現時点の在庫数（青）＋ 発注数（黄）＝ 8 日間の売上数
となれば、売り場をまかなうだけの数量を確保できます。
しかし、売上数を正しく予測できるとしても、現時点の在庫数量によって発注量が変動してしまいます。つまり、発注数を直接予測すると「売上数」「在庫数」2つの未知変数を予測しなくてはなりません。そのため、発注数を目的変数に置いた場合は問題が難化する可能性があります。
そこで、【ドメイン知識を駆使して解くべき問題を簡単にする】を活用し、問題を簡単にします。まず発注数は【（予測）売上数ー在庫数】で機械的に計算できることを思い出します。また、在庫数は既知であるため、売上数が予測できるならば発注数も計算できます。よって、売上数を発注数の代わりに予測しても問題を解決できます。このことから、「発注数」の代わりに「売上数」を目的変数、つまりモデルの出力にします。
何をモデルの入力とするか
ここでは、第 1 回目で解説した【大規模な検証よりも小さな検証を繰り返す】【ドメイン知識を駆使して解くべき問題を簡単にする】の 2 つを活用して機械学習の入力を設定します。
さきほど売上を目的変数にすることに決定しましたが、売上に影響しそうな因子はどれくらいあるでしょうか。パッと思いつくだけで、過去の売上、類似商品の売上、商品の種別、商圏の人口、天気、周辺のイベント予定、SNSやテレビCMなど影響を与えそうな要素が多岐にわたります。
理想的にはこれらを全て入力データに入れてモデルに考慮させたいのですが、プロジェクトやモデルが巨大かつ複雑になりすぎます。前回の記事で述べたように【大規模な検証よりも小さな検証を繰り返す】という立場に立つと、1つの開発単位は小さい方がよく（下図）、モデルに多くの情報を詰めこむことは避けた方がよいでしょう。
そこで、【ドメイン知識を駆使して解くべき問題を簡単にする】を用います。つまり、玉石混交のデータを全て与えるのではなく、厳選した意味のあるデータのみを与えて、機械学習にとって問題を解きやすいものにします。
入力となる説明変数が多く玉石混交だと、意味のないデータがノイズとなってモデルに混乱を与えます。一方、厳選したデータのみを与えることで、モデルが入力情報を解釈をし易くなります。また、入力データを厳選することにより、データの前処理工数も削減することが可能です。
どのデータに最も情報が含まれているかはドメイン知識をもとに決めます。この仮想プロジェクトではドメインエキスパートにヒアリングを行い、「天気」「過去の売上」「商品種別」「類似商品の売上」の 4 つに入力データを絞ることにします（下図）。
どの程度の精度を目指すか
完璧な精度を目標にすべきではないことは、前回の記事で述べました。ImageNetという超有名タスクで数多くのトップ研究者が競いながら10年以上かけて到達した精度が90.2%ですので、短期間のPoCでこれ以上の精度をあまり期待することはできません（下図）。
この仮想プロジェクトでも、災害やイベントなど想定していない偶発的な事象で売上が大きく左右されることが考えられるので、売上(発注数)を毎回ピタリと正確に予測することは難しいです。このように、外因に予測値が大きく左右される場合や、医療など予測の誤りに大きなリスクを伴う場合などでは、「機械学習モデルは推奨値を出してサポートはするが、最終的な判断は人間が行う」という戦略がとられる場合があります (Guha et al., 2022など）。今回の例でいうと、想定外の外因や地域特有の現象を全てモデルに入れ込むことは困難であるため「機械学習モデルが発注推奨値は出すが、特殊事情による推奨値の微修正は人間が行う」という戦略です。このように推奨値を算出してくれるだけでも作業負担を小さくでき、熟練者と初級者の予測の質の差をある程度埋めることができます。
計算資源はどの程度使うか
最後に計算資源についてです。GBDT系や線形回帰などは学習・推論ともにそこまで大きな計算資源を要求しませんが、どの程度の計算資源を使えるかという判断は、深層学習を使う場合は特に重要な要素です。
深層学習の場合は高価で高性能なCPUだけでなく、GPUやTPUを搭載した計算機を必要とし、場合によってはそれを数週間から数ヶ月以上実験で使い続けます。そのため、プロジェクトを開始する前に、どの程度の計算資源が使えるのか、またはAWSなどの計算サーバーのコストがどのくらい許容できるのかを確認しておきましょう。今回の例では、運良くエンジニアの手持ちPCが高性能だったので学習（開発）は手持ちPCで行うことにします。モデルのデプロイは本ブログの内容を超えるので詳述しませんが、実運用は何らかのサーバー上で動くウェブアプリを作ることにします。
問題設定のまとめ
長くなったので、どのような設定になったかをおさらいします。計算資源以外の設定を以下に示します。
では、何も考えずに問題設定をすると、どうなるでしょうか？
上に示したように、問題設定は熟慮しないとプロジェクト失敗の原因になりかねません。本プロジェクトで使った考え方を下にまとめます。
3. 必要なデータを集め、前処理をする
機械学習で使えるデータには「型」があります。例えば、画像分類であれば、入力は「画像データ」、出力は「カテゴリを示す数値ベクトル」です。物体検知（アンカー使用）であれば、入力は「画像データ」、出力は「カテゴリを示す数値ベクトル」と「位置情報を示す4つの数値」です。このように、機械学習に入力するデータにするには、何らかの処理を施す必要があります。
問題設定で決めたような入出力データを用意しなければなりませんが、「型」があるため、どのようなデータを準備するかは機械学習担当エンジニアとよく相談しましょう。この相談を行わずにデータを準備すると、データが無駄になったり、前処理工数が膨大になったりするので注意が必要です。
4. 機械学習で学習・モデルの改善を行う
データの処理が終わったら、実際にモデルを学習させてみましょう。この仮想プロジェクトで扱うデータの形式はテーブルデータといわれる表形式のデータで、問題としては教師あり学習の回帰問題に属するタスクです。線形回帰、ランダムフォレスト、GBDT、深層学習など色々な手法が適用できますが、どの手法が最適かはデータやタスクの内容によるので、特に開発の初期段階では色々試してみることをお勧めします。
ここからは「学習→解析→改善→学習→…」のループを回していってモデルを改善してきます(下図)。ここで改良するのはモデルだけではなく、データも改善することに注意してください。モデルを補助できるような新たな特徴量を作ったり、新たにデータを外部から取得することも考えられます。
また、モデルの改善精度だけに目が行きがちですが「何を予測できていて、何を予測できていないのか」を見ることも大切です。これを見ることによって、モデルが解釈できている部分・できていない部分を知ることができ、新たな改善につながります。例えば、コンビニの売り上げを予測するモデルを学習させたとき、平日の予測はよく当たっているが土日の予測がうまくいっていないということがわかれば、曜日を示す特徴量を明示的にいれる改善施策が検討できます。第 4 回目の記事で説明する可視化手法 (下図) を使うのも良い考えです。モデルが重視している特徴量をもっと詳述したり、ノイズになっていそうなものを削除したりもできます。
終わりに
第 2 回目では、仮想プロジェクトを題材にして、機械学習プロジェクトの流れを説明しました。機械学習を使ったプロジェクトでは問題設定をどう上手く設定するかが非常に重要で、ここはエンジニアの腕の見せ所です。
次回の記事では、プロジェクトで頻出する問題とどう向き合い、解決すればよいかを見ていきます。
このブログのように、「いかにして機械学習を使って現実世界の問題を解決するか」を解説した本を書いています。ここで書いたことより詳しく書いていますので、気になった方はぜひ手に取ってみてください。
記事を書くために、多くの調査や論文の読み込みを行っております。情報発信を継続していくためにも、サポートをいただけると非常に嬉しいです。