さまざまなレベルの自律性を車両にもたらすのに何が遅れているのか疑問に思ったことはありませんか？ 車両が見るもの（知覚）と、車両がシーン内のさまざまなエージェントの行動を予測する方法（行動予測）は、自律システムの最初のXNUMXつのステップです。 これらのステップを成功させるには、大規模な運転データセットが重要です。 運転データセットは通常、カメラ、LIDAR、レーダー、GPSなどの複数のセンサーを使用して、さまざまな気象条件や場所でXNUMX日のさまざまな時間帯にさまざまな交通シナリオでキャプチャされたデータで構成されます。 NS Amazon 機械学習ソリューション ラボ とコラボレーションしています インテリジェントで安全な自動車研究所（LISAラボ） カリフォルニア大学サンディエゴ校（UCSD）で、きめの細かい車両、歩行者、シーンの属性を備えた、注釈が豊富な大規模な実世界の運転データセットを構築しました。

この投稿では、を使用した2Dバウンディングボックスのデータセットラベル分類とラベル付けアーキテクチャについて説明します。 Amazon SageMakerグラウンドトゥルース。 Ground Truthは、完全に管理されたデータラベリングサービスであり、機械学習（ML）ワークフロー用の非常に正確なトレーニングデータセットを簡単に構築できます。 これらのワークフローは、3D点群、ビデオ、画像、テキストなど、さまざまなユースケースをサポートしています。 ワークフローの一部として、ラベラーは、自動3D直方体スナップ、2D画像の歪みの除去、データセットのラベル付けに必要な時間を短縮する自動セグメント化ツールなどの補助的なラベル付け機能にアクセスできます。 さらに、Ground Truthは、MLモデルを使用してデータにラベルを付ける自動データラベル付けを提供します。

LISA Amazon-MLSL車両属性（LAVA）データセット

LAVAは、自動車分野のさまざまな最新のコンピュータービジョンアプリケーションに高品質のラベル付きビデオデータを提供するために作成した独自のラベルセットを備えた、多様で大規模なデータセットです。 1×2.3の解像度で2.8 / 1920インチのセンサーサイズとf / 1080の絞りを備えたしっかりと取り付けられたカメラを使用してデータをキャプチャしました。 選択した絞り、センサーサイズ、焦点距離が1〜20メートルの場合、被写界深度は無限遠になります。つまり、道路上のほとんどのオブジェクトに焦点が合っています。 センチメートルレベルの位置特定精度と慣性運動情報を提供する追加のナビゲーションセンサーでデータを補強しました。 さまざまな照明、天気、交通状況、道路状況の下で南カリフォルニアを実際に運転しているときにデータを収集して、実際の車両操作の複雑さと多様性を把握しました。 これを独自の注釈セットと組み合わせることで、既存の自動車アプリケーション向けの信頼性の高いMLモデルと、高品質のラベル付きデータがないために以前は実現できなかった新しいモデルを開発することができました。

多くのデータ収集ドライブ中にキャプチャされた数百時間の生データから、最初にLAVAデータセットに含めるためにビデオデータの10秒のセグメントを処理およびキュレートしました。 10秒のビデオクリップを手動でキュレートして、車両や歩行者の活動が多いクリップ、交差点、車線変更などの操作などの「興味深い」クリップを特定しました。 これらのクリップは、データセット内の既存のクリップと比較した独自性と、さまざまなタスクのMLモデルのトレーニングに対する全体的な価値に基づいて選択しました。 クリップをキュレートした後、歪みを取り除くためにクリップを処理し、簡単に共有および再生できるように圧縮しました。 次に、確立された分類法に従ってラベル付けするためにこれらのクリップを送信しました。

この投稿では、分類法、分類法の設計の背後にある動機、および分類法をGround Truthラベリングジョブにマッピングして、ラベリングの優先順位の変更に柔軟に対応しながら、高品質のアノテーションを迅速に生成するラベリングパイプラインを作成する方法について説明します。

LAVAデータセットの分類

次のコードは、LAVAデータセットの分類法を示しています。

DRIVE_LEVEL_ATTRIBUTES |── drive_id |── weather: clear|overcast|partly cloudy|rainy|foggy|undefined |── time_of_day: daytime|night|dawn/dusk|undefined └── route: route taken for data capture

CLIP_LEVEL_ATTRIBUTES |── DRIVE_LEVEL_ATTRIBUTES |── clip_id |── scene: highway|tunnel|residential|parking lot|city street|gas station|intersection|roundabout|school zone|contruction|entrance|exit|undefined └── traffic: free-flowing|stop-and-go|undefined └── traffic_density: high|medium|low

