顧客を喜ばせ、パッケージの無駄を最小限に抑えるために、Amazon は毎年出荷される何十億ものパッケージに最適なパッケージ タイプを選択する必要があります。 コーヒーマグのような壊れやすい商品に十分な保護が施されていないと、商品が破損して届き、Amazon は顧客の信頼を失うことになります。 あまりにも多くの保護を使用すると、コストが増加し、ごみ箱がいっぱいになりすぎます。 数億の製品が利用可能であるため、製品のテストと顧客からのフィードバックから継続的に学習するには、スケーラブルな意思決定メカニズムが必要です。
これらの問題を解決するために、Amazon Packaging Innovation チームは機械学習 (ML) モデルを開発しました。このモデルは、商品がメーラー、バッグ、箱などの Amazon のパッケージ タイプに適しているかどうか、または追加のパッケージなしで出荷できるかどうかを分類します。 以前、チームは、に基づいてカスタム パイプラインを開発しました。 AWSステップ関数 毎週のトレーニングと、毎日または毎月の推論ジョブを実行します。 しかし、時間の経過とともに、パイプラインは、新しいアーキテクチャでモデルを立ち上げるのに十分な柔軟性を提供しなくなりました。 新しいパイプラインの開発にはオーバーヘッドがあり、データ サイエンティストと開発者の間で調整が必要でした。 これらの問題を克服し、新しいモデルとアーキテクチャの展開速度を向上させるために、チームはモデルのトレーニングと推論を調整することを選択しました AmazonSageMakerパイプライン.
この投稿では、Step Functions に基づく以前のオーケストレーション アーキテクチャについて説明し、パイプラインを使用したトレーニングと推論アーキテクチャの概要を説明し、Amazon Packaging Innovation チームが達成した柔軟性を強調します。
Amazon Packaging Innovation における以前の ML パイプラインの課題
パッケージのパフォーマンスに関する継続的なフィードバックを組み込むために、増え続けるラベルを使用して新しいモデルが毎週トレーニングされます。 製品の在庫全体の推論は毎月実行され、毎日の推論が実行されて、新しく追加された在庫のジャストインタイム予測が提供されます。
複数のモデルをトレーニングして予測を提供するプロセスを自動化するために、チームは Step Functions に基づいてカスタム パイプラインを開発し、次の手順を調整しました。
- トレーニングおよび推論ジョブのためのデータ準備と、データベースへの予測のロード (Amazonレッドシフト）と AWSグルー.
- モデルのトレーニングと推論 アマゾンセージメーカー.
- を使用した検証セットでのモデル パフォーマンス メトリックの計算 AWSバッチ.
- 使い方 Amazon DynamoDB モデル構成 (トレーニングと検証のデータ分割比率、モデル アーティファクトの場所、モデル タイプ、トレーニングと推論のインスタンス数など)、モデル パフォーマンス メトリック、および正常にトレーニングされた最新のモデル バージョンを保存します。
- モデル パフォーマンス スコアの差の計算、トレーニング ラベルの分布の変化、以前のモデル バージョンと新しいモデル バージョンの入力データのサイズの比較 AWSラムダ 機能します。
- 多数のステップがあることを考えると、パイプラインには、利害関係者に問題を警告するために、各ステップで信頼できる警告システムも必要でした。 これは、 Amazon シンプル キュー サービス （Amazon SQS）および Amazon シンプル通知サービス （アマゾンSNS）。 アラームは、ビジネス関係者、データ サイエンティスト、および開発者に、失敗したステップやモデルおよびデータ メトリックの大きな偏差について通知するために作成されました。
このソリューションを 2 年近く使用した後、チームは、この実装は、単一のモデルがトレーニングされ、検証データセットでスコアリングされる典型的な ML ワークフローでのみうまく機能することに気付きました。 ただし、このソリューションは複雑なモデルに対して十分な柔軟性がなく、障害に対する回復力がありませんでした。 たとえば、アーキテクチャは順次モデルのトレーニングに簡単に対応できませんでした。 パイプライン全体を複製してインフラストラクチャを変更せずに、ステップを追加または削除することは困難でした。 データ分割比率の調整や別の機能セットの選択など、データ処理手順の単純な変更でさえ、データ サイエンティストと開発者の両方による調整が必要でした。 パイプラインがいずれかのステップで失敗すると、最初からやり直す必要があったため、実行が繰り返され、コストが増加しました。 実行の繰り返しや、失敗したステップからの再起動を避けるために、チームは簡略化されたステート マシンの新しいコピーを作成しました。 このトラブルシューティングにより、ステート マシンが急増し、それぞれが一般的に失敗するステップから開始されました。 最後に、トレーニング ジョブでラベル、モデル スコア、またはラベル数の分布に偏差が発生した場合、データ サイエンティストはモデルとそのメトリックを手動で確認する必要がありました。 次に、データ サイエンティストは、モデル バージョンを含む DynamoDB テーブルにアクセスし、テーブルを更新して、次の推論ジョブで正しいモデルが使用されるようにします。
このアーキテクチャの保守には、少なくとも XNUMX つの専用リソースと、開発用の追加のフルタイム リソースが必要でした。 新しいユース ケースに対応するためにパイプラインを拡張することの難しさを考慮して、データ サイエンティストは独自のワークフローの開発を開始しました。その結果、コード ベースの拡大、同様のデータ スキームを持つ複数のデータ テーブル、および分散型モデル モニタリングにつながっていました。 これらの問題が積み重なると、チームの生産性が低下し、オーバーヘッドが増加していました。
これらの課題に対処するために、Amazon Packaging Innovation チームは、SageMaker Pipelines (2020 年 XNUMX 月リリースのお知らせ）。 パイプラインは、エンドツーエンドの ML ワークフローを構築、管理、自動化、スケーリングするための SageMaker の機能です。 Pipelines を使用すると、ML ワークフロー全体でステップ数を減らすことができ、データ サイエンティストがカスタム ML ワークフローを定義できるほど柔軟です。 ステップの監視とログ記録を処理します。 また、新しいモデルを自動的にバージョン管理するモデル レジストリも付属しています。 モデル レジストリには、本番環境で推論するモデルを選択するための承認ワークフローが組み込まれています。 パイプラインでは、同じ引数で呼び出されたステップをキャッシュすることもできます。 以前の実行が見つかった場合、キャッシュが作成されます。これにより、正常に完了したステップを再計算する代わりに、簡単に再起動できます。
評価プロセスにおいて、Pipelines は、現在および将来のワークフローをサポートおよび拡張するための機能の柔軟性と可用性において、他のソリューションから際立っていました。 Pipelines に切り替えることで、開発者はプラットフォームのメンテナンスやトラブルシューティングに費やす時間を解放し、新しい機能の追加に注意を向けることができました。 この投稿では、Pipelines を使用した Amazon Packaging Innovation チームでのトレーニングと推論のワークフローの設計を紹介します。 また、Pipelines に切り替えることでチームが実現したメリットとコスト削減についても説明します。
トレーニングパイプライン
Amazon Packaging Innovation チームは、ますます多くのラベルを使用して、すべてのパッケージ タイプのモデルをトレーニングしています。 次の図は、プロセス全体の概要を示しています。
ワークフローは、Amazon Redshift データベースからラベルと特徴を抽出し、データをアンロードすることから始まります。 Amazon シンプル ストレージ サービス (Amazon S3) スケジュールされた抽出、変換、ロード (ETL) ジョブを介して。 入力データとともに、モデル タイプとパラメータを含むファイル オブジェクトが S3 バケットに配置されます。 このファイルは、Lambda 関数を介してパイプライン トリガーとして機能します。
次のステップは完全にカスタマイズ可能であり、SageMaker Python SDK for Pipelines を使用してデータ サイエンティストによって完全に定義されます。 この投稿で提示するシナリオでは、入力データはトレーニング セットと検証セットに分割され、SageMaker 処理ジョブを起動することによって S3 バケットに保存されます。
Amazon S3 でデータの準備が整うと、SageMaker トレーニングジョブが開始されます。 モデルが正常にトレーニングおよび作成された後、SageMaker バッチ変換ジョブを介して検証データに対してモデル評価ステップが実行されます。 次に、モデルメトリクスは、SageMaker 処理ジョブを使用して、前の週のモデルメトリクスと比較されます。 チームは、モデルのパフォーマンスの偏差を評価するための複数のカスタム基準を定義しました。 モデルは、これらの基準に基づいて却下または承認されます。 モデルが拒否された場合、以前に承認されたモデルが次の推論ジョブに使用されます。 モデルが承認されると、そのバージョンが登録され、そのモデルが推論ジョブに使用されます。 利害関係者は、結果に関する通知を次の方法で受け取ります。 アマゾンクラウドウォッチ アラーム。
からの次のスクリーンショット Amazon SageMakerスタジオ トレーニング パイプラインの手順を示します。
Pipelines は各パイプラインの実行を追跡します。これは Studio で監視できます。 または、次を使用して実行の進行状況を照会できます。 ボト3 または AWSコマンドラインインターフェイス (AWS CLI)。 Studio でモデル メトリックを視覚化し、異なるモデル バージョンを比較できます。
推論パイプライン
Amazon Packaging Innovation チームは、商品の在庫全体の予測を毎月更新しています。 毎日の予測が生成され、最新のトレーニング済みモデルを使用して、新しく追加された在庫のジャストインタイムのパッケージングの推奨事項が提供されます。 これには、推論パイプラインをさまざまな量のデータで毎日実行する必要があります。 次の図は、このワークフローを示しています。
トレーニング パイプラインと同様に、推論は Amazon Redshift から S3 バケットにデータをアンロードすることから始まります。 Amazon S3 に配置されたファイル オブジェクトは、推論パイプラインを開始する Lambda 関数をトリガーします。 機能は推論用に準備され、データは SageMaker Processing ジョブを使用して適切なサイズのファイルに分割されます。 次に、パイプラインは、予測を実行して S3 バケットにロードするための最新の承認済みモデルを識別します。 最後に、SageMaker Processing ジョブ内の boto3-data API を使用して、予測が Amazon Redshift に読み込まれます。
Studio からの次のスクリーンショットは、推論パイプラインの詳細を示しています。
SageMaker Pipelines で ML ワークフローを設計することを選択する利点
このセクションでは、モデルのトレーニングと推論をパイプラインに切り替えることで Amazon Packaging Innovation チームが実現した利点について説明します。
すぐに使用できる本番レベルの MLOps 機能
次の ML パイプライン ソリューションに向けて社内外のさまざまなソリューションを比較しながら、3 人のデータ サイエンティストが Studio Jupyter 環境で Pipelines を使用して ML ワークフローのフル バージョンのプロトタイプを作成し、XNUMX 週間以内に開発することができました。 プロトタイピングの段階でも、モデルのバージョン管理、キャッシング、アラームなど、実稼働レベルのワークフローに必要なすべてのインフラストラクチャ コンポーネントが Pipelines によって提供されていることが明らかになりました。 これらの機能をすぐに利用できるということは、それらの開発とカスタマイズに余分な時間が費やされないことを意味していました。 これは価値の明確な実証であり、パイプラインが適切なソリューションであると Amazon Packaging Innovation チームを確信させました。
ML モデルの開発における柔軟性
チームのデータ サイエンティストにとって最大のメリットは、さまざまなモデルを簡単に実験して反復できるようになったことです。 ML 作業にどのようなフレームワークが好まれ、それに含まれるステップと機能の数に関係なく、パイプラインは彼らのニーズに対応しました。 データ サイエンティストは、追加の機能やステップを追加するためにソフトウェア開発スプリントに着手するのを待つ必要なく、実験する権限を与えられました。
コスト削減
SageMaker のパイプライン機能は 無料です。: トレーニングと推論に関連するコンピューティング リソースとストレージに対してのみ料金が発生します。 ただし、コストについて考えるときは、使用するサービスのコストだけでなく、ワークフローの維持、デバッグ、パッチ適用に必要な開発者の時間も考慮する必要があります。 Pipelines を使用したオーケストレーションは、より少ない要素と使い慣れたインフラストラクチャで構成されているため、よりシンプルです。 以前は、新しい機能を追加するには、Amazon Packaging Innovation チームで少なくとも XNUMX 人 (データサイエンティストとソフトウェアエンジニア) がそれを実装する必要がありました。 再設計されたパイプラインにより、機械学習コードを追跡するための単一のリポジトリの作成、AWS アカウント全体でのモデルのデプロイの簡素化、統合された ETL ジョブの開発、および共通の再利用可能な機能。
チームがパイプライン全体を再実行する可能性が低くなったため、同様の入力でステップをキャッシュする機能もコストの削減に貢献しました。 代わりに、障害点から簡単に開始できます。
まとめ
Amazon Packaging Innovation チームは、ML モデルを毎月トレーニングし、推奨される製品パッケージ タイプの予測を定期的に更新しています。 これらの推奨事項は、無駄を減らし、注文ごとに顧客を喜ばせることで、複数のチームおよび会社全体の目標を達成するのに役立ちました。 トレーニングと推論のパイプラインは、定期的に確実に実行する必要がありますが、モデルの継続的な改善を可能にする必要があります。
Pipelines への移行により、チームは 2 か月以内に 5 つの新しいマルチモーダル モデル アーキテクチャを本番環境にデプロイできました。 以前のアーキテクチャを使用して新しいモデルをデプロイするには、1 日 (同じモデル アーキテクチャの場合) から 4 か月 (新しいモデルのアーキテクチャの場合) が必要でした。 Pipelines を使用して同じモデルをデプロイすることで、チームは開発時間を同じモデル アーキテクチャで 5 時間、新しいモデル アーキテクチャで 80 日に短縮することができました。 これは、労働時間のほぼ XNUMX% の節約に相当します。
その他のリソース
詳細については、次のリソースを参照してください。
著者について
アンクルシュクラ パロアルトを拠点とする AWS-ProServe のプリンシパル データ サイエンティストです。 Ankur は 15 年以上のコンサルティング経験を持ち、顧客と直接やり取りして、技術を使ってビジネス上の問題を解決する手助けをしています。 彼は、AWS 内で複数のグローバルな応用科学および ML-Ops イニシアチブを率いています。 余暇には、読書や家族との時間を楽しんでいます。
アカシュ・シングラ Amazon Packaging Innovation チームのシニア システム開発エンジニアです。 彼は、17 年以上にわたり、複数の業種のテクノロジーを通じて重要なビジネス上の問題を解決してきた経験があります。 彼は現在、さまざまなパッケージング中心のアプリケーションの NAWS インフラストラクチャをアップグレードして、それらをより適切にスケーリングすることに重点を置いています。
ヴィタリナ・コマシコ は、AWS プロフェッショナル サービスのデータ サイエンティストです。 彼女は薬理学と毒物学の博士号を取得していますが、「データ生成と結果の解釈を自分で行いたい」という理由で、実験研究からデータ サイエンスに移行しました。 キャリアの早い段階で、彼女はバイオテクノロジーおよび製薬会社で働いていました。 AWS では、さまざまな業界の顧客の問題を解決し、顧客固有の課題について学ぶことを楽しんでいます。
プラサント・メイヤッパン Amazon Packaging Innovation に 4 年以上携わっている上級応用科学者です。 彼は、機械学習の業界で 6 年以上の経験があり、製品を出荷して、検索の顧客エクスペリエンスと顧客のパッケージング エクスペリエンスを向上させてきました。 Prasanth は持続可能性に情熱を傾けており、気候変動の統計モデリングで博士号を取得しています。
マシュー・ベイルズ は、お客様からのフィードバックと機械学習を使用してパッケージ タイプの選択を最適化するために取り組んでいるシニア リサーチ サイエンティストです。 Amazon に入社する前は、ドイツで素粒子物理学のシミュレーションを行うポスドクとして働いていました。前世では、新興企業で放射性医療インプラント デバイスの生産マネージャーを務めていました。 彼は博士号を取得しています。 ミシガン大学で物理学の学士号を取得しています。
