作成者別アーカイブ: gorn

分析者目線のPowerShell活用シナリオ

PowerShellもバージョンを重ね、WindowsだけではなくLinuxでの稼働などいろいろな方向性が見えてきている。それらを踏まえて、インフラ側ではなく分析者として活用を過去の事例を踏まえて検討する。

私は、業務において分析者として、PowerShellを活用してきた。なぜならば、PowerShellは.NET Framework、そして、WindowsであればCOMコンポーネントを呼び出せるため、通常だと操作がしにくいものも操作できる可能性があるためである。

例えば、パスワード付きのExcelファイルなどは分析者泣かせである。ETLツールでの対応もほとんど見ないため、分析のワークロードの中にパスワード付きExcelが入ってくるとかなり面倒になる。しかし、コンプライアンス等々の観点から、パスワード付きExcelファイルなどを処理したいというニーズは存在するであろう。

さて、PowerShellをデータ分析で用いる場合、行志向のデータを行でイテレートして集計するなどの動きは容易に起こりえるが、この辺りがPowerShellでは厄介になるところである、たしかに、PowerShellにはforeach構文とForEach-Objectというイテレートが存在し、ForEach-ObjectにはIEnumerableなどを使って、行ごとのイテレートをこなせる可能性がある。

とはいえ、IEnumerableのようなインターフェイスを使いたいもっとも、大きな理由、行を逐次的に扱うことでデータの行数に対するスケーラビリティを確保するが実現できるかどうかはここのオブジェクトの実装にも左右される面が多く一筋縄ではいかない。なぜなら、データを途中でメモリに全量バッファリングしてないかどうかは個々のオブジェクトによるからである。

Hiveなどを使って並列分散の処理環境を構築すれば回答としては単純であるが、そもそも、環境の準備に要する時間や、パスワード付きのExcelファイルが紛れ込んでいたりすると一筋縄ではいかない。そして、ただでさえデータの前処理は必要であり、なおかつ時間も要する作業であり、できるだけライトウェイトな作業を心掛けたいところではある。

分析者として、有用なcmdletを一つ上げるとすれば Measure-Object である。このcmdletは数値の合計、最大値、最小値、平均を算出できるため、データの確認に有用である。もちろん、データサイズのスケーラビリティには注意する必要があるが。

現在であれば、MCMDをWindowsで稼働させるのも容易になってきているので、PowerShellに頼るべき局面も減少してきているとは思うが、COMの呼び出しなどほかのソリューションでは困難な状況も打開できるため、PowerShellを活用した前処理基盤の構築を現在、もくろんでいる。

PowerShellの分析シーンでの活用としては、以下の記事を参照した。

DP マッチングのコードを公開しました

DPマッチングのコードをF#で書いてBitbucket で公開しました。基本的な考え方はあちこちで触れられているアルゴリズムをそのまま実装しているので特徴と呼べるものはあまりないですね。まあ、半分、知識の確認がてら作ったようなものですから。

Neural Network Console

ソニーが先に公開した、Neural Network Consoleで遊んでいる。ごくごく当たり前のモデルであればありがちな設定というのはある程度確立しているものがありその設定でいいだろう。しかし、それだけであると少し変化球を投げられると破綻する。結果、mnist +alpha で悶々とする事態は発生する。

例えば、文字と一緒にだれが書いたかモデルに組み込もうとすれば、文字種を増やして対応するとか弥縫策と思う対応はいくつも思いつくが仕組みとして組み込もうとすればどこかでモデルの構造に挑まざるを得ないだろう。そういったときに、現行のTensor FlowやCognitive Toolkit との格闘は正しいだろうかということになる。現在は、Deep Learning≒Python とみられていることもあり、半ばPython技能が必須に近くなっているがそれがいつまでも正しいだろうか。

ビジネス側の知見と、技術者の橋渡しができる超人がどんな現場でもいるとは限らない。というか、いないほうが多いだろう。技術者側がビジネス側にきちんと歩み寄れればいいがいつでも、どこでもとはいかないだろうと思っている。

実務におけるモデリング

TJOさんがなにやら、ためになる記事を書いているので乗ってみます。Let’s throwing Masakari.

汎化性能についてはそのままだと思います。基本的には、正にその通りです。ここで付け加えることは多くはないです。とはいえ、とはいえ、汎化性能でもそうなのですが、問題はどこまで求めるかですね。つまり、どこまで性能の引き上げを頑張るかです。

例えば、それがセールスとかのモデルであれば最終的なモデルの出来不出来の目安は売り上げとなるでしょう。まあ、売り上げに至るまでの細かい情報が取れる場合にはその辺の情報も加味されるかと思います。

ただ、モデルが外れることがそのまま、損失につながるような状況だと厄介です。当然ながら、モデルの結果が出るのは将来の話です。まあ、そういう場合にはモデルのモニターを通じて何らかのモデルの精度を損なうような事象が観測された場合にはリモデルの提案をするしかないかもしれません。まあ、すんなりいくかどうかは別としてですが。

まあ、そう考えると不安な事象をどうするかってことですね。例えば、モデルを作った段階で、CVとかで検証してそれなりのアウトプットが出たとしてゲインチャートなどで確認して形状の差異など不安を感じるものが出たときにどうジャッジするかとかになるのかなと思います。

モデルの解釈性と予測性のプライオリティは厄介です。両方、お客さんは取りたくなるからです。この辺は色々と厄介でございます。

