LLM-jp-4.1 モデルの公開

著者：児玉貴志，Yunang Wu

はじめに

LLM-jp ではオープンかつ日本語に強い大規模言語モデルの開発を進めています．2026年4月以降 llm-jp-corpus v4 および llm-jp-corpus v4.1 を用いて訓練した「LLM-jp-4」シリーズを順次公開してきました．これまでに 8B と 33B の2種類の dense モデルと 32B-A3B の MoE モデルを公開しています．

今回，新たに「LLM-jp-4.1」シリーズを公開します．LLM-jp-4.1 では，LLM-jp-4 シリーズの事後学習を改善しており，STEM 分野を中心とした性能向上や Tool Calling 機能の追加などが主な変更点です．

また，チューニング済みモデルに加えて，学習に使用した SFT データおよび DPO データも公開しています．

• チューニング済みモデル
  • llm-jp/llm-jp-4.1-8b-thinking
  • llm-jp/llm-jp-4.1-32b-a3b-thinking
  • llm-jp/llm-jp-4.1-33b-thinking
• チューニング済みモデル（量子化版）
  • llm-jp/llm-jp-4.1-8b-thinking-gguf
  • llm-jp/llm-jp-4.1-32b-a3b-thinking-gguf
  • llm-jp/llm-jp-4.1-33b-thinking-gguf
• 事後学習データセット
  • llm-jp/llm-jp-4.1-thinking-sft-data
  • llm-jp/llm-jp-4.1-8b-thinking-dpo-data
  • llm-jp/llm-jp-4.1-32b-a3b-thinking-dpo-data
  • llm-jp/llm-jp-4.1-33b-thinking-dpo-data

本記事では，これらのモデルの学習方法と評価結果について紹介します．

事後学習

事後学習では，まず Supervised Fine-Tuning（SFT）を行い，その後に Direct Preference Optimization（DPO）を行いました．

SFT

一般タスク向けデータセットの拡充

SFT では LLM-jp-4 で使用したデータに加え，既存サブセットの拡充および新規サブセットの追加を検討しました．候補として用意したサブセットは以下のとおりです．いずれも OSAID に準拠するサブセットです．

• Nemotron-Post-Training-Dataset-v2  （→ nemotron_post_v2_stem）
  • stem サブセットのみ利用
• Nemotron-Math-v2 (nemotron_post_v3_math)
  • high_part00, high_part01, high_part02 サブセットの中で StackOverflow 由来のインスタンスのみを使用
• Nemotron-SFT-Instruction-Following-Chat-v3
  • chat サブセットの中で，seed_dataset が allenai/WildChat-1M 由来のインスタンスのみ使用 (nemotron3_chat_v3)
  •  instruction_following サブセットの中で seed_dataset が synthetic のインスタンスのみ使用 (nemotron3_if_v3)
• Nemotron-SFT-Science-v2 (nemotron3_science_vendor)
  • vendor サブセットのみ使用
• Table-GPT  (table_gpt_train_large)
• Nemotron-SFT-Multilingual-v2 (  nemotron3_sft_multilingual_v2_math_ja_stackoverflow, nemotron3_sft_multilingual_v2_math_ko_stackoverflow)
  • math_ja，math_ko サブセットの中で StackOverflow由来のインスタンスのみ使用

これらのデータについては，元データから質問部分のみを抽出し，推論過程と回答を gpt-oss-120b で再生成しました．

nemotron_post_v2_stem と nemotron_post_v3_math は LLM-jp-4 の SFT でも使用していましたが，LLM-jp-4.1 では使用量をそれぞれ約6倍，約15倍に増やしました．元データには正解が付与されているため，予備実験では，最終回答が正解しているデータのみに絞った SFT も試しました．しかし，最終回答の正誤によらず全データを使用した場合のほうが高い性能を示したため，本学習でも全データを使用しています．

残りの6サブセットは，LLM-jp-4.1 で新たに追加を検討したものです．採用するサブセットを決定するため，本学習の約1/8の規模で小規模な SFT 実験を行いました．具体的には，ベースとなるデータセット集合に候補サブセットを1つずつ追加して SFT を行い，各評価タスクにおけるスコアの変化を測定しました．

結果を以下に示します．図では，ベースラインモデルに対する各評価スコアの増減を可視化しています．

