質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.50%

  • Python

    7989questions

    Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

  • Python 3.x

    6401questions

    Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。

  • Python 2.7

    1265questions

    Python 2.7は2.xシリーズでは最後のメジャーバージョンです。Python3.1にある機能の多くが含まれています。

  • Keras

    210questions

時系列データなのに、LSTMよりランダムフォレストの方が精度が高くなることはあり得る事なのでしょうか?

解決済

回答 3

投稿

  • 評価
  • クリップ 0
  • VIEW 759

kururi10

score 17

株価の分析をしているのですが、
今のところLSTMよりランダムフォレスト方が高い精度が出ています。

自分の理解だと、ランダムフォレストは
時系列を時系列だと認識できず
単なる組み合わせとして判断している
と思っているのですが、
それがLSTMより精度が高くなるのはなぜなのか
が分からずにいます・・・・

私がLSTMを使いこなせていないだけ
というのが一番の理由かもしれませんが。。。

時系列データなのに
LSTMよりランダムフォレストの方が精度が高くなる理由について
考えられることがあれば教えていただけると幸いです。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 3

checkベストアンサー

+1

https://www.slideshare.net/mobile/KeishoSuzuki/randomforest-vs-lstm

ランダムフォレストの方がパラメータチューニングしやすいこともありますから。

どちらかが得意でしょうがないデータもあるかもしれませんが、トイモデルでない限りそのようなデータに当たることは珍しいでしょう。


https://www.quora.com/Which-classifier-is-better-random-forests-or-deep-neural-networks

性質は結構異なるらしいので実践的には合わせた方が性能が出ます。


ネコの画像を見てネコだとわかるか、ネコの仕草を見てネコだとわかるか
ネコのマンガを見るか、ネコの動画を見るか、を比較してみると、どちらもそれなりにわかるのでは?

3分後になにかが起こることと、
1分経ってからさら1分経って、そしてその1分後になにかが起きる、
ということも同じです。

違いは順序にあります。
3分前にAがあって、2分前にBがあって、1分前にCがあると、Dになるということであれば、2つの手法はそれほど違いが出ません。
Aの後にBが来て、それからCが来れば次にDがくるもいうことであればLSTMが有利そうです。