う、いろいろ、表に出さないで書いたら、まったくとりとめがなくなった。

パーセプトロンによる分岐予測

PC Watchの後藤氏によるアーティクル “AMDの次世代CPUコア「ZEN」のニューラルネットワーク分岐予測機能“。注意すべきはCPUの分岐予測関連は完全に秘密のベールに包まれており、AMDが先行しているかどうかはよくわからないということに尽きる。AMDにしても殆どの情報は非公開でありほとんど情報はない。

恐らく、単層のパーセプトロンだろうってことぐらいしか、恐らくほとんど情報はないのではないか。ただ、実用上はいわゆるオンライン学習になっているだろうとも考えられる。ただ、そうすると学習したモデルの揮発からの保護はどうなっているのかという問題も生じる。一旦、学習させ尽くしてしまってコールドスタート時からはファクトリープリセットのモデルに戻すというのならばこの問題は生じないが。

ただ、パーセプトロンでも通常、過学習の問題は生じるので、コールドスタート時はファクトリープリセットのモデルに戻すというのも悪い発想ではないとも考えられる。

 

AIの「よくある誤解」10個、ガートナーが見解

さて、クリスマスです。細かい話をするのもないので、この発表から。

ガートナーの発表した、AIのよくある誤解はすごくわかりやすいです。

  1. すごく賢いAIが既に存在する。
  2. IBM Watsonのようなものや機械学習、深層学習を導入すれば、誰でもすぐに「すごいこと」ができる。
  3. AIと呼ばれる単一のテクノロジが存在する。
  4. AIを導入するとすぐに効果が出る。
  5. 「教師なし学習」は教えなくてよいため「教師あり学習」よりも優れている。
  6. ディープ・ラーニングが最強である。
  7. アルゴリズムをコンピュータ言語のように選べる。
  8. 誰でもがすぐに使えるAIがある。
  9. AIとはソフトウェア技術である。
  10. 結局、AIは使い物にならないため意味がない。

1.と3.はものすごく関連があり、機械学習という単一の物があるわけではなく、機械学習というのは複数の技術を括る一つの目線に過ぎないのだと思います。従って、機械学習と称する技術は複数の学問分野にまたがっています。

当然ながら、深層学習は最強でもなんでもなく、適切な分野を選べば力を発揮するアルゴリズムの一つです。選択を誤れば深層学習で何も得ることはかないません。

まあ、ガートナーと契約しているわけでもないので、全文は未見ですが、9はソフトウェア技術と限定してしまうとひどいことになるでしょうね。確かに。

 

Visual Studio Code で Stan 拡張を作ってみようとする

今日はVisual Studio Code Advent Calendar 24日目のはずです。さて、Visual Studio Codeを使っていて、はたと困ったのはStanの機能拡張がなかったことです。ないのならば作ってしまえホトドギスで作ってみようとしました。まず、開発環境を用意しようとしました、それほど長時間使うわけでもないし困ったらサクサク作り直したいので、Microsoft AzureからA1v2を1インスタンス用立てて作ります。Linux環境を作らないのは手っ取り早くリモートデスクトップでつなぎたいからです。

とりあえず、必要なものを考えてみます。まず、StanのテストはR上で行うことにして、RStanをベースにします。RのVisual Studio Codeの機能拡張は既にあるし、まあ、Visual StudioのR拡張でとりあえずなんとかなるだろうと。そして、qiitaのVisual Studio Code はじめての拡張機能開発を参考にして、以下の物を。

  • Windows Server 2016
  • Visual Studio 2017RC
  • Microsoft R Open
  • Visual Studio Code
  • node.js
  • git

さしあたり、コードのレポジトリをgithubに作って作業開始。

と思っていたら、以下の記述がLanguage Extension Guidelinesに。

Syntax highlighting, snippets, and smart bracket matching can be implemented declaratively with configuration files and don’t require writing any extension code.

どうやら、コードを書かずに目的を達成できそうである。今回は拡張機能を作るのが目的ではなく、あくまでStanのためのよりよい環境がほしいだけなので、楽ができるのは歓迎である。

さて、先ほどから語っているStanについて、少々触れておく。Stanはベイズ統計モデリングをするための一種のドメイン特化言語である。Rなどとことなり、ベイズ統計モデリングのためにあるので汎用の言語ではない。R用のStanパッケージであるRStanやPython用のPyStanと用いられることが多い。言語自体は最終的にCのコードになりコンパイルされる。

とりあえず、yeomanで雛形を出力させると、必要なファイルが入っているようなので無駄にはならなかった感じですね。あとは、ちまちまと予約語とかを整備していけばある程度使える形にできるのかな?

と、思ったら、Ivan Bocharov氏のstan-vscodeが。脱力感、漲る。

地味に便利なAzure DevTest Labs由来の自動シャットダウン

先日のMicrosoft Azureの機能拡張でDevTest Labs由来の自動シャットダウン機能が仮想マシンにつきました。この機能のリリース前はAzureの機能の一つであるAzure Automationを使って自動シャットダウンを実施する必要がありました。特に単価の高い、Hadoopなどのクラスターなどは確実にシャットダウンしないと金銭的に破滅しますので重要です。

この機能の設定はとても簡単です、管理支援機能であるAzure Automationの設定と比較しても簡単です。勿論、できることは限定されますが、自動シャットダウンというものを実現するには十分です。

インターフェイス上は仮想マシンのスケジュールのところにあります。

Screen shot of Azure Portal