Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Kaggleふりかえり会〜LLM 20 Questions & ISIC 2024

Recruit
December 04, 2024

Kaggleふりかえり会〜LLM 20 Questions & ISIC 2024

Recruit

December 04, 2024
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. © Recruit Co., Ltd. All Rights Reserved Kaggleふりかえり 〜LLM 20

    Questions & ISIC 2024 19:00~19:05:オープニング 19:05~19:40: LLM 20 Questionsの解法 と Q&A 19:40~20:15:ISIC 2024の解法 と Q&A 20:15~20:25:クロージング
  2. © Recruit Co., Ltd. All Rights Reserved • 質問について 登壇者ならびに事務局への質問は

    ZoomのQ&Aにご記入ください。 特定の登壇者への質問は、冒頭に 【登壇者名】を記載いただけますと 回答がしやすくなります。 時間の関係上、質問への回答ができな い場合がございます。ご了承ください。 3
  3. © Recruit Co., Ltd. All Rights Reserved 自己紹介 名前 阿内

    宏武(あうち ひろむ) 仕事 リクルート新卒入社9年目 現在はHR領域のデータサイエンス グループのマネージャ その他 オセロとギターが好き
  4. © Recruit Co., Ltd. All Rights Reserved 株式会社リクルートについて 5  マッチング&ソリューションSBU

    HRテクノロジーSBU 人材派遣SBU 国内派遣 海外派遣 選択・意思決定を支援する情報サービスを提供し、 「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」を実現する
  5. © Recruit Co., Ltd. All Rights Reserved データ推進室について 6 各事業領域のデータ戦略立案・推進を行う領域特化ユニットと

    領域横断で支援を行う専門職種のユニットが交差するマトリクス型組織 z 職種・ 機能単位 プロダクト単位 アジリティテクノロジー部 データソリューションユニット データテクノロジーユニット HR 結婚 旅行 自動車 学習 飲食 美容 住宅 SaaS 横断 データプロダクト マネジメント1部 データプロダクト マネジメント2部 データプロダクト マネジメント3部 データサイエンス・機械学習エンジニアリング部 データエンジニアリング部 データマネジメント部 採用・育成による専門性強化に責任を持つ プロダクト戦略の実現のための活動に責任を持つ より高度な専門性を基に領域・横断の重要案件の支援を行う データ テクノロジー ラボ部 室直下 アドバンスド テクノロジーラボ部 イノベーティブテクノロジー 研究戦略部
  6. © Recruit Co., Ltd. All Rights Reserved クラウド利用支援制度があります! クラウド利用支援制度とは? •

    自己成長機会の支援施策、「クラウド環境」の利用を支援する制度です • MAX 8万円/月補助がでます 対象者 • 自己研鑽でクラウド環境を利用したい方 • 実際にクラウドを触って勉強したい、新しい技術を試したい • Kaggleや競プロでの研鑽資源として使いたい 等 実際の活用事例 • 今日発表するLLM 20 Questionsコンペの 金メダルチームが、GeminiのAPIを叩く費用として利用
  7. © Recruit Co., Ltd. All Rights Reserved Kaggleふりかえり 〜LLM 20

    Questions & ISIC 2024 19:00~19:05:オープニング 19:05~19:40: LLM 20 Questionsの解法 と Q&A 19:40~20:15:ISIC 2024の解法 と Q&A 20:15~20:25:クロージング
  8. © Recruit Co., Ltd. All Rights Reserved LLM 20 Questions解法紹介

    9 株式会社リクルート データ推進室 若月 良平、翁 啓翔、桑原 旦幸 2024/11/15
  9. © Recruit Co., Ltd. All Rights Reserved アジェンダ 1. 自己紹介

    2. コンペ概要 3. majimekunチーム解法 4. 結果 5. コンペ全体の感想 10
  10. © Recruit Co., Ltd. All Rights Reserved 12 若月 良平

    (NIWATORI) 現在はデータサイエンティストとしてHR領域のデータプロ ダクトを担当 Kaggle Competitions Grandmaster 翁 啓翔 (oks) 現在はデータサイエンティストとして『リクルートダイレクト スカウト』等のHR領域のデータプロダクトを担当 Kaggle Competitions Master 桑原 旦幸 (akmr) 現在はデータエンジニアとしてHR領域のデータプロダクト を担当 Kaggle Competitions Expert
  11. © Recruit Co., Ltd. All Rights Reserved コンペ概要 • 2

    vs 2の対戦形式のコンペ • 秘密の「物に関する」キーワードが与えられる • GuesserとAnswererの2種類のエージェントが1チームとなって協力し、 Guesserが20 Round以内の質問でキーワードを当てることを目指す ◦ Guesser : 各RoundでAnswererに一つ質問 (ask) をし、 その回答を踏まえてキーワードを一つ推測 (guess) する ◦ Answerer : Guesserからの質問に対して、“yes” か “no” のいずれかを返す (answer) ◦ 自身のエージェントがGuesserかAnswererかは対戦のたびにランダムに決まる • 2チームの対戦形式で、先にGuesserが正解したチームが勝ちとなる ルール説明 14
  12. © Recruit Co., Ltd. All Rights Reserved コンペ概要 ゲームの流れ 15

    Guesser Answerer Team1 Guesser Answerer Team2 Croissant keyword Start
  13. © Recruit Co., Ltd. All Rights Reserved コンペ概要 ゲームの流れ 16

    Guesser Answerer Team1 Guesser Answerer Team2 Croissant keyword Round: 1 ask Is it a living thing? Is it an animal?
  14. © Recruit Co., Ltd. All Rights Reserved コンペ概要 ゲームの流れ 17

    Guesser Answerer Team1 Guesser Answerer Team2 Croissant keyword Round: 1 answer Is it a living thing? Is it an animal? no no
  15. © Recruit Co., Ltd. All Rights Reserved コンペ概要 ゲームの流れ 18

    Guesser Answerer Team1 Guesser Answerer Team2 Croissant keyword Round: 1 guess Is it a living thing? Is it an animal? Radio Computer no no
  16. © Recruit Co., Ltd. All Rights Reserved コンペ概要 ゲームの流れ 19

    Guesser Answerer Team1 Guesser Answerer Team2 Croissant keyword Round: 2 ask Is it a type of food? Is it a bird?
  17. © Recruit Co., Ltd. All Rights Reserved コンペ概要 ゲームの流れ 20

    Guesser Answerer Team1 Guesser Answerer Team2 Croissant keyword Round: 2 answer yes no Is it a type of food? Is it a bird?
  18. © Recruit Co., Ltd. All Rights Reserved コンペ概要 ゲームの流れ 21

    Guesser Answerer Team1 Guesser Answerer Team2 Croissant keyword Round: 2 guess yes no Is it a type of food? Is it a bird? Croissant Headphone
  19. © Recruit Co., Ltd. All Rights Reserved コンペ概要 ゲームの流れ 22

    Guesser Answerer Team1 Guesser Answerer Team2 Croissant keyword Round: 2 guess yes no Is it a type of food? Is it a bird? Croissant Headphone Win! Lose…
  20. © Recruit Co., Ltd. All Rights Reserved コンペ概要 • Public評価時

    ◦ 公開された「物」に関するキーワードリストからランダムに選ばれる • Private評価時 ◦ Public評価時のものと「同じような」キーワードリストから抽出される ◦ Public評価時のものと重複はない ◦ 「物」に関する単語である 候補となるキーワードについて 23 実際の運営によるコメント
  21. © Recruit Co., Ltd. All Rights Reserved コンペ概要 • 文字数制限

    ◦ Guesserが行う質問は750文字以内 ◦ 推定する単語は100文字以内 • 実行時間の制限 ◦ 各ラウンドで各エージェントが使用出来る時間が60秒与えられる ◦ 上記に加えてゲームを通じて使用できる時間が300秒与えられる • 実行環境 ◦ Disk: 100GB ◦ RAM: 16GB ◦ GPU: T4 x1 • 提出数 ◦ 最新の提出2つが評価に使われる その他詳細 24
  22. © Recruit Co., Ltd. All Rights Reserved Answerer • ペアとなるGuesserが正しく正解に辿り着けるよう、

    素直になるべく質問に正確に答えられることを目指す • Public評価期間中にLeaderboardで収集出来る対戦ログを観察し、 以下の2パターンを組み合わせた ◦ 典型的な単純な質問 → ルールベース ◦ その他の質問 → LLM 方針 27
  23. © Recruit Co., Ltd. All Rights Reserved • 対戦ログを見ると以下のような質問をするエージェントが多いことが分かった •

    また、これらの質問は軽量なLLMでは誤答するケースが多く見られた Answerer ルールベースパート 1/2 28 Does the keyword start with the letter ‘A’? Does the keyword include the letter ‘A’? Does the keyword precede ‘melon’ in alphabetical order? 開始・終了文字 辞書順 含有文字
  24. © Recruit Co., Ltd. All Rights Reserved • 対戦ログを見ると以下のような質問をするエージェントが多いことが分かった •

    また、これらの質問は軽量なLLMでは誤答することケースが多く見られた • これらの典型的な質問を正規表現で一致判定し、ルールベースで回答 Answerer ルールベースパート 2/2 29 Does the keyword start with the letter ‘A’? Does the keyword include the letter ‘A’? Does the keyword precede ‘melon’ in alphabetical order? 開始・終了文字 辞書順 含有文字 starts|start|begins|begin|end|ends) with the letter['"]?([a-zA-Z])['"]?\?$ (includes|include|contains|contain) the letter ['"]?([a-zA-Z])['"]?\?$ keyword.*(?:come before|precede) "([^"]+)" .+ order\?$
  25. © Recruit Co., Ltd. All Rights Reserved Answerer • システムプロンプト、キーワード、Guesserの質問をLLMに入力し、

    ‘yes’ か ‘no’を出力させる LLMパート 1/2 30 messages = [ { "role": "system", "content": "You are an AI that answers with 'yes' or 'no' to determine if a statement based on a keyword is true. Answer yes or no only." }, { "role": "user", "content": "Keyword: {keyword}, Question: {question}" } ]
  26. © Recruit Co., Ltd. All Rights Reserved Answerer • 4bitに量子化したGemma-2-9B,

    Llama-3.1-8B, Mistral-7Bの多数決 • Geminiでラベリングしたものを正解データとしてローカルで評価してモデルを選択した • 細かい工夫:3モデルは同時にVRAMに載らないが、推論のたびにモデルをロードすると 制限時間に間に合わない → 推論の順番を変更してロードの回数を減らす ◦ Round1: Gemma → Llama → Mistral ◦ Round2: Mistral → Gemma → Llama ◦ Round3: Llama → Mistral → Gemma LLMパート 2/2 31
  27. © Recruit Co., Ltd. All Rights Reserved Guesser • 質問とキーワードの推定を全てLLMにやらせるのは探索空間が広すぎて厳しい

    • 事前計算と推論時にそれらを活用する方法を採用 (Offline-Policy) 方針 32 事前計算 キーワードリスト生成 質問生成 確率値ラベリング 推論 キーワード推定 質問選択
  28. © Recruit Co., Ltd. All Rights Reserved Guesser • 事前計算で得られる以下の値は一旦所与のものとして話を進める

    • これらの生成方法については後述する 推論 - 前提条件 33 Guessの探索対象となるキーワードの集合 Askで使用する質問の集合 事前計算 キーワードリスト生成 質問生成 確率値ラベリング 環境上のAnswererが、ある質問とキーワードの ペア に対して “yes” と返す確率
  29. © Recruit Co., Ltd. All Rights Reserved • ラウンド目のGuess時において、Guesserはそれまで行った質問と解答のペア が与えられることになる

    • このとき、あるキーワード が正解となる事後確率が計算可 Guesser 推論 - キーワード推定 34 確率値ラベリングで 計算済みの値 事前分布 • 最も確率の高いキーワードをGuessに使用する (MAP推定) 推論 キーワード推定 質問選択
  30. © Recruit Co., Ltd. All Rights Reserved • なるべくキーワードの候補が最も絞れる質問をしたい •

    新たに質問を追加した際の 条件付きエントロピーが最も小さくなる質問を選択する Guesser 推論 - 質問選択 35 新たに質問と回答のペア が 得られた場合のキーワードのエントロピー 推論 キーワード推定 質問選択
  31. © Recruit Co., Ltd. All Rights Reserved Guesser • 事前計算の詳細について紹介する

    事前計算 36 Guessの探索対象となるキーワードの集合 Askで使用する質問の集合 事前計算 キーワードリスト生成 質問生成 確率値ラベリング 環境上のAnswererが、ある質問とキーワードの ペア に対して “yes” と返す確率
  32. © Recruit Co., Ltd. All Rights Reserved コンペ概要 • Public評価時

    ◦ 予め公開された「物」に関するキーワードリストからランダムに選ばれる • Private評価時 ◦ Public評価時のものと「同じような」データセットから抽出される ◦ Public評価時のものと重複はない ◦ 「物」に関する単語である 候補となるキーワードについて (再掲) 37 実際の運営によるコメント 公開されているPublic評価時のキーワードリスト から「似たキーワード」を生成する必要がある!
  33. © Recruit Co., Ltd. All Rights Reserved Guesser • キーワードリスト生成の精度を定量化するため、

    Publicのキーワードリストをtrain/validに分割して評価を行った • 初手は WordNet から単語を抽出する方法を試した ◦ physical_entity.n.01 の子孫ノードの単語全て ▪ Recall = 46%, Vocab size: 35,000 ◦ trainに含まれる単語に隣接する単語全て ▪ そんなに良くなかった 事前計算 - キーワードリスト生成 1/3 38 事前計算 キーワードリスト 生成 質問生成 確率値ラベリング
  34. © Recruit Co., Ltd. All Rights Reserved Guesser • LLM

    (gemini-1.5-pro, gpt-4o-mini) を使ってキーワードリストから似た単語を出 力させるタスクを試したところ、WordNetよりも大幅に性能が良いことが分かった ◦ WordNetより少ない語彙でRecallが8割程度 事前計算 - キーワードリスト生成 2/3 39 事前計算 キーワードリスト 生成 質問生成 確率値ラベリング Public用 キーワードリスト 生成元キーワード 出力キーワード Private用 キーワードリスト N個 復元抽出 LLMにより M個生成 重複削除
  35. © Recruit Co., Ltd. All Rights Reserved Guesser • N個サンプリング→M個生成する処理を繰り返すと同一のキーワードが複数生成される

    • 出現回数が高い単語ほどPrivateに出現する確率が高いことが推察された • この事実を以下で活用 ◦ 各単語の事前分布の設定 ◦ 出現頻度の低い単語の足切り 事前計算 - キーワードリスト生成 3/3 40 事前計算 キーワードリスト 生成 質問生成 確率値ラベリング 出現頻度 Precision 出現頻度ごとのPrecision 足切り頻度ごとのRecall 足切り後のリストサイズ Recall
  36. © Recruit Co., Ltd. All Rights Reserved Guesser • 次の3パターンで質問を用意

    ◦ 「Does the word start with “a”?」のような質問 ◦ Public評価時の対戦ログから収集した質問 ◦ LLMが生成した質問 ▪ キーワードリストからランダムにN個抽出し、 それらをなるべく半分に分ける質問を生成させた • 同様な質問が重複すると確率値ラベリングの処理が重くなるため、 SentenceTransformersを用いて類似の質問を削除する処理を行った 事前計算 - 質問生成 41 事前計算 キーワードリスト 生成 質問生成 確率値ラベリング
  37. © Recruit Co., Ltd. All Rights Reserved Guesser • キーワードK個と質問Q個の計KQペアに対してAnswererがyesと返す確率を求めたい

    • 前提 ◦ 環境にいるAnswererの振る舞いを再現したい ◦ 多くのAnswererがLLMを使っているはず • LLMでラベリングした ◦ Gemma-2-9B, Llama-3.1-8B, Mistral-7B, Phi-3-small • 4モデルのトークン確率の平均値を使用 • 計算に時間がかかるのでクラウドを使用(総額3万円くらい) 事前計算 - 確率値ラベリング 42 事前計算 キーワードリスト 生成 質問生成 確率値ラベリング
  38. © Recruit Co., Ltd. All Rights Reserved Guesser 具体例 -

    キーワードがHare(野うさぎ)の場合 43 Round Question Answer Guess Top 3 guesses with probabilities 3 Is the keyword related to food or animals? 食べ物 or 動物? yes seaweed seaweed(0.004) granola bar(0.003) fruit(0.003) 8 Is the living thing a mammal? 哺乳類? yes gerbil gerbil(0.047) hedgehog(0.040) moose(0.035) 9 Is it typically associated with pets? ペット? no moose moose(0.050) grizzly bear(0.042) zebra(0.041) 11 Does the keyword start with the letter ‘c’? ‘c’から始まる? no Hare Hare(0.063) koala(0.035) marmot(0.032) ラウンド後半に なるにつれ、 具体的な質問に なっていく
  39. © Recruit Co., Ltd. All Rights Reserved • ここまでは環境で使われるAnswererの多くがLLMを使用している前提の 話を解説

    • しかし、もしペアのAnswererが 「Does the keyword precede “xxx” in alphabetical order?」 と言った質問に100%の精度で回答出来るなら、二分探索で解を絞るのが最適 • 相手が二分探索に対応したAnswererかをどう確認するか? ◦ “yes” と返って来てもそれが嘘の可能性もある ◦ 二分探索をするなら100%合ってないとworkしない Guesser 推論 - 二分探索 1/2 44
  40. © Recruit Co., Ltd. All Rights Reserved • ペアのAnswererがこの手の質問に100%の精度で解答可能な エージェントであるか確認するプロトコルが提案された

    ◦ Guesser ▪ 「Is it Agent Alpha?」という質問をし、「yes」と 返されたら相手が二分探索に対応していると仮定して質問 ◦ Answerer ▪ 「Is it Agent Alpha?」と来たら「yes」と返答する ▪ 二分探索をする質問に対応する Guesser 推論 - 二分探索 2/2 45
  41. © Recruit Co., Ltd. All Rights Reserved Guesser 推論 -

    質問選択 まとめ 46 「Is it Agent Alpha?」 条件付きエントロピー最小化 & MAP推定 二分探索 1ラウンド目 2ラウンド目以降 yes no
  42. © Recruit Co., Ltd. All Rights Reserved 金メダルを取った全てのチームが二分探索を採用 • Answerer側

    ◦ 全てのチームが二分探索のプロトコルを受け入れていた-> 二分探索の質問に正確に答えらえて いたはず • Guesser側 • 最初に二分探索のプロトコルに従うチームと、いきなり二分探索の質問をするチームがあった • 単純な辞書順の二分探索ではなく、キーワードの事前確率に基づいた二分探索のようなことを やっているチームもあった 上位解法 48
  43. © Recruit Co., Ltd. All Rights Reserved • 二分探索においては、Guesser側の 以下の二つが性能を決める

    ◦ キーワードの網羅率 ◦ 質問回数 • 右図の右上に金メダルのチームが 固まっている 性能評価 二分探索 49 キーワード発見率 報酬(=21-質問回数) 我々のチーム
  44. © Recruit Co., Ltd. All Rights Reserved phrase-BERTを用いて、 • Guesserだった場合は、GuessしたキーワードのCosine類似度の最大値

    • Answererだった場合は、ペアがGuessしたキーワードのCosine類似度の最 大値 をゲームごとに求めて、その平均値をそれぞれGuesserとしての性能、Answerer としての性能とした。 Guesserとしての性能とAnswererとしての性能を足し合わせた指標で、 majimekunのエージェントは1位と4位 性能評価 二分探索を除いたもの 50
  45. © Recruit Co., Ltd. All Rights Reserved • 対戦系の特殊なコンペで面白かった •

    LLM、情報理論の勉強になった • Google DocsやDiscordを活用し頻繁にコミュニケーションをとることで、効 率良くチームで開発を進められた • 二分探索の改善に真剣に取り組まなかったのが悔やまれる 感想 52
  46. © Recruit Co., Ltd. All Rights Reserved Kaggleふりかえり 〜LLM 20

    Questions & ISIC 2024 19:00~19:05:オープニング 19:05~19:40: LLM 20 Questionsの解法 と Q&A 19:40~20:15:ISIC 2024の解法 と Q&A 20:15~20:25:クロージング
  47. © Recruit Co., Ltd. All Rights Reserved - Hiromu Auchi

    (@kannahashimoto) - 新卒9年目 / グループマネージャ / Kaggle Competition Master - Tosei Hatori (@toseihatori) - 新卒10年目 / シニアデータサイエンティスト/ Kaggle Competition Master - Yugo Fukuyama (@fyk) - キャリア入社3年目 / Kaggle Competition Master - Yuhi Nagatsuma (@nynyny67) - キャリア入社1年目 / Kaggle Competitions Expert 参加メンバー
  48. © Recruit Co., Ltd. All Rights Reserved - 皮膚がんの病変の陰性/陽性を予測する2値分類タスク -

    画像とテーブルの2通りのデータが与えられた - データ(trainに使えるもの) - 患者数: 1042、病変数: 約40万 - 正例病変数:約400(全体の約0.1%) - 病変の画像 - 15 x 15mm領域の画像 - 患者の年齡、病変の大きさ形状などのメタデータ コンペについて
  49. © Recruit Co., Ltd. All Rights Reserved - 画像・テーブルの両方のデータ活用が必要 -

    単体ではテーブルの方が分類精度高い - 正例が極端に少なく、負例が多い - 過学習のリスクが大きい - train, testは共通の患者を持たない - p-AUCによる評価指標 - 病変のサンプルは多いが患者はそれほど多くない コンペの特徴
  50. © Recruit Co., Ltd. All Rights Reserved ベースラインになっていた構成 - 画像モデル予測値をテーブルモデルの特徴量として使うモデルがスタンダードだった

    - ここからモデルにどのように多様性を生むかが重要だった - 一見すると画像コンペに見えたが、単体性能はテーブルの方が高かった
  51. © Recruit Co., Ltd. All Rights Reserved - パイプラインを統一せず、それぞれ独立にモデルを磨き込んだ -

    結果的に各自のモデルの違いが多様性となりいい方向に働いた - モデルの多様性を大きくすることが今回のコンペのポイントだったと感じた - CV戦略だけはチームで統一 - 画像とテーブルモデルのCVも同一のものを用いた - こうしておくと精度比較とスタッキングへの活用が簡単にできる - stageごとのfoldをきっちり揃えて厳密にリークを避けた - 画像のOOFは逐次共有してスタッキングに使用 コンペ中の進め方
  52. © Recruit Co., Ltd. All Rights Reserved - コンペ中はデータセット内に各実験のversionを保 存していた

    - このように管理することで過去の実験の再現性や チーム間での共有の面でメリットがあった コンペ中の進め方
  53. © Recruit Co., Ltd. All Rights Reserved チームの最終的なパイプライン - 終盤まで各々でモデルを磨きつつ独立に進めていた

    - コンペ終了2週前くらいに最終的なsubをどうしていくか話し合い始めた - 画像モデル2つ、テーブルモデル3つをどう組み合わせるか?
  54. © Recruit Co., Ltd. All Rights Reserved 画像パート1 - timmライブラリを使用

    - CNNやViTをPyTorchで1から書いたりはせ ず、backbornモデルを用いる方法で進めた - pretrainされたweightを用いない場合、精 度が出にくかった - 主に利用したモデル - convnext_base - eva02_small - swin_base
  55. © Recruit Co., Ltd. All Rights Reserved 画像パート1 - ダウンサンプリング

    & バギング - 各epochの最初に負例をリサンプリング - timmのbackborn - Google Corab Pro+を利用 - 過学習回避のためearly stoppingをしなかった - 推論時はno validationのフルデータ学習を行ったモデルを使用 - 5foldと比べて推論時間を20%まで軽量化 - アンサンブルの自由度に貢献 - 5foldとほぼ同等の精度 - スタッキングと精度評価のために5fold学習で進めつつ、最終的にフル データ学習モデルを作ってsubするという流れでやっていた
  56. © Recruit Co., Ltd. All Rights Reserved 画像パート2 - 学習データ

    (後述) - 今回のコンペのデータ全量 - 過去コンペのデータ全量 - train, validation双方に過去データを使用 - SIIM-ISIC Melanoma Classification 1st place solution - 主に後段のモデル用に過去データにもoofを付与するため - 目的変数 (後述) - 本来のtarget - lesion_idを持っているか - 補助ロスとして利用 - 過去コンペのデータかどうか - 補助ロスとして利用
  57. © Recruit Co., Ltd. All Rights Reserved 画像パート2 学習の詳細 -

    学習設定 - early stoppingなし 5 epoch on local RTX 3090 - backbone - convnext_small.fb_in22k_ft_in1k - convnextだけやたらとLB scoreが良かった(privateは普通) - resnet18.fb_swsl_ig1b_ft_in1k - 単体精度は全然だけどアンサンブルではそれなりに効いていた模様 - swin_small_patch4_window7_224.ms_in22k_ft_in1k - resnet152.tv2_in1k - optimizer - optimizer : Adam - lr_head : 2e-4 - lr_backbone : 2e-5
  58. © Recruit Co., Ltd. All Rights Reserved 画像パート2 補助ロスについて -

    lossを以下の形で定義 - loss = target loss + w_1 * has_lesion_id loss + w_2 * is_past_data loss - w_1 = 0.1 - lesion_idのlossのレンジがtarget_lossのおよそ10倍なのでこれ で大体 1 : 1くらいのブレンド感 - w_2 = 1e-4 - これは適当に決定 - アーキテクチャ - backboneからそれぞれのloss用のheadを生やすよくある構造 - backbone -> head_target -> head_has_lesion_id -> head_is_past_data
  59. © Recruit Co., Ltd. All Rights Reserved 画像パート2 補助ロスについて -

    lesion_idについて - 悪性の可能性が一定ある画像にはlesion_idが付与される - lesion_idが付与された画像は生検などによって詳細な診断がなされ、そ のうちの一部の画像についてtargetが1となる - つまり、lesion_idを持っていればそれなりの確率でtarget=1だという 見込みが立つ - 今回この補助ロスがかなり効いていた - 過去コンペのデータについて - 与えられるデータが結構違いそうなので明示的に情報を与えてみた - 実験した感じ「無いよりは多少マシ」という程度
  60. © Recruit Co., Ltd. All Rights Reserved 画像パート2 補助ロスについて -

    実験結果 - 補助ロスによって結果が大きく改善した - local cvだけでなく、LBもprivateも改善 - 余談 - ageやらsiteやら使えるものを全部補助ロスとして入れたモデルが privateでは最良だった - ただLBが信じられないほど低く、切り捨ててしまった - 自分を信じられていれば・・・ モデル cv mean 補助ロス無し resnet18 0.125 補助ロスあり resnet18 0.151
  61. © Recruit Co., Ltd. All Rights Reserved テーブルパート: 概要 -

    特徴量エンジニアリング - 集約系特徴量 - シフト系特徴量(時系列的側面) - 過去コンペのデータの利用 - Soft Label - indeterminate sampleの扱い - 実用上の有効性について - 学習・推論データの分布を揃える - attribution (病院) 特徴量の有無による2パターンのモデル作成 - 推論時の病院情報によるモデル選択 - 計算リソースの最適化 - GPUを使用した学習 - Polarsによるメモリ効率化 - 推論時のメモリ最適化(chunk処理)
  62. © Recruit Co., Ltd. All Rights Reserved テーブルパート: 特徴量エンジニアリング -

    集約系特徴量 - 様々な単位で集約を行う - patient_id, lv_location, attribution, tile_typeとそのsubset - 特にattribution(病院)単位の集約が有効だった - 病院によって肌の状態や撮影状況・判断者が異なる - 例) 病院、病変部位の平均的な数値に対してどの程度乖離 しているか? - シフト系特徴量 (時系列的側面) - 同じ患者のある病変部位のn年前の病変直径・コントラスト etc… - n年前と現在の病変直径・コントラストの変化量 etc… - 過去コンペデータの利用 - 本コンペと重複した患者の過去の診断結果やskin color等をleft join
  63. © Recruit Co., Ltd. All Rights Reserved テーブルパート: Soft Label

    - indeterminate sampleの扱い - 正例とも負例とも言えないindeterminateなlesion(病変)を label=1(正例), sample_weight=0.5として学習 - 補助ロスのような効果を期待したが、 最終的にはモデルの多様性観点で貢献した - 実用上の有効性について - 疑わしい病変は目検・生検に回すべきなので、Soft Labelは 実用上有効かも? - がん検診等のセンセーショナルな判断を全てMLモデルのみで判断す ることは考えにくい
  64. © Recruit Co., Ltd. All Rights Reserved テーブルパート: 学習・推論データの分布を揃える -

    attribution (病院) 特徴量の有無による2パターンのモデル作成 - attributionの文字列を含む病院系特徴量あり/なしで 2パターンを構築 →テストデータに未知のattributionが出現することに対応 - 推論時の病院情報によるモデル選択 - 病院が既知の場合:attributionを含むモデルで推論 - 病院が未知の場合:attributionを含まないモデルで推論 → 学習時と推論時のデータ分布を揃え、privateで微改善
  65. © Recruit Co., Ltd. All Rights Reserved テーブルパート: 計算リソースの最適化 -

    GPUを使用した学習 (XGBoost & LightGBM) - アンサンブル前提だったため、再現性を犠牲に実験速度を重視 - Polarsによるメモリ効率化 - Pandas使用時、メモリエラーでnotebookが停止 (特徴量数:3000、レコード数:50万) - Pandasはjoinやgroupby処理で一時的に大量のメモリを消費 → 前処理をPolarsに移行し、メモリ使用量を30GB → ~20GBに削減 - 推論時のメモリ最適化(chunk処理) - 全量推論ではDataFrame→DMatrixコピー時にOOMリスクが発生 → 5〜10万レコード単位で推論し、メモリ使用量を抑制
  66. © Recruit Co., Ltd. All Rights Reserved アンサンブル - Weighted

    mean - 画像モデルのOOFを特徴量としてXGBoostに組み込む - 画像とテーブルデータ学習のfoldは揃える - モデルの多様性を意識する - 画像OOFのbackbone・補助ロスの種類を多様に (ConvNext、Swin、ResNet系で散らす) - 特徴量選択、ソフトラベルの有無、病院系特徴量の有無で 分岐させて多様なモデルを作成
  67. © Recruit Co., Ltd. All Rights Reserved - CVとLBはあまり連動しなかった -

    正例が少ないことによる過学習リスクがあった - trainingデータに含まれない病院のデータがpublic/private LBに含まれていた - 7th Solutionは未知の病院を想定したCV戦略を編み出してLBとの高い相関を獲得していた とのこと(すごい) - 基本的にはtrust CVするしかないが、未知の病院のサンプルへの性能についてはLBを参考にした CV / LBについて
  68. © Recruit Co., Ltd. All Rights Reserved - 過学習を避けて多様性のあるパイプラインを作成したことが勝因になった -

    それぞれが独立してモデルの改善をしていったことで多様性に繋がった Overview
  69. © Recruit Co., Ltd. All Rights Reserved - Public LBは機能していなかったので予想よりかなり

    良い順位で驚いた - この金メダルで福山さん(@fyk)がKaggle Master になった 運命のLB確定
  70. © Recruit Co., Ltd. All Rights Reserved - 賞金による金銭的なメリット -

    Kaggleで金メダルと賞金を得る実績を得られた - テックブログ記事を公開することで今後技術者として 使える名刺ができた - メンバー間で作戦会議したりが楽しかった 参加したメリット
  71. © Recruit Co., Ltd. All Rights Reserved - コンペ期間中時間が取られる -

    夜にsubすると結果が気になって目が覚めたりして寝不足になる - winner’s call等が大変 - 深夜1時からの召集がかかる - 我々は日時変更をお願いした&結局ビデオ提出になった - 英語での資料作成 - 子育てとの両立ができず、Kaggle謹慎中 参加したデメリット