累積和の閾値とか…

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/07/12 21:33

    mkgreiさん、お久しぶりです!
    ご回答ありがとうございます。

    なるほど~、合わせるという発想はなかったので勉強になりました。
    参考先のリンクもありがとうございます。
    ちょっと英語が不慣れなもので翻訳しながら読んでいます。

    「3分前にAがあって、2分前にBがあって、1分前にCがあると、Dになるということであれば、2つの手法はそれほど違いが出ません」
    というのは、
    これって時系列的に順序があるように見えるのですが、
    LSTMが有利にはならないんでしょうかね?

    キャンセル

  • 2018/07/12 21:47

    お久しぶりです。

    あまりうまく説明できていないかもしれません。

    定間隔だとなんとも言い難い、ということを言いたかったです。
    顕著に有利だと思う理由があまりないように思います。

    5分の間に、ぶれ込でABCの順番であればLSTMが有利そうです。

    他に例えば、

    5リットルの容器があって、毎分1リットル漏れていくことを考えます。
    毎分0〜3リットル確率的に流入してきていて、何リットル流入してきたかが特徴量として与えられるとします。
    予測しようとしているものが次の瞬間容器からあふれるかどうか、という場合、LSTMがうまく働くように思います。
    これに対してランダムフォレストはうまく行きにくいように思います。
    もちろん連続で3、3リットル流入した場合はランダムフォレストでも学習できますが、2、2、3と3、2、1、2も同じようにあふれるというのは学習しにくいように思います。

    もちろん本来このような問題設定に対して機械学習をするのはおかしいですが、イメージとして捉えていただければ幸いです。

    キャンセル

  • 2018/07/12 22:29 編集

    早速のお返事ありがとうございます!

    合っているかどうかわかりませんが、
    定間隔でない場合は抜けが生じる時間帯ができて
    その時間の分をランダムフォレストは加味できず
    LSTMは加味できる。
    一方、
    定間隔であれば抜けが生じないので
    その時はどちらの手法も差があるようには思えない
    という風な理解になりました。

    そうすると、ローソク足のように定間隔で
    値が刻まれるものなら2つの手法に差はない
    という感じでしょうかね。

    例え話も出してくださってありがとうございます。

    キャンセル

  • 2018/07/17 19:36

    時間だけでなく、値にも影響されるので、一概に等間隔の振動であることが差異の有無に直結する訳ではありませんが、1つの指標にはなります。

    R.Shigemoriさんの挙げられている項目も考慮すると改善するかもしれません。
    金融データの場合、移動平均が特に大事です。

    季節性については既存の金融モデルを取り入れた方が精度が向上する可能性は高いです。
    ただ、その方向性を極めると、ただの金融モデルになるので、機械学習で楽してモデルを構築するというモチベーションに反するかもしれません。

    結局機械学習モデルの利点はその柔軟性・再構築性にあるので、短期間の反復学習モデルを作ってみると良いがしれません。
    (1つのいいモデルで最初から最後まで説明できるのなら機械学習でやる必然性は薄くなります)
    サンプルが減るとランダムフォレストの方が過学習しやすいのではと期待する側面や、LSTMなら途中から初期値を引き継げる強みが出てきます。

    ---

    ご評価いただいて光栄ですが、こちらの質問サイトでの回答はあくまで趣味の範疇ですので、申し訳ありませんが金銭の絡むお話はお断り致します。

    無償だから無責任というわけではありませんが、好きな時に好きなだけやることを大事にしているので、ご理解いただけたら幸いです。

    キャンセル

  • 2018/07/17 22:31

    ご回答ありがとうございます!

    移動平均は特徴量に入れているのと、
    自分の場合はデイトレなので季節性はあまり影響していないように感じるので
    季節性は考慮していない感じですね・・・。

    なるほど、LSTMは途中から引継ぎできる点が強みで
    別のモデルからの繋ぎに使えるということなのですね。

    R.Shigemoriさんのところにも記述したのですが、
    実行したLSTMでの学習過程は一応こんな感じです

    Train on 5524 samples, validate on 1382 samples
    Epoch 1/500
    5524/5524 [==============================] - 25s 5ms/step - loss: 5.2890 - acc: 0.2444 - val_loss: 0.7459 - val_acc: 0.2590
    Epoch 2/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.8069 - acc: 0.2587 - val_loss: 0.8735 - val_acc: 0.2590
    Epoch 3/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.2372 - acc: 0.2587 - val_loss: 0.7537 - val_acc: 0.2590
    Epoch 4/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.2505 - acc: 0.2587 - val_loss: 0.7657 - val_acc: 0.2590
    Epoch 5/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.1615 - acc: 0.2589 - val_loss: 0.7552 - val_acc: 0.2590
    Epoch 6/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0657 - acc: 0.2621 - val_loss: 0.7287 - val_acc: 0.2590
    Epoch 7/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0800 - acc: 0.2717 - val_loss: 0.7214 - val_acc: 0.2677
    Epoch 8/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0767 - acc: 0.2864 - val_loss: 0.7164 - val_acc: 0.3973
    Epoch 9/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0728 - acc: 0.2822 - val_loss: 0.7140 - val_acc: 0.3958
    Epoch 10/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9702 - acc: 0.3059 - val_loss: 0.7064 - val_acc: 0.5456
    Epoch 11/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9884 - acc: 0.3219 - val_loss: 0.7003 - val_acc: 0.6035
    Epoch 12/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0324 - acc: 0.3503 - val_loss: 0.6983 - val_acc: 0.6165
    Epoch 13/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9398 - acc: 0.3756 - val_loss: 0.6882 - val_acc: 0.6621
    Epoch 14/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9705 - acc: 0.3807 - val_loss: 0.6877 - val_acc: 0.6657
    Epoch 15/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.8913 - acc: 0.4035 - val_loss: 0.6831 - val_acc: 0.6867
    Epoch 16/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9296 - acc: 0.3914 - val_loss: 0.6820 - val_acc: 0.6838
    Epoch 17/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.8784 - acc: 0.4178 - val_loss: 0.6725 - val_acc: 0.7164
    Epoch 18/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9106 - acc: 0.4222 - val_loss: 0.6679 - val_acc: 0.7315
    Epoch 19/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.7937 - acc: 0.4575 - val_loss: 0.6613 - val_acc: 0.7366
    Epoch 20/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.8684 - acc: 0.4526 - val_loss: 0.6596 - val_acc: 0.7373



    Epoch 495/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9476 - acc: 0.7493 - val_loss: 0.6178 - val_acc: 0.7410
    Epoch 496/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.6723 - acc: 0.6696 - val_loss: 0.6095 - val_acc: 0.7410
    Epoch 497/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9770 - acc: 0.6872 - val_loss: 0.5990 - val_acc: 0.7410
    Epoch 498/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.5253 - acc: 0.6895 - val_loss: 0.6039 - val_acc: 0.7410
    Epoch 499/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9107 - acc: 0.6961 - val_loss: 0.6310 - val_acc: 0.7410
    Epoch 500/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9368 - acc: 0.7820 - val_loss: 0.6162 - val_acc: 0.7410


    lossが高いのに、val_accがそれなりに高くなるのがなぜだかちょっと分かっていないのと、

    不均衡データを扱っていて
    LSTMのclass_weightに"balanced"を入れたり手動で重みを設定しているのですが
    どうもしっくりこない感じです。

    データ量が1万ぐらいしかないので
    オーバーサンプリングやアンダーサンプリングは
    ちょっと厳しいかなと感じています。

    キャンセル

  • 2018/07/17 23:46

    このaccの良さはデータの偏りからくるものではない、という認識で正しいですか?

    損失関数は何を使っているのでしょうか?
    サンプル数と相関があるように見えるのですが。

    キャンセル

  • 2018/07/18 22:53 編集

    mkgreiさん、遅れてすみません・・・。

    accの良さですが、不均衡データでclass_weightを手動で指定していて
    正しく設定できていませんでした。
    損失関数はcategorical_crossentropyを設定していました。
    また、オプティマイザはRMSpropを設定していました。



    ちょっと見直して
    class_weightを"balanced"に、
    オプティマイザをAdamに、
    その他以下のように設定してみました。

    アウトプットが2で二値分類なのでbinary_crossentropyでも
    今やってみていますが、途中経過はcategorical_crossentropyと
    そんなに変わらない感じです。

    RMSpropだとval_lossが上がっていって過学習しているように見えたので
    Adamのパラメタ指定に変えてみました。
    RMSpropのパラメタ指定も試してみます。。。

    ----------------------------------------------------------
    モデルの定義
    ----------------------------------------------------------
    n_hidden = 32 #1層目の出力の次元数。
    n_out = 2 #アウトプット
    batch_size = 50 #バッチサイズ。

    epochs = 100
    patience_limit = 30

    model = Sequential()
    model.add(LSTM(n_hidden,
    activation='tanh',
    recurrent_activation='hard_sigmoid',
    use_bias=True,
    kernel_initializer='random_uniform',
    bias_initializer='zeros',
    dropout=0.5,
    recurrent_dropout=0.5,
    return_sequences=True,
    input_shape=(n_time, n_dim)
    ))
    model.add(LSTM(16,dropout=0.5,return_sequences=True))
    model.add(LSTM(8,dropout=0.5))

    model.add(Dense(n_out,
    kernel_initializer='random_uniform',
    bias_initializer='zeros'))
    model.add(Activation("softmax"))

    model.compile(loss="categorical_crossentropy",
    optimizer=Adam(lr=0.01, beta_1=0.9, beta_2=0.999),
    metrics=['accuracy'])
    ----------------------------------------------------------
    モデルの学習
    ----------------------------------------------------------
    history = model.fit(x_train, y_train,
    class_weight="balanced", #ここでクラスウェイトを指定
    batch_size=batch_size,
    epochs=epochs,
    validation_data=(x_test, y_test),
    verbose=1,
    shuffle=False #シャッフルしないようにFalseに
    )





    結果

    Train on 5524 samples, validate on 1382 samples
    Epoch 1/100
    5524/5524 [==============================] - 57s 10ms/step - loss: 0.6085 - acc: 0.7902 - val_loss: 0.9451 - val_acc: 0.7410
    Epoch 2/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.7805 - acc: 0.5932 - val_loss: 0.8033 - val_acc: 0.7410
    Epoch 3/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.7652 - acc: 0.7411 - val_loss: 0.6533 - val_acc: 0.7410
    Epoch 4/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.6823 - acc: 0.7312 - val_loss: 0.6348 - val_acc: 0.7410
    Epoch 5/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.6639 - acc: 0.7409 - val_loss: 0.6313 - val_acc: 0.7410
    Epoch 6/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.6618 - acc: 0.7413 - val_loss: 0.6291 - val_acc: 0.7410
    Epoch 7/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.6603 - acc: 0.7411 - val_loss: 0.6275 - val_acc: 0.7410
    Epoch 8/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.6579 - acc: 0.7411 - val_loss: 0.6268 - val_acc: 0.7410
    Epoch 9/100
    5524/5524 [==============================] - 55s 10ms/step - loss: 0.6591 - acc: 0.7413 - val_loss: 0.6259 - val_acc: 0.7410
    Epoch 10/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.6581 - acc: 0.7411 - val_loss: 0.6253 - val_acc: 0.7410



    Epoch 97/100
    5524/5524 [==============================] - 53s 10ms/step - loss: 0.6568 - acc: 0.7411 - val_loss: 0.6228 - val_acc: 0.7410
    Epoch 98/100
    5524/5524 [==============================] - 55s 10ms/step - loss: 0.6569 - acc: 0.7409 - val_loss: 0.6218 - val_acc: 0.7410
    Epoch 99/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.6582 - acc: 0.7409 - val_loss: 0.6228 - val_acc: 0.7410
    Epoch 100/100
    5524/5524 [==============================] - 54s 10ms/step - loss: 0.6557 - acc: 0.7413 - val_loss: 0.6231 - val_acc: 0.7410

    キャンセル

  • 2018/07/18 22:58 編集

    あれ・・・上手く学習できてないですね・・・

    すいません、早く返信しなきゃと思って
    ちょっと焦ってそのまま結果を載せてしまいました。

    もう少し見直してみます。

    キャンセル

  • 2018/07/19 03:08 編集

    うーん、上手く学習が進まないというより
    層をシンプルにしたり複雑にしたりしても
    なんだかclass_weight="balanced"が効いてないようです。

    それで一方のクラスばかりを評価した結果
    acc: 0.7902
    とかっていう高い数値が始めから出ているようなのです・・・。

    ちなみに、訓練データとテストデータに分割する前の
    データの偏り方は
    負例 -> 5119
    正例 -> 1787
    です。

    これでclass_weight="balanced"を指定しても
    負例を過剰に評価してしまいます。

    "balanced"が効かないなどのご経験や
    上記のコードでお気づきのことがあれば教えて頂けると幸いです。。。

    キャンセル

  • 2018/07/19 06:44

    lossとaccの乖離が起きている理由は、データが偏っているから、と考えてよろしいでしょうか。

    偏りがあるデータを処理するには、2つのアプローチがあるはずです。

    一つは損失関数自体に手を加えることです。
    https://stackoverflow.com/questions/35155655/loss-function-for-class-imbalanced-binary-classifier-in-tensor-flow#answer-38912982
    https://datascience.stackexchange.com/questions/13490/how-to-set-class-weights-for-imbalanced-classes-in-keras
    そうすれば損失関数への寄与が補正されます。
    ただし、この方法だとひどく偏ったデータにおいて、バッチ内に優勢データだけしかない状況が起きるかもしれません。
    その結果バッチサイズをそれなりに大きくしたときにまともに学習できる場合があります。
    その分過学習を少ししやすくなります。

    もう一つの方法は、バッチを取り出す方法を工夫することです。
    この場合epochというのが従来の意味とは少し異なってしまいます。
    バッチ内に同じデータを複数含みうるので、やはり過学習に気を配る必要があります。

    ひどく偏ったデータセットいえば、以下のようなものがあります。
    https://www.kaggle.com/c/porto-seguro-safe-driver-prediction/discussion/44629
    DenoisingAutoEncoderを使って教師なし学習を最初に行うことで精度を出したものです。
    参考になるかもしれません。

    キャンセル

  • 2018/07/20 22:59 編集

    選択肢を色々教えて頂き、ありがとうございます。

    >lossとaccの乖離が起きている理由は、データが偏っているから、と考えてよろしいでしょうか。

    うーん、どうなんですかね・・・。
    上記のコメントの1回目の結果は
    5524/5524 [==============================] - 25s 5ms/step - loss: 5.2890 - acc: 0.2444 - val_loss: 0.7459 - val_acc: 0.2590
    から始まっていて、
    これは偏っているのを上手く修正できていないことは
    間違いないと思います(自分の理解の中では)。

    ただ、上記のコメントの2回目の結果は
    5524/5524 [==============================] - 57s 10ms/step - loss: 0.6085 - acc: 0.7902 - val_loss: 0.9451 - val_acc: 0.7410
    から始まっていて、
    これはlossとaccの乖離はあまり起きていないように見えるので
    class_weight="balanced"
    と指定したのが効いているのかなと思っていました。

    ただ、学習が進んでいないのと、始めからacc: 0.7902で精度が高すぎることから
    やっぱり効いていないのかなと
    どちらか分からなくなりました。


    損失関数自体に手を加えることで教えて頂いた
    2番目のリンクにclass_weightの事をsklearnでやっていたので
    しっくりきました。
    ここに書いてある
    class_weights = class_weight.compute_class_weight('balanced',
    np.unique(y_train),
    y_train)
    を試してみましたが、
    どうも
    model.fit (x_train, y_train, class_weight="balanced")

    model.fit (x_train, y_train, class_weight=compute_class_weightの結果のclass_weights)
    では
    ほぼ似たような結果になりました。


    教師なし学習の方は全くやったことがないので
    こちらは基礎からやらなきゃなあと思っています。
    教えて頂いたサイトはお気に入りに追加させていただきました。

    色々とお返事をくださってありがとうございます^^

    キャンセル

  • 2018/07/20 23:54

    偏りがあるデータでは、うまい評価方法を見つける方が大変であることが珍しくありません。

    その際に、CNNのような難しいものではなく、線形モデルを試す方が手っ取り早いことが多い気がします。
    線形モデルではデータに強く依存するので、交差検定を行うことである程度の感覚がつかめるような気がします。

    データを取り扱う方針がたってからモデルに力を入れる方がモヤモヤ感が減るような気がします。

    キャンセル

  • 2018/07/21 21:35

    線形モデルですか・・・
    ランダムフォレストの後に、scikit-learnのsvm.SVCを試したのですが、
    ランダムフォレストほどの汎化性能が得られなかったので
    やっぱり株価の時間的要素がもし必要だとすれば
    RNNだろうなあと思って
    なんとなくで使っていました。

    まだ詳しく理解した上で使ったわけではないので
    線形モデルももう少し深く勉強したいと思います。

    特徴量が4000ぐらいあるので、
    データを取り扱う方針というのをどう立てていくのかが
    想像できないのですが、

    交差検定を行った後はmkgreiさんなら
    例えばSVCとかでどういう風にその方針を立てていかれますか?

    キャンセル

  • 2018/07/22 02:58

    あ、すいません、
    svm.SVCのカーネルにRBFカーネルを使ってました。
    非線形モデルでやってました。。。

    キャンセル

  • 2018/07/22 23:46

    ちょっと色々聞きすぎましたね・・・
    すみません。
    色々とありがとうございました!

    キャンセル

  • 2018/07/23 07:20

    偏りが大きいデータに対しては、accのほかrecallやprecisionなども見てみるとよいかもしれません。

    https://www.kaggle.com/rspadim/gini-keras-callback-earlystopping-validation

    このようにコールバックに仕込めばほぼ任意の評価関数を入れることができます。

    キャンセル

  • 2018/07/23 15:23 編集

    他の視点からのアドバイスありがとうございます!

    まだ基本的な評価関数のところしかやっていないのですが、
    教えて頂いたリンク先のように
    色々と定義もできるようになっているのですね。


    一応、僕としてはprecisionを最大限良くすることを目標に
    今までやってきました。
    recallは50%程度で良く、取りこぼしがあっても構わないので
    とにかく判断したものは高い確率で正しくあってほしい
    という指針を立ててやっている感じです。

    一応今のところ一番上手くいっているのは(ましなもの)
    検証データでこんな感じです。

    -------------------------------------------
    [[247 | 145]
    [ 66 | 63]]
    -------------------------------------------
    class | precision | recall | f1-score | support

    0 | 0.79 | 0.63 | 0.70 | 392
    1 | 0.30 | 0.49 | 0.37 | 129

    avg / total | 0.67 | 0.60 | 0.62 | 521

    これが今のところ一番いいprecisionでして、
    1の方のprecisionが0.3前後ぐらいになります。

    1の方が少数派のクラスで、
    このprecisionを可能な限り上げるのが目標です。

    これ以上がまだまだです・・・。

    キャンセル

