ゼファーネットのロゴ

Booking.com が Amazon SageMaker を使用して ML 実験フレームワークを最新化した方法 |アマゾン ウェブ サービス

日付:

この投稿は、Booking.com の Kostia Kofman 氏と Jenny Tokar 氏の共著です。

オンライン旅行業界の世界的リーダーとして、 Booking.com はサービスを強化し、顧客にカスタマイズされたシームレスなエクスペリエンスを提供するための革新的な方法を常に模索しています。 Booking.com のランキング チームは、ユーザーに最高の結果を提供するために検索および推奨アルゴリズムが最適化されていることを確認する上で重要な役割を果たしています。

社内リソースを他の社内チームと共有しているため、ランキング チームの機械学習 (ML) 科学者は、モデルのトレーニングや実験のためのリソースにアクセスするのに長い待ち時間が発生することが多く、迅速な実験や革新を行う能力に課題がありました。最新化された ML インフラストラクチャの必要性を認識し、ランキング チームは、 アマゾンセージメーカー ML モデルを大規模に構築、トレーニング、デプロイします。

Booking.comとの提携 AWSプロフェッショナルサービス 次の改善により、改良された ML モデルの市場投入までの時間を短縮するソリューションを構築します。

  • トレーニングと実験のためのリソースの待ち時間の短縮
  • ハイパーパラメータ調整などの重要な ML 機能の統合
  • ML モデルの開発サイクルの短縮

待ち時間が短縮されるということは、チームがモデルを迅速に繰り返して実験し、より速いペースで洞察を得ることができることを意味します。 SageMaker オンデマンドで利用可能なインスタンスを使用すると、待ち時間を 10 分の 1 に短縮できました。ハイパーパラメータ調整やモデルの説明可能性などの重要な ML 機能がオンプレミスに不足していました。チームのモダナイゼーションの取り組みでは、これらの機能が導入されました。 Amazon SageMaker 自動モデルチューニング & Amazon SageMaker の明確化。最後に、チームの目標は、コードに加えられた各変更について即座にフィードバックを受け取り、フィードバック ループを数分から瞬時に短縮し、それによって ML モデルの開発サイクルを短縮することでした。

この投稿では、Booking.com のランキング チームが SageMaker の機能を利用して ML 実験フレームワークを最新化するために行った取り組みについて詳しく説明します。そうすることで、既存の課題を克服しただけでなく、検索エクスペリエンスも向上し、最終的には世界中の何百万人もの旅行者に利益をもたらしました。

近代化へのアプローチ

ランキング チームは数人の ML サイエンティストで構成されており、各サイエンティストは独自のモデルをオフラインで開発してテストする必要があります。オフライン評価に従ってモデルが成功したと判断された場合は、実稼働 A/B テストに移行できます。オンラインで改善が見られる場合は、すべてのユーザーに展開できます。

このプロジェクトの目標は、ML 科学者がカスタマイズ可能なツールを簡単に実行できる、ユーザーフレンドリーな環境を作成することでした。 AmazonSageMakerモデル構築パイプライン 長く複雑なモジュールをコード化する必要なく、仮説をテストできます。

直面したいくつかの課題の 1 つは、既存のオンプレミス パイプライン ソリューションを AWS で使用できるように適応させることでした。このソリューションには、次の 2 つの主要なコンポーネントが含まれていました。

  • 既存のコードの変更と拡張 – ソリューションの最初の部分では、AWS インフラストラクチャとの互換性を持たせるための既存のコードの変更と拡張が行われました。これは、オンプレミスからクラウドベースの処理にスムーズに移行するために非常に重要でした。
  • クライアントパッケージ開発 – SageMaker API と以前の既存のコードのラッパーとして機能するクライアント パッケージが開発されました。このパッケージは 2 つを組み合わせたもので、ML サイエンティストがコーディングなしで ML パイプラインを簡単に構成およびデプロイできるようにします。

SageMaker パイプライン構成

カスタマイズ可能性はモデル構築パイプラインの鍵であり、それは以下によって達成されました。 config.ini、広範な構成ファイル。このファイルは、パイプラインのすべての入力と動作のコントロール センターとして機能します。