例えば，nemotron3_science_vendor を追加した場合には GPQA Diamond のスコアが大きく向上するなど，データセットの内容から期待される性能向上が確認できました．一方，nemotron3_if_v3 は指示追従を目的としたデータセットであるにもかかわらず，IFBench のスコアが低下するなど，必ずしも期待どおりの効果が得られないケースもありました． そこで，LLM-jp-4.1 の SFT では nemotron3_if_v3 を除外し，平均スコアが向上した残り5サブセットを使用しました．なお，SFT では除外した nemotron3_if_v3 についても，DPO 用の選好データ作成には使用しています．

Tool Calling 機能の追加

LLM-jp-4.1では，ツール呼び出しに対応するため，以下の新しいサブセットを追加しました．

• nemotron_agentic_mix_v0.1.1
  • 21,048件
• nemotron_agentic_mix_v0.1.1_ja
  • 11,174件

nemotron_agentic_mix_v0.1.1 は，NVIDIA Nemotronが公開している以下のサブセットを組み合わせたものです．

• nvidia/Nemotron-Agentic-v1 (interactive_agent, tool calling)
  • 19,027件/312,632件
• nvidia/Nemotron-SFT-Agentic-v2 (interactive_agent)
  • 278,878件

これらのデータセットに対しては，(1) LLM-jp学習用フォーマットへの変換と不良データの除去，(2) データセットおよびツール呼び出しの段数に基づくサンプリング（ソースデータセットの約 3.5 %），(3) 誤ったツール呼び出しのラベル付与，という後処理を施しています．さらに，作成したデータセットを日本語に翻訳し (nemotron_agentic_mix_v0.1.1_ja)，学習データとして利用しています．

特に，ツール呼び出しの段数（連続または並列のツール呼び出し）が多いデータを優先的に抽出しました．段数5以上のデータは各データセットに1〜2%程度しか存在しないため，可能な限り最終的なデータミックスに採用しました．また，翻訳についてはユーザ発話とモデルの応答のみを翻訳対象としました．さらに翻訳後に品質フィルタリングを施しており，翻訳後のデータ量は元データの半分程度です．

また，ソースデータには誤ったツール呼び出し（実行環境がエラーを返す原因となる呼び出し）に対するアノテーションが付与されていないため，こういったツール呼び出しにラベルを付与し，SFT時には学習対象から除外することで，望ましくない挙動を学習してしまうことを防いでいます．

LLM-jp-4 シリーズでは，OpenAI の gpt-oss シリーズで採用されている OpenAI Harmony Response Format をベースとしたチャットテンプレートを使用しています．ただし，LLM-jp-4.1 の開発過程でいくつか独自の変更を加えたため，現在の LLM-jp モデルで使用しているテンプレートは Harmony Response Format と完全には一致しません．主な変更点は以下の2点です．

（１）並列ツール呼び出しへの対応：標準の OpenAI Harmony Response Format では，ツール呼び出しは必ずstop token <|call|> で終わります．LLM-jp-4.1では，複数の呼び出しを並列に行う場合に限り，最後の呼び出し以外を <|end|> で終わる仕様に変更しました．

<|start|>user<|message|>Weather in Tokyo and Osaka, and the time in Tokyo?<|end|>
<|start|>assistant to=functions.get_weather<|channel|>commentary <|constrain|> json<|message|>{"city": "Tokyo"}<|end|>
<|start|>assistant to=functions.get_weather<|channel|>commentary <|constrain|> json<|message|>{"city": "Osaka"}<|end|>
<|start|>assistant to=functions.get_time<|channel|>commentary <|constrain|> json<|message|>{"city": "Tokyo"}<|call|>
<|start|>functions.get_weather to=assistant<|channel|>commentary<|message|>"22C sunny"<|end|>
<|start|>functions.get_weather to=assistant<|channel|>commentary<|message|>"25C cloudy"<|end|>
<|start|>functions.get_time to=assistant<|channel|>commentary<|message|>"14:05"<|end|>
<|start|>assistant

この変更により，BFCLなどのベンチマークにおけるparallelカテゴリの評価が可能になりました．

（２）推論の扱い：標準の OpenAI Harmony Response Format は，直近のターンの推論のみを保持し，それ以前のターンの推論はコンテキストから除外する設計です．これに対し，LLM-jp-4.1 では，学習時・推論時ともにすべての推論をコンテキストから除外しています．比較実験では，すべての推論を除外する方式の方が良好な性能を示したため，現時点ではこの方式を採用しています．ただし，将来的には，ロングコンテキスト性能の向上に合わせて，過去の推論も可能な限り保持する方向へ移行することを計画しています．

