今週のTOPIC

[論文] Learning to Defer with Limited Expert Predictions

概要

• AAAI2023

• 委譲学習（Learning to Defer）のためのデータ拡張手法
• 委譲学習では、MLが解くよりも人間が解いたほうが正確な問題（instance）は、人間に任せる。どの問題を任せるかを判断するための学習 → 入力データに対して委譲するかどうかを予測する

• 委譲するかどうかの予測のため、人間の回答を使った学習が必要だが、人間ラベルを多く集めるのは大変

• 少ない回答データから委譲学習のためのラベルを作成する方法を提案

提案手法

• 入力: データ、ラベル、一部に専門家予測ラベル

• 多クラス分類問題について、3段階で委譲学習のためのデータを作成
• 埋め込みモデル学習: データ → x（特徴料）
• 人間（専門家）の能力予測モデルの学習: x → 専門家予測が正解する or not
• 正解（専門家予測と真のラベルが一致）するかどうかの二値分類にすることで問題を単純化
• 専門家予測一部のデータにしか付与されていないため、全てのデータで正解がわからない設定 → 半教師あり学習を使う
• 専門家予測の生成: x → 専門家予測が正解する or not → 擬似ラベル
• 正解すると予測された場合は、真のラベルをそのまま専門家予測とする
• 間違えると予測された場合は、間違ったクラスの中からランダムに選んで専門家予測とする

• 本物の専門家予測の付与されていないデータにも擬似的な専門家予測を付与できる。これを使って委譲判断モデルを学習する
• 委譲判断モデル自体は、過去の手法を踏襲する

 

実験結果

• CIFER100（60,000 images with 100 classes）に人工的に専門家予測を付与して実験
• 上段が100ラベル中90ラベルが得意、下段が60ラベルが得意という設定でシミュレーション

• 基準となる精度
• Complete Expert Predictions: 全てのデータに専門家予測が付与されている。精度の上限値でこの精度を100%として表示している。
• Human Expert Alone: 人間だけで解いた時の精度（96~98%）
• Classifier Alone: 分類機だけで解いた時の精度（88 ~ 92%）

• 提案手法（Embedding-FixMatch, Embedding-CoMatch）が少ない専門家予測データでもより良い精度（多クラス分類問題）に達している

[doc] Amazon SQS visibility timeout

• 可視性タイムアウト (visibility timeout) とは、Amazon SQSキューからメッセージを受信した際に、他のコンシューマーには一時的に見えなくなさせ処理できないようにする仕組み

• Amazon SQSはメッセージを自動的に削除しないため、コンシューマーはメッセージを正常に処理した後に、DeleteMessageアクションで削除する必要がある
• コンシューマーが可視性タイムアウトの期限が切れる前にメッセージを削除できなかった場合、そのメッセージは再びキュー内で可視状態となり、他のコンシューマーに取得される可能性がある
• コンシューマーがメッセージの処理に失敗した場合、可視性タイムアウトが切れる前にメッセージを削除できなかった場合、そのメッセージは自動的にキュー内で再び可視状態になる

• 可視性タイムアウトを高すぎる値に設定してしまうと、処理されなかったメッセージが再び可視化されるまでの時間が遅れ、再試行のタイミングが遅くなる可能性があるので、適切な可視性タイムアウトを設定することが、迅速なメッセージ処理には重要

• Amazon SQSでは、ChangeMessageVisibilityアクションを使用して可視性タイムアウトを変更または終了させることで、メッセージ処理を柔軟に管理可能
• タイムアウトの変更
• 初期設定の可視性タイムアウトが不十分な場合は、ChangeMessageVisibilityアクションを使用してタイムアウトを調整できる
• タイムアウトの終了
• 受信したメッセージを処理しないと判断した場合は、ChangeMessageVisibilityアクションを使用してVisibilityTimeoutを0秒に設定することで、そのメッセージの可視性タイムアウトを終了させることができる

---

Reliable Machine Learning

どんな本？

• 非常に包括的な本です。

• yarnit.ai というオンラインショッピングサイトを本全体の例として扱い、最終章に Case Studies も用意されていますが、超具体的な Howto 本というよりは概念的な解説も多めな本となっています。

• 以下のような気持ちで臨むのが良い本かもしれません。
• 俯瞰的に全体像を見てみたい
• 自分は○○エンジニアとしてのバックグラウンドなので、理解がまだ十分でないところの入門をしたい
• チームで共通言語を育みながら自分たちのシステムに必要なものを見極めるディスカッションの呼び水としたい

今日のお話

9章 Monitoring And Observability For Models

• SLOとMLモニタリング
• SLO（サービスレベル目標）は、システムの信頼性レベルを事前に設定し、機能開発と信頼性向上のバランスを取るための指標。
• 例：99.9%の可用性を目標にし、下回った場合は修復作業に集中する。（Error Budgetと言う考え方）
• MLシステムにおけるSLOの複雑さ
• データの考慮が不可欠：モデルだけでなく、データの分布や新鮮さなども対象とする必要がある。
• 可用性の定義の難しさ：MLシステムでは、提供される結果の品質（例：分類器の信頼度など）もSLOの一部として考慮する必要がある。