内部で利用可能な構成 config.ini 次のとおりです。

  • パイプラインの詳細 – 実践者は、パイプラインの名前を定義し、実行するステップを指定し、出力を保存する場所を決定できます。 Amazon シンプル ストレージ サービス (Amazon S3)、使用するデータセットを選択します
  • AWSアカウントの詳細 – パイプラインをどのリージョンで実行するか、どのロールを使用するかを決定できます
  • ステップ固有の構成 – パイプラインの各ステップについて、使用するインスタンスの数やタイプ、関連するパラメーターなどの詳細を指定できます。

次のコードは、構成ファイルの例を示しています。

[BUILD]
pipeline_name = ranking-pipeline
steps = DATA_TRANFORM, TRAIN, PREDICT, EVALUATE, EXPLAIN, REGISTER, UPLOAD
train_data_s3_path = s3://...
...
[AWS_ACCOUNT]
region = eu-central-1
...
[DATA_TRANSFORM_PARAMS]
input_data_s3_path = s3://...
compression_type = GZIP
....
[TRAIN_PARAMS]
instance_count = 3
instance_type = ml.g5.4xlarge
epochs = 1
enable_sagemaker_debugger = True
...
[PREDICT_PARAMS]
instance_count = 3
instance_type = ml.g5.4xlarge
...
[EVALUATE_PARAMS]
instance_type = ml.m5.8xlarge
batch_size = 2048
...
[EXPLAIN_PARAMS]
check_job_instance_type = ml.c5.xlarge
generate_baseline_with_clarify = False
....

config.ini は、Git によって管理されるバージョン管理されたファイルで、トレーニング パイプラインの実行を成功させるために必要な最小限の構成を表します。開発中に、バージョン管理されていないローカル構成ファイルを利用できます。これらのローカル構成ファイルには、特定の実行に関連する設定のみを含める必要があるため、複雑さのない柔軟性が実現します。パイプライン作成クライアントは、複数の構成ファイルを処理するように設計されており、最新の構成ファイルが以前の設定より優先されます。

SageMaker パイプラインのステップ

パイプラインは次のステップに分かれています。

  • トレーニングとテストのデータ準備 – テラバイトの生データが S3 バケットにコピーされ、次の方法で処理されます。 AWSグルー Spark 処理用のジョブを作成し、互換性を保つためにデータが構造化およびフォーマットされます。
  • トレーニング – トレーニング ステップでは、SageMaker トレーニング ジョブに TensorFlow エスティメーターを使用します。トレーニングは Horovod を使用して分散方式で行われ、結果のモデルアーティファクトは Amazon S3 に保存されます。ハイパーパラメータ調整の場合、ハイパーパラメータ最適化 (HPO) ジョブを開始して、目的のメトリックに基づいて最適なモデルを選択できます。
  • 予測する – このステップでは、SageMaker 処理ジョブは、保存されたモデル アーティファクトを使用して予測を行います。このプロセスは利用可能なマシン上で並行して実行され、予測結果は Amazon S3 に保存されます。
  • 評価します – PySpark 処理ジョブは、カスタム Spark スクリプトを使用してモデルを評価します。評価レポートは Amazon S3 に保存されます。
  • 調子 – 評価後、モデルの品質に関する決定が行われます。この決定は、構成ファイルで定義された条件メトリックに基づいて行われます。評価が肯定的であれば、モデルは承認済みとして登録されます。それ以外の場合は、拒否されたものとして登録されます。どちらの場合も、評価および説明可能性レポートが生成されると、モデル レジストリに記録されます。
  • 推論用のパッケージモデル – 処理ジョブを使用して、評価結果が肯定的であれば、モデルはパッケージ化され、Amazon S3 に保存され、内部 ML ポータルにアップロードできるように準備されます。
  • 説明する – SageMaker Clear は説明可能性レポートを生成します。

2 つの異なるリポジトリが使用されます。最初のリポジトリには ML パイプラインの定義とビルド コードが含まれ、2 番目のリポジトリには、処理、トレーニング、予測、評価などの各ステップ内で実行されるコードが含まれます。このデュアル リポジトリ アプローチにより、モジュール性が向上し、科学チームとエンジニアリング チームが ML コードと ML パイプライン コンポーネントを独立して反復できるようになります。

次の図は、ソリューションのワークフローを示しています。

自動モデルチューニング

ML モデルをトレーニングするには、ビジネス用途向けの堅牢でパフォーマンスの高い最終モデルを構築するために、複数のトレーニング実験を反復するアプローチが必要です。 ML 科学者は、適切なモデル タイプを選択し、正しい入力データセットを構築し、トレーニング中にモデル学習プロセスを制御するハイパーパラメーターのセットを調整する必要があります。

