Amazon Web Services ブログ

Category: Artificial Intelligence

Amazon SageMaker で複数の TensorFlow モデルを一つのエンドポイントへデプロイする方法

概要 Amazon SageMaker では、TensorFlow、MXNet、Chainer、PyTorch、scikit-learn といった機械学習フレームワークをサポートしています。これらのフレームワークを利用して機械学習による予測結果を得るためには、学習した機械学習モデルをエンドポイントにデプロイする必要があります。複数のモデルを利用したい場合、モデル一つ一つに対してエンドポイントを作成する方法が一般的ですが、推論リクエストが少ないモデルに対してエンドポイントを常時起動すると、推論処理に対するコストが高くなってしまいます。そこで、推論リクエストの少ないモデルを、他のモデルと同じエンドポイントにデプロイし、常時起動するインスタンス数を低減する方法があります。この手法はリアルタイム処理が必要な場合は特に有効です。なお、推論処理がリアルタイム性を要求しない場合はバッチ変換ジョブをご利用ください。 本記事では、複数のモデルを一つのエンドポイントにデプロイする方法について説明いたします。Amazon SageMaker がサポートする全ての機械学習フレームワークで、複数のモデルを一つのエンドポイントにデプロイすることができますが、ここでは Tensorflow Serving を利用して、複数のモデルをデプロイする方法について説明します。例として、軽量な物体検出モデル SSD MobileNet と、軽量な画像分類モデル MobileNet を1つのインスタンスにデプロイします。デプロイまでの手順の概要は以下のとおりです。 複数の TensorFlow モデルを TensorFlow Serving にデプロイ可能な SavedModel 形式で保存します。 保存したモデルを1つのアーカイブファイル (tar.gz 形式) にして、Amazon S3 (S3) にアップロードします。 Amazon SageMaker の API を利用して、1 つのインスタンスにデプロイし、テストします。 それでは各手順について以下で説明します。 1. TensorFlow モデルの保存 Jupyter Notebook からコードを実行し、TensorFlow の学習済みモデルをダウンロードして、以下のような SavedModel 形式で保存します。model1 を SSD MobileNet、model2 を MobileNet とします。TensorFlow モデルには、SavedModel 形式以外の学習済みモデルが公開されている場合があるので、必要に応じて変換します。今回は […]

Read More

Bridgeman Images は Amazon Translate を使用してグローバルに事業を確立

多くの企業は、新規顧客を獲得し成長を加速させるために世界規模で拡大することを目指しています。Bridgeman Images の場合、これは英語以外の言語を話す顧客を引き付けることを意味しました。手作業で翻訳しただけでは十分なスピードや費用対効果が得られないため、同社は言語の壁を克服するためのスケーラブルなソリューションを必要としていました。Amazon Translate を使用して、コンテンツのローカライズに必要な時間を数か月から数週間に短縮し、5 億 7000 万の英語の文字をイタリア語、フランス語、ドイツ語、スペイン語に翻訳しました。 Bridgeman Images は、アーカイブ内に 300 万近くのアクティブアセットを保有する権利管理型のイメージライセンス会社です。自社サイトで簡単に検索できるように、これらの各アセットには、タイトル、説明、および Amazon Elasticsearch Service (Amazon ES) にインデックス付けする一連のキーワードや媒体が含まれています。同社の調査によると、すべてのプラットフォームで集計した顧客の 20~30% が、英語以外のイタリア語、フランス語、ドイツ語、スペイン語のいずれかの言語で画像データを表示する必要があることが分かりました。そこで同社は、顧客に可能な限り最高の体験を提供するために、すべてのメタデータを翻訳することにしました。 Bridgeman Images はさまざまな数多くの選択肢を研究し、機械翻訳が彼らのビジネスに全体的に最高の価値をもたらすだろうと判断しました。新しい翻訳の準備をするとき、同社はその機会に内部のメタデータ構造を見直し、重複を最小限に抑えて翻訳コストを節約する堅牢なワークフローを実行することにしました。 同社は最初にキーワードシステムを更新しました。キーワードシステムもともとはセミコロンで区切られたレコードを持つフラットなデータ構造として作成されたものでした。同社はこれらのエントリーの重複を排除し、複数のアセットがその翻訳と同時にキーワードを共有できるようにするリレーショナル構造を作成しました。キーワードは Amazon RDS MySQL インスタンスに保存され、キーワードへの変更がトリガーされるかシステムに新しいキーワードが入力されるたびに Amazon Elasticsearch Service インデックスに反映されます。 キーワード (およびその他のデータ) の翻訳を処理するために次に行った作業は、Python、Boto3 や Zappa と共に AWS Lambda にデプロイされた Flask API を使用して、Amazon Translate サービス用の単純なラッパーを作成することでした。 その後、システムに新しいキーワードが追加されるたびにタスクが RabbitMQ クラスターのキューに入れられるようにトリガーを設計しました。これにより、ワーカーを呼び出して AWS Lambda 関数をクエリして Amazon Translate […]

