HOME/ AINOW編集部 /データサイエンスから機械学習エンジニアリングへの移行
2020.08.28

データサイエンスから機械学習エンジニアリングへの移行

著者のCaleb Kaiser氏は機械学習モデル開発プラットフォームCortexの開発に関わりながら、機械学習に関する技術論をMediumに投稿し続けています。AINOWで紹介した記事『機械学習自体を学ぶな』で機械学習モデルの開発実践力の重要性を力説した同氏は、最近Mediumに投稿した記事『データサイエンスから機械学習エンジニアリングへの移行』において、そうした開発実践力に「機械学習エンジニアリング」という名称をつけて詳しく解説しています。

テキストアドベンチャーゲーム『AI Dungeon』のような機械学習システムには、同ゲームに活用されている言語モデルGPT-2を開発する技術と、この言語モデルを使ってゲームを開発するそれという位相の異なるふたつの技術が関わっています。同氏は、前者のような機械学習システムの中核機能を司る技術をデータサイエンス、そして後者を機械学習エンジニアリングと区別します。このように区別すると、後者は「機械学習を現実世界の問題に応用する技術」と定義できます。
同氏によると、従来のAIツールやAIプラットフォームはデータサイエンスを意識したものとなっています。しかしながら、実際に機械学習システムの構築に役立つのは、機械学習エンジニアリングを意識したものです。こうした機械学習エンジニアリングは、サーバの負荷分散やAPIの呼び出しのような既存のソフトウェアエンジニアリングに似た技術と見なすことができます。
同氏が開発に関わるCortexは、以上のような機械学習エンジニアリングを意識した開発プラットフォームとなっています。そして、今後の機械学習システムの普及において重要なのは、機械学習エンジニアリングとそれを意識したツール群なのです。

日本のAI業界に求められる人材像を考えた場合、機械学習自体の研究開発に関わる「機械学習のリサーチエンジニア」と実装を専門とする「機械学習エンジニアリングに詳しいソフトウェアエンジニア」の2種類の人材が挙げられます。後者の人材に関しては、これからキャリアパスが整備されていくことでしょう。

なお、以下の記事本文はCaleb Kaiser氏に直接コンタクトをとり、翻訳許可を頂いたうえで翻訳したものです。また、翻訳記事の内容は同氏の見解であり、特定の国や地域ならび組織や団体を代表するものではなく、翻訳者およびAINOW編集部の主義主張を表明したものでもありません。

機械学習とソフトウェアの世界は変わりつつある

過去20年間、 機械学習は1つの疑問を問い続けてきた。何事かを実行するモデルを訓練することはできるのか。

何事か」と言うからには、もちろんどんなタスクであってもよい。文章の次の単語を予測する、写真の中の顔を認識する、特定の音を発生させる。機械学習が機能するかどうか、あるいは正確な予測ができるかどうか、ということが目標だったのだ。

データサイエンティストによる何十年にもわたる研究のおかげで、今では多くの「何事か」を実行できるモデルが、以下のようにたくさんある。

  • OpenAIのGPT-2(現在はGPT-3)は、なかなかに人間らしいテキストを生成することができる。
  • (公式版をめぐる議論はさておき(※訳註1))YOLOv5のようなオブジェクト検出モデルは、毎秒140フレームの動画からオブジェクトを解析することができる。
  • Tacotron 2のようなテキスト音声合成モデルは、人間の声のように聞こえる音声を生成することができる。

データサイエンティストや機械学習の研究者たちの仕事は驚くべきもので、その結果、自然と第二の疑問が生まれてきた。

これらのモデルで何が作れるのか、そして、どうやって作れるのか。

この疑問は、明らかにデータサイエンスの問題ではない。工学的な問題である。それに答えるために、機械学習エンジニアリングという新しい専門分野が登場した。

(※訳註1)動画内のオブジェクトを検出するAIモデル「YOLOv5」は、YOLOv1を発表したJoseph Redmon氏ではなく、Glenn Jocher氏が開発した。ただし、Jocher氏は同AIモデルのソースコードはGitHubで公開したものも、論文を発表していない。こうした事情から、同AIモデルに「YOLO」という名称を使う妥当性をめぐって論争が起こった。この論争に関しては、オブジェクト検出技術を提供するAIスタートアップroboflowが公開したブログ記事『YOLOv5に関する論争への対応』に詳しく解説されている。

