マイクロサービスに関するメモ２

前回の続き

モノリスの分解方法

  • そもそも分解するべきか
    • 既存のコードの理解が先、リファクタリングなどでビジネスドメインの境界線を作ることで、そもそもマイクロサービス化までする必要がないことに気が付く場合がある。
  • 分解する場合
  • コードの改修するときの御作法。うまく動作しない時に戻せるように修正しようよ。
  • 新しいサービス用のプロキシ作ってそれだけでまずデプロイして確認する。
  • 移行する範囲は変更を許可しないことが楽。そのためにも、小さく移行を進めようね。
  • フロントでもUI合成などで、一部ずつ移行することが可能。
  • フィーチャブランチでなく、抽象ブランチを使う。（わかるようなわからんような。。）
  • 新しいサービスの機能とモノリスの機能を両方使い、新しいサービスの機能を検証したり、システム全体の機能を増やすという手もある。
  • モノリスは変更しないで、モノリスとクライアントのやりとりを傍受してプロキシを介して新しいサービスを呼び出す。（ただし、新サービスに必要な情報が足りなかったりすると、モノリスを変えるしかない。）
  • データベースの変更をトリガーとして、新サービスに情報を送ることも可能だが、管理が難しくなる可能性があるため非推奨。

データベースの分割について

  • そもそもマイクロサービスはビジネスドメインごとにサービスを分けるアーキテクチャであり、データベースも各ビジネスドメインのサービスに分ける必要がある。（共有データベースとすることは、マイクロサービスの利点を潰す可能性が高い）
  • まずはデータベースをラップするサービスを作る方法がある。それからモノリスや各サービスに情報を送ることで、サービスに応じて必要な情報のみを送ることができる（情報の隠蔽）
  • 上記方法の場合、APIで各サービスに情報を送ることが考えられる。しかし、分析用のサービスなどを用意する場合、直接データベースに繋ぎたい要望が出てくる。この場合、真のDBをマッピングした（必要に応じて情報を隠蔽し）読み取り専用のDBを設けることで解決できる。
  • マイクロサービスによりデータが分割された場合、データの同期には検討が必要になる。例えば上記分析用サービスも毎日夜にその日のマッピングをしたとすると、一日分のラグが生じている。サービスとしてそれを許容するのかという検討が必要になる。情報源を段階的に同期をするトレーサー書き込みなど。
  • サービス間のデータの読み込みと書き込みがクロスする場合には、トラブルが起こりやすいため、サービス境界の見直しや処理フローの再検討が望ましい。

コードを先に分割するかデータベースを先に分割するか

  • パフォーマンスの懸念やデータの一貫性に関する懸念が生じている場合には、スキーマを分割することを考える、
  • 上記以外の場合には、先にコードを分割することでデータの所有権にどのような影響が出るか考える、
  • 多分だけど、通常アーキテクチャがビジネスロジックごとに綺麗に分かれていないと、コードのリファクタとかが先にくると思う。

その他

  • 分散トランザクションは避ける。
  • 各サービスが順番に処理される場合に、どこかのサービスで転けたときのロールバックについて考える必要がある。転けたときの影響がでかいものを先に持ってくることや、転け方に応じてロールバックの方法を変えるなどの工夫が必要。

感想

  • 「モノリスからマイクロサービスへ」一通り読んだけど、特別不思議なことはしてなくて、まぁサービス分けようと思うとそういうこと考えなきゃいけなそうだようねといった感じ。
  • 面白そうだけど、今まで既に動いている大きいサービスをいじるっていう経験がないから、やるとなったら結構怖そうだなーと思った。副作用も大きいから、既に大きな問題があってマイクロサービス化で解決できるという強い確信がないと提案しずらそう。。
  • この手の本としては結構読みやすい方だったと思う。

マイクロサービスに関するメモ

マイクロサービスの勉強中。「モノリスからマイクロサービスへ」の2章までのメモ。

マイクロサービスとは

マイクロサービスとは、ビジネスドメインに基づいてモデル化された、独立してデプロイ可能なサービス。