• SLOの設計のポイント
1. ビジネス目標に基づいたSLOの設定
• MLシステムのパフォーマンスではなく、そのシステムが達成すべきビジネス目的に焦点を当てるべき。
• システム全体のユーザー体験が一定の限界内であれば、多少の品質低下は許容される。
2. 複数のモデルやユースケースに対応するSLOの拡張
• モデルごと、またはモデルのクラスごとにSLOを定義するためのセルフサービス型インフラが有効。
• ゴールデンデータセットを基準にSLOを評価することで、SRE（サイト信頼性エンジニア）がモデルごとの信頼性管理を支援できる。
3. 隣接システムとのSLOの連携
• MLシステムはビジネス全体に絡んでいるため、MLだけでなく隣接システムにもSLOを設定する必要がある。
4. 自動化と人間の協調
• 高度なSLO（99.5%以上）の達成には、人間による対応だけでなく、自動システムと人間の協調が必要。
• 自動化の導入は有用だが、MLシステムでは慎重に進めるべき。

• SLO設定の具体的な始め方
• 表9-1を参考に、測定対象とそのスコープに基づいてSLOを策定する。
• 例：MLトレーニングシステム全体の健康状態を懸念する場合、該当する指標や例を表から見つける。
表9-1: MLコンテキストごとの監視対象の行動や指標

カテゴリ	トレーニング	サービング	アプリケーション（例：YarnIt）
全体のシステム健全性	- モデル構築時間（スナップショット除く） - 同時トレーニングの数 - 失敗した構築試行の数 - リソースの飽和状態（例：GPUやI/Oスループット）	- レイテンシ（リクエスト応答時間） - トラフィック（リクエスト数） - エラー数（失敗したリクエスト数） - 飽和状態（CPU、RAM、I/Oなどのリソースの枯渇）	- ユーザージャーニーやセッションに依存 - 購入率 - ログイン率 - ページのサブコンポーネントの障害率（例：カートの表示） - カート放棄率
一般的なMLシグナル／基本的なモデル健全性	プレトレーニング： - ソースデータサイズ（前回構築時から大幅な変動がない） トレーニング中： - モデルタイプや入力データサイズに対するトレーニング時間 - トレーニング設定（例：ハイパーパラメータ） トレーニング後： - モデル品質指標（精度、適合率、再現率、その他のモデル固有の指標）	- モデルサービングのレイテンシ（全体のサービングレイテンシの一部または経時的比較） - モデルサービングのスループット - モデルサービングのエラー率（タイムアウト／空の値） - サービングリソース使用量（特にRAM） - サービング中のモデルの年齢／バージョン	- ページ読み込みごとに可視化されるモデル固有の指標 - ページごとの推奨数 - 各推奨の推定品質（予測クリック率） - 検索モデルに類似した指標
ドメイン固有のシグナル	- 構築されたモデルが検証テストに合格する（集計フィルタが機能するだけでなく、ゴールデンセットや保持セットのテスト結果が同等以上の品質であること） - ストアの新製品に対する推奨の品質が同等または向上している	- これらの指標は扱っている問題のドメインによっては遅延することがある。（橋が崩壊する可能性を予測するとか） - オフライン信号が提供された予測と集計および関連スライスで一致する。 - 特定のクエリに対して提供された推奨数が事前の期待値に一致する。	- セッションまたはユーザージャーニーに特化した指標 - 購入が伴う訪問の割合が低下していない。 - 訪問ごとの平均購入額が維持されている。 - セッションの持続時間が維持されている。

11章 Incident Response

• 一般的なインシデントレスポンスに加え、 MLシステムでは以下のようなポイントを押さえる必要が強くなります
• 検知
• ML（機械学習）システムは、非MLシステムよりも決定論的ではありません。その結果、人間のユーザーが検出する前にすべてのインシデントをキャッチするための監視ルールを書くのが難しくなります。
• 解決に関与する役割とシステム
• MLのインシデントは、トラブルシューティングや解決の際に、ビジネスやプロダクト担当者、管理職やリーダーシップなど、幅広いスタッフを巻き込む傾向があります。MLシステムは複数のシステムに広く影響を与え、多くの場合、複雑なシステムの上に構築され、それらからデータ供給を受けています。そのため、どのインシデントにも多様なステークホルダーが関与する可能性が高くなります。また、MLの障害はインフラ内の他の部分と統合・変更を行う役割を果たしているため、複数のシステムに影響を及ぼすことがよくあります。
• 不明確なタイムラインと解決
• 多くのMLインシデントでは、時間とともに変動する品質指標への影響が関係します。このため、インシデントのタイムラインや解決の時期を正確に特定することが困難になります。

