今週のTOPIC

[blog] Temporal Python – A durable, distributed asyncio event loop

• tempralはよく使うデザインパターンのプリミティブを実装したSDKのようなもの

• 例えばworkerを使ったworkflowの実装が以下のようにサクッとかけたりするらしい

• リッチなUIとかも付けてくれるしい

• MLのworkflowを組むみたいな事例も
AI, ML, and Data Engineering Workflows with Temporal
AI and ML developers bump into the same rough edges of system orchestration that nearly every developer encounters. Whether it's management of complex data pipelines, job coordination across GPU resources, failure handling, or deploying a model
https://temporal.io/blog/ai-ml-and-data-engineering-workflows-with-temporal

メインTOPIC

[書籍紹介] 「機械学習システムデザイン ―実運用レベルのアプリケーションを実現する継続的反復プロセス」より、今の機械学習チームにとって大事そうなポイント

はじめに

• 1章　機械学習システムの概要

• 2章　機械学習システム設計の概要

• 3章　データエンジニアリングの基礎知識

• 4章　訓練データ

• 5章　特徴エンジニアリング

• 6章　モデル開発とオフライン評価

• 7章　モデルのデプロイと予測サービス

• 8章　データ分布のシフトと監視

• 9章　実現場での継続学習とテスト

• 10章　MLOpsにおけるインフラとツール

• 11章　機械学習の人的側面

4章　訓練データ

• サンプリング
• 機械学習プロジェクトのライフサイクルの中では多くの段階でサンプリングが行われる
• 実世界のデータから訓練用に利用するデータをサンプリングする
• データを訓練用・検証用・テスト用に分割する
• 機械学習システムで発生するあらゆるイベントをサンプリングしてモニタリングに活用する
• etc...
• サンプリングの方法
• 非確率サンプリング
• 本ではいくつか紹介されていますが、どれも選択バイアスに満ちている方法となってしまうのでお薦めされない
• 一例：コンビニエンスサンプリング（convenience sampling）入手しやすさでデータのサンプルを選ぶ手法です。このサンプリング手法は有名ですが、その理由はただ手軽だからというだけです。 入手しやすさでデータのサンプルを選ぶ手法です。このサンプリング手法は有名ですが、その理由はただ手軽だからというだけです。
• 確率サンプリング

• ラベル付け
• 手作業によるラベル
• 3つの大変さ
• 手作業によるラベル付けはコストがかかる
• 手作業でのラベル付けにはデータのプライバシーに関するリスクがある
• 手作業でのラベル付けには時間がかかる
• ラベル付けが遅いとイテレーションのスピードも遅くなり、環境や要件の変化にモデルが適応しにくくなってしまう。タスクやデータに変化があったときには、モデルを更新する前に再ラベル付けが済むのを待たなければいけない。
• アノテーター間の相違を最小限に抑えるには、まず何よりも問題定義を明確にすることが重要
• ラベル付けにおいてもデータリネージの考え方が大事。クラウドソーシングのアノテーターに新規のアノテーションをお願いして区別なく混ぜ込んでしまった場合（特に特別な訓練などを積んでいない人だと質が悪くなってしまうリスクが上がる）、後からモデル性能の劣化が確認されても問題を分解して扱うことができなくなってしまう
• 天然のラベル
• 天然のラベルを使用したタスクとは、モデルの予測がシステムによって自動的に評価されたり、部分的に評価されたりするようなタスクのこと
• レコメンドであればユーザに提示した候補のうち、実際にクリックされたものを positive、クリックされなかったものを negative とみなしたラベルを採用すること
• 著者が接点のある86社の企業に調査をかけたところ、天然のラベルを利用している企業は比較的多かったとのこと

• 欠損ラベルへの対処



