Skip to Content

抄訳 Towards ML Engineering: A Brief History Of TensorFlow Extended (TFX)

この記事はMLOps Advent Calendar 2020の25日目の記事です。(盛大に遅れました)

KDD2019の招待講演でGoogleがTFXの歴史について発表されており、TFX信者の自分としては発表内容が以前から気になっていたが、公開はされておらずなんとかして見れないかな~と思っていましたが、TensorFlowのBlogで該当の招待講演が論文化されたことを知ったのでメモがてら抄訳として残しておく。

  • 注意)この翻訳記事は原著論文の著者陣からレビューはされていません
  • Shunya Ueta, are providing a translation and abridgment, which has not been reviewed by the authors.

Citation


Karmarkar, A., Altay, A., Zaks, A., Polyzotis, N., Ramesh, A., Mathes, B., … & Li, Z. (2020). Towards ML Engineering: A Brief History Of TensorFlow Extended (TFX). arXiv preprint arXiv:2010.02013. ***

TFXを知らない方向け

TFXとは、Googleが開発するTensorFlow Extended(TFX)の略称で、Google社内で開発されたTensorFlowを基にした機械学習基盤のプロジェクト。 TFXの各コンポーネントはOSSとして公開されている。

抄訳

Abstract

ソフトウェアエンジニアリングは成熟しつつあるが、一方で機械学習エンジニアリングはまだ成熟しきっていない。この論文ではAlphabetで成功しているエンドツーエンドの機械学習基盤である Sybil, TFXの紹介を行う。主にTFXが機械学習エンジニアリングの実現にどう役立つかについて紹介していく。そして我々は機械学習による恩恵を受けるために、まずは機械学習チームの成熟と強固なインフラストラクチャ、組織内での教育活動が同時に必要であることを主張する。また、先進的なモデル開発を行う前に、容易に相互運用可能な機械学習基盤導入を強くすすめる。

Where We Are Coming From

Sibyl 2002-2020

2007年からSibyl は運用開始されており、2020年まで運用されていた。最近では開発は廃止され、TFXに移行中であり、主に非深層学習をサポートする機械学習基盤である。

TFXと同等のミドルウェアであるData Ingestion, Data Analysis and Validation, Training (of course), Model Analysis, and Training-Serving Skew Detectionを解決するコンポーネントが存在している。

(といってもSibylはTFXの先祖みたいなものなので、TFXがこれらの機能を踏襲してると考えるのが正しそうですね)

TFX (2017 - ?)

2015年からは深層学習の台頭により、TensorFlow がリリースされた。TensorFlowの課題点としてエンドツーエンドの機械学習基盤としては提供されてはいないことである。Sibyl は逆に深層学習用途に対する柔軟性が足りていないのが欠点であり、それらを補うためにTFXの開発を開始したのは2017年のことだった。偶然にもTFXはSibyl 誕生から約十年後に開発されことになった。

TFXの運用開始から3年、Alphabet内でTFXは企業レベルの機械学習基盤として数千のユーザーから使われており、数百のAlphabet (GCP含む) の機械学習プロダクトを支えている。毎日数千のTFXのパイプラインが稼働し、エクサスケールのデータとともに数万ものモデルが生み出されており、TFXが提供する推論のリクエスト数は秒間数百万超えの規模になっている。TFXによりAlphabet内の研究成果がより早くプロダクションにリリースされ、機械学習基盤の開発よりもモデル開発に集中することが可能になった。

TensorFlow がAlphabet内部、そして外部でも人気と衝撃を与えたのと同じく、機械学習エンジニアからTFXにも人気と衝撃が走った。外部の機械学習エンジニアからの要望を叶えるために我々はTFXを徐々にOSSで公開していった。TFX, sibyl はGoogle内部の強固なインフラストラクチャから構成されており、そのおかげでOSSでの公開が加速した。例えばSibyl はMapReduceとFlumeを使ったデータ処理を行っており、TFX は同じくポータビリティ性の高いApache beamをベースにしているのでOSSでの公開がスムーズに進んだ。