• MLインシデントの特徴と課題
• 公開性（Public）
• 多くのML障害はエンドユーザーやシステムの最終段階で初めて検出される。
• モデルの品質問題はユーザーには明確でも、開発者やSREには見えにくいことが多い。特に一部のユーザーだけに悪影響が出るケースは、集計データに反映されにくい。（ごくわずかなユーザに対して100%発生するような問題でも全体の集計データには現れにくい）
• 不明確さ（Fuzzy）
• インシデントの開始・終了時点や原因を特定するのが難しい。
• モデルは継続的に改善されるため、「故障」と「改善の余地あり」の境界が不明瞭。
• 境界のない広がり（Unbounded）
• MLシステムは多部門にまたがって構築されているため、障害対応には技術・製品・ビジネスの各部門の協力が必要となる。
• MLの障害が他のシステムより必ずしも重大というわけではないが、広範囲の組織対応が求められる。

• モデル開発者やデータサイエンティストの役割とインシデント対応
• 準備段階での推奨事項
1. モデルとデータの整理・バージョン管理
• すべてのモデルやデータをバージョン管理し、特徴量ストアに保存する。
• データの出所や生成に関わるチーム、変換プロセスを明確にするためのメタデータを記録。
• 過去のモデルを保存し、品質低下時の迅速な対応ができるようにする。
2. 受け入れ可能なフォールバックの設定
• 初期段階ではシンプルなヒューリスティック（例：人気商品を推奨）をフォールバックに使用可能。
• モデルが進化するにつれ、フォールバックが有効でなくなる場合があるため、複数バージョンのモデルを保存し、切り替えをテストする。
3. 適切なメトリクスの決定
• モデルの品質と性能を測るため、実装に依存しない指標を用意する。
• 問題が発生した際に、モデルの不具合を正確に検知できるメトリクスが必要。
• インシデント対応時の役割
• モデルの説明と問題の仮説検証
• モデル開発者とデータサイエンティストは、インシデント時にモデルの現状を説明し、問題の原因に関する仮説を生成・検証する。
• 必要に応じて、当番制のオンコール体制を組み、緊急対応に備える。
• 倫理的な判断とカスタム分析
• プライバシーや倫理を守りながら、カスタム分析やモデルのバリアントを用いた仮説検証を行う。
• 不適切な要求があった場合は、拒否するための準備も必要。
• 継続的な改善
• モデル品質評価のループを短縮する
• 変更から評価までの時間を短縮することで、問題の迅速な解決とモデルの改善に繋がる。
• トレーニングの効率化や適切なリソースの確保が重要。これにより、長期的なシステム停止リスクを低減する。

• ソフトウェアエンジニアの役割とインシデント対応
• 準備段階での推奨事項
1. データの整理とバージョン管理
• データは一貫性を保ち、由来を明確にする。
• 同一データの複数のバージョンを可能な限り減らし、「最新」データが複数存在しないようにする。これにより、モデル品質の低下や予期しないエラーを防ぐ。
2. モデルとバイナリの分離
• モデルとバイナリ（推論を実行するプログラム）は、独立してデプロイできるようにする。
• 各デプロイ後に品質評価を実施し、問題発生時のトラブルシューティングを容易にする。
3. 特徴量の整合性の確保
• トレーニングと推論時の特徴量の扱いを一致させる（トレーニング・サービングの不一致を防ぐ）。
• 特徴量の変化（例：「収入」が「郵便番号」に変わるなど）によるエラーを避ける。
4. ツールの整備
• モデルとバイナリの展開およびロールバック用のツールを用意する。
• データのバージョン管理を可視化するツールや、サポートスタッフ/SREがデータを直接確認できるツールも必要。
• 既存のフレームワークや環境で利用できるツールがあれば活用し、不足分は開発する。
• インシデント対応
• ソフトウェアエンジニアは、インシデント時のエスカレーション先として機能する。
• モデルサーバ、データ同期ツール、データバージョニング、モデルトレーニング、特徴量ストアなど、各システムの障害が発生し得るが、成熟したシステムではこれらを効率的に管理できる。
• 組織が成熟すれば、ソフトウェアエンジニアがインシデント対応に割かれる時間は少なくなる。
• 継続的な改善
• 他部門との協力
• モデル開発者、SRE、カスタマーサポートと連携し、欠けている機能や改善点を特定する。
• レジリエンスとモニタリングの改善
• データの大きな変化への耐性を強化し、ソフトウェアの状態を効果的にエクスポートすることで、監視を改善する。

今日ここでは紹介しなかったこと

• 9章
• モデル開発・訓練時の取り扱いについては、扱うドメインの特性に合わせて何をやるべきかを見定めたり、データドリフトやデータ品質への気遣いが必要ですが、それについても本章では詳細に触れられています。

• 11章
• インシデントレスポンスについては仮想的な具体事例が記載されています。どんな心構えが必要かというまとめ的部分の要約をここで紹介しましたが、より実践的な動きに起こしていくためには原著をあたりながら理解を深めるのが良さそうです。
• ML SRE or Production Engineer / Product Manager or Business Leader 向けの心構えについても同様に記されています。また、取り扱うデータの秘匿性からプライバシーを尊重しながらもインシデントレスポンスに当たるための心構えについても記されており、やはり自分の取り扱っているシステムに合わせて深く理解をすべき箇所を見極めるのが大事になってきそうです。