Read More

Amazon SageMaker Ground Truth と自動化されたデータのラベル付けによる低コストでのデータのアノテーション

  Amazon SageMaker Ground Truth を使うと、正確にラベル付けされた機械学習データセットを簡単に低価格で構築することができます。ラベル付けのコストを削減するために、Ground Truth の機械学習を使用して、人によるアノテーションが必要な「困難な」画像と、機械学習で自動的にラベル付けできる「簡単な」画像を選択します。この記事では、自動化されたデータのラベル付けの仕組みと、その結果の評価方法について説明します。 自動化されたデータのラベル付けを伴う物体検出ジョブを実行する 以前のブログ記事では、Julien Simon が AWS マネジメントコンソールを使ってデータのラベル付けジョブを実行する方法を説明しました。このプロセスをより細かく制御するには、API を使用できます。  その方法をご紹介するため、今回は鳥の画像 1,000 個に対して バウンディングボックスアノテーション を生成する API を使用した Amazon SageMaker Jupyter ノートブックを使用します。 注意: デモノートブックの実行コストは約 200 USD です。 デモノートブックにアクセスするには、ml.m4.xlarge インスタンスタイプを使用して Amazon SageMaker ノートブックインスタンスを開始します。インスタンスは、このステップバイステップチュートリアルに従ってセットアップできます。ステップ 3 では、IAM ロールの作成時に「任意の S3 バケット」にチェックを入れるようにしてください。 以下にあるように、Jupyter ノートブックを開いて [SageMaker Examples] タブを選択し、object_detection_tutorial.ipynb を起動します。 ノートブックの「Introduction」および「Run a Ground Truth labeling job」の各セクションにあるセルのすべてを実行します。セルには変更が必要なものもあるため、ノートブックの指示を注意深く読んでください。これらのセクションを実行すると、以下が行われます。 鳥の画像 1,000 […]

Read More

DXC Technology が AWS の機械学習を使ってサポートチケットの選別を自動化

  DXC Technology は、さまざまな企業や政府機関向けに、デジタルトランスフォーメーション上でエンドツーエンドのサービスを提供している IT サービスの世界的大手企業です。同社は、オンプレミスとクラウドで、クライアントのサービス管理も行っています。  プロセスの過程でインシデントチケットが発生した場合は、サービスレベルアグリーメント (SLA) に沿ってすばやく解決する必要があります。  DXC は、人的作業を減らし、インシデントの解決時間を短縮し、知識管理を強化して、インシデント解決の一貫性を向上させることを目標に掲げています。  そして、この目標を念頭に、知識管理 (KM) 記事の予測メカニズムを開発しました。 今回のブログでは、DXC が、KM 記事を自動的に特定するために AWS で機械学習をどのように使用しているか、またそれをチケット解決用のオーケストレーションランブックで自動化し、IT サポートの効率をいかに向上できるかについてご紹介します。 AWS を活用した DXC のソリューション その 1: Amazon S3 にデータレイクを構築する DXC の顧客が、インシデントチケットを IT サービスマネジメントツール (ITSM) へ送ります。チケットは、ユーザーまたはマシンにより生成できます。データは、Amazon S3 のバケットへプッシュまたはプルされます。Amazon S3 は、高い耐久性で低価格のオブジェクトストレージであり、形式やフォーマットを問わずあらゆるデータを保存できます。 その 2: 最適な機械学習ツールとアルゴリズムを選択する 一般に、問題は、テキストをいかに分類するかということです。AWS は、テキストを分類するためのさまざまな選択肢を顧客に提供しています。DXC は、次の AWS サービスの評価を行いました。 BlazingText と呼ばれるアルゴリズム内蔵の Amazon SageMaker Amazon Comprehend のカスタム分類 最適な選択肢は、Amazon […]

