TFX: A TensorFlow-Based Production-Scale Machine LearningPlatform 読んだメモ
Creating and maintaining a platform for reliably producingand deploying machine learning models requires careful or-chestration of many components—a learner for generatingmodels based on training data, modules for analyzing and val-idating both data as well as models, and finally infrastructurefor serving models in production. This becomes particularlychallenging when data changes over time and fresh modelsneed to be produced continuously. Unfortunately, such or-chestration is often done ad hoc using glue code and customscripts developed by individual teams for specific use cases,leading to duplicated effort and fragile systems with hightechnical debt.
↑を解決するGoogleの基盤TFX
TensorFlowベースの汎用機械学習プラットフォームであるTensorFlow Extended(TFX)
やったこと・改善点
- やったこと
- モデルを作るプラットフォームを作った(TFX)
- コンポーネントの標準化
- プラットフォーム構成の簡素化
- disruptionsを最小限に抑えるプラットフォームの安定性を実現
- 改善点
- 再利用性のない実装からの回避(技術的負債の軽減)
- 実験サイクルの高速化 数か月から数週間の生産時間の短縮
- データおよびモデル分析の改善によりアプリのインストールが2%増加
モデルを作るプラットフォームの複雑さとは
- Building one machine learning platform for many different learning tasks
- Continuous training and serving
- Human-in-the-loop
- UIを公開して,エンジニアが簡単にデプロイ・監視できるように
- データサイエンティストがデータとモデルを理解・分析するのを支援する必要性
- 新しいデータに対して合理的に動作するかどうかを予測することは困難である[8]
- Production-level reliability and scalability
- 一貫性のないデータ,ソフトウェア,ユーザーコンフィグによるdisruptions,および基礎となる実行環境の障害による失敗に対してreliable
- model validation, data validation:変な訓練データ,不良なモデルの検証
- 大量のデータ,サービスシステムへの運用トラフィックの増加にscalable
- 一貫性のないデータ,ソフトウェア,ユーザーコンフィグによるdisruptions,および基礎となる実行環境の障害による失敗に対してreliable
component詳細
data analysis (Sections 3.1)
特徴量に関する記述統計を出力する
データをセグメントを切って個別に見ることも可能
- バイナリ分類問題の正例,不例
- 特徴量ごとの相関,共分散
data transformation (Section 3.2)
特徴量のラングリングを可能にする
- vocabularies: feature-to-integer mappings
- など
訓練と予測で一貫性のある同じ変換ロジックを使わないとダメ
- エンコーダ系
モデルの一部として変換を出力することでこれを回避
data validation (Section3.3)
スキーマによるデータの異常検出
機能
- どんな異常が検出され,その範囲が一目でわかるようにする
- 各異常には,ユーザーがデータをデバッグおよび修正する方法を理解するのに役立つ簡単な説明が必要
- 特徴量の値が特定の範囲外であるという異常
- 予想される分布と実際の分布のKLの相違がしきい値を超えたという異常→これはデバックしづらい
- 適切にスキーマの変更を提案できるか(特徴料のドメインの変更)
- 新しいユニーク値の提案
- 範囲の増加
- 異常の文書化・追跡・報告がきちんとしたフォーマットで出力される
検出項目
trainer (Section 4)
すべてのトレーニングユースケースをサポートできるプロダクション品質モデルのトレーニングプロセスを合理化(および可能な限り自動化)する
warm-starting
これを活用してあまり多くのリソースを消費せずに高品質のモデルを実現
前提
実際には転移学習
the ability to selectively warm-start selected features of the network was identified asa crucial component and its implementation in TensorFlow was subsequently open sourced.
他にも,TensorFlowはさまざまな学習手法(ディープラーニング、ワイドアンドディープラーニング、シーケンスラーニングなど)を使用してモデルトレーニングを構成するための高レベルな統合APIを提供
High-Level Model Specification API
ベストプラクティスをエンコードする高レベルの抽象化レイヤーで実装の詳細を隠す
- FeatureColumns:ユーザーが機械学習モデルのどの機能に焦点を当てるのに役立つ
- Estimator:trainとevaluateが絶対にある
model evaluation and validation (Section 5)
- evaluation: ビジネスメトリックに対するオフライン評価
- データのセグメントを切って比較可能(country=USなど)
- validation: カナリアリリースによって品質をしきい値とベースラインモデルとの比較
いいモデルとは?
- モデルは安全に提供可能
- ロード時,または不良・予期しない入力がきたときに,クラッシュしたりエラーを引き起こさない
- ライブラリのバージョンなど
- あまり多くのリソース(CPUやRAMなど)を使用しない
- ロード時,または不良・予期しない入力がきたときに,クラッシュしたりエラーを引き起こさない
- モデルは一定以上の予測の品質を持つ
課題点:モデルの動作で予想される変化と予期しない変化を区別するのが難しい
メトリックの変化に保守的すぎると警告が増え,狼少年問題
→緩いしきい値に引っかかるものを警告すればバグは検知できるかも
ユーザはこの機能を欲しがってたわけじゃない(別にモデルの精度が上がるわけじゃないし,むしろ手間がかかる)
→基盤チームから出て来た機能
→実際に検証で防げたはずの問題に遭遇すると使われ始めた
serving (Section 6)
TensorFlow Servingの話
機械学習をサービングするためのカスタマイズ可能なフレームワークを提供することで,機械学習モデルのプロダクショングレードの提供システムを展開するために必要な定型コードの削減を目指す
プロダクションに乗せるために必要な要素 - lowlatency - high efficiency - horizontal scalability - reliability - robustness
Multitenancy with Isolation TF ServingにおいてのMultitenancy:複数の機械学習モデルを同時に提供可能にすること
model-isolation モデル分離
システムが新しいモデルをロードしているときに多数のクエリがきたら?
→モデルの読み込み操作用に分離された専用スレッドプールの構成を可能にする機能をTensorFlowに実装.呼び出し元が指定したスレッドプールで任意の操作を実行
今まで高負荷時にモデルロードが走った時のレスポンスタイムの99.9パーセンタイルのレイテンシは約500〜1500msecだったが,↑の機能により75~150msecに
Fast Training Data Deserialization ニューラルネットワーク以外のモデル(線形モデルなど)は、CPU集約型よりもデータ集約型 このようなモデルでは,データ入力・出力,前処理がボトルネックになる傾向
→汎用プロトコルバッファパーサーの使用は非効率的だった
→複数の解析構成でのさまざまな実際のデータ分布のプロファイルに基づいて,専用のプロトコルバッファパーサーを構築
2〜5倍の高速化に成功