読者です 読者をやめる 読者になる 読者になる

統計・機械学習OverView

OverView 統計学機械学習 与えられた「Data」から人がわかる最もらしい答え[命題]を見つける ↔ 与えられた「Data」から、”次の個体”の性質を予測する

記述統計

keywords

  • 中間値
  • 平均値
  • 最頻値
  • 4分位点
  • 分散

分散

σ2 = {Σ(Xi-μ)2}/n [μ: データの平均値 Xi: 各データ]

標準偏差

σ = ({Σ(Xi-μ)2}/n) ^ 1/2 [μ: データの平均値 Xi: 各データ]

記述統計 → すべてのDataが観測できている場合

推測統計

一部のDataに対する分析から全体を推測する

P値 → P値をデータ分析者が決め、それに従って信頼区間などが決まる。

ex. 標本平均が50, 元の集団が正規分布 P値が 5 → 45~50 母集団平均 P値が 0.01 → 40~60 母集団平均 とか。

P値を下げると、その分「正確な値を取ろうとする」ため、分析の結果出てくる信頼区間が大きくなる(不確かな幅を大きくせざるをえない)

ノンパラメトリック手法の方が、頑健である(どんな分布にも対応できる)が、検出力が低い(peakyに反応しない) → みたいデータの特徴に反応し辛い → 前提(正規分布)を落としているため

統計学における「誤り」

第一種過誤 または偽陽性 -> 帰無仮説が実際には真であるのに棄却してしまう過誤 第二種過誤 または偽陰性 -> 対立仮説が実際には真であるのに帰無仮説を採用してしまう過誤

Keywords

  • ベイズ統計 → 古典統計 + α
    • 頻度主義では不確かさの定量化はランダム性のみに基づくのに対し、ベイズ主義では情報が不足していることにも基づくとし、不確かさの定量化を広く考える。
    • 事前分布
  • 分布

  • 検定

    • 母集団に対して, 要素xが有意に異なる、ということ
    • 帰無仮説 ↔ 対立仮説
  • 回帰分析
    • 5つぐらい統計的仮説がある
    • 多重線形性
    • 単回帰、重回帰
  • 変数の尺度、質
  • 時系列データ ARMA, ARIMA

データサイエンティストの極意

  1. 分析力
    1. モデルを理解し、データセットと仮説があればoutputできるか
  2. システム力
    1. データセットの収集、継続的な運用のためのシステム要件定義ができるか
      1. オンライン学習: Spark
      2. バッチ学習 : Hadoop
  3. 戦略立案力
    1. 必要なDataの判断、仮説立案力、それをビジネスにどうフィードバックさせるか

機械学習

  • 教師あり学習
  • 教師なし学習
  • 強化学習

  • 教師あり学習

-> 「被説明変数」的答えありきでStartする

よく使われるジャンル

分類回帰, Ranking

カーネル関数 soft-margin hard-margin

Neural Network

入力層 隠れ層 hidden parameter 出力層 Back

  • 教師なし学習
  • 強化学習
  • Back Propagation
  • 学習立
  • parameter最適か
  • 損失関数
  • 抽象化
  • 次元削減

Random Forest

アンサンブル学習 -> 学習器をたくさん作って木をたくさん作る

  • ROC曲線
  • NLP
  • 次元の呪い(説明変数を多くするほど汎化性能が低下する、計算量が多くなる)を脱却できる

ROC曲線

判別木の性能評価

  • 適合率 Precision
  • 再現率 Recall
  • 正解率 Accuracy
  • AUC

true-positive false-positive false-negative true-negative のマトリクスで見る Area Under Curve http://qiita.com/kenmatsu4/items/550b38f4fa31e9af6f4f

教師なし学習

Un Supervised Learning

  • 教師あり学習の最適化 → 損失関数を最小化している、と考えられる「間違って分類するcaseをなるべく減らそう!」

  • 教師なし学習

    • 高次元データから低次元データにどうやって落とすか
    • parameter目線
    • なんでもいいから、分けろ。
    • 必ずしも人間に把握できる分類とは限らない
  • k-means法

  • 主成分分析
  • 自己組織化Map

k-means法

再現性があんまない 各データのベクトルのユークリッド?距離をとる 近いものをピトピトピト 雪だるま 重心が平均

主成分分析

ベクトルの射影? なるべく情報量の損失が少なくなるように 回帰分析っぽい?

自己組織化Map

Neural Networkの一部 一個選ぶ 周りにおすそ分け

強化学習

-> 教師あり学習の一部と見る人も多い 教師あり学習 → 「答え」を与える 強化学習→ 「報酬」を与える

ミソ → 「報酬をどう決めるか」

ex. 将棋 どの手がいいのか?

昔: 「銀が王の周りにいると。。。」 「駒得...」

