orizuru

つながる.見える.わかる IoTソリュ-ション

main_contents

更新情報

工場(製造現場)向けIoTソリューション

自社のIoTシステムを利用した工場(製造業)向けソリューション「Orizuru」は、工場内の各種設備からデータを収集する「ゲートウェイ」、収集したデータ処理をする「データプラットフォーム」、リアルタイムにデータを見える化する「ダッシュボード」、3D CADデータをブラウザ上で表示する「3Dビュー」などの各システムを備えるトータルソリューションになります。

IoTソリューション「Orizuru」では、これらの各ソリューションの個別提供から、「ゲートウェイ」「データプラットフォーム」「ダッシュボード」をパッケージングした「Orizuru IoT」の提供をしております。また、3Dデータをクラウドで管理、表示、検索できる機能を備えた「Orizuru 3D」の提供もしております。

IoTソリューション全体像

IoTソリューション全体像

  • 設備のデータ収集
  • 設備の制御
  • 他のシステムへのデータ連携
  • サーバとのデータ送受信
  • リアルタイム通信
  • リアルタイム検知・通知
  • データの統計処理と機械学習
  • データ保存先選択
  • 各種データのグラフ化
  • 設備ごとの見える化
  • 設備のコントロール
  • ユーザ管理
  • 3Dデータの各種表示
  • 3Dデータの360°ビュー
  • 大容量データの表示

IoTソリューション「Orizuru」の特長

製様々な設備のデータ収集
工作機械で使用するCNCやPLC、産業用ロボット、温度や振動などのセンサーなどのデバイスから各種データを収集することが可能です。様々なデバイスからデータを集約して収集できることで、管理メリットが生まれます。
データの他システムへの連携
昨今様々なwebサービスがありますが、それらの各種webサービスへのデータ連携が可能です。例えば、見える化のwebサービスやBIツールなどへのデータ連携、それ以外にも社内システムへ連携することができます。
データの一元管理
Gateway(ゲートウェイ)から送られてくる様々なデータを一元管理します。様々なソリューションやサービスを使うことによるデータ管理コストを抑えられ、御社の貴重なデータ資産を管理します。
AI、機械学習によるデータ活用
解析したデータを活用し、不良品の検知や製品需要予測、設備異常の検知、製品の故障予測などに繋げることができます。お客様の課題にあわせて必要なデータを取得することから始めていきます。
自動化、予兆保全の実現
AI・機械学習により予測や異常検知できたことをキーとして、次のアクション、すなわち自動化や予兆保全を実現することが可能です。データ活用としてコスト削減や品質改善などを実現します。
各種データのグラフ化
データを目的に応じて表示を変えることが可能です。時系列データーであれば折れ線グラフ、累積データであれば円グラフや棒グラフなどの形式で表示でき、データの取得間隔を狭めることで、リアルタイムデータでの表示も可能です。
巨大な3Dデータをwebで表示
数十GBに及ぶ巨大な3Dデータもスムーズにレンダリングして表示することができます。また、専用ソフトを必要とせず、様々な形式のデータをWebブラウザやスマートフォンで確認することが可能です。
3Dデータの検索
管理しているデータから類似する3Dデータを検索できます。データ形式を問わず、異なる3Dデータを横断して検索可能です。3Dデータ作成前に類似データを確認することで、設計の二度手間を防ぐことができます。
点群データを扱える
CADデータだけでなく、点群データも管理できます。従来は別々に管理していたデータを結合することで、複数のソフトウェアを立ち上げてデータを検索しなければならないといった手間がなくなります。

Orizuru IoT

工場IoT

Orizuru IoTは設備を制御しているCNCやPLC、ロボット、各種センサーとゲートウェイが通信することでリアルタイムにデータを取得、蓄積していくことが可能です。 Orizuru IoTは、マルチデバイス対応ができる国内唯一のソフトウェアです。多くのお客様が実現したいと考えられている、工場、ライン、設備単体の稼働監視や故障原因の特定も、Orizuru IoTでデータを取得することで可能になります。ゼロベースからIoTシステムの開発をすると大規模投資が必要になります。Orizuru IoTならば短時間で設備との通信を確立させることが可能です。 Orizuru IoTによって工場のスマート化を実現させてください。

「Orizuru IoT」の詳細はこちら

Orizuru 3D

3Dデータのweb表示

Orizuru 3DはCAD・点群などの3Dデータを統合管理するソフトウェアです。これまで扱えなかった数十GBに及ぶ容量の巨大な3DデータをWebブラウザで表示できます。それぞれのデータ形式ごとの専用のソフトウェアを使う必要はありません。また、類似する他の3Dデータを、データ形式を問わず横断的に検索できます。クラウドサービスとして提供しているだけでなく、セキュリティや通信速度などのご要望に応じてオンプレミス環境で社内ツールとしてもご利用いただけます。​

