機械学習（ML）モデルの本番稼働後に精度を継続して高める。それには、精度監視や再トレーニングなどのプロセスの自動化が不可欠だ。ヤマト運輸、SUBARU、クックパッド、三菱ガス化学の取り組みを紹介する。
ヤマト運輸
コンテナのパイプラインで開発環境を丸ごと移行
ヤマト運輸は機械学習（ML）モデルによって、全国に約6500カ所ある配送センターごとの荷物量を予測し、各センターの人員やトラックの手配に役立てている。2021年1月に本番導入し、現在は主に月次で新しいモデルを開発し更新している。MLOpsの基盤を構築してデータの前処理やトレーニングなどのプロセスを自動化することで、新モデルの開発・更新に要する工数を従来の数分の1に短縮したという。
同社が配送センター経由で顧客に届ける荷物は2022年度で年間22.5億個に上る。各センターで扱う荷物量には地域差があり、季節や曜日による変動も大きい。さらに近年、大手ネット通販会社の期間限定セールなどで荷物量が急増するケースも顕著になっている。
従来は集荷や配達の実績データなどを基に人手で人員やトラックの手配を決めていたが、「担当者の経験と勘に頼る部分が大きかった」と中林紀彦執行役員デジタル機能デジタルデータ戦略担当は話す。MLモデルによって、経験と勘への依存から脱却しデータに基づいた経営を目指す。
開発環境をイメージにしてデプロイ
一般にMLモデルの開発では、まずデータウエアハウスなどのデータストアからデータを抽出し、データの欠損を補ったりフォーマットをそろえたりといった前処理をして学習データ（評価用データを含む）を用意する。そのうえで、モデルのアルゴリズム（フレームワーク）などを決定してコードを作成。学習データでトレーニングし、評価用データによってモデルの予測精度を確認する。
こうした一連のプロセスの大部分を、スクリプトなどによって自動実行できるようにした環境を「パイプライン」と呼ぶ。パイプラインは実行環境も備えており、推論も行える。
パイプラインは基本的に開発環境として設けるが、ヤマト運輸は本番環境でもほぼ同じ構成のパイプラインをつくって運用している。つまり本番環境にも、モデルの改良プロセスを自動化する機能を持たせたわけだ。
目的はモデル改良の頻度を高めるためである。ヤマト運輸は荷物量の予測モデルのアルゴリズムやハイパーパラメーターなどを月次で見直し、月初にバージョンアップしたモデルを本番リリースしている。しかし「荷物量のトレンドが急変することがあり、月次の改良では不十分と考えている」（中林執行役員）。そこで改良頻度をさらに高めるため、本番環境でも随時、最新のデータでモデルを再トレーニングできるようにした。
本番環境にも開発環境と同じパイプラインを設けた利点はもう1つある。それは月次でバージョンアップしたモデルを、円滑に本番環境に移行できることだ。
ヤマト運輸は2種のパイプラインをDockerイメージとして保存している。このイメージを読み込んだコンテナを展開するだけで、開発環境と本番環境のパイプラインを構築できる。この利点を生かして、開発環境のパイプラインを丸ごと本番環境に移す仕組みにしている。
具体的には、月末までに開発環境のパイプラインをDockerイメージとして保存しておく。月初の本番移行では、本番環境の従来のパイプラインを削除したうえで、保存しておいたイメージを使って新しいパイプラインを構築する。パイプラインはコンテナ基盤上につくるので、削除や作成の操作はスクリプトで可能だ。
ヤマト運輸のMLOps基盤を担当する、エクサウィザーズの毛利拓也AIプラットフォーム事業部AIイノベーショングループAIコンサルタントは「モデルの開発基盤そのものを本番適用する考え方だ」と話す。これによって本番移行のトラブルを回避しやすくなるという。
ヤマト運輸は以前、開発環境にのみパイプラインを設けていた時期があった。その際、MLモデルの本番移行に伴う本番環境の改修によって、障害が発生することがあったという。
本番環境にもパイプラインを設けるようにしてからは、手間をかけず円滑にMLモデルを本番移行できるようになった。仮に移行後、本番環境で障害が発生しても、開発環境においてあらかじめパイプラインとして機能することを確認できているため、原因分析の調査範囲をパイプライン以外の部分に限定できるという。