+1

LSTMはベースが時系列モデルなので、モデルに適合するようにデータの事前処理をしたり、データの傾向に合わせてモデルを定義しないと期待した性能が出ません。一方、ランダムフォレストはツリーで表されるモデルを学習過程で構築する手法なので、ハイパーパラメーターの設定を失敗しなければそれなりの結果が得られます。
詳細不明なため、確信的なことは言えませんが、モデルそのものに問題があるか、データの事前処理が不十分である可能性を疑ったほうがいいかと思います。
とりあえず思いつくチェックポイントは以下です。
1.定常性の有無
2.自己相関の有無、移動平均との相関の有無
3.階差モデルの適用の適否
4.季節的周期性
5.外部要因組み込みの適否
ざっくりでいいので時系列モデルの理論を確認して、kerasで実装するとどうなるのかを踏まえて見直しするといいかと思います

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/07/17 22:22

    ご回答いただき、ありがとうございます!
    定常性や階差についてはある程度考慮したと思ってはいたのですが、
    きちんとできているかどうか自信がありません。。。
    教えて頂いた他のチェックポイントも含めて
    もう一度見直してみたいと思います。

    実行したLSTMでの学習過程は一応こんな感じです

    Train on 5524 samples, validate on 1382 samples
    Epoch 1/500
    5524/5524 [==============================] - 25s 5ms/step - loss: 5.2890 - acc: 0.2444 - val_loss: 0.7459 - val_acc: 0.2590
    Epoch 2/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.8069 - acc: 0.2587 - val_loss: 0.8735 - val_acc: 0.2590
    Epoch 3/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.2372 - acc: 0.2587 - val_loss: 0.7537 - val_acc: 0.2590
    Epoch 4/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.2505 - acc: 0.2587 - val_loss: 0.7657 - val_acc: 0.2590
    Epoch 5/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.1615 - acc: 0.2589 - val_loss: 0.7552 - val_acc: 0.2590
    Epoch 6/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0657 - acc: 0.2621 - val_loss: 0.7287 - val_acc: 0.2590
    Epoch 7/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0800 - acc: 0.2717 - val_loss: 0.7214 - val_acc: 0.2677
    Epoch 8/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0767 - acc: 0.2864 - val_loss: 0.7164 - val_acc: 0.3973
    Epoch 9/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0728 - acc: 0.2822 - val_loss: 0.7140 - val_acc: 0.3958
    Epoch 10/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9702 - acc: 0.3059 - val_loss: 0.7064 - val_acc: 0.5456
    Epoch 11/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9884 - acc: 0.3219 - val_loss: 0.7003 - val_acc: 0.6035
    Epoch 12/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 3.0324 - acc: 0.3503 - val_loss: 0.6983 - val_acc: 0.6165
    Epoch 13/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9398 - acc: 0.3756 - val_loss: 0.6882 - val_acc: 0.6621
    Epoch 14/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9705 - acc: 0.3807 - val_loss: 0.6877 - val_acc: 0.6657
    Epoch 15/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.8913 - acc: 0.4035 - val_loss: 0.6831 - val_acc: 0.6867
    Epoch 16/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9296 - acc: 0.3914 - val_loss: 0.6820 - val_acc: 0.6838
    Epoch 17/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.8784 - acc: 0.4178 - val_loss: 0.6725 - val_acc: 0.7164
    Epoch 18/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9106 - acc: 0.4222 - val_loss: 0.6679 - val_acc: 0.7315
    Epoch 19/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.7937 - acc: 0.4575 - val_loss: 0.6613 - val_acc: 0.7366
    Epoch 20/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.8684 - acc: 0.4526 - val_loss: 0.6596 - val_acc: 0.7373



    Epoch 495/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9476 - acc: 0.7493 - val_loss: 0.6178 - val_acc: 0.7410
    Epoch 496/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.6723 - acc: 0.6696 - val_loss: 0.6095 - val_acc: 0.7410
    Epoch 497/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9770 - acc: 0.6872 - val_loss: 0.5990 - val_acc: 0.7410
    Epoch 498/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.5253 - acc: 0.6895 - val_loss: 0.6039 - val_acc: 0.7410
    Epoch 499/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9107 - acc: 0.6961 - val_loss: 0.6310 - val_acc: 0.7410
    Epoch 500/500
    5524/5524 [==============================] - 18s 3ms/step - loss: 2.9368 - acc: 0.7820 - val_loss: 0.6162 - val_acc: 0.7410


    何かお感じになることとかありますでしょうか?

    また、一番苦心しているのが不均衡データであることなのですが、
    LSTMのclass_weightに"balanced"を設定したり手動で重みを入れたりしていますが
    その調整が難しいです。
    データ量が1万ぐらいしかないので
    アンダーサンプリング・オーバーサンプリング
    は厳しいと考えていて、weightを調整するしかないかなと思っています。

    キャンセル

