AIアルゴリズムエンジニアの涙の体験談

[[425033]]

私たちはしばらくの間、展開モデルの最適化に取り組んできました。ここ数日でようやく需要が出てきたので、また新しいモデルのトレーニングを始めなければならなくなりました。この機会に、トレーニング モデルに関する以前のメモの一部を要約してみました。少し雑然としているかもしれませんが、皆さんがさらに学習するきっかけになれば幸いです。もちろん、これは不完全な統計的経験です。トレーニング部分に加えて、まだ書かれていないデプロイメントの落とし穴が数多くあります。

モデルトレーニングフェーズ

1. アルゴリズム エンジニアは、データの処理に 50% の時間を費やしています。データのコピー (複数のフォルダーから特定のフォルダーへ)、データのフィルタリング (品質の悪いデータを除外)、データの名前の変更やプレフィックスの追加 (マルチスケールや複数の画像強化戦略など、後続のトレーニング中にデータの特性を区別するため) などを行うこともあります。これらのタスクは月に何度も繰り返される可能性があるため、まとめておくのが最適です。Python またはシェル スクリプトを使用して処理するか、jupyter ノートブックを使用して頻繁に使用するファイル処理コードを保存できます。

2. データのソースと信頼性が不明な場合は、まずfind ./ -size -1k -exec rm {} \などのコマンドを使用してフィルタリングすることができます。このコマンドは、1k 未満 (またはその他の値) の破損したイメージをスキャンして削除します。もちろん、他のパラメータを設定することもできます。多くの場合、渡される写真は必ずしも正常な写真ではありません。事前に選別しておくのが最善です。そうしないと、その後の処理が非常に面倒になります。

3. すべてのデータにラベル情報があるわけではありません。ラベル付けするデータを一括して収集し、会社にラベル付け担当者がいる場合は、データを事前にラベル付けして、ラベル付けフレームを調整または補足してもらうと、より効率的です。フレームに事前にラベルを付ける方法としては、まずモデルに少量のデータをトレーニングさせ、再現率の高い小さなモデルをトレーニングしてからフレームを予測してラベルを付ける、または古いモデルを使用してフレームにラベルを付けるという方法があります。ただし、不思議な現象があります。ラベル付け担当者がラベル付けを行うと、速度は向上しますが、事前にラベル付けされたフレームのデータのラベル付けの品質は低下します。これは、ほとんどのラベル付け担当者が調整を望まないためです。このとき、ラベル付け担当者を注意深く監視する必要があります。そうしないと、その後のモデルの精度が向上しず、データの問題になる可能性があります。

4. モデルの指標は、正しい動きだけではない場合があります。モデルが他の人にサービスを提供する場合、実際のシナリオでモデルの出力結果の使用を PM がどのように見ているかによって異なります。検出モデルの最終的な出力スコアについては、最終的にユーザーに与えられるボックスは、取得したスコアのしきい値に応じて設定されるのが一般的です。低く設定するとボックスが多くなり (再現率が高い)、高く設定するとボックスが少なくなります (精度が高い)。異なる方法とシナリオで異なるしきい値を設定すると、効果が異なります。はっきり言えば、モデルの品質はシナリオに大きく依存します。実際のプロジェクトでは、このような状況は実際によくあります。はっきり言えば、損失と精度はどちらも非常に一方的で脆弱な評価指標です。これはモデル構造と評価データの分布に大きく関係しており、モデルの選択方法はアプリケーションシナリオに大きく関係しているはずです。

5. モデルが不良ケースに遭遇した場合、モデルの容量を増やすだけでは効果がない場合があります。この不良ケースはシナリオと密接に関連している可能性が高いためです。この場合、不良ケースを収集するのが最善です。モデルを使用している人が不良ケースを提供する場合もありますが、これは非効率的であり、プロバイダーの気分や緊急性に依存します。モデルの使用シナリオのクエリを大量に直接収集し、現在のモデルをテストに使用して、対応するカテゴリの信頼度が比較的低いケースを収集してから選択することができます。

6. テスト セットは非常に重要です。テスト セットは通常、トレーニング セットから分割されません。検証セットはトレーニング セットから分割されます。検証セットは通常、モデルが過剰適合しているか、不適切にトレーニングされているかを判断するために使用されます。検証セットを使用してモデルの良し悪しを判断する場合、モデルの実際のレベルを表現できないことがよくあります。テスト セットがあることが最善であり、テスト セットは、モデル コレクションとは異なるバッチでモデルをトレーニングする場合に、実際のレベルに近い評価基準です。テスト セットがない場合は、トレーニング セットの損失を見て大まかに判断することもできます。一般的に言えば、デモ レベルのシナリオでない限り、モデルは簡単に過剰適合しません。トレーニング セットには、重い画像強化戦略が含まれていることが多く、画像分布は各エポックで異なる場合があります。このとき、実際にはモデルmodel_last選択できます。

