• 第5会 関東kaggler会 NFLコンペ 2026 解法紹介
• NFLコンペの1st solution
• ちゃんとデータを可視化して、仮説を立てて実験して、という見本のような解法
• 人によっても、ボールとの位置によっても、進む方向によっても変わるのは確かに

• Data Centric Kaggle
• Data CentricなアプローチがKaggleで役に立った実例の紹介
• 普通に実務でも大事な話
• 最近はLLMを用いた合成データ作成が盛ん
• データの評価 (の一つ)にUMAPが有効という話。LLM-as-a-Judgeも有用。

概要

実現のための3つの技術的柱

1. メモリへの直接展開による容量制限の回避

• 課題: Lambda（特にSnapStart利用時）のディレクトリは512MBの制限があり、数GBのモデルをディスクに保存できません。また、などのライブラリはモデル読み込みにファイルパス（ファイルディスクリプタ）を要求します。

• 解決策: Linuxのシステムコールである を使用しました。これによりメモリ上に「仮想ファイル」を作成し、S3からダウンロードしたデータをディスクを経由せずに直接メモリへ書き込むことで、ディスクI/Oのオーバーヘッドと容量制限を回避しました。

2. SnapStartによるコールドスタートの解消

• 課題: 4.5GBのモデルをS3からダウンロードして展開すると、初期化に約63秒、推論含め合計80秒以上かかり、実用的ではありませんでした。

• 解決策: Lambda SnapStart を導入しました。モデルのダウンロードとメモリ展開が完了した状態をスナップショットとして保存し、次回以降はその状態から復元します。

• 結果: スナップショット復元時間を約4秒まで短縮し、推論処理の最適化（スレッド数調整）と合わせて、トータル21〜22秒での処理を実現しました。

3. Lambda Web Adapterによるストリーミング配信

• 課題: LLMのチャット体験には、回答を逐次表示するストリーミングが不可欠です。

• 解決策: Lambda Web Adapter (LWA) とFastAPIを組み合わせました。

• 注意点: LWAとSnapStartを併用する際、LWAがモデルロード完了前に初期化完了を報告してしまう問題が発生しました。これを防ぐため、環境変数 を設定し、同期的に初期化を行う必要がありました。

• 結果: 最初のトークンが表示されるまでの時間（TTFT）を 1〜3秒 程度に短縮することに成功しました。

まとめと知見

• : GB級のファイルをLambdaで扱う際、ディスク容量制限を回避する強力なテクニックとなる。

• SnapStart: LLMに限らず、初期化処理が重いLambda関数のコールドスタート対策として有効。

• Lambda Web Adapter: PythonランタイムでWebフレームワークを動かし、ストリーミングなどを実現するための強力なツールである。

QE手法

• Q2E (Query2Expansion):
• LLMを利用して、元のクエリに関連する追加のキーワードやフレーズを生成し、これを元のクエリに追加することで拡張

• Q2D (Query2Doc):
• LLMにクエリに対する「疑似回答ドキュメント」を生成させ、これを拡張として利用

• GaQR (Generation-augmented Question Rewriter):
• LLMを用いて、元のクエリをより検索に適した形に書き換える手法。これは、特定のキーワードを追加するのではなく、クエリ全体の表現を調整することで、検索の精度や網羅性を高めることを目指す。

研究課題

実験設定

主な結果

• LLMが知識を欠く場合、QEの改善効果が大幅に低下

• Q2EとQ2Dは知識がある場合に有効だが、知識不足時はGaQRの方が安定

• 密検索モデルはQEで性能が低下する傾向があるが、LLMが知識を持つ場合は悪影響が軽減

• 高曖昧度クエリではRecall@100の改善が小さい

• LLMは人気のある解釈を優先し、マイナーな解釈を見落とす傾向（popularity bias）

• GaQRは人気度に関わらず安定した性能を示す

結論

1. イントロダクション

現状の課題: スキーマの複雑性とロジックの分離