回答の簡潔化

LLM-jp-4 には，質問で求められていない内容まで回答に含めるなど，回答が冗長になる傾向がありました．これは実際の利用時の使い勝手を損なうだけでなく，不要な内容を生成することでハルシネーションを誘発する一因にもなります．

そこで LLM-jp-4.1 では，SFT データの推論過程と回答を gpt-oss-120b で生成する際，developer message によって回答を簡潔にするよう明示的に指示しました．具体的には，以下のようなプロンプトを使用しています．

Follow the user's requested format, detail, and item count. Give a correct, sufficient answer.

Unless detail is explicitly requested, answer only what was asked. Do not restate the question or add unnecessary background, examples, alternatives, caveats, next steps. For extraction, classification, translation, rewriting, and exact-format tasks, output only the requested result.

なお，STEM 系のタスクについてはこの指示を適用せず，従来どおり情報量の多い回答を生成するようにしています．

以下の図は，SFT データに含まれる推論過程（Reasoning）と最終回答（Answer）のトークン数を，LLM-jp-4 と LLM-jp-4.1 で比較したものです．LLM-jp-4.1 では推論過程は長くなっている一方，最終回答は大幅に短くなっています．特に reasoning effort が low または medium の場合には，回答部分のトークン数を LLM-jp-4 の半分程度まで抑えることができました．

実際にこのデータを用いて学習したモデルに「SFTとDPOの違いは？」と質問すると，回答スタイルにも大きな違いが見られました．LLM-jp-4 は，SFT で一般的に用いられるデータ形式の説明から DPO の損失関数，さらに疑似コードまで含む長大な回答を生成しました．一方，LLM-jp-4.1 は SFT と DPO の違いを表形式で簡潔に整理し，最後に1文で要約する程度にとどまりました．最終回答の長さは，LLM-jp-4 と比較して約1/5になりました．

このように，必要な情報を維持しながら回答の冗長さを大幅に抑えることで，実際の利用時の使いやすさも改善できたと考えています．

Self System Question

これまでの LLM-jp シリーズでは，いわゆる「自己言及」に関する質問（例：「あなたの名前は？」）に対して，意図しない回答をしてしまうことがありました．これは LLM-jp に限った問題ではなく，教師モデルを用いて事後学習データを生成する近年の手法に共通する課題です．

LLM-jp では，事後学習データの再生成に gpt-oss-120b を用いています．そのため，上記のような質問に対する生成データには，「私は ChatGPT です」といった教師モデル由来の自己言及が含まれるケースが多く見られました．このようなデータを用いると，モデルが教師モデルに由来する自己言及表現を学習してしまいます．

以下は，実際の生成データに含まれていた自己言及の例です．

[1] ID: logical_math_coding_wizard8x22b-51927

<user>

...Dijkstraのアルゴリズムを使用して...Pythonプログラムを書いてください．...

<assistant/final>

...

* Type‑annotated, fully documented and ready for unit‑testing / reuse.

Author : ChatGPT (LLM‑jp‑4)

