Shunya Ueta

機械学習システムの信頼性を数値化し、技術的負債を解消する論文「 The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction」

[抄訳] What’s your ML test score? A rubric for ML production systemsで紹介した論文の続編があったので読んでみました。

Change log

Citation

Eric Breck, Shanqing Cai, Michael Salib, . The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. In 2017 IEEE International Conference on Big Data (Big Data) (pp. 1123-1132). IEEE.

大規模なオフラインの機械学習実験は注目されているが、反対にオンラインでの信頼性がある機械学習システムの開発は難しく、技術的負債が溜まりやすい

図1 では、左側が伝統的なシステムのテストとモニタリング、右側は、機械学習システムのテストとモニタリングである 機械学習システムのテストとモニタリングが複雑になる要因として、コードだけではなく、動的に決定されるデータの質とモデルの多種多様な設定に依存するからである

Figure 1 in paper

TL; DR;

TEST FOR DATA AND FEATURES

TESTS FOR MODEL DEVELOPMENT

TESTS FOR ML INFRASTRUCTURE

MONITORING TESTS FOR ML

あなたの機械学習システムが、リリース時に正しく動いたかどうかだけではなく、機械学習モデルが正常に稼働し続けることを把握することは非常に重要です。 標準的なアプローチとしては、ダッシュボードを作成し、関連するグラフや統計情報を可視化し、確認できるようにします。そして、その値が大きく動いたときには自動的に担当のチームにアラートが飛ぶようにします。 機械学習システムでは、サービングシステム、学習パイプライン、入力データの監視が非常に重要です。 また、インシデントの対応として機械学習システムが主に行うのはシステムのロールバックではなく、モデルのロールバックである。

文化の変化

技術的負債は定量化が難しい。また負債を返済するための優先順位付けもやどれくらい改善されたかの測定も難しい。ここで提案した試験項目は定量化した機械学習のテストスコアを提供する。これは、測定可能かつ改善可能なものである。 この指標は、機械学習システムの開発者はどこを改善すればより信頼性のある機械学習システムを作ることができるかのガイドラインとなる。この方針は Google の Test Cerfiedの仕組みを基に発案され、信頼性向上のためのはしごを提供する。

なぜ最小の値を選択する理由として、全ての章が重要であり、すべての章を考慮したスコアを計算するべきだからである。また全てのテスト項目は同一の価値を持つ。 以下に、ML Test Score からその機械学習システムがどのレベルに達しているかの説明を示す

ポイント説明
0プロダクションレベルというよりも、研究プロジェクトの一種
(0,1]総合的にテストはされていないが、可能な限り信頼性向上に努めている
(1,2]基礎的なプロジェクトの要求事項は通過した。しかし、信頼性向上のためのさらなる投資が必要とされる
(2,3]適切なテストがされている、だが更に自動化の余地が残っている
(3,5]信頼性の高い自動化されたテストとモニタリングレベル。ミッションクリティカルな状況でも問題はない
>5卓越したレベルの機械学習システム

Rubic の現実世界の機械学習システムへの適用と実際に起きたこと

我々は Google 内部の機械学習に携わるチームのために ML Test Score Certified Program を開発した。 36 チームにインタビューや Rubric を通じた評価を行い、その統計値を以下の図にまとめた。 Figure 4 in paper

Rubric の重要性

Google 内の事例では、グローバル・サービスがローカライズされた際に、特定の単一の国に対して粗悪な予測を提供していないかどうかのチェックリストとして役立ったり、各機械学習システムの評価の標準化の普及に役立った。最終的に ML Test Score が普及をしていく中で、あるチームは training / serving skew の危険性を認識し、特徴生成の部分にテストを実施したり、手動テストを自動テストに切り替えていったりしていきました。

依存性の問題

機械学習システムのデータの依存性の問題として、開発チームが Upstream サービスから提供されるデータの完全なる理解のオーナーシップを失ってしまう傾向もあります。

フレームワークの重要性

結合テストは、サービングシステムには適合されていることが多いが、学習パイプラインに適用されていることは稀である。それは、アドホックなスクリプトや手動実行に依存している部分が多いからである。

モデルのカナリリリース(Infra 6) は、頻繁に多くのチームで既に実装されていた。だがカナリリリースに面白い２つの興味深い問題が浮き彫りになった。

おそらく、一番重要かつ、最も実装されていないテストの一つがtraining / serving skew (Moniro 3)だ。実際この問題は非常に発見が難しいが、TFX などのフレームワークによりこの課題を解決可能である。

Rublic の評価検証

Google 内で開発チームに対して、この指標が有用かそうでないかの評価を行った。 興味深い結果として、画像や音声のみを扱うチームは Data の章は多くの部分が適切ではないと答えた。 だが、人的検査やLIMEなどの解析は音声・画像のみのデータでも重要だと確認できた。 例えば、そのような検査は分布の不均衡や不確かな影響を受けている学習データを明らかにした。

教師あり学習は、ラベル付きデータを必要とする。しかし、特定のドメインではそもそもデータセットが手に入らなかったり、取得コストが非常に高い。 あるグループはとても巨大で多様性があるデータセットを所有しており、人力でラベルを付けていくことは不可能に見えた。彼らは、ヒューリスティックなシステムを構築して、それを活用して機械学習モデルを構築しました。（機械学習の専門家はこの学習モデルは狂っていてうまくいくわけがないと言っていました）

実際にヒトが評価を行ってみるとヒューリスティックシステムの性能は一貫して良いが、そこから学習した機械学習システムのほうが更に良かった。しかし、ここで基本的なヒューリスティックシステムに対する指標を我々が用意できていないことが露呈した。ラベリングコストが高いことは、学習モデルの定量的評価も難しいことを意味し、Model4, Infra 4の検査も困難になる。

  1. https://pair-code.github.io/facets/ ↩︎

  2. https://research.google/pubs/pub46484/ ↩︎

---

関連しているかもしれない記事


📮 📧 🐏: 記事への感想のおたよりをおまちしてます。 お気軽にお送りください。 メールアドレス入力があればメールで返信させていただきます。 もちろんお返事を希望せずに単なる感想だけでも大歓迎です。

このサイトの更新情報をRSSで配信しています。 お好きなフィードリーダーで購読してみてください。

このウェブサイトの運営や著者の活動を支援していただける方を募集しています。 もしよろしければ、Buy Me a Coffee からサポート(投げ銭)していただけると、著者の活動のモチベーションに繋がります✨

#paper #translation #machinelearning #mlops