「Orizuru 3D」の詳細はこちら

IoTソリューション紹介動画

IoTのお悩み解決

 お客様からIoTに関する様々なお悩みをご相談いただいております。IoTの導入に関することやデータの取得方法、取得したデータの活用方法や見える化など多岐にわたります。このようなお悩みごとに対して弊社としてもなんとか解決したく、日々ご提案をしています。こちらでは、その内容の一部をご紹介します。

パートナー・会員

三菱電機のe-F@ctoryパートナー

e-F@ctory Allianceとは、弊社FA機器との接続親和性の良いソフトウェア・機器を提供するパートナーとそれらを活用しシステムを構築するシステムインテグレーションパートナーとの強力な連携により、お客様に最適なソリューションを提供するためのFAパートナープログラムです。

  • e-F@ctory Allianceの詳細は、こちら をご覧ください。

e-F@ctory Alliance

Aras社の公認パートナー

Aras Innovator®は米国Aras社が開発・提供している、ライセンスフリーのエンタープライズPLM(Production Lifecycle Management)ソリューションです。製品の企画・設計から生産・保守までの製品ライフサイクル全体の管理が行えます。

  • Aras Innovatorの詳細は、Aras PLMソフトウェア をご覧ください。
  • Aras®およびAras Innovator®は、Aras Corporationの登録商標または商標です。

Aras AUTHORIZED Partner 2017

BECKHOFF社の開発パートナー

2018年よりベッコフオートメーション株式会社 の開発パートナーとして、弊社はソフトウエアの開発をサポートさせていただいております。BECKHOFF社製品とソフトウエアとのコミュニケーションを円滑にできる技術支援などを行わせていただいてます。

BECKHOFF

ORiN協議会の会員

ORiN (Open Resource interface for the Network)とは,メーカ・機種の違いを超え、統一的なアクセス手段と表現方法を提供する通信インターフェースです。ロボット、PLC、NC工作機械などの制御装置の情報にアクセスするための標準仕様であり、ORiN2SDKとして実用化されています。

ORiN協議会

AWSパートナーネットワーク(APN)

弊社はAPNコンサルティングパートナーとして、AWS上での顧客のワークロードとアプリケーションの設計、開発、構築、移行、および管理を支援することが可能です。AWSのシステムインテグレーションやアプリケーション開発などご相談いただけます。

AWSパートナーネットワーク(APN)

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
こんにちは、アートディレクターのhayatoです。
先月に続き、今月もLT会を開催。
今回は「今さら聞けない!IoT・AI技術」と題して、IoTやAIの基本的な部分の解説を交えて事例や経験談などに話を展開します。若手層の参加者を想定していましたが、意外と満遍なくのご参加で私の予想は当てにならないものだと感じました。。。

開催概要

開催日時 2018年11月16日(金)19:00~21:00
開催場所 株式会社コアコンセプト・テクノロジー カフェスペース
概要 弊社ではIoTやAIソリューションの提供や各種コンサルティング、IT開発の受託案件などを行っております。 Orizuruチームでは、「Orizuru」を中心とした「Orizuru IoT」「Orizuru 3D」などの製品を開発しています。これらIoTやAI関連の開発を進めている技術者やメンバーにその技術話や開発体験談、顧客の抱える課題など、 飲食を交えながらLTを行います。いつもは濃いめの内容ですが、今回は初めての方が聞いても内容が分かるように基本と実例を交えて発表いたします。
対象
  • IoTやAIエンジニアに興味がある方
  • IoTやAIなどの居心地の良いコミュニティを探している方
  • IoTやAIに関わっていて、実用的な情報を欲している方
  • IoTやAIソリューション開発に興味がある方

発表内容

ここをタップして表示Close
担当者 発表タイトル 発表概要
IoTエンジニア Orizuru IoTは何を変えたのか 【IoTの活用・導入事例】Orizuru IoTの導入事例をもとに製造現場においてIoTをどう活用すべきかを考える。
AIエンジニア AIによる簡単レコメンドシステム実装 【AIの活用方法とレコメンドの仕組み】AIを活用してどのようなことが出来るのか他社事例などをご紹介。さらに、AIを用いたブログや商品のレコメンドシステムの概要、開発事例を説明した上で、機械学習のアルゴリズムを用いた簡単なレコメンドシステムの実装方法を紹介する。
AIエンジニア 深層強化学習入門 【深層強化学習】2016年、GoogleのAlphaGoが囲碁の名人に勝利しました。このAlphaGoでも使われている深層強化学習について、ほんの入り口だけを紹介します。
センシング サイエンティスト 工場に!オフィスに!明日、お安く、安全に導入できるセンサー紹介します 【センサ活用】IoTわからないときは、とりあえずセンサ使ってみましょ~。でも、時間ない、予算ない、セキュリティ対策ない・・・。そんな方々のためにセンサに関する最低限の知識と、専門家が勧める入門センサを紹介します。
CTO なぜIoTプロジェクトは途中で止まってしまうのか。 【スペシャルコンテンツ】世の中の数々のIoTプロジェクトは成功しているのか、それとも失敗しているのか。どの程度の割合なのか、そして成功とはなんなのかを自社での開発経験を踏まえてご紹介します。

