vs deus.com

The pen is mightier than the sword.

水中ポンプ向け人工知能を作ってみた

人工知能の機械学習の入門的な手法、線形回帰分析を使用して、
以前、作ったサイト水中ポンプのサイトで販売してる商品データの重回帰分析をやってみた。
何故、水中ポンプにしたのかと言うと、見てると人工知能を学ぶ人達が扱うデータはそもそも用意されてるデータが多くて、
それだと実際に応用してみると実は難しい点が見えにくくなる点と、
勉強のための勉強で終わると全く意味がないので、実際使用されているデータにした。
実際に利用してるデータなら水中ポンプでなくても良かったが、
類似した商品が一定数以上あるカテゴリは無かったので消去法で決めた。
因みにデータを入れれば全て解析してくれる様に作ったので、
正の相関のあるデータなら入れるだけで同じようにcvs等のデータから線形回帰のグラフを出せる。

以下は実際に売っている商品の線形回帰の分析結果になる。

sample graph

1).A軸をポンプの出力(kw)、B軸を値段(円)
赤い点がそれぞれの商品、緑の点がA)出力から導き出されるB)値段の線形回帰。

sample graph

2).A軸をポンプの出力(kw)、B軸を値段(円)、Y軸を吐出口(cm)
青い点がそれぞれの商品、
赤の点がA)出力とB)値段から導き出されるY)吐出口の線形回帰。

sample graph

3).A軸をポンプの出力(kw)、B軸を値段(円)、C軸を吐出口(cm)
青い点がそれぞれの商品、
赤の点がA)出力とC)吐出口から導き出されるB)値段の線形回帰。

sample graph

4).2)と3)を合わせたグラフ。

sample graph

5).4)から各商品の青い点を消したグラフ。
つまり、この赤の平面と緑の平面が交差する線が全てから近い直線になる。

水中ポンプの線形回帰をしてみた感想

まず、上のグラフを見てもらえば分かるとは思うが、
実際にこのグラフをお客さんに見せて説明しようとすると、
次元は少ない方が理解してもらいやすくなる。

プログラマーなどに説明するなら3次元のモデルでも良いかもしれないけど、
商用で3次元モデルを持ち出して説明するなら、2次元の方が圧倒的に分かりやすい。
論文とサービスは違うので、いくら優れていても人の脳処理の機能に合わせて作らないと、
普通の人には分かりにくくて、サービスとしては弱くなるだろう。

勿論、重回帰分析を行って得たアルゴリズムをバックグラウンドで動かしてサジェストするみたいなサービスであれば、
高次元でも良い結果が出るのならそちらがベターだと思う。

線形回帰についての感想

線形回帰についていうと、モデル式を作り、コスト関数を作り、 最急降下法をするのだが、
数式を紐解いて考えていく内に、実際にはコスト関数と最急降下法、
このある種完成された2つの別々の手法を組み合わせてるように感じた。

コスト関数に関しては、考えれば同じような式は思いつきそうに思うし、
場合によっては、Σ(y'-y)2乗の数式を少し工夫しないといけない状況もあるので
万能性や普遍性で弱いように見える。

一方、最急降下法の偏微分したものを削っていって最終的には、
グラフの極限の平らの部分に近づくと言う手法は、
かなり芸術性が高く美しく、これを最初に考えた人は凄いと思った。

最急降下法は最初からニュートン法に似てると思っていて、
ニュートン法を弄ってみたら、ニュートン法は最急降下法の亜種であると言えるような式になって面白かった。
数学は英語などとは違い、いくら細かくして言ってもそれを構成する要素には矛盾が存在しないのが面白い。

そう言う点は、プログラミングも同じではある。
どこまでも細かくしても客観的に論理的に説明ができるので、抽象的な思考をして答えを出す際には言語の何倍も有用になる。

最急降下法をニュートン法と比較して考えてみると学習率が大体どういう性質で、
どのような値になるのかが見えてくると思う。
そういう部分に自力で辿り着く事が凄く重要で、わざわざ出来合いのライブラリを使わずに一から構築する最大の意味であると思う。
(今回もライブラリはほぼ使わなかった。線形代数に必要なnumpy、グラフ描写に必要なmatplotlib、Axes3Dのみ。)

ライブラリ、フレームワークを多用すると本質的な構造、機構が見えなくなり、プログラミングの記述能力も著しく下がる。
(肥大化したフレームワークが最も見えにくくするので、フレームワークには特に注意した方がいいと思う。)

構造を学ぶ最大の目的、メリットはサービスを作る上でのアキレス腱はどこであり、
どこがビジネスモデルに繋がる部分であるのかというのを俯瞰して思考出来るようになる点。

例えば、ライブラリやAPIで作られた部分が100で自分で書いた部分が1としてもその1の部分をどこに持っていけば、
競争有利性が働くのか?ミートされにくいサービスになるのか?
そこら辺の見通しを立てれるようになる。

格闘技で体格差が何倍もあっても関節技を決めれば相手を倒せるように、
競争相手が何倍も体力があったとしても、構造を知っている方が基本的には勝てるような場合が多い。
つまり、"普通の奴らの上を行く"事が出来なければ戦場では生き残れないのだ。

今回の線形回帰を行って算出されたモデル式使えるかどうかという点については、
今回のグラフに関して言えば改良しないといけないと思う。
かなり強い正の相関が無いと一発でこれで完璧という訳にはなら無いケースが多い。
データを弄って調整するのか、アルゴリズムを弄って調整するのかどちらか一方を選べと言われたらデータを選ぶと思う。

人工知能を学ぶのにかかる時間

人工知能ブームのお陰で、学習効率が凄く上がって、
学ぶためにかかるコストよりもリターンが大きくなり、
商用的にも利用できるフェーズに突入したなと感じている。
実際、ゼロから始めてクラウドサーバーで重回帰分析を行い理解するまでに、
どのくらいの時間がかかるのか経験を元に記しておこうと思う。

まずは、機械学習をさせる上で必要な科目や知識は、
A).高校までの数学、
B).プログラミング、
C).サーバー構築。