FRAME_LEVEL_ATTRIBUTES |── CLIP_LEVEL_ATTRIBUTES |── frame_no |── timestamp |── ignore (x N) | |── 2d_box_coordinates (left, top, right, bottom) ├── vehicle (x N) | |── 2d_box_coordinates (left, top, right, bottom) | |── track_id | |── type: car|van|truck|bus|motorbike|bicycle|undefined | |── occlusion: not occluded|partially occluded|major occlusion | |── license plate | | └── 2d_box_coordinates ├── pedestrian (x N) | |── 2d_box_coordinates (left, top, right, bottom) | |── occlusion: not occluded|partially occluded|major occlusion | └── track_id ├── lane (x N) | |── polyline_coordinates | |── lane_style: solid|dashed | |── lane_type: crosswalk|double other|double white|double yellow|road curb|single other|single white|single yellow | └── lane_direction: horizontal|vertical ├── traffic_light (x N) | |── 2d_box_coordinates (left, top, right, bottom) | |── state: red|green|yellow|undefined | |── is_front: true|false | └── occlusion: not occluded|partially occluded|major occlusion ├── traffic_sign (x N) |── 2d_box_coordinates (left, top, right, bottom) |── type: stop|yield|do not enter|wrong way|school zone|railroad|red and white regulatory|white regulatory|highway construction and maintenance|warning |── is_front: true|false └── occlusion: not occluded|partially occluded|major occlusion

ラベル付けの分類法は、最上部にドライブレベルの属性を持つ階層構造で構成されています。 これらの属性には、天気、ルート、時刻など、データ収集ドライブ全体に適用できるプロパティが含まれます。

ドライブレベルの属性の下には、データセットを構成する10秒のビデオセグメントに対応するクリップレベルの属性があります。 これらのクリップレベルの属性は、親ドライブからドライブレベルの属性を継承し、シーン、トラフィック密度、トラフィックフローなどの追加フィールドも含みます。 これにより、ユーザーはデータセット内の個々のクリップにきめ細かいラベルを割り当てることができ、非常に特定のシーン、トラフィック、または気象条件でモデルがどのように機能するかを測定する実験を行うこともできます。 この種の分析は、実際に展開する前にモデルの準備と欠点を測定するのに非常に価値があり、他の一般的なデータセットでは簡単に達成できません。

クリップレベルの属性の下には、ラベリング階層の最下部にあるフレームレベルの属性があります。これは、10秒のビデオセグメントの各フレームに対応しています。 以前と同様に、フレームレベルの属性はクリップレベルの属性から（およびドライブレベルの属性から間接的に）継承し、さらに画像フレーム内のさまざまな対象オブジェクトの場所とプロパティに対応するフィールドを含みます。 対象のオブジェクトは、静的オブジェクトと動的オブジェクトに大きく分類できます。

車両や歩行者などの動的オブジェクトの場合、2Dボックスの場所とトラックIDにラベルを付けました。 ほとんどのデータセットに見られるこれらの標準属性に加えて、ナンバープレートの位置、ヘッドライトとテールライトの位置と状態など、車両のきめ細かい属性にもラベルを付けました。 これにより、ユーザーは単に車両の位置を検出するだけでなく、モデルをトレーニングすることができます。

次に、シーン内の静的オブジェクトについて、車線、交通標識、信号機に焦点を当てました。 最大XNUMX車線に制限されている一般的な車線検出データセットとは異なり、進行方向のすべての車線（ポリラインを使用）とそのマーカータイプにラベルを付けました。 また、縁石と横断歩道は、自由空間と運転行動を決定する重要なマーカーであるため、ラベルを付けました。 信号機については、すべての可視光とその状態にラベルを付けました。

最後に、交通標識については、表示されているすべての標識とそのタイプ（一時停止、降伏、進入禁止など）にラベルを付けました。 目に見えるすべての信号機と標識にラベルを付けたため、進行方向に対応する信号機にもバイナリインジケーターでマークを付けました。 is_front 前の分類法から。 これにより、ラベルの付いた標識やライトが多数あるという利点があり、モデルのトレーニングが向上すると同時に、実際に運転行動に影響を与えるものを特定することができます。 このラベリング分類法により、ユーザーは、既存のデータセットのいくつかの欠点に決定的に対処しながら、最新の自動車アプリケーションで重要なほとんどのタイプのコンピュータービジョンモデルをトレーニングできます。

レーンラベルの例を次の画像に示します。 車両に垂直な線は横断歩道であり、ラベルには車線のスタイル、タイプ、方向が含まれています。 同様に、車両の左側の車線仕切りと右側の縁石には、前述の分類法に従ったラベルが付いています。

ラベルの付いた車両を次の画像に示します。 車両ラベルは、車両内部オブジェクト（状態とナンバープレート付きのテールライト）に加えて、そのタイプとオクルージョンレベルで構成されます。

次の例は、さまざまな状態、方向、および閉塞レベルのラベル付き信号機と、さまざまなタイプ、方向、および閉塞レベルの交通標識を示しています。

ラベリングアーキテクチャ

このような複雑な分類法をGroundTruthの実際のラベリングタスクにマッピングする場合、分類法のどの部分がラベリングジョブでグループ化されるか、Ground Truthのどのモダリティと注釈タイプが問題にうまく対応するかについて、複数のトレードオフが発生することがよくあります。バッチまたはストリーミングジョブモデルに従うかどうか。

