Amazon Web Services ブログ

Category: Artificial Intelligence

Amazon SageMaker マルチモデルエンドポイントを使用して推論コストを削減する

ビジネスでは、コホートやセグメントに基づくモデルではなく、ユーザーごとの機械学習 (ML) モデルをますます発展させています。個々のユーザーデータに基づき、数百から数十万のあらゆる場所からのカスタムモデルをトレーニングしています。たとえば、音楽ストリーミングサービスでは、各リスナーの再生履歴に基づくカスタムモデルをトレーニングし、音楽のおすすめをパーソナライズしています。タクシーサービスでは、各年の交通パターンに基づくカスタムモデルをトレーニングし、乗客の待ち時間を予測しています。 ユースケースごとにカスタム ML モデルを構築すると、推論の精度が向上するという利点がありますが、モデルのデプロイコストが大幅に増大するという欠点もあり、本番環境で多くのモデルを管理するのが困難となっています。このような課題は、同時にすべてのモデルにアクセスはしないがいつでも利用可能にしておく必要がある場合により顕著になります。Amazon SageMaker マルチモデルエンドポイントは、このような弱点に対応し、複数の ML モデルをデプロイする、スケーラブルでコスト効率の高いソリューションをビジネスに提供します。 Amazon SageMaker はモジュラー型のエンドツーエンドサービスで、大規模な ML モデルの構築、トレーニング、デプロイを容易にします。ML モデルはトレーニング後、完全マネージド型でリアルタイムの推論を低レイテンシーで実行可能な Amazon SageMaker エンドポイントにデプロイできます。単一のエンドポイントに複数のモデルをデプロイし、マルチモデルエンドポイントを使用する単一のサービングコンテナにより稼働させることが可能になります。エンドポイントと、その基盤となるコンピューティングインスタンスの利用率増加により、大規模な ML のデプロイ管理が容易になり、モデルのデプロイコストが低下します。 本記事では Amazon SageMaker マルチモデルエンドポイントを紹介し、この新機能を導入して XGBoost を使用することで、個々の市場セグメントの利用料金を予測する方法を説明します。本記事では、マルチモデルエンドポイントで 10 個のモデルを実行する場合と、個別のエンドポイント 10 個を使用する場合との比較を行いました。この結果、以下の図に示すように、月あたり 3,000 USD を節約できました。 マルチモデルエンドポイントは、数百から数千のモデルに規模を変えて容易に対応できます。また本記事では、エンドポイントの設定とモニタリングの考慮事項も検討し、1,000 個のモデルでコストを 90% 以上節減した例についてハイライトします。 Amazon SageMaker マルチモデルエンドポイントの概要 Amazon SageMaker により、冗長性の高い複数のアベイラビリティーゾーンで、自動スケーリングの Amazon ML インスタンスにモデルを 1 クリックでデプロイすることが可能になります。インスタンスのタイプと、希望する最大数および最小数を指定すれば、Amazon SageMaker が残りを引き受けます。インスタンスを立ち上げ、モデルをデプロイし、安全な HTTPS エンドポイントを設定します。低レイテンシー、高スループットの推論を実行するため、アプリケーションはこのエンドポイントへの API 呼び出しを含む必要があります。このアーキテクチャーにより、モデルの変更でアプリケーションのコード変更が不要になるため、アプリケーションに新しいモデルを数分で統合できます。Amazon […]

Read More

Amazon Forecast で 自由選択した分位数での予測作成のサポートを開始