TFX は最終的に2019年の頭にOSSとして公開され、オンプレスミスやGCPのCloud AI Platform Pipelinesなどで活用可能になった。パートナー企業もTFXを活用し始めており、実践的な機械学習の開発速度が改善されはじめている。

参考文献: The Winding Road to Better Machine Learning Infrastructure Through Tensorflow Extended and Kubeflow

Lessons From Our 10+ Year Journey Of ML Platform Evolution

Googleでの機械学習基盤の進化の旅は長くそしてワクワクするものであり、ぜひとも我々が学んだことをここで共有したい。

我々が学んだことは大きく2つに分類される。

この長い旅で

  1. 何が変わり
  2. 何が変わらなかったのか

だ。Sibyl とTFX の開発を通じで学んだことを共有するが、Google外部での機械学習基盤開発にも適用可能だと我々は信じている。

What Remains The Same And

何が変わらず、そしてなぜそれが残ったのか この章ではSibyl, TFX の両者の長期間の運用期間にも耐えることができた機械学習とインフラストラクチャの観点についてまず説明を行う。

Applied ML

Rules of Machine Learning というGoogle内部での機械学習プロダクト開発で学んだ経験則を我々は公開している。

Rules of Machine Learning の一例

  1. シンプルなルールベースとヒューリスティックから開発をまずはじめ、そこからデータを生み出し学びを深めよう。基本的にはここでルールベースのサービングシステムを開発する。
  2. 次に単純な機械学習モデルに移行することで、大きな利益を実現させます。ここでやっと機械学習パイプラインが導入される。
  3. 特徴量を増やし機械学習モデルも先進的なものを適用してみる。
  4. SOTAを達成した機械学習モデルを適用してみまる(管理コストは増大しパイプラインも複雑になるが、それに見合った価値があることが前提である。)
  5. 上記のサイクルを念頭に置いて機械学習プロダクトの開発に役立ててみよう。そして常に費用対効果(ROI)は忘れないようにするのが大事である。

我々はRules of Machine Learning がたとえサービスドメインや稼働する基盤が異なったり、時間が経過したとしても揺るぎない価値があると信じている。特に機械学習エンジニアリングの観点においてRules of Machine Learning は我々とその読者の致命的な失敗を避ける助けになると信じており、TFX は上記の流れを極めて高速に試行するのに役立つ。

The Discipline Of ML Engineering

Rules of Machine Learning の作成を通じ、我々はソフトウェアエンジニアリングを基にした複雑なコードとデータの処理が実行可能な頑強なシステムの理念を学んだ。ここで我々は機械学習エンジニアリングを以下のように定義する。

  • 機械学習エンジニアリングの定義: ソフトウェアエンジニアリングを包含する形での実践的な機械学習の複雑性を制御するための学問

実際、機械学習エンジニアリングのすべてをまとめようとするのは、なかなか難しいが

  • 我々の持っている限られた理解していることは、プラットフォームと時間を超えてうまく稼働している
  • 過去から学び、相似のものとしてみなすことは強力なアプローチであり、ソフトウェアエンジニアリングの様々な視点は、機械学習エンジニアリングにより機械学習プログラミングをどう進化させれるかが分かる

参考書籍: Software Engineering at Google: Lessons Learned from Programming over Time

TFXに関する基礎的な考えは、TFX: A TensorFlow-Based Production-Scale Machine Learning Platform にて公開されており、現在 ML metadata を軸にしてOSSとして公開されている。

では、これから機械学習エンジニアリングの基礎的な要素について、ソフトウェアエンジニアリングとの相似を基に説明を行う。

Data

ソフトウェアの中心がコードであるように、データは機械学習の中心的な存在である。データマネジメントはプロダクション環境での機械学習適用において挑戦的な課題である。

参考文献: Data Management Challenges in Production Machine Learning