Read More

[AWS Black Belt Online Seminar] Amazon SageMaker Basic Session 資料及び QA 公開

先日 (2019/2/6) 開催しました AWS Black Belt Online Seminar「Amazon SageMaker Basic Session」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190206 AWS Black Belt Online Seminar Amazon SageMaker Basic Session from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. バッチ推論とは何ですか? A. バッチ推論とは、大量の推論対象データに対して、一括で推論処理を行うことを指します。Amazon SageMaker においては、推論用のインスタンスを立ち上げて、S3 から対象データを読み込んで推論を行い、結果を S3 に書き出す形で実現しています。 Q. SageMakerの各コンポーネントで、モデル変換とありましたが、このモデル変換後出てくるモデルの形式は何になりますでしょうか(例:Keras⇒Chainer等) A. モデル変換は、Neo-AI プロジェクトとして OSS で公開されておりますコンパイラによって実施されます。出力形式は、Neo の独自フォーマットとなり、Neo Runtime にて動作いたします。Neo-AI プロジェクトの詳細については、こちらのブロク記事も参照ください。 Q. SDKの基本コード3行目のchainer_estimator.fitはestimator.fitの間違いでしょうか?chainer_estimatorという変数が宣言されていないように思えます。 A. ご指摘の通りです。こちらの資料間違いでご迷惑をおかけして申し訳ありません。公開バージョンの資料では、こちらの間違いは修正いたしました。 Q. SageMakerのハイパーパラメータチューニングについて、通常のGridSearchやベイズ最適化をPythonで組んで実行するのと何か違いはありますか?例えばGridSearchの範囲を指定しなくても最適なものを選んでくれるとか。 A. SageMaker のハイパーパラメタチューニングは、ベイズ最適のみをサポートしています。通常の最適化ライブラリとの違いは、SageMaker […]

Read More

Amazon Rekognition に関する最近の研究論文および関連記事についての考察