Amazon Forecast で、自由に選択した分位数で予測を作成できるようになったことをお知らせいたします。 re:Invent 2018 で発表され、2019 年 8 月から一般公開されている Forecast は、機械学習 (ML) により、それまでの機械学習の経験を待つことなく、非常に正確な予測を作成できる完全マネージド型サービスです。Forecast は、製品需要の見積り、サプライチェーンの最適化、エネルギー需要の予測、財務計画、人事計画、クラウドインフラストラクチャ使用状況の算定、トラフィック需要の予測など、さまざまなユースケースに使用できます。 Forecast は、Amazon.com で使用されているものと同じ技術に基づいており、完全に管理されたサーバーですので、プロビジョニングするためのサーバーはありません。また、使用した分だけお支払いいただくようになっており、最低料金や前払い金を求められることはありません。Forecast を使用するために必要なことは、予測対象の履歴データをご提供いただくことだけです。オプションとして、予測に影響を与えると思われる追加データもご提供ください。後者には、価格、行事、天候など、時により変化するデータと、色、ジャンル、リージョンなどカテゴリに関するデータの、両方が含まれます。このサービスは、お手元のデータに基づいて機械学習モデルを自動的にトレーニングし、デプロイして、予測をダウンロードするためのカスタム API を提供します。 ポイント予測 (p50) を作成する他のほとんどの予測ソリューションと異なり、Forecast は、10% (10p)、50% (50p)、90% (90p) の 3 つのデフォルト分位数で確率的予測を作成します。ビジネスにおける資本コスト (過大予測) と顧客需要の不足 (過小予測) のトレードオフに応じて、ご自身のビジネスニースに合った予測を選択できます。10p 予測では、真正値は 10% 予測値よりも低いことが予想されます。投資資本のコストが高い場合 (例:製品在庫が過剰)、分位数 p10 の予測は、比較的少数の商品を注文するのに役立ちます。これと同様に、p90 予測では、真正値は 90% 予測値よりも低いことが予想されます。顧客需要が失われた結果、収益が大きく損なわれたり、カスタマーエクスペリエンスが低下したりした場合は、p90 予測がより役立ちます。詳細については予測精度の評価を参照してください。 Forecast でサポートされている既存の 3 つの分位数は便利ですが、2 つの制約があります。第一に、固定値である分位数は、特定のユースケースの要件に、常に合致するとは限りません。例えば、すべてのコストで顧客需要を満たすことが必須である場合は、p99 予測のほうが p90 より便利でしょう。 第二に、Forecast はデフォルトで常に 3 […]

Read More

Amazon Rekognition カスタムラベルの発表

本日、アマゾン ウェブ サービス (AWS) は、Amazon Rekognition カスタムラベルを発表しました。これは Amazon Rekognition の新機能で、お客様が独自の特別な機械学習 (ML) ベースの画像分析機能を構築し、特別なユースケースに統合する固有のオブジェクトやシーンにを検出します。たとえば、画像から機械部品を検出するために Amazon Rekognition を使用するお客様は、小さなセットのラベル付きの画像でモデルをトレーニングして、MLの専門知識なしでも「ターボチャージャー」や「トルクコンバーター」を検出できるようになります。モデルを最初からトレーニングすることには、特別な機械学習の専門知識と何百万の高品位のラベル付き画像が必要ですが、その代わりにお客様は Amazon Rekognition を使用してカスタムラベルを使用して、独自の画像分析ニーズのために最先端のパフォーマンスを達成することができるようになりました。 Amazon Rekognition カスタムラベルをより良く理解するために、このサービスの新機能をしようする方法の例を順番に見ていきましょう。 自動車修理工場は Amazon Rekognition ラベル検出 (オブジェクトとシーン) を使用して、在庫の機械部品を分析し、ソートすることができます。これらのすべての画像について、 Amazon Rekognition は正常に「機械部品」を返します。 Amazon Rekognition カスタムラベルを使用して、お客様は独自のカスタムモデルをトレーニングして、ターボチャージャーやトルクコンバーターなどの特定の機械部品を識別できます。最初に、お客様は識別したいそれぞれの特定の機械部品のために、わずか 10 個程度のサンプル画像を収集します。 このサービスコンソールを使用して、お客様はこれらの画像をアップロードして、ラベル付けすることができます。 この段階では、機械学習の専門知識は必要ありません。お客様はコンソール内のプロセスの各ステップを通じて導かれます。 データセットが準備でき、完全にラベル付けされると、お客様は Amazon Rekognition カスタムラベルをワンクリックだけで動作させることができます。Amazon Rekognition は各ユースケースに対して、自動的に最も効率的な機械学習技術を選択します。 トレーニングを完了すると、お客様は仮想化にアクセスして、各モデルのパフォーマンスを確認して、それらのモデルをさらに向上する方法に対する助言を得ることができます。 当社の例の自動車修理工場では、大規模な画像処理のための完全マネージド型の使用が簡単な API ビルドを使用して、画像の分析を開始して、名前で特定の機械部品を検出したり、在庫管理を自動化することができるようになりました。 Amazon Rekognition オブジェクトとシーンの検出では「機械部品」を返す一方で、いくつかのラベル付きの画像でトレーニングされた Amazon Rekognition カスタムラベルは、「ターボチャージャー」、「トルクコンバーター」、および「クランクシャフト」を返します。 NFL や […]