LT会の様子

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
2ヵ月連続の開催の今回は5回目となりました。
今回もファイシリテーターは池田が担当しました。

Orizuru IoTは何を変えたのか

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
トップバッターは、製造現場に詳しいIoTエンジニアの込山。
弊社のIoTソリューション「Orizuru IoT」の開発にも携わっております。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
まずは、Orizuru IoTの機能について簡単に説明。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
こちらの事例では、金属加工工場にOrizuru IoTを導入し、製造コストの削減に寄与したと解説。
具体的には、製造用プログラムを作成し、製品に合わせた工作機械の設定をすることで得られた結果であると紹介。
これ以外にも事例を紹介しつつ、どんな効果があったかを解説。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
最後に本日のまとめ。
スモールスタートからスケールさせていくことで効果が期待できるのかなと感じました。

AIによる簡単レコメンドシステム実装

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
続いて、AIエンジニアの馬場。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
まずはレコメンドシステム概要を解説。
特徴を定量的に定義することがポイントです。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
基本的な解説の後は実際に作ってみたレコメンドシステムを紹介。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
詳しい内容は、こちら(機械学習入門記~ブログをレコメンドするプログラムを作ってみた)の記事に記載してありますが、
データクリーニングの内容など詳しく説明することで、みなさん真剣に聞いていただけました。

深層強化学習入門

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
次もAIエンジニアの熊田。
深層強化学習について解説。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
深層強化学習(DQN)を活用した事例を紹介。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
こちらはネズミに2種類のボタン「電源ボタン」と「商品ボタン(餌が出てくるボタン)」を学習させる内容を図解したもの。
回数を重ねると「電源ボタン」「商品ボタン」の順にボタンを押すと餌が出てくることを学習する。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
今回の話をまとめとしてはこちらになります。

工場に!オフィスに!明日、お安く、安全に導入できるセンサー紹介します

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
続いては毎回恒例のセンシングサイエンティストの坂本。
今回もセンサを紹介してもらいました。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
よく使用するセンサはこちらの4種になります。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
今回はよく使用するセンサではなく、ほこりセンサについて紹介。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
実際のセンサがこちら。秋月で900円とのこと。
安く購入できるので、様々なシチュエーションでご活用いただければと。

なぜIoTプロジェクトは途中で止まってしまうのか。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
最後はCTO田口のスペシャルコンテンツ。
今回はIoTプロジェクトの失敗に関する考察。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
GEの話。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
Googleで検索するとたくさんでてくる「IoTプロジェクト 失敗」。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
なんとIoTプルジェクトの3/4は失敗している。。。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
失敗と成功の理由は様々。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
ここで疑問。IoTプロジェクトの成功の定義とは。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
各コストが下がることも一つ。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
逆に売上を上げることも一つ。

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
最後の見解として、コストを下げることも重要だが、それ以上に売上・利益へ貢献するほうが大きな成功につながるのではないでしょうか。

懇親会では恒例のお寿司登場

IoT/AIイベントを実施:【寿司懇親会付き】今さら聞けない!IoT・AI技術 #5
LT後はお寿司を食しながらの懇親会。
私がお話を聞いたお客様からは、「AIのデータクレンジングの話が分かりやすかった」「業務ではIoTなどに携わってないけれど興味があって参加した」「大規模会場では得られない、小さい会場だからこその発表者との距離感がよかった」など様々なお話をいただくことができました。

最後に

今回もほぼ満席の状態で開催させていただくことができました。
ご参加いただいたお客様からは「ぜひ次も参加したい」というアンケート結果を多くいただいております。

次回も来月を予定しておりますので、お客様のご期待に応えられるように次回もしっかりと企画していきたいと思います。
また、一緒にイベントを開催してくださる企業さまも募集します。
ぜひ、ご興味があるかたはこちらからご連絡お願いいたします。

それでは、次回もお楽しみに。
hayato

Amazon SageMakerのAPIを使った賢いWebアプリの作り方

こんにちは、BBです。

10月のLT会でも発表の際にAmazon SageMakerを使ったので、資源の有効活用という観点でブログにもまとめていきます。ややタイトル詐欺の感もありありですがお付き合いください。

Amazon SageMakerってなに??

