RE：不動産取引価格 Public 1st place Private 3rd place Solution
目次
1. どんなコンペか
今回出たのは前記事でも紹介したこちらのコンペです
不動産の取引価格を予測するものですね。Reと書いてあるのは、評価指標がRMSEからRMSLEに変わったからです。
RMSEが外れ値というか過剰に大きい値に過敏に反応する指標であることは、どこかしらで述べている事実だと思います。
探してみたらどこにもいい記事がなかったですが、実際前回のコンペはおみくじ要素とか出てなかなかだったと思うので、RE：は非常にありがたかった。
2. 解法概要
今回は俺人さんという方とチームマージして臨みました。締め切り1週間前くらいになって、どうしても高順位に行きたいなと思い、精力的に活動している俺人さんに急遽声をかけさせていただきました。若造に協力してくれて本当にありがたいです。
こちら俺人さんの記事です
実際には俺人さんとsubmitを単純平均して提出しているため、こちら側のsolutionをここに書きたいと思います。
簡単な概要は以下の通りです。
またこちらでsource cordは公開しています。
https://github.com/arenzero/real_estate_comp
これで分かれば幸いですが、かなり書きなぐっている内容なので、次のところで詳細に記述したいと思います。
3. 特徴量設計について
基本的な特徴量はもうだいたいコードを見ていただければ簡単にわかるものしか作ってないです。特筆すべきものがあるとすれば
- 面積：2000平方メートル以上のものは2000にするのは正確じゃないと思ったため、それだけあるかないかの[0,1]カラムを用意した。
- 経過年月：取引年から建築年を引いて、経過年月を算出した。よく効いたけど、風の噂では2項演算特徴量は入れても意味ないことを聞いたので錯覚だったかもしれない
- published dataの活用：単に同じカテゴリでのH31価格のmean,median,count,stdをマージしたものがMerge1だった。しかし途中で取引年を考慮したmergeを実行し、それがMerge2。このmerge2はよく効いた。当たり前かもしれないが、取引時点によっては平均価格帯などが変わる。また価格を面積で割り、1平米単価としたものもMerge1では入れている
くらいです。
publishedのmergeについては、正直全く意味がないかもしれないと思っていました。カテゴリの分岐が数字に変わっただけでは？と思っていましたが、解法をいろいろとみてみるとtarget encodingも効いていることを発見したため、なるほどカテゴリをラベルエンコードするよりターゲットエンコーディングのように数字にするのも一手なのだと知りました。（今更
4. モデルについて
基本はlightgbmをメインで回していました。simpleなDNNも使いたかったのですが、間に合わずお粗末なXGBoostとCatBoostを入れて終わりました。1位解法を見ると、objectiveを変えることで少し効いたらしいことがあり、それには面喰いました…
5. チームマージよる効能
正直1人では順位がかなり下だったと思います。どうやら自分のsubの結果だけ見ると3位は変わらないみたいですが、俺人さんからはアイデアをいくつかもらったことがよかったです。モチベーション的なところでもすごくよかったので、感謝しています。
また、チームマージをすることによってコードや自分の解法を整理しなければならず、それも一つよかったことでした。
ただし、ちょっとしたデメリットはありました。それは一日のsub回数がチームで5subに変わるということです。
ですので、最後のところでチームマージをすべきだと思います。（probspaceなら
6. お疲れさまでしたぁ
いや本当にお疲れさまでした。業務でも実は使うかもしれないと思い参加した結果、かなり有益なものが得られて非常によかったです。良コンペでした。
ありがとうございました。
初めて真面目に取り組んだコンペで疑問に思ったこと（ProbSpace）
はじめに
僕は現在Probspaceというデータ分析プラットフォームにおける「Re：不動産取引価格予測」というコンペに参加しています。
今までもマネーフォワードのコンペやkaggleのコンペに参加したり、つまみ食い程度にやっていたのですが、始まってすぐに高順位に行けたことから少しモチベーションが上がったので、今回かなり真面目に取り組んでます。
あ、一応現時点では残り9日だそうなので、興味ある人はチームマージなりなんなりしましょ。
どんなコンペ？
このコンペは土地の面積や場所から不動産の価格を予測したいというコンペ。かなりわかりやすいデータで、取扱しやすいです。
さて、このコンペ、僕はLightGBMでモデルを組んでいるのですが、非常に不思議だなと思うところがありました。
1つ目のpipeline
pipelineを作るとき、初めに以下のようなものを作りました。
- ハイパーパラメータの選択肢を作成
- trainデータを使って、LightGBMのcvでearly_stoppingをかける
- 2.の動作を各種ハイパラで行い、最もスコアがよかったハイパラを決定する
- 確定したハイパラと、early_stoppingがかかったround数を用いて全データで学習
- できたモデルでtestデータの推論を行う
まあ割と素直なものだと思います。
しかしここで、どうやらsignateの土地コンペがこのコンペの参考になると聞きました。そこで以下の解法を拝見しました
こちらの一位解法にはこのように書いてありました。
LightGBM（5fold CVの各モデルのアンサンブル）
あれ、CVしたときの各モデルの予測をアンサンブルすることってもしかして必要？？
実は前にも考えたことがあったので、以下のようなpipelineも作ってみました
2つ目のpipeline
このような形でtrainデータをCVする中で各foldごとにハイパラの調整とearly_stoppingを行いました
そして5つのモデルができたので、5つのモデルそれぞれにtestを入れ、5つの予測が出てきます。
5つの予測を、各foldの精度の逆数を取ってweight averageをしました。
そして、上記のpipelineを単純な5foldのCVの内側でNestするように実行してみると、どうやら1つ目の方が精度がいいそうです。LBのスコアもやはり1つ目の方が精度がいいので、では1つ目がいいのでしょうか
ここで疑問
これ自体は実装が間違っている可能性が大いにあるんですが、どこが違うのでしょうか
また、僕は今まで特徴量を少し変更したりハイパラの選択肢を少し変更したりしながらsubを出してきました。その中でも、よいsubトップ５を単にaverageしたものを試しに提出したところLBの数値がかなりよくなりました。
では、なぜ2つ目のアプローチが効かなかったんでしょうか。なんとなく2つ目のアプローチと、subをaveragingするのはそれほど変わらないように思います。
いやいや、特徴量変えたら全然違うでしょ
いうてそんなに変えてないときもあるんです。ハイパラの選択肢を少しいじったりするくらいのsubしかないものもあります。
seed値では？
seed値は2020で固定しています。
実装が間違っている線がきっと正しいのでしょう。そしてコードも公開したいところですが、まだコンペ期間中です。
同じようなことを体験された方がいるか、はちゃめちゃ天才がいたらご教授くださいな。