昨日発表された研究論文と関連記事は、Amazon Rekognition の精度について触れています。私たちはフィードバックを歓迎しており、実際に常に人々からフィードバックを得ていますが、この研究論文と記事は誤解を招きやすく、誤った結論に導いています。このブログ記事が、いくつかの誤解や不正確さを明確にするのに役立つことを願っています。 多くの場合、精度は絶対的な尺度と考えられます。たとえば、数学の試験のパーセンテージスコアでは、それぞれの答えは正しいか、間違っているかのどちらかです。 機械学習システムの精度を理解、解釈、比較するには、何が予測されているか、予測の信頼性、どのように予測を使うべきかを理解することが重要であり、これを単一の絶対数またはスコアから収集することは不可能です 。 何が予測されているか: Amazon Rekognition は、コンピュータービジョンと呼ばれる一種の機械学習を使用して、2 つの異なる顔機能を提供します。最初の機能は顔分析です。特定の画像やビデオについて、このサービスは顔がどこに表示されているか、および画像の特定の特性 (画像に笑顔、めがね、口ひげ、顔の性別が含まれているかなど) を知らせることができます。こうした属性は通常、写真のカタログを検索するのに役立ちます。Amazon Rekognition の 2 番目の機能は、一般に顔認識と呼ばれている機能です。これは、顔分析とは明確に異なる機能であり、似ているように見える顔を照合します。これは、一部の電話のロックの解除、建物に入る人の認証、または対象となる人物を識別するために法執行機関がフィールドを絞り込むために使用するのと同じアプローチです。後者は、昔の映画に登場する写真の本をめくる探偵に似ていますが、はるかに高速です。 顔分析と顔面認識は、基盤となるテクノロジとそれらをトレーニングするために使用されるデータの点でまったく異なります。そうした目的を意図したアルゴリズムではないので、顔認識の精度を測定するために顔分析を使用することは軽率です (説明は、ドキュメントをご覧ください)。 信頼性: 顔分析と顔認識の両方について、Amazon Rekognition は、特定の結果がどの程度の信頼性であるかについても説明します。すべての機械学習システムは本質的に確率論的なので、信頼スコアはシステムがその結果にどれだけ信頼を置いているかの尺度と考えることができます。信頼度が高いほど、結果を信頼できます。結果を解釈するために使用される信頼度閾値について透明かつ思慮深くなければ、顔分析または顔認識のいずれかの品質を解釈することは不可能です。この調査で使用されている閾値はまだ分かっていませんが、以下に示すように、推奨される信頼水準で実行した場合の結果は大きく異なります。 予測のユースケース: 信頼性と組み合わせることで、精度を適切な文脈でとらえるのに役立つので、機械学習による予測の使用の意図は重要です。たとえば、写真のカタログで「サングラス」を含む画像を検索するために顔分析を使用する場合、完全に一致しないものが含まれるとしても、検索結果に表示する画像の数を増やすことが望ましい場合があります。このユースケースにおける不完全な結果のコストは低いので、より多い結果とそれらの結果のより少ない手作業による検査と引き換えに、より低い信頼レベルが受け入れられることが多くなります。ただし、捜査で関心のある人物を識別するために顔認識を使用する場合は、法執行機関は推奨されている 99% の信頼度閾値 (文書化されているとおり) を使用し、あくまでも捜査の 1 つの要素としてのみ使用することが必要です。 Amazon Rekognition の「テスト」についてどのように考えるかについての上記の文脈で、私たちはこの最新のレポートとその誤った主張にたどり着きました。 この研究論文は「商業的な顔認識製品のパフォーマンスの脆弱性をさらす」ことを目指していますが、実際には代わりに顔分析を使用しています。 上述したように、顔分析と顔認識は 2 つの別々のツールです。顔認識の場合と同じ方法で顔を照合するために顔分析を使用することはできません。これは単に意味や定義の問題ではありません。2つの異なる目的を持つ 2 つの異なる機能なのです。顔分析では、主に画像のフィルタ処理や整理に役立つ一般的な特徴 (髪の毛、笑顔、眉をひそめる、性別など) しか見つけることができません。顔を一意に特定する知識は持ちません (これを画像からリバースエンジニアリングすることはできません)。対照的に、顔認識は、顔を照合するための顔の一意な特徴に焦点を合わせており、顧客が持ち込むデータセット内の顔と照合するために使用されます。顔認識を行うために顔分析を使用することは、一意の個人を識別するには不正確で推奨されない方法です。  これについてはドキュメントで説明していますが、この問題について混乱している顧客からの報告は受けていません。 その研究論文は、Amazon Rekognition が低品質の顔分析結果を提供していると述べています。しかし、これは、私たち自身の広範囲にわたるテストや、サービスを利用している顧客から聞いたことを反映していません。 まず、この研究者達は古いバージョンの Amazon Rekognition を使用しています。私たちは、11 月に大幅な改善を行っています。次に、AWS が Amazon Rekognition […]

Read More

EI 対応の TensorFlow 1.12 で利用できる柔軟性のある新型 Python API を使用して、Amazon Elastic Inference で TensorFlow モデルをデプロイする

Amazon Elastic Inference (EI) が、TensorFlow 1.12 の最新バージョンのサポートを開始しました。EI は、新しくなってさらに使いやすくなった Python API 関数である EIPredictor を備え、EI アクセラレーターを使用してTensorFlow モデルをデプロイします。EI で TensorFlow モデルを実行するのに、TensorFlow Serving に代わって、この新しい Python API 関数を推論スクリプト内で使用できるようになりました。EIPredictor では簡単な実験が可能で、EI の有無でのパフォーマンスも比較できます。このブログ記事では、EIPredictor を使用して EI にモデルをデプロイする方法を説明します。 まず、この背景から始めましょう。Amazon Elastic Inference は re:Invent 2018 で発表された新しい機能です。EI は、スタンドアロンの GPU インスタンスを使用するよりも、コスト効果が非常に優れた新しい方法を提供し、深層学習推論ワークロードを高速化します。EI を使用すると、任意の Amazon SageMaker または Amazon EC2 インスタンスタイプにアクセラレーターをアタッチでき、GPU の高速化によってもたらされる低いレイテンシー、高スループットといった利点を、極めて低いコスト (最大75%) で実現できます。EI では、TensorFlow、Apache MXNet、および ONNX モデルをデプロイし、推論を実行できます。 TensorFlow Serving を使用して、EI […]