モデルのトレーニング プロセスのハイパーパラメーターに適切な値を選択すると、モデルの最終的なパフォーマンスに大きな影響を与える可能性があります。ただし、特定の使用例にどの値が適切であるかを判断する固有の方法や定義された方法はありません。ほとんどの場合、ML サイエンティストは、わずかに異なるハイパーパラメータのセットを使用して複数のトレーニング ジョブを実行し、モデルのトレーニング メトリクスを観察し、次の反復でより有望な値を選択する必要があります。モデルのパフォーマンスを調整するこのプロセスはハイパーパラメーター最適化 (HPO) とも呼ばれ、場合によっては数百回の実験が必要になることがあります。

ランキング チームは、非常に限られた数のトレーニング ジョブしか並行して起動できないため、オンプレミス環境で HPO を手動で実行していました。したがって、HPO を順番に実行し、ハイパーパラメータ値のさまざまな組み合わせを手動でテストして選択し、定期的に進行状況を監視する必要がありました。これにより、モデルの開発と調整のプロセスが延長され、実行可能な時間内に実行できる HPO 実験の総数が制限されました。

AWS への移行により、ランキング チームは SageMaker の自動モデル チューニング (AMT) 機能を使用できるようになりました。 AMT を使用すると、ランキング ML サイエンティストは、関心のあるハイパーパラメータ範囲内で何百ものトレーニング ジョブを自動的に起動し、選択したメトリクスに従って最終モデルの最高パフォーマンスのバージョンを見つけることができます。ランキング チームは、ハイパーパラメータの選択に関して 4 つの異なる自動チューニング戦略から選択できるようになりました。

  • グリッド検索 – AMT は、すべてのハイパーパラメータがカテゴリ値であることを期待し、異なるカテゴリの組み合わせごとにトレーニング ジョブを起動し、ハイパーパラメータ空間全体を探索します。
  • ランダム検索 – AMT は、指定された範囲内でハイパーパラメータ値の組み合わせをランダムに選択します。異なるトレーニング ジョブとパラメーター値の選択の間には依存関係がないため、この方法を使用して複数の並行トレーニング ジョブを起動でき、最適なパラメーター選択プロセスを高速化できます。
  • ベイジアン最適化 – AMT は、ベイジアン最適化実装を使用して、ハイパーパラメータ値の最適なセットを推測し、回帰問題として扱います。以前にテストされたハイパーパラメータの組み合わせと、新しいパラメータ選択によるモデル トレーニング ジョブへの影響を考慮し、より少ない実験でよりスマートなパラメータ選択を最適化しますが、以前のトレーニングから常に学習できるようにトレーニング ジョブを順番にのみ起動します。
  • ハイパーバンド – AMT は、実行中のトレーニング ジョブの中間結果と最終結果を使用して、より有望な結果を示し、パフォーマンスが低い結果を自動的に停止するハイパーパラメーター構成を備えたトレーニング ジョブにリソースを動的に再割り当てします。

SageMaker の AMT により、ランキング チームは初めて複数の並列実験を実行し、自動調整戦略を使用し、数日以内に 2 桁のトレーニング ジョブを実行できるようになり、モデル開発のハイパーパラメータ調整プロセスに費やす時間を削減できました。敷地内では実現不可能なこと。

SageMaker Clear によるモデルの説明可能性

モデルの説明可能性により、ML 実践者は、特徴量エンジニアリングと選択の決定に貴重な洞察を提供することで、ML モデルの性質と動作を理解できるようになり、結果的にモデル予測の品質が向上します。ランキング チームは、説明可能性の洞察を 2 つの方法で評価したいと考えていました。1 つは、特徴入力がデータセット全体のモデル出力にどのような影響を与えるかを理解すること (グローバルな解釈可能性)、もう 1 つは、対象のデータ点での特定のモデル予測に対する入力特徴の影響を発見できることです (ローカルでの解釈可能性)。このデータを使用すると、ランキング ML サイエンティストは、モデルのパフォーマンスをさらに向上させる方法や、モデルが時折提供する困難な予測結果を考慮する方法について情報に基づいた決定を下すことができます。

