Composability

NN のモデルがアプリのあちこちに色々ありすぎてメモリや CPU を使いまくって厳しい。モデルの実行は自分の与り知らないネイティブコードの奥深くで起こっているのではたして全体でいくつのモデルがあるのかすらわからないが、なかなか現代的な事象を目の当たりにしているとは思う。

アプリの性格上、こうしたモデルの大半は何らの方法で画像を入力として受け取るモデルのはずである。理想的には、アプリに内在するいくつものタスクは入力を共有する multi-head なモデルとして表現され hidden layer などの計算資源を共有すべきだが、たぶんそうなっていない。

これは入力の解像度やモデルの実行頻度の違いなどに起因している面もあるけれど、より本質的には Andrej Karpathy の Software 2.0 や Keras 作者の The future of deep learning が envision しているような未来のプログラミングとしての model composition という世界がまだここには来ていない、という話のような気がする。

モデルを開発しているチームが会社の中の別のところにいるせいでおこる ML 版 Conway's Law という見方もできる一方、伝統的なソフトウェアではチームをまたいでコードが分断されても機能自体は API を通じて共有され同じ計算を何度もやりなおしたりは(そんなには)していない。ML モデルにしても、たとえば segmentation なんかは複数チームの機能をまたいでモデルおよび結果を共有している。つまりモデルの入力という切り口でなく Java なり C++ なりの API というところまで遡れば共有されている。

複数機能やチームをまたいでモデルのアーキテクチャを部分的に共有する、なんて言うは易しだけれどもトレーニングどうするなどを含め自明でないことが多すぎ、自分にはあるべき姿がまったく想像できない。一方でそうしたモデルの統合なしにデバイスの計算資源が要求にあわせスケールすることがあり得ないのもまた明らかなので、この問題は数年以内にどこかの頭のいい人がなんとかするのだろう。それを見届けたい気はする。単にスケールせず AI 機能は頭打ちになりました、おしまい、という可能性もまあまああるが・・・。


あるとき AI っぽい新機能を開発している同僚と話していたら、その機能は実は別のあまり関係なさそうな既存機能のモデルで実現でき、したがって性能上のインパクトほとんどないんだよ、と聞かされてびっくりした。モデル再利用できちゃってる?自分の問題認識が遅れているだけで、結局問題は Conway さんという話なのかなあ。

Martin Fowler が micro models とかいいだすのはいつだろうか。Micro frontends 以上にどうでもいい話になりそうだが・・・。