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

数理的手法を使いやすくするためのソフトウェア開発

科学技術計算とデータサイエンスについて

計算科学からデータ集約型科学へのワークシフト

この半年、機械学習エンジニアとして仕事をしたいと思ったり ^1 ^2 、 データ分析の仕事のほうがまだ適性があるのではと言われて、 そこを目指そうと思ったりしてきました。

ただ、キャリアを変えるのはなかなか難しいです。 社内公募がないと聞いて落胆したり、 自分にはまだデータサイエンス分野で 仕事を得るためにアピールできるものがないと思い知らされたり。

しかし、チャンスもあるようです。 高性能計算(HPC)の分野では、 昔は、計算科学のためのシステムが大きな割合を占めていましたが、 今では、機械学習ディープラーニングのためのシステムが増えてきているからです。 しかも、計算科学のなかでも機械学習の手法が使われることが増えてきています。

そんなわけで、計算科学分野からデータ集約型科学分野へ ^3 ^4 華麗にキャリアチェンジというわけにはいきませんでしたが、 地味にワークシフト ^5 していきたいと思います。


参考

^1:機械学習エンジニアになるために学ぶべき5つのスキル(海外記事紹介)

^2:Coursera機械学習コースは、仕事を得るための準備としてどれほどのものか?

^3:“The Fourth Paradigm: Data-Intensive Scientific Discovery – Book Released”, eSciece@Microsoft .

^4:計算科学からデータ集約型科学へのシフトで、数理的手法が使いやすくなっている

^5:「ワーク・シフト ― 孤独と貧困から自由になる働き方の未来図」リンダ・グラットン (著), 池村 千秋 (翻訳)

テクノロジーを民主化するには、ソフトウェア開発の民主化から

グーグルなどの言う「機械学習民主化^1 ^2 が文字通りの意味ならば、彼らが目指しているのは、 多数の機械学習エンジニアが、多数の人々の利益のために、 という理想だと思います。 これに対して、現実では、 少数のエンジニアリングを理解しない人々が、少数の人々の利益のために、 ということが起こりがちです。 このギャップを解消することは可能なのでしょうか?

テクノロジーを民主化するために

民主化といえば、 リンカーンのゲティスバーク演説 ^3

「人民による、人民のための、人民の統治」

のフレーズが有名です。これにならえば、テクノロジーの民主化とは、

「エンジニアによる、エンジニアのための、エンジニアリング」

ではないでしょうか。

リンカーンのフレーズは、フランス革命やアメリカ建国がされる前には、 統治のありかたが、人民ではない貴族や専制君主によって決定されていた、 という問題があったことを踏まえています。 同様に、テクノロジーの民主化がされる前、現在では、 エンジニアリングのありかたが、エンジニアではなく、 エンジニアリングを理解しない人々によって決められがちであること が問題なのだと思います。

ソフトウェア・エンジニアリングを理解しない人々によるエンジニアリング

例えば、日本の家電メーカーには次のような問題があります。

日本経済新聞「日の丸家電、打倒アップルの条件 ソフト重視へ転換せよ」中島聡^14

魅力的なソフトウエアを作り出すための全体仕様(アーキテクチャー)を設計することは、机上だけでは決して不可能だ。シェフが実際の料理を作りながらレシピを作るのと同様に、設計を担当するエンジニア自らがプログラムを書き「作っては壊し」の過程を経てはじめてよいアーキテクチャーを作ることができる。

アップル・アマゾン・グーグルをはじめソフトで勝負をしている企業は、どこもそうした開発体制をとっている。…

一方、日本のメーカーでは自分自身がプログラムを書いたこともない幹部候補生が頭の中だけでソフトを設計し、プログラミング作業は子会社に丸投げしている。…

ここで問題なのは、プログラミングを理解しない人が、 ソフトウェアの設計をして、プログラミングのありかたを決めていることです。 こうして、生み出されるソフトウェアに競争力がないために ^4 、利益率が低くなり、エンジニアの待遇は悪くなっています ^5

そして似たような問題は、伝統的な計算科学分野にもあります。