Read More

Amazon Comprehend Medicalで、極秘ヘルスケアデータを識別し、それを扱い作業する

AWSで、私は定期的にAWSのお客様およびAWS パートナーネットワーク (APN) のパートナー様と、人間の健康の形を変えるためにどのように技術を使っていらっしゃるかについてお話します。これらの企業はしばしば人間健康管理および電子健康記録のような様々なアプリケーションで使用する大量の健康データを生成します。 開発者は保護健康情報 (PHI)のような極秘データに関するコンプライアンス義務に準拠しながら、これらのアプリケーションで価値のある医療情報を使用する方法を見つける必要があります。当社のお客様およびAPNパートナー様がこれを今日行っている一部のアプリケーションは、臨床決定サポート、収益循環管理、および臨床試験管理です。 データをマスクするために複数の方法があり、各組織が内部リスク査定にも続く独自のアプローチを有しています。当社はお客様が組織の特定の実装手順について、リスク査定専門家に相談されることを推奨します。一般的に、データは2つの手順でマスクされます。一つ目として、PHIが識別されなければなりません。その後、通常安全ルールまたは専門家の判断によって、データを匿名化する、または非識別するアルゴリズムが使用されます。このアプローチは一時的に自身に状態マシンを使用させ、お客様の組織が各手順で独立的に必要とする事業論理を適用し、状態間で情報を渡します。 このブログ投稿で、私はどのようにAmazon Comprehend Medical、AWS Step Functions, および Amazon DynamoDBの組み合わせを使用して、極秘健康データを識別し、お客様のコンプライアンス目標をサポートするお手伝いをするかを実証します。私はその後、お客様がしばしば採用するパターンであるアーキテクチャーの、見込まれる拡張のいくつかを論じます。 アーキテクチャ このアーキテクチャは以下のサービスを使用します: 文字列体内のエンティティを識別するためのAmazon Comprehend Medical ワークフローを調整および実行するためのAWS Step FunctionsおよびAWS Lambda 再識別されたマッピングを保存するAmazon DynamoDB このアーキテクチャーおよび後続のコードはAWS CloudFormationテンプレートとして利用できます。 個別の構成要素 AWS上で構築された多くの近代的なアプリケーションのように、アーキテクチャー内の個別の構成要素はLambda関数として表されます。このブログ投稿で、私は3つのLambda関数を構築する方法をお見せします。 IdentifyPHI:Amazon Comprehend Medical APIを使用して、文字列体からカルテのようなPHIエンティティを検出および識別します。 MaskEntities:IdentifyPHIから入力としてエンティティを取り、文字列体でそれらをマスクします。 DeidentifyEntities: IdentifyPHIからエンティティを取り、各エンティティにハッシュを付け、そのマッピングをDynamoDBに保存します。 それぞれを通して順番に見てゆきましょう。 PHIを識別する 以下のコードはJSON体で読み込み、メッセージからPHIエンティティを抽出して、抽出されたエンティティのリストを返します。 from botocore.vendored import requests import json import boto3 import logging import threading comprehend = boto3.client(service_name=’comprehendmedical’) def […]

Read More

