How to Develop Experiment-Oriented Programs
•
7 recomendaciones•3,836 vistas
20140925 PFI seminar (ver. 1.0)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a How to Develop Experiment-Oriented Programs
Similar a How to Develop Experiment-Oriented Programs (20)
Más de Kenta Oono
Más de Kenta Oono (17)
How to Develop Experiment-Oriented Programs
- 1. 2014/09/25 PFIセミナー 実験プログラム 開発⽅方法論論 ⼤大野健太 oono@preferred.jp
- 2. ⾃自⼰己紹介 • ⼤大野健太(@delta2323_) • 経歴：数理理科学研究科（共形幾何）→2011.8 PFIインターン →2012.3- PFI • 所属：研究班（担当領領域：理理論論解析・ライフサイエンス） • 近況：ブログを再開しました：http://delta2323.github.io • 関連資料料 • 今⽇日の発表に関連する資料料（スライド・⽂文書・コードへのリンク） は以下にまとめています • https://docs.google.com/document/d/ 1PB6qHAt2Lyvm_AUXjiAjOt1v9BgbATnKtb38buwlOZI/edit 2
- 3. アジェンダ • 実験プログラムとは • 概要/典型パターン • 実験プログラム開発 • 特徴/課題/リソース管理理⽅方法 • デモ • 話さない事 • ツールの使⽤用⽅方法/細かなノウハウ/開発対象のアルゴリズム 3
- 4. 実験プログラム = 実験を⾏行行うプログラム • コンピュータ上で実験を⾏行行う際に開発するプログラム • ⼊入る • 開発アルゴリズムの精度度評価 • データ（画像・動画・センサー）の性質解析 • ソフトウェア開発以外でもプログラミングが伴う場合も • 既存ソフトウェアの検証 • 実験結果の統計解析 • ⼊入らない • 装置を使うだけの実験 4
- 5. 科学実験のサイクル 先⾏行行研究調査 仮説構築 計画・準備 予備実験 解析・考察 実証実験 公表 既存ソフトウェアの試⽤用 データの前処理理 プログラム開発 様々なパラメータでプログラム実⾏行行 統計解析ツールを使った分析 開発ソフトウェアの公開 5
- 6. 実験プログラム開発は 科学実験とソフトウェア開発論論の境界領領域 • 科学実験の側から⾒見見ると • 今⽇日コンピュータを使わない実験の⽅方が珍しい • 注⽬目度度：実験結果 ＞ 開発物 • アルゴリズムの新規性 ＞ 開発⽅方法 • 必要性：ノウハウは各研究グループの秘伝のタレ • ソフトウェア開発の側から⾒見見ると • ⼀一般のソフトウェア開発論論は古くから議論論されている • 注⽬目度度：データマイニング・機械学習への特化は（まだ）少ない • 必要例例：通常のソフトウェア開発とは異異なる特徴・要求を持つ 6
- 7. 実験プログラム開発はアルゴリズム開発だけではない サーバー ライブラリ ⾃自動化 実験結果・ログ スクリプト 実験プログラム 設定ファイル データセット 7
- 8. 実験プログラム開発の典型パターン サーバー ライブラリ 実験⼿手順 実験結果・ログ プログラム 実験プログラム データセット 設定 ファイル 出⼒力力 本体 ⼊入⼒力力 環境 8
- 9. 実験プログラム開発・バリエーション(1)：データ解析 サーバー ライブラリ 実験⼿手順 実験結果・ログ プログラム 3rd Party プログラム データセット 設定 ファイル 環境 出⼒力力 本体 ⼊入⼒力力 9
- 10. 実験プログラム・バリエーション(2)：⾃自動⽣生成 実験プログラム 実験⼿手順 プログラム データセッ ト 実験プログラムの 設定ファイルを⾃自動⽣生成 10
- 11. 実験プログラム・バリエーション(3)：パイプライン化 実験プログラム 実験⼿手順 プログラム 実験結果 前の実験プログラムの 結果・ログが後段の実験 プログラムの⼊入⼒力力 11
- 12. 実験プログラム・バリエーション(4)：可視化 実験結果 実験⼿手順 プログラム実験プログラム 可視化結果 12
- 13. 実験プログラム・バリエーション(5)：分散システム ・実験⼿手順プログラムがサー バーを横断して実⾏行行指⽰示 ・実験プログラムの並列列実⾏行行 ・実験プログラムの協調動作 13
- 14. 実験プログラム開発
- 15. ソフトウェア開発論論の実験プログラム開発への適⽤用 • ソフトウェア開発のツール・ノウハウは充実している • ツール • ビルドツール（make/cmake/waf） • バージョン管理理ツール（git/svn/mercurial） • 依存ライブラリ管理理ツール（bundler/cabal） • 開発⼿手法（git flow/TDD/CI） • コードの品質（Clean Code/リファクタリング/ユニットテスト） • 実験プログラムの特性を考慮した、ソフトウェア開発論論への適⽤用が実 験プログラム開発技術となる（と思う） 15
- 16. 実験プログラム開発の特徴(1) ：ソフトウェアより実験結果がほしい • 最終⽬目標がソフトウェア開発でないことも多々 • 1回しか動かさないプログラム • 予備実験/⽣生データ可視化/⽣生成物が巨⼤大な前処理理 • （結果的に）捨てるプログラム • 開発の過程で実験の⽅方向性が変化し、検証の意義がなくなる • 他⼈人の使⽤用を想定しないプログラム • アルゴリズム開発が⽬目的でも実験結果は重要 • KDD, ICMLでは実験での検証がほぼ必須 16
- 17. 実験プログラムのジレンマ • プログラムの品質 vs. 実験結果を出す速度度 • 実験結果を出す事の優先度度が⾼高い → プログラムの品質向上の施策がないがしろにされがち （サンプル・ユニットテスト・リファクタリング・コード管理理） • 後回し⾃自体は優先度度の問題で悪くはない（と思う）。全く取られな いとしたらそれは問題 • 個別性 vs. 汎⽤用性 • 当⾯面実験で使うサンプルには”スパム”と”ハム”の2通りのラベルし かつかないからそれを前提として書いてしまおう • ⼀一⽅方であまりに汎⽤用化しても、テストケースが増えるだけでその コードパスは2度度と使われないかも（20%ルール）、妥協も⼤大事 17
- 18. 実験プログラム開発の特徴(2)：結果の再現性 • 科学であるための必要条件 • ⼿手段：保存 or 再⽣生成 • 保存 • 管理理対象：実験結果・ログ・可視化図 • ⽅方法：後述（結果ディレクトリを残しておくだけだと⼤大抵失敗する） • ポイント：1ヶ⽉月前の⾃自分は他⼈人 • 再⽣生成 • 管理理対象：プログラム(本体/⼿手順)・設定ファイル・データセット • 実験結果の保存が困難な場合（容量量などの問題） • ポイント：ソフトウェアとしての品質が再現の容易易さ 18
- 19. 実験プログラム開発の典型パターン サーバー ライブラリ 実験⼿手順 実験結果・ログ プログラム 実験プログラム データセット 設定 ファイル 出⼒力力 本体 ⼊入⼒力力 環境 19
- 20. ⽣生成⽅方法の管理理 （実験プログラム・実験⼿手順プログラム） • 基本的には通常のソフトウェア開発の⽅方法を踏襲 • Backward Compatibilityは気にしなくても良良くなることがある • 昔の結果を再現したかったら、過去のコミットをチェックアウトし てプログラムを動かし直せば良良い • 開発ソフトウェアを公開する場合、公開以後は通常のソフトウェア と同等の注意が必要 20
- 21. ⽣生成結果の管理理 （実験結果・ログ） • ⼀一般的にプログラムの⽣生成物（含実験結果）はバージョン管理理ツール は含めない • 理理由：サイズが膨⼤大 / 実⾏行行ごとに結果が変化する • Githubでは50MB以内/ファイルを推奨されている • 善後策（案） • ⼀一貫した命名規則を与える（result.YYMMDD.commitNo.txtなど） • 実験結果の置き場所を固定する（/data/result/repo名/など） 21
- 22. ⽣生成⽅方法と⽣生成結果の対応付けの管理理 • ⽣生成⽅方法と⽣生成結果を独⽴立立に管理理するだけでは不不⼗十分 • 設定ファイル・リソース・外部ライブラリ・実験環境どれが変わって も実験結果は変わりうる → ログだけ残っていても何のログかわからなかったら使えない • プログラム改良良と実験を細かい粒粒度度で頻繁に繰り返す → 通常のソフトウェア開発以上にバージョン違いが発⽣生しやすい → ログのバリエーションが爆発・命名規則に⼀一貫性がなくなる 22
- 23. デモ：モンテカルロ法の開発
- 24. ドキュメントの管理理：ドキュメントしてのサンプル • 課題：ドキュメントの充実度度 vs. 追従コスト • 通常のソフトウェア以上に変化が激しく、追従コスト⾼高 • しかしドキュメントが全くないのは危険（1ヶ⽉月前の⾃自分は他⼈人） • ソフトウェアを公表する場合には必須 • 解決案 • サンプルをコードと共に管理理する • サンプルデータ/サンプル設定ファイル/想定実験結果の⼀一部 • 実験⼿手順プログラムのコマンドをシンプルにする 24
- 25. 残課題 • 本番データセットの管理理 • 通常バージョン管理理ツールでは管理理しない • 実験環境の管理理 • 環境変化は開発の脅威 • ライブラリのバージョンが上がってプログラムが動かなくなる • 環境を変えて実験しようとしたらコンパイルできない • 解決案：Vagrantなど？ • 実験プログラムから外部公開できるライブラリへのスムーズな移⾏行行 • ノウハウのツール化 25
- 26. まとめ • 実験プログラムとは実験を⽬目的に開発するプログラムです • アルゴリズムの開発・結果解析には、実験⼿手順プログラム、⼊入⼒力力リ ソース、実験結果などのコンポーネントの開発・管理理を伴います • 実験プログラム開発の課題の⼀一つに、迅速な実験結果⽣生成とソフト ウェアとしての品質の両⽴立立があります • 再現性の確保には⽣生成⽅方法の管理理・⽣生成物の管理理・両者の対応付けの 管理理が重要です • ノウハウのツール化は実験プログラムのライブラリ化につながります 26
- 27. 補⾜足資料料
- 28. 想定聴衆 • ⼤大学でデータマイニング・機械学習を専攻する⼤大学⽣生、⼤大学院⽣生及び その指導をする教員 • 機械学習のアルゴリズムを開発する研究者 • データマイニング技術の各分野（ライフサイエンス・製造業・ウェ ブ）への応⽤用を⾏行行う研究者 • 企業でデータマイニングを⾏行行うデータ分析担当者 • 何らかのリソースを処理理するプログラム開発を⾏行行う開発者 • データマイニング・機械学習の⾃自前開発を検討している企業関係者 • 機械学習の新しいアルゴリズムを開発したい • アルゴリズムの開発の裏裏側を知りたい • 論論⽂文で紹介されているこのアルゴリズムを試しに使ってみたい •2 8⼿手元にデータがあるのでそれの特性を知りたい
- 29. 誰が実験プログラムを開発しているか？ • 機械学習系研究グループ • 外に出るのはアルゴリズムやソフトウェア • 研究グループ内での秘伝のタレはあるが、普遍的に語られることは 少ない • ⼤大学の情報系学部・情報科学実験 • 導⼊入としてプログラム開発⽅方法 • 開発環境・エディターの使い⽅方・プログラミングの初歩など • 最近の道具が使われることも 29
- 30. 開発⽅方法論論の必要性 • きれいなコードが実験効率率率につながる • ⽅方法論論なくプログラムを開発すると実験結果が出せない • 改良良したいけれどコードが複雑すぎてどこを変えればいいかわ からない • コードを少しいじったら急に動かなくなった • プログラム開発の効率率率が実験全体の効率率率につながる 30
- 31. 実験の理理想的なサイクル 計画 開発 実験 考察 31
- 32. 実験プログラム開発の流流れ：開発と実験を何度度もイ テレーションする 実装 実験計画の策定 ラージデータで 実験 リファクタリン グ 結果のまとめ 設定の調整 テスト スモールデータ で実験 レポジトリの管 理理 リファクタリン 32グ
- 33. ⾃自然科学での実験とコンピュータ上での実験の⽐比較 • 通常の⾃自然科学での実験 • 実験計画を⽴立立てて • 実験装置を⽤用意して ← ここにプログラム開発が伴う • 実験試料料を調整して • 試料料を装置にかけて結果を取得して • 結果を統計解析して ← ここでもプログラム開発が必要かも • 考察を論論⽂文・報告書にまとめて • 最初に戻る • コンピュータ上での実験 • 実験装置 → 実験プログラム or ソフトウェア・ライブラリ • 実験試料料 → データファイル（画像・⾃自然⾔言語・センサーデータ） 33
- 34. コンポーネント解説(1)：実験プログラム • アルゴリズムの本体が記述されているプログラム • 開発物のコア • どの⾔言語を⽤用いるかはケース・バイ・ケース • 実装者の好み・スキルセット • ライブラリの充実度度 • 既存ソフトウェアの使⽤用 34
- 35. コンポーネント解説(2)：実験⼿手順プログラム • 実験プログラムの使い⽅方を⽰示すプログラム • 設定ファイルの種類 • データセットの種類 • パラメータの種類 • 実験プログラムの⼀一番の特徴（だと思っている） • 通常のプログラムで⾔言えばビルドツールに当たるか • 理理想的にはプログラムで⾃自動化されている • 実験規模が⼩小さければシェルスクリプトで⼿手軽に 35
- 36. コンポーネント解説(3)：設定ファイル • テキストファイルが⼀一般的 • JSON, tsv, csv, yaml … • 実験⼿手順に関する設定を記述する • 後述するリソースで紹介する実験プログラムに与える設定ファイルの パラメータを作るためのパラメータ（ハイパーパラメータ？）など • 設定項⽬目が少なければ実験⼿手順ファイルに直書きしてもいいかも • 設定ファイルをどれだけ複雑にしないかは実験開発での鍵の⼀一つ 36
- 37. コンポーネント解説(4)：データセット • 実験プログラムに与える設定ファイル • 実験に⽤用いる⽣生データセット • ⾃自動⽣生成した設定ファイルや・前処理理した⽣生データセットもリソース とみなせる • 実験⼿手順プログラムが⽣生成した設定ファイル • 前処理理プログラムで加⼯工済のデータセット • 実験プログラムが⽣生成した結果がリソースになること • 実験プログラムの設定ファイルは複雑になりがち • 例例えばNNの設定ファイルを⾃自分で書くのは厳しい 37
- 38. データセットのデータ形式 • テキストフォーマット • JSON • ⻑⾧長所：パーザーが充実、壊れにくい • 短所：パーズに時間がかかる • CSV, TSV • ⻑⾧長所：扱いやすい、⽣生成しやすい、human readable • 短所：壊れやすい、パーズに時間がかかる • バイナリ • ⻑⾧長所：データサイズが⼩小さい、読み込みが速い • 短所：human readableでない、前処理理が必要 38
- 39. コンポーネント解説(5)：実験結果 • 実験プログラムの⽣生成物 • これを得るのが実験プログラム開発の⽬目的 • 機械学習の学習モデル、評価指標の表・グラフ • プログラム実⾏行行結果ログ • 通常テキストファイル • 実験結果をリソースとして再び実験プログラムが使うことも 39
- 40. 管理理戦略略 前処理理プログラム 実験プログラム 設定ファイル 実験⼿手順 プログラム サンプル 設定ファイル ⽣生データ サンプル ⽣生データ 前処理理済 データ サンプル 前処理理済 データ 40レポジトリ管理理
- 41. mafのノウハウ • Nodeは階層で作れる • 依存関係を明⽰示化するためのdummy node • タスクをIdentifyするのにParameterを使う • ⼊入出⼒力力でJSONを扱う • TaskのParameterとして関数を与える 41