• 現実世界のデータベーススキーマの構成要素数千ものテーブルで構成されるスキーマを正しく結合してクエリするために必要な、高度なドメイン知識。

• 企業による対応策SQLエンジンの上に構築される「セマンティックモデリング層」(LookerやTableauなどのBIツール)。

問題点: SQLユーザーの置き去り

• BIツールの制約ツールで定義された便利なビジネスロジック(例:「解約率」の計算式)が、そのツールの外では利用不可能という問題。

• 直接SQLを書くユーザーへの影響データサイエンティストやエンジニアがBIツールと同じロジックをSQLで再実装(コピー&ペースト)しなければならず、ロジックの不整合やメンテナンスコストの増大を招く状況。

提案: GoogleSQLの拡張

• 本論文のアプローチGoogleの社内標準SQL(GoogleSQL、BQやSpannerで利用)を拡張し、セマンティックモデル自体をSQLの中で定義・利用可能にする提案。

• 期待される効果BIツールを使うユーザーも、SQLを直接書くユーザーも、共通のビジネスロジックを利用可能にする仕組み。

2. 背景

2.1 セマンティックデータモデリング

1. 分析の崖(Analysis Cliff): BIツールのGUIで表現できない複雑な分析が必要になった瞬間、ユーザーはツールを使えず生のSQLを一から書く必要があり、モデルの恩恵を一切受けられない状況。

2. データのサイロ化(Data Silo): Python、データパイプライン、AIエージェントなど、BIツールのAPIを使えないシステムからはビジネスロジックが利用不可能。

3. All-or-Nothing問題: 従来のモデリングツールは導入コストが高く、組織全体での導入か全く使わないかの二択。

2.2 自然言語クエリ

2.3 グラフクエリ

2.4 構造化データ

2.5 SQLにおける結合

3. 解決策 - SQLの構成要素 (Solution - SQL Building Blocks)

3.1 仮想カラム (Virtual Columns)

• 定義: テーブルにデータを保存せず、クエリ実行時に計算されるカラム。

• 特徴: 既存のView（ビュー）と類似するが、で増分的に追加可能な点が優位。また、他の仮想カラムやサブクエリ（相関サブクエリ）を参照でき、複雑な計算ロジックのカプセル化を実現。

3.2 結合カラムとROW型 (Join Columns and ROW types)

• 結合のオブジェクト化: 「結合（Join）」自体を仮想カラムとして定義する仕組み。
• N:1結合: 親テーブルへの参照を、単一のオブジェクト（STRUCTのような型）として表現。
• 1:N結合: 子テーブルへの参照を、行の配列（ARRAY）として表現。

• パス式によるクエリ: 明示的な句を記述せず、ドット記法でテーブル間を移動可能に。
• 従来:
• 提案: 。

• 自動推論: 外部キーが定義されていれば、自動的に結合カラムとして扱うことが可能。

3.3 水平集計 (Horizontal Aggregation)

• 配列に対する集計: 1:Nの結合カラム（配列として見える）に対し、と集計関数を組み合わせて直接計算する構文。

• 構文: 。

• メリット: 通常、配列を展開（Unnest）後にで元の行に戻す必要があるが、本構文では1行内で展開と集計が完結し、クエリが劇的に簡潔化。

3.4 メジャーカラム (Measure Columns)

• 集計の安全装置: 型を持つ特殊な仮想カラム。

• Grain Locking（粒度ロック）: 最も重要な革新要素。メジャーカラムは、定義された元のテーブル（例：Orders）の粒度（Grain）にロック。

• 仕組み: クエリ内で他のテーブルと結合し行数が増幅しても、メジャーカラムを集計（関数を使用）する際には、自動的に「元のテーブルのキー」で重複排除を実行。

• 結果: ユーザーは「結合による数字のズレ」を気にすることなく、正しい集計結果を取得可能。

4. 解決策 - セマンティックデータモデリング

4.1 セマンティックデータグラフ