まずはデータに対するユニットテストを考える。ユニットテストはコードがどのように振る舞うべきかを検証する。同様に、データ形式への明示的な期待(スキーマ、不変量や分布)を設定し検証を行うことができる。

参考文献: Data Validation for Machine Learning

コードリポジトリとバージョンコントロールは、コード管理の軸となっている。。データ管理を行うことができるシステムはまた機械学習エンジニアリングでも同様に重要である。TFXの ExampleGen, StasticsGen, SchmaGen とExample Validator の各種コンポーネントにより継続的な機械学習パイプラインのデータ管理、分析、検証が可能になりデータをコードのように扱うために非常に役に立つ。

参考文献: TensorFlow DataValidation , The ExampleGen TFX Pipeline Component

Models (機械学習モデル)

ソフトウェアエンジニアがコンパイルされたコードを作成するのと同じように、機械学習エンジニアは、データとコードを基に「コンパイル」された機械学習プログラムを作成する。コンパイルされたものが、一般的には機械学習モデルとして知られている。この2種類のプログラムの性質は大きく異なっている。ソフトウェアはプログラムを通して一貫性を保つが、機械学習モデルは一貫性を保つことが非常に難しい。またこの一貫性の検証は何かしらの要約された形式でしか検証できない。(例えばラベルデータの部分集合で十分な精度が出ているなどの形でしか機械学習モデルの一貫性の保証ができない)

コードとデータは時間経過により変化し、モデルもそれに伴い変化する。しかし、モデルの変化はコードやデータの変化に比べて更に複雑になる。例えば、コードに対する高いテストカバレッジはコードの一部の正しさと変化に対する高い信頼性を得ることができるが、モデルに対するテストでは、分布外のデータや因果関係を理解できるデータを作成しテストすることはとても困難である。

同じく結合テストでも同じ問題が発生し、end-to-end でのモデルの検証と理解が機械学習エンジニアリングの重要な構成要素である。

参考文献: Slice Finder: Automated Data Slicing for Model Validation

TFXのevaluator とInfraValidator コンポーネントはモデルの検証と理解についての機能を提供する。これらもまた機械学習エンジニアリングの大事な一要素である。

The Evaluator TFX Pipeline Component

Mergeable Fragments

ソフトウェアエンジニアがプログラムを既存のパッケージを合わせて作成するのと同じように、機械学習エンジニアはコード、データ、解析、モデルの断片を合わせて機械学習パイプラインを構築する。ソフトウェアエンジニアリングと機械学習エンジニアリングの決定的な違いは、コードは不変だが、データは常に揮発性を持ってり、変化する点である。(基本的にデータは常に新しくなり続ける)。例えば、入力データの一部分でも傾向が変化した場合には、それに対応して新しいモデルを作成する必要がある。

このように作成される生成物は常に mergeable (併合可能) であることは、機械学習パイプラインにおいて重要である。例えば一つのデータセットの統計値の要約は、2つのデータセットの和集合の統計値を簡単に要約できるように、もう一つのデータセットへ簡単に併合可能であるべきである。またモデルの観点から言えば、一つのモデルの学習を別のモデルへと簡単に転移学習できるようにしておくべきである。

しかしこれは前章で述べたモデルのテストカバレッジと同じ課題を抱えている。新しくモデルにフラグメントをマージすると、分布外データや反実仮想の評価データの作成が必要になる可能性があり、それによってモデルの複雑性があがってしまう。

TFXの Example Gen, Transform, Trainer, Tuner のコンポーネントはTensorFlow Hub で管理され、併合可能なパイプラインを作成することに役立ちます。

Artifact Lineage (生成物の経路追跡)

