Amazon Web Services ブログ

利用したいテクスチャをライブラリから探す作業は非常に手間がかかる作業です。Amazon RekognitionやAmazon Machine Learning APIを利用することで、テクスチャへのタグ付けを行い、高速な検索が実現できます。 ゲーム開発では一般的に”painter’s pallet(画家のパレット)”として扱われるテクスチャやシーンを扱う巨大なアセットライブラリを持っています。これらは3Dのランドスケープや地形を表現するために利用されており、データの選択によって世界観をを変えることができるため、非常に重要なものとなります。テクスチャによっては実生活の風景や漫画の陰影、セル画調での世界滅亡の風景などを自由に表現することができます。 膨大な数のデータが保存されているライブラリから、何千ものテクスチャを選ぶことも珍しいことではありません。その場合、まれに正しいタグが付与されていなかったり、ファイルやフォルダ名に依存することで生じる誤解などが問題となります。より正確性を向上するために、正確なタグ付けを手作業によって行うことは非現実的でとてつもない作業になるでしょう。 正確なタグ付けを実現するために、１人または複数人でデータを確認し、意見を集め、その情報によって各ファイルにタグ付けをする必要がありますが、どんなシナリオでも非常に多くの時間がかかります。 しかし、機械学習を利用したAmazonの画像認識サービスであるAmazon Rekognitionを使えば、これらの作業を非常に簡単に高速に行うことができます。アーティストがファイルを開くのに40秒かかり、画像を見て意見を集め、複数のタグを書き込んでデータベースに格納する場合、5,000ファイルを処理するのに約55時間を要します。Amazon Rekognitionを利用する場合、画像のアップロードをバッチ処理することが可能で、私たちのテストコードでは200Mbpsの速度でアップロードしたところ3分未満で完了しました。 試してみましょう！ もし１枚の画像で試す場合、こちらをご確認ください。画像をアップロードし、レスポンスを確認するだけです。 https://console.aws.amazon.com/rekognition/home?region=us-east-1#/label-detection もちろん、SDKもご利用になれます。こちらのページからインストールできるAWS SDKを利用します。 https://aws.amazon.com/tools/#sdk それでは、特定のフォルダで簡単なサンプルを動かしてみましょう。ご紹介するサンプルはフォルダの中のすべてのJPEG/PNGファイルをAmazon Rekognitionにアップロードし、メタタグをファイル名と一緒にSQLiteに保存します。また、簡単な検索機能も提供します。 今回はPythonを使ったシンプルな例をご紹介します。もしあなたがPythonのファンではない場合は、AWS SDKでサポートされているお好みの言語を利用いただくことができます。 まずはAWS SDK for Pythonをこちらの手順に沿ってインストールします。 https://boto3.readthedocs.io/en/latest/guide/quickstart.html 最も早い方法は”Boto3″パッケージのインストールです。 pip install boto3 また、AWSアクセスキーの設定をAWSマネージメントコンソール(https://console.aws.amazon.com)から行います。 [IAM]-[ユーザー]-[認証情報]-[アクセスキーの作成]をクリックしてください。 アクセスキーIDとシークレットアクセスキーをメモし、以下のクイックスタートの設定ファイルを編集してください。（Macの場合は”~/.aws/credentials”、Windowsの場合は”%USERPROFILE%\.aws\credentials”となります。） あとは数行のコードで実行することができます。 1.　boto3のライブラリをインポートします。 import boto3   2.  利用するリージョンをRekognition APIに設定します。 def detect_labels(bucket, key, imagebytes=None, max_labels=6, min_confidence=70, region=”us-east-1″): rekognition = boto3.client(“rekognition”, region)   3. […]