0

どんな使い方をしているかにもよります。うまく動いていない可能性もあるでしょうし。モデルの設計が悪いとか、LSTMを学習させるのに十分なデータの蓄積がないとかもありえます。

また、ランダムフォレストは普通に使っても過学習っぽくなるのも特徴なので、汎化性能を見ないでスコアを出すと評価を見誤ります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/07/12 21:01

    精度と書くとわかりにくいですね、もう少し詳しく書かないといけなかったと
    気づかされました^^;
    precisionが高いことを目標としているのですが、
    ランダムフォレストの方が高かったのと、
    期間的に全くかぶりのないテストデータでの汎化性能も高かったので
    疑問でした。
    確かにおっしゃるとおり設計が悪かったり
    データが足りなかったりもする感じかもしれないですね。。。
    簡単なところからもう少し1つ1つ進めてみたいと思います。
    ご回答ありがとうございます^^

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.50%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る

  • Python

    7989questions

    Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

  • Python 3.x

    6401questions

    Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。

  • Python 2.7

    1265questions

    Python 2.7は2.xシリーズでは最後のメジャーバージョンです。Python3.1にある機能の多くが含まれています。

  • Keras

    210questions

  • トップ
  • Pythonに関する質問
  • 時系列データなのに、LSTMよりランダムフォレストの方が精度が高くなることはあり得る事なのでしょうか?