• 弱教師学習: 特定の正規表現パターンマッチによって自動的にラベルを判定するなど、ラベリング関数を作り運用する。データに直接触れる機会をかなり限定的にできるため、データのプライバシー要件が厳しい場合に特に役立つ
• 転移学習: BERTなど、事前学習を行なったモデルに対して fine-tuning を行うといったアプローチ。今こそ脚光を浴びている
• 能動学習: まだラベルが付加されていないサンプルをモデル（アクティブ学習器）がアノテーター（通常は人間）に送り返してラベルの付加を依頼するという手法
• Active Learning は過去勉強会でも何度か扱っています

• クラスの不均衡
• 非常にディープなニューラルネットワークや2値分類タスクにおいては、データの不均衡に対して優れたパフォーマンスを発揮しやすい。
• さらにモデル自体を工夫してこの問題に立ち向かうこともできるが、それは現実的に難しいこともあるため、下記3つの手法が紹介されている
• 問題に適した指標を選択する手法
• データの分布を変更して不均衡を軽減するデータレベルの手法
• 学習方法を変更してクラスの不均衡に対して堅牢にするアルゴリズムレベルの手法

• データオーグメンテーション
• ラベルを保ったシンプルな変換
• 画像処理においては、ラベルを保ったまま画像にランダムな変更を加えるのが最もシンプルなやり方
• 自然言語処理においては、ある単語を類似する単語に、文の意味や感情を変えないようランダムに置き換える方法がある
• 摂動
• ラベルを保った変換の範疇と言えるが、少し意図が異なったりするため分けて解説

自然言語の分野ではあまり一般的ではありませんが、モデルをより堅牢なものにする目的で摂動が使われています。最も特筆すべき例のひとつにBERTがあります。BERTのモデルは、それぞれのシーケンス内の全トークンから15%をランダムに選択し、その選択したトークンのさらに10%をランダムな単語で置き換えます。

• データの合成
• 自然言語領域での安直な方法として、テンプレートに対する値の埋め込みによってデータをカサ増しさせる方法が紹介されている

8章　データ分布のシフトと監視

• 機械学習システムの障害の原因

2020年に、Googleの機械学習エンジニアのDaniel PapasianとTodd Underwoodは、Googleの大規模機械学習パイプラインにおける96件の障害事例を調査しました。2人は過去15年以上ものデータを検証し、この96件の障害のうち60件は機械学習と直接関係のない原因によって生じていたことを明らかにしました。

これらの問題の大半は、ワークフローのスケジューラーやオーケストレーターによる誤りなどのような分散システムに関連するものや、複数のソースからのデータを結合する際の誤り、使用したデータ構造の誤りなどのデータパイプラインに関連するものでした。

• この調査の通り、機械学習を支える周辺のシステムに対してのソフトウェアエンジニアリングの問題の方が多くなりがちというのは、まず頭に置いておきたいこと。
• 機械学習特有の問題は上記のような問題に比べ、検出や対応が難しい。少ないとはいえ大きな問題になり得るもの
• 訓練データと実環境のデータとの差異はなぜ生まれるか
• 現実世界に対し、訓練データは限定的なものであり、どうしても選択バイアスやサンプリングバイアスが存在してしまう
• 時間の経過とともにデータの分布が変化してしまう
• これはいわゆるデータドリフト・データシフトだが、ダッシュボードなどでデータドリフトのように見えるパフォーマンスの変化の真の要因は内部的なエラーであることも多い
• データパイプラインに不具合がある
• 不適切に入力された欠損値がある
• 訓練時と推論時に抽出された特徴の間に不整合がある
• 誤ったサブセットのデータからの統計を使用して特徴を標準化してしまった
• モデルのバージョンに誤りがある
• アプリのUIに問題がありユーザーが行動の変更を余儀なくされている