新しいビデオクリップが収集されて利用可能になったときに、ラベラーに永続的に送信したかったので、 GroundTruthストリーミングラベリングジョブ。 これにより、各クリップにラベルを付けた後、ラベルを受け取り、品質保証と調整をリアルタイムで実行することもできました。 また、バッチサイズに応じてタスクタイプごとに複数のジョブではなく、タスクタイプごとにXNUMXつの長寿命のストリーミングラベリングジョブのみが必要だったため、並行して実行する必要のあるラベリングジョブの総数も削減されました。 ストリーミングラベリングジョブの利点の詳細については、を参照してください。 Amazon SageMaker GroundTruthを使用したMLワークフローのリアルタイムデータラベリングパイプライン.

継続的な調整の要件に加えて、分類法は、複数のクラスと複数の注釈タイプに基づいて構成されています。 たとえば、車両にラベルを付けるには、 ビデオオブジェクトトラッキングジョブ ビデオクリップの過程でオブジェクトごとに一貫したインスタンス識別子を生成して動きをキャプチャしますが、交通標識にラベルを付けるには、 ビデオオブジェクトの検出。 分類法では、ラベリングジョブタスクタイプ内にさまざまな注釈タイプも必要です。 たとえば、車両や交通標識には境界ボックスが必要ですが、車線には、道路標識の曲線をより適切にモデル化するために、ポリラインツールを使用した線分が必要です。

たとえば、以下は、バウンディングボックスアノテーションを使用してビデオオブジェクトトラッキングジョブでラベル付けされているビデオのフレームです。

対照的に、次の同様のクリップは、線分がレーンを定義するポリライン注釈を使用しています。

さまざまなデータモダリティでサポートされている使用可能な注釈タイプの詳細については、を参照してください。 ラベルカテゴリとフレーム属性を使用してラベリングカテゴリ設定ファイルを作成する.

単一のタスクでクリップのすべてのラベル付けを実行しようとするのではなく、分類法を複数の並列ラベル付けタスクに分割するXNUMXつの主な理由が見つかりました。

• アノテーションが重複すると、ラベラーのスループットが低下します –シーンに識別対象のオブジェクトが豊富にある場合、XNUMXつのタスクに非常に重複する注釈が多数あることを意味します。 これにより、ワーカーのスループットが低下し、ワーカーによって作成されるエラーの数が増える可能性があります。
• アノテーションタイプが異なると、個別のジョブが必要になる場合があります –現在、SageMaker Ground Truthでは、ラベリングジョブごとにXNUMXつのAnnotationTypeしか許可されていません。 これには、境界ボックスでラベル付けされた分類法を、ポリラインでラベル付けされた分類法から分割する必要があります。
• 複数のラベリングジョブにより柔軟性が向上します –複数のジョブがある場合、エンドユーザーに応じてラベル付けの優先順位が変わるため、優先順位が変わるにつれて人数とリソースを再割り当てする方が簡単です。 たとえば、エンドユーザーが車両検出器など、分類全体のサブセットのみを使用するモデルを構築しようとしている場合、ラベラーは車両専用のすべてのクリップにラベルを付け、優先度が高くなるまでワーカーポータルの他のジョブを無視できます。 。
• 複数の仕事が専門化を可能にします –データラベリングの仕様がより複雑になるにつれて、さまざまなモダリティでのデータラベラーの再トレーニングに関連するコストが高くなることがよくあります。 並行して仕事をするということは、特定の労働者が交通標識のラベリングのみのスペシャリストになることができ、他の労働者が車線の注釈を専門にすることができることを意味し、全体的なスループットを向上させます。

高品質の注釈が生成されるようにするために、入力にクリップを公開することでリアルタイム調整機能を追加しました Amazon シンプル通知サービス （Amazon SNS）タスクタイプの第XNUMXレベルのストリーミングジョブのトピック。完了後、ラベルの付いたクリップを、より熟練したアノテーターの専門グループを使用して最初のパスの出力を確認する調整ストリーミングジョブに送信します。 これらの上級アノテーターは、品質保証を実行し、必要に応じてラベルを変更します。 この調整機能は、GroundTruthの ラベル調整および検証機能.

これらのラベリングジョブを接続する簡単な方法のXNUMXつは、第XNUMXレベルのストリーミングジョブの出力SNSトピックを使用し、それを第XNUMXレベルのストリーミングジョブの入力SNSトピックに直接接続することです（詳細については、を参照してください。 Amazon SageMaker GroundTruthを使用したMLワークフローのリアルタイムデータラベリングパイプライン）。 GroundTruthの上にオーケストレーションレイヤーを追加しました AWSステップ関数, Amazon DynamoDB, AWSラムダ Ground Truthのタイムアウトウィンドウ内で初期または調整のラベル付けタスクが完了しなかった場合に、ビデオクリップを再送信します。

アーキテクチャ図

ラベリングアーキテクチャを推進する全体的な要件について説明したので、有効期限前後のエッジケースを処理しながら、実行中の各ストリーミングジョブへのデータオブジェクトの送信を処理するために実装したステップ関数の機能を大まかに確認しましょう。

ビデオクリップとラベルカテゴリの構成の各組み合わせには、ビデオクリップが各目的のラベリングジョブを通過することを保証するために、独立して実行されるステップ関数呼び出しがあります。 各実行は、主にDynamoDBを介して状態を管理し、アノテーションタスクIDを後続の状態に渡すためにステートマシンの状態のみに依存します。 アノテーションタスクの追跡を担当するDynamoDBテーブルは、状態情報（完了、失敗、または停止）に加えて、クリップ識別子、クリップの入力マニフェストの場所、ラベル付けジョブ出力の出力マニフェストの場所、ラベル属性名などのメタデータを維持します。