機械学習エンジニアリングとは、機械学習を現実世界の問題に応用する方法である

データサイエンスと機械学習エンジニアリングの違いは、最初は少し無形のものに感じるかも知れないので、いくつかの例を見てもらって理解の手助けとしたい。

1.画像分類から機械学習生成カタログへ

画像分類とキーワード抽出は、それぞれコンピュータビジョンと自然言語処理の古典的な問題である。

Glisten.aiは、両方のタスクのために訓練されたモデルを同時に使用して、製品画像から構造化された情報を抽出するAPIを作成した(※訳註2)。

画像出典:TechCrunch

(※訳註2)Glisten.aiが提供するAPIおよび技術的背景に関しては、同社公式サイトを参照のこと。

モデル自体はデータサイエンスの印象的な偉業である。しかし、Glisten APIは機械学習エンジニアリングの偉業だ。

2.オブジェクト検知から密猟予防へ

Wildlife Protection Solution(略称:WPS)は、絶滅の危機に瀕している種の保護にテクノロジーを利用している小さな非営利団体である。最近、彼らはビデオ監視システムに密猟者を認識するために訓練されたオブジェクト検出モデルを組み込むというアップグレードを行った。このモデルの検出率はすでに2倍となっている。

画像出典:Silverpond

YOLOv4のようなオブジェクト検出モデルはデータサイエンスの成功例であり、WPSがモデルの訓練に使用したプラットフォームであるHighlighterは印象的なデータサイエンスツールである(※訳註3)。しかし、WPSの密猟者検出システムは、機械学習エンジニアリングの偉業だ。

(※訳註3)以上に解説された密猟予防システムは、WPSとAIスタートアップSilverpondが共同して開発した。この開発に使われたのが、silverpondが提供するAIツールHighLigterである。同密猟予防システムに関する詳細はこちらを参照のこと。

3.機械翻訳からCOVID19のムーンショットへ

機械翻訳とは、データをある形式から別の形式に「翻訳」するために機械学習を使用することを指し、人間の言語間の場合もあれば、全く異なる形式の場合もある。

PostEraは、機械翻訳を利用して化合物を工学的な設計図に「翻訳」する薬化学プラットフォームだ。現在、化学者は、COVID19の治療法を見つけるためのオープンソースの取り組みでこのプラットフォームを使用している。

画像出典:PostEra

分子を一連の(分子から別の分子への変換する)「ルート」に変換できるモデルを開発することは、データサイエンスの偉業である。PostEraプラットフォームの構築は、機械学習エンジニアリングの偉業である(※訳註4)。

(※訳註4)PostEraの詳細は、公式サイトを参照のこと。

4.テキスト生成から機械学習のダンジョンマスターへ

OpenAIのGPT-2は、リリース当時、史上最もパワフルなテキスト生成モデルであった。15億という非常識なパラメータを持ち、transformerモデルの進化に大きな足跡を残した。

AI Dungeonは、ひねりを加えた古典的なダンジョンクローラーだ(※訳註5):そのダンジョンマスターは、実のところ、プレイヤー自身によって選択された冒険のストーリーに関するテキストでファインチューニングされたGPT-2であった。

GPT-2の訓練はデータサイエンスの歴史的偉業だ。それを使ってダンジョンクローラーを構築することは 機械学習エンジニアリングの偉業である。

以上に挙げたプラットフォームはすべてデータサイエンスの肩の上に立っている。これらのプラットフォームは、タスクのためにモデルを訓練できなければ機能しない。しかし、これらのモデルを現実世界の問題に応用するためには、アプリケーションに組み込む必要があるのだ。

別の言い方をすれば、機械学習エンジニアリングとは、データサイエンスのイノベーションが機械学習の研究の外で顕在化する方法なのだ。

しかしながら、機械学習エンジニアリングが提示する中心的な課題は、機械学習エンジニアリングが全く新しいカテゴリーの工学的問題を導入することであり、そうした問題について私たちはまだ簡単に答えられないのだ。

(※訳註5)AI Dungeonは、こちらから実際にプレイできる(ただし英文表示)。また、同ゲームの技術的背景に関してはAINOW翻訳記事『ディープラーニングはもう難しくない』を参照のこと。

機械学習エンジニアリングには何があるのか