• データ分布のシフト
• データ分布のシフトを検出するには
• データ分布のシフトが問題になるのは、精度が変化する（劣化する）時。つまり、モデルの精度に関連する指標（正解率、F値、再現率、AUC-ROCなど）に実際の現場で変化がないかを監視するのが良い
• 正解ラベルが利用できない、または時間がかかりすぎてあまり役に立ちそうにない場合は、その代わりに入力分布、ラベル分布、条件分布、などのような他の関心のある分布を監視できる
• 分布を監視する基本的な方法として、要約統計量を利用できる。
• もっと踏み込んだものとして、二標本検定を利用する方法も挙げられる（2つのデータセットの間の差が統計的に有意であるかどうかを判定）
• データ分布のシフトに立ち向かうには
• シフトは起きるものだと捉え、シフトの程度にかかわらず、毎月、毎週、毎日などの頻度で定期的にモデルの再訓練をやっている会社も多い
• その他のアプローチとしては
• 膨大なデータセットを使用してモデルを訓練する
• （あまり実例は見受けられないが）変化する分布に対して不変なデータ表現を学習できる教師なしドメイン適応手法を適応する
• ターゲット分布（モデルが推論するデータの分布）のラベル付きデータを使用してモデルを再訓練する

• 監視と可観測性



• 精度に関する指標の監視
• ユーザからのフィードバックを受け取り、場合によっては天然のラベルの推測に使用したり、モデルのパフォーマンスに関連する指標の計算に利用したり。
• もっとも直接的にモデルのパフォーマンスが低下したかを判断できるもの。
• 予想の監視
• もっともよく監視されるであろうとされるもの。
• 予測の分布がシフトしていないかどうかを監視することが良い。予測は低次元なので、二標本検定で予測分布のシフトを検出することも簡単にできる。
• 正解かどうかが不明確なものより、Falseなどの異常値になってしまっている量の変化であれば顕在化しやすく即時発見することもできるようになりやすい
• 特徴の監視
• 特徴量エンジニアリングが肝となるようなモデリングを行なっているのであれば、特徴のバリデーションを行うのが良い
• 特徴の最小値、最大値、中央値が許容範囲内にあること
• 特徴の値がある正規表現形式を満たすこと
• すべての特徴の値が事前定義済みのセットに含まれること
• ある特徴の値が常に他の特徴の値よりも大きいこと
• 特徴の監視を行うにあたって気をつけておくべきこと
• 企業が運用するモデルの数が数百になることや、それぞれのモデルが（数千とまでは言わないが）数百の特徴を使用することがある。高コストな運用になってしまう可能性がある
• 特徴を追跡することはデバッグの用途では役に立つものの、モデルのパフォーマンスの低下の検出にはあまり役に立たない。偽陽性のアラートの大量発生に繋がってしまうかもしれない
• 特徴抽出は、さまざまなサービス（BigQueryやSnowflakeなど）でさまざまなライブラリ（pandasやSparkなど）を用いて複数のステップ（欠損値埋めや標準化など）で実施されることが多い。入力部分なのかETL部分なのかどこで変化が発生したかがわかりにくくなりかねない
• 時が経つにつれて特徴が準拠するスキーマが変化する可能性がある。スキーマをきちんと管理するすべを持っていなければ、データの変化とスキーマの不一致のどちらが問題なのかの見分けがつきにくくなる

• 監視ツールボックス
• ログ
• システムのデバッグのため、コンテナの計算資源に関するログやクラッシュ、スタックトレース、エラーコードなどのログを取得するようにするのがまず基本
• マイクロサービスアーキテクチャであれば各プロセスに一意のIDを割り当てるような分散トレーシングも大事になる
• ダッシュボード
• ただ作るだけではなく、経験や統計の知識を活かして有用なものにするのが大事
• 指標の数を無闇にふやすとかえって逆効果となってしまう。適切な指標を選択するか、あるいは低レベルの指標を抽象化して、特定のタスクにとってより有意義な高レベルなシグナルを計算することが重要

• 可観測性（Observability）
• 可観測性とは、ソフトウェアの複雑な振る舞いが理解できるように実行時にシステムから収集した出力を使用して可視性を向上させること
• 機械学習における可観測性にはモデルの説明能力などが挙げられる。たとえば、この1時間の間にモデルのパフォーマンスが低下した場合に、この1時間に行われた予測の誤りに最も影響を与えている特徴はどれなのかを説明できることなど