このソリューションは、さまざまなラベルカテゴリ構成でストリーミングラベリングジョブを開始するためのAPIも提供します。 このストリーミングジョブは、同じモダリティを持つラベル付けのために送信されたすべてのクリップ（車両の境界ボックスなど）で共有されます。 このソリューションは、これらのラベリングジョブを名前で別のDynamoDBテーブルに保存します。このテーブルは、入力および出力SNSトピックを含む、ソリューションを通じて開始されたストリーミングジョブに関するメタデータを維持します。 ストリーミングジョブのライフサイクル管理用に個別のAPIを使用すると、クリップごとに冗長なラベル付けジョブを起動するのではなく、ラベル付けする固有のモダリティのジョブのみを起動できます。

SageMakerノートブックインスタンスは、各ステップ関数の実行（注釈タスクと呼ばれます）を開始し、アップロードされたビデオクリップのリストを繰り返し処理します。 Amazon シンプル ストレージ サービス （Amazon S3）そして、クリップとモダリティのペアごとにアノテーションタスク作成APIを呼び出します。 アノテーションタスク作成APIは、リクエストされたアノテーションタスクをDynamoDBに保存し、ステップ関数の実行を開始してリクエストされたタスクを処理します。 ノートブックは、クリップの入力場所、XNUMX秒あたりのフレーム数、およびワークフローを構成するラベル付けジョブのリストを注釈タスク作成APIに提供します。このAPIは、その情報を各ステップ関数の実行に渡します。 たとえば、次の注釈タスク定義は、特定のクリップをストリーミングラベリングジョブに送信する必要があることを定義しています。 VOTVehicle、次に、この最初のストリーミングジョブの出力をXNUMX番目のジョブに送信する必要があります AdjVOTVehicle 調整用：

{ "labelingJobs": [ { "jobName": "VOTVehicle", "inputConfig": { "clipS3Uri": "s3://clip_bucket_fake/clip_id_1234", "fps": 1 }, "jobLevel": 1 }, { "jobName": "AdjVOTVehicle", "inputConfig": { "chainFromJobName": "VOTVehicle" }, "jobLevel": 2 } ]
}

次のステートマシン図は、作成された各注釈タスクの全体的なロジックフローを示しています。これには、ビデオクリップと、ビデオクリップを送信するためのラベル付けジョブのリストが含まれています。 すべてのビデオクリップは変換ループを通過します（Transformation, IsDoneTransforming, WaitForTransformComplete）、XNUMX秒あたりの特定のフレームレートで画像フレームを抽出します。 フレーム抽出後、ステートマシンは、初期ラベル付け（TriggerLabelingFirstLevel、CheckForFirstLevelCompletion）のためにフレームをGroundTruthストリーミングジョブに送信します。

ラベル付けの完了後、ステートマシンは、フレームとラベルを送信して、第XNUMXレベルのラベル付けジョブでラベルの裁定を行います（TriggerLabelingSecondLevel, CheckForSecondLevelCompletion).

調整後、ステートマシンはラベルを処理します（PostProcessing）クリップのサマリーメタデータを計算し、Amazon S3に保存します（Complete).

ステートマシンには、からの逆状態遷移も含まれています CheckForFirstLevelCompletion 〜へ TriggerLabelingFirstLevel とから CheckForSecondLevelCompletion 〜へ TriggerLabelingSecondLevel。 これらの状態遷移により、パイプラインは、ラベリングの最初のラウンドで有効期限または問題が検出された場合に、ラベリング用のクリップの送信を再試行できます。 これらの例外ケースについては、次のセクションで詳しく説明します。

SNSトピックを接続し、ビデオクリップのライフサイクルを管理する

前述のように、長時間実行されるアノテーションタスクにストリーミングジョブを使用するには、オーケストレーションレイヤーが必要です。 その理由を説明するために、Amazon SNSを介してストリーミングラベリングジョブを接続する直接的なアプローチについて説明し、潜在的な障害状態について説明します。

次の図は、オーケストレーションのステップ関数からの介入を必要としない、最初のラベリングジョブと調整ジョブを接続するXNUMXつの方法を示しています。

このアプローチは、タスクが迅速に完了する場合（ TaskAvailabilityLifetimeInSeconds ラベル付けジョブの作成時に指定）。 ただし、タスクの可用性よりも長い時間、クリップがラベル付けのためにキューに入れられている場合、クリップはドロップインされる可能性があります。 Amazon シンプル キュー サービス （Amazon SQS）またはパイプライン内のGroundTruth。

このアプローチの代わりに、ラベリングジョブ間の直接のAmazon SNS接続を切断し、代わりに CheckForFirstLevelCompletion 状態は、最初のラベリングジョブからSNSトピックを待機し、オプションで再試行を処理してからに移動します TriggerLabelingSecondLevel。 DynamoDBテーブルは、新しいストリーミングジョブが作成されるたびに、各ラベリングジョブのSNSトピック名を追跡します。