「ビジネスドメインに基づいてモデル化された」というところも大事らしく、今までは、システムがいわゆる3層構造（フロント、バックエンド、データベース）の分け方をしていたのを、ビジネスが受注生産品の販売であれば、「受注」「生産」「販売」「製品管理」「発送」など、ビジネス自体に基づいて分けられることになるらしい。 当然、組織もビジネスに合わせて分けることになり、ＤＢなども複数持つことになるらしい。DevOpsとかの文脈も含むみたい。

利点

  • 各チームが仕事をコントロールしやすくする（仕事の範囲を明確に線引きできる）
    • 管理範囲が横断的でなくなるため、仕事をコントロールしやすくなる。（三層構造だと、各チームの仕事が他のチームに影響を及ぼしやすい）
  • 市場投入までの時間の削減
    • 小さくデプロイできるため。
  • 負荷に対するスケーリング
    • 小さいサービスが複数あるため、サービスに応じてスケーリングできる。
  • 堅牢性の改善
    • 各サービスが独立しているため、トラブル時の影響範囲を狭められる。
  • 同時に作業可能な開発者の数の増加
    • サービスを分けることで、並行作業を容易になる。
  • 新しい技術を受け入れ
    • サービスを分けることで、サービスにあった技術を選択できる。

マイクロサービスがうまく機能しないと想定される場合

  • ビジネスドメインがはっきりしていないとき
    • マイクロサービスは、ビジネスドメインでわけるため。
  • スタートアップなど、マイクロサービスの利点よりも他に優先するべきものが多い場合
    • スタートアップはそもそもビジネスがうまくいくかわからんので、ビジネスを試すことを優先すべき
  • 顧客の環境にインストールして管理するソフトウェアなど。
    • Kubernatesをいれろというわけにいかない。
  • 最もな理由を持たない場合
    • なんとなくマイクロサービスにしようっていうのはやめようねってはなし。おおそうだけど。

感想

なんというか、利点はわかるけど、導入は難しそうだなってのも思う。本で書かれている通り、一部の機能だけ切り出してやってみるとかがいいんだろうな。例えば、コードを書く人が6人くらいいれば、4人と2人に分けてサービス持つとかするといいかも。逆に、そもそも２人しかコードを書く人いなかったら、仕事増えるだけな気もする。

MLOps勉強会に参加した。

参加レポート

はじめに

  • m3とFringeが主催したMLOps勉強会に参加した。
  • MLOpsの勉強会というよりは、gokart(ml pipline tool)の宣伝だった笑
    • とはいえ、titleがgokart meet up的なのだったら参加しなかったと思う。
  • 「Web engineer自身がMLOpsになることだ」のキャッチコピーはいずこへ？

結論

  • 六本木のビルがすごくて妬ましかった。
  • マイセンのカツサンドを二つくれた。
  • 内容はかなり有益だったので良かった。
  • 懇親会でM3の偉い人と話せたのは特に良かった。
    • その人に限らず、m3やFringeの人は海上の雰囲気を良くしようと心掛けてるのを感じた。
  • 最近piplineをちょこちょこ作ってたので、gokartを使ってもみたい。
  • もう少し規模の大きいpiplineツールを作ってみたいなという気にもなった。

以下、内容

  • 詳しい内容はtwitterとかで、スライドが上がっているのでそっちを参考にしてね。

gokartを作った話

経緯

  • アルゴリズムの開発でPDCAを高速に回したい
    • 前処理の変更や追加
    • データパイプラインの変更
  • パラメータが変わったら、そこだけ再計算したい
  • luigi（既存のpipline tool）をラップしてgokart を作った

効果

  • もともとの課題
    • mlはできるけど、設計が苦手な人が多かった（大きいクラスを作っちゃうとか）
    • 設計レビューは難しい
  • gokartにより以下ができるようになる
    • 書き方を統一
    • タスクの使いまわし
    • 単一責任の原則の強制
    • gokartのパイプライン上で一部pandasのテストをしてくれる（型チェック）。
  • 上記による効果
    • 複数のプロジェクトを同時に開発したいときなど、モデルの共通化をしたい場合がある。
      • モデルをidで管理してくれる
    • キャッチアップのコストを下げることができる。
      • cookiecutterで構成を作れる。
    • 本番落ちた時に対応できる。
      • 中間生成物をS3に保存している。
    • 色々、共通化したい。

今後