強化学習: 中盤から相互にランダムに駒を動かし続けて 「その手によって盤の評価スコアが上がったか下がったか」を見る

キャリアプランについて

2月から自分達の会社をやっていて、

  • エンジニアとして
  • CTOとして
  • COOとして
  • デザイナとして
  • カメラマンとして

やれることを何でもやってきた。

会社としてまだほとんど何も結果が出ていないので、正直何も偉そうなことは言えないけれど、

この半年で自分の人間としての質が大きく変わったのを感じる。

一方で、 これが5年後、10年後のキャリア、やりたいことへの確度、に対してどれだけ貢献できているのか、というのは、正直わからない。

手元のCacheをまず貯めてから、と思っていたけれど、そんなに簡単に稼げるわけでもなく、 また、単純に自分一人で手元にお金を残そうと思うならば、フリーのエンジニアとして受託で仕事をやっていた方がいいに決まっている。

経営のノウハウ、事業ドメインに関するノウハウ、学んだことは多いけれど、 それらは決して体系だっているわけではなく、どちらかというと混沌の中から部分最適な解を導く能力が伸びただけで、 きちんとまとまった形で次につながるかわからない。

ゴキブリのやり方はわかってる、というか どんなに自分がクソで、社会とうまく擦り合わせが取れなくても、迫りたいものに近づく、という精神は伸びたんだと思うけれど。

シュッとしたいなんて思わないけれど、 きちんと仮説を立てた上で、分析の元に世界をコントロールして、勝つ体験をしないと、このままだとただただ労働のキャパシティが広がっただけになってしまうな、と考えている。

手元の進めるべき物事を進めるために言語を選び、最終的なoutputの結果だけで道具を選んでいるから どうしてもjavascriptやらrubyやらを選びがちで、iosも最近書いてないし、エンジニアとしてどこに落ち着けたいのか、というのもよくわからないな、という感じ。

自分の適性について自分で評価を下すのは難しいけれど、 僕は究極的にはコードを書くこと自体にはピカイチのセンスはなくて、もう少しマクロなレイヤと、現実とコネクトする部分の能力、脳みその方が向いているのかもな、と思ったり。

小さなコードを程よくつまみ食いし続けるのは楽しいけれど、 設計が見えてしまったコード、解決すべきことがすでにわかってしまった後に作業をスケールアウトしていくような形でコードを追加していくことには何の面白みも感じなくなってしまったね。 タイプすることの面白さ、それでもミクロに解決しなきゃいけない問題の面白さはあるけれど、それが持続するのも、持って8時間、という感じ。 自分がコードを書くよりも、僕は何で技術で実現できる/できないということを把握した上でそれを適切に成長させていくことの方が興味があるのかもしれないの。

最近のこととか

f:id:bokuo-okubo:20150715014556j:plain

京都にいます

明日から祇園祭っぽいです。浴衣の人が増えました。

BOOK OFFで欲しかった本が固まってたのでカッとなって四冊も買ってしまった。

完全にはてなさんが放出したもののような気がする。

PHP書いてます

ひょんなきっかけで受けた仕事で、Cakeを触っています。 ModelのインスタンスがArrayで来るのがうぜえ あとデバッガとか、コンソールとか、ツール類がよくわからん。 というか、Railsは相当いいフレームワークだ。 PlayFrameworkも少し触ったけど、Railsのインテグレーテッドでモノリシックでとにかくスポーンと気持よく全体が作れる感じはRailsが段違いな気がする。少ない言語経験ながら。 そしてどちらかというとRubyが偉い。Sinatraも触ったけどよかった。

最近やっとこさwebのこの十年、二十年になにがあったのか、ってのが分かるようになってきたような気がするけれど、 ParlのCPANの文化ができて、言語設計的にソフィスティケートされてRubyができて、みたいな流れ、アー、アー、なるほどなー、という感じ。 Rubyのしくみ、買った。読む。 Ruby以外の言語にも興味津々だけど、Rubyになりたい。Rubyという存在になりたい。

スパゲティ耐性つけたい

保守してるコードを書かれた前任者がものすごく強靭な脳みそをお持ちだったのか、曖昧な名前の$flagとかものすごいネストしたループとかばっかりで、脳が衰弱する思いがする。 理解出来ない僕が悪い、と鞭打って、少しずつ結び目を解くようにしたい。

新しい言語とかフレームワークを触るときの自分の悪いクセに気がついた。 どうしても注目される機能とかのほうに意識がいってしまうけれど、

「所謂普通のコードを普通に書けるか」

デバッグツールはなにか」

「テスト書けるか」

この辺を先に身に付けなきゃいけないんだな。 特にデバッグツールの環境は言語やフレームワークによって様々で、かつそこのスキルのボリューム感が最終的な実装力の底上げになる。 少なくとも手戻りからの復帰が早くなって、結果的に仕上がりが早く的確になる。 もっと意識していきたい。デバッグの科学。