• グラフとしてのデータベース: 結合カラム（エッジ）とテーブル（ノード）を組み合わせることで、データベース全体を相互接続されたオブジェクトのグラフとして表現。

• 探索の自由: 任意のテーブルを起点（句）とし、結合カラムを辿って関連データ（属性やメジャー）を引き出すことが可能。

• フラット化: グラフの深い階層にあるデータを、手前のテーブルの仮想カラムとしてフラット化することで、エンドユーザーに複雑な構造を意識させない使い方を実現。

4.2 セマンティックデータグラフの構築

• 増分的構築: 既存の物理テーブルの上に仮想カラムや結合カラムを追加していく方式により、大規模な移行プロジェクトが不要。

• プライバシーの適用: ユーザーIDを非表示にしつつIDを使った結合は許可するといった、フィルタリングされたビューを作成することで、プライバシー保護と分析能力の両立を実現。

5. 分析 (Analysis)

5.1 論理的および物理的なデータ独立性

• 分離の実現: 物理的なストレージ設計（正規化、パフォーマンス最適化）と、ユーザーが見る論理モデル（ビジネス概念、オブジェクト指向的なビュー）の完全な切り離し。

• 実例: 物理的には正規化された多数のテーブルであっても、論理的にはJSONのようなネストされたオブジェクトとしてクエリ可能な仕組み。どちらの形式で保存されているかをユーザーが意識する必要のない設計。

5.2 プロパティグラフとの比較

• SQLとGQLの融合: 本提案のセマンティックグラフと、SQL標準のプロパティグラフ（SQL/PGQ）との概念的な類似性。

• 違い: プロパティグラフ（GQL）における明示的なグラフ定義の必要性と、本提案における既存のSQLスキーマからのグラフ自動推論・利用への重点。

• 相互運用: 同じグラフ定義に対する、SQL（リレーショナルな操作）とGQL（パス探索などのグラフ操作）の両方からのクエリ実現。

6. 関連研究 (Related Work)

既存技術との位置づけ

• ORM（Object-Relational Mapping）: アプリケーション層でオブジェクトとリレーショナルの変換を行う技術。本提案はこれをデータベースエンジン内部で実現するもの。

• 新しいDBパラダイム: DeshpandeやDittrichらが提案する「リレーショナルモデルの完全な置き換え（E/Rモデルや関数型モデルへの移行）」に対する対比。本論文は「SQLの増分的な拡張」による実用的な解決策。

• Pipe Syntax: Googleが別途提案しているSQL構文の改善案（パイプ演算子 を使用）との関係。相互補完的な位置づけ。42。

7. 今後の展望 (Future Work)

7.1 DDLの標準化

7.2 最適化

7.3 マテリアライゼーション

7.4 SQLへのMATCH句導入

付録 A. 例 (Examples)

A.1 情報スキーマ (Information Schema)

複雑なメタデータ

改善

A.2 TPC-H スキーマ

ベンチマークでの実証

安全性の証明

3行まとめ

• Qwen2.5-VL-7B をベースに、SFT（教師あり）と RL（強化学習） を組み合わせた文書解析モデル。

• ただ文字を読むだけでなく、「読み順（Reading Order）」 を報酬関数に組み込むことで、多段組みなどの複雑レイアウトを攻略。

• 7Bという軽量モデルながら、特化学習により 商用ツールや72Bモデルを超えるSOTA を達成。

1. 背景・課題感

なぜこれをやるのか？

• 従来のOCRパイプラインはエラーが累積しやすく、End-to-EndのLVLM（Large Vision-Language Model）が主流になりつつある。

• しかし、LVLMは「文字認識」は強いが、新聞やポスターのような複雑なレイアウトの「読み順」を間違えることが多い（例：左の段から右の段へ読むべきところを、行をまたいで読んでしまう）。

• 単なる「次の単語予測（Next-Token Prediction）」だけでは、この構造的な論理（Logics）を学習しきれない。

2. 提案手法：SFT-then-RL