その他

  • sterほしい

機械学習を無理なく広告システムに導入する

前提

  • 広告配信のシステムに、機械学習を乗せた話
  • ユーザー状況をもとに興味がありそうな広告を配信する。
  • click率を上げることが効果的
    • 統計的にもできるけど、機械学習をつかうと、精度以外でも使いたいパラメータを柔軟に使えたりする。
  • 広告配信はビジネス上の制約もある（応答時間: 20ms）。
    • モデルを軽量化する必要がある。

開発時に気を付けたこと

  • ML専門じゃない人とシステム開発を一緒にやる必要がある。
    • ＊この辺の話を懇親会で聞けばよかった...。
    • 定量的に話すことで、認識の違いをなるべく減らした。
      • 特に、数字だけ言うと人によって単位を違ってイメージしていたりする。
    • 配信側が対応するのか、ML側が対応するのか
  • ログ出力が可能かどうかを最初に考える必要がある。
    • システム側で必須か、ＭＬ側のために取る必要があるか。
    • ＊この辺も最近気になっていて、システム開発してからＭＬやりたいっていう要望への対応を考えると、あらかじめ必要そうなものは取っておくべきなのか、どこまで考慮すべきなのかってのが気になっている。
  • トラブってもなんとかなる設計を心掛けた。
    • ストレージを一枚はさみ、ML側のサーバがとらぶっても、配信側のサーバが生きていれば動くようにした。
  • モデルの特徴量を減らした。
  • 修正のたびにデプロイしたくない。
    • 大量のログを効率よく学習する
    • 並列実行できるおうに、モデルを複数つくって平均するようにする
      • 特徴量ごとにcsvファイルがあって、それをzipにまとめて学習してる
      • 最新のフォルダと古いフォルダが別のストレージにある。
  • AWS Step Function（＊よくわからなかったけどメモ）

gokartを利用したワークフローの運用と課題について

機械学習ワークフローがサポートすべきところ

  • データ、特徴量加工の冪等性（べきとうせい）
  • モデル感の依存性
  • スケールするか
  • 保守性
  • 説明可能性
  • gokartは以下をサポート
    • 特徴量加工
    • モデルの保守性
      • cookiecutterでフォルダ構成を共通化できる。
      • thunderbokt（ハッシュで登録したモデルや特徴量を管理できるって感じかな）
      • redshells（なんぞ？）

gokartがサポートしてない

  • 複数のモデルを組み合わせたい
    • １プロジェクト１モジュール
  • hadoop, sparkの分散学習サポートは強くない
  • guiはなし

唯一の欠点

使い方とか

  • cukkiecutterで保存先はS3とか手元とかに決めれる
  • task管理例
    • taskA: データをロード
    • taskB: データを学習
    • taskC: taskAとtaskBをdump
  • thunderbolt でpandasでロードできる
  • luigiとの比較：
    • パラメータ管理を自分で記述する必要がある。

前提と課題

  • １人１プロジェクト
  • バッチ推論がメイン
  • クラウドサービスは多くない
    • ターゲットユーザが絞られている場合がいいのでは？
  • タスクＡとタスクＢでメモリが違うときとか、本来わけるべき
    • 可視化がない（feature inportanceとかは？っておもったけど、難しいのかな）
  • 中間ファイル、キャシュの取扱いが難しい
    • 中間ファイルの一部が破損していてもそれが気付きにくい。

その他

  • Ｍ３テックブック２、piplineのまとめを技術書展で出すらしい。
  • starがほしい

gokart導入のきっかけと、運用の現状

きっかけ

  • mlppで知った
    • Airflowは重そう。
    • luigiで特徴量の管理はできた。
  • uniposの機能のα版に使う
    • 分析するときに同じような処理をしている。
  • csvが増えていく。（＊めっちゃわかる）

gokartできること（luigiでも可:L, gokartで可）

  • Ｌ：taskuごとにコードが分離されている。後からの修正が容易。
    • コードをきれいにするのは後回しにできる。
    • 各タスクが何を受け取って、何を吐き出すかが明瞭
  • Ｇ:outputを書かなくてもpickeに吐き出される。
  • Ｇ:parameterは記述の必要があるため、意識するようになる。
    • しらなくてもいいパラメータをバケツリレーしなくなる（＊たまにやってしまう）
    • パラメータによって、ファイル名にハッシュ値がつく
      • thunderboltで管理できる。
      • sphonxを使ってdocstringからhtmlを自動生成してくれて、html管理できる。