高レベルでは、機械学習エンジニアリングとは、訓練されたモデルを取得し、生産的アプリケーションを構築するために必要なすべてのタスクを指していると言える。

(※訳註6)以上のデータサイエンスと機械学習エンジニアリングの違いを視覚化した模式図では、両者のタスクを以下のようにまとめている。

画像出典:翻訳者が作成

機械学習エンジニアリングのタスクをより具体化するために、簡単な例を挙げてみよう。

機械学習を駆使したダンジョンクローラーであるAI Dungeonに話を戻そう。このゲームのアーキテクチャはシンプルだ。プレイヤーがテキストを入力し、ゲームがモデルを呼び出し、呼ばれたモデルがレスポンスを生成し、ゲームがそれを表示する。このプロセスを構築する明白な方法は、モデルをマイクロサービスとして実装することだ。

理論的には、AI Dungeonの実装は他のWebサービスのそれと似ているはずだ。モデルをFastAPIのようなAPIでラップし、Dockerでコンテナ化し、Kubernetesクラスタに実装し、ロードバランサ―を使って公開する。

(※訳註7)上図は、本記事著者のKaiser氏が開発に関わる機械学習エンジニアリング支援プラットフォームCortexのアーキテクチャ図。データサイエンスではなく、伝統的なソフトウェアエンジニアリングの設計思想に則って構築されている。

実際には、GPT-2の実装は複雑である。

  • GPT-2は巨大だ。完全に訓練されたモデルは5GBを超える。それを提供するためには、大規模なインスタンスタイプでプロビジョニングされたクラスタが必要だ。
  • GPT-2はリソースを大量に消費する。1つの予測でGPUを長時間ロックアップすることがある。低レイテンシを実現するのは難しく、1つのインスタンスでは一度に多くのリクエストを処理できない。
  • GPT-2 は高価である。以上に挙げた事実の結果、GPT-2を本番環境に実装する時、それなりのトラフィックがあると仮定した場合、多くの大規模なGPUインスタンスを実行することになり、コストが高くなる。

AI Dungeonのリリース後すぐに100万人以上のプレイヤーがプレイしたことを考えると、以上の問題はより深刻になる。

効率的に駆動するAPIの記述、GPUインスタンスを用いたクラスタのプロビジョニング、コストを最適化するためのスポットインスタンスの使用、推論ワークロードのためのオートスケーリングの設定、モデルを更新するたびにAPIがクラッシュしないようにローリングアップデートを実装するなど、多くのエンジニアリング作業があるのだが、これらは機械学習のシンプルな応用だ。

多くの機械学習アプリケーションに共通して必要とされる機能としては,トレーニング,モニタリング,マルチモデルのエンドポイント,バッチ予測などがあるが,それぞれの機能が複雑さのレベルを大きく引き上げることになる。

これらの問題を解決するのが機械学習エンジニアの(組織によっては機械学習プラットフォームチームと連携して行う)仕事であり、機械学習を扱うためのツールのほとんどが機械学習エンジニアリングではなくデータサイエンスのために設計されているという事実によって、彼らの仕事は非常に難しくなっている。

幸いなことに、機械学習エンジニアリングにまつわる困難さは変わりつつある。

私たちは、データサイエンスではなく、機械学習エンジニアリングのためのプラットフォームを構築している

数年前、私たちのまわりにいた何人かがソフトウェアエンジニアリングから機械学習エンジニアリングに移行した。データサイエンスのワークフローをハックしたり、機械学習アプリケーションを動作させるためのグルーコードを書いたりして数週間を過ごした後、私たちはソフトウェアエンジニアリングの原則を機械学習エンジニアリングにどうやって応用できるかを考え始めた。

例えば AI Dungeon を見てみよう。このアプリの開発者がGPT-2を介さない通常のAPIを構築していたとしたら、Lambdaのようなものを使って15分でAPIを立ち上げることができただろう。しかし、GPT-2 を提供するには 機械学習固有の課題があるため、ソフトウェアエンジニアリングによるオーケストレーションツールは機能しない。

しかし、ソフトウェアエンジニアリングの原理原則を機械学習エンジニアリングに応用すべきではない理由はあるのだろうか。

そこで私たちは、機械学習エンジニアリングのためのツール、つまりソフトウェアエンジニアリングの原理を機械学習に応用するツールの開発に着手した。当社のオープンソースAPIプラットフォームであるCortexは、機械学習エンジニアが、ソフトウェアエンジニアなら誰もが知っているインターフェースを使って、モデルをAPIとして実装することを可能な限り簡単にしている。