というのは、この分野では、ソフトウェア開発のありかたを決めている人々は ハードウェアや計算科学については十分に理解していますが、ソフトウェア開発についての理解は、 フォートラン時代のままで不十分だからです。 それでも、新しい計算科学分野では、さすがにFortranは廃れつつありますが、 伝統的な分野では、昔から残っているレガシーコードに慮って、 今でもFortranのような古い言語が使われることが少なくありません。 そして、フォートラン時代の手法を使ってシミュレーションを開発することになります。 その結果、近代的なプログラミング言語とスタイルで開発している アメリカとの競争において不利になるという問題が生じるのです。

ソフトウェア・エンジニアリングを理解する人々によるエンジニアリング

日本に比べて、 アメリカのソフトウェアが高い競争力を持っているのは、 ソフトウェア開発者を理解している人々がソフトウェア開発のありかたを決めているからです ^4

そこには、プログラミングを理解しない人が、 プログラミングのありかたを決めてしまうという愚行はありません。 また、フォートラン時代のプログラミングしか知らない人が、 開発言語や手法を左右することも少なくなっています。

このようなソフトウェア開発の民主化によって、 機械学習民主化も実現されつつあります。

具体的に言うと、 昔は、機械学習のアプリケーションプログラムを書くときに、 CやC++でゴリゴリと書いていたのが、 まず、C++Pythonで包み込んだライブラリやソフトウェアフレームワークが普及して、 scikit-learn ^6 などで python スクリプトによって楽にアプリを開発できるようになりました。 そのうちに、TensorFlow ^7 , Chainer ^8 のようにニューラルネットワーク記述のための 領域特化言語が埋め込まれたフレームワークが出てきて、更に楽になりました。 そして、今では、クラウド機械学習 ^9 ^10 ^11 が提供されて、 アプリ開発はプラモデル並みの気楽さになりつつあります ^12 ^13

これに対して、日本の計算科学分野では、ソフトウェア開発が民主化されていないので、 FortranやCでゴリゴリと書くしかなく、 そのような前近代的なプログラミングスタイルには、 オブジェクト指向フレームワークや領域特化言語を使うことによる 素早さや楽しさはありません。

このように、ソフトウェア開発のありかたが、 フォートラン時代なのか近代的なのかによって、 生み出されるソフトウェアやテクノロジーの競争力はまるで違ってきます。

数理的手法を民主化する鍵は、ソフトウェア開発の民主化

以上のように見ていくと、アメリカで機械学習や科学シミュレーションといった数理的手法 が民主化されつつあるのは、ソフトウェア開発が民主化されていたからだと思います。 近代的なソフトウェア開発手法や、 ソフトウェア部品を利用するというプログラミングスタイルが広まっていたからこそ、 大勢の人々がテクノロジーのアプリケーション開発に参加することができ、 その利益が大勢の人々に分配されるのです。

対照的に、日本では、数理的手法に基づくテクノロジー分野において、 ソフトウェア開発が民主化されていないために、 ソフトウェアの生産性と競争力は低く、 その利益は小さいままです。

このように、経済的な利益からいえば、 ソフトウェア開発を民主化したほうが、つまりは、 ソフトウェア・エンジニアリングを理解している人がソフトウェア開発のありかたを 決めたほうが、良さそうです。 しかし、日本企業は労働集約型のビジネスモデル ^4 に合わせて組織を固めてしまっているので、 ソフトウェア・エンジニアリングに基づく知識集約型のビジネスモデルに 転換するのは難しそうです。

そんなわけで、テクロジーの民主化についてのギャップは、日本企業では、 なかなか解消されないのではないかと思います。 ただ、個人にはとっては悪いことばかりではないと思います。 仕事のソフトウェア開発には、取り入れられずにいるテクノロジーが、 趣味の開発には、民主化によって、取り入れやすくなっていくのですから。


参考

^1:Quara “Why is it important to democratize machine learning?”

^2:なぜ、機械学習の民主化は重要か?

^3:ゲティスバーク演説 - wiki

^4:gihyo.jp » Software is Beautiful » 第3回 なぜ日本のソフトウェアが世界で通用しないのか