Amazon SageMaker(以降はSageMaker)はAmazon Web Service(以降はAWS)が提供する機械学習サービスの中の一つです。SageMakerは2017年末に発表され、東京リージョンで公開されたのは2018年6月という比較的ナウいサービスです。SageMakerは機械学習のコーディング~デプロイまでを一括してカバーしている点を売りにしており、運用やバックエンドについてとやかく考えたくないAIエンジニアでもAWSの庇護のもと安心してサービスを展開できます。また、学習済みのモデルも用意されており、機械学習のことはあまり詳しくないエンジニアでも簡単に利用することができます。得意分野の垣根を越えて機械学習をより使いやすくするためのサービスともいえそうです。
amazon sagemaker
参照:https://aws.amazon.com/jp/

Amazon SageMakerの仕組み

御託は判ったけど、仕組みが分からないと取っ付き辛いと思いますのでここで、簡単にSageMakerの仕組みというかできることを説明していきます。SageMakerには大きく分けて以下3つの機能があります。

  1. コーディング
  2. トレーニング
  3. デプロイ

それぞれの機能に対して専用のインスタンスを作成しますのでSageMakerでは3種類のインスタンスを使い分けていることになります。ちなみにインスタンス?ってなった方はサーバーと読み替えてもらって大きな認識の違いはないと思います。

1. コーディング

コーディングの言語はPythonで、エディタは機械学習ではおなじみのJupyter Notebookを使います。AIエンジニアなら使い慣れている方が多いと思いますので、利用する際のハードルが低くて助かりますね。また、うれしいことにAnacondaをはじめ、機械学習や深層学習で利用するライブラリがすでにそろった状態で開発が始められるというのもお手軽でいいと思います。コーディングやちょっとしたデータの前処理に利用する程度であれば低スペックインスタンスを利用することで費用を抑えることができます。

2. トレーニング

深層学習のモデルをトレーニングする際は低スペックのPCではかなり時間がかかってしまい効率が悪いです。こんな時に一時的にでもハイスペックなPCが利用できたら……という願いを叶えたのがこちらのSageMakerです。GPU付きのハイスペックインスタンスを一時的に利用して効率よく学習を完了します。また、トレーニングの実行から完了にかかった時間のみ課金される仕組みになっており、トレーニング完了次第インスタンスは解放される為、消し忘れなど無駄に料金がかさむ心配がありません。

3. デプロイ

学習済みのモデルは専用インスタンスにデプロイしエンドポイントとして利用することができます。なんかカタカナが多くてよくわからない感じですが、要するに学習させたモデルにデータを突っ込んで、結果を返してもらうための専用サーバーを簡単に作れるよってことです。エンドポイントは動いている限り課金されてしまうので、用がないときは消しておくことを強くお勧めします。

Amazon SageMakerでWebアプリを作ってみる

さて、前段が長くなりましたが今回の本題に入ります。SageMakerを組み込んだWebアプリを作ってみたので手順をまとめていきます。Webアプリは手書き数字画像データの分類を行うものとします。教師データは機械学習の入門でもおなじみのMNISTを使って学習させています。
MNIST

こんなの作りました

作成したWebアプリの構成はこちらになっております。SageMakerで作成したエンドポイントを使用していますが、APIとして利用するためにAPI Gateway、AWS Lambdaを利用しています。Webサーバは動作検証のみなのでローカルに立てました。フレームワークはFlaskを利用しています。色々慣れないことが多くハードルを下げないと頭がパンクしてしまいますので使用した言語はPythonのみとなっております。
flask api lambda

エンドポイント周辺

エンドポイント周辺の構成を説明していきます。サーバレスという言葉にそこはかとない憧れを感じておりますのでAWS LambdaとAPI Gatewayを使った構成にしていきます。以下で説明しているのはとりあえず動けばよいかという動作検証前提の設定です。

機能
AWS Lambda SageMakerのエンドポイントを起動するトリガーの役割を果たします
API Gateway APIを提供します。リクエストに対してLambdaとの橋渡しをします

エンドポイント作成

では手始めにSageMakerでエンドポイントを作成してみましょう。SageMakerのダッシュボード画面に入り、ノートブックインスタンスを作成します。

学習用のソースを作成して実行していくのですが、MNISTの分類問題はすでにソースのサンプルがJupyter Notebook内に保存してありますので、サンプルをそのまま実行していけば何も感じることなくエンドポイントが出来上がってしまいます。ノートブックを開いてSageMaker Examplesタブを選択、SageMaker Python Sdkの中の「tensorflow_distributed_mnist.ipynb」の右にあるUseボタンを押下します。するとFilesタブにフォルダが追加されています。

フォルダ内の「tensorflow_distributed_mnist.ipynb」を開いてそのまま「Run All」するとエンドポイントを作成するまで一気に処理が進み、最後に作成したエンドポイントを削除してしまうので最後の

だけは事前にコメントアウトしておきましょう。実行完了したらエンドポイントが作成されているかどうかを確認して終了です。SageMakerの出番はこれでおしまいです……。