その他

  • star ほしい、contributeしたい
  • ＊懇親会で話すネタを提供してくれたのが結構良いと思った。

懇親会

  • OSS開発を推進しているとのことだけど、どういう経緯でそうなったの？

    • Ｍ３はもともとエンジニアがいなくて、やりたいことがあるんだからエンジニアは外注すればよいという考えで始めた。
      • が、開発をしてみると大失敗した。
        • 顧客が本当にほしかったもののブランコ状態
    • そこで、やっぱり社内でエンジニアが必要だねとなった。
      • それで採用したエンジニアが、ＯＳＳの権威みたいな人だった。
        • 我々もＯＳＳ使って開発しているのだから、他のＯＳＳに貢献するのは当たり前だよねという考え。
    • 現在、ＯＳＳ開発を促進しているというよりは、ＯＳＳ開発してもいいよというスタンスが近い。
      • githubで役員がスポンサーになってる
    • 顧客のプロダクトの場合、難しいかもしれないけど、うまく切り分けてあげるのがいいのでは。

  • AUCが何％ですとか、特徴量のマトリックスが必要で人がわからなくても済む場合にも、効果をわかりやすくするために、あえて人がわかる形にしてあげることで、説明しやすさを増して、顧客にアプローチしやすい工夫をする。

参考

DSB2019 7th solution まとめ

kaggle

はじめに

DSB2019の7th place solutionまとめました。

結論

  • 情報が少ない感じするけど、かなり王道のやり方をしている気がする。
    • ドメインを調べて、それにあった特徴量作成を頑張っている。
    • 特徴量数が少なく、かなりシンプルにしている感じがする。（そう心掛けているよう）

以下、solutionまとめ

  • 一時ソース
  • ＊ 以下、拙訳ですので気になるところは1次ソースを見てね。

Approach

  • 自分にとって最もよかったのは、feature engineeringでした。最終的に、150から削り、51 featuresを用いました。
  • 効果の高かったfeaturesはそれぞれのAssessmentの分布を基にしたものです。しかし、これらはみなが用いていました。small dataが与えられた個々のfeatureは、それほど重要でないが、これらが勝敗を決めたと考えます。
  • 最終的なensembleモデル： 0.3 LGB, 0.3 CATB, 0.4 NN

  • 全てのモデルで20 fold-baggingをしました。NNでは加えて、seed averagingもしました。

    • ＊20 foldもすることあるんだな...。

  • 学習時に、サンプルとして、test setから、assessment を用いた。

    • training sampleの数を増やす方法を探した。
    • 特に、private LBにあるchildren(install_id)のdataを追加しました。

Results

  • Truncated CV: 0.575
  • Private LB: 0.559
  • Public LB: 0.559

Validation setup

  • test setの構造を反映するために、ランダムに assessment を一つ選択します。

Update 1: Features

Motivation:

  • On the measure of intelligenceの論文によって衝撃を受けました。
    • そこには興味深く、強力な考えがたくさんあります。
    • 私は、知性の測定の仕方を論じることによって刺激を受けた。
      • A/ by overall-skill-level（全体的なスキルレベル）
      • B/ by skill-acquisition-tempo（スキル習得テンポ）
  • 今回は、A/を測定することになります。それは、2つの能力に分割できます。
    • experience.
      • すなわち、ある子はどのくらいの時間をgame中に活動に費やしたのか。
      • これは、初めのfeatureのグループです。
    • accuracy
      • その子がどのくらい正解したか。
      • これは、二番目のfeatureのグループです。
  • 一方で、どのくらいはやく子供たちが学習するかを表す方法としてskill-acquisition-tempoはとても興味深い。
    • minutes per level, events per level, etc.
    • これが、三番目のfeatureのグループです。
  • 私は、手作業でのfeature engineeringをするコンペが大好きです。
    • 人間と機械の組み合わせは良い結果をもたらします。
      • それは、AIが世界に与える影響の仕方についての私の見解を表しています。
  • ＊なんかすごくドメインを重要にしているんだなっていう感じがする。
    • ＊けど、具体的な内容が少ないから、いまいちピンとこない。