ソフトウェアエンジニアリングは方法論やツールなどが高度に発展しているが、それでも常にデバッグが必要である。それは機械学習プログラムも同様の課題があるが、ソフトウェアエンジニアリングと比べると一段と難易度が増す。なぜなら、機械学習プログラムではプログラムに付随する生成物が難易度への影響を与えている。モデルのデバッグを行う際にコードの欠陥、学習アルゴリズム、学習データ、サービングパス、サービングされるデータなどいくつものエラー原因があり、それらが原因で精度の低下につながる。ソフトウェア開発において、根本原因を探すためにスタックトレースが重要なように、機械学習パイプラインではすべての生成物の生産と消費の追跡が機械学習モデルの精度劣化の根本原因の解明に役立つ。

TFXではML Metadata (MLMD) を使用して、生成物を管理している。MLMDは、生成物のメタデータ管理と追跡を可能にし、機械学習パイプライン外に高い信頼性を持って生成物の管理が可能になる。

Continuous Learning And Unlerning

プロダクション環境下での機械学習パイプラインは、動的な環境下で以下の特徴がある。

  • 定期的に新しいデータが到来する
  • モデルのコードは、初期段階では頻繁に変化する
  • インフラ面も変化する

もし上記の変化が発生した場合、パイプラインはそれらに対して追従する必要があり、変更後の環境でパイプラインを新たに実行する必要がある。パイプライン実行の監視は、デバッグと原因究明の解析にとても有用である。例えば単純な例では、モデルの失敗原因をデバッグするためには、どのデータが学習済のモデルに使われたかだけではなく、モデルコードとパッケージのバージョンの把握が必要不可欠である。

機械学習パイプラインはそれらの変化に対して対応できる仕組みが必要である。例えば新しいデータが到来した際には、モデルの再学習が必須である。これらは推薦システムや広告関係などのように迅速に変化する環境においてごく自然に要求される。もしデータが頻繁かつ定期的に変化する環境だった場合、エンジニアが手作業でモデルの再学習を実行することが要求されているならそれは非現実的である。その代わりにTFXはパイプラインが新規のデータを検知して、モデルの再学習を行うことで継続的学習を実現し、手作業を自動化することができる。その自動化を実現するためには高度なオーケストレーションが必要である。また機械学習パイプラインは、何年間もコードとデータを取り込み、継続的に意思決定に役立つ予測を行うモデルを作成するのが一般的である。

参考文献: Continuous Training for Production ML in the TensorFlow Extended (TFX) Platform

次に機械学習パイプラインのために必要とされる仕組みの例では、backfilling 機能がある。例えば、モデルのパッケージやコードは更新済のものを既存のデータに適用するケースなど、エンジニアはコンポーネントが更新された状態でパイプラインを実行する必要があるかもしれない。次のbackfillingが必要となる状況例として、データ関連の問題を解決するために、既存のデータの新しいバージョンに対してパイプラインを実行することが考えられる。これらのbackfill は継続的学習のために直交である必要がある。実例では、エンジニアは手作業で学習ジョブを実行可能であり、モデルが生成後、そのモデルは自動的にモデルの評価と検証が実行が可能である。

The TFX User Guide ではまだ継続的機械学習パイプラインを公開できていないが、この公開に向けて我々は動き続けている。 参考: RFC: TFX Advanced DSL semantics #253

Infrastructure

Building On The Shoulders Of Giants

野心的な目標実現のために、強固な基盤を作る必要がある。TFXは Sibyl のシステムデザインの多くを再利用を行った。

  • Sibyl のアルゴリズムとワークフローは MapReduceを基に実現されていたが、TFXはTensorFlow, Apache Beamを使って、分散学習とデータ処理のワークフローを実現した
  • Sybylはカラムベースのデータ管理を行っていたが、Apache arrow によりインメモリでのカラムベースのデータ管理に適合した。

また、頑強な標準化が進んでいる箇所では、依存性をあえてもたせることによりTFXとその使用者にパフォーマンスとスケーラビリティを提供することに成功した。例えば、TFXの依存先でもあるKubeflow PipelinesApache Airflow はそれらを使用する利益が依存先の管理に勝ると判断されたので選択されました。

Interoperability And Positive Externalities