^5:ITエンジニアの地位とは?国別、職種別の年収比較

^6:scikit-learn

^7:TensorFlow

^8:Chainer

^9:Amazon Machine Learning

^10:Machine Learning - Microsoft Azure

^11:Google Cloud Machine Learning at Scale | Google Cloud Platform

^12:Gigazine「Googleが自社で使っている「クラウド機械学習」を一般に開放、こんなスゴイことが簡単にできる」

^13:Cloud Vision APIの凄さを伝えるべくRasPi botとビデオを作った話

^14:日本経済新聞2014/01/15「日の丸家電、打倒アップルの条件 ソフト重視へ転換せよ」中島聡

なぜ、機械学習の民主化は重要か?

この質問に対して、 Googleのデープラーニング研究者(でKeras開発者)であるChollet氏は、 2つの理由を答えています^1

(Quara “Why is it important to democratize machine learning?"への回答の要約)

ひとつは、機械学習からなるべく大きな価値が生み出されるようにするためです。 そのためには、機械学習を研究したり、あるいは、使いこなすだけの意志と知性を もっている人であれば、誰でも、 機械学習の知識やツールにアクセスできるようにする必要があります。

もうひとつは、機械学習によってなるべく大勢の人々が豊かになり、 社会全体が安定するようにするためです。 ただ、近い将来には、これから生み出される仕事や利益は 機械学習サービスを開発している人々(や企業)に集中していきそうです。 ですから、そのような富と力の集中を緩和してバランスをとるために、 機械学習による価値の創造に大勢の人が参加する必要があるのです。

^1:Quara “Why is it important to democratize machine learning?”

機械学習・ディープラーニングのこれからの進展

松尾先生の「人工知能は人間を超えるか」^1を読んで、

  • (1)機械学習・デープラーニングの何がブレークスルーなのか?
  • (2)これから成長するのはどの分野か?

をまとめて、

  • (3)どんな仕事が求められるのか?

を考えてみました。

(1)機械学習によるブレークスルー

これまでの人工知能ブームでは、2つの課題を解決できなかった。

  • 第1次ブーム : 推論、探索

    • 課題1: 迷路などの簡単な問題は解けても、チェス、将棋などでは組み合わせが莫大すぎて、探索しつくすことができないので、解けない。
  • 1回目の冬の時代

    • 現実の問題は、計算機に解かせるには複雑すぎる。
  • 第2次ブーム : エキスパートシステムで計算機に「知識」を入れる。

    • 課題2: 「知識」を書きだそうとすると、どこまで書いても書ききれない。
  • 2回目の冬の時代

    • フレーム問題 : 計算機がタスクを実行しようとすると、計算機は適切な「知識」の範囲を選び出すことができない。「知識」の範囲が狭すぎて失敗するか、あるいは、範囲が広すぎて計算時間が足りなくなる。
    • シンボルグラウンディング問題 : 計算機は「モノ」を抽象化した「記号」は扱うことができる。しかし、「モノ」と「記号」を結びつけることができない。それは「意味」が分かっていないから。

課題1の解決 -- チェス世界チャンピオンとプロ棋士に計算機が勝利

  • 機械学習

    • 論理的推論ではなく統計的推定 : 過去の膨大な棋譜という「ビッグデータ」の活用
    • 良い特徴量の発見 : 将棋の盤面を評価するときには、「2つの駒の関係」だけでなく、「3つの駒の関係」を使う。
  • 弱点

    • 良い特徴量は計算機でなく人間が見つけねばならない。

課題2を解決する目処がつき、機械学習の弱点は克服されつつある

  • 「現実からどの特徴を取り出すか」を人間でなく計算機にさせることができれば、これまでの難問はすべて解決できる。
  • ディープラーニングというブレークスルー : 特徴表現学習
    • 計算機がデータから着目すべき特徴を見つける --> 機械学習の弱点は克服される
    • 計算機が特徴を見つけ出して、その特徴で抽象化されている「モノ」との対応関係を取り出すことができれば、その対応関係が「モノ」の「意味」であり、現実の「モノ」を抽象化された「記号」である特徴と結びつけることができる。 --> シンボルグラウンディング問題の解決
    • 計算機はデータから特徴を取り出すことができるのだから、その特徴がタスクをこなすために必要な範囲の情報となる。 --> フレーム問題の解決

次の課題を解けるか、それとも、3回目の冬の時代か?

  • 課題3 : マルチモーダルな抽象化、時系列データからの文脈抽出
    • 画像・音声・圧力データを連携させることで、計算機に感情を認識させられるか?
    • 生物は視覚・聴覚・触覚を連携させて生きている。
    • 動画をばらばらの画像としてではなく、文脈を持つ時系列として認識させることができるか?
  • 課題4 : 行動と結果の抽象化
    • 機械自身の行為とその結果を、あわせて抽象化できるか?
  • 課題5 : 外界との相互作用の抽象化
  • 課題6 : 言語理解・自動翻訳
  • 課題7 : 知識獲得

(2)成長分野

これまで

  • 課題1の解決
    • チェス、将棋、碁

現在の注目分野

  • 課題2の解決 : データから良い特徴量を自動的に抽出

これからの成長分野

  • 課題3の解決 : マルチモーダルな抽象化
    • 環境認識、行動予測、感情理解
    • 「ペッパー」のようなロボットに接客をさせる。
    • 街中の画像、音声センターからのデータを連携させて、防犯・防災に役立てる。
  • 課題4の解決 : 行動と結果の抽象化
    • 自律的な行動計画
      • 自動運転
      • 物流でお客さんに渡すところまで
      • 農業の自動化

(3)これから求められる仕事

  • 課題3の解決 : 種類の異なるセンサーからのデータ収集と予測モデルの連携
    • IoT組み込みデバイスからのデータ収集と解析
    • 収集したデータによる機械学習、学習させてモデルによる予測、デバイスへのフィードバック
    • データ収集、解析、予測をクラウドで統合

???


参考

^1:「人工知能は人間を超えるか (角川EPUB選書)」松尾 豊 (著)

メモ:VMwareとVirtualBoxの仮想マシンを引っ越し

自宅のデスクトップPCでブルースクリーンが頻発するようなりました。 そこで、仮想マシンを外部HDDへコピーして、新しいPCへ引っ越そうと思います。 その方法をメモしておきます。

VMware

仮想マシンディレクトリごとコピーして、新しいPCでVMwareからコピーしたディレクトリを開いて、仮想マシンを立ち上げます。

簡単。

VirtualBox

すこし面倒。 なぜなら、VirtualBoxで使用する仮想マシンはvmdk形式(拡張子.vmdk)であるが、このファイルをそのまま別環境にコピーしても残念ながら仮想マシンの移行はできないから。 vmdk形式のファイルを一旦ova形式(拡張子.ova)に変換(エキスポート)してから、このovaファイルを別環境のVirtualBoxでインポートせねばなりません。 インポートが終われば、あとは別環境でその仮想マシンを使うことができます。(確認できるのは、新しいPCが届いてから。しかし、それまで古いPCがもつのか心配です。)

VirtualBoxで仮想マシンを別環境や別フォルダに移動する方法

VirtualBox仮想マシンを別環境や別フォルダに移動するためには、仮想アプライアンスのエキスポート → 仮想アプラインアンスのインポートという手順を踏む。

(1) VirtualBoxのメニューバーから[ファイル(F)] → [仮想アプライアンスのエクスポート(E)…]をクリック

(2) エクスポートする仮想マシンを選択し → [次へ(N)]をクリック

(3) 出力ファイル名を指定し、[次へ(N)]をクリック

(4) [エクスポート]をクリック

(5) 数十秒~数分、以下の画面に何の変化もないが、待っているとプログレスバーが動き始める。

すごいプログラミング言語Formura で、たのしく科学シミュレーション?

科学シミュレーションのプログラミングは、 しばしば、退屈でめんどうなことがあります。

まず、退屈なのは、 ひとそろいの偏微分方程式で記述できるようなシミュレーションであっても、 長大で冗長なソースプログラムを書かねばならないことです。 そして、めんどうなのは、 微分方程式の意味とハードウェアアーキテクチャから どのように高速化すれば良いのかが明らかなときでも、 その機械的なチューニング作業をコンパイラではなく 人間がせねばならないことです。

新しいプログラミング言語

しかし、こうした冗長性と機械的作業を解消するための 研究も行われています ^1 ^2 ^3 ^4 ^6 ^7 。 こうした研究は理化学研究所でも進められおり ^5 、 その論文 ^7 は、 スーパーコンピューティングの国際会議"SC16"において、 ゴードンベル賞のファイナリストに選ばれました ^9

論文 ^6 ^7 は、新しいプログラミング言語 Formura について書かれています。 この言語は、 Fortran が初等的数式を実行形式のコードへと変換するように、 偏微分方程式をCのコードへと変換します。 そして、偏微分方程式で、例えば、菌類の地下ネットワークをシミュレートしようとすれば、 FortranやCでは長大なソースプログラムを書かねばなりませんが、 Formuraならたった20ステップ!ですみます。 また、そのチューニング作業を人間が行わずとも、 コンパイラによる自動チューニングだけで、 理研スパコンから1.2ペタプロップスの性能を引き出せるのです。

楽しいプログラミングだけですごいのか?

さて、こうした研究は科学シミュレーション分野を変えていくのでしょうか? たしかに、プログラミングから冗長性と機械的作業が減れば、 それだけプログラミングは楽しくなります。 しかし、楽しさに現実を変える力はあるのでしょうか? ちなみに、Formura論文の筆頭著者の村主さんは、 「すごいHaskell、たのしく学ぼう」 ^8 の訳者のひとりでもあり、 私はこの本を途中まで読んでみて、 関数型プログラミングには、シミュレーションプログラミングにつきものの冗長性と機械的作業を 解消し、プログラミングを楽しくできる可能性があると知りました。 ただ、Haskellのような関数型プログラミング言語やその楽しいプログラミングスタイルを、 自分の仕事である数理的手法のソフトウェア開発に使える可能性は小さいと判断し、 このすごい本を途中で読むのをやめてしまいました。

関数型プログラミングと領域特化言語はすごい

しかし、私の判断は間違っていたのかもしれません。 プログラミング言語Formura は、Haskellで実装された独立型の領域特化言語 ^10 ^12 であり、 関数型プログラミングの楽しさが科学シミュレーション開発のやり方を変えうることを示している と思います。 また、Formuraの研究の前に、Haskellで実装された埋込み型の領域特化言語 Paraiso ^4 も、 関数型プログラミングが、シミュレーションをプログラミングしやすくするだけでなく、 その計算速度をも向上させられることを 示しています。

やはり、関数型プログラミング、それによるメタ言語的抽象 ^11 と領域特化言語は素晴らしいです。


参考

^1:Klaus Iglberger, Georg Hager, Jan Treibig, and Ulrich Rüde, "Expression Templates Revisited: A Performance Analysis of Current Methodologies", SIAM J. Sci. Comput., 34(2), C42–C69.

^2:Pierre Esterie, Joel Falcou, Mathias Gaunard, Jean-Thierry Lapresté, Lionel Lacassagne, "The Numerical Template toolbox: A Modern C++ Design for Scientific Computing", Journal of Parallel and Distributed Computing, Elsevier, 2014, 74 (12), pp. 3240-3253.

^3:Christophe Prud'Homme, Vincent Chabannes, Vincent Doyeux, Mourad Ismail, Abdoulaye Samake, Gonçalo Pena, Cécile Daversin, Christophe Trophime, "Advances in Feel++: a domain specific embedded language in C++ for partial differential equations",Eccomas'12 - European Congress on Computational Methods in Applied Sciences and Engineering, Sep 2012, Vienna, Austria

^4: T. Muranushi, “Paraiso: an automated tuning framework for explicit solvers of partial differential equations,” Computational Science & Discovery, vol. 5, no. 1, p. 015003, 2012.

^5:理化学研究所プレスリリース「式が書ければ「京」が使える-高度なプログラムを自動生成できる新言語「Formura」を開発-」

^6:Takayuki Muranushi, Seiya Nishizawa, Hirofumi Tomita, Keigo Nitadori, Masaki Iwasawa, Yutaka Maruyama, Hisashi Yashiro, Yoshifumi Nakamura, Hideyuki Hotta, Junichiro Makino, Natsuki Hosono, Hikaru Inoue, "Automatic generation of efficient codes from mathematical descriptions of stencil computation", FHPC 2016: Proceedings of the 5th International Workshop on Functional High-Performance Computing

^7:Takayuki Muranushi, Seiya Nishizawa, Hirofumi Tomita, Keigo Nitadori, Masaki Iwasawa, Yutaka Maruyama, Hisashi Yashiro, Yoshifumi Nakamura, Hideyuki Hotta, Junichiro Makino, Natsuki Hosono, Hikaru Inoue, "Simulations of below-ground dynamics of fungi: 1.184 pflops attained by automated generation and autotuning of temporal blocking codes", SC '16 Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis Article No. 3

^8:「すごいHaskell、たのしく学ぼう」Miran Lipovaca (著), 田中 英行 (翻訳), 村主崇行 (翻訳)

^9:Finalists Compete for Prestigious ACM Gordon Bell Prize in High Performance Computing

^10:M.Fowler and R.Parsons, "Domain-Specific Languages", Addison-Wesley, 2011.

^11:Structure and Interpretation of Computer Programs 2nd edition

^12:"Functional Programming for Domain-Specific Languages", Central European Functional Programming School Volume 8606 of the series Lecture Notes in Computer Science pp 1-28.

データ分析入門としてのKaggleコンペ「タイタニック乗客の生存予測」

これまで、Kaggleコンペティション ^1 ,^13 ,^14 は初心者には関係のない場所だと思っていましたが、 そうではありませんでした。 もちろん、賞金付きのコンペでは専門家がデータ解析で競い合っているのですが、 その他の賞金なしのコンペのなかには初心者が楽しめるものがあるのです。 特に、"Titanic: Machine Learning from Disaster"^2というコンペは入門レベルであり、 予備知識としてpython機械学習の基本を理解していれば、 kaggleコンペのプロセスをひととおり体験できます (ただ、賞金獲得だけは体験できません)。

以下で、その体験の内容をかいつまんで紹介します。

"Titanic: Machine Learning from Disaster"とは

このコンペは、1912年4月15日の大惨事にちなんでいます。 タイタニック号は氷山に衝突して沈没し、 2224人の乗員乗客のうち1502人が亡くなりました。 彼らの生死を分けたのは何だったのでしょうか? 幸運でしょうか?それだけではありません。 実は、ある種の属性を持つ人々はそうでない人々よりも生き延びやすかったのです。 例えば、女性、子供、一等船室の人々は生存確率が高かったことが知られています。

なので、乗客の性別、年齢、船室等級が分かれば、 ある程度はその乗客の生死が予測できるのです。 そして、他の属性も考慮すれば、 その生存予測の正確さを更に向上させられるかもしれません。

コンペ参加者は、このように予測の正確さを向上させて、 他の参加者とその正確さを競います。

このコンペは学習用なので、この予測の仕方を様々なチュートリアル ^3 ,^4 ,^5 ,^6 ,^7 ,^8 が指南してくれます。 このなかで私はインタラクティブなチュートアル^8

A free interactive Machine Learning tutorial in Python

をやってみました。 インタラクティブの良いところは、ゲームでステージを次々にクリアしていくように、 チュートリアルを学んでいけるところです。 そのチュートリアルのwebサイトにアクセスすると、セクションごとに説明が現れて、 pythonスクリプトを書いて提出するように求められ、 スクリプトが間違っていればヒントが表示され、 正しければ次のセクションに進めます。 そして、このようにチュートリアルを進んでいくうちに、以下のデータ分析のプロセス

  1. データ加工
  2. モデリング、トレーニングデータによる学習
  3. テストデータによる検証
  4. 特徴エンジニアリング

を体験できます。

必要な予備知識と使用するライブラリ

チュートリアルをこなすためには、pythonについては基本的な構文を理解していて、 機械学習については何らかのモデルを訓練データから作った経験があれば、 問題ないと思います。

3つのPythonライブラリ

  • NumPy  数値計算 (インポートするときはnumpy と表記)
  • Pandas データ加工 (pandas
  • scikit-learn 機械学習 (sklearn) 

を使いますが、それらを使ったことがなくともチュートリアルの説明を読めば、 課題のpythonスクリプトを書くことができますので、 問題なく最後のセクションまで進めます。

また、課題のpythonスクリプトのなかで、3つのライブラリを

import pandas as pd
import numpy as np
from sklearn import tree

のようにインポートすることになりますが、 こうしたスクリプトはwebサイトのなかで実行されるので、 手元のPCにpythonやそのライブラリを用意する必要はありません。

データ加工

訓練データはコンペ主催者によって収集され、csvファイルとして提供されています。 チュートリアルでは、この訓練データを後でモデルの学習に使いますので、 ここではcsvファイルをpython に読み込ませて、 DataFrameオブジェクトを生成します。 DataFrameオブジェクトは表形式のデータ構造を持っていて、データ加工に使うことができます ^9 ,^10

train_url = "http://s3.amazonaws.com/assets.datacamp.com/course/Kaggle/train.csv"
train = pd.read_csv(train_url)

例えば、与えられた訓練データtrainのフィールド(列)"Embarked"には欠けているところがありますので、その欠損値を次のように穴埋めします。

train["Embarked"] = train["Embarked"].fillna("S")

また、trainのフィールド(列)"Embarked"には、はじめは文字型の値"S","C","Q"が入っていますので、それらを機械学習で扱える数値型の値に変換します。

train["Embarked"][train["Embarked"] == "S"] = 0
train["Embarked"][train["Embarked"] == "C"] = 1
train["Embarked"][train["Embarked"] == "Q"] = 2

モデリング、トレーニングデータによる学習

モデリングには様々なやりかたがあるのですが、ここでは決定木を使います。 決定木は、scikit-learnライブラリではDecisionTreeClassifierクラスとして用意されていますので、 そのインスタンスを作成してmy_tree_oneに代入します。

my_tree_one = tree.DecisionTreeClassifier()

決定木モデルを学習させるためには、モデルへの入力となる特徴量ベクトルと、モデルからの出力と照合できるターゲットデータが必要です。 そこで、まず、特徴量として乗客属性"Pclass","Sex","Age","Fare"を使うことにして、それらを訓練データtrainから取り出して、feature_oneに代入します。

features_one = train[ ["Pclass", "Sex", "Age", "Fare"] ].values

次に、ターゲットデータとなる乗客の生死を訓練データtrainから取り出して、targetに代入します。

target = train["Survived"].values

こうして、ターゲットと特徴量ベクトルが揃ったので、 それらを使ってモデルを学習させます。

my_tree_one = my_tree_one.fit( features_one, target)

これで、機械学習によりモデルmy_tree_oneが出来上がりました。

テストデータによる検証

テストデータも訓練データと同様に主催者によってcsvファイルとして用意されています。 しかし、このcsvファイルには乗客の生死のデータは入っておらず、乗客の属性データだけが入っています。 なので、チュートリアルでは検証プロセスのうち、テストデータの乗客の属性データを上で作成したモデルに入力して、乗客の生存予測を出力させるところまでを行います。

実際の検証プロセスであれば、テストデータには乗客の生死データも含まれていて、 これらの生死データとモデルの出力を比較します。 しかし、コンペティションではこの比較をコンペ主催者が行うので、 csvファイルには生死のデータが入っていないのです。

コードは省略しますが、まず、 テストデータのcvsファイルを読み込んでDataFrameオブジェクトtestへと変換して、 欠損値を穴埋めしておきます。 そして、テストデータtestから特徴量ベクトルを取り出します。

test_features = test[ ["Pclass","Sex", "Age", "Fare"] ].values

そのテストデータの特徴量に基づいて、乗客の生死を予測させます。

my_prediction = my_tree_one.predict(test_features)

この予測結果をkaggleに提出するには、csvファイルでなければなりませんので、 予測結果my_predictionを所定のフォーマットのcsvファイルに変換します。

PassengerId =np.array(test["PassengerId"]).astype(int)
my_solution = pd.DataFrame(my_prediction, PassengerId, columns = ["Survived"])
my_solution.to_csv("my_solution_one.csv", index_label = ["PassengerId"])

この生存予測ファイルmy_solution_one.csvチュートリアルのwebサイトからダウンロードできますので、 それをkaggleに提出すると、 実際の乗客の生死データを比較して順位をつけてくれます。

私がやってみたところ、 順位は5,838チームのうちで5,692番目で、スコア(正確さ)は 0.569 でした。 順位が底辺に近いのは、何の工夫もしていないからです。 そこで、 次は特徴エンジニアリングを行います。

特徴エンジニアリング

これまでは、乗客の生死を左右するの属性は、 客室の等級"Pclass",性別"Sex",年齢"Age",運賃"Fare"だけであると 考えてきました。 しかし、他にも重要な属性があるかもしれません。 例えば、一緒に乗船している家族の人数もまた生死を左右していたと考えられます ^11 。 というのは、家族で一緒に旅をしていた人は、救命ボートに乗る順番が回ってきたとしても、 家族全員が揃っていなければ、ボートで脱出せずにタイタニック号に留まっていたのではないかと想像できるからです。 この仮説が正しければ、 大家族であればあるほど救命ボート乗り場に集合するまでに時間がかかるので、 それだけ生存確率が下がるはずです。

この仮説にそって、乗船している家族の人数を訓練データに加えます。

train_two = train.copy()
train_two["family_size"] = train_two["SibSp"] + train_two["Parch"] + 1

こうして更新した訓練データを使って、新たに決定木モデルを学習させます。

features_three = train_two[ ["Pclass", "Sex", "Age", "Fare", "SibSp", "Parch", "family_size"] ].values

my_tree_three = tree.DecisionTreeClassifier()
my_tree_three = my_tree_three.fit( features_three, target)

さて、この新しいモデルmy_tree_threeでは、どのくらい順位が上がるのでしょうか?

このmy_tree_threeにテストデータを入力して、 出力をkaggleに提出してみました。 順位は5,838チームのうちで4,760番目、スコア(正確さ)は 0.756 と、 すこし良くなりました。 しかし、順位はまだまだ悪いです。 それで、上位に入っている人の記事^12を読みますと、 非常に感心させられます。

まとめ

以上で紹介したように、コンペ"Titanic: Machine Learning from Disaster"チュートリアル^8で、主要なデータ解析のプロセス、データ解析、モデリング、学習、検証、特徴エンジニアリング、をひととおり体験できます。 ちなみに、モデリングとして、このブログ記事では、決定木を使う場合だけを書きましたが、 その他に、決定木で過学習を抑制するためのテクニックや、ランダムフォレストを使う場合についても体験できます。

私はやってみて、機械学習アプリ開発だけでなく、 データ解析もけっこう面白いのではないかと思いました。 おすすめです。


参考

^1:Kaggle Competitions

^2:"Titanic: Machine Learning from Disaster"

^3:Getting Started with Excel: Kaggle's Titanic Competition

^4:Getting Started with Python: ...

^5:Getting Started With Python II: ...

^6:Getting Started With Random Forests: ...

^7:Getting Started with R: ...

^8:A free interactive Machine Learning tutorial in Python

^9:Qiita pandasでよく使う文法まとめ

^10:pandas 0.19.1 documentation » API Reference » pandas.DataFrame

^11:Large families not good for Survival - Kaggle

^12:Kaggleのtitanic問題で上位10%に入るまでのデータ解析と所感

^13:賞金稼ぎから仕事探しまで、世界のデータサイエンティストが「Kaggle」に集まる理由

^14:世界のデータサイエンティストが集う「Kaggle」とは?ビッグデータ分析を競い合え!