SGD

全データ計算の限界を突破するSGDの確率的な学習アプローチ

通常の勾配降下法は、手元にある全データを計算してからパラメータを更新する。データが数万件ならいい。だが、製造業のIoTセンサーから送られてくる数テラバイトの時系列データだったらどうなるか。メモリはパンクし、1回の更新に何日も待たされる。

そこでSGDの出番である。

ランダムに1件、あるいは少数のデータをピックアップして計算し、即座にパラメータをいじる。これを猛烈なスピードで繰り返す。

計算の方向は毎回ブレる。だが、全体として見れば着実に誤差の少ない方向へ進んでいく。非エンジニアには乱暴な手法に見えるかもしれない。しかし、この適当に選んでとにかく動くアプローチが、現代のディープラーニングを根底で支えている。

物流や製造現場におけるSGDの活用領域と代表的なAIツール

物流センターの需要予測や、製造ラインの不良品検知。こうした現場では、TensorFlowやPyTorchといったフレームワークを使ってモデルを組むのが日常である。scikit-learnでサクッと回帰モデルを作る時も、裏側ではSGDが走っていることが多い。

例えば、ある物流企業で配送ルートの最適化モデルを構築した時のこと。天候や交通量、ドライバーの過去の配送履歴など、変数が多すぎて計算が全く終わらなかった。

全データを使った厳密な計算を諦め、ミニバッチSGDに切り替えた途端、数時間で実用レベルのモデルが組み上がった。現場の担当者は魔法でも見たような顔をしていたが、単に計算のショートカットをしただけである。

計算速度の向上と精度におけるトレードオフ

速いことには当然代償がある。

SGDは毎回ランダムなデータを使うため、計算の軌跡がジグザグになる。運が悪いと局所最適解と呼ばれる偽の谷底にハマって抜け出せなくなることもある。

学習率というハイパーパラメータの調整も厄介である。歩幅が大きすぎれば谷底を飛び越えて永遠に正解にたどり着かないし、小さすぎれば計算が終わらない。このあたりの塩梅は、正直なところエンジニアの勘と経験に依存している部分が大きく、属人化しやすいのが悩ましい。

バッチサイズをいくつにするか。これも正解はない。プロジェクトごとに泥臭くチューニングしていくしかないのが現実である。

自社のAIプロジェクトでSGDを採用すべきかの判断基準

マネージャー層がベンダーから提案を受けた時、最適化アルゴリズムに何を使っているかまで気にする人は少ない。

だが、そこは突っ込んで聞くべきである。

AdamのようなSGDの進化系を使っているのか、それとも古典的な手法で止まっているのか。扱うデータ量が数百万件を超えるなら、クラウドコンピューティングのGPUリソースをどう割り当てるかというインフラの話とセットで議論しなければならない。

計算コストと精度のバランスをどこで取るか。100点の精度を求めて莫大なAWSの請求書を受け取るか、80点の精度で翌日から現場に投入するか。ビジネスの要件によって判断が分かれる。