"""

...

[2] ID: random_to_fixed_multiturn_calm3-8905

<user>

あなたの業界において，患者が抱える主な問題や課題は何ですか？詳細に教えていただけますか？

<assistant/analysis>

User asks about "your industry" - presumably healthcare? As ChatGPT, respond detailing main patient problems/challenges in healthcare industry. Provide detailed list.

生成データに含まれる自己言及を適切に処理すれば，モデルが自身をどのように認識するかをある程度制御できると考えました．そこで，自己言及を含む箇所について，内容に応じて削除，書き換え（例：ChatGPT → LLM-jp-4），またはそのまま維持するフィルターを導入しました．

今回のリリース版では，v1 のルールを採用しています．具体的には，製品として ChatGPT などに言及している会話は会話単位で削除し，それ以外の自己言及は LLM-jp-4 に書き換えました．この処理を生成済みの SFT データに適用して学習した結果，自己言及に関する質問に対して，「LLM-jp-4」と正しく回答する割合は大きく向上しました．

しかし，最終版の学習後に実施したユーザーテストで，このフィルターには別の問題があることが分かりました．自己言及を過剰に書き換えた結果，OpenAI や ChatGPT に関する一般的な知識まで影響を受け，LLM-jp と OpenAI を混同するケースが増えていました．下表でも，v1 は自己認識の正答率が高い一方で，「LLM-jp への誤帰属」や「他社知識」で大きく性能が低下していることが分かります．

フィルター	LLM-jp への誤帰属 ↓（例：「LLM-jpのCEOは誰ですか．」）	他社知識 ↑（例：「GPT-4を開発したのはどこですか？」）	自己認識 ↑（例：「あなたはChatGPTですか？」）
なし	5/26 (19%)	17/18 (94%)	8/24 (33%)
v1 （製品として言及）	14/26 (54%)	9/18 (50%)	23/24 (96%)
v2 （第一・三人称）	2/26 (8%)	18/18 (100%)	16/24 (67%)

そこで，追加実験では v2 のルールを設計しました．v2 では，一人称としての自己言及のみを書き換え，OpenAI や ChatGPT について三人称的に述べている箇所は保持します．また，どちらに該当するか判断できない場合のみ，会話単位で削除します．この変更により，v1 で見られた LLM-jp と OpenAI の混同は大きく改善し，他社に関する知識もほぼ維持できることを確認しました．一方で，自己認識の正答率は v1 より低下しており，自己認識と一般知識の両立にはまだ改善の余地があります．

現在のリリース版には v1 を採用していますが，以上の追加実験から，フィルター設計には改善の余地があることが分かっています．今後は，修正したフィルターを適用した改訂版のリリース，または次期バージョンでの反映を予定しています．

学習

これまでに説明したデータを統合し，約12B tokens からなる SFT データセットを構築しました．このデータセットを3 epoch 学習し，総学習量は約35B tokens となりました．LLM-jp-4 では約5.4B tokens のデータセットを2 epoch 学習していたため，LLM-jp-4.1 では総学習量を約3倍に増やしています．

SFT の大規模化に伴い，学習効率を高めるための最適化も行いました．具体的には，会話単位で attention を計算することで異なる会話間の attention を省略したほか，padding 部分に対する attention，FFN，LM head の計算や，損失計算の対象とならないトークンに対する Cross Entropy の計算を省略しました．これらの最適化を組み合わせることで，8B モデルでは学習速度が約2.7倍になりました．

モデルの学習には，NVIDIA H200 SXM5 141GB HBM3e を8基搭載したノードを最大16ノード使用しました．8B モデルは16ノードで約17時間，32B-A3B モデルは8ノードで約49時間，33B モデルは16ノードで約67時間の学習時間を要しました．

Global batch size は64とし，学習率は全学習期間の最初の5%で 4.0e-5 まで線形に増加させ，続く20%では 4.0e-5 に固定し，その後は学習終了時に0となるよう減衰させています．

DPO

DPO 用の選好データは，DPO 学習前の SFT 済み LLM-jp-4.1 を用いて作成します．指示文には，SFT データの各サブセットから最大20,480件ずつサンプリングしたものに加え，SFT では使用していない安全性データセット ac_self_inst も使用しています．ac_self_inst は AnswerCarefully をもとに作成した合成データセットですが，ライセンス上の理由から再配布していません．各指示文に対して，温度 0.6，top-p 0.95 のサンプリング設定で4件の回答候補を生成します．

生成した回答は，gpt-oss-120b を評価モデルとして採点します．一般的な指示応答では，指示への追従性，内容の正確性，分かりやすさを評価します．安全性に関する指示応答では，危険または不適切な依頼に対して安全に対応できているかを評価します．

採点後，最もスコアの高い回答を望ましい回答，最もスコアの低い回答を望ましくない回答として選択します．1つの指示文につき，望ましい回答 1 件と，最大 2 件の望ましくない回答を組み合わせ，最大2組の選好データを作成します．一般的な指示応答では，最高スコアが6点を超え，かつ最高スコアと最低スコアの差が2点以上ある場合のみ採用します．安全性に関する指示応答では，最高スコアが3点を超え，かつスコア差が1点以上ある場合のみ採用します．さらに，望ましい回答と望ましくない回答について，最終回答部分の長さの比が1.5倍を超える組は除外します．これは，内容の違いではなく，回答の長さそのものによって評価差が生じた選好データを減らすためです．

最終的に，8B モデル用に305,831件，32B-A3B モデル用に269,287件，33B モデル用に89,023件の選好データを作成し，DPO に使用しました．SFT データと同様に，これらの選好データについても公開しています（ライセンス上の理由から再配布できないデータは除く）．

DPO は2 epoch 学習しました．Global batch size は256とし，学習率は全学習期間の最初の5%で 9.0e-7 まで線形に増加させ，続く20%では 9.0e-7 に固定し，その後は学習終了時に0となるよう減衰させています．DPO の β は0.5に設定しています．

評価

続いて，LLM-jp-4.1 シリーズのモデル性能について，一般タスクと Tool Calling に分けて紹介します．

一般タスク

評価ツール

LLM-jp で従来使用してきた llm-jp-eval や llm-jp-judge に加え，今回新たに swallow-evaluation-instruct による評価結果も追加しています．swallow-evaluation-instruct は高難度タスクが充実しているほか，pass@k，すなわち k 個の出力のうち少なくとも1つが正解した割合を算出できる点も特徴です．

swallow-evaluation-instruct

まず，LLM-jp-4 から LLM-jp-4.1 への性能変化をヒートマップで可視化した結果を以下に示します．赤色が濃いほど，LLM-jp-4 からの性能向上が大きいことを表しています．LLM-jp-4.1 については，SFT のみを施したモデルと，SFT と DPO の両方を施したモデルをそれぞれ掲載しています．

今回は swallow-evaluation-instruct が提供するベンチマークの中から比較的高難度のものを選定し，Math，Science，Knowledge & QA，Code，IF（Instruction Following），MT（Machine Translation）の6カテゴリに分類して図示しています．

すべてのモデルサイズにおいて，LLM-jp-4.1 の平均スコアは LLM-jp-4 を上回りました．学習段階ごとの変化を見ると，SFT によって大きく性能が向上し，その後の DPO によってもさらに着実な改善が見られました．

カテゴリ別では，特に Math，Science，IF の3カテゴリで大きな性能向上が見られます．Math と Science については，STEM 系データを増強した効果が大きいと考えられます．一方，IF については指示追従専用のデータを大幅に増やしたわけではないため，STEM 系の問題をより正確に解けるようになったことが，結果として指示追従性能の向上にも寄与した可能性があります．

Knowledge & QA は，事後学習のみで大幅に性能を向上させることが比較的難しい領域と考えています．一方，Code については依然として改善の余地が大きく，今後重点的に取り組みたいカテゴリの一つです．

reasoning effort を medium および low に設定した場合についても，同様に可視化した結果を以下に示します．

次に，既存のオープンウェイトモデルとの比較結果をモデルサイズ別に以下に示します．ここでは，各評価カテゴリの平均スコアを掲載しています．LLM-jp モデルと gpt-oss では reasoning effort を high に，Olmo-3-7B-Think，Olmo-3.1-32B-Think，Qwen3，Qwen3.5，Qwen3.6，Gemma 4 では enable_thinking = True に，Qwen3.8-27B と Muse-Glimmer-30B では reasoning effort を xhigh に設定して評価しています．

2026年9月30日追記 Qwen3.8-27B および Muse-Glimmer-30B の Code カテゴリの性能について，現行の評価ツールでは，問題文に明示されていない実行環境上の制約により，多くの有効な Python コードが不正解判定されていることを確認しています．本スコアは現行の評価ツールに基づく値としては正しい一方，モデルの実際のコーディング性能が過小評価されていることにご注意ください．

まず，33B モデルについて見ると，llm-jp-4.1-33b-thinking は Olmo-3.1-32B-Think や Qwen3-32B を上回る平均スコアを記録し，gpt-oss-120b とほぼ同等のスコアとなりました．一方，Qwen3.8-27B，Gemma-4-31B-it，Muse-Glimmer-30B と比較すると，平均スコアではやや差が残っています．カテゴリ別に見ると，特に Math や Science には改善の余地が大きく残っています．

32B-A3B および 8B モデルについても，LLM-jp-4.1 では LLM-jp-4 から性能が向上し，高性能な既存モデルとの差を着実に縮めています．特に IF では比較的高いスコアを記録している一方，Math や Science には依然として改善の余地が残っています．

なお，Math カテゴリに含まれる AIME については，公開されている Olmo 3 の SFT データセットを利用することでスコアが顕著に向上することを，LLM-jp 内部の実験で確認しています．一方，同データセットには ChatGPT の出力を利用したデータや，取得元ウェブサイトの利用規約との整合性に注意を要するデータが含まれており，ライセンスや利用条件の観点からそのまま利用することは難しいと判断しました．そのため，LLM-jp-4 および LLM-jp-4.1 の学習では使用していません．

LLM-jp では，学習データのライセンスや利用条件をサブセット単位で確認し，利用可能と判断したデータのみを使用しています．このような制約のもとでも，LLM-jp-4.1 で高難度タスクの性能を大きく向上させられたことには，一定の意義があると考えています．今後もデータの適切な利用を前提としつつ，高難度タスクを含むさらなる性能向上に取り組んでいきます．

llm-jp-eval

まず，日本語タスクの評価結果を示します．LLM-jp モデルおよび gpt-oss では reasoning effort を high に，Qwen3-8B では enable_thinking = True に，Qwen3.8-27B では reasoning effort を xhigh に設定して評価しています．各評価カテゴリの詳細についてはこちらをご参照ください．

LLM-jp-4.1 では，すべてのモデルサイズにおいて，LLM-jp-4 と比較して平均スコアが向上しました．特に大きな改善が見られたのは，試験問題（JMMLU，MMLU-ProX，GPQA など），基礎解析（固有表現認識など），コード生成（MBPP，JHumanEval），指示追従（M-IFEval）です．

既存のオープンウェイトモデルと比較すると，8B モデルでは Qwen3-8B や gpt-oss-20b を上回る平均スコアを記録しました．また，33B モデルでは gpt-oss-120b に近いスコアとなっています．一方，Qwen3.8-27B は，特に指示追従で高いスコアを記録しており，全体としても高い性能を示しています．LLM-jp-4.1 では LLM-jp-4 から着実に差を縮めているものの，こうした高性能モデルとの差は依然として残っており，引き続き性能向上に取り組んでいきます．

続いて，英語タスクの評価結果です．

日本語タスクと同様に，LLM-jp-4.1 では，すべてのモデルサイズにおいて LLM-jp-4 と比較して平均スコアが向上しました．

一方，既存のオープンウェイトモデルと比較すると，8B モデルでは LLM-jp-4.1 でも Qwen3-8B や gpt-oss-20b には及んでいません．日本語性能を維持しつつ英語性能も高められるよう，今後も両者のバランスを意識した開発を進めていきます．

最後に，高難度タスクをピックアップした評価結果をご紹介します．

MMLU については，英語版・日本語版ともに既存オープンウェイトモデルと同程度のスコアを記録しています．一方，GPQA Diamond や AIME では，LLM-jp-4.1 で LLM-jp-4 から大幅な改善が見られたものの，既存のオープンウェイトモデルとの差は依然として残っています．この傾向は，swallow-evaluation-instruct で得られた結果とも整合しています．

llm-jp-judge

llm-jp-judge による評価結果を以下に示します．reasoning effort を指定可能なモデルについては，medium に設定して評価しています．

	MT-Bench (JA)	MT-Bench (EN)	AnswerCarefully	llm-jp-instructions
gpt-4o-2024-08-06	7.29	7.69	4.00	4.07
gpt-5.4-2026-03-05	8.87	8.89	4.43	4.82
gpt-oss-20b	7.33	7.85	3.55	3.16
llm-jp-4-8b-thinking	7.54	7.79	3.69	3.54
llm-jp-4-32b-a3b-thinking	7.82	7.86	3.70	3.61
llm-jp-4-33b-thinking	8.00	8.24	3.79	3.79
llm-jp-4.1-8b-thinking	7.58	7.67	3.92	3.67
llm-jp-4.1-32b-a3b-thinking	7.69	7.85	3.91	3.79
llm-jp-4.1-33b-thinking	7.76	7.98	4.08	3.83

LLM-jp-4 と LLM-jp-4.1 を比較すると，MT-Bench のスコアはおおむね横ばい，もしくは若干低下しています．MT-Bench は情報量の多い回答が高く評価される傾向があるため，今回の事後学習で行った回答の簡潔化がスコアに影響している可能性があります．LLM-jp-4 までは MT-Bench を主要な評価指標の一つとして用いてきましたが，スコアが頭打ちになりつつあることも踏まえ，LLM-jp-4.1 では補助的な評価指標として位置付けています．

一方，日本語安全性ベンチマークである AnswerCarefully と，日本語質問応答ベンチマークである llm-jp-instructions では，LLM-jp-4.1 で改善が見られました．llm-jp-instructions では，回答の正確性や情報量などをサブ指標として評価しています．詳細を見ると，回答の情報量は低下した一方で，正確性は向上していました．回答を簡潔にしたことで，ハルシネーションや不要な情報の生成が抑えられ，結果として回答の安全性や正確性の向上につながった可能性があります．

Tool Calling

LLM-jp-4.1 では，新たにエージェント関連のタスクを評価対象に加えました．LLM-jp-4.1 は，LLM-jp シリーズで初めてツール呼び出しに対応したモデルであることから，ツール呼び出し能力を評価する代表的なベンチマークである BFCL と τ²-bench を採用しています．さらに，日本語でのツール呼び出し能力を評価するため，BFCL-nejumi における性能も測定しました．なお，LLM-jp モデルについては，reasoning effort を medium に設定して評価しています．

英語 tool calling

英語のツール呼び出し評価には，以下のベンチマークを採用しました．

• BFCL
  • BFCLでは，v3までのカテゴリのみを評価に使用しています．そのため，v4で追加したweb search/memoryカテゴリは今回は評価対象外です．
• τ²-bench
  • user simulatorおよびNL-assertion judgeの判定には，Azureのgpt-5-1-2025-11-13を使用しています．スコアは2回の試行の平均値です．

表を見ると，BFCLのsingle turnタスクでは，LLM-jp-4.1 シリーズはQwen3シリーズと同等か，やや下回る性能でした．multi turnのスコアはほぼ同水準です．また，8Bから33Bにかけてmulti turnの性能が大きく向上しており，複雑なmulti turnタスクではモデルサイズが重要な要因であることがわかりました．

τ²-benchでは，LLM-jp-4.1 は全体的にQwen3を上回るスコアでしたが，Qwen3.5とは依然として大きな差がある状態です．こちらもretailとtelecomのカテゴリで8Bから33Bにかけてスコアが大きく向上しています．全体として，8Bと32B-A3Bのモデル間ではスコアに大きな差は見られず，ツール呼び出しにおいて，両者はほぼ同等の性能だと考えられます．

また，BFCLのカテゴリ別スコアを見ても，同様の傾向が確認できます．single turnでは33Bモデルに明確な優位性は見られない一方，multi turnでは33Bモデルが大きく上回っています．特にmulti turnのlong contextカテゴリでは，33Bと8B・32B-A3Bとの差が最も大きくなっています．long contextはQwen3.5シリーズとLLM-jp-4.1との差が最も大きいカテゴリでもあります．

日本語 tool calling

日本語のツール呼び出し評価には，以下のベンチマークを採用しました．

• BFCL（Nejumi LLM Leaderboard 4 版）
  • BFCLの日本語翻訳版．BFCLと同じ設定で推論を行っています．

BFCL-nejumi のスコアを見ると，全モデルで英語版よりもスコアが低下する傾向が見られます．single turnでは，英語版で見られたQwenシリーズの優位性がなくなっています．さらに，multi turnではLLM-jp-4.1-33BがQwen3-32BおよびQwen3.5-9Bを上回る結果となりました．

おわりに

本記事では，LLM-jp-4.1 シリーズの事後学習の内容と評価結果について紹介しました．

LLM-jp-4.1 では，STEM 分野を中心に性能が向上したほか，新たに Tool Calling 機能も追加しました．LLM-jp-4 と比較して高性能な既存モデルとの差を着実に縮めている一方で，AIME や GPQA などの高難度タスクには依然として改善の余地が残っています．現在の LLM-jp の事後学習パイプラインは SFT と DPO のみで構成されており，今後は強化学習も取り入れたモデルの開発・公開を進めていきたいと考えています．

LLM-jp では，今後も LLM の安全性に関する研究開発を継続して進めていきます．LLM を社会で利活用していく上では，透明性や信頼性の確保が重要であり，モデルの高度化に伴って安全性への配慮もさらに重要になります．今回公開したモデルや今後開発するモデルを活用してこれらの研究を進め，LLM の研究開発の促進に貢献していきます．

LLM-jp の活動に興味を持たれた方はこちらのページからぜひご参加ください！