ファインチューニングせずメインコンペを解く方法

2026-03-26 松尾研 大規模言語モデル講座2025応用編 修了イベント 技能賞 解法発表
https://weblab.t.u-tokyo.ac.jp/large-language-model/

Transcript

1. ファインチューニングせず メインコンペを解く方法 技能賞 解法発表 pokutuna 2026-03-26 松尾研 大規模言語モデル講座2025応用編 修了イベント
2. 自己紹介 名前: ぽくつな 活動: pokutuna.com 仕事: Web エンジニア 株式会社はてな / の開発 AIを活用したインタビュー分析SaaS
3. 発表内容 • メインコンペ思い出し • チャットテンプレートとは • プロンプト追加による解法 • DSPy & GEPA を利用した指示最適化 ファインチューニングせず メインコンペを解く方法
4. メインコンペ
5. メインコンペ • 構造化出力の精度を競う ◦ ベースモデル: Qwen3-4B-Instruct-2507 ◦ JSON / YAML / TOML / XML / CSV 形式が対象 ◦ データ生成 と 形式変換 の 2 パターン • 評価 ◦ 構文の正しさ + パス & 値のマッチ ◦ 基準点 0.7 が修了条件
6. メインコンペ • 制約 ◦ 推論コードが固定 / 学習データ拡張に制限 • 想定される解法 ◦ ルールベースでデータ拡張 & 整形 ◦ SFT, DPO で学習 & 学習パラメータの調整 🤔 素のモデルでも 0.6 点台が出るらしいぞ... もしプロンプトを書けたら解けるんじゃないか?
7. 推論コード ① 推論コードで apply_chat_template を呼んでいる ② マージ済みモデル merged なら モデルパスのトークナイザがそのまま使われる 🤩 これはチャットテンプレートで解けそうだ
8. チャット テンプレート
9. チャットの生成 • 自己回帰言語モデル • p(t|日本,の,首都,は) → t=東京 • 尤もらしい次トークンを選択 • チャットの生成 ◦ 特殊トークンで話者&区切りを表現 ◦ 思考やツール呼び出しも 特殊トークンで表現している 例: 😀「日本の首都は?」🤖「東京」
10. モデルごとに異なる形式 Tokenizer のチャットテンプレートが表現の差異を吸収 ChatML(GPT-3,4系, Qwen など) <|im_start|>user 日本の首都は?<|im_end|> <|im_start|>assistant 東京<|im_end|> Gemma 系 <start_of_turn>user 日本の首都 は?<end_of_turn> <start_of_turn>model 東京<end_of_turn> Harmony(gpt-oss) <|start|>user<|message|>日本の首都は?<|end|> <|start|>assistant<|message|>東京<|end|> OpenAI API 由来の messages 形式 [{"role": "user", "content": "日本の首都は?"}, {"role": "assistant", "content": "東京"}] チャットテンプレートの適用 Tokenizer.apply_chat_template(...) モデルに応じた形式
11. Jinja2 • テンプレートエンジン ◦ 条件分岐・ループ などロジックが書ける 入力テキストに応じてプロンプトを変えられる ➜ プロンプトチューニングができる!! Qwen3-4B-Instruct-2507 の チャットテンプレートから抜粋
12. チャットテンプレー ト での指示挿入
13. フォーマット検出と指示挿入 • テンプレート内でフォーマットを検出し指示を追加 ◦ タスク1行目最後のフォーマット名が出力形式と仮定 • 追加の指示をuser(入力タスク)の末尾に追加 タスク1行目の例 Please output TOML code:\n Please convert the following CSV code to YAML code.\n
14. 指示プロンプトの調整 対象フォーマット • CSV / JSON ◦ そのままでも十分な精度 • TOML / XML / YAML ◦ 構文エラーやデータの 欠落が目立つ 👉この3つに指示を追加 最適化方法 • DSPy & GEPA を試す DSPy: プロンプト最適化フレームワーク GEPA: プロンプト最適化手法 https://x.com/lateinteraction/status/1966640111979819255 余談: DSPy 回りの読みが 分からない問題への回答
15. GEPA による最適化 改善の流れ 1.プロンプト選択 & 少数の train (minibatch) で推論 & 評価 2.リフレクションモデルで入出力を分析しプロンプトを改善 3.minibatch を再推論 & 評価 → 改善あれば valid で検証 4.valid 各問のスコアと共に候補プールに追加 → 1 に戻る プロンプト候補プール 確率的にサンプルして改善する 学習データ(train) 評価フィードバックを収集する 検証データ(valid) プロンプト候補の性能を追跡する リフレクションモデル 改善プロンプトを生成する 推論モデル このモデル出力を最適化する 評価関数 出力にフィードバックを返す 用意するもの 特徴 • 入出力(実行トレース)を参照して改善 ◦ スコアだけでなくテキストのフィードバックを活用 • 各 valid ごとに最高スコアの候補を残す ◦ 多くのタスクで最良の候補ほど次の改善候補に選ばれやすい [2507.19457] GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning
16. 評価フィードバック • StructEval & 公式学習データを参考に評価関数を作成 ◦ 構文チェック(入力を parse できたら成功) ◦ 期待パス(正解データから抽出 or 生成)を全て含むか • 評価関数のフィードバック ◦ スコア ◦ 不足したパス ◦ 出力の冒頭
17. 最適化の実行 Qwen3-4B-Instruct-2507 (vLLM on RunPod) Qwen3-235B-A22B (OpenRouter) リフレクションモデル 改善プロンプトを生成する 推論モデル このモデル出力を最適化する 評価回数 (budget) train val 所要時間 TOML 815 50 25 54分 XML 790 50 20 95分 YAML 865 35 35 80分 点の散らばりが大きい → 安定した改善が見られなかった(TOML)
18. 最適化の結果
19. 最適化の結果 • TOML (1行) ◦ 初期生成プロンプトからほぼ変わらず, 配列の指示のみ Output ONLY raw TOML. Use [table] for nested objects and [[array]] for arrays. Do not use inline tables. • XML (47行) ◦ JSON 入力時の root 要素の決定 ◦ パス構造の一致ルール, データ型(ISO 8601, UUID)の保持 • YAML (83行) ◦ XML, CSV, JSON からの個別の変換ルール ▪ XML 繰り返し要素のタグ省略、CSV列名のドットはネスト ◦ 学習データの一部が例として指示に含まれることも見られた
20. 最適化の結果 • 提出スコア: 0.756 ◦ ファインチューニングなしに基準点をクリア 🎉 ◦ pokutuna/llm2025-basic-chat-template-only File and versions → chat_template.jinja に実際のテンプレートがあります
21. おまけ: 実モデルのチャットテンプレート活用 • 思考モードの切り替え (Qwen3-32B ほか) ◦ enable_thinking が偽なら </think> を追加し思考タグを閉じる • 思考量のコントロール (gpt-oss-120b ほか) ◦ "Reasoning: " + reasoning_effort • 現在の日付・ナレッジカットオフの追加 (SmolLM3-3B ほか) ◦ "Today Date: " + strftime_now("%d %B %Y") ◦ "Knowledge Cutoff Date: June 2025"
22. まとめ
23. まとめ • メインコンペ思い出し ◦ 改変不可の推論コードにプロンプトチューニングの余地があった • チャットテンプレートとは ◦ Tokenizer に同梱されるモデルに応じた入力の変換レイヤ • プロンプト追加による解法 ◦ タスク1行目から出力フォーマットを検出し指示を追加 • DSPy & GEPA を利用した指示最適化 ◦ 反復的なプロンプト改善を自動化するアルゴリズム