アルゴリズムエンジニアの日常生活において、トレーニングされたモデルが失敗した場合はどうすればよいでしょうか?

[[353013]]

みなさんこんにちは。今日は職場でのアルゴリズム エンジニアの日常生活、つまりモデルの失敗についてお話ししたいと思います。

アルゴリズム エンジニアの仕事の中心はモデルのトレーニングであることは誰もが知っています。多くの人の日常業務は、機能を作成し、パラメータを調整して、モデルをトレーニングすることです。したがって、アルゴリズム エンジニアにとって最も一般的な問題はモデルの失敗です。非常に困難を伴ってトレーニングされたモデルでも、結果は非常に悪いままです。多くの初心者はこのような状況に遭遇すると途方に暮れ、何が悪かったのかわからなくなります。

そこで今日は、私が個人的にまとめた簡単な体験をいくつか皆さんにシェアしたいと思います。このような状況に遭遇したとき、私たちはどのように対処すればよいのでしょうか。

サンプルを確認する

不十分なモデル トレーニング結果のトラブルシューティングのプロセス全体は、大規模なものから小規模なものへ、浅いものから深いものへと順に続きます。つまり、まず全体的かつマクロ的な調査を行い、その後に細かい内容を確認します。

多くの初心者は経験が浅いため、全体的な検査を無視して機能の詳細をチェックし始めることがあります。その結果、サンプルの割合またはサンプルの量が間違っているという問題が簡単に検出できることに気づくまでに、多くの時間を費やすことになりました。時間の無駄になるだけでなく、上司や周りの人に悪い印象を与えてしまいます。

そこで、まず全体の状況から始めて、陽性サンプルと陰性サンプルの比率を確認し、トレーニング サンプルの数を確認します。通常の実験と比べて何か変更点はありますか? このタイプの検査は通常簡単で、数分で結果が得られる場合があります。問題が見つかれば最高ですが、問題が見つからなくても、少なくとも原因のいくつかは除外されているので、損失にはなりません。

サンプルの割合と数を確認した後、特徴の分布をチェックして、新しく作成された特徴に問題がないか確認できます。ここで発生する可能性のある問題はたくさんあります。たとえば、ほとんどの機能が空の場合、2 つの状況が考えられます。 1 つの可能性としては、機能コードに問題があり、バグが含まれている可能性があることです。もう 1 つの可能性は、特徴自体がスパースであり、少数のサンプルのみが値を持つということです。私の経験上、機能が少なすぎると効果は非常に少なくなり、逆効果になることもあります。追加しない方がよいでしょう。

もう一つの考えられる問題は、特徴の値の範囲が非常に不均等に分布していることです。たとえば、特徴の 80% が 10 未満で、残りの 20% が最大 100 万になる場合があります。このような極端に不均衡な特徴の分布は、モデルの効果を低下させます。より良い方法は、それをセグメント化してバケット特徴にすることです。機能に関する問題は、その分布を調べることで簡単に調査できる場合がよくあります。

トレーニング曲線を表示

多くの初心者は、AUC や精度などの最終結果に基づいてモデルを判断しますが、トレーニング プロセス全体を通じてモデルに生じる変化を無視します。これは実はあまり良い習慣ではありません。多くの情報が失われ、多くの状況が無視されることになります。

モデルのトレーニング プロセスを表示するには、Tensorboard の使用に慣れることをお勧めします。Tensorboard は、基本的にすべての主流のディープラーニング フレームワークで利用できます。これを通じて、トレーニング プロセス中のいくつかの重要な指標の変化を確認できます。その最も重要な機能は、過剰適合または不足適合を検出することです。

よくある状況として、元の機能セットではモデルに問題がないのに、新しい機能を追加すると効果が低下し始めるというものがあります。ログを確認すると、モデルの学習が終了する前の期間でもAUCなどの指標が上昇していたため、問題がないと誤解していました。実際、途中でモデルが過剰適合に陥った可能性が非常に高いのですが、トレーニング時間が比較的長かったため無視されました。

多くの人が、特に初心者は、この損失に悩まされることが多いです。問題が見つからないまま、多くの時間が無駄になりました。実際、テンソルボードを開くと、モデルが過剰適合または不足適合していることがわかります。その後、それを修正するためにいくつかの的を絞った対策を講じることができます。

パラメータチェック

上記 2 つに加えて、確認すべきもう 1 つのポイントはパラメータです。

ここでのパラメータは、学習率、反復回数、batch_size などのモデルのトレーニング パラメータに限定されません。また、埋め込み初期化の分散、埋め込みのサイズなど、モデル自体のいくつかのパラメータも含まれています。

簡単な例を挙げると、埋め込み初期化にはデフォルトの初期化を使用する人が多く、デフォルトの分散は 1 です。この分散は、実際には多くのシナリオ、特に勾配爆発を起こしやすい一部のディープ ニューラル ネットワークでは少し大きすぎます。多くの場合、これを 0.001 に調整すると、効果が改善されることがよくあります。

モデルの構造が主体であり、パラメータは補助的なものに過ぎないとはいえ、パラメータがモデルの効果に影響を与えないということではありません。それどころか、影響が非常に大きく、無視できない場合もあります。もちろん、これを行うには、各パラメータの意味を知る必要があるだけでなく、モデルの構造とモデルの動作原理を理解して、パラメータの効果と重要性を推測する必要があります。そうでなければ、単純にコピーして貼り付けるだけでは明らかに機能しません。

シナリオ思考

上記の 3 つのポイントは比較的明白です。次に、アルゴリズム エンジニアにとって最も難しい、もう少し隠れた点についてお話しします。

多くの場合、特定のシーンでうまく機能するモデルが別のシーンではうまく機能しなかったり、非常に便利な機能が突然無効になったりすることがあります。これは隠れたバグによるものではなく、単にモデルが現在のシナリオに適していないことが原因である可能性があります。

推奨シナリオを例に挙げてみましょう。たとえば、ホームページ上の推奨では、追加の入力情報がないため、ユーザーの過去の行動の好みに基づいて推奨することしかできません。この時、ユーザーの過去の行動と現在の商品情報との交差や重なりに特に注目し、その情報を機能として生かすことに注力します。しかし、同じ機能が商品詳細ページの下部にある「おすすめ商品」セクションに移動されると、あまり適切ではない可能性があります。

その理由は非常に簡単です。詳細ページの下部で思い出したい製品は、基本的に同じカテゴリ、または同じ製品です。つまり、これらの製品自体のほとんどの情報は、同じか非常に類似しているということです。これらの情報は非常に類似しているため、モデルがこれらの小さな違いを持つ特徴から重要な情報を学習することは困難であり、当然同じ効果を達成することは困難です。これは機能やモデルの問題ではなく、単にシーンが適切でないだけである可能性があります。

シナリオ、機能、モデル間の理解と思考は、アルゴリズム エンジニアの能力と経験を最も試される部分です。新人はこの側面に注意を払わず、機能とモデル自体に限定されることがよくあります。時には、私たちの思考はスムーズに一直線に流れることができず、頻繁に立ち止まって考え、思考の中に見落としている問題がないか確認する必要があります。

この記事はWeChatの公開アカウント「TechFlow」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合は、TechFlow公式アカウントまでご連絡ください。