Azure Machine Learningが凄くて震える
この記事は「MoneyForward Advent Calendar 2015」の24日目の記事です。
概要
MicrosoftのAzure Machine Learningに甚く感動したので、そんな思いを書こうと思います。ということをqiitaに投稿しようと思ったら完璧に被ってたので、始めたばかりのハテブに移動 orz
使ってみたきっかけ
Andrew Ng教授のMachine Learningやワシントン州立大学のMachine Learningなどを基礎的なインプットをしてきたので、そろそろ業務にアウトプットしたいな〜と思ってた時に、Azure Machine Learningのセミナー案内が来たのがキッカケです。
Azure Machine Learning Sugeeeee
受講して衝撃を受けました。私が機械学習newbieだからなのかもしれませんが、一瞬、今まで自分が勉強してきたことの意義を疑いかけるほどには、インパクトがありました。以下、Sugeeeと思った点です。
- 簡単 & わかりやすい
- カスタマイズもできそう
- 学習済みモデルをWebAPI化して使える
- Azure Maket Placeで販売もできる
簡単 & わかりやすい
簡単なモデルの生成がGUIベースで作成できます。試しにモデルを評価できるようにしてみましょう。
ご覧の通り、メニューからドラッグ & ドロップでGUIブロックを持ってきて、接続するだけでOkです。又、データをベクトル化して...などもGUIブロックがよしなにやってくれるため、数学初心者も安心して使えます。行列のサイズ間違えなどあまり起きず、安心して使えます。
又、機械学習における各ステップがメニュー内容で上手く分類されているため、全体的なフローをイメージしやすいというのも特徴の一つだと思います。
さらに言うと、各ステップにおける入力値・出力値を確認しやすいので、もし想定外の結果が出力された時のデバッグも楽にできるのではないでしょうか。例として、先ほど追加した評価ブロックの出力をみてみましょう。
この様に出力ノードをクリックし"visualize"を押すだけで、グラフィカルな結果を表示してくれます。単にAccuracyだけでなく、Precision, Recall, Tru Positive数などの数字も表示してくれるので、気配りが効いてますね。
カスタマイズもできそう
簡単なモデルを作るだけなら用意されているブロックを利用すれば事足りると思います。ただ高度なことをしたい時にも対応できる柔軟性もありそうです。メニューをご覧いただければわかりますが、Python/Rのスクリプトを走らせるブロックも準備されているためです。
学習済みモデルをWebAPI化して使える
Azure Machine Learningは学習済みモデルをWebAPI化して使える。後、自分の作ったAzure Machine Learning自体も公開できるようですね。 * ここまでならGoogle Predictions APIもAmazon Machine Learningもできるみたいですが。
販売もできる!
個人的に一番すごいな、と思った部分です。どうやらAzure Market PlaceでAPI化したモデルを販売することも出来る様です。夢が広がりますね。
価格
- Freeプランがあります。制限期間はなさそう。
- Standardプランでは、基本従量課金です。
- 円払い可能ですが、四半期ごとに為替レートで調整される
- MLシートとは???
| 内容 | 料金 |
|---|---|
| ML シート サブスクリプション | ¥1,018.98/シート/月 |
| ML Studio 使用 | ¥102/スタジオ実験時間 |
| ML API 使用 | ¥204/実稼働 API Compute 時間 |
| トランザクション | ¥51/1,000 実稼働 API トランザクション |
まとめ
以上、機械学習がとても楽になるPaaSサービス「Azure Machine Learning」の紹介でした。勿論これらを独自ビジネスに適用して、精度の高いモデルを作るには、機械学習の仕組みを深く理解していないと思います。ただ、機械学習を初めて業務に使ってみたい、とか、スモールに初めてみたい、といった場合にはパワフルで心強いサービスになると思います。
Activ◯ Direct◯ryなどで辛酸を舐めさせられた記憶から、Microsoftに対して余り良い思い出を持っていませんでした。が、Azure Machine Learinigを使ったら、そんな気持ちは吹き飛びました。本当に(m´・ω・｀)m ｺﾞﾒﾝでした
明日Concurrencyについてm9(^Д^)ﾌﾟｷﾞｬｰられないための基礎知識
本記事はGo その2 Advent Calendar 2015の23日目の記事です。
Go言語どころかナンチャってプログラマーである私が、"Goの強みの一つにConcurrencyがあるんだぜ"とドヤ顔で友人に話した所、十分に理解しておらずm9(^Д^)ﾌﾟｷﾞｬｰられてしまいました。そんな被害者を増やさないために、調査したことを書きます。
目的
Go言語におけるConcurrencyについて概要を理解する。
Concurrencyとは
なんなんでしょう。まずは日本語訳をググってみましょう。
concurrency: 同時並行性
なるほど。最初、私はconcurrency = 並列性だと考えていましたが、いきなり間違えてました。よく考えれば並列だったらparallelismになります。これはm9(^Д^)ﾌﾟｷﾞｬｰられるのも納得です。 次にParallelismもあわせて、その定義を探っていきましょう。
Concurrency vs Parallelism
The Go Blogにおいて下記のような記述がありました。
- concurrency is...
- about dealing with lots of things at once
- parallelism is...
- about doing lots of things at once
なるほど。わからん。もっと読みこんでみました
- Concurrency: Programming as the composition of independently executing processes
- 個々に実行されるプロセスの構成物
- ここでのプロセス≠Linuxプロセス である模様
- Parallelism: Programming as the simultaneous execution of computations
- 処理の同時実行
どうやら、Concurrencyは構成(structure)でありParallelismは実行(execution)である模様。 もっと細かく言うと、Concurrencyは何かしらの問題を解決するために枠組みとして、問題を一つ一つ個々に実行可能なタスクに落とし込める(プログラムの)構成手法のことです。一方、Parallelismはその枠組みを使った問題の解決手法の一つである模様。本当かいな、と思いましたが、少なくともGoでの思想はそうなっているようですね。
Concurrencyの例
言葉は不要か。図示してみましょう。 * 以下は全て、Concurrency is not Parallelismの画像です
Gopherちゃん初めての焚書
一匹のGopherちゃんが積ん読された大量のマニュアルを焼却炉に破棄しようとしています。これにおける問題は「積読マニュアルを焼却する」といったことにあります。またこの問題を「実行」するのがGopherちゃんです。これをConcurrencyな構成(Concurrency Composition)にしてみましょう
Concurrencyな構成パターンA
この問題において「一部の積読マニュアルを拾って、運搬し、焼却炉で燃やす」といった単位でタスクを捉えるならば、もう一匹別のGopherちゃんと焼却炉を準備すれば、問題解決に向けた構成(concurrent composition)が設計できます。
このパターンでは、同じタスクを実行させる、というParallelismになっています。ただし、上記の構成ですと片方のGopherちゃんがサボったり、積読本の中のジャンプを読み始めたりする可能性もあります。つまり２匹のGopherちゃんが「同時実行しない」可能性があるということなので、何かしらの問題でParallelismではなくなることもあります（Conccurentではあり続ける)
Concurrencyな構成パターンB
下記の図がConcurrencyな構成その２です。タスクを「積読マニュアルをカートに入れる」「運ぶ」「燃やす」といった単位で切り出し、それぞれのタスクをGopherちゃんが実行しています。ここでは、何かしらのトラブルがなければ、Gopherちゃん達は各々のタスクを同時実行しているのでParallelismが実現しているといえます。
Concurrencyな構成パターンC
下記の図はパターンBの発展形です。「運ぶ」タスクを細分化しており、「本が入ったカートを運ぶ」タスクと「空になったか−とを運ぶ」タスク及び実行担当のGopherちゃんが追加されています。
Concurrencyな構成パターンD
今度はタスクを「積読本を中継地点まで運ぶ」タスクと「中継地点から焼却炉まで運んで燃やす」タスクにわけてみましょう。切り分け単位が焼却するまでの動作ではなく、積読マニュアルをどこまで運ぶかの距離となっています。
Concurrencyな構成パターンE
これはパターンAとパターンDの合わせ技です。片方の焼却炉が死んでも、もう片方の焚書ミッションは継続できるので、そちらでのParallelismは維持されます。
Concurrencyな構成パターンF
パターンA~パターンEをがっちゃんこしたやつ。Gopherちゃんが沢山いて、可愛くてつらい。
現実に置き換えると
まとめ
以上のことから、Concurrencyとは何かしらの問題に対するアプローチの仕方であり、設計であるとの模様です。そしてその設計の仕方により、Parallelismを実装するかどうか、そしてどう実装するかが、変化する、ということを理解しました。少なくともGo言語においては、その整理でよいのではないでしょうか。
おまけ: 色々なConcurrency vs Paralellism