人工知能 (AI) および機械学習 (ML) の分野は、ヘルスケア産業、特に医用画像化において、勢いを増しつつあります。ML に対する Amazon SageMaker のアプローチは、ヘルスケア分野において将来有望であると言えます。ML は、産業間全体のどの分野においても、適用可能であると考えられています。ヘルスケア分野の範囲で言えば、ML は最終診断を下すための重要な要素として、放射線検査または検査報告のような役割を果たすことが可能なのです。 このブログ投稿では、UCI ML Dataset を使用して、整形外科における ML の使用について説明し、脊椎の病状予測を自動化することを目指します。この技術は、診断時間を短縮し、ML を用いた拒絶選択肢技術を促すことによって、診察訪問数および / または処方数を最小限に抑える対策について考えるよい機会となるでしょう。 この技術により、難しい症例は整形外科医などの専門家に委ねられることになるでしょう。データセットの 2 つの診断である、椎間板ヘルニアおよび脊椎すべり症は、筋骨格疼痛障害を引き起こしうる脊髄病変の 1 つです。疼痛障害のためのオピオイド処方を最小限に抑えるため、リスクにさらされている患者を客観的かつ効果的に特定し治療を行うことのできる ML 技術を駆使することで、コンピュータ支援診断システムに可能性を見出すことができるのです。 このブログの記事では、これらのデータセットをダウンロードして、脊柱の特徴または特性に基づいて、正常または異常な整形外科的あるいは脊髄の病状 (ヘルニアまたは脊椎すべり症) を有するかどうかを予測するための例を提示しています。これらの病状の特性を考慮する予備診断ツールは、高い偽陽性率を有します。MRI は、腰椎椎間板ヘルニアの抑制を検出するのに使用しますが、この技法では ~ 33％ の偽陽性率を有します。診断に用いる脊髄ブロック (注射) は、22％ から 47％ の偽陽性率があります。(注: これを ML モデルを評価する際のベースラインとして使用します)。 これらのデータセットは、マルチクラスおよびバイナリ分類問題の両方を提示します。 病理予測のための Amazon SageMaker での ML モデルの作成 この投稿では、マルチクラスのカテゴリ分類モデルとバイナリ分類モデルという 2 つのモデルを作成し、両方を評価します。マルチクラスのカテゴリ分類は、正常、椎間板ヘルニア、または脊椎すべり症の病状を有するかどうかを予測します。バイナリ分類はバイナリ応答を予測します。0 – 正常、または 1 – […]

先月、私は Nitro システムについて語り、これがどのように EC2 インスタンスの選択肢を広げ、コンピューティング、ストレージ、メモリ、ネットワークオプションの選択肢を拡大することでペースを速めることができるかを説明しました。これによって最新テクノロジーへのアクセスが非常に迅速に可能になり、アプリケーションに最適なインスタンスタイプを選択することができます。 本日は、現在準備中で、間もなく利用できるようになる新しい 3 つのインスタンスタイプを紹介します。 Z1d – 持続するオールコア Turbo Boost を搭載した最大 4.0 GHz で動作する計算集約型インスタンス。これらは EDA (Electronic Design Automation) やリレーショナルデータベースワークロードに最適であり、複数の HPC ワークロードにも適しています。 R5 – 持続するオールコア Turbo Boost を搭載した最大 3.1 GHz で動作するメモリ最適化されたインスタンスで、R4 インスタンスと比べて最大 50% 増加した vCPU と 60% 多くのメモリを搭載しています。 R5d – ローカル NVMe ストレージ (最大の R5d インスタンスでは最大 3.6 TB) を持つメモリ最適化されたインスタンスで、R5 インスタンスと同じサイズ、同じ性能で利用できます。 また、R5 ベアメタル、R5d ベアメタル、Z1d […]

私は工場が大好きで、見学ツアーがあれば必ず参加するほどです。これまでも運良く、原材料や組み立て部品が、車、機関車、メモリチップ、連結式バスといったものに変化するのを見れる機会がありました。スピード、精度、再現性、そして可能な限り全ての生産段階をオートメーション化しようとする努力に、いつも感心するのです。最近参加したツアーで、EC2 インスタンスや他のクラウドリソースと同じくらい簡単かつ効率的に、機械装置をモニタリングするオンプレミスの工業用 PC のグローバルコレクションを設定し、集中管理できるようにしたいと、IT マネージャーが言うのを耳にしました。 そして今日、AWS Snowball Edge デバイス上で作動する EC2 インスタンスの導入により、彼の夢が実現しようとしています。100 TB のローカルストレージを備え、耐久性を持つこのデバイスを使うと、限定したまたは存在しないインターネット接続といった厳しい環境においてデータを収集および処理した後、処理済みデータを保存、集約、詳細分析するために AWS に戻すことが可能となります。インスタンスのスペックは次をご覧ください。 インスタンス名 vCPU メモリ sbe1.small 1 1 GiB sbe1.medium 1 2 GiB sbe1.large 2 4 GiB sbe1.xlarge 4 8 GiB sbe1.2xlarge 8 16 GiB sbe1.4xlarge 16 32 GiB 各 Snowball Edge デバイスは、Intel ® Xeon ® D プロセッサを 1.8 GHz で実行でき、インスタンスのどんな組合わせもサポートすることで、最大 24 […]