Step 1: Supervised Fine-Tuning (SFT)

• 目的: 基礎的な認識能力とHTMLフォーマット出力の学習。

• データ: 論文、レポート、化学式、手書きなど30万ページ以上の高品質データ（HTMLアノテーション済）。

• モデル: Qwen2.5-VL-7B。入力解像度を動的に扱い（最大 1024×1024 px）、HTMLを出力させる。

Step 2: Layout-Centric Reinforcement Learning (LC-RL)

• アルゴリズム: GRPO (Group Relative Policy Optimization)。

• 工夫点:
• 報酬設計 (Reward Function): 以下の3つを評価。
1. テキスト一致率: 基本的な認識精度。
2. Box位置精度: 正しい場所を見ているか。
3. 読み順 (Reading Order): 「段落の順序逆転数」 をペナルティとして与え、人間らしい読み順を学習させる。
• Hard-Sample Mining: SFTで「あとちょっとで正解できそう（編集距離 0.5 ∼0.8）」な難易度の高いデータを抽出し、重点的にRLにかける。

3. 結果・評価

• 精度: 総合的な編集距離で 最小値（SOTA） を記録。
• 英語: 0.124 / 中国語: 0.145
• 商用ツール（TextIn, Mathpix）や、パラメータ数が10倍の Qwen2.5-VL-72B すら上回った。

• 読み順: RL導入により、SFT単体時と比べて「読み順の間違い」が激減。多段組み記事も正しく解析可能に。

これは何？

4つの重要な学び

• 新しいインフラの導入は組織的インセンティブに従う - 技術的優位性だけでは不十分

Adoption follows alignment. Teams adopted infra only when it was organizationally incentivized, for example by product goals, leadership priorities, or industry timing.

• 基盤はボトムアップで一時的 - 各技術波（DNNs、GPUs、LLMs）が再構築を強いる

Foundations are layered, bottom-up, and temporary. Each stable layer enables the next, but no foundation is permanent — every wave (DNNs, GPUs, LLMs) eventually forces a rebuild.

• ローカル革新は可能性を証明するが共通基盤なしでは腐敗 - 一般化には再構築が必要

Local innovations prove possibility, but decay without shared foundations. Cutting-edge experiments tend to be coupled to local context and often need to be rebuilt to generalize.

• 有効化・効率性・速度は相乗効果 - モデリングとプラットフォームの進歩が重要

Enablement, efficiency, and velocity multiply each other. Increasingly, they're shaped by both modeling and platform advances working in tandem.

📅 5つの時代（2014-2025）

Era 1-2: 断片化から初期統一（2014-2019）

• 課題: 各チームが独自スタック構築 → Training-serving skew、重複投資

• 初期解: Linchpin DSL、Scorpion推論エンジン

• 学び: 2人のMLプラットフォームチーム、技術的に正しくても組織的インセンティブなしでは導入が進まず

Era 3: 過渡期（2019-2020）

• AutoML: Home Feedの局所最適化がエンゲージメント急上昇も一般化困難

• UFR導入: 統一特徴量表現で基盤リセット

Era 4: 広範な統一（2021-2022）

• 転換点: VPスポンサーシップ、ML Scorecard導入

• 成果: MLEnv採用率 <5% → 95%、TabularML導入でコスト半減

Era 5: フロンティア（2022-2025）

• GPU推論: 効率化でHomefeedエンゲージメント16%向上

• Foundation Models: 大規模埋め込み、16k+ユーザーシーケンス、統一ランキングモデル

🎯 Take Home Message

Platform成功の3つの条件

• 技術的に正しい ≠ 使われる

• エグゼクティブスポンサーシップが転換点

• ローカルチームが可能性を証明

• プラットフォームチームが一般化

• 両者の健全な緊張関係が進化を生む

10年間で見えたパターン

About

背景課題

• RLVRによって最終解の正しさのみを最適化すると、そこに至るまでの探索で冗長な出力や、必要以上に複雑なパターンの試行錯誤をしてしまうことがある