Update 2: Feature selection

  • featureをdropした後cvを計算した。
    • 150feature、すべて個別おこないました。
      • ＊これって1個づつ、消してスコアを確認してっていうのをやってたってことかな？
      • ＊相互作用とかどうなってんだろ。
  • ドロップされたすべてのfeatureが、QWKの減少が0.0001より小さければノイズとみなした。
    • この方法で100のfeatureをノイズとみなした。
  • 100 のノイズfeatureを取り除いたあと、CVを再度計算したところ、わずかにスコアが上昇した。

DSB2019 4th place solution まとめ

kaggle

はじめに

DSB2019の4th place solutionまとめました。

結論

  • なんかすごく読みにくい英語だと思ったらロシアの人だった。
    • まぁ、自分も英語まともに書けないから言えないけど。
      • というか間違って訳しているかも...。
  • RNN(codeみたらBidirectional GRUっぽい)を用いているってところが肝なんだろうな。

以下、solutionまとめ

  • 一時ソース
  • ＊ 以下、拙訳ですので気になるところは1次ソースを見てね。

summary

  • best submitはNNのblending
    • private: 0.561
    • public: 0.571
  • second submitは3-levelのstacking
    • private: 0.560
    • public: 0.566
  • ＊stackingは、意外に使われないことおおいよね。

Some ideas first

  1. trainと同じ手順でラベルされたtest setは、trainに用いることができる。
  2. events sequenceのtfidf
    • それぞれのevent_idは、title + event_code + correct + incorrectであらわすことができる
    • その後、installation_idのhistoryをsequenceとして見て、それをtfidf化したものを学習する。
    • ＊学習前に上記変形を適用したってことかな？
      • ＊最初 actual sequenceのactualを「実際の」だと訳して、tfidf化する前のものかと思ったけど、「現実の」とか「現在の」みたいな使われ方なんだろうな
  3. いくつかのclipsとtitleはassesmentにおけるaccuracyの予想にとても重要である。おそらく、これらの順番はそれほど重要ではないが、RNNでは、user historyにおけるこれらをうまく扱うことができる。
    • ＊RNNは順番が重要だからじゃないのって思うけど...?
  4. 少量のデータしかないため、安定性は実際のスコアよりも重要である。もし、行を入れ替えるとスコアが悪くなるなら、それは何か間違ったことをしている
    • ＊うーん、しっくりこない。順番が大事なものと大事じゃないものがある気がするけど...。

Models

Neural network

tf-idf features + RNN (featureとしてtitle sequenceと以下を追加した。)

  1. 次元数7でのtitleの埋め込みベクトル
  2. 各titleにおけるcorrectの数
  3. 各titleにおけるincorrectの数
  4. 上記、2と3の比
  5. 各titleにおける経過時間のlog
  6. 前のtitleにおけるcorrectの数
  7. 前のtitleにおけるincorrectの数
    • ＊ラグ特徴量みたいにしたってことかな？
  8. 上記、7と6の比
  9. モデル内にcounterを含めたかったが、最終的に断念した。しかし、これらのモデルはprivate LBでよい結果をだした。
    • ほとんどのsingle networkは0.56程度であった。おもしろかったことは、privateとpublicのscoreが同じであったことである。
      • ＊あれ？最初に書かれているところでは、score微妙に違う気がするけど...?
    • ＊counterっていうのは、何のcounterのことなんだろう？
    • ＊2位の人も一緒だったけど、結構同じになる人もいるんだなぁ。

Tree based models

Lightgbm, Xgb, Catboost. (will be soonらしい)

Stack

  • 0 level) NN , lgbm, catboost.
  • 1st level) MLP, Lightgbm.
  • 2nd level) Ridge.
  • https://www.kaggle.com/c/data-science-bowl-2019/discussion/127312 から抜粋
    • 全てのモデルは回帰モデルで学習した。
    • 木系はtest dataを直接用いると悪く働く。
    • 以下は効果がなかった。
      • counters, assesment単体等のtfidf
      • world, succsessful attempts等

