DVCによるデータバージョン管理

Transcript

1. DVCの目的は・・・ 機械学習プロジェクトの再現可能性(reproducible)の確保 こんな経験はありませんか？ • 過去に自分 or 他人が取り組んだ機械学習プロジェクトを再実行することになった • 実行したがナゼか当時の報告書の結果と一致しない ※原因はデータ・コード・パラメタに変更が発生したが、変更が残っていない等 紹介 1/5 はじめに
2. 紹介 2/5 現状 • コードはgitで管理できるが、大規模なデータセットはgitでは管理が難しい(容量の制限) ➢ コードはgitで管理、データセットはローカルorクラウドストレージに保存 • データとコードの対応をバージョン管理する難しさ(ドキュメント作成の難しさ) ➢ どのコードでどのデータを使用したか、記録はドキュメント作成者の努力に依存する • チーム間でのデータ共有の難しさ(統一された保存先がない) ➢ データの保存場所だけでなく、実行フォルダへの配置方法などをドキュメントや口頭 で詳細に説明する • コード・パラメタ・データを変更した場合の性能比較が困難(結果ファイルの管理が大変) ➢ 変更の履歴、結果の比較をドキュメントとして保存 ➢ 結果ファイルをストレージへ保存 ➢ 手順に従ったとき、結果が一致するか目視でチェック 上記のようにコードとデータとそのバージョン管理にミスが発生す る状況ではプロジェクトの再現性が低下してしまいます 現状の解決策
3. DVCはGitと連携して動作する(特にデータ管理の)補完的なツールと してプロジェクトの実験再現性を確保するように設計されています 解決策 • 大きなデータファイルはGitの外で管理 • データやコード、モデルの重みなどに発生した差異をmd5ハッシュを使い検知 • dvc.yamlや.dvcなどのメタファイルのみをGitで追跡 • Gitライクなコマンドでデータのバージョンを管理（add, checkout, pushなど） • 実データはキャッシュやストレージ(AWS S3, Google Cloud Storage, Azure Blob)に保 存 • データ処理から学習、評価までのパイプラインを定義可能 • コード・パラメタ・データの組み合わせごとの評価指標をコミット履歴やブランチをつか い比較することが可能 紹介 3/5 DVCによる解決策
4. git hub DVC remote storage git ローカルリポジトリ DVC cache ソースコード DVCメタファイル ソースコード DVCメタファイル 実データ (データセット、モデル) 実データ (md5ハッシュによる重複削除) リモート環境 ローカル環境 git push git pull dvc push dvc pull dvc add dvc commit dvc checkout 紹介 4/5 DVCのデータ管理イメージ
5. 前処理 pre.py 特徴量作成 feat.py 学習 train.py 評価 eval.py 実行パイプライン dvc.yaml パラメタ params.yaml pre.py feat.py train.py eval.py 中間生成物 (特徴量、モデル) 実験結果 (metrics.json、plot.png) 紹介 5/5 • 依存ファイルの変化をmd5ハッシュで検知 • dvc reproコマンドでパイプラインに定義したスクリプトを順番に実行 • 結果の生成、比較を半自動化 パイプラインによる実行過程の再現