次のセクションでは、各有効期限のケースと緩和策について説明します。

AmazonSQSの時間制限の処理

各ストリーミングラベリングジョブは、指定された入力SNSトピックをSQSキューに接続します。 ラベリングジョブ内でタスクが完了すると、Ground Truthはアイテムをキューから取り出し、ラベリングに使用できるようにします。 Amazon SQSには、アイテムが入力キューの有効期限が切れるまでに14日間の制限があります。つまり、特定のアイテムでキューの14日間の制限に達しないなど、ワーカーが十分なタスクを完了できなかった場合、そのアイテムはドロップされます。

これを処理するXNUMXつの方法は、クリップごとに一意の重複排除識別子を使用してクリップを定期的に再送信することです。 この重複排除識別子は、クリップとともにAmazonSNSメッセージで指定できます。 重複排除IDとキーの詳細については、を参照してください。 重複メッセージ処理。 14日間の制限より前にクリップを再送信する限り、キューには常に有効期限が切れていないバージョンがあります。 Ground Truthが同じ重複排除識別子を持つ5つのクリップを受信した場合、重複を無視するため、ジョブに送信する重複データオブジェクトの数に関係なく、この操作はべき等になります。 14日間のウィンドウに達した場合に備えて、Amazon SQSのデータアイテムの経過時間を繰り返し更新するように、XNUMX日間というかなり短い再試行期間を設定しました。

ワーカーダッシュボードの時間制限の処理

処理するもうXNUMXつの有効期限のケースは、オブジェクトがストリーミングラベリングジョブによって取り込まれ、ワーカーポータルで使用可能であるが、 TaskAvailabilityLifetimeInSeconds。 このタイムアウトは、 HumanTaskConfig ラベル付けの仕事の。 この問題を軽減するXNUMXつの方法は、 MaxConcurrentTaskCount ラベリングジョブの。 これにより、Ground Truthが入力キューから取得するタスクの数が減ります。つまり、タスクタイムアウトは、一度に少数のタスクでのみアクティブになります。 ただし、同時タスク数の調整が少なすぎると、追加のタスクが入力キューから移動され、ラベル付けのために前処理されている間にワーカーがタスクを使い果たす可能性があるため、これは常に解決策とは限りません。

大型を使用してこれを処理しました MaxConcurrentTaskCount ラベリングジョブの出力SNSトピックでGroundTruthタスクの有効期限を検出します。 ステートマシンは、Ground Truthからタスクの有効期限を検出すると、データオブジェクトを再送信して、有効期限タイマーを0にリセットします。XNUMXつの注意点は、Ground Truthは期限切れのデータ項目の重複排除識別子をすでに確認しているため、 Ground Truthがタスクを新規と見なし、ワーカーポータルに表示するように、重複排除識別子を変更しました。

これらの再試行を実行し、クリップがラベリングプロセスを通過するときにクリップを監視するには、前のステップ関数の状態図で説明した外部オーケストレーションが必要です。 ステップ関数は、Amazon SQSタイムアウトを処理するために再試行を実行している場合は以前の重複排除IDを再利用するか、データオブジェクトのフォーマットの有効期限がGround Truthであることがわかっている場合は新しい重複排除IDを生成することにより、前述の両方のケースを処理します。

アーキテクチャ図の手順

長時間実行されるストリーミングジョブでの失敗のケースと軽減策を確認したので、これらがstep関数でどのようにモデル化されているかを確認し、状態遷移がどのように発生するかを詳しく見ていきます。

　 Trigger* 全体的なステップ関数の状態は、ラベリングジョブにクリップを送信します。 このトリガー状態は、クリップにラベルが付けられるのを待つ完了状態のチェックに移行します。 からの状態遷移があります CheckForFirstLevelCompletion 〜へ TriggerLabelingFirstLevel。 これにより、前述の障害ケースのXNUMXつが原因でクリップにラベルを付けることができなかった場合に、完了状態のチェックを元に戻すことができます。

CheckForFirstLevelCompletion ステップ関数を利用してイベント駆動型の待機を実行します タスクトークン。 ステートマシンは、到達すると、現在のステートマシン実行のタスクトークンをDynamoDBに保存します CheckForFirstLevelCompletion、次に、各ストリーミングジョブ出力SNSトピックをリッスンするLambda関数に呼び出しを処理させます SendTaskSuccess or SendTaskFailure ステートマシンの実行に。 これは、特定のクリップでラベリングジョブが完了した直後に、クリップのステートマシンの実行がブロック解除され、次のレベルに流れることを意味します。 次の図は、このワークフローを示しています。

AWS StepFunctionsのコードサンプル

次のステップ関数のコードブロックは、 TriggerFirstLabelingLevel & CheckForFirstLevelCompletion 前の状態図の状態ループ。

　 TriggerFirstLabelingLevel stateは、ラベリングジョブを起動するLambda関数を実行します。 関数が正常に実行されると、ステートマシンはに遷移します。 CheckForFirstLevelCompletion 州。 エラーの場合、ステートマシンは、既知の一時的なエラーである場合は関数の実行を再試行するか、 BatchError でのみ停止させることができます。

