Contenu connexe
Similaire à How to Develop Experiment-Oriented Programs (20)
How to Develop Experiment-Oriented Programs
- 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
- 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
- 20. ⽣生成⽅方法の管理理
(実験プログラム・実験⼿手順プログラム)
• 基本的には通常のソフトウェア開発の⽅方法を踏襲
• Backward Compatibilityは気にしなくても良良くなることがある
• 昔の結果を再現したかったら、過去のコミットをチェックアウトし
てプログラムを動かし直せば良良い
• 開発ソフトウェアを公開する場合、公開以後は通常のソフトウェア
と同等の注意が必要
20
- 21. ⽣生成結果の管理理
(実験結果・ログ)
• ⼀一般的にプログラムの⽣生成物(含実験結果)はバージョン管理理ツール
は含めない
• 理理由:サイズが膨⼤大 / 実⾏行行ごとに結果が変化する
• Githubでは50MB以内/ファイルを推奨されている
• 善後策(案)
• ⼀一貫した命名規則を与える(result.YYMMDD.commitNo.txtなど)
• 実験結果の置き場所を固定する(/data/result/repo名/など)
21
- 24. ドキュメントの管理理:ドキュメントしてのサンプル
• 課題:ドキュメントの充実度度 vs. 追従コスト
• 通常のソフトウェア以上に変化が激しく、追従コスト⾼高
• しかしドキュメントが全くないのは危険(1ヶ⽉月前の⾃自分は他⼈人)
• ソフトウェアを公表する場合には必須
• 解決案
• サンプルをコードと共に管理理する
• サンプルデータ/サンプル設定ファイル/想定実験結果の⼀一部
• 実験⼿手順プログラムのコマンドをシンプルにする
24
- 25. 残課題
• 本番データセットの管理理
• 通常バージョン管理理ツールでは管理理しない
• 実験環境の管理理
• 環境変化は開発の脅威
• ライブラリのバージョンが上がってプログラムが動かなくなる
• 環境を変えて実験しようとしたらコンパイルできない
• 解決案:Vagrantなど?
• 実験プログラムから外部公開できるライブラリへのスムーズな移⾏行行
• ノウハウのツール化
25
- 26. まとめ
• 実験プログラムとは実験を⽬目的に開発するプログラムです
• アルゴリズムの開発・結果解析には、実験⼿手順プログラム、⼊入⼒力力リ
ソース、実験結果などのコンポーネントの開発・管理理を伴います
• 実験プログラム開発の課題の⼀一つに、迅速な実験結果⽣生成とソフト
ウェアとしての品質の両⽴立立があります
• 再現性の確保には⽣生成⽅方法の管理理・⽣生成物の管理理・両者の対応付けの
管理理が重要です
• ノウハウのツール化は実験プログラムのライブラリ化につながります
26
- 28. 想定聴衆
• ⼤大学でデータマイニング・機械学習を専攻する⼤大学⽣生、⼤大学院⽣生及び
その指導をする教員
• 機械学習のアルゴリズムを開発する研究者
• データマイニング技術の各分野(ライフサイエンス・製造業・ウェ
ブ)への応⽤用を⾏行行う研究者
• 企業でデータマイニングを⾏行行うデータ分析担当者
• 何らかのリソースを処理理するプログラム開発を⾏行行う開発者
• データマイニング・機械学習の⾃自前開発を検討している企業関係者
• 機械学習の新しいアルゴリズムを開発したい
• アルゴリズムの開発の裏裏側を知りたい
• 論論⽂文で紹介されているこのアルゴリズムを試しに使ってみたい
•2 8⼿手元にデータがあるのでそれの特性を知りたい
- 29. 誰が実験プログラムを開発しているか?
• 機械学習系研究グループ
• 外に出るのはアルゴリズムやソフトウェア
• 研究グループ内での秘伝のタレはあるが、普遍的に語られることは
少ない
• ⼤大学の情報系学部・情報科学実験
• 導⼊入としてプログラム開発⽅方法
• 開発環境・エディターの使い⽅方・プログラミングの初歩など
• 最近の道具が使われることも
29
- 33. ⾃自然科学での実験とコンピュータ上での実験の⽐比較
• 通常の⾃自然科学での実験
• 実験計画を⽴立立てて
• 実験装置を⽤用意して ← ここにプログラム開発が伴う
• 実験試料料を調整して
• 試料料を装置にかけて結果を取得して
• 結果を統計解析して ← ここでもプログラム開発が必要かも
• 考察を論論⽂文・報告書にまとめて
• 最初に戻る
• コンピュータ上での実験
• 実験装置 → 実験プログラム or ソフトウェア・ライブラリ
• 実験試料料 → データファイル(画像・⾃自然⾔言語・センサーデータ)
33
- 36. コンポーネント解説(3):設定ファイル
• テキストファイルが⼀一般的
• JSON, tsv, csv, yaml …
• 実験⼿手順に関する設定を記述する
• 後述するリソースで紹介する実験プログラムに与える設定ファイルの
パラメータを作るためのパラメータ(ハイパーパラメータ?)など
• 設定項⽬目が少なければ実験⼿手順ファイルに直書きしてもいいかも
• 設定ファイルをどれだけ複雑にしないかは実験開発での鍵の⼀一つ
36
- 37. コンポーネント解説(4):データセット
• 実験プログラムに与える設定ファイル
• 実験に⽤用いる⽣生データセット
• ⾃自動⽣生成した設定ファイルや・前処理理した⽣生データセットもリソース
とみなせる
• 実験⼿手順プログラムが⽣生成した設定ファイル
• 前処理理プログラムで加⼯工済のデータセット
• 実験プログラムが⽣生成した結果がリソースになること
• 実験プログラムの設定ファイルは複雑になりがち
• 例例えばNNの設定ファイルを⾃自分で書くのは厳しい
37
- 38. データセットのデータ形式
• テキストフォーマット
• JSON
• ⻑⾧長所:パーザーが充実、壊れにくい
• 短所:パーズに時間がかかる
• CSV, TSV
• ⻑⾧長所:扱いやすい、⽣生成しやすい、human readable
• 短所:壊れやすい、パーズに時間がかかる
• バイナリ
• ⻑⾧長所:データサイズが⼩小さい、読み込みが速い
• 短所:human readableでない、前処理理が必要
38
- 41. mafのノウハウ
• Nodeは階層で作れる
• 依存関係を明⽰示化するためのdummy node
• タスクをIdentifyするのにParameterを使う
• ⼊入出⼒力力でJSONを扱う
• TaskのParameterとして関数を与える
41