Read More

Amazon Lex の感情分析を用いた会話体験の設計

効果的な会話をするには、感情を理解し、適切に対応することが重要です。コールセンターでは、不満を抱えた顧客と話すときには、たとえば「お手数をお掛けして申し訳ございません」といった簡単な謝辞が役立つこともあります。 感情を理解することは、人間のエージェントに電話を代わってサポートを引き継ぐタイミングを判断するのにも役立ちます。 このような会話の流れをボットで実現するには、ユーザーがあらわにした感情を検出し、適切に対応する必要があります。以前は、Comprehend API を使用してカスタム統合を構築する必要がありました。この記事の執筆時点では、Amazon Lex で感情をネイティブに判断できるようになっています。 本稿では、ユーザーの感情を使用して会話の流れをより適切に管理する方法を説明します。 ボットを構築し、ユーザーの感情に基づいて応答を更新するロジックを追加し、エージェントへの引き継ぎを設定する手順を説明します。 ボットを構築する 次の会話を使用して、ボットをモデル化します: ユーザー: 荷物はいつ到着しますか? とても遅いのですが。 エージェント: ご不便をおかけして申し訳ございません。 追跡番号をお教えいただけますか? ユーザー: 21132 です。 エージェント: 確認いたしました。11 月 27 日にご自宅に到着いたします。 ユーザー: 分かりました、ありがとう。 それでは、配達ステータスを追跡し、配達日を変更する目的で、Amazon Lex ボットを構築しましょう。CheckDeliveryStatus インテントは、追跡番号情報を引き出し、配達日を返します。ChangeDeliveryDate インテントは、配達日を新しい日付に更新します。本稿では、追跡番号と配達日でデータベースを管理しています。AWS Lambda 関数を使用して配達日を更新できます。 ボットで感情分析を有効にするには、次の手順を実行します: Amazon Lex コンソールで、該当のボットをクリックします [Settings] の中から [General] を選択します [Sentiment Analysis] では [Yes] を選択します [Build] をクリックして新規ビルドを作成します ロジックを追加して応答を変更する ボットをセットアップしたので、ユーザーの感情に反応するロジックを追加します。CheckDeliveryStatus 内のダイアログのコードフックは、感情スコアを検査します。否定的な感情のスコアが特定のしきい値を超えている場合、追跡番号の入力を求めるときに、「ご不便をおかけして申し訳ございません」などの謝辞を挿入できます。以下の Lambda コードスニペットをご覧ください:   if (negativeSentimentVal […]

Read More

Amazon SageMaker Ground Truth ジョブをチェーン化して、ラベルを段階的に作成する

Amazon SageMaker Ground Truth は、機械学習用の高精度なトレーニングデータセットを構築するお手伝いをします。自動ラベル付け機能を使用して、ラベル付けコストを最大 70% 下げることができます。 このブログ投稿では、Amazon SageMaker Ground Truth チェーン機能について、いくつかの例とデータセットのラベル付けの可能性について説明しています。Amazon SageMaker Ground Truth がすでにラベル付けされているオブジェクトを判別し、自動データラベル付けモード用にデータを最適化するため、連鎖により時間とコストが大幅に削減されます。前提条件として、Amazon SageMaker Ground Truth を使用して階層型ラベル分類法を作成するという投稿を確認してください。この記事では、マルチステップの階層ラベル付けを実現する方法と、拡張マニフェスト機能の使用方法に関するドキュメントを示しています。 ラベリングジョブのチェーン チェーンは、次のシナリオで役立ちます。 部分的に完了したラベル付けジョブ – ラベルがほとんど含まれていない入力マニフェストがあり、残りはラベル付けされているラベル付けジョブです。 失敗したラベル付けジョブ – いくつかのラベルを生成し、残りのラベルが失敗または期限切れになったラベル付けジョブです。 停止されたラベル付けジョブ – ユーザーが停止したラベル付けジョブです。停止する前にいくつかのラベルが生成された可能性があります。 チェーン機能により、これらの以前のラベルを再利用し、残りのラベルを一貫して取得できます。詳細については、ラベル付けジョブのチェーンを参照してください。 チェーンでは、前のジョブの出力を後続のジョブの入力として使用します。 以下は、新しいチェーンラベル付けジョブのブートストラップに使用されるアーティファクトです。 LabelAttributeName 前のラベル付けジョブからマニフェストファイルの内容を出力する モデル (利用可能な場合) Amazon Sagemaker Ground Truth コンソールからジョブを開始する場合、デフォルトでは、LabelingJob 名が LabelAttributeName として使用されます。詳細については、LabelAttributeName を参照してください。 部分的に完了したジョブをチェーンしている場合、コンソールは親ジョブの LabelAttributeName を使用して、既にラベル付けされているオブジェクトとラベル付けされていないオブジェクトを決定します。その結果、ラベル付けされていないオブジェクトまたは以前に失敗したオブジェクトのみがラベル付けのために送信されます。別の LabelAttributeName を指定することでこの動作を上書きできます。その場合、以前のラベルはカウントされず、新しいラベル付けジョブはラベル付けのためにすべてのデータを送信します。このプロセスについては、この投稿の後半で詳しく説明します。 API または SDK […]

Read More

Amazon EMR、Amazon SageMaker、および AWS Service Catalog で Intuit Data Lake をプロビジョニングする

この投稿では、Intuitの学習内容と AWS 上でのデータレイクの推奨事項を共有します。Intuit Data Lake は、Intuit データプラットフォームの数多くのチームにより構築され、運営されています。Tristan Baker (チーフアーキテクト)、Neil Lamka (プリンシパル製品マネージャー)、Achal Kumar (開発マネージャー)、Nicholas Audo、および Jimmy Armitage のフィードバックとサポートに感謝いたします。 データレイクとは、あらゆる規模で構造化データと非構造化データを保存する、一元化されたリポジトリです。Intuit では、未加工データのパイルなどを作成することは、容易です。しかし、より興味深い課題がその中に存在しています。 AWS アカウントを整理する方法 使用する取得方法 アナリストの必要とするデータの検索方法 データの保存場所 アクセスの管理方法 Intuit の機密データを保護するために必要なセキュリティ措置 このエコシステムで自動化できる部分 この投稿では、Intuit で採用されるアプローチを概説します。ただし、データレイクを構築するには多くの方法 (例: AWS Lake Formation) があることを覚えておくことは重要です。 高いレベルで Intuit Data Lake を作成する際に含まれる技術やプロセスを取り上げます。これには、全体的な構造とアカウントやリソースのプロビジョニングに使用される自動化を含みます。Intuit Data Lake を協力して構築した他のチームやエンジニアから寄せられたシステムの特定の局面でより詳細なブログ投稿について、今後もこのスペースをご覧ください。 アーキテクチャ アカウント構造 データレイクは一般的にデータソースへのアクセスをコントロールする共有サービスを含むハブアカウントにより、hub-and-spoke モデル に従います。この投稿の目的で、ハブアカウントを Central Data Lake と呼びます。 このパターンでは、Central Data Lake […]

Read More

Amazon SageMaker を使って新しいユーザーにリアルタイムで配信する音楽レコメンデーション

この記事は、iHeartRadio 社の Matt Fielder 氏および Jordan Rosenblum 氏からの寄稿によるものです。おふたりの言葉を借りると、「iHeartRadio は、毎月数千万人の人に配信しており、また、数万人の新規登録者を日々集めているオーディオストリーミングサービスです。」、とのことです。 パーソナライゼーションはユーザー体験の中でも重要な位置を占めています。そして当社としても、お客様の使用履歴の早い段階で、有用なレコメンデーションを提供したいと強く希望しています。音楽作品の提案をユーザー登録直後に表示することで、当社のサービスがお客様の好みに素早く対応可能であり、その中で色々と探し回る必要はそれほどないのだと伝えられます。しかし、まだ視聴をまったく開始していないユーザーに対し、どうやってコンテンツの提案をしているのか、ご関心をお持ちの方もいらっしゃるでしょう。 この記事では、当社がリアルタイムのパーソナライズサービスを実現するために、ユーザーの方が登録の際に提供してくださる情報を、いかに活用しているかを説明します。新規のお客様には音楽視聴に関する記録がまったくありませんが、通常はサービス参加の段階で、一定数の好みジャンルを選択し、ご自身についての統計学的な情報を提供してくれるものです。ここではまず、当社がパーソナライゼーションに使用している有益なパターンを含む、それらの属性の分析をお見せします。次に、そういったデータを、新規のお客様それぞれに最良の音楽を予測するため使用しているモデルについて説明しいきます。最後に、登録直後に Amazon SageMaker を使用して、推奨としてこれらの予測をリアルタイムで提供する方法を示します。これにより、A / Bテストでのユーザーエンゲージメントが大幅に向上します。 新規ユーザーの視聴パターン モデル構築を始める前に、ヒントとなり得る情報が含まれそうな特別なパターンが、データの中に存在するかを確認しておく必要があります。 最初に挙げられる仮説は、統計学的に違う背景をもつ人々は、それぞれ別のタイプの音楽を好むはずだということです。たとえば、まったく同じ環境にいたとしても、50 歳の男性は、25 歳の女性よりクラシックロックを聴く確率は高そうだといえます。仮に、平均的な意味で、このことの中に何らかの真実が存在するならば、有用なレコメンデーション作成のためにユーザーの方が視聴履歴を残すのを待つ必要はないことになります。ユーザー登録の際に提供していただく、統計的な情報を活用するだけで十分でしょう。 この点の分析を行うため、ユーザー登録から 2 か月経過した方の視聴行動に着目し、それを、同じ方から登録の時にご提供いただいた情報に照らし合わせてみることにしました。この 2 か月というギャップにより、既にコンテンツの中をいろいろ試しているアクティブなユーザーに対し確実に焦点を絞れます。この時期になれば、その方がどのような好みであるのかは、かなり明白になっていると思われます。同時に、サービス参加時やマーケティングの初期段階に存在したノイズも、すでに低減しているはずです。 次の図では、あるユーザーの方が、登録から 2 か月間にとった視聴行動についてのタイムラインを示しています。 次に、新規の男性ユーザーと新規の女性ユーザーを対比して、視聴するジャンルにおける分布を比較します。この結果から、音楽の好みには統計的情報と関連があるパターンが存在するという、先の仮説が立証できます。たとえば、スポーツやニュース、そしてトークショーなどは、男性の間でより人気があることが読み取れるでしょう。このデータは、特に視聴履歴をまだ残していないユーザーの方に対するレコメンデーションを向上でき得るものだといえます。 次に示すグラフでは、ユーザーの性別と好みのジャンルの関連性を大まかに示しています。 2 つめに挙げられる仮説は、同じ好みを持つユーザーの方達でも、探しているジャンルを違った表し方をするということです。さらにいうと、iHeartRadio ではジャンルの分類に対し、ユーザーの方々が認識しているものと比べて少し違う定義をしています。当然これは、一定のジャンルに関する 分析の 1 つの論拠となり得ます。たとえば、実際には当社内部で Hip Hop として分類しているものをお聞きの多くの方が、好みの音楽は R&B だとおっしゃることがあります。このことは、同じジャンルに対してでも、ユーザーの方はそれぞれ別の定義をしているという意味で、ジャンルとういものが持ついくぶん主観的な特性も示しています。 ジャンルの予測 さて、統計情報とジャンルの好みが、新規ユーザーの行動を予測する上で有用であるという分析的な確証がある程度得られたので、モデルの構築とテストに着手することにします。モデルには、統計的背景とジャンルの好みがいかに視聴行動と関係性があるかを、システム的に学習してくれることが期待されます。もし上手くいけば、新しいユーザー様が当社のプラットフォームのご利用を開始する際に、適切なジャンル分けでコンテンツを提示するため、そのモデルが利用できるでしょう。 分析段階においては、サインアップから 2 か月経ったユーザーの方が自然と選択するであろうコンテンツを提示できる、見本の予測方法を人間が定義します。結果に求めるのは、モデル用のトレーニングデータをご提供いただいた方が、当社のアプリのコンテンツを開くのに時間を割くような、活発なユーザー様となることです。従って、目標変数は、登録 2 か月後にユーザーの方が最も視聴するジャンルになります。また、その方の統計的な背景と登録段階で選択されたジャンルの組合せを特徴量として使用します。 今回もその開始時点では、多くのモデリング作業と同じく、最も基本的なモデリングテクニックである、マルチラベルのロジスティック回帰分析を使用します。トレーニングするモデルでの特徴係数のサンプリング結果と、次のヒートマップに示している視聴結果がそれらの値との間に持つ関連性とを分析します。統計学的ではないモデルは、ユーザーの方が登録の際に選択したジャンルに関するマルチホットエンコーディングを備えています。より明るい色 (より重みがある) のスクエアは、よりモデルの特徴量との関連性があり、これは、ユーザーが登録から 2 か月後に視聴しているジャンルと関係します。 明らかにここからは、いくつかの初期パターンを見出すことができます。1 […]

Read More

Amazon Rekognition と Amazon Athena を使用してソーシャルメディア上の画像を探る

たいていの企業と同様であれば、お客様とブランドイメージをよりよく理解したいと考えておられるでしょう。マーケティングキャンペーンの成功と、お客様が関心を持っているトピック、あるいは不満を感じているトピックを追跡したいと考えておられるでしょう。ソーシャルメディアはこの種の情報の豊富な情報源になると期待されており、多くの企業が Twitter などのプラットフォームから情報を収集、集約、分析し始めています。 ただし、ソーシャルメディアでの会話の中心は画像と動画です。ある最近のプロジェクトでは、収集されたすべてのツイートの約 30% に 1 つ以上の画像が含まれていました。こうした画像には、分析なしでは簡単にアクセスできない関連情報が含まれています。 このブログ記事について 完了するまでの時間 1 時間 完了するためのコスト ~ 5 USD (公開時、使用する条件による) 学習レベル 中級 (200) AWS のサービス Amazon Rekognition Amazon Athena Amazon Kinesis Data Firehose Amazon S3 AWS Lambda ソリューションの概要 次の図は、ソリューションコンポーネントと、画像や抽出データがコンポーネントの間をどのように流れるかを示しています。 これらのコンポーネントは、AWS CloudFormation テンプレートを介して利用できます。 Twitter Search API はツイートを収集します。 Amazon Kinesis Data Firehose は、ツイートを送信して、Amazon S3 に保存します。 指定されたバケットフォルダーで S3 オブジェクトが作成されると、Lambda 関数がトリガーされます。 Lambda […]

Read More

機械学習と感度分析を組み合わせてビジネス戦略を開発する

機械学習 (ML) は、意思決定を支援するために無数の企業で日常的に使用されています。ただし、ほとんどの場合、ML システムによる予測とビジネス上の決定には、判断を下すために人間のユーザーの直感がまだ必要です。 この記事では、ML を感度分析と組み合わせて、データ駆動型のビジネス戦略を開発する方法を示します。この記事では、顧客の解約 (つまり、競合他社への顧客の離反) に焦点を当て、ML ベースの分析を使用するときにしばしば発生する問題を取り上げます。これらの問題には、不完全で不均衡なデータの処理、戦略的オプションの導出、およびそれらのオプションの潜在的な影響の定量的評価に関する困難が含まれます。 具体的には、ML を使用して解約する可能性の高い顧客を特定し、機能の重要性とシナリオ分析を組み合わせて定量的および定性的な推奨事項を導き出します。次に、組織はその結果を使用して、将来の解約を減らすための適切な戦略的および戦術的決定を下すことができます。このユースケースは、以下のように、データサイエンスを実践する際に発生するいくつかの一般的な問題を示しています。 低い信号と雑音比と、特徴と解約率の間の明確な相関関係の欠如 非常に不均衡なデータセット (データセット内の顧客の 90% が解約しない) 確率論的な予測と調整を使用した、解約問題への過剰投資のリスクを最小限に抑える意思決定メカニズムの特定 エンドツーエンドの実装コードは、Amazon SageMaker で利用でき、Amazon EC2 でスタンドアロンとして利用できます。 このユースケースでは、さまざまなタイプの製品を提供する架空の会社を考えます。その会社の 2 つの主要な製品を製品 A と製品 B と呼びます。会社の製品と顧客に関して部分的な情報しか持っていません。同社は最近、競合他社への顧客離反 (解約とも) が増加している様を見ています。データセットには、数か月にわたって収集およびソートされた数千の顧客の多様な属性に関する情報が含まれています。これらの顧客の一部は解約しており、一部はそのままです。特定の顧客のリストを使用して、個人が解約する確率を予測します。このプロセス中、次のいくつかの質問に対して回答しようと思います。顧客離れの信頼できる予測モデルは作成できるのか? 顧客が解約する可能性を説明する変数は何か? 会社は解約を減らすためにどのような戦略を実行できるか? この記事では、ML モデルを使用して解約削減戦略を策定するための次の手順について説明します。 データの探索と新機能のエンジニアリング 最初に、個々の入力機能と解約ラベルの間の単純な相関関係と関連性を調べて、顧客データを探索する方法を説明します。また、機能自体の間の関連付け (相互相関、または共分散と呼ばれる) も調べます。これにより、アルゴリズムの決定、特に、どの機能を派生、変更、または削除するかを決定できます。 ML モデルのアンサンブルの開発 次に、自動機能選択を含むいくつかの ML アルゴリズムを構築し、複数のモデルを組み合わせてパフォーマンスを向上させます。 ML モデルのパフォーマンスの評価と改善 3 番目のセクションでは、開発したさまざまなモデルのパフォーマンスをテストします。そこから、解約する顧客の数を過大評価するリスクを最小限に抑える意思決定メカニズムを特定します。 ビジネス戦略設計への ML モデルの適用 最後に、4 番目のセクションでは、ML の結果を使用して、顧客の解約に影響する要因を理解し、戦略的オプションを導き出し、解約率に対するこれらのオプションの影響を定量的に評価します。そのためには、感度分析を実行します。この分析では、実際の生活で制御できるいくつかの要因 (割引率など) […]

Read More

Amazon SageMaker RL Notebook を使用した AWS DeepRacer のカスタム深層強化学習およびマルチトラックトレーニング

re:Invent 2018 で開始された AWS DeepRacer は、開発者が強化学習 (RL) を実践するのに役立ちます。  それ以来、世界中の AWS Summits で開催された 21 の AWS DeepRacer リーグイベントで、何千人もの人々が仮想的に AWS DeepRacer コンソールを通じてモデルを開発し、競い合いました。サミット以外にも、AWS Lofts でのいくつかのイベント、開発者のミートアップ、パートナーセッション、企業イベントなどがありました。 AWS DeepRacer で学び、実験する開発者の熱意は非常に高いものがあります。多くの人は、さらに探求し、ニューラルネットワークアーキテクチャやトレーニングプリセットを改良したり、複数のトラックで並行してトレーニングしたりする能力を高めたいと考えています。 AWS DeepRacer は、Amazon SageMaker、AWS RoboMaker、Amazon Kinesis Video Streams、Amazon CloudWatch、Amazon S3 など、他のいくつかの AWS のサービスを利用しています。こうした各コンポーネントをよりきめ細かく制御してシミュレーション環境とモデリング環境を拡張するために、この記事にはこうした環境のプロビジョニングと管理に役立つノートブック環境が含まれており、AWS DeepRacer でのエクスペリエンスのあらゆる側面を改良できます。詳細については、この記事の GitHub リポジトリを参照してください。 この記事では、環境の設定方法を探り、AWS DeepRacer コードベースの主なコンポーネントを掘り下げ、ニューラルネットワークやトレーニングプリセットの変更、アクションスペースのカスタマイズ、複数のトラックでの並行トレーニングについて詳しく説明します。最後には、Amazon SageMaker を使用して AWS DeepRacer モデルトレーニングを変更する方法を理解できているはずです。 開発者は、AWS DeepRacer コンソールの背後にあるツールを利用することで、AWS DeepRacer トレーニングとモデルのあらゆる側面をカスタマイズおよび変更し、モデルを直接レースにダウンロードして、NeurIPS […]

Read More