Cのクラウドサーバーは作れなくてもローカルの環境で動かせればいいので、
3つ目は最初は無くても問題ない。
(データの量が多くなるとローカルでは無理になる。目安は1万行くらい。10万行になると完全にローカルではやらない方がいいと思う)

Aの高校までの数学に関しては、人によっては高校数学の、線形代数と微分積分、統計までが出来れば良いと言うだろう。
実際はそれでも出来るんだけど、一通り分からないと数理モデルの中で完全には理解できない部分が出てきて、
良く分からないけどこうなるみたいな数学的ではない部分が残る。
なので、一応全部出来ないと理解が浅く応用が利かなくなる。
実際には線形回帰のグラフは出したんだけど、似た商品を出す時にやる微調整などをどうすれば良いのか分からくなる可能性が高い。
もっとも、理解が浅いとその疑問すら持つことなく通り過ぎてしまうケースが大半かもしれない。

B、プログラミングに関してはpythonでやってみるなら、pythonは簡単な部類の言語だと思うから、比較的直ぐに習得できると思う。
(ただ、全くプログラミング自体をやった事が無い人だと3か月~半年くらいは見たほうがいいかもしれない。
別の言語を何年も使っていたなら、特に学ぶための時間すら必要なく、やっていく内に出来るようになると思う。)

この3つの中で、Cのサーバー構築に関しては他と比べて異質で、概念や論理を学ぶというより、記憶力の部分が大きい。
クラウドサーバーになって顕著になってきてるが、やはりPaaS型の部分が増えてきてて、
学んだからと言って賞味期限が長いのかと言われると微妙なところ。

実際スナップチャットではGAEで動かしてるらしいし、誰がやっても1つの解に収束しやすい様な分野である。
それと、記憶力がメインになると、個人的には演繹的に考える力が弱くなると思うので今までもこれからも、それ程重点を置かないと思う。
(このサイトもGCP上で動いてる訳だが、GCPクラウドサーバーの構築を行う際、独自のルールや調べても殆ど書いてない事、
初見ではほぼ嵌る初見キラーなポイントが多数あって時間がかかった。)

かかった時間は仕事をやりながらで、pythonが数日、
あとは高校までの数学、GCPサーバー構築それぞれ一か月くらい、合計3か月くらいかかった。

とりあえずは人工知能の機械学習、深層学習の基本的な技法は一通り理解して実装できるようになって、
それを応用する新しいサービスを作る予定なのでもう少しかかる。(恐らくあと数か月)

その過程で出来た今回のような副産物は時間がある時に、運営してるサイトに実装して行く。

開発者がサービスを考える際に気を付ける事

プロダクトアウトとマーケットインと言う真逆の考え方がある。
個人的な経験では今まで数十個はサービスを作ったけれど、
プロダクトアウトはマーケットインの10分の1くらいしかエイム率が無かった。
実際、色々な所で言われてるようにサービスを作るならマーケットインでなければ、
当たる確率が凄く悪くなるというのが正しい答えだと思う。

人工知能系のサービスを開発者が考えて作る場合、サーバー構築、アルゴリズムの実装など、
どうしてもプロダクトアウト寄りの思考になってしまう。
やっている事がプロダクトアウト的な思考でなければ出来ないので必然だと思う。

ここ数か月、数学、サーバー構築、機械学習的なことばかりやっていたのでマーケットインに思考を戻さないといけない。
(大体作る時は、マーケットインとプロダクトアウトの比重を8対2くらいにして、
プロダクトアウトの更に一部にコアとなる部分を入れて行くイメージで考えてる)

アイデアの質は基本的にはどれだけの量のアイデアを知っているかで決まるので、
毎日1つ以上はアイデアを出して、実際に付加価値を世の中に提示出来て、
収益にも繋がるサービスを考えて行くようにする。

シンセサイザーが全ての楽器の音色を出せる様に、
既に人工知能を使いこなせるソフトウェアエンジニアは全ての産業の上位互換になりつつある。


人気の過去の記事

DjangoとFlaskをどちらも使ってみた感想

GCP(google cloud platform)構築について


GCP + Django or Flask 応用操作

デバッグルームは負荷を考慮して読み込み以外のリンクは全部消去。自分で辿りついてね☆彡

https://c.vsdeus.com(ストレージ用)

カメラ操作&js-python連携 非同期通信

MTV(CSRF対策済)抽出&自動翻訳

MTVテスト(継承、繰り返し、条件分岐)

画像から文字を抽出&自動翻訳

PUMP商品データの重回帰分析


GCP + Django or Flask 基本操作

CSVをDATASTOREに整形後、書き込み

PUMP CSVをDBに書き込み

htmlを呼び出し

htmlを書き込みup

htmlを呼び出し&書き込みup

DBに書き込み

DBから呼び出し

matplotlib作成画像をストレージに保存

TOPに戻る / Return to TOP

AKI.BBA01