🌊

A brief introduction to Training/Serving Skew

2020/12/24に公開

Training/Serving Skew

Training/Serving Skew はモデルの訓練時と推論時の環境の差異に起因して、モデルが不都合な振る舞いをしてしまうことを言います。Training/Serving Skew について述べている文章はいくつかありますが、ここでは TensorFlow Data Validation のガイド に書かれていた文章を和訳して掲載します。

この文章は https://github.com/tensorflow/tfx/commit/f677d055b93d38034a11bbacaa5eccb8ea273fde#diff-09227482e877396abc5ae39296d992f69a5aa8a776af6365fe8812eb6c8d5a4a により TFDV のドキュメントからは削除されてしまいましたが、多くの機械学習勢の参考になる名文だったのでここに掲載します。


トレーニングサービングスキューの検出

概要

トレーニングサービングスキュー検出器は TensorFlow Data Validation のサブコンポーネントとして実行され、訓練データと本番データの間の分布の偏り (スキュー) を検出します。

分布の偏りの種類

さまざまな本番環境のポストモーテムから、さまざまなタイプの偏りを4つの重要なカテゴリに分類しました。以下では、それぞれのカテゴリと、それが発生しうるシナリオの例について述べます。

スキーマの偏り

スキーマの偏り は訓練用データと本番用データが同一のスキーマに従わないときに発生します。スキーマデータの性質を論理的に記述するため、訓練データだけではなく本番データも同一のスキーマに準拠していることが期待されます。ラベルとなる特徴量は訓練データにだけ出現し、本番データには出現しないといった、2つの環境間で予期されるいかなる違いについてもスキーマの環境フィールドに指定されている必要があります。

訓練データの生成はバルクデータ処理の1ステップであるのに対し、(オンラインでの) 本番データ生成は典型的には遅延に考慮が必要なステップであるため、訓練データの生成と本番データの生成に異なるコードが使われていることがよくあります。これは誤りです。この2つのコード間の不一致はすべて (それが開発者の記述によるものでも、バイナリファイルの不一致によるものでも) スキーマの偏りを引き起こしえます。

シナリオの例

ボブはモデルに新しい特徴量を追加し、訓練データに加えたいと考えています。オフライン学習での各種指標は素晴らしい値を示したものの、オンラインでの各種指標はずっと悪くなってしまいました。数時間のデバッグのあと、ボブは自分が同じ特徴量を本番環境のコードに加えることを忘れていたことに気が付きました。追加した特徴量にモデルは高い重要度を与えていましたが、その特徴量は本番環境では利用できないものだったため、モデルは本番環境の各種指標を悪化させる、質の悪い推測結果を生成してしまいました。

特徴量の偏り

特徴量の偏りはモデルに与えられる特徴量の値が訓練時と本番環境とで異なることにより発生します。これは次に示すものを含む、複数の理由から発生します。

  • 特徴量を生成する外部のデータソースが訓練時から本番環境に移行する間に修正される場合
  • 訓練時と本番環境とで特徴量を生成するロジックが一貫していない場合。例えば、何らかの変換処理をどちらか一方のコードにしか追加していない場合。

シナリオの例

アリスは連続して実行される機械学習パイプラインを持っています。そこでは本番環境に今日投入されたデータが記録され、次の日の訓練データとして用いられます。保存容量を節約するため、彼女は保存するのは動画の ID のみにして、訓練データの生成時に動画の各属性を読み込むようにしようと決めました。

そうする中で、訓練時と本番環境とで視聴回数の差異が、特に新規にアップロードされた人気の動画において危険なほど異なっているという偏りを意図せず導入してしまいました。偏りの例を次に示します。

     Serving Example           Training Example	
     -------------------------  -------------------------	
     features {                 features {	
       feature {                  feature {	
         key "vid"                  key "vid"	
         value { int64_list {       value { int64_list {	
           value 92392               value 92392	
         }}                         }}	
       }                          }	
       feature {                  feature {	
         key "views"               key "views"	
         value { int_list {       value { bytes_list {	
           value "<b>10</b>"                value "<b>10000</b>"  # skew	
         }}                         }}	
       }                          }	
     }                          }

これは訓練時のデータは大幅に増加した視聴回数を参照してしまったために生じた、特徴量の偏りの1つです。

分布の偏り

分布の偏り は特徴量の分布が本番環境のデータの分布と著しく異なるときに生じます。分布の偏りが生じる主要な原因の1つに、コーパスに利用したいデータが最初はまったくないという状態を克服するために、全く異なるコーパスを用いて学習させてしまうというものがあります。別の理由に、本番環境のデータの一部を訓練データとしてサンプリングするする機構の欠陥というものもあります。

シナリオの例

たとえば、データに出現しなかったスライスを補間するために、もしバイアスの生じたサンプリングが用いられ、アップウェイティングもダウンサンプリングも適切に行われなかったデータを用いた場合、訓練データと本番環境の間で特徴量には大きな偏りが生じるでしょう。

スコアリングサービングスキュー

スコアリングサービングスキュー は発生していることを検知するのが困難で、スコア付された標本データの一部だけが本番環境に提供されるときにのみ発生します。ラベルは本番環境に提供された標本データについて利用可能であり、スコア付された標本データ全体ではないため、本番環境に提供されたもののみが訓練に用いられます。このことはスコア付された標本データについてモデルが誤予測することを潜在的に引き起こします。なぜなら徐々にそれらのデータは訓練データに出現しなくなっていくためです。

シナリオの例

トップ10件の広告を提示するような広告システムを考えます。これらの10件の広告のうち、1つのみがユーザーにクリックされる可能性があります。10件の提示された標本データが次の日の訓練データに使われます。1件はポジティブで、9件はネガティブです。一方、本番環境ではそのモデルは100件の広告をスコア付するために使われます。他の90件の提示されなかった広告は、暗黙的に訓練データから取り除かれます。これは、下位にランク付けされたものについて誤予測するように、暗黙的なフィードバックループを引き起こします。下位にランク付けされたデータは訓練データに現れないからです。

なぜ注意すべきか?

偏りは検出が困難であり、多くの機械学習パイプラインの間にはびこっているからです。偏りが引き起こしたパフォーマンスの劣化や機会損失についてのインシデントがしばしば発生し続けています。

現状何がサポートされているか?

現在のところ、TensorFlow Data Validation はスキーマの偏り、特徴量の偏り、分布の偏りの検知をサポートしています。

Discussion