SageMaker Clear を使用すると、次を使用してモデルの説明可能性レポートを生成できます。 Shapley 添加剤の説明 (SHAP) SageMaker でモデルをトレーニングする場合、グローバルとローカルの両方のモデルの解釈可能性をサポートします。モデルの説明可能性レポートに加えて、SageMaker Clarify は、トレーニング前のバイアス メトリクス、トレーニング後のバイアス メトリクス、および部分依存プロットの分析の実行をサポートします。このジョブは AWS アカウント内で SageMaker 処理ジョブとして実行され、SageMaker パイプラインと直接統合されます。

グローバル解釈可能性レポートはジョブ出力で自動的に生成され、 Amazon SageMakerスタジオ トレーニング実験の実行の一部としての環境。このモデルが SageMaker モデル レジストリに登録されると、レポートはモデル アーティファクトにさらにリンクされます。これらのオプションの両方を使用することで、ランキング チームはさまざまなモデル バージョンとその動作の変更を簡単に追跡することができました。

単一の予測 (ローカル解釈値) に対する入力特徴の影響を調査するために、ランキング チームはパラメーターを有効にしました。 save_local_shap_values SageMaker Clarify ジョブに含まれており、SageMaker Studio の Jupyter ノートブックでさらに分析するために S3 バケットからそれらをロードすることができました。

上の画像は、任意の ML モデルのモデルの説明可能性がどのように見えるかを示す例を示しています。

トレーニングの最適化

ディープラーニング (DL) の台頭により、ML は計算能力と膨大な量のデータにますます依存するようになりました。 ML の実践者は一般に、これらの複雑なモデルをトレーニングするときにリソースを効率的に使用するというハードルに直面します。大規模なコンピューティング クラスターでトレーニングを実行すると、I/O ボトルネック、カーネル起動の遅延、メモリ制約、十分に活用されていないリソースなど、リソース使用率の最適化においてさまざまな課題が発生します。トレーニング ジョブの構成が効率を高めるために微調整されていない場合、これらの障害によりハードウェアの使用が最適化されなかったり、トレーニング時間が長くなったり、トレーニングの実行が不完全になったりする可能性があります。これらの要因により、プロジェクトのコストが増加し、スケジュールが遅れます。

CPU と GPU の使用率のプロファイリングは、これらの非効率性を理解し、モデル内のさまざまな TensorFlow 操作のハードウェア リソース消費 (時間とメモリ) を特定し、パフォーマンスのボトルネックを解決し、最終的にはモデルの実行を高速化するのに役立ちます。

ランキング チームは、次のフレームワーク プロファイリング機能を使用しました。 Amazon SageMakerデバッガ (現在は非推奨になっており、 Amazon SageMaker プロファイラー) これらのトレーニング ジョブを最適化します。これにより、CPU と GPU の使用率、GPU でのカーネルの実行、CPU でのカーネルの起動、同期操作、GPU 間のメモリ操作、カーネルの起動と対応する実行の間の遅延、CPU 間のデータ転送など、CPU と GPU 上のすべてのアクティビティを追跡できます。そしてGPU。

ランキングチームも使用しました TensorFlow プロファイラー の特徴 テンソルボードこれは、TensorFlow モデルのトレーニングのプロファイリングにさらに役立ちました。 SageMaker は現在 TensorBoard とさらに統合 また、TensorBoard の視覚化ツールを SageMaker に導入し、SageMaker のトレーニングおよびドメインと統合します。 TensorBoard を使用すると、TensorBoard 視覚化プラグインを使用してモデルのデバッグ タスクを実行できます。

これら 350 つのツールの助けを借りて、ランキング チームは TensorFlow モデルを最適化し、ボトルネックを特定し、平均トレーニング ステップ時間を CPU で 140 ミリ秒から 170 ミリ秒に、GPU で 70 ミリ秒から 60 ミリ秒に短縮し、59% 高速化することができました。とXNUMX%、それぞれ。

ビジネス成果

移行の取り組みは、可用性、スケーラビリティ、弾力性の強化を中心としており、これにより、モデル トレーニングの頻度の増加と障害の減少、トレーニング時間の最適化、高度な ML 機能などに代表されるように、ML 環境が新たなレベルの優れた運用性を実現しました。

モデルのトレーニングの頻度と失敗