機械学習基盤は孤立した環境で運用されるのではなく、既存のデータ基盤からのETLやシステムへのモデルのデプロイなどの相互運用を意識する必要がある。

  • Google AdsでSibyl が相互運用されていたのと同じく、TFXでは複数のサービスからのデータのETL、サービングが複数の開発環境やデバイスに提供している
  • Sibyl でGoogle社内技術で相互運用されていたのと同様に、TFX は Apache BeamApache FlinkApache Spark のクラスターやGoogle Cloud Dataflow などのサーバーレスデータ処理を実行するために活用されている
  • TFXはオーケストレーション機能の抽象化をMLMDを用いて実現しApache Airflow, Apache Beam, Kubeflow Pipelines も選択肢の一つとして採用できるようにしている

上記で説明したように、運用が簡単になるような技術群を採用しており既存のデータ基盤との接続や、サービングなどがAlphabet 外でも容易に構築可能になっている。

また複数の技術の組み合わせは指数関数的に開発環境の設定が増加するため、マネージドサービスである Could AI Platform Pipelines も提供を開始した。

What Is Different And Why

ここでは、TFXを現実的な問題に適応するために変化させた部分を説明する。

Environment And Device Portability

Sibyl はGoogle での大規模クラスタである Borg へのデプロイを前提にデザインされていた。当初、Google での機械学習適用についてこれで問題なかったが、世界的に機械学習技術の発展に伴い、Google 外部かつ大規模だけではない小規模な環境へのデプロイの必要性も高まった。その結果、ポータビリティが重視された機械学習基盤が必要になってきた(が厳密な一貫性を保つことももちろん要求される)。

  • Sibyl がGoogleのデータセンターでのみ動くが、TFXはラップトップ、ワークステーション、外部のデータセンター、クラウド上で実行することができる。特にGoogle Cloud では最適化と自動化されたTFXが提供される
  • Sibyl はCPUでのみ動くが、TFXは異なるハードウェア(CPU, GPU, TPU )で動く
  • Sibyl で作成されたモデルはサーバー上での実行のみ可能だが、TFXはラップトップ、サーバー、TensorFlow Serving, Apache Beam、モバイルやIOTでは TensorFlow Lite, ブラウザ上では TensorFlow JSによって実行可能である

小規模から大規模な問題を解くために、TFXのポータビリティ性は洗練され多種多様な環境、デバイスでの実行を可能にしている。

だがポータビリティはコストも高くなってしまう。メンテンスを行う際に、環境固有もしくはデバイス固有の特殊な要求を満たす必要があり、環境やデバイスの数が増えるとそれらは超線形にコストが増加する。が、一般の使用者はそれらのメンテンスコストは意識せずTFXを使用することが可能です。

Modularity And Layering

Sibyl は既存のプロダクトと密結合され、モノリシックに構成されており、既存の仕様に把握して、それに合わせる必要があった。対象的に TFX はモジュラー化とレイヤー化が意識されたアーキテクチャ設計になっており、チーム間で連携しつつ開発を行えるようになっている。

TFX のレイヤーデザイン

TFXのレイヤーアーキテクチャは、使用者の必要性に合わせて、開発者にはライブラリから、パイプライン、エンドユーザー向けにはML Service などを提供可能にしている。

Multi-faceted Flexibility

Sibyl は開発当初は他の利用可能なツールに比べると、柔軟性があったが機械学習ワークフローの高速化の需要に答えることができなかったこともTFXの開発に繋がった。

  • Sibyl は特定のデータ解析しか提供していなかったが、TFX は TensorFlow DataValidation により柔軟なデータ分析が可能になっている
  • Sibyl は特定のmappers しか提供していなかったが、TFXはTensorFlow Transform により、カスタマイズ可能な柔軟性に長けたmappers, analyzers が使用可能になっている
  • Sibyl は非深層学習のみサポートしていたが、TFXはTrainer Component によりTensorFlow ベースのモデルを提供可能になっており、TensorFlow Hub などで転移学習なども容易に行えるようになっている
  • Sibyl は非深層学習モデルに対する自動的な特徴量の組み合わせ(feature conjunction) のみ提供していたが、TFX では Tuner component によりstate of the art ベースのハイパーパラメータチューニングが利用可能になっている
  • Sibyl は特定のモデルの解析手法しか提供していなかったが、TFXは TensorFlow Model Analysisにより、Evaluator Component をベースにビルトインのメトリクスなど多様なモデル解析手法を提供している
  • Sibyl は 固定されたパイプラインしか扱えなかったが、TFXはカスタムコンポーネントが使用可能であり、柔軟にパイプラインを設計可能である