Validation

  • いろいろ考えたけど、結局sinpleなものを使用したよということらしい。
    • ＊普通のKFoldってことかな？

What doesn’t work for us

  • Transformers, GPT-2 , BERT, Graph NN.
    • ＊Graph NN やってみたい！
    • ＊とりあえず、BERTが適用できるか何らか試すっていうのは、いろんなタスクで行われるようになっている気がする。ちゃんと理解していると、うまく転用できるんだろうな。

DSB2019 3rd place solution まとめ

kaggle

はじめに

DSB 3rd place solution まとめました。

結論

  • single transformerモデルであり、1位、2位とはまた違った解法をしている。
    • transformer使って何か試してみたいなぁ。
  • data augmentationは、テーブルだしと思って、自分はまったく考えなかったんだけど割とみんなやってる。

以下、solutionまとめ

  • 一時ソース
  • ＊ 以下、拙訳ですので気になるところは1次ソースを見てね。

summary

  • input dataを理解するよりもinput data の構造にフォーカスをあてた。
  • つまり、feature engineering よりも dataにあったNNモデルを見つけることに注力した。

Interesting point

  • 何が面白かったかといえば、positionに関係する情報（特にposition embedding）を用いることがlocal CV scoreを低下させることである。
    • BERT, ALBERT, GPT2 モデルはうまく働かなかった。（これらのモデルには、position embeddingを含む）
  • だから、position embeddingを含まないTRANSFORMER を用いることにした。
  • ＊BERTとtransformerは論文読んでた気がするけど、position embeddingとか全然覚えてないや。要確認

Pre-processing

Aggregation by game_session

  • installation_id のsequenceは 長すぎて、（transformerに？）用いることができない。

    • だから、game_sessionによってlog_dataを集計した。
    • ＊コード略、inputの形としてこれでいいの？って感じする

  • NLP の LSTM と TRANSFORMER モデルはinput として単語のsequenceを受け取ります。同じように、ここではinputとしてgame_session（またはinstallation_id）のsequence用います。

Model

  • Best private score: 0.564 (Single transformer model)

ここでのkeyは、game_sessionからのembeddingの作り方である。

  • event_codeとかのcategoricalな値はそれぞれembeddingする。その時、その categorical vectorは、それぞれのembeddingをつなげることでできる。
  • 次に、nn.lenear layerは、categorical vectorの次元削減のために用いる。
  • 連続的な値は、直接linear layerでembeddingする。
    • 連続値の正規化には、np.log1pを用いた

hyper parameters（抜粋）

Modified loss function

  • このリンクでは、accuracy_groupの0と3のクラスは、とても似ていることが言及されている。そこで、新しいtargetを定義して、それに合うようにした。
    • ＊つまり、accuracy_groupの0と3が意外に似ており、qwkを用いることが悪く働きそうということらしい。
      • ＊accuracy groupは順序を持つ（カテゴリじゃない）けど、0と3が似ているという指摘は、1回やってあきらめても0だし、1000回やってから正解しても1なわけで、1000回やってから正解する人と1回しかやってない人どっちの方が3に近いかというと、1000回やったほうとは限らないということだと思う。
    • ＊そこで、target に 成功数(num_correct)と失敗数(num_incorect)を定義して、それを予測し、そこから新しぅaccuracy groupを算出しているみたい？
    • ＊いまいちよくわからなかったけど、そうすることで元のaccuracy groupを使うよりも改善したとのこと。

Additional training data generation

  • Game typeのgame_sessionの追加のラベルを生成した。
    • event dataのcrrect trueとcorrect falseから、num correctとnum_incorrectを作ることができた。そして同様に、accuracy groupを作ることができた。
    • 追加の学習データの数は41194件
  • ＊要は、Assesmentだけでなくて、Gameのデータから学習データを作ったということっぽい。

Pre-training and fine-tuning steps

  • 3 epoch までで、上記データを追加して学習し、それ以降ではoriginalのデータのみを使って学習した。
  • ＊画像系とかでは、こういうやり方よく見るよね。まぁ、NNだからってことなんだろうな。