毎月のモデル トレーニング ジョブの数は 50 倍に増加し、モデルの最適化の頻度が大幅に増加しました。さらに、新しい ML 環境により、パイプライン実行の失敗率が減少し、約 20% から 5% に低下しました。失敗したジョブの処理時間は、平均 XNUMX 時間以上から無視できる XNUMX 秒まで大幅に短縮されました。これにより、業務効率が大幅に向上し、リソースの浪費が減少しました。

トレーニング時間の最適化

移行に伴う効率は、SageMaker ベースの GPU トレーニングを通じて向上します。この変更により、モデルのトレーニング時間が以前の 60 分の 12 に短縮されました。以前は、深層学習モデルのトレーニング プロセスには CPU で約 XNUMX 時間を消費していました。これは GPU で約 XNUMX 時間に短縮されました。この改善により、時間が節約されるだけでなく、開発サイクルが短縮され、より迅速なイテレーションとモデルの改善が可能になります。

高度な ML 機能

移行の成功の中心となるのは、ハイパーパラメーターの調整とモデルの説明可能性を含む SageMaker 機能セットの使用です。さらに、移行により、次を使用したシームレスな実験追跡が可能になりました。 AmazonSageMakerの実験、より洞察力に富んだ生産的な実験が可能になります。

最も重要なことは、新しい ML 実験環境が、現在運用されている新しいモデルの開発の成功をサポートしたことです。このモデルはツリーベースではなくディープラーニングであり、オンライン モデルのパフォーマンスに顕著な改善がもたらされました。

まとめ

この投稿では、スケーラブルな ML フレームワークの実装につながり、ランキング チームの ML モデルの市場投入までの時間を短縮することに成功した、AWS プロフェッショナル サービスと Booking.com のコラボレーションの概要を説明しました。

Booking.com のランキング チームは、クラウドと SageMaker への移行が有益であることが証明されており、機械学習オペレーション (MLOps) の実践を適応させることで、ML エンジニアと科学者が自分たちの技術に集中して開発速度を向上できることを学びました。チームは、コードと機能を共有する ML 実践者との対話や専用セッションを通じて、Booking.com の ML コミュニティ全体と学習内容や行った作業を共有しています。この投稿が知識を共有する別の方法として役立つことを願っています。

AWS プロフェッショナル サービスは、チームが AWS でスケーラブルで本番環境に対応した ML を開発するのを支援する準備ができています。 詳細については、次を参照してください。 AWSプロフェッショナルサービス または、アカウント マネージャーを通じてご連絡ください。


著者について

ローレンス・ファン・デル・マース は、AW​​S プロフェッショナル サービスの機械学習エンジニアです。彼は、AWS で機械学習ソリューションを構築している顧客と緊密に連携し、分散トレーニング、実験、責任ある AI を専門とし、機械学習が私たちが知っている世界をどのように変えるかについて情熱を持っています。

ダニエル・ザギバ AWS プロフェッショナル サービスのデータ サイエンティストです。彼は、AWS の顧客向けにスケーラブルな本番グレードの機械学習ソリューションの開発を専門としています。彼の経験は、自然言語処理、生成 AI、機械学習の運用など、さまざまな分野に及びます。

コスティア・コフマン Booking.com のシニア機械学習マネージャーで、検索ランキング ML チームを率い、Booking.com の最も広範な ML システムを監督しています。パーソナライゼーションとランキングの専門知識を活かし、最先端のテクノロジーを活用して顧客エクスペリエンスを向上させることに取り組んでいます。

ジェニー・トーカー Booking.com の検索ランキング チームのシニア機械学習エンジニアです。彼女は、効率、信頼性、拡張性、革新性を特徴とするエンドツーエンドの ML パイプラインの開発を専門としています。 Jenny の専門知識により、彼女のチームは毎日何百万ものユーザーにサービスを提供する最先端のランキング モデルを作成できます。

アレクサンドラ・ドキッチ は、AW​​S プロフェッショナル サービスのシニア データ サイエンティストです。彼女は、顧客が AWS 上で革新的な AI/ML ソリューションを構築できるようサポートすることに喜びを感じており、データの力によるビジネス変革に興奮しています。

ルバ・プロツィバ AWS プロフェッショナル サービスのエンゲージメント マネージャーです。彼女は、AWS の顧客がビジネス価値を最大化し、イノベーションのスピードを加速できるようにするデータおよび GenAI/ML ソリューションの提供を専門としています。

スポット画像

最新のインテリジェンス

スポット画像