本日、Amazon Translate が、日本語、ロシア語、イタリア語、繁体字中国語、トルコ語、さらにチェコ語のサポートを追加しました。Amazon Translate は、高速で高品質な言語翻訳を、お手ごろな価格で提供する翻訳 API です。Amazon Translate は元々、2017 年開催の AWS re:Invent でのプレビューでリリースしました。同僚の Tara が、このサービスの詳細について書いています。 最初のプレビュー時から、Amazon Comprehend 、 Amazon CloudWatch の指標、および各 TranslateText 内にある膨大なテキストを使った自動ソース言語推論のような機能を追加しようと、お客様とのやり取りを続けてきました。4 月にはこのサービスが一般に利用可能となり、機能のリクエストやフィードバックをお客様から引き続きいただいています。 Amazon Translate との連携 Amazon Translate コンソールにある API エクスプローラーを使って、今すぐ新しい言語を試してみてください。 任意の SDK を使用することもできます。以下に、簡単な Python のサンプルを書いてみました。 import boto3 translate = boto3.client(“translate”) lang_flag_pairs = [(“ja”, “????”), (“ru”, “????”), (“it”, “????”), (“zh-TW”, “????”), (“tr”, “????”), (“cs”, […]

多くのお客様が、Amazon EMR と Apache Spark を使用してスケーラブルなビッグデータパイプラインを構築しています。大規模な生産パイプラインの場合、一般的ユースケースは、さまざまなソースから発生する複雑なデータを読み取ることです。このデータは、機械学習パイプライン、分析ダッシュボード、ビジネスレポートなどの下流アプリケーションに役立つように変換する必要があります。このようなパイプラインでは、Amazon EMR で Spark ジョブを並行して実行することがたびたび必要になります。この記事では、EMR バージョン 5.9.0 以降で利用可能な Apache Livy を使用して、複数の Spark ジョブを EMR クラスター上で平行して送信する方法を中心に取り扱います。 Apache Livy は、REST インターフェイスを通じて、Spark クラスターとのやりとりを容易にするサービスです。Apache Livy を使用すると、大きな jar ファイルを管理、デプロイする代わりに、REST API コールでシンプルな Scala コードまたは Python コードを送信できます。これは、EMR ステップ API を使用してシリアルで実行するのではなく、複数の Spark ジョブをパラレルで実行することでデータパイプラインを容易に拡張できるためです。お客様は、ワークフローの一環として一時的なクラスターを継続して利用し、結果としてコストを削減できます。 このブログ記事の目的に合わせ、今回は Apache Airflow を使用してデータパイプラインをオーケストレーションします。Airflow は ETL タスクの管理に役立つオープンソースのタスクスケジューラです。ワークフローを 1 か所からスケジューリングして管理できるため、Apache Airflow はお客様に人気があります。Airflow の Configuration as Code […]

(この記事は2018年7月17日に公開したあと、7月31日にシナリオが更新されたので追記しました） みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 2018年7月3日にAmazon SageMaker ハンズオンを弊社目黒オフィスで開催しました。講師は弊社ソリューションアーキテクトの志村と鮫島がお届けさせていただきました。 その時の資料が公開され、ご自宅でもハンズオンを楽しんでいただくことができるようになりましたのでお知らせいたします。 Amazon SageMaker 紹介 & ハンズオン（2018/07/03 実施） from Amazon Web Services Japan Amazon SageMaker 紹介 & ハンズオン（2018/07/25 実施） from Amazon Web Services Japan （2018年7月31日、シナリオが新しく更新されました） 57ページからがハンズオンの資料となっています。SageMakerはその学習モデルの開発においてJupyter Notebookを使用します。このため、ハンズオンではあらかじめ用意されたJupyter Notebookの内容に従って作業を進めて行く形態をとっています。中身はDeep Learningですので、慣れてない方からすると、すべてを理解いただくのが大変な一方で、ハンズオンの完走自体は非常に簡単に行っていただけるような工夫がされています。 最後に自分のマウスで書いた手書きの文字を判別する実習を行ってハンズオンは終了となります。 またSageMakerは非常に頻繁にアップデートがかかっています。 https://aws.amazon.com/jp/blogs/news/category/artificial-intelligence/sagemaker/ 2018年6月1日東京リージョンでの一般提供開始以降に対応した主なアップデートが以下です。 トレーニングジョブのクローン作成機能 自動モデルチューニングにおけるハイパーパラメーターチューニングに対応 PyTorch と TensorFlow 1.8 のサポート AWS PrivateLink を使用した Amazon Virtual Private Cloud […]

AWS ヒーローの新しいカテゴリーを立ち上げ 2014 年より AWS コミュニティヒーロープログラムを開始し、AWS エキスパートたちが運営する活気あふれたグループを認定しています。優秀な開発者がその幅広い知識を駆使し、いろんな媒体にわたり AWS 製品とサービスに関して顧客や技術者を教育しています。AWS が成長するにつれ、ヒーローの新たなグループがどんどん生まれています。 今日、優れたコミュニティリーダーを認定しましたが、AWS ヒーロープログラムが拡大してきている証拠です。コミュニティ内で AWS サービスを幅広く推奨することを目的とするコミュニティヒーローとは異なり、今回の新しいカテゴリーのヒーローは特定のテクノロジーの開発に努力し、その推奨に取り組むスペシャリストたちです。新しいヒーローとして最初に立ち上げたカテゴリーは、AWS サーバーレスヒーローと AWS コンテナヒーローです。テクニカルコミュニティでは、AWS のナレッジ共有へのあふれる情熱がますます大きくなっています。ぜひ、新しいヒーローたちの登場を歓迎してあげてください。 AWS サーバーレスヒーロー サーバレスヒーローは、AWS サーバレスエコシステムを早期に取り入れた熱意あふれるパイオニアたちです。GitHub や AWS Serverless Application Repository のオープンソース化に対する貢献だけでなく、AWS サーバーレステクノロジーをオンラインや対面で普及させる活動を行っています。こうしたサーバーレスヒーローは、開発者、企業、コミュニティなどが最新鋭のアプリケーションを構築する際、その発展に一役買っている人たちです。サーバーレスヒーローとして最初に選ばれたコホートは、下記の人たちです。 Yan Cui Aleksandar Simovic Forrest Brazeal Marcia Villalba Erica Windisch Peter Sbarski Slobodan Stojanović Rob Gruhl Michael Hart Ben Kehoe Austen Collins AWS コンテナヒーローのご紹介 AWS コンテナヒーローは、AWS […]

Amazon SageMaker が、分類と回帰の問題を解決するため、ビルトイン k-Nearest-Neighbor (kNN) アルゴリズムのサポートを開始したことをご報告します。kNN は、マルチクラス分類、ランキング、および回帰のためのシンプルで、解釈しやすい、そして驚くほど強力なモデルです。 kNN の導入 kNN の背後にある考えは、類似したデータポイントは、少なくともほとんどの時間、同じクラスを持つ必要があるというものです。この方法はとても直感的で、レコメンデーションシステム、異常検出、画像 / テキスト分類を含む多くの分野で実証されています。 例えば、「人物」、「動物」、「屋外」、「海」、「日没」など、考えうる 2000 のタイプのうちの 1 つとして、あるイメージを分類する場合を考えてみましょう。画像間の適切な距離関数が与えられると、ラベル付けされていない画像の分類は、最近傍に割り当てられたラベル、すなわち距離関数に従ってそれに最も近いラベルの付いた画像によって決定されます。 あまり見られませんが、kNN の別の使用法は、回帰問題です。ここでの目的は、クエリのクラスを決定するのではなく、むしろ連続する数字 (例えば、特定の人の給与、ある実験にかかるコストなど) を予測することです。クエリの予測は、その近傍のラベルの関数として設定されます。通常は、平均として、そして時には外れ値を特定する方法としての平均値または幾何平均として、設定されます。 どんな時に kNN を使用するか? kNN 分類と回帰の使用を考えている場合に、考慮すべきいくつかのメリットとデメリットについてご紹介します。 メリット 予測品質: kNN クラシファイヤー (分類器) は、例えばクラス間の線形分離を必要とする線形クラシファイヤーとは対照的に、空間の非構造化パーティションを回復することができます。また、空間の異なる密度にも適応することができ、放射基底関数 (RBF) カーネルによるサポートベクターマシン (SVM) 分類といった方法よりも安定しています。 2D データの下記の 2 つの例は、ラベルの付いたデータによって与えられた空間の異なるパーティションおよびその空間上の kNN モデルの予測を示しています。 短いサイクル: kNN のもうひとつの利点は、トレーニングがほとんど、あるいは全く必要ないことです。つまり、深いネットワークや SVM、または線形関数などの多くのトレーニング手順を必要とするクラシファイヤーと比較すると、入力データセットの考えられる様々なメトリック / 修正に対する反復が、潜在的に高速であることを意味しています。 多くの出力クラス: kNN は非常に多くのクラスをシームレスに処理できます。比較すると、交差エントロピー損失を伴う線形モデルまたはディープニューラルネットワークは、考えられる各クラスのスコアを明確に計算し、最良のものを選択しなければなりません。例えば、画像または特徴のセットによって花の種類を認識するタスクを想像してください。10 万個のラベルが付いた特徴の例と 5,000 個の花の種類の例があります。それぞれの花の種類を識別するのに、5,000 個のパラメータセットを明確に学習するモデルはどれもすぐに過学習してしまう傾向があり、誤った答えを生む可能性があります。 […]

本日私たちは Amazon SageMaker の DeepAR について、いくつかの新機能をリリースしています。DeepAR は再帰型ニューラルネットワーク (RNN) を使用して確率的予測を生成する、時系列予知または予測のための教師付き機械学習アルゴリズムです。発表以来、このアルゴリズムはさまざまなユースケースにおいて使用されてきました。今回のリリースにより開発者は、欠損値のサポート、ユーザー提供による時系列機能、複数のカテゴリー機能、頻度の一般化などの新しい機能にアクセスできるようになりました。 予測はあらゆる分野へ 予測は、多くの業界に渡りビジネスプロセスを改善することができます。これにより、機械学習 (ML) と人工知能 (AI) を使用して自動化と最適化の世界への理想的なエントリーポイントを予測することができるようになるのです。より良い製品需要予測を通じてサプライチェーンを最適化するかどうか、Web サーバーのトラフィックを予測することによってコンピューティングリソースをより効果的に割り当てるかどうか、患者のニーズを満たすために病院にスタッフを派遣して人命を救うかどうかなど、ほとんどの分野において予測は素早く投資に対する効果を見せてくれるでしょう。 Amazon では、予測を使用しさまざまな分野におけるビジネス意思決定の自動化を推進しています。これらの中にはフルフィルメントセンターでの製品や労働需要の予測や、AWS サービスのキャパシティ予測などが含まれます。 DeepAR アルゴリズムの新機能 このブログ記事では、今回利用可能となった DeepAR アルゴリズムの新機能の概要を簡単に紹介させていただきます。 欠損値のサポート 予測アルゴリズム (またはそれらの実装) においてはデータが完全であると仮定している場合が多いのですが、現実は一致しない傾向にあります。実際には、時系列データはたびたび部分的にしか観察されない場合があります。たとえば、時系列にセンサーデータが含まれていて、そしてそのセンサが一定時間に渡って故障していたりオフラインであったりする可能性があります。需要予測時に製品の在庫がなくなったり、サーバーのトラフィック時系列情報がダウンタイムや設定ミスのために数日間利用できなくなる可能性があるのです。このような場合、予測アルゴリズムを使用する前に不足している値を埋め (置き換え) なければならないという負担がユーザーにかかる場合が頻繁に発生します。しかしながら、誤って置き換えられたデータは予測に悪影響を及ぼす可能性があります。たとえば、在庫切れ状況により観測されていない値をゼロに置き換えた場合、予測はゼロに向かって偏っていきます。確かにこれは、特に長い在庫切れ段階の後に将来の製品需要を予測したい場合には望ましくありません。 DeepAR の最新リリースにおいては、モデル内で欠損値が直接処理されるようになりました。これにより、欠損値を含む時系列の予測が容易に (前処理時の置き換えは不要)、かつより正確に (粗い外部置き換え手法に頼るのではなく、RNN モデルを利用することにより) なります。 欠損値を持つ時系列の予測をモデルが生成する方法の例は、以下の通りです。 カスタム時系列機能 DeepAR に対してお客様から最も多く頂いた要望の 1 つは、カスタムの時間変動機能をモデルへと供給することでした。時系列を予測する場合、ユーザはしばしばターゲットとなる時系列について有用な情報を提供することができる他の説明的な時系列を有しています。たとえば製品の需要を予測する場合には、一定期間内にプロモーションが実施されたかどうかや製品の価格がどの程度であったかなど、時間に依存する情報へとアクセスをするかもしれません。(DeepAR が内部的に提供するデフォルトの季節性機能に加えて) カスタムの季節性パターン、因果効果などをモデル化する独自の機能時系列を提供できるようになりました。この時間変動性を持った情報の使用は、そうでなければノイズに起因する効果を「説明する」ことにより、最終的に精度を向上させる可能性があります。さらには、「what if」シナリオをシミュレートすることもできます。たとえば、「今後この商品を 1 週間プロモーションするとどうなるか?」などです。 ここでは、短期需要の増加と相関する時間変動機能 (青色の線) を使用する例を示します。実際には、これはプロモーションイベントまたは特別なカレンダーイベントです。この例において、DeepAR はこの機能によって需要の増加した期間とそれ以外の期間を区別することができます。 時系列ごとの複数カテゴリ 特定の時系列を予測する場合、グループ情報は非常に役立ちます。特に、利用可能な履歴データがあまりない場合に便利です。以前の DeepAR は単一のカテゴリ分類属性によって時系列をグループ化することをサポートしており、ユーザーは時系列のグループの可能な […]