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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 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…

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

© Recruit Co., Ltd. All Rights Reserved コンペ概要 ● 文字数制限 ○ Guesserが行う質問は750文字以内 ○ 推定する単語は100文字以内 ● 実行時間の制限 ○ 各ラウンドで各エージェントが使用出来る時間が60秒与えられる ○ 上記に加えてゲームを通じて使用できる時間が300秒与えられる ● 実行環境 ○ Disk: 100GB ○ RAM: 16GB ○ GPU: T4 x1 ● 提出数 ○ 最新の提出２つが評価に使われるその他詳細 24

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 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? 開始・終了文字辞書順含有文字

Slide 29

Slide 29 text

© 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\?$

Slide 30

Slide 30 text

© 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}" } ]

Slide 31

Slide 31 text

© 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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© Recruit Co., Ltd. All Rights Reserved Guesser ● 事前計算で得られる以下の値は一旦所与のものとして話を進める ● これらの生成方法については後述する推論 - 前提条件 33 Guessの探索対象となるキーワードの集合 Askで使用する質問の集合事前計算キーワードリスト生成質問生成確率値ラベリング環境上のAnswererが、ある質問とキーワードのペアに対して “yes” と返す確率

Slide 34

Slide 34 text

© Recruit Co., Ltd. All Rights Reserved ● ラウンド目のGuess時において、Guesserはそれまで行った質問と解答のペアが与えられることになる ● このとき、あるキーワードが正解となる事後確率が計算可 Guesser 推論 - キーワード推定 34 確率値ラベリングで計算済みの値事前分布 ● 最も確率の高いキーワードをGuessに使用する (MAP推定) 推論キーワード推定質問選択

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

© 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 事前計算キーワードリスト生成質問生成確率値ラベリング

Slide 39

Slide 39 text

© 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個生成重複削除

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

© 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 事前計算キーワードリスト生成質問生成確率値ラベリング

Slide 43

Slide 43 text

© 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) ラウンド後半になるにつれ、具体的な質問になっていく

Slide 44

Slide 44 text

© 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

Slide 45

Slide 45 text

© Recruit Co., Ltd. All Rights Reserved ● ペアのAnswererがこの手の質問に100%の精度で解答可能なエージェントであるか確認するプロトコルが提案された ○ Guesser ■ 「Is it Agent Alpha?」という質問をし、「yes」と返されたら相手が二分探索に対応していると仮定して質問 ○ Answerer ■ 「Is it Agent Alpha?」と来たら「yes」と返答する ■ 二分探索をする質問に対応する Guesser 推論 - 二分探索 2/2 45

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

© 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 参加メンバー

Slide 56

Slide 56 text

© Recruit Co., Ltd. All Rights Reserved - 皮膚がんの病変の陰性/陽性を予測する2値分類タスク - 画像とテーブルの２通りのデータが与えられた - データ（trainに使えるもの） - 患者数: 1042、病変数: 約40万 - 正例病変数：約400(全体の約0.1%) - 病変の画像 - 15 x 15mm領域の画像 - 患者の年齡、病変の大きさ形状などのメタデータコンペについて

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

© 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

Slide 66

Slide 66 text

© 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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

© 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万レコード単位で推論し、メモリ使用量を抑制

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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