"TriggerLabelingFirstLevel": { "Type": "Task", "Resource": "arn:aws:lambda:<ACCOUNT>:function:smgt-workflow-sf-trigger-labeling-job", "Parameters": { "parent_batch_id.$": "$.transformation_step_output.batch_id", "job_level": 1 }, "ResultPath": "$.first_level_step_output", "Next": "CheckForFirstLevelCompletion", "Retry": [{ "ErrorEquals": [ "Lambda.TooManyRequestsException" ], "IntervalSeconds": 5, "MaxAttempts": 8, "BackoffRate": 2 }], "Catch": [{ "ErrorEquals": [ "States.ALL" ], "Next": "BatchError", "ResultPath": "$.error-info" }]
}

次のステップ関数コードブロックは、 CheckForFirstLevelCompletion 前の状態図の状態。 この状態は、ラベリングタスクの完了を待機するLambda関数を実行します。 状態は、ラベル付けの完了を432,000秒（5日間）待機します。その後、ステートマシンはに戻ります。 TriggerLabelingFirstLevel ビデオをGroundTruthSQSキューに送り返します。 エラーが発生すると、ステートマシンは、エラーが一時的なものである場合はLambda関数の実行を再試行し、に移行します。 BatchError エラーが再試行できない場合、またはに戻る場合の状態 TriggerLabelingFirstLevel エラー状態が期限切れになった場合は、データ項目がストリーミングジョブから期限切れになったことを示します。 この最後のエラー状態では、Ground Truth内で有効期限が発生すると、有効期限の直後にアイテムを再送信できます。

"CheckForFirstLevelCompletion": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken", "Parameters": { "FunctionName": "smgt-workflow-sf-wait-batch-completion", "Payload": { "token.$": "$$.Task.Token", "execution_id.$": "$$.Execution.Id", "batch_id.$": "$.first_level_step_output.batch_id" } }, "ResultPath": "$.first_level_completion_step_output", "TimeoutSeconds": 432000, "Next": "TriggerLabelingSecondLevel", "Retry": [{ "ErrorEquals": [ "Lambda.TooManyRequestsException" ], "IntervalSeconds": 5, "MaxAttempts": 8, "BackoffRate": 2 }], "Catch": [ { "ErrorEquals": [ "States.Timeout", "expired" ], "Next": "TriggerLabelingFirstLevel", "ResultPath": "$.error-info" }, { "ErrorEquals": [ "States.ALL" ], "Next": "BatchError", "ResultPath": "$.error-info" } ]
},

AWSLambdaの第XNUMXレベルのラベリングコードサンプル

　 TriggerFirstLabelingLevel 前のセクションで述べた状態は、 smgt-workflow-sf-trigger-labeling-job 実行中のストリーミングラベリングジョブにデータセットオブジェクト（ビデオクリップなど）を送信するLambda関数。

Lambda関数の次のコードブロックは、一連のフレームからジョブを起動する方法を説明しています。 NS lambda_handler 関数は、ラベリングレベル（第XNUMXレベルのラベリングまたは第XNUMXレベルの裁定）と親バッチIDを受け取ります。 起動するジョブをジョブレベルでフィルタリングし、 trigger_labeling_job 関数。 最後に、ジョブが再試行でない場合は、ラベリングジョブのメタデータをDynamoDBデータベースに保存します。

def lambda_handler(event, context): """Figures out which job level tasks need to be created in a level of the step function execution.""" parent_task_id = event["parent_task_id"] job_level = event["job_level"] parent_task = db.get_task_metadata(parent_task_id) # Use a unique ID per step function execution so we can trace # which step function execution sent the data_object. execution_arn = parent_task[Attributes.STEP_FUNCTION_EXECUTION_ID] execution_id = execution_arn.rsplit("-", 1)[1] metadata_type = MetaDataTypeByJobLevel[job_level] # Filter jobs by job level to figure out which jobs should be running. labeling_jobs = parent_task[Attributes.LABELING_JOBS] current_jobs = [job for job in labeling_jobs if job["jobLevel"] == job_level] log.logging.info("Kicking off %d jobs for level %d", len(current_jobs), job_level) task_id = f"{parent_task_id}-{metadata_type.lower()}" prev_task_data = db.get_task_metadata(task_id) # If the task was already sent to the labeling job and hasn't been marked expired. is_retry = prev_task_data is not None and ( prev_task_data[Attributes.TASK_STATUS] == TaskStatus.IN_PROGRESS ) for job in current_jobs: trigger_labeling_job(parent_task_id, task_id, execution_id, job, is_retry) # Only generate the labeling job meta task in the DB if we're not retrying. if not is_retry: try: db.insert_perform_labeling_job_metadata( parent_task_id=parent_task_id, task_id=task_id, task_status=TaskStatus.IN_PROGRESS, task_metadata_type=metadata_type, num_children_taskes=len(current_jobs), ) except botocore.exceptions.ClientError as err: raise Exception(f"failed to put task id {task_id}") from err return { "task_id": task_id, }

次のコードは、ラベリングジョブを起動する関数を示しています trigger_labeling_job, trigger_streaming_job, send_frames_to_streaming_job.