7. 損失と精度は完全に比例するわけではないことを再度強調しておきます。損失の変動は正常です。損失が低いからといって、必ずしもモデルの mAP が高いというわけではありません。逆に、損失が高くなったとしても、モデルの精度が悪いとは限りません。損失の設定が十分ではなく、部分的に増加が支配的になり、別の部分の通常の減少をカバーしている可能性があります。関連する議論: https://github.com/thegregyang/LossUpAccUp および https://www.zhihu.com/question/318399418

8. 検出モデルの mAP を計算します。実際には、計算中にターゲット ボックスのスコアしきい値は考慮されません。つまり、スコアが 0 より大きいすべての検出ボックスを mAP の計算に送信します。ただし、mAP の計算には、検出されたターゲットの最大数である max_num があることに注意してください。タスクの要件に応じて、100、500、または 5000 になります。この制限がある場合、ボックスはスコアに従って並べ替える必要があり、上位 100、500、または 5000 のボックスが計算に使用されます。最後に、結果を視覚化してグラフにボックスを描画する必要がある場合は、この時点でしきい値を設定できます。たとえば、スコアしきい値を 0.2 より大きくすると、最終的に描画される画像に多くの壊れたボックスが含まれます。最後に、NMS を忘れないでください。

9. 変換されたモデルが正しいかどうかをテストするには、入力画像が一貫している必要があります。ここでの一貫性とは、入力画像の値がまったく同じで、dif が 0 でなければならないことを意味します。一般的に言えば、入力するモデルの画像範囲は 0 ～ 1 で、チャネル数は通常カラー、つまり RGB ですが、カラーが擬似カラーであるかどうかに注意する必要があります (伝送リソースを節約するために、グレースケール画像が伝送され、実際の推論中にカラー画像に変換される場合があります。一部のシナリオでは、擬似カラーと真のカラーの精度はそれほど変わりません)。入力サイズも一貫している必要があります。パディングが必要かどうか (0 または 127 または 255 にパディングします。これらのパディング方法は結果に大きな影響を与えます)、32 の倍数にパディングする必要があるかどうか、最大エッジと最小エッジを制限する必要があるかどうかも一貫している必要があります。カテゴリの場合、これがテストモデルの精度を確保する唯一の方法です。

10. モデルについては、後でオンラインにすることを検討している場合。オンラインにする方法はたくさんあります。pytorch+flask を直接 dockerize したり、libtorch を試したり、TensorRT を使用してオンラインにしたり、もちろん独自に開発したフレームワークを通じてオンラインにしたりすることもできます...などです。 モデルが精度を追求し、リアルタイムではなく一定期間オフラインで実行される場合は、flask + docker サービスを試すことができます。モデルのリアルタイム性が高く、モデルの設計時にその後のオンライン起動を考慮する必要がある場合は、モデルの最適化と対応するサーバー推論フレームワークを考慮する必要があり、TensorRT + triton サーバーを試すことができます。

展開

1.トレーニングセット、検証セット、トレーニングセットの実際の役割を再度強調します。トレーニングセットは、教師が割り当てた宿題に相当します。そして、キーポイントはパラメーターなどを調整し、最終的にトレーニングセットの一部を分割しますが、テストセットはテストセットの「未知の」性を確保する必要があります。検証セットの知識は、「さまざまな形式でのトレーニングに参加する」検証セットと同じようにテストを行うことはありません。テスト セットは一般化エラーの近似値として使用するため、テスト セットの情報は最後まで漏洩しません。

2.データの品質はモデルの品質に直接影響します。データ量の初期段階では、最初にモデル構造を変更することでモデルの精度を向上させることができます。注意を追加したり、DCNを追加したり、バックボーンを強化したり、その他の巧妙な構造を使用したりすることで、最終的な精度を高めることができます。しかし、後期段階でモデルの一般化能力を向上させたい場合は、トレーニングデータを増やす必要があります。なぜでしょうか?現時点では、悪いケースはほとんどのトレーニング セットに含まれておらず、モデルが悪いケースを経験していなければ学習できないことは間違いありません。この時点で、悪いケースをターゲットを絞って補足する必要がありますが、悪いケースを補足するのが難しい場合はどうでしょうか。このとき、画像生成は非常に重要です。悪いケースのシナリオのトレーニングセット画像をどのように生成するか、生成されたデータの品質は、モデルの最終的な効果に直接影響します。また、画像強化も非常に重要です。私たちがしなければならないのは、画像強化後のデータの分布をテストセットの分布にできるだけ近づけることです。簡単に言えば、画像生成と画像強化という2つの主要な技術を通じて、実際のシーンをシミュレートすることです。

