APIのテキスト分析をPowerShellから叩くコメントをどうぞPowerShellからWatsonのテキスト分析を叩いてみた。Servicesのネガポジ分析をたたいてみました。2018で.NET環境に機械学習を実装するML.NETが発表されました。今までですと、Accord.NET、KelpNet、Megalopolisなどいくつかの機械学習を可能にするライブラリがコミュニティベースで実装されてきたわけですが標準といえるものはありませんでした。ML.NETはフレームワークとして作られ、まさにその標準を担うものといえます。ML.NETは機械学習の実装だけでなく、フレームワークを提供するのが肝といえます。Coreで実装されているため、プラットフォームを選ばずに実行できます。データを放り込んで触っているところです。Extensionがモデルに関してはかなりのものを実装してくれると期待しています。APIのモデルをエクスポートできる拡張が入るようです。Blogの記事では以下のようになっています。ONNXでエクスポートできるようです。gorn分析者目線のPowerShell活用シナリオコメントをどうぞPowerShellもバージョンを重ね、WindowsだけではなくLinuxでの稼働などいろいろな方向性が見えてきている。それらを踏まえて、インフラ側ではなく分析者として活用を過去の事例を踏まえて検討する。私は、業務において分析者として、PowerShellを活用してきた。Framework、そして、WindowsであればCOMコンポーネントを呼び出せるため、通常だと操作がしにくいものも操作できる可能性があるためである。パスワード付きのExcelファイルなどは分析者泣かせである。ETLツールでの対応もほとんど見ないため、分析のワークロードの中にパスワード付きExcelが入ってくるとかなり面倒になる。コンプライアンス等々の観点から、パスワード付きExcelファイルなどを処理したいというニーズは存在するであろう。PowerShellをデータ分析で用いる場合、行志向のデータを行でイテレートして集計するなどの動きは容易に起こりえるが、この辺りがPowerShellでは厄介になるところである、たしかに、PowerShellにはforeach構文とForEach-Objectというイテレートが存在し、ForEach-ObjectにはIEnumerableなどを使って、行ごとのイテレートをこなせる可能性がある。いえ、IEnumerableのようなインターフェイスを使いたいもっとも、大きな理由、行を逐次的に扱うことでデータの行数に対するスケーラビリティを確保するが実現できるかどうかはここのオブジェクトの実装にも左右される面が多く一筋縄ではいかない。データを途中でメモリに全量バッファリングしてないかどうかは個々のオブジェクトによるからである。Hiveなどを使って並列分散の処理環境を構築すれば回答としては単純であるが、そもそも、環境の準備に要する時間や、パスワード付きのExcelファイルが紛れ込んでいたりすると一筋縄ではいかない。ただでさえデータの前処理は必要であり、なおかつ時間も要する作業であり、できるだけライトウェイトな作業を心掛けたいところではある。算出できるため、データの確認に有用である。データサイズのスケーラビリティには注意する必要があるが。現在であれば、MCMDをWindowsで稼働させるのも容易になってきているので、PowerShellに頼るべき局面も減少してきているとは思うが、COMの呼び出しなどほかのソリューションでは困難な状況も打開できるため、PowerShellを活用した前処理基盤の構築を現在、もくろんでいる。PowerShellの分析シーンでの活用としては、以下の記事を参照した。基本的な考え方はあちこちで触れられているアルゴリズムをそのまま実装しているので特徴と呼べるものはあまりないですね。半分、知識の確認がてら作ったようなものですから。Consoleで遊んでいる。当たり前のモデルであればありがちな設定というのはある程度確立しているものがありその設定でいいだろう。それだけであると少し変化球を投げられると破綻する。悶々とする事態は発生する。文字と一緒にだれが書いたかモデルに組み込もうとすれば、文字種を増やして対応するとか弥縫策と思う対応はいくつも思いつくが仕組みとして組み込もうとすればどこかでモデルの構造に挑まざるを得ないだろう。格闘は正しいだろうかということになる。みられていることもあり、半ばPython技能が必須に近くなっているがそれがいつまでも正しいだろうか。ビジネス側の知見と、技術者の橋渡しができる超人がどんな現場でもいるとは限らない。いうか、いないほうが多いだろう。技術者側がビジネス側にきちんと歩み寄れればいいがいつでも、どこでもとはいかないだろうと思っている。設定および積み残し設定の解決コメントをどうぞいろいろと設定の未解決部分を解決した。CloudflareとWordpressの相互作用あたり。gorn実務におけるモデリングコメントをどうぞTJOさんがなにやら、ためになる記事を書いているので乗ってみます。Masakari.汎化性能についてはそのままだと思います。基本的には、正にその通りです。ここで付け加えることは多くはないです。いえ、とはいえ、汎化性能でもそうなのですが、問題はどこまで求めるかですね。どこまで性能の引き上げを頑張るかです。それがセールスとかのモデルであれば最終的なモデルの出来不出来の目安は売り上げとなるでしょう。売り上げに至るまでの細かい情報が取れる場合にはその辺の情報も加味されるかと思います。モデルが外れることがそのまま、損失につながるような状況だと厄介です。当然ながら、モデルの結果が出るのは将来の話です。いう場合にはモデルのモニターを通じて何らかのモデルの精度を損なうような事象が観測された場合にはリモデルの提案をするしかないかもしれません。いくかどうかは別としてですが。考えると不安な事象をどうするかってことですね。モデルを作った段階で、CVとかで検証してそれなりのアウトプットが出たとしてゲインチャートなどで確認して形状の差異など不安を感じるものが出たときにどうジャッジするかとかになるのかなと思います。モデルの解釈性と予測性のプライオリティは厄介です。両方、お客さんは取りたくなるからです。この辺は色々と厄介でございます。う、いろいろ、表に出さないで書いたら、まったくとりとめがなくなった。すべきはCPUの分岐予測関連は完全に秘密のベールに包まれており、AMDが先行しているかどうかはよくわからないということに尽きる。AMDにしても殆どの情報は非公開でありほとんど情報はない。単層のパーセプトロンだろうってことぐらいしか、恐らくほとんど情報はないのではないか。実用上はいわゆるオンライン学習になっているだろうとも考えられる。すると学習したモデルの揮発からの保護はどうなっているのかという問題も生じる。学習させ尽くしてしまってコールドスタート時からはファクトリープリセットのモデルに戻すというのならばこの問題は生じないが。パーセプトロンでも通常、過学習の問題は生じるので、コールドスタート時はファクトリープリセットのモデルに戻すというのも悪い発想ではないとも考えられる。過去の投稿Caution本ブログは現在、某社でデータサイエンティストをしているG.O.R.Nの提供でお届けします。本ブログは個人の見解であり、所属組織とはまーったく関係がございません。内容は無保証であり、この結果に基づいて事業を進めた結果、倒産しようがなんだろうが一切保証しませんし、健康上の被害を訴えられましてもなんら保障いたしません。