　 trigger_labeling_job 関数はを呼び出します trigger_streaming_job 特定のラベリングジョブに注釈タスクを送信するために必要なパラメーターを持つ関数。 NS trigger_streaming_job 関数は、入力SNSトピックと入力マニフェストを取得し、出力ラベル用のファイルを作成します。 次に、 send_frames_to_streaming_job 入力SNSトピック、マニフェスト、およびさまざまなIDを使用します。

　 send_frames_to_streaming_job 各フレームをループし、重複排除キーを作成し、フレームをDynamoDBに保存し、出力SNSトピックにフレームを公開します。 AmazonSQSとGroundTruthの両方の有効期限を処理するためのロジックは、この関数でエンコードされます。 Ground Truthの有効期限が切れた場合は、新しい重複排除IDを再生成できます。また、Amazon SQSでアイテムの有効期限が切れないようにする場合は、既存の重複排除IDを再利用できます。

def trigger_labeling_job(input_task_id, task_id, execution_id, job_params, is_retry): """Start a labeling job and store metadata in JOB_LEVEL DB entry""" job_input = input_config_to_job_input( input_task_id, job_params["jobName"], job_params["jobLevel"], job_params["inputConfig"], ) trigger_streaming_job(task_id, execution_id, job_input, job_params, is_retry)
def trigger_streaming_job( parent_task_id, execution_id, job_input, job_params, is_retry
): """Start a streaming job""" job_name = job_params["jobName"] streaming_job_details = db.get_job_by_name(job_name) sns_arn = streaming_job_details["InputSnsArn"] task_id = f"{parent_task_id}-{job_name}" input_manifest_lines = fetch_s3(job_input.input_manifest_s3_uri).splitlines() data_object_count = len(input_manifest_lines) if not is_retry: # Create an empty file at this path to indicate this is # where the listener should write output annotations. s3_output_path = ( f"s3://{task_processing_bucket_name}/task_manifests/{task_id}/data.manifest" ) put_s3(s3_output_path, "") db.insert_job_level_metadata( parent_task_id=parent_task_id, task_id=task_id, task_status=TaskStatus.WAIT_FOR_SMGT_RESPONSE, labeling_job_name=job_name, label_attribute_name=streaming_job_details["LabelAttributeName"], label_category_s3_uri=streaming_job_details["LabelCategoryConfigS3Uri"], job_input_s3_uri=job_input.input_manifest_s3_uri, job_output_s3_uri=s3_output_path, num_data_objects=data_object_count, ) send_data_objects_to_streaming_job( task_id, execution_id, input_manifest_lines, sns_arn, is_retry )
def send_data_objects_to_streaming_job( task_id, execution_id, input_manifest_lines, sns_arn, is_retry,
): """Processes a given manifest by creating data_objects in db and sending to SNS""" log.logging.info( f"Sending {len(input_manifest_lines)} data_objects to {sns_arn} for task {task_id}" ) published_messages = [] # Content should be in ground truth manifest format, one json string per line. for data_object_index, label_object in enumerate(input_manifest_lines): log.logging.info(f"Parsing and sending data_object {data_object_index}") label_object = json.loads(label_object) data_object_id = f"{task_id}/{data_object_index}" # Fresh deduplication id to use. try_hash = str(uuid.uuid4())[:4] new_dedup_key = f"{execution_id}/{try_hash}/{data_object_id}" # Deduplication key used in output message. act_dedup_key = None if not is_retry: # This is the first time we've ever generated tasks, so write them to database # and use the brand new deduplication id. response = db.insert_data_object_task_metadata( # Tasks are hierarchical, the current task id becomes the parent task of the data object # level tasks. task_id, # The data object id becomes the new "task_id". data_object_id, TaskStatus.IN_PROGRESS, data_object_index, new_dedup_key, ) log.logging.info( f"data_object task metadata db insert response: {response}" ) act_dedup_key = new_dedup_key else: # We've already sent data objects to labeling jobs, so we are performing # a re-send here. Get the previous task's metadata to figure out what # the data object's state is. prev_data_object_data = db.get_task_metadata(data_object_id) if ( prev_data_object_data[Attributes.TASK_STATUS] == TaskStatus.FRAME_SMGT_EXPIRATION ): # The data object was explicitly marked as expired by the listener lambda. If we # tried to resend with the same deduplication id, the data object wouldn't # show back up in the worker portal because SageMaker Ground Truth will filter it. db.update_task_status(data_object_id, TaskStatus.IN_PROGRESS) act_dedup_key = new_dedup_key else: # Otherwise we are just doing a retry to keep the data objects in the input SQS queue # from getting dropped due to the 2 week limit. Here we reuse the same deduplication # id as before since SageMaker Ground Truth hasn't actually processed this data object # and seen the deduplication id yet. If we used a unique data object, we would end up # with duplicate data objects in the worker portal. act_dedup_key = prev_data_object_data[Attributes.FRAME_DEDUP_ID] log.logger.info("Using deduplication key: %s", act_dedup_key) label_object["dataset-objectid-attribute-name"] = SNS_DEDUPLICATION_KEY_NAME # Use data_object index into manifest as key. # This will allow the listener lambda to find the metadata record associated with # this data_object. label_object[SNS_DEDUPLICATION_KEY_NAME] = act_dedup_key published_messages.append(label_object) topic = sns.Topic(sns_arn) response = topic.publish(Message=json.dumps(label_object)) log.logging.info(f"sns topic publish response: {response}") return published_messages

