- LFM2.5-350MをGRPOで100ステップ調整し、IFStructスコアが22.6%→29.7%に向上
- JSON成功率は18.0%→31.9%の改善。YAMLは27.2%→27.5%とほぼ横ばい
- 約500サンプルでQwen3.5-2Bの33.15%に迫る。LoRA学習は約600万パラメータ
背景と実行環境
LLMを実際のシステムに組み込むとき、指定した形式で解析可能な出力を返すかどうかは、応答品質と同じくらい重要な判定基準になる。Hugging Faceのブログ投稿は、この「スキーマ適合」に特化したベンチマークIFStructを使い、小規模モデルの改善可能性を検証している。対象モデルはLiquid AIのLFM2.5-350Mで、学習と評価の手順を公開している。
学習はHugging Face TRLのGRPOConfigを利用し、評価はllama.cppが提供するOpenAI互換のAPIサーバ経由で行う。学習処理は、無料枠のColabまたはKaggle GPU(16GB)でも回るように設計されている。このように、比較的低い計算資源で試せる点が記事の特徴だ。
データと報酬設計
学習データにはnvidia/Nemotron-RL-instruction_following-structured_outputsから約500サンプルを使う。各サンプルはプロンプトと、それに対応するJSON Schema、期待されるフィールド数をセットにしたものだ。ただし、そのままではIFStructの評価分布と差があるため、データを2種類の方法で拡張している。
具体的には、40%のプロンプトに「コードフェンスの内側に出力を返す」という指示を追加する。これにより、コードブロックなしで生のJSONを返す癖を防ぐ狙いがある。また、別の20%はスキーマを配列で包み、トップレベル配列を返すタスクに変換している。
報酬関数は3つ定義され、それぞれjson_format_reward、field_count_reward、schema_validation_rewardと呼ばれる。形式が正しくパースできるか、トップレベルのフィールド数が合うか、JSON Schemaの制約を満たすかを0〜1のスケールで評価する。最終的な報酬は重み[1.0, 0.5, 2.0]の加重和で計算される。
IFStructスコアの変化
まず、調整前のLFM2.5-350Mをllama.cppとBF16のGGUFで2000件のIFStruct評価にかけると、全体スコアは22.6%だった。IFStructの公開ブログに記載された21.1%と近い数値で、ローカル環境でもほぼ再現できている。その後、100ステップのGRPOで学習したモデルを同じ評価系で測ると、スコアは29.7%に上がった。
形式別の成績を見ると、JSONの成功率は18.0%から31.9%へと約14ポイント改善している。一方、YAMLの成功率は27.2%から27.5%でほとんど変わらない。この変化は、報酬関数で重点を置いたフィールド数やスキーマ適合の部分に現れており、比較対象として挙げられたQwen3.5-2Bの33.15%に近づいた。
現時点で分かること
この結果は、小規模モデルでもタスク固有の報酬を使った短いRL学習で、形式遵守の信頼性を引き上げられることを示している。LoRAアダプタとして追加された学習パラメータは約600万で、全パラメータの1.66%にすぎない。計算資源を抑えたまま性能を高める手法として注目できる。
その半面、YAMLでは明確な改善が見られず、平均レイテンシも1453msから1518msへとやや増加した。この記事の目的は特定モデルの学習パイプラインの紹介であり、IFStructのベンチマークスコアの再現そのものを狙ったものではない点も補足しておきたい。実務で使う場合には、自社のスキーマや配布形式に合わせた追加評価が必要になる。
| 項目 | LFM2.5-350M(ベース) | LFM2.5-350M(GRPO適用後) |
|---|---|---|
| IFStruct総合スコア | 22.6% | 29.7% |
| JSON成功率 | 18.0% | 31.9% |
| YAML成功率 | 27.2% | 27.5% |
| 平均レイテンシ | 1453ms | 1518ms |
The takeaway is that a cheap, task-specific reward signal can make a small model substantially more reliable about form, closing much of the gap to models several times its size.
要点は、安価でタスク固有の報酬信号が、小さなモデルの形式遵守の信頼性を大幅に高め、数倍大きいモデルとの差を大きく縮められるということだ。
今後の見通し
この手法の有効性は、報酬関数の設計と学習データの分布に依存している。次に試すべきは、ステップ数を増やした場合のスコア推移や、Qwen3.5-2Bなど他の小規模モデルとの比較、自社スキーマでの再現実験だろう。また、YAMLでの改善が小さい点が、形式固有の難しさによるものか、学習タスクの設計によるものかが分かれば、報酬設計を改善する材料になる。
日本の開発者・IT企業にとっての意味
日本のIT企業では、LLMを業務システムや外部APIに接続するとき、JSONの型や必須フィールドの不整合が運用コストを押し上げる。この事例は、大規模APIに依存せず、3.5億パラメータ級のモデルを社内で調整して構造化出力タスクに特化させる選択肢があることを示す。手順はTRLとllama.cppなどのOSSで構成され、報酬関数を自社のスキーマ向けに書き換えれば、請求書やログ解析など特定フォーマットの精度を高められる可能性がある。一方で、学習データと評価データの分布が実業務と異なる場合には効果が変わるため、自社データでの再評価が前提になる。
気になる点
- GRPOとは何か。通常のファインチューニングと何が違うのか
- モデルに同じプロンプトから複数の出力を生成させ、報酬関数のスコアに応じて有望な出力を強化する強化学習の一種。TRLのGRPOConfigで実装され、通常の教師あり学習よりも「形式を守る」といった評価指標を直接最適化しやすい。
- どの程度の計算リソースが必要か
- 元記事のノートブックは、無料枠のColabまたはKaggle GPU(16GB)で動くよう設計されている。LoRAが追加するパラメータは約600万で、推論はMacBook上でllama.cppを使って行える。ただしCUDAなど環境依存の手順は別途確認が必要。
- 自社のJSONスキーマにも応用できるか
- 報酬関数のうち、パース可能性やフィールド数、スキーマ適合を評価する仕組みは汎用性が高い。一方で、自社のスキーマや業務データの分布に合わせたデータセットを作り、評価し直すことが前提となる。元記事のIFStructやNemotronのタスクだけで効果が保証されるわけではない。
用語解説
- GRPO
- 複数の出力サンプルを比較し、報酬に応じてモデルの出力分布を調整する強化学習手法。TRLで利用できる。
- IFStruct
- LLMの出力が指定形式を守っているか、JSON Schemaに適合するかを測るベンチマーク。
- LoRA
- 既存の重みを固定し、低ランクの追加行列だけを学習する手法。少ないパラメータ数でファインチューニングできる。
- JSON Schema
- JSONデータの構造や型、必須項目などを定義するための仕様。
- GGUF
- llama.cppなどで使われるモデルファイル形式。BF16や量子化データを保存してCPU/GPUで推論できる。
出典
Fine-tuning a 350M Model for Better Structured Outputs in 100 GRPO Steps
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する