画像出典:Cortex repo

機械学習を意識したAPIプラットフォームは、AI Dungeonをはじめ、上記に挙げた他の機械学習スタートアップがモデルを実装する際に使用されていたものである。そのプラットフォームの背後にある設計哲学、そしてCortexでのすべての仕事は、非常にシンプルだ。

私たちは、機械学習エンジニアリングの課題を、データサイエンスではなく、エンジニアリングの課題として扱っている。

機械学習APIプラットフォームでは、バージョン管理が難しく、隠れた状態に依存し、任意の実行順序が可能なノートブックの代わりに、YAMLとPythonファイルを使用する。「デプロイ」ボタンのあるGUIの代わりに、実際に実装を管理できるコマンドラインインタフェースを構築した。

以上のようなCortexの設計哲学は、機械学習を本番環境で使えるようにするために取り組むべき多くの課題に対して応用することができるのだ。

例えば、再現性は機械学習だけの課題ではない。これはソフトウェアエンジニアリングの問題でもあるが、私たちはバージョン管理を使って解決している。そして、Gitのような従来のバージョン管理ソフトウェアは機械学習には通用しないが、その原則を応用することはできる。DVC (Data Version Control) は、Git のようなバージョン管理を学習データ、コード、そしてその結果として得られるモデルに応用することで、まさに機械学習モデルのバージョン管理を実現している(※訳註8)。

画像出典:DVC

(※訳註8)DVCの詳細は、公式サイトを参照のこと。

モデルを初期化して予測値を生成するために必要なボイラープレートやグルーコードのファイルはどうするのか?ソフトウェアエンジニアリングでは、このためのフレームワークを設計する。

最後に、Cortexの設計哲学は機械学習エンジニアリング全般でも見られるようになってきている。例えば、Hugging FaceのTransformerライブラリは、大部分の一般的なtransformerモデルのために簡単なインターフェースを提供している(※訳註9)。

画像出典:Hugging Face

(※訳註9)Hugging Face社が提供するTransformerライブラリは、こちらのGitHubリポジトリから利用できる。

以上の画像に書かれている6行のPythonコードを使えば、最も強力なテキスト生成モデルの1つであるGPT-2から予測値をダウンロードし、初期化し、提供することができる。この事実は、成熟した資金力のあるチームでさえ3年前にはできなかったことを、6行のPythonコードで実現することができることを意味する。

機械学習エンジニアリングのエコシステムに私たちが参加しているという事実を超えて、このエコシステムに興奮するのは、機械学習に関する数十年にわたる研究と、人々が日々直面している問題との間の架け橋になっているからだ。機械学習と現実世界の問題を架橋するプロジェクトが機械学習エンジニアリングの障壁を取り除くたびに、新しいチームが機械学習を使って問題を解決するのがより簡単になるのだ。

将来的には、機械学習はすべてのエンジニアのスタックの一部になるだろう。機械学習が触れない問題はほとんどなくなるだろう。機械学習がソフトウェアエンジニアにとって当たり前となるまでのペースは、Cortexのようなプラットフォームをどれだけ早く開発し、機械学習エンジニアリングの普及を加速できるかにかかっている。

もし機械学習エンジニアリングの普及があなたにとっても刺激的であれば、私たちは常に新しいコントリビューターを歓迎しています。


原文
『Moving from data science to machine learning engineering』

著者
Caleb Kaiser

翻訳
吉本幸記(フリーライター、JDLA Deep Learning for GENERAL 2019 #1取得)

編集
おざけん

無料メールマガジン登録

週1回、注目のAIニュースやイベント情報を
編集部がピックアップしてお届けしています。

こちらの規約にご同意のうえチェックしてください。

規約に同意する

あなたにおすすめの記事

生成AIで“ウラから”イノベーションを|学生起業家が描く、AIを活用した未来

特許技術×AIでFAQを次のステージへ|Helpfeel

GPUの革新からAI時代の主役へ|NVIDIA

あなたにおすすめの記事

生成AIで“ウラから”イノベーションを|学生起業家が描く、AIを活用した未来

特許技術×AIでFAQを次のステージへ|Helpfeel

GPUの革新からAI時代の主役へ|NVIDIA