まとめ

この投稿では、LAVAデータセット、データ収集戦略、ラベル分類、およびGroundTruthを使用した2Dバウンディングボックスのラベル付けアーキテクチャについて説明しました。 データセットは、 Amazon 機械学習ソリューション ラボ と インテリジェントで安全な自動車研究所（LISAラボ） カリフォルニア大学サンディエゴ校（UCSD）

LAVAデータセット用に開発されたラベリングアーキテクチャソリューションにより、継続的な大規模なビデオ収集とラベリングの取り組みが可能になります。 ラベリングアーキテクチャは、フレーム抽出、第XNUMXレベルおよび第XNUMXレベルのラベリング、タイムアウトからビデオクリップのラベリングライフサイクルを管理するパイプラインで構成されています。 このパイプラインは高品質の注釈を生成し、ラベル付けの優先順位の変更に柔軟に対応します。

 　 Amazon MLソリューションラボ チームとMLエキスパートを組み合わせて、組織で最も価値の高いMLの機会を特定して実装できるようにします。 製品およびプロセスでのMLの使用を加速するための支援が必要な場合は、 Amazon MLソリューションラボ.

謝辞

著者は、Larry Ly、David Lu、Sean Liu、Jason Isa、Maitrayee Keskar、Anish Gopalan、Ethan Lee、TristanPhilipを含むLISAのデータセットコレクションおよび注釈チームに感謝します。

著者について

ニナド・クルカルニ Amazon Machine Learning Solutions Labのデータサイエンティストです。 彼は、ビジネスの問題に対処するためのソリューションを構築することにより、顧客がMLとAIを採用するのを支援します。 最近では、スポーツや自動車の顧客向けの予測モデルを構築しています。

ジェレミー・フェルトラッコ アマゾンウェブサービスのアマゾンMLソリューションラボのソフトウェア開発エンジニアです。 彼は、コンピュータービジョン、ロボット工学、機械学習のバックグラウンドを利用して、AWSのお客様がAIの採用を加速できるよう支援しています。

サマンサラフ のデータサイエンティストです Amazon MLソリューションラボ。 彼のバックグラウンドは、ディープラーニング、コンピュータービジョン、時系列データ予測などの応用機械学習です。

アクシャイ・レンジシュ カリフォルニア大学サンディエゴ校の電気およびコンピュータ工学の博士号取得者です。 彼の研究対象は、オブジェクトの検出と追跡、人間の活動の認識、および一般的なドライバーの安全システムに焦点を当てた、コンピュータービジョンと機械学習に及びます。 彼はまた、リアルタイムアルゴリズムのためのセンサーフュージョンとマルチモーダルアプローチにも特に興味を持っています。

ロス・グリア カリフォルニア大学サンディエゴ校の電気およびコンピューター工学の博士課程の学生であり、モハン・トリヴェディ博士の助言を受けています。 LISAでの彼の研究は、機械学習を使用した運転行動の推定と予測に焦点を当てています。

ナチケットデオ カリフォルニア大学サンディエゴ校の電気およびコンピュータ工学の博士号取得者です。 彼の研究対象は、自動運転のためのコンピュータービジョンと機械学習に及び、周囲のエージェントの意図と動きの予測、および安全な制御遷移のためのドライバー活動分析に焦点を当てています。

ジョナサン・バック アマゾンのソフトウェアエンジニアです。 彼の焦点は、機械学習を民主化するための影響力のあるソフトウェアサービスと製品の構築にあります。

スチトラサティアナラヤナ のマネージャーです Amazon MLソリューションラボ、彼女はさまざまな業界のAWSのお客様がAIとクラウドの採用を加速するのを支援しています。 彼女はシンガポールの南洋理工大学でコンピュータービジョンの博士号を取得しています。

モハン・M・トリヴェディ （ライフフェローIEEE、SPIE、およびIAPR）は、カリフォルニア大学サンディエゴ校の電気およびコンピューターエンジニアリングの著名な教授であり、コンピュータービジョンおよびロボティクス研究（CVRR、推定1986）およびインテリジェント研究所の創設ディレクターです。および安全な自動車（LISA、推定2001）。 彼の研究は、高度道路交通システム（ITS）、自動運転、運転支援システム、アクティブセーフティ、人間とロボットの相互作用、マシンビジョンの分野です。 UCSD LISAは、IEEE ITSS Lead InstitutionAwardを受賞しました。 Trivediは、Machine Vision and Applicationsの編集長、IEEE Trans on IVおよびITSCの上級編集者、およびIEEE ComputerSocietyのロボティクス技術委員会の委員長および理事会を務めてきました。
IEEEITSSおよびIEEESMC協会の知事。

PlatoAi。 Web3の再考。 増幅されたデータインテリジェンス。

アクセスするには、ここをクリックしてください。

ソース：https：//aws.amazon.com/blogs/machine-learning/creating-a-large-scale-video-driving-dataset-with-detailed-attributes-using-amazon-sagemaker-ground-truth/