AWS Lambdaの設定

AWS Lambdaの役割はAPI Gatewayから受け取ったデータをSageMakerのエンドポイントに受け渡してやる事です。その為、作成するLambdaの「トリガー」にはAPI Gateway、「アクセスが許可されているリソース」にはAmazon SageMakerが最低限設定されている必要があります。「トリガー」はAPI Gatewayを作成するときに追加されますので、「アクセスが許可されているリソース」をIAMから編集してSageMakerの権限を追加しました。

画像の「test-lambda」部分を選択すると画面下部に関数コードエディタが表示されますのでPythonで以下の通りコードを入力します。

受け取ったデータをSageMakerに渡して分類結果を返却するだけの簡単なお仕事です。

API Gatewayの設定

API Gatewayでは設定されたURLにリクエストを送るとLambdaを起動するように設定します。API Gatewayで新規APIを作成しPOSTメソッドを追加します。

メソッドを追加すると統合ポイントの選択画面が表示されますので、統合タイプにLambda関数を選択してやり、作成したLambda関数名を入力すれば完了です。

API呼び出し用のURLはメソッドを追加した画面で「アクション」ボタンからAPIのデプロイを行うことで作成されます。

Webサーバー

次はWebサーバーですが、Python以外使いたくないので簡単だと噂のFlaskを使います。本題とそれるのでFlaskの説明はまた機会がある際にでも回して、APIとアクセスする為の関数の作り方を紹介します。APIへのアクセスを検証する場合はPostmanが非常に使いやすいです。Postmanの使い方はこちらを参考にしました。API Gatewayへのアクセスを検証したいので以下のような設定をしてリクエストを送ります。ここではAPIキーの設定はしていません。

  1. URLに先ほどAPI Gatewayで取得した参照用URLを入力
  2. URLの左にある選択ボタンからPOSTを選択
  3. URLの左にある選択ボタンからBody→rowを選択
  4. 表示された入力欄に送信するJsonを入力する


送信するJsonはLambdaで設定した通り’img’をキーに指定します。’img’の中身は784次元で0~1の値を持つベクトルです。MNISTの画像が28×28格子の白黒データである為、このような形の値を入力としています。ここでは数字の8にあたるデータを送信しているので結果は以下の通りになります。

Amazon Lambdaに設定した通りの結果が返却されていい感じです。この”body”に格納された”8″が分類の結果となりますので、入力に対してこの値をクライアントの画面に表示すればよいことになります。センスが全くない画面ですがこんな感じになりました。

画像を選択すると選択した画像を784次元のベクトルに変換してAPIに投げるようにしています。

まとめ

今回は簡単ではありますが、Amazon SageMakerを利用したWebアプリを作成しました。Webアプリの構築は初めてということもあり、UIもダサダサですが何とか思った通りの結果を出力することができました。Pythonのみ(ほぼ)を使ってアプリの作成ができたということがPythonをメインに使用している僕にとってはうれしい発見でした。SageMaker部分以外での躓きが多かったのですが、SageMaker自体の使い方は簡潔で取っ付きやすいと思います。あとはエンドポイントを連続稼働し続けても費用がかさまない仕組みがあれば遊びで使っても楽しそうだと思います。
今回は以上です!

識別モデルと生成モデル

はじめに

 分類問題に適用される機械学習の手法は、以下の3つに大別できる(下図参照)。

  1. 識別関数を用いるもの
  2. 識別モデルを用いるもの
  3. 生成モデルを用いるもの


識別関数は1つの点を推定するが、識別モデルと生成モデルは確率を推定する。各手法の代表的なアルゴリズムも上図に示した。

 今回の記事では、2分類問題を取り上げ、識別モデルと生成モデルの2つのアプローチでこれを解き、それぞれの手法の特長を解説する。

ソースコード

 今回のソースコードはここにあるsample.ipynbである。

識別モデル

 いま、観測データ\{X,Y\}が与えられているとする。ここで

(1)    \begin{eqnarray*} X&=&(x_1,\cdots,x_N), \;\;x_n \in \mathcal{R}^1\\ Y&=&(y_1,\cdots,y_N), \;\;\;y_n \in \{0,1\} \end{eqnarray*}

である。パラメータ\theta=(\alpha,\beta)を導入し、同時確率分布p(X,Y,\theta)を考える。ベイズの定理から次式を得る。

(2)    \begin{equation*} p(\theta|X,Y)=\frac{p(Y|X,\theta)p(\theta)}{p(Y|X)} \end{equation*}

最初に尤度p(Y|X,\theta)をBernoulli分布を用いてモデル化する。

