実験するときのデー タ管理 d3m LT @515hikaru 2018/11/6

背景 あるデー タとあるアルゴリズムの組み合わせでどんな予測結果が出 るのかを検証するためのアプリを作りたい システム化以前の効果検証 実際に予測や推薦とかをして結果を見てみる 検証期間は1 ヶ月～ 数ヶ月 特定のデー タに様々 な試行錯誤を施す 前処理のスクリプトのメンテナンスコストの増大 自分が書いたコー ドが自分もワカラナイなんてことも起こり得 る デー タとアルゴリズムの組み合わせを検証 どの組み合わせは既に終えたのかなどが混乱しがち

課題 デー タの管理 デー タが3 種類: 生デー タ、 前処理済みデー タ、 予測時に利用す るデー タ 前処理の内容は日々 変わる どのデー タがどんな前処理を施したデー タかわからなくなる スクリプトの管理 デー タとスクリプトの依存関係が不明瞭

やったこと リポジトリを2 つにわける 前処理用リポジトリ アプリケー ションリポジトリ 前処理用リポジトリはアプリケー ションが使うデー タを作成するた めのスクリプト群 アプリケー ションはそのデー タを使って実際に予測結果の出力など を行う

なぜこうしたか 2 つのプロセスを明確に分離したかった 予測に必要なデー タを集め整備すること あるデー タが与えられたとき予測すること 前者は前処理リポジトリが、 後者はアプリケー ションが担う

1. 前処理用リポジトリの管理 成果物を定義する 成果物はアプリケー ションが使うデー タを作成すること 前処理用のスクリプトとアプリケー ションで分担ができていれ ばよい アプリケー ションは何を想定して何を想定しないのかを明確に 欠損は前処理のうちに埋めておく 標準化の実施はアプリケー ション側で制御する etc...

2. 前処理用リポジトリの管理 フォルダ構成( 抜粋) ├ ─ ─ M a k e f i l e ├ ─ ─ d a t a │ ├ ─ ─ i n t e r m e d i a t e # 中間生成物 │ ├ ─ ─ o u t p u t # 成果物 │ └ ─ ─ r a w # 生デー タ └ ─ ─ s r c / * . p y ここで s r c と r a w の中身だけ Git 管理下に置く。 Makefile 成果物や中間生成物はバー ジョン管理をしない 完成版をいつでももう一度 m a k e と叩けば再生成できるようにする デー タを管理するのではなくデー タを作成するプロセスを管理 する

注意 少人数・ テキストの構造化デー タに対して行っていたときにとった 方法 m a k e が長くても数分で終わる状況だったのでもっと大きなデー タ・ 質の異なるデー タになると話は変わる

アプリケー ション側 普通にアプリケー ションを実装する Web かCLI か ( 地味に重要) 前処理用のリポジトリとバー ジョン番号を合わせる どのバー ジョンでどのデー タを想定していたのかが明確

この方法のメリット 各実験デー タとアプリケー ション管理がGit とMakefile だけでできる 可搬性が非常に高い デー タを操作するフェイズとアプリで微調整するフェイズが明確化 アプリケー ションで制御できる程度の実験はアプリケー ション でできる( 工数小、 手戻りコスト少) デー タの変更を行う大規模な変更を行う回数の最小化 デメリット Makefile 意外と誰も読めない 複数人でできるか未検証

No content

まとめ 前処理リポジトリとアプリのリポジトリで分離した 前処理リポジトリの成果物をアプリが利用する 目的が違うプログラムは別の場所で管理しただけ デー タは生デー タ以外は管理しない その代わりいつでも生成できるようMakefile に記述

自己紹介 名前: 515 ひかる 25 歳、 男性、 愛知県出身、 学部時代は数学をしていた だいたいTwitter(@515hikaru) にいる ここ半年くらいサー バー サイドのWeb エンジニアっぽいことをして いた