Where We Are Going

2020年において、TFXの開発はroadmapRFCContribution guideline を基に進めています。我々は応用機械学習の普及のために、機械学習エンジニアリングのさらなる発展に尽力し、responsible AI (TensorFlow を用いた高い信頼性を持つ機械学習開発のための方法論)をGoogle のAI原則論 に基づき実世界へ適用していく。

Drive Interoperability And Standards

相互運用性を高め、我々は原則論である、社会に利益をもたらすことを意識していく。我々のミッションとして、我々はOSSによる先進的な機械学習システム構築をサポートし、機械学習による生成物の標準化も行っていく。例えば具体例として上げると

  • TFX standardized input
  • TFX DSL semantics, Data model and IR
  • 標準化された機械学習生成物とメタデータ
  • 多様な実行環境での分散実行環境の標準化
  • 分散かつストリーミングでのモデルの推論
  • モバイルやエッジでの相互運用を意識した改善
  • 相互運用を意識した機械学習フレームワークの改善

Increase Automation

自動化こそ、高信頼性のプロダクションシステムの柱となる考えであり、TFXは自動化にとてつもなく投資を行っている。我々の原則論である”安全のためのビルドとテスト”、””

TFX pipeline では開発が進むことで、 TFX Tuner によるモデルの自動改善や、教師あり学習のモデルの多次元でのスライスでの挙動の自動検知、Model Cards の自動生成もサポート、training-serving skew の自動検知も開始された。GCPでのTFXは先進的な機能が提供されていく。

Improve ML Understanding

機械学習を理解することは、プロダクション環境下に機械学習を適用する際に重要な側面の一つである。機械学習を理解するためにはモデル作成に付随する生成物の追跡( lineage) は最も重要事項の一つである。struct2tensor (TensorFlow内部の構造化データのパーシングライブラリ)は構造化データにおいて、学習やサービング、解析においてより役立つTFXの技術の一つである。

Uphold High Standards And Best Practices

高水準の標準化とベストプラクティスの共有のために、TFXチームはこれからも科学的論文の執筆・公開を継続していくことでAlphabet 外にもこのベストプラクティスが普及することを狙っていく。AutoML pipelinesのベンチマークツールとしてNitroMLも再現性の鍵の一つとなる。

Improve Tooling

TFXは機械学習エンジニアリングと機械学習ライフサイクルのいくつもの段階のためのツールを提供しており、いまだこの領域は黎明期であることを願っている。

大規模かつ重要度が高いストリーミングかつレイテンシーが要求されるデータは挑戦的な課題である。TFXではApache Beamと Cloud Dataflowの実行によりストリーミングイベントにも対応した予測を実行可能になっている。我々はこの枠組みをTensorFlow Serving でも同等のことが行えないか計画している。

更に、たくさんのツールが機械学習ワークフローでもまだ自動化が必要とされているものが多い。例えば、機械学習パイプライン実行時に、そのジョブの結果が現行のモデルよりもパフォーマンスが低いことを積極的に予測しジョブの実行を停止することで、大幅なリソースと実行時間の削減が期待できる。

A Joint Journey

TFXの構築は、機械学習エンジニアリングの基礎の探索でもあり、多くの人々の長年の努力の累積である。

さあ、我々もあなたを"機械学習エンジニアリングに向けた” 旅に招待します。

See Also