インフラさわってます

web感バリバリの開発現場ではないので、Immutable Infrastructureみたいな考え方があるわけもなく、開発環境の設定からデプロイメントまで、しこしこhttpd.confさわったりscpしたりしてます。 でもま逆に如何に自分世代のエンジニアはLinuxベタの世界から抽象化された世界で生きているかを思い知るいい機会。泥臭いけど、とても勉強になります。

ボトルネックの切り分けだったりパフォーマンスチューニングみたいなところも触らせてもらい、普段打たないようなコマンドを沢山うち、CPU使用率とかコネクション数とか見てます。Linuxともっとお友達になりたい。

自前サービスの運用、みたいな場所にいると、僕のスキルセット的にインフラべったり運用したり、インフラ設計みたいな大きな仕事はまだ来ないと思う。 でもインフラの勉強って、稼働運用中じゃないと得られない知見ある。

だから自分のお砂場としてのサービスをやっぱ作らないとな、って思う。

MySQLのチューニングとか

さすがにヘボの僕がみてもアレなSQLだったり、設定そのままだったりして、ニョロニョロとMySQLの設定とかもいじってます。

MySQL, 基本のキの部分は勉強した、お作法はわかっていたつもりだったけど、じゃぁなんでそのSQLのほうがはやくなるの?とか、MySQLの内部的な挙動だったりとか全然意識が行っていなかったことを思い知ります。というかそうか、こういうこと気にしなきゃいけなかったんだ!というような気づきが多い。

Java裁判とか

Oracleが勝ってもGoogleが勝ってもあんまり良い結果にならなさそうで、なんとも言えないですが、オープンソースコミュニティが当たり前になった後の時代にエンジニアになった身としては、あ、そうか、もともとはもっとクローズドな世界だったんだよな、と気づいた今日このごろ。


7月の目標とか

先月はヌルポで生きてたから結構色々と手を伸ばして勉強できていたけれど、さすがに業務忙しくなると色々なものが後回しになりますね。 少なくとも長期投資的勉強はやはり優先度下がってしまう。

7月ももう半分終わってますが、月末、来月に向けいろいろやりたいことやらなきゃいけないこと沢山あるので自分のKPI設定のために。

  • インフラ系の勉強

ネットワーク系をもう一周してもう一段深い理解にしたい、DBはもう少し事実(実装)に立脚した理解にしたい。 インフラデザインパターンみたいの読む、勉強する。 Chefもう少しちゃんとドキュメント読む。

カッコイーJavaのコード書けるようにすんねん。

やんなきゃいけなくなったので、Scalaやる。

ひきつづきRailsその他gemのソースリード続けていく。 OSS参加できるようになりたいなー

  • 楽器練習する

コード関係ないけど。Chordの方だけど。関わるとしたら。 Tilzの7cを手に入れたので慣らす。 良い楽器がほしいな。誰かKing 3b譲ってくれないかな。 あ、あとお金できたらソプラノサックス買う。

  • やせる

というか運動する。筋量を増やす。 まぁどうせ京都にいるうちはものすごく動くと思うからたぶん痩せる。

プログラミング言語の基礎概念」「Understanding Computation」が完全にスタックの奥のほうにいってしもた(T T)

下半期の目標とか

やっぱり35くらいまでには大学院いきたいな、と思って、 数学ちゃんとやる。とりあえず線形代数の復習と、代数系あたり。 計算機科学系のスタックも消化する。

コンピュータ楽しい。

↓この本読んでるけどちょーいい。てきとーだなぁ

おまじないのおまじない

f:id:bokuo-okubo:20150621175912j:plain

ほとんどスタブです。


cookieまわりの実装で手詰まり、

Request -> Response

の流れを追いたくて、重い腰を上げてRailsのソースリードを始めたんですよ。

世の中腐るほどRailsのソースはおもろい、という主張があるのになぜ読んで無かったのかという話ですが、

た し か に お も し ろ い

具体的に是々が面白いという話はまたこんど、ってことで逃げますが、

Rubyの定数に対する考え方とか、例外に対する考え方とか(メソッド探索)、そのへんがにょろにょろとつながっていく思いがします。

いかに自分がアプリケーションのコードを書いているときにオマジナイ的にRailsメソッドを書いていたかを思い知り、

そのメソッドの先にほんとうのRubyのお呪いが沢山あることを思い知りました。

active_support/core_ext/array/access.rb 読んでて

class Array

  .
  .
  .

  def second
    self[1]
  end

  .
  .
  .

  def forty_two
    self[41]
  end
end

を見つけて一人で嬉しくなった、っていうだけの話ではあるんですが。