• 長さペナルティで制御すると必要な推論までおとしてしまい、性能が落ちる

• 人間の熟練者は「筋の悪そうはパターンは早い段段階で候補から落としている」、それを再現できないか？

• そこで「この解法と最終回答は適切か？」を判定させるJudgementとして初めに訓練→その重みを使って回答生成を訓練の二段階にわける「JudgeRLVR」手法を提案。正答率＋効率の両取りができた

手法

• 今回は数学課題の推論のみを対象

• Qwen3-30B-A3B（MoE）をCoTデータでSFTしたモデルを利用

結果

正解率と生成長比較

推論スタイル転移

• PPL（perplexity）の上昇→推論スタイルの変化

効率的な推論ができているか？

• JudgeRLVR訓練後、対比マーカーが大幅に減少

• より直接的で効率的な推論パターンへの移行を示唆

どんなもの？

• マルチ報酬RL向けにadvantageの計算方法をGRPOから改良したもの

• GRPOは累積報酬(一連の報酬を足し合わせたもの)をグループ内正規化してadvantageを得る

• GDPOは先に各報酬チャネルごとにグループ内正規化をしてadvantageを得てそれらを合算する

先行研究と比べてどこがすごいの？

• マルチ報酬タスクの場合、従来のGRPOでは報酬の相対的な差異が潰れてしまう。例えばGRPOでは以下のようなケースを同様のadvantageとして扱う
• rollout1: 簡単な中間報酬1.0と簡単なアウトカム報酬が0.0で累積報酬は1.0
• rollout2: 簡単な中間報酬0.0と簡単なアウトカム報酬が1.0で累積報酬は1.0

• GDPOは報酬チャネルでまず正規化してadvantageを計算するため学習信号の表現力が高まる

• 実験的にも、学習曲線の安定性、収束速度、最終性能（正解率、形式遵守、長さ制約遵守、バグ率低減）で一貫して優位な結果を示している

• 「標準偏差正規化を外す」だけの変種(Dr.GRPO)よりも安定で、収束失敗も回避している

技術や手法の"キモ"はどこにある？

1. 各報酬ごとのグループ内正規化で、各報酬チャネルの相対差を保ったadvantageを得る

2. 報酬チャネルごとに報酬の重みづけをした上で1の値を合算した後にバッチ内正規化を行う

どうやって有効だと検証した？

• ツール呼び出し(ToolRLの実験条件に従う)
• 報酬(2): フォーマット報酬、正解報酬
• フォーマット精度と正解率がGRPOやDr.GRPOと比べて向上

• 数理推論
• 報酬(2): 長さ報酬(応答長さが4000トークン未満でr=1)、正解報酬
• AIMEやMATH、Olympiadなどで精度向上と長さ超過率の大幅低減を同時に達成
• 学習曲線ではGRPOが約400ステップ以降で正解報酬が劣化・長さ暴走が増える不安定性を示す一方、GDPOは回復・改善を継続

• コード推論
• 報酬(3): テストパス率報酬、条件付き報酬(応答長さが一定以下で報酬)、バグ報酬(エラーなしで実行できたらr=1)
• 合格率を維持・改善しつつ、長さ超過とバグ率を下げ、3報酬（合格・長さ・バグ）設定でもバランス良く最適化できることを示した

議論はあるか？

• 学習安定化のために条件付き報酬設計を推奨している
• ex; アウトカム報酬を満たしたときのみプロセス報酬を与える。

• GDPOの効果は報酬の粒度・スケールやロールアウト数に依存するため、実タスクに応じた報酬設計と正規化の相互作用を観察する必要がある

• 計算的な追加コストは小さい一方、バッチ内正規化の統計が小規模バッチや極端な分布で不安定化しないよう、実装上のケア（例：ε項、統計の安定化）は重要である

• メモ
• 似た論文としてGiGPOがある
• arXiv.orgGroup-in-Group Policy Optimization for LLM Agent Training