(3)    \begin{eqnarray*} p(Y|X,\theta)&=&\prod_{n=1}^N p(y_n|x_n,\alpha,\beta) \\ p(y_n|x_n,\alpha,\beta) &=& {\rm Bern}(y_n|\nu_n) \\ &=& \nu_n^{y_n}(1-\nu_n)^{(1-y_n)} \\ \nu_n&=&f_s(z) \\ z&=&\alpha+\beta x_n \\ f_s(z)&=&\frac{1}{1+\exp{(-z)}} \end{eqnarray*}

次に事前分布p(\theta)をモデル化する。

(4)    \begin{eqnarray*} p(\theta)&=&p(\alpha)p(\beta) \\ p(\alpha)&=&\mathcal{N}(\alpha|0,\sigma^2_0) \\ p(\beta)&=&\mathcal{N}(\beta|0,\sigma^2_0) \end{eqnarray*}

ここで、\mathcal{N}(z|\mu,\sigma^2)は平均\mu、標準偏差\sigmaの正規分布を表す。先に与えた関数f_s(z)はシグモイド関数である(下図参照)。

この関数の値はy_nが1になる確率に相当するので、0と1を分離する境界線はf_s(z)=0.5となるzの値、z=0から求めることができる。すなわち

(5)    \begin{equation*} \alpha + \beta x_n=0 \end{equation*}

故に

(6)    \begin{equation*} x_n=-\frac{\alpha}{\beta}\equiv b_d \end{equation*}

が境界線となる。以上の準備のあと事後確率、p(\alpha|X,Y)p(\beta|X,Y)を求めることになる。\sigma_0はあらかじめ与える定数である。

 先に見た尤度p(Y|X,\theta)は、Xを与えて、それが属するクラスYを識別するモデルとなっている。これが識別モデルと呼ばれる所以である。

生成モデル

 同時確率分布p(X,Y,\theta)に戻る。この分布はベイズの定理より以下のように変形することもできる。

(7)    \begin{equation*} p(\theta|X,Y)=\frac{p(X|Y,\theta)p(\theta)}{p(X|Y)} \end{equation*}

最初に尤度p(X|Y,\theta)をモデル化する。

(8)    \begin{equation*} p(X|Y,\theta)=\prod_{n=1}^N p(x_n|y_n,\theta) \end{equation*}

ここで、y_nが0のときの分布と1のときの分布に分けて考える。

(9)    \begin{eqnarray*} p(x_n|y_n=0,\theta)&=&\mathcal{N}(x_n|\mu_0,\sigma_c^2) \\ p(x_n|y_n=1,\theta)&=&\mathcal{N}(x_n|\mu_1,\sigma_c^2) \end{eqnarray*}

どちらも正規分布とする。その標準偏差は共通の値とし、平均だけを異なるものとする。次に、事前分布p(\theta)をモデル化する。

(10)    \begin{eqnarray*} p(\theta)&=&p(\mu_i)p(\sigma_c),\;\;i=0,1 \\ p(\mu_i)&=&\mathcal{N}(\mu_i|0,\sigma^2_3) \\ p(\sigma_c)&=&\mathcal{N}(\sigma_c|0,\sigma^2_4),\;\;\sigma_c \geq 0  \end{eqnarray*}

\sigma_3,\sigma_4はあらかじめ与える定数である。2つのx_nの分布を正規分布とし、その標準偏差を同じものとしたので、2つの分布の境界線は次式で与えられる。

(11)    \begin{equation*} b_d=\frac{\mu_0+\mu_1}{2} \end{equation*}

以上の準備のあと事後確率、p(\mu_0|X,Y)p(\mu_1|X,Y)p(\sigma_c|X,Y)を求めることになる。

 ここでは尤度として2つのXの分布を考えた。すなわち、各クラスYに属するサンプルXを生成するモデルとなっている。これが生成モデルと呼ばれる所以である。

PyMC3による実装

 ここまでの計算を、データセット「iris」を用いてPyMC3により行う。このデータセットにはアヤメの3品種

  1. setosa
  2. versicolor
  3. virgnica

が50個ずつ集められており、4つの特徴量

  1. がく片の長さ:sepal length
  2. がく片の幅:sepal width
  3. 花びらの長さ:petal length
  4. 花びらの幅:petal width

の値が格納されている。データの先頭の様子は以下の通りである。

sepal_lengthについてのバイオリン図を次に示す。縦軸はsepal_lengthの値、横軸は3つの品種を表す。