3. データセット A と B の 2 つがある場合、A にはカテゴリ a と b がありますが、GT ボックスは a のみです。B にもカテゴリ a と b がありますが、GT ボックスは b のみです。明らかに、このデータセットは直接使用できません (GT ボックスのない a と b はトレーニング中に背景と見なされます)。モデルは a ボックスと b ボックスの両方を同時に検出するようにトレーニングする必要があります。どうすればよいでしょうか。 4 つの方法: 1. モデルをトレーニングして a と b をそれぞれ検出し、お互いのデータ セットで予測を行ってラベル付けを支援し、スコアしきい値を制御し、新しいデータ セットを作成した後にモデルをトレーニングします。 2. 蒸留法を使用してモデルをトレーニングして a と b をそれぞれ検出し、これら 2 つのモデルのソフト ラベルを使用して新しいモデルをトレーニングします。 3. 損失​​を変更します。 一般的に言えば、損失関数は負のサンプル (つまり、背景) も逆伝播し、損失フィードバックが発生します。 ここでは、次のように変更します。現在の画像にカテゴリ a の GT ボックスがない場合は、a の損失を直接 0 に設定して、このカテゴリ チャネルが逆伝播を実行しないようにします。これにより、ボックスのない画像をトレーニングできます。モデルは a を背景と見なしません。これは、モデルが「a を見ていないし、a が何であるかも知らない」ためです。 最終的にトレーニングされたモデルがどのようになるか想像できますか? 4. モデルの最後に、ヘッドを分離します。1つはaを検出するためのもので、もう1つはbを検出するためのものです。この時点で、モデルのバックボーンは特徴抽出器になります。

4. 仕事では、古いモデルを使用して、トレーニングが必要な新しいモデルのデータをフィルタリングする必要があるシナリオが多数あります。たとえば、トレーニング済みの検出モデル A を使用して、新しいモデルをトレーニングするためのカテゴリ a の画像を選択する必要があります。このとき、このプロセスを実装するための小さなサービスを構築する必要があります。もちろん、以前の古いモデルの Python ライブラリ コードを開いて、以前の demo.py といくつかの対応するパラメーターを見つけることもできます。明らかにこれは面倒なので、以前のモデルをまとめ、いつでも内部で使用できる小さなサービスを構築するのが最善です。他の人もあなたのモデルを使用してデータを選択する必要があるかもしれないからです。小さなサービスを構築するにはどうすればよいでしょうか。 Flask+Pytorch を使用することもできますが、qps リクエストが大きいとフリーズします。しかし、結局のところ、これはデータをフィルタリングするだけなので、qps を適切に削減して、オフライン リクエストを夜間に完了することができます。

5. 現在、より効果的なオブジェクト検出フレームワークは、広く使用され、リソースが豊富で、導入が容易な古典的なフレームワークにすぎません。結局のところ、モデルのトレーニングの最終目標はオンラインになることです。シングルステージシリーズには、SSD、yolov2-v5シリーズ、FCOS、CenterNetシリーズ、Cornernetなどがあります。2ステージのfaster-rcnnは何度も実装されており、mask-rcnnも多くの人が実装しています。トランスフォーマー構造を使用した最新のDETR検出フレームワークと同様に、上記のすべてはTensorRTを使用して展開できます。実際には、何を使用するかは、速度と精度、および動的サイズをサポートしているかどうかを見るだけです。ただし、最高の実行スコアは、データに適しているとは限りません。データセットの特性に応じてモデルを選択する必要があります。独自のデータセットでは効果が異なる可能性があるため、自分でプルダウンして実行する必要があります。関連モデルのTensorRT展開リソース：https：//github.com/grimoire/mmdetection-to-tensorrtおよびhttps：//github.com/wang-xinyu/tensorrtx

