20221206 キックオフ - 今日やること - ~21時40分 目的・目標 - ~22時 ルール決め - ~22時20分 出場するコンペ決め - ~23時 環境設定&お試し - 目的 - 業務活用(DS・アジャイル) - 副業や転職に活用する - 目標 - 人への説明に活かせるドキュメントを2個/月残す - DS関連 - アジャイル関連 - ルール - アジャイルベースで進める - MTG - 頻度:週2程度 - タイミング:平日⇒22-23、土日⇒朝活 - 内容: - スプリント期間中:DONE/ToDOの共有 - スプリント前後:スプリントプランニング等 - 参加コンペ - Spaceship Titanic 20221213 2回目 - 決めること - スプリントの期間:2 - 週ごとの動き方 - マストの打ち合わせ:火曜日 - (-1週目):少し準備 - 1週目:前のスプリントの振り返り・次のスプリントにやること決め - 2週目:進捗共有 - スプリントの進め方 - 1スタートの日:やりたいこと(タスク)を書き出すProduct Backlog - 1スプリント内で確保できる工数を見積もる - 2w(平日1日⇒2h×2=4h+土日の朝どちらか⇒3h×2日=6h) - 火曜日の打ち合わせ - Mitty:10h - Kenty:10h - Velocity = 20h - 1やりたいことの優先順位を決める - 1各タスクの工数をざっくり見積る - 1次のスプリントでやることの最低ラインを決める Sprint Backlog - 1スプリントゴール(XXXが有効であるかを検証できている状態。等)を決める - 2 - 4ゴールの日:スプリントゴールが達成しているかを確認する - 4次のスプリントのスタートの日(最初から) - Product Backlog(hidane:https://the.hidane.app/room/gH3whzPLS8pI) - 0.1:データDL - 0.1:ライブラリインポート - 0.5:カラムの意味を理解する - 0.5:分類する(カテゴリ変数?等) - 0.5:欠損値の確認 - 2:調査する方針決め - 1:ドキュメント化 - 1:実際に調査する - 0.5:前処理 - 1:機械的に関係性を調査 - 2:差分が出てきた場合、統計的に有意な差があるかどうかを確認 - ー-------------------------------------- - 1:ドキュメント化 - 2:新たな特徴量を作成する - 1:過去のEDA参照する - 2:機械学習モデルの構築 - Sprint backlog - 0.1:ライブラリインポート:0.1 - 0.5:カラムの意味を理解する:0.5 - 0.5:分類する(カテゴリ変数?等):0.3 - インデックス付け(演算の効率を向上させる):0.1 - 0.5:欠損値の確認:0.2 - 2:調査する方針決め - 2:可視化 - 1:統計的に有意な差があるかどうかの検証方法を勉強する - 1:ドキュメント化 - 1:実際に調査する - 0.5:前処理 - 1:機械的に関係性を調査 - 2:差分が出てきた場合、統計的に有意な差があるかどうかを確認 - Sprint Gall - 目的変数に対して関係があると思われる特徴量を確認できている状態 - 統計的に有意な差があることを確認する方法を把握できている状態 - 上記がドキュメントに残されている状態 - 会議体 - 12/27:レビュー/反省会/スプリントプランニング - 12/20:進捗共有⇒やったこと、次やること、課題の共有 # 進捗 - 20221214 Kenty - 調査する方針まで決めた。 - 20221220 進捗報告 - 調べる方針をまとめてから分析作業に取り掛かる - 分析したいことリストを作る - 分析し、結果を共有する - 分析結果に基づき2段階目の分析したいことリストを作る - ある程度煮詰まったら、他に気になっていることを分析する - 次やること - 分析に取り掛かる前に、仮説を立てる - 仮説を検証するための分析する - 仮説と、検証結果を共有する - ドキュメント化 - このコンペ特有の知見 - データに関しての知見 - 体系的知識のための知見 - このスプリントで注力した箇所 - 良かったこと - 反省点 - 次のスプリントでやると良さそうなこと - # Product Backlog - データの読み込み型の標準化 - データ読み込み後 可視化の処理の標準化 - test と Train の分布に違いが無いか? - カテゴリ変数と量的変数の分類の自動化 - 欠損値の処理 - 多重共線性への対処方法 # 20221230 Sprint1終了・Sprint2開始 - Sprint1 - Sprint Rview - 成果物の確認 - スプリントゴールを達成したかどうかを確認する - Sprint Gall - 目的変数に対して関係があると思われる特徴量を確認できている状態 ⇒ 達成 - 統計的に有意な差があることを確認する方法を把握できている状態 ⇒ 達成 - 上記がドキュメントに残されている状態 ⇒ 達成 - 改善したいところ - 2人で同じ作業を実施できるようにする - お互いの作業を確認できる状態にする - ドキュメントの運用ルールを決める - 調査方法の正解が分からないので、過去の人たちのドキュメントも調べて取り入れるようにする - ドキュメント(コードの記述方法も含め)の体裁は整えるようにする - Sprint Retrospective - プロセス自体の反省会 - Keep - ++ドキュメントの運用方法をなんとなく決めた - コードの標準化に関する取り組み - +過去のKaggleを参考にしながら分析を行った - +分析の方針決めを行った - データの分布の見方や効率的な記述方法の共有 - Problem - ++分析の目標の軸がブレたこと - ++統計的な知識の習得がきちんと行えていない(水戸) - 効率的な可視化の方法が分からない - 簡単なグラフ化の方法を忘れてしまう - 後半のスプリントでアジャイル的な動き方ができていなかった - Try - +統計的知識の習得 - コードの記述含む - 分析の方針決めを二人で共有する - ++分析の方針を体系的に整理する(「仮説の方針」と目次の整合性を取る) - +上位の人が毎コンペ共通で行っていることをEDA_templeteに組み込む - 簡単なグラフもvisualization_templeteに残す - - Sprint2 - Sprint Planning - PBLの整理 - 優先度付け - 最低限実施することを決める - スプリントゴールを決める - Sprint Backlog - 特徴量の作成 - 欠損値処理はしない(今回はあくまでもモデルの勉強) - モデルの選定(LightGBM固定) - 突っ込む特徴量の決定(全ぶっぱ) - データセットの作成(LightGBMに合う形に成型する) - モデルの学習(シンプルな実装、ハイパーパラメータは初期値) - シンプルな実装をした場合の性能を評価 - --------------------------- - パラメータチューニング - grid search - random search - 確率に基づくチューニング - クロスバリデーションの意義をまとめる - 一旦提出(validでのスコアと比較) - 各説明変数の重要度の確認 - 重要度を参考に、特徴量を更新 - LightGBMに適している入力データの形式に関する知見 - onehot? - 数値変数の分布? - - Sprint Goal - LightGBM の基本的な使い方を分かっている(よく使うメソッドとかもまとめる) ⇒ ドキュメントを残す - どのようなパラメータで性能が向上するか分かっている ⇒ ドキュメントを残す - スケジュール - 1/17:進捗報告 - 1/24:スプリントレビュー・スプリントプランニング - 20230124 スプリントレビュー・スプリントプランニング - Sprint2のスプリントレビュー - お互いの成果物を共有しあう - Kenty:ハイパーパラメータ最適化のところで止まっている - Mitty:特徴量エンジニアリングのところで止まっている - スプリントゴールの達成可否を確認する - NO(下記は今回のSprint Goal) - LightGBM の基本的な使い方を分かっている(よく使うメソッドとかもまとめる) ⇒ ドキュメントを残す - どのようなパラメータで性能が向上するか分かっている ⇒ ドキュメントを残す - スプリントレトロスペクティブ - KPT - https://the.hidane.app/room/PNvIBcF9QSLu - Try - 目標を細分化して立てる - 2人で同一のnotebookを編集する - 共有notebookには、TryとSprint backlogを目次に転記する - Sprint3のスプリントプランニング - Product backlogを整理する - このSprintでどこまでやるかを決める - 20230207 スプリントレビュー・スプリントプランニング - Sprint3のスプリントレビュー - Sprint Goal - LightGBM の基本的な使い方を分かっている(よく使うメソッドとかもまとめる) ⇒ ドキュメントを残す - どのようなパラメータで性能が向上するか分かっている ⇒ ドキュメントを残す - お互いの成果物を共有しあう - Kenty: - Mitty: - スプリントゴールの達成可否を確認する - LightGBM の基本的な使い方を分かっている ⇒ OK - どのようなパラメータで性能が向上するか分かっている ⇒ 微妙(各パラメータの意味の理解が浅い) - スプリントレトロスペクティブ - KPT - https://the.hidane.app/room/xcAti6h5grAs - Try - Githubでのソースコード管理 - Sprint4のスプリントプランニング - Product Backlog / Sprint Backlog - LightGBMの知見を深める系 - 各パラメータの意味をまとめる(Mitty) - LightGBMに適している入力データの形式に関する知見を深める - onehot / Labelencodingの比較を行う(Kenty) - Box-Cox変換を行う(Mitty) - 対数変換を行う(Kenty) - 改善系 - kaggle.jsonのdrive配置(Mitty) - 特徴量管理方法の関数化(Kenty) - パラメータチューニング結果をdbで保存(Mitty) - Githubでバージョン管理する(Kenty) - ー------------- - モデルの学習に関する知識を深める - 過学習防止策のドキュメント化(Mitty) - クロスバリデーションの意義をまとめる(Kenty) - クロスバリデーションでパラメータチューニング(Mitty) - どのような時にPrivate / Public Scoreの乖離が発生するかを調べる(Kenty) - パラメータチューニングのやり方をまとめる(Mitty) - その他の知見を深める - 重要度を参考に、特徴量を更新 - 各説明変数の重要度変数の可視化と応用 - 欠損値の埋め方を工夫したい - 新しい特徴量を作成する - 20230228 スプリントレビュー・スプリントプランニング - Sprint4のスプリントレビュー - お互いの成果物を共有しあう - Kenty: - Mitty: - スプリントゴールの達成可否を確認する - 決め忘れた - スプリントレトロスペクティブ - KPT - https://the.hidane.app/room/xcjGHBD8RISF - Try - Sprint5のスプリントプランニング - Product Backlog / Sprint Backlog - コード管理(Mitty) - Youtubeで「github colab」とかで調べると良い(優先度:Colabで実行 > ローカル > GCPやAWS) - コードをGithub上で管理し、Colabでの作業は各自別々のNotebookを開く。作業が終わったらGitにPUSHする仕組みを検討する - コード管理のやり方を相方にレクチャーするための準備を行う - コード管理のやり方を相方にレクチャーする - Problem管理(Kenty) - スプリント中に感じた・発生したProblemをメモしていく方法を考える - KPTのときに、Problemを引っ張ってこれるようにする - KPT会で決まったTryが実行される仕組みを作る(PBIとして追加する。みたいな案でOK) - PBL管理(Kenty) - スプリント中にやりたいと感じたことをProduct Backlogに追加していく仕組みを考える(可能であれば、Github) - Product Backlog Item の優先度を入れ替える方法を考える - 次回のスプリントで対応したいPBIが分かる状態を作る - スプリント中に、PBIのステータス(ToDo Doing Done)を更新する - 検討した項目のレビュー(Mitty) - 検討した内容をレビューする時間を抑える >> 毎週火曜日とは別日で確保 - 上記のやり方について、レビューを行う - レビュー結果をもとに修正し始める(各自) - -------------- - 運用を開始する - 次のスプリントについて「必ずやる」「可能であればやる」「やらない」の3段階を線引きする仕組みを作る - 工数の実績が分かるようにする - Sprint Goal - Githubでの一元管理のたたきをつくり、運用方法のレビューが一度完了している状態 - 欠損値処理 - 量的 ⇒ 0 - カテゴリ ⇒ NaNカテゴリ - 利用する特徴量を決める - Select-K bestについて、いくつかのKを比較する。Kを増やしていき、飽和したらKを増やすのをやめる - K=10, 20 - 上記の結果を見て、どのような特徴量が選択されているかを確認する - 重要度変数を確認する - 利用する特徴量をエクセルで印をつけておく - 本格的な欠損値処理をSelectKBestで選んだ特徴量に対してのみ行う - 欠損値処理を行う担当を決める - 他の特徴量の情報を参考に欠損値を埋められないかを確認する - どうしても埋まらない場合には、medianなどで埋める - 外れ値への対応をSelectKBestで選んだ特徴量に対してのみ行う - 外れ値があるかどうかの確認(量的変数のみ) - 外れ値の除外を行う - Skewのある特徴量に対してBox-Cox変換 - https://www.kaggle.com/code/serigne/stacked-regressions-top-4-on-leaderboard?scriptVersionId=1955054&cellId=84 - 全ぶっぱでモデル作成