pythonで実行時間を測定しつつ時間も取得したい
実行時間を測定するには?
KaggleMasterのアライさん著・Kaggleコード遺産でおなじみ timer を使うのが便利です! いつもお世話になってます😊
from contextlib import contextmanager from time import time # https://qiita.com/kaggle_master-arai-san/items/d59b2fb7142ec7e270a5#timer をちょっといじったやつ @contextmanager def timer(logger=None, format_str='{:.3f}[s]', prefix=None, suffix=None): if prefix: format_str = str(prefix) + format_str if suffix: format_str = format_str + str(suffix) start = time() yield d = time() - start out_str = format_str.format(d) if logger: logger.info(out_str) else: print(out_str)
あとは、測りたいコードの部分を with 区でくくります。かんたんで便利ですね!
with timer(prefix='foo'): # run some function sleep(10)
しかし timer は print で時間を表示してくれるものの時間の計測が timer 側で閉じてしまっているので、計測後に実行時間を取得することができません。たとえば実行時間を console に出しつつデータフレームなどに保存したい〜というときなど、実行時間自体にアクセスしたいですね。
Classを使って書き直す
これを解決する一つの方法が timer 自体に時間などを保存できるようにする方法です。timer ごとに値を属性として保存するため funcition だったものを Timer class に書き直しました
class Timer: def __init__(self, logger=None, format_str='{:.3f}[s]', prefix=None, suffix=None, sep=' '): if prefix: format_str = str(prefix) + sep + format_str if suffix: format_str = format_str + sep + str(suffix) self.format_str = format_str self.logger = logger self.start = None self.end = None @property def duration(self): if self.end is None: return 0 return self.end - self.start def __enter__(self): self.start = time() def __exit__(self, exc_type, exc_val, exc_tb): self.end = time() out_str = self.format_str.format(self.duration) if self.logger: self.logger.info(out_str) else: print(out_str)
enter / exit を定義して with のときの動作を書いているだけです。
これを使うと一度定義した timer に start_at / duration などの属性がひも付きますのであとから時間を取り出すことが可能です。
hoge_timer = Timer() with hoge_timer: sleep(10) print(hoge_timer.duration)
また今まで通り timer として使いたいよ〜というニーズもあると思います。その場合以下のように function を定義しておけば OK です
def timer(logger=None, format_str='{:.3f}[s]', prefix=None, suffix=None, sep=' '): return Timer(logger=logger, format_str=format_str, prefix=prefix, suffix=suffix, sep=sep)
scikit-learn の grid-search を sample_weight と同時に使用する場合の問題点
以下の記事によると scikit-learn の BaseSearchCV の実装には問題があり意図しない動作をしている可能性がある、とのことが報告されています。いつも scikit learn を使う身としては気になる話題なので、少し詳しく見ていきます。
BaseSearchCVと sample weight の問題点
記事中で指摘されている問題点をまとめると以下のようになります。
BaseSearchCVを継承した CV class において, 各 CV ごとの学習自体はsample_weightが適用される- しかし validation set に対する score の計算では
sample_weightが適用されない- 具体的には https://github.com/scikit-learn/scikit-learn/blob/0.24.0/sklearn/model_selection/_validation.py#L620 このあたり
- 例えば pos / negative にそれぞれ 1 / 1000 の重みを与えると本来的の重み付きスコアは 0.999 になっていてほしい。
- だが実際には重みが適用されないので 0.5 のままになる。
検証
試しにさっくり手元の環境でもやってみました。使用するバージョンは最新の scikit-learn==0.24.0 です。
cv = np.array([0, 0, 1, 1]) X = np.ones(shape=(4, 1)) y = np.array([1, 0, 1, 0]) fold = np.array([ [[0, 1], [2, 3]], [[2, 3], [0, 1]], ]) # negative に対して weight を 999 / 1000 で与える sample_weight_for_zeros = [ 1, 999, 1, 999 ] # grid search で学習. 入力が const の linear model なので positive の割合が weight になるはず. grid = GridSearchCV( estimator=LogisticRegression(), param_grid={ 'random_state': [42] }, scoring='accuracy', cv=fold, return_train_score=True ) grid.fit(X, y, sample_weight=sample_weight_for_zeros)
上記の設定だと sample_weight は negative に多く設定されています。したがって重み付きのスコアは 0.999 になっていてほしいです。
scikit-learn に実装されている accuracy では sample_weight arg が用意されていて、手動で計算すると以下のようになります.
from sklearn.metrics import accuracy_score # 本当は 0.999 になってほしい accuracy_score(y, grid.predict(X), sample_weight=sample_weight_for_zeros) # 0.999
しかし実際には 0.5 になっています
# 実際には weight がないときと同じスコアになる grid.best_score_ # 0.5
sample_weight が適用されていないのは validation でのスコア計算の部分で, 学習自体は意図した動作です.
# 予測値は negative が 0.999 が出力される (学習自体には sample_weight が適用されているため.) grid.predict_proba(X) array([[0.99900002, 0.00099998], [0.99900002, 0.00099998], [0.99900002, 0.00099998], [0.99900002, 0.00099998]])
まとめ
- 学習自体は sample_weight つきで期待通り実行されるが, 算出される score は sample_weight を無視して計算されている.
- GridSearchCV や RandomSaerchCV など, BaseSearchCV を継承したパラメータサーチでは score の意味で最も良いパラメータが選ばれる.
- したがって, sample_weight を考慮して最も良い parameter が知りたい場合でも, sample_weight を無視したスコアの意味でもっとも良いモデルが選ばれるため、問題.
sample_weight を使っていてかつ sciki-learn の枠組み上でパラメータ最適化を行う場合には注意したほうが良いかもしれません。
以下使用したコードです。
SGDにおける「順番」の問題
この記事は atma Advent Calendar
の 12/1 分の記事です。大分遅くなってしまいましたがこの記事では Stochastic Gradient Descent における順番が与える影響とそれにまつわる論文をいくつか紹介したいと思います。
Stochastic Gradient Descent とはなにか
Stochastic Gradient Descent (SGD) は連続変数に対する最適化手法の一つで、ベースとなっているのは勾配法 (Gradient Descent) です。ここで以下の説明のためにいくつか用語を定義します。まず考える最適化問題は以下のように関数 $f_n$ の和で表される関数 $F$ の最適化です。
$$ {\rm minimize}_{x \in \mathbb{R}^d} F(x) := \sum_{n=1}^N f_n (x) $$
こういう関数は例えば機械学習・統計分析で頻出です。というのも $\sum$ の部分というのは期待値の計算とみなせるので、期待値を取ったなにかを最大化・最小化する問題もこの形式で記述できるためです。
また尤度関数の最大化問題も対数を取ってあげると上記の形式に帰結することができます。この場合 $N$ はデータの数に相当します。典型的なニューラルネットワークや線形モデルによる学習はすべてこれに該当する問題です。
最適化手法・勾配法では $i$ 番目の iteration において、今の最適化変数 $x_i$ の周りで計算した目的関数全体の勾配 $\nabla F$ を用いて, 全体の勾配の意味で最も下がる方向へ更新します。 $$ \begin{aligned} x_{i + 1} &= x_i - \alpha_i \nabla F(x_i) \\ &= x_i - \alpha_i \sum_{n=1}^N f_n(x_i) \end{aligned} $$
ここで $\alpha_i \in \mathbb{R}$ は $i$ 番目の更新で用いるステップサイズです。
SGD では全体の勾配の代わりに適当なインデックス $k \in \{1, 2, ... N\}$ を選んでそれを用いて更新を行います。すなわち以下のとおりです。
$$ x_{i + 1} = x_i - \alpha_i \nabla f_{k}(x_i) $$
更新時にはただひとつの勾配を計算すれば良いだけなので、GD に比べ一回あたりの更新の計算量が小さいのが特徴です。特に $N$ が膨大な値になる場合には GD では都度 $N$ 回の計算が必要になるのに比べて有利です。一方で、都度ただひとつのデータに対しての勾配しか計算しませんので、目的関数全体に対する正確な勾配との乖離が起こり、収束は遅くなります。
SGD における「順番」の問題
前置きが長くなってしまいましたが、ここからが本題です。先ほど SGD では毎回更新に使うデータの index $k$ を選ぶ、という話をしました。
ではこの $k$ はどのように選ぶのが良いのでしょうか。
まずナイーブに思いつくのは $k$ を $1, 2, \cdots, N, 1, 2, \cdots$ の用に順繰りに選んでいく方法です。この方法を以下では Cyclic と呼びます。
他のやり方は都度 ${1, 2, ..., N}$ を取りうる一様な分布から一つサンプルする方法です。この方法を以下では Random と呼びます。
$n$ ごとに重みをつけて偏りがある分布からサンプルする方法 (Importance Sampling) という方法もありますが以下では確率はいじらずに、一様な分布からサンプリングする方法に絞って議論していきます。
さらに上記の中間のような感じで、都度ランダムにサンプルはせず $N$ 回に1回だけ順番を入れ替え(シャッフル) して、そのあとはその順番通り選んでいく方法もあるでしょう。これを RR: Randomly-ReShuffle と呼びます。
実はやり方で収束速度が違う
この3つの方法、どれも各 $n$ が選ばれる確率は $i \to \infty$ では $1/N$ で同じなのですが、面白いことに収束レートは違うことが経験的に知られています。
Curiously Fast Convergence of some Stochastic Gradient Descent Algorithms 2009 では Logistic Regression に対して、上記3つの方法を用いた場合の収束レートを CCAT Dataset で実験した様子が報告されていて、Random < Cyclic < RR の順番で収束が早くなっています。更に Cyclic / Shuffle の場合には理論研究で得られている収束レート $t^{-1}$ よりも早く収束しています。
SGD に対する理論研究では $k$ の選び方は、前後の関係によらず独立にサンプルされたものである、という立場にたって分析されています。一方で Cyclic / Shuffle は前後に依存関係があるという違いがあり、この違いがレートの違いを生んでいるとして、選び方に対してより分析の余地があるのではないか? とコメントされています。
この問題に $f_n$ が二次関数で定義されるもので、一般の凸関数に対する議論ではないという限定的な課題設定ではあるものの、理論的な証明を与えたものが Why Random Reshuffling Beats Stochastic Gradient Descent です。
証明の気持ち
証明のアイディアは Cyclic や RR では $N$ 回ごとに必ず1度すべての関数 $f_n$ を使って計算が行われる、という点です。この性質を利用して各 $N$ 回の更新ごとの場所を $x_j$ のように定義して $x_j$ と $x_{j+1}$ の位置関係に対して成り立つ収束レートを元に、 Polyak-Rupper Averaging と呼ばれる方法で使われているような「過去 k 回の平均値を使う」ことで RR の方がレートとして早くなることを証明しています。
ライブラリでの実装はどうなっている?
順番に関する実装ですが、pytorch や keras では普通に実装するとデータセットを1度全部見るまでは順番が固定で取り出して、一周するごとに順番を並び替える用になっています。これはまさに Randomly Reshuffle ですね。
まとめ
- SGD には順番をどう選ぶか、という問題が存在しています。
- 特定の関数に対してではあるが RR が Random よりも早いという証明を与えた論文を紹介しました。
最後論文をガッツリ紹介しようと思っていたのですが、内容も詳しく追えておらず(最適化特有の数式 & 僕のパワーのなさ…) アイディアの一欠片ぐらいしかご紹介できませんでした。が、こういう問題意識や、その周辺の議論もあるんだなーというのを知っていただいて、あわよくば最適化おもろいな、と興味を持っていただけたのであれば幸いです。
参考文献
pyspark (mmlspark) で LightGBM 使うときのメモ
Spark 上で Machine Learning を行うためのツールを Microsoft が MMLSpark (Microsoft Machine Learning for Apache Spark) というパッケージで公開しています。
https://github.com/Azure/mmlspark
この中に lightGBM on spark も含まれており python を使って spark 上で lightGBM の学習を回すことができます。 これを使っていて、わからなかったこと・困ったことがいくつかありましたので、調べたメモ書きを共有します。
mmlspark での LightGBM のパラメータ指定
mmlspark の lightGBM と本家本元の lightGBM のパラメータは引数の名前が違います。本家の lightGBM では無限にエイリアスが貼られているので雰囲気で名前を与えても動きますが mmlspark はそうではありません。
パラメータに関するドキュメントが公式にあればよいのですが見当たらないようです (おそらく sコードを読んで追いかけろということ?)。以下 Classifier の方に関してざっと作ってみました。本家の方では fit の方で指定するパラメータも __init__ で指定するようになっていることに注意してください。
class LightGBMClassifier: def __init__(self, baggingFraction=1.0, baggingFreq=0, baggingSeed=3, boostFromAverage=True, boostingType='gbdt', categoricalSlotIndexes=None, categoricalSlotNames=None, defaultListenPort=12400, earlyStoppingRound=0, featureFraction=1.0, featuresCol='features', groupCol=None, initScoreCol=None, isProvideTrainingMetric=False, labelCol='label', labelGain=[], lambdaL1=0.0, lambdaL2=0.0, learningRate=0.1, maxBin=255, maxDepth=-1, maxPosition=20, minSumHessianInLeaf=0.001, modelString='', numBatches=0, numIterations=100, numLeaves=31, objective='lambdarank', parallelism='data_parallel', predictionCol='prediction', timeout=1200.0, useBarrierExecutionMode=False, validationIndicatorCol=None, verbosity=1, weightCol=None): """ Args: # tree 成長に関わるパラメータ numIterations: 大事. learning rate との兼ね合いで決まります. rate を小さくすると iterations は多くしましょう. learningRate: 大事. 0.3 ~ 0.1 ぐらいが普通. 小さくすると精度は上がる傾向があるけれど時間もかかります maxDepth: 3 ~ 8 ぐらい. 問題によって最適な値が違うことが多いですが 3=8位を設定しておけば大概はOK。 # 正則化 lambdaL1: lambdaL2: L1/L2 正則化. 大きくすると木の成長がゆっくりになります (極端な予測を持つ葉ができにくくなる) numLeaves: 葉の数. 2 ** max_depth より小さくすることで木の成長をゆっくりにできる # ロバスト性 / 正則化 baggingFraction: bagging (subsamples) の割合 0 ~ 1 featureFraction: columns のサンプリング割合. 0.3 / 0.5 / 0.7 とかを使うことが多いです. baggingFreq: bagging を実行する頻度. たとえば 10 とすると tree を 10 個作るごとに bagging を実行します baggingSeed: bagging でランダムに選ぶときの seed 値 boostingType: `"gbdt"` で問題ないと思います minSumHessianInLeaf: カジュアルに言うと一つの予測集合の最小の大きさみたいなものです。(Objective="mse" のとき一致します) 小さすぎると細かい粒度での分割を許可してしまうのである程度大きい値を指定してあげても良いと思いいます。 (集合サイズなので学習させるデータの大きさに依存して良い値が変わってくるのに注意) # eval set 作るとき validationIndicatorCol: ちょっと指定のしかたが lightGBM (python) と違っていて, evaluation set を作りたい場合, fit にわたすデータに valid data を concat して train or valid を表す 0-1 の flag を `validationIndicatorCol` に指定します. earlyStoppingRound: 指定された回数以上 objective が改善しないときに学習を中断します. 50 とか 100 を指定することが多いです。 """
References
2: evaluation set をつかって early stopping をする
学習させるとなると early stopping を使いたいでしょう。本家 lightGBM では fit を呼び出す際に eval_set に validation 用のデータを渡せば early stopping を行ってくれますが mmlspark の場合そうではなく若干クセがあります。これも公式ドキュメントに記載が何もなかったので作ってみました。大きな流れは以下のとおりです
- validation かどうかのフラグをデータにもたせる
- evaluation data を train data と merge (pyspark method でいうと union) する
validationIndicatorColに作ったフラグのカラムを指定する
python api の流儀と異なっているので注意してください。
Reference
- https://github.com/Azure/mmlspark/issues/435
- https://github.com/Azure/mmlspark/blob/master/src/main/scala/com/microsoft/ml/spark/lightgbm/LightGBMParams.scala#L310
Sample Code
train_df = # (some pyspark dataframe for train) eval_df = # (me too. for test) # 1. `"validation"` column にこのデータが train / eval であることを表すフラグを作る # python api の用に fit で eval_set= とは渡さないことに注意 _train = train_df.withColumn('validation', F.col('target') * 0)[['target', 'feature', 'validation']] _test = eval_df.withColumn('validation', F.col('target') * 0 + 1)[['target', 'feature', 'validation']] input_df = _train.union(_test) from mmlspark.lightgbm import LightGBMClassifier params = { 'numIterations': 200, 'learningRate': .2, 'maxDepth': 7, 'lambdaL2': 1., 'numLeaves': 31, 'baggingFraction': .7, 'featureFraction': .5, 'baggingFreq': 3, 'minSumHessianInLeaf': 100. } # 2. `validationIndicatorCol` を指定する clf = LightGBMClassifier( validationIndicatorCol='validation', earlyStoppingRound=50, labelCol='target', featuresCol='feature', **params ) # 3. call `fit`. (fit のときにはたんに事前に作った data-frame を入れる) clf = clf.fit(input_df)
note
validation data での objective 及び metric 評価は spark 上で分散計算されないようです。そのため training data と同じぐらい大きいデータセットを validation に指定すると速攻で Out-Of-Memory になりますので注意してください。