6. もう 1 つ言わせてください。実際、多くのモデルを展開する際の主な難しさは、誰かがすでにこのモデルを作成しているかどうかです。誰かがすでに作成してオープンソース化している場合は、コピーして貼り付け、変更するだけです。落とし穴がある場合は、他の人がすでにそれを踏んでいます。参照できるオープンソース コードがない場合は、自分で行う必要があります。まず、このモデルのバックボーンに特別な操作 (DCN や SENET など、もちろんこれら 2 つはすでにサポートされています) があるかどうか、構造が特殊であるかどうか (通常の畳み込みの組み合わせだけでなく、再形成、ロール、ウィンドウシフトなどのさまざまな特別な操作も含む)、および後処理が複雑であるかどうかを確認します。私が変換した最も複雑なモデルは、バックボーンにカスタムオペレーションがあり、自分で実装する必要があります。また、このモデルには多くの後処理があり、後処理の一部はトレーニングに参加します。つまり、学習したパラメータがありますが、後処理オペレーションの一部はtrtまたは他のフレームワークに変換できません（一部のオペレーションはサポートされていません）。したがって、モデルは2つの部分に分割することしかできず、1つの部分はTensorRTで実装され、もう1つの部分はlibtorcで実装されます。実際には、ほとんどのモデルを展開できますが、難易度は異なります。もっと考える気があれば、常に方法があります。

7. 変換されたモデルは、Pytorch->onnx、onnx->TensorRT、tensorflow->TFLITE のいずれの場合でも、変換前と変換後のモデルは同じパラメーターと構造を持ちますが、同じ入力と出力がまったく同じになることはありません。もちろん、小数点以下4桁の精度で出力すれば同じになるはずですが、小数点以下5桁、6桁、7桁で完全に同じになることは不可能であり、変換自体がロスレスにはなりません。たとえば、Pytorchを使用して学習した検出モデルAがあり、その後、TensorRTに変換されたモデルA`があります。これら2つは同じモデルであり、変換されたTensorRTもFP32の精度を持っています。ランダムな数値を入力すると、2つのモデルの出力を比較すると、1e-4のベンチマークで絶対誤差と相対誤差が0であることがわかります。ただし、これら2つのモデルを検出に使用する場合は、すべてを一貫して保ちます（入力、後処理など）。最終的に生成される検出ボックスは基本的に同じ高スコアを持ち、低スコア（0.1未満または0.2未満など）の検出ボックスには多少の違いがあり、エッジのハードケースも不一致になります。もちろん、この状況は一般的に影響はほとんどありませんが、それでも注意する必要があります。

8. モデルの理論上のフロップは、実際のモデル実行速度とはほとんど関係がありません。これは特定の実行プラットフォームに依存します。フロップが低いモデルが高速であると盲目的に想定しないでください。 多くのオープンソース検出ライブラリは、比較のためにPytorch上で直接実行されます。それらはすべてGPUですが、Pytorchは動的グラフであるため、実際には最適化はありません。一般的なモデルの展開には、演算子の融合や計算グラフの最適化など、あらゆる規模の最適化が含まれます。最も単純な例は、CONV + BN最適化です。多くのPytorchベースのモデル速度比較は、この点を無視しています。2つのモデルの速度を比較する場合、実際に展開するフレームワークとプラットフォームで比較するのが最適です。ただし、モデルのパラメータが多い場合、モデルが高速になる可能性は低くなります。理由は簡単です。ほとんどのパラメータは、一般に畳み込みカーネルパラメータと完全接続パラメータです。パラメータが多いほど、当然演算操作が増えるため、当然遅くなります。

9. 同じ TensorRT モデル (または Pytorch、または GPU で実行されている他のモデル) は、cuda、cudnn、ドライバーなどのバージョンが異なる、またはグラフィック カードのハードウェア パワー ウォール設定 (P0、P1、P2) が異なる、またはシステム バージョン/カーネル バージョンが異なるために、同じモデル カード上で異なる動作をする場合があります。違いは大きい場合も小さい場合もあります。私が見た最大のものは、速度が 70% 異なるというものでした。したがって、モデルの速度が一定でない理由がわからない場合は、これらの理由を検討したほうがよいでしょう。

10. 展開するモデルを変換した後、通常はモデルの速度とスループットをテストする必要があります。速度は、for ループ推論を実行して平均値を取得することで直接測定できますが、実際のスループットは、データ転送、モデル実行、キューイング時間をシミュレートする必要があります。一般的に、モデルのスループットは、1000/xx で簡単に計算できます。xx はモデル実行のミリ秒です。ただし、一部のタスクでは、入力画像が特に大きい場合、これは受け入れられません。実際の画像転送時間、ローカルかどうか、ネットワークセグメント全体かどうかなどを考慮する必要があります。