バイオリン図とは、ヒストグラムを縦軸に沿って描画し、それを左右に展開したものである。今回は4つの特徴量の中のsepal lengthをx、setosaとversicolorの2品種をyとして用いる。

 最初に識別モデルを考える。コードは以下の通り。

  • 4行目:p(\alpha)を定義する。\sigma_0=10とした。
  • 5行目:p(\beta)を定義する。
  • 6行目:zを定義する。
  • 7行目:f_s(z)を定義する。
  • 8行目:b_dを定義する。
  • 9行目:尤度p(Y|X,\alpha,\beta)を定義する。
  • 10行目:MCMCを行う。

  • 収束具合を見るため、次のコードでGelman-Rubinテストを行う。

    計算される値は全て1.1未満となることを確認できる(結果は略)。1.1未満であれば収束したとみなして良い。次に、事後確率から算出される要約統計量を次のコードで計算する。

    出力は以下の通り。

    「mean」欄の「bd」の値5.42が、0と1を分ける境界線である。下図は、境界線の平均値とシグモイド関数の平均値を描画したものである。

    黒丸はsepal lengthの観測値(下側がsetosa)、濃い赤のラインが境界線b_dの平均値、薄い赤の領域がb_dの95%HPDである。また、濃い青のラインがシグモイド関数f_sの平均値、薄い青の領域がf_sの95%HPDである。ある量が95%HPDの領域内にあるとは、95%の確率でその領域内に存在することを意味する。HPDはHighest Posterior Density(最高事後密度)の略である。

     次に、生成モデルの場合を考える。コードは以下の通り。

  • 2行目:p(\mu_i)を定義する。\sigma_3=10とした。
  • 3行目:p(\sigma_c)を定義する。\sigma_4=5とした。
  • 4,5行目:2つの分布p(x_n|y_n=0,\theta)p(x_n|y_n=1,\theta)を定義する。
  • 6行目:b_dを定義する。
  • 7行目:MCMCを行う。

  • 先と同様に、Gelman-Rubinテストは合格する(詳細は略)。要約統計量は以下の通り。

    境界線の平均値は5.47程度になることが分かる。これは先に求めた識別モデルでの結果、5.42に近い値である。境界線の平均値と95%HPDを図示したものが下図である。

    識別モデルでの結果に比べ、95%HPDが少し狭くなっている。すなわち、生成モデルの方が確からしさの高い値になる。

    識別モデルと生成モデルの比較

     識別モデルと生成モデルの違いは、それぞれの尤度を比較すると明確になる。すなわち、前者の尤度はp(Y|X,\theta)であり、これはXが観測されたときクラスYが実現する確率を表している。識別を行うと言う目的に直接アプローチする手法である。一方、後者では、その尤度p(X|Y,\theta)を見ても分かる通り、識別に直接アプローチせず、Xの分布を最初に求めるている。この分布を通して未知パラメータの事後分布を求めることで本来の目的である識別を行っている。生成モデルの場合、Xの分布が得られるので、擬似データの生成や、外れ値検知などにも応用することができる。
     今回の例では、生成モデルの方が確度の高い境界線を得ることができた。その理由は、setosaとversicolorのサンプルが正規分布で良く近似できたためであると思われる。サンプルの分布が正規分布に従わない場合は、識別モデルの方が良いアプローチとなる。
     今回生成モデルで用いた境界線b_dはとても簡単な式(\mu_0+\mu_1)/2で表すことできた。その理由は、2つの正規分布の標準偏差を同じものとしたためである。サンプルの分布を正規分布とし、その標準偏差を等しくする解析手法を線形判別分析と呼ぶ。

    AnacondaのNumPyとpipによるNumPyの速度の違い

    こんにちは、エンジニアのtetsuです。

    Pythonで機械学習をおこなう人はAnacondaを使っている方も多いのではないのでしょうか。
    Anacondaを使えば、一発でNumPyやscikit-learn、Matplotlib、Pandasといった便利なライブラリを導入することができるので人気なのもうなずけます(一方で不便な面もありますが)。しかしながら、Anacondaを使うメリットはそれだけではありません。
    NumPyで呼び出される行列演算を実際に担うBLAS (Basic Linear Algebra Subprograms)というものには様々な実装法が存在しているのですが、その一つがIntel社が開発しているIntel MKL(Math Kernel Library)となります。実はAnacondaによってインストールされたNumPyから呼び出されるBLASはMKLになっていますが、pipでNumPyをインストールした場合には通常はOpenBLASというBLASが使われるため、ここで性能に差が出る可能性があるわけです。
    今回はこれらの速度の違いについてみていきます。

    BLASの確認

    速度比較に移る前に、使用しているNumPyの中ではどのBLASが呼ばれているかを確認しましょう。
    確認は簡単で、次の2行で済みます。

    MKLが使われているNumPyの場合には次のような出力になります。

    またOpenBLASが使われていれば次のようになるでしょう。

    MKLとOpenBLASの速度比較

    速度比較の準備

    今回は2つのBLASに対して次の計算の速度を測ってみます。

    1. 行列の要素同士の積
    2. 行列積
    3. 行列 + ベクトル(ブロードキャスト)
    4. 行列の特異値分解
    5. 行列の固有値分解
    6. 連立一次方程式の求解

    計算に使われる行列はすべて一様乱数によって生成された1000 \times 1000のサイズの実数の正方行列です。ベクトルについても同様に一様乱数によって生成された1000次元の実数のベクトルとしました。
    計算時間の計測にはipythonの%%timeitを使っています。
    NumPyのバージョンはそれぞれ1.15.1で計算機のCPUはIntel(R) Core(TM) i7-7700 CPU @ 3.60GHzであり、4コアが載っています。

    MKLとOpenBLASの速度比較の結果

    計測した計算時間の平均を次の図に示します。特異値分解と固有値分解は他の計算時間と桁が大きく違うのでグラフを分けています。
    semantic_label
    semantic_label

    結果をみると、行列の要素同士の積に関してはOpenBLASのほうが高速ですが、他に関してはすべてMKLのほうが速いです。特に特異値分解や固有値分解は大分速いですね!2倍近く速いのは驚きますね。
    行列のサイズやCPUのコアの数でも傾向が変わるかもしれませんが、その辺の話についてはfuture workということでお願いします。

    終わりに

    今回はAnacondaでNumPyをインストールしたときとpipでNumPyをインストールしたときでの差についてお話しました。
    従来の機械学習手法では特異値分解や固有値分解をおこなうケースも多々ありますのでスピードが気になったら、MKLを使うことを検討するのもいいかと思います。

    【C#】CSVファイル書き込み速度比較

    お久しぶりです、エンジニアのMasashiです。

    前回記事(【C#】ファイル書き込み速度比較)ではtxtファイルの書き込み速度について比較を行いましたが、今回はcsvファイルでは速度差がどうなるのか比較を行いたいと思います。

    ファイル形式で書き込み速度に変化が生じるというのは、今までソースコードを書いてきて感じたことはないため特に面白い結果にはならないと思いますが、確認してみたいと思います。
    今回もファイルの書き込みを行う関数の速度を4つの方法から検証してみたいと思います。

    測定までの流れ

    今回測定を行うのは、【0,1,2,3,4,5,6,7,8,9,】という文字列を500,000回、
    csv形式で書き込むまでに要した時間になります。
    比較対象としてStreamWriterをtry~finallyの形で記載したもの、StreamWriterをusingを使用して記載したもの、AppendAllTextを使用、WriteAllLinesを使用の4つの場合について検証しています。
    AppendAllTextについては、毎回ファイルのオープン・クローズが走ることで速度が
    どの程度遅くなってしまうのかを計測するために、Loop内で使用するという間違った使い方で計測しています。

    測定環境

    • CPU:Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 CPUs), ~2.9GHz
    • メモリ:16GB
    • Visual Studio 2015

    対象データ

    • 書き込む文字列:0,1,2,3,4,5,6,7,8,9,
    • 書き込む回数:500,000
    • ファイル形式:csv形式

    測定対象

    • StreamWriterをtry~finallyで記載
    • StreamWriterをusingを使用して記載
    • AppendAllTextを使用
    • WriteAllLinesを使用

    テストコード

    ファイル書き込み速度の測定結果

    10回試行した結果の平均値が下記になっています。小数点第1位で四捨五入しています。

    ここをタップして表示Close
    計測項目 計測時間(ms)
    StreamWriterをtry~finallyで記載 127
    StreamWriterをusingを使用して記載 120
    AppendAllTextを使用 測定不能
    WriteAllLinesを使用 164

    結果の比較の前にAppendAllTextを使用したパターンですが前回同様、毎回ファイルのオープン・クローズを行うため、結果の取得に非常に時間がかかり、計測することを諦めたため、計測不能という形で記載させていただきました。
    結果も前回同様非常に似通っており、StreamWriterを使用したパターンよりusingを使用したほうが若干ですが早くなっています。
    また、前回よりも全体的に速度が遅い状態で結果は出ていますが、純粋に「,」が文字として増えているため、その分の時間が計測結果の時間に現れたと考えられます。

    ファイル書き込み速度のまとめ

    結論につきましては、前回と同様になってしまいますが、再度載せさせていただきます。

    AppendAllTextを使用する場合は、データを加工してから使用することで、ファイルのオープン・クローズ処理を意識する必要がないため非常に便利です。
    StreamWriterを使用する場合は、非常に小さい値ですが速度差が生まれるため、usingを使用して実装するのがいいかと思います。
    またusingを使用することでClose処理を意識しなくてすむため、finallyでClose処理を入れることを忘れていたようなバグを防ぐことができます。
    WriteAllLinesを使用する場合は、改行を入れる処理を意識しなくていいため、取得したデータを改行して書き込んでほしいという要望がある場合は使用することになると思います。

    今回の計測によりファイルの違いでは、速度差を見つけることができませんでした。よってファイルの拡張子が異なっていたとしても状況に応じて使用する関数を変更して問題ないと考えられます。
    この記事が少しでも皆さんのお役に立てば幸いです。