Amazon Comprehend Medicalを用いた臨床実体の抽出及び可視化

 Amazon Comprehend Medicalは機械学習(ML)を用いて高精度で医療情報を抽出する、HIPAAの対象となっている新サービスです。これは大量の構造化されていない医療テキストを処理するためのコスト、時間、手間を低減します。薬、診断、投与量のような実体や関係を抽出することができ、またPHI(保護医療情報)も抽出することができます。Amazon Comprehend Medicalを利用することで、エンドユーザーは解析が困難な為ほとんど解析目的で利用されることのない生の臨床メモから価値を得ることが可能になります。これらのメモから情報を抽出して電子カルテ(EHR)や治験管理システム(CTMS)のような他の医療システムと統合することには計り知れない価値が存在します。本来なら廃棄されるような生のメモにある情報を考慮することで長期的な患者への視点の生成を可能にします。 他の全ての当社APIレベルサービスと同様、Amazon Comprehend Medicalの焦点は開発者にとっての使い勝手です。当社はAPIコールを利用することで、あるいはコンソールで呼び出すことができる事前訓練済みモデルを提供します。結果は、解析可能かつ他の構造臨床データセットとの統合が可能な、構造化されたJSONファイルとして返されますAmazon Comprehend Medicalについてもっと詳しく知るには、プロダクトマニュアルをご覧ください。 こちらの例では、Amazon Comprehend Medicalを使用してどのように臨床実体を抽出、Kibanaダッシュボード上で視覚化できるかをお見せします。このソリューションはAWS CloudFormationテンプレートとして提供されているのでご自身の環境で簡単にデプロイが可能です。 ソリューションのアーキテクチャ 本アーキテクチャ図はソリューションの様々なコンポーネントをショーケースしています。以下は各コンポーネントの詳細です: あなたの生の臨床メモを格納するためAmazon S3をプラットフォームとして使用することができます。 Amazon Comprehend Medical APIを利用して、メモをループスルーして様々な臨床実体や関係をメモから抽出しましょう。また抽出された要素をフィルタリングして、メモからPHI(保護医療情報)を除外することもできます。これは下流分析でメモ内の識別不可能な要素を必要とするユースケースにおいて有用です。 抽出された実体を含むJSONファイルは解析されAmazon DynamoDBテーブルに挿入されます。このテーブルは経時的な全臨床実体のリポジトリとして機能し開発者によって下流統合のため利用されることができます。 DynamoDBテーブルはストリームが接続しています。このストリームはストリーム上のイベントによってトリガーされたAWS Lambda関数を利用して解析されます。 Lambda関数はAmazon Elasticsearch Service (Amazon ES)ドメインにレコードを挿入します。このドメインは全臨床実体情報によって最新の状態を維持することができます。 臨床実体を可視化するためKibanaダッシュボードがAmazon ESの上に構築されています。これはメモに関する分析情報及び検索機能を求めるエンドユーザー向けエントリポイントとして機能します。 ソリューションのデプロイに関する說明 ここではソリューションのデプロイのためAWS CloudFormationスタックを利用します。CloudFormationスタックは本ソリューションによって必要となるリソースを作成します。次が含まれます: S3 バケット DynamoDB テーブル Lambda 関数 必要なAWS Identity and Access Management (IAM) のロール この例では、us-east-1 (バージニア北部)のAWS リージョンを使用します。 IAMのユーザー名とパスワードを使って、AWS マネジメントコンソールにサインインしてください。下の「スタックをローンチ」アイコンを右クリックして新規タブで開きます。 […]

Read More
keras-logo

Amazon SageMaker で簡単に Keras を使う方法

Amazon SageMaker は、すべての開発者とデータサイエンティストに機械学習モデルの構築、トレーニング、デプロイの手段を提供する AWS のマネージドサービスです。SageMaker は深層学習の主要なフレームワークをサポートしており、TensorFlow、Apache MXNet、PyTorch、Chainer などを用いてモデルを記述することができます。また、TensorFlow や MXNet をバックエンドとした Keras の高レベルな API を用いることで、モデルを簡単にすばやく作成することもできます。 これまで、Keras で書いたコードを SageMaker 上で動かす方法について、多くのお客様からご質問を頂いておりました。2018年12月に、SageMaker の TensorFlow ならびに MXNet のコンテナに、それぞれのフレームワークをバックエンドとする Keras がデフォルトでインストールされました。また両コンテナでは Script Mode をサポートしているため、SageMaker 外で開発した Keras のコードに、わずかな修正を加えるだけで動かすことができるようになりました。ここでは Keras 公式サンプルコードの mnist_cnn.py をなるべくそのまま利用して、SageMakerのTensorFlowとMXNetコンテナで実行する方法をご説明します。   TensorFlow Backend での Keras の使い方 トレーニングスクリプトの修正 AWS のマネージドコンソールから SageMaker ノートブックインスタンス (Jupyter/JupyterLab) を開き、Keras のリポジトリをクローンします (このブログのようにノートブックインスタンスの作成時に関連付けることも可能です)。keras/examples/mnist_cnn.py の中で以下の3点を修正します: 学習からモデルの保存までを train(args) 関数として定義します。ここでは次の手順で読み込む args […]

Read More