Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
関東Kaggler会_NVIDIA_Nemotron_コンペ_振り返り
Search
rick
August 07, 2026
Programming
120
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
関東Kaggler会_NVIDIA_Nemotron_コンペ_振り返り
rick
August 07, 2026
Other Decks in Programming
See All in Programming
yield再入門 #phpcon
o0h
PRO
0
930
Claude Code全社展開のためにやったことn選~プラグイン302個・コミッター271人を支えるために~
kenchan
4
1.3k
メールのエイリアス機能を履き違えない
isshinfunada
0
220
AIエージェントで 変わるAndroid開発環境
takahirom
2
770
PostgreSQL 18で考えるUUID主キー
kazuhiro1982
0
460
AI時代に設計が 最大の生産性レバーになる 意図駆動開発とデータを消さない設計|Don't Delete Your Data or Your Intent — Design as the Deepest Lever in the AI Era
tomohisa
1
660
Apache Hive: そしてCloud Native Lakehouseへ
okumin
1
200
生成AIで帳票OCRが「簡単に」作れる時代になった?
kon_shou
0
420
VibeCodingからAgenticWorkflowへ
starfish719
0
220
【やさしく解説 設計編・中級 #1】一つの車に、運転手は一人 ~ある倉庫システムの事例から~
panda728
PRO
0
200
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
530
霧の中の代数的エフェクト
funnyycat
1
460
Featured
See All Featured
KATA
mclloyd
PRO
35
15k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
980
Ethics towards AI in product and experience design
skipperchong
2
340
Discover your Explorer Soul
emna__ayadi
2
1.2k
A Tale of Four Properties
chriscoyier
163
24k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
It's Worth the Effort
3n
188
29k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
480
Bash Introduction
62gerente
615
220k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
Transcript
NVIDIA Nemotron コンペ 振り返り Team: kansai-kanto-kaggler
自己紹介 kansai-kanto-kaggler 連合 関東 関東 関西 2
Agenda 01. コンペ概要 02. 上位解法と私たちの取り組み 03. 学習トレース作成における工夫 04. モデル学習における工夫 3
Agenda 01. コンペ概要 02. 上位解法と私たちの取り組み 03. 学習トレース作成における工夫 04. モデル学習における工夫 4
コンペ概要:目的 目的 NVIDIA 「Nemotron-3-Nano-30B」 の推論能力の向上 【例】 • 12 ◯ 5
= 17 • 8 ◯ 3 = 11 • 7 ◯ 9 = 16 ◯は足し算を 表していそう… お題 推論(隠されたルール) 暗号パズルの解読 複数の「入力 → 出力」の例から背後 にある変換ルールを推論し、最後の問 題に適用して答えを導く暗号パズル形 式の知能評価タスク 【問題】 20 ◯ 7 = ??? お題イメージ 20+7=27だ! 5
コンペ概要:評価指標と制約 評価指標 正答率(Accuracy) • 文字列出力:完全一致 • 数値出力:誤差 1e-2 以内 コンペの制約
01 LoRAアダプタのみ提出可能 02 外部プログラムの実行不可 提出できるのは LoRAアダプタの重みのみ。 ベースモデルの変更や前処理/後処理、 複数のアンサンブル構築などは一切不可。 推論制限 • temperature = 0 • 1問につき入出力で最大 8192 トークン まで生成可能 これを超える長さの推論トレースは途中で 強制終了となり不正解となる。いかにCoT を短縮するかがポイント。 推論時にPython等のプログラムは実行 できない。そのため、推論トレース(CoT) 自体をテキストとして出力して、解を導く 必要がある。 6
コンペ概要:7つのタスクカテゴリ カテゴリ 特徴 難易度 bit_manipulation (ビット演算ルールの推論) 入力ビット列から出力ビット列への変換規則(AND, OR, NOT・・・)を推論する。 難
cipher (暗号文の復号) 与えられた暗号文と平文のペアから、適用されている換字式暗号や転置式暗号などの ルールを特定する。 易 cryptarithm (覆面算の推論) アルファベットや記号などの文字に置換された数字・演算子の対応関係を特定し、数式 を成立させる。 難 equation_numeric (記号が表す演算の推論) 未知の記号に割当てられた算術演算とその一貫した規則性を解明する。 難 gravity (重力加速度の推定) 落下時間と落下距離の例から重力加速度 𝑔 を推定し、別の落下条件に適用する。 易 numeral (ローマ数字ルールの推論) 整数とローマ数字の対応例から表記ルールを推論し、未知の整数をローマ数字に変換す る。 易 unit_conversion (変換係数の推定) 入力値と出力値の対応例から変換係数を推定し、未知の値を変換する。 易 7
公開ベースラインの紹介 中盤時点で1位だったコードが公開され、参加者全員のデファクトスタンダードとなった。 01 決定論的なソルバーの構築 02 推論過程(CoTトレース)の出力 03 トレースを用いたSFT学習 • 各カテゴリの法則をプログラムで解く
• ソルバーの思考プロセスをテキスト化 • LLMにCoTトレースを学習させる • 「入力データ→変換ルール」を逆算・ 復元するPythonロジックを実装 • モデルが真似しやすいよう、曖昧さを排 除した明示的な思考手順を記述 • 入力プロンプト部分をマスクし、CoT思 考プロセスのみを最適化ターゲットに • ルール抽出の成功率を高め、教師 データの質を担保する • 最終出力を一貫したフォーマットで厳 密にカプセル化 • 決定論的なソルバーの思考プロセスを モデルに模倣させる LLM自体を、決定論的ソルバーと同じステップで考え、動く仮想マシンとして振る舞わせる 8
コンペの戦い方 トレース長は有限、探索範囲は広い。だからこそ、行き先を絞りながら進む必要がある。 START 悪い探索 START 良い探索 届かない GOAL 行き先を絞れないと、限られた距離(トレース長)の 中でゴール(正解)にたどり着けない。
GOAL ルール空間や仮設空間をうまく選べば、限られた 距離(トレース長)でもゴール(正解)に到達できる。 9
コンペの戦い方 基本的にはデータの質を高めることが最優先で、学習で取りこぼしをなくしていく。 問題の本質にあった仮設空間を選ぶことで、 無駄な探索を減らし、正解にたどり着く確率を高める 長く複雑な回答の中から、本質的な論理だけを抽出・圧 縮することで、モデルが模倣しやすくなり学習が安定する モデルがつまづきやすいケースを特定し、重点的に学習する ことで苦手を克服し、全体の予測精度を底上げする 10
Agenda 01. コンペ概要 02. 上位解法と私たちの取り組み 03. 学習トレース作成における工夫 04. モデル学習における工夫 11
上位解法 / 私たちの取り組み bit_manipulation のアプローチ cryptarithm(deduce) のアプローチ 97.5% 1位 •
• HEX(16進数)圧縮によるトークン節約 ルールカタログによる修復アルゴリズム 42.9% • 署名カタログをモデルに暗記させ、深さ優先 探索 99.1% 2位 • • HEX(16進数)圧縮によるトークン節約 系列分解 • • HEX(16進数)圧縮によるトークン節約 ルール適用順序の動的変更 27.8% • • • • 10位 (私達) • • ベース ライン 5つのテンプレートに集約・整理 ビット配列の両端アンカー絞り込み cryptarithmが解けていた1位 はぶっちぎりのスコアだった。 • bit_manipulationが解けてい るチームは金圏に入っている傾向 が見られた。 • 各カテゴリの解き方はチームによっ て大きく異なっていた。 乗算パターンの暗記 効率的なバックトラックの実行 99.4% 4位 • 改善なし 89.4% 3位 上位解法のトレンド 改善なし 私たちの取り組み • bit_manipulationと equation_numericに対して、 高水準な回答性能を持つトレー スを作成した。 • 苦手データの再学習やハイパラ 調整を通じて、トレースの考え方 を効果的に学習することができた。 98.8% キーテーブル方式による仮設空間の再定義 ビット配列の両端アンカー絞り込み 85.1% 改善なし 8.2% 12
主要なソルバー改善: bit_manipulation ナイーブな総当たり検索 𝑝, 𝑞 = 0,1 , 0,2 ,
⋯ , 6,7 𝑥 0 𝐴𝑁𝐷 𝑥 1 → 𝑚𝑖𝑠𝑚𝑎𝑡𝑐ℎ 𝑥 0 𝐴𝑁𝐷 𝑥 2 → 𝑚𝑖𝑠𝑚𝑎𝑡𝑐ℎ 𝑥 0 𝐴𝑁𝐷 𝑥 3 → 𝑚𝑖𝑠𝑚𝑎𝑡𝑐ℎ ⋯ 全ペアを試行 各出力ビットごとに、標準的な論理演算 (AND, OR, NOT, XOR)の組み合わせを 総当たりで試行していた。 トレースが非常に長くなり、3入力なども試せ ず精度は85%で頭打ち。中間過程を圧縮 すると論理の飛躍が生じ、モデルが学習でき ない。 3入力×キーテーブル方式 𝑜𝑢𝑡 𝑖 = 𝐹 𝑟𝑜𝑡𝑙 𝑥, 𝑎 𝑖 , 𝑠ℎ𝑙 𝑥, 𝑏 𝑖 , 𝑠ℎ𝑟 𝑥, 𝑐 𝑖 𝐹: 3入力ブール関数 𝑎, 𝑏, 𝑐: シフト/ローテートのオフセット Point 1: 境界ビット制約 シフトで溢れたビットが0になるという境界条件を活用。これにより、 オフセット候補の探索空間を数千通りから数十通りに削減。 Point 2: キーテーブルの作成 例から「3ビット入力状態→出力ビット」の対応表を生成する。論 理的な矛盾が1つでも発生した候補関数は即座に枝刈りする。 「1ビットずつ順番に推論する」無駄を排除し、「ビット配列全体に共通 するシフト則と真理値表(キーテーブル)」へと定式化し直すことで、 記述効率を劇的に改善 精度向上 85.1% → 98.8% 13
記事紹介 Kaggleコンペ紹介:NVIDIA Nemotron Model Reasoning Challenge 詳細な解法はこちらから 14
Agenda 01. コンペ概要 02. 上位解法と私たちの取り組み 03. 学習トレース作成における工夫 04. モデル学習における工夫 15
前提:学習データ =「解き方の実況」 このコンペの SFT データは、ルールベースの reasoner が生成する“決定論的トレース” ① reasoner が問題を解く
② SFT でトレースを模倣 ③ 推論は temperature=0 解く過程を全行出力 = 決定論的トレース モデルは解き方の 次トークンを学ぶ (暗記) トレースを“なぞれれば” 正答できる つまり 「何を学ばせるか」= トレースの書き方そのものが精度を決める。 担当:データ作り(中間1位の方の公開パイプラインを流用、変更したのはトレースだけ) 16
終了2日前:ポテンシャルはあるのに、モデルが学習できない Rick さんが bit_manipulation の効率の良いトレース案を発見 ― これが金メダルの種になった 解ける問題(被覆) 98.8% 旧エンジン
85% から大きく向上 SFT 後の正答 なのに 103/169 旧トレースの 153/169 から悪化 正解トレースは作れるのに、モデルが学習できない。 「何がいけないのか?」を分析してトレースを改善した ― 今日の話。 17
定義:学習できるトレース = モデルが“なぞれる” 各行を「直前までに書いた情報」だけから 決定論的に再現できること 同じ問題・同じ結論でも、導出を書くか飛ばすか で学習可能性が変わる: ✗ 論理の飛躍あり ―
学習できない ✓ 飛躍なし ― 学習できる 問題:x×y=12, x+y=7 問題:x×y=12, x+y=7 導出:―(書かれていない) 導出:x+y を確認 → (1,12)=13 (2,6)=8 (3,4)=7 ✓ 結論:x=3, y=4 結論:x=3, y=4 どう探したかが無い = 再現できない 各手が見える = そのままなぞれる 条件: ① 飛躍(隠れ推論)を書かない ② 問題ごとに違う列挙・値を残さない ③ 分岐は直前の表から導ける 被覆(解けること)だけでは不十分 ― “なぞれる”形かどうかが学習可能性を決める。 18
実例:トレース改善の詳細 元(抜粋) 改善後(抜粋) Before: conflict の“結論だけ”を1行で書く(いきなり bit2 から) List: a3b4c1
a3b4c2 a3b4c3 a3b4c4 a3b4c5 …(98個を列挙) Try a3b4c1 -> bit2 (5,6,1): 111>0 010>0!=1 conflict Try a3b4c2 -> bit1 (4,5,-): 010>0!=1 conflict Try a3b4c3 -> bit1 (4,5,-): 010>0!=1 conflict After: どの Try も bit0 から探索し、conflict で打ち切る Try 1: a3b4c1 bit0 (3,4,-): 000>0 100>0 010>1 000. 110>0 100. 010. bit1 (4,5,0): 011>0 000. 101>0 000. 110. 011. 100. bit2 (5,6,1): 111>0 010>0!=1 conflict Try 2: a3b4c2 bit0 (3,4,-): 000>0 100>0 010>1 000. 110>0 100. 010. …(以降も同じ構造で続く) 「結論だけ」→「bit0 から探索・conflict で打ち切り」に統一。 どの Try も構造的に同一になり、モデルが再現できない情報が消える。 19
方法:ズレを見つけて直すループ ① 生成して照合 ② ズレの行を特定 出力を正解と行単位で比較 一致が切れる“最初の行”を見つける ↻ ④ 再学習して再測定
③ なぞれる形に書換 ズレが消えたかを確認 その行だけを直す ズレが消えるまで回す ― bit_manipulation では、このループで 103 → 152 まで回復。 20
分析:生成出力は正解と「どこから」ズレるか 不正解の出力を 正解トレースと行単位で照合すると―― ここからズレ始める 生成出力 前半(転記・計算)は一致 → “候補列挙”の行から崩れて暴走する 正解 :
…前半一致… 候補 a1 a2 a3 a4 a5 a6 → 検証 → 答え 生成 : …前半一致… 候補 a1 a2 a3 a1 a2 a3 a1 a2 … 繰り返して答えに未到達 長さの問題ではない。最初にズレる行 = モデルが再現できない行(候補列挙)。 対応:列挙を消す・Try に番号を付ける・紛らわしいラベルを言い換える ― その行だけ書き換えた。 21
結果:103 → 152 → 162 bit_manipulation held-out 169問での正答数 発見した案を そのまま学習
トレース改善(私) 学習の工夫(eikichi さん) 103 152 162 被覆は 98.8% と高いのに +49 ― なぞれる形に書換 最後の一押し → 次のパート 私の改善は「可能性を引き上げた」まで。仕上げの 152 → 162 は、この後の eikichi さんパート で。 22
まとめ:エージェントで改善する「外枠」を作る 「どうすれば改善されるか」を 言語化 → ルール化 し、 その範囲内で繰り返し改善させる “外枠” を作る のが有効
外枠(改善のフレーム) ① 言語化 ② ルール化 ③ 範囲内で反復 ↻ 何が「良い」かを言葉に 例:なぞれるトレース 条件・手順に落とす 例:条件3つ+照合ループ ルールの中で回し続ける 例:103 → 152 人がやるのは“外枠の設計”。枠の中の反復は エージェント(モデル)に任せられる。 その外枠の設計自体も、失敗の教訓をルール化するたびに、任せられる範囲が広がっていくはず。 23
Agenda 01. コンペ概要 02. 上位解法と私たちの取り組み 03. 学習トレース作成における工夫 04. モデル学習における工夫 24
学習での狙い 推論途中でトレースが崩れること減らし、 正解トレースの解法をできるだけ保持する 25
主な内容 決定論的トレースをSFT 01 カテゴリ別solverで正しい解法トレースを作る モデルの苦手問題を特定し、重点的に再学習 02 崩れやすいトレースをlogprobを用いて抽出 データを2倍にして再学習 LoRA alphaの調整
03 lora_alpha / r = 4 の強気の設定でトレース追従性を強化 26
主な工夫 決定論的トレースをSFT 01 カテゴリ別solverで正しい解法トレースを作る 説明済み モデルの苦手問題を特定し、重点的に再学習 02 崩れやすいトレースをlogprobを用いて抽出 データを2倍にして再学習 LoRA
alphaの調整 03 lora_alpha / r = 4 の強気の設定でトレース追従性を強化 27
モデルの苦手問題を特定し、重点的に再学習 考え方 推論制約で temperature=0 のため、出力は各ステップの最大確率token に固定される。 そのため、一度誤った判断をすると、以降の推論が連鎖的に崩れる。 学習済みモデルが 正解トレースを自信をもって再現できているのかを確認・対策したい 28
パイプライン 01 トレース Corpus作成 02 Stage 1 SFT 03 min
logprobs を出力 Prompt と正解トレースを固定 通常データでLoRA adapterを作成 このadapter自身の苦手トレースを見る トレース毎のtokenのlogprobsを確認 min logprobをトレースの評価値とする 04 苦手問題の抽出 05 Replay Corpusの作成 06 Stage 2 SFT 各トレースにおいて評価値から閾値以下 (今回は-0.69)を抽出 苦手問題として抽出されたサンプルを 2倍複製してCorpusを再作成 苦手問題を2倍複製したCorpusで 1から再度学習(追加学習ではない) Stage1とStage2のbit_manipulationで 152 → 162 の改善 29
min logprobs を出力 実装の流れ 各問題トレースの min を取得 生成ではなく、トレースの logprobを取得 トレース部分を抽出・評価
prompt + トレースをfull textとしてvLLMに渡し 各token位置のlogprobsを取得 prompt_logprobsは全token分のリストのため prompt部分を除き、 作成トレース部分のtokenで確認 params = SamplingParams( prompt_logprobs=1, max_tokens=1, temperature=0.0, ) outputs = llm.generate(full_texts, params) output = outputs[0] prompt_logprobs = output.prompt_logprobs トレースのlogprobs例 -0.04 -0.12 -0.08 -3.91 -0.20 token 0 token 1 token 2 token 3 token 4 一番低いtokenのlogprobsをトレースの評価値とする 30
主な工夫 決定論的トレースをSFT 01 カテゴリ別solverで正しい解法トレースを作る 説明済み 低logprob の問題を複製して再学習 02 崩れやすいトレースをlogprobを用いて抽出 データを2倍にして再学習
LoRA alphaの調整 03 lora_alpha / r = 4 の強気の設定でトレース追従性を強化 31
LoRA alphaの調整 考え方 推論制約で r=32 のため、このrankの中でいかに正解トレースへ倣うことができるか。 今回決定論的にトレースを再現したい思惑があるため、今回の学習効果をより強めるようにしたい。 lora_alphaを高く設定することで学習効果を強め 正解トレースを再現するようにしたい 32
LoRA alphaの調整 あるSnapshotでの実験 lora_alpha alpha_over_rank CV(3run平均) 32 1 0.872 (828.3
/ 950) 64 2 0.874 (830.3 / 950) 128 4 0.877 (832.7 / 950) 256 8 0.876 (831.7 / 950) 最終Subでの実験 lora_alpha alpha_over_rank CV(3run平均) 32 1 未実験 64 2 未実験 128 4 0.905 (859.7 / 950) 256 8 未実験 lora_alphaをsweepし、lora_alpha=128(lora_alpha / r = 4)を採用 33
LoRA alphaの調整 あるSnapshotでの実験 lora_alpha alpha_over_rank CV(3run平均) 32 1 0.872 (828.3
/ 950) 64 2 0.874 (830.3 / 950) 128 4 0.877 (832.7 / 950) 256 8 0.876 (831.7 / 950) じゃあ実際はどうだったのか? 最終Subでの実験 lora_alpha alpha_over_rank CV(3run平均) 32 1 未実験 64 2 未実験 128 4 0.905 (859.7 / 950) 256 8 未実験 lora_alphaをsweepし、lora_alpha=128(lora_alpha / r = 4)を採用 34
LoRA alphaの調整(追加検証) あるSnapshotでの実験 lora_alpha alpha_over_rank CV(3run平均) 32 1 0.872 (828.3
/ 950) 64 2 0.874 (830.3 / 950) 128 4 0.877 (832.7 / 950) 256 8 0.876 (831.7 / 950) 最終Subでの実験 lora_alpha alpha_over_rank CV(3run平均) 32 1 0.900 (855.3 / 950) 64 2 0.896 (851.3 / 950) 128 4 0.905 (859.7 / 950) 256 8 0.904 (858.7 / 950) lora_alpha=128がCVベストは変わらず 35
LoRA alphaの調整(Late Subによる追加検証) Gold border 最終sub 結果として最終Subの選択は変わらなかったと考えられるが、慎重な検証は必要 36
〜 Fin 〜 ご清聴ありがとうございました