Data Augmentation

  • training time augmentation: 30 行以上のgame_sessionを持つinstall_idでは、50%までrandomに古い行から削除した。
  • test time augmentation: 30 行以上のgame_sessionを持つinstallation_idでは、60%までrandomに古い行から削除した。
    • ＊このtrainとtestの割合の違いはなんなんだろう...?
      • ＊まぁ、いろいろためした結果ってことなんだろうけど。

DSB2019 2nd solution まとめ

kaggle

はじめに

DSB 2019 の 2nd solution まとめました。

結論

  • 思いついたアイデアもあったけど、word2vecによるfeatureやMeta Featureといった全く思いつかないのもあったので、おもしろかったし勉強になった。
  • 1st solutionでもあったけど、null importance によるfeature selectionはちゃんと覚えておいた方がよさそう。

以下、solutionまとめ

  • 1次ソース
  • ＊ 以下、拙訳ですので気になるところは1次ソースを見てね。

Results

  • public score: 0.563
  • private score: 0.563
    • ＊publicとprivate一緒なのすごくない？local cvのscoreが気になる。

Feature Engineering

Word2Vec features of title series

  • targetであるassessmentまでの科目のseries(historyと一緒？)をdocumentとみなすと、これらをword2vecとして処理でき、取得したベクトルから mean/std/max/minを計算した。
    • ＊全く発想になかったので面白い。本当にこんなことしていいのって感じもする笑

Historical feature

  • world(all, treetop, magma, crystal)でgroupby してsession, world, types, title, event_id, event_code を countした.
  • Count, mean, max of (event_round, game_time, event_count).
    • ＊この辺はやったけど、あんまり利かなかった気がしたんだよなぁ（なお、CV）。

Decayed historical feature

  • 直訳すると減衰させたhistorical feature (title, type, world, event_id, event_code).
  • 各セッションで history の蓄積を半分に減少させた。
    • ＊最近のデータに重みづけをしているということだと思う。
    • ＊似たようなことをやったけど、どのくらい減衰させるかは決めかねた。（なお）

Density of historical feature

  • historical data の頻度（密度） (title, type, world, event_id, event_code).
  • Density = (count) / (開始してからの経過時間).
    • ＊これも似たようなことをやったけど、なぜか各カウントに対して行うって発想がなくて、全体のカウントに対してしかやらなかった。

Lagged Assessment

  • num_correct, num_incorrect, accuracy, accuracy_group.の mean/std/...等
    • ＊これらのラグ特徴量を作ったってことかな。
  • 過去のassessmentからのどのくらい時間がたったか。
  • 評価回数あたりの特徴量（？）

Meta Features

  • 「事前のgame_sessionがどのような評価結果をもたらすか」を示すために、各assessment titleに対し、meta target featuresを作成した。
  • train dataにはout of foldを用い、testやmeta targetのような他のデータにはKFold averageを用いた。
    • ＊要はtarget encodingみたいなことをしているってのはわかる。
    • ＊どうやら、過去のgame sessionのデータに各assessments titleごとの今の評価結果をtargetとしていれて、out of foldでそれを予測してあげて、その予測値の平均をmeta feature として用いるといったことをしているみたい（画像のコピペはなんとなく避けました）。
      • ＊なんとなく、leakしそうな感じするんだけど、うまくいくんだなぁ。

Feature Selection

  • Delete duplicate columns.
  • Delete high-correlated columns (over 0.99).
  • null importanceで top 300 のscoreのfeatureを用いた.
    • ＊1st solution でもそうだったけど、2nd solution null importanceが使われている。

Modeling

  • validation setではuserごとに、1件づつsampleするようにした。
    • ＊あれ？地味にこうなってなかったかもしれない。
  • Stratified Group K Fold, 5-fold.
    • ＊これは一緒
  • RSA (5 random seed) of LGB, CB, and NN.
    • ＊LGB, NNはやってる。CBはやってないけど、kNNをやった。

Post Processing

  • Ensemble = 0.5 * LGB + 0.2 * CB + 0.3 * NN.
    • ＊自分もensemble したけど、scoreが伸びなかったので、lgbのみだった。
  • cv の qwkが高くなるようにthresholdを決めた。
    • ＊threshold は初めにoptunaかなんかで決めたけど、なんかそこ以外のところに原因があると思ったので、途中からは、途中で決めた数字をとりあえず使ってた。