TypeSafe AI の System One Decision モデル Jev のような Decision モデルを、日本語のデータセットを多く含めて学習した saihai (采配) を公開しました。学習に利用したデータセットも公開しています。

• saihai-v1-8b
• saihai-v1-8b-gguf
• saihai-v1-310m (小型モデル)

saihai-8b は、オープンかつ日本語に強い大規模言語モデル llm-jp-4.1-8b-thinking を基盤モデルとし、Decision モデルとしてのファインチューニングを行った 8B サイズのモデルです。llm-jp のモデルを用いることで、日本のドメイン知識を最大限活かすことができそうですね。ライセンスも llm-jp と同じ Apache 2.0 です。

通常のモデル重みに加えて GGUF も公開しているので、各所で利用されている推論エンジン llama.cpp に最近追加された /v1/systemone API エンドポイントでも利用できるようにしています。

また、小型の saihai-310m も合わせて公開しました。こちらは decoder の LLM ではなく、bekko-system-one と同じアプローチで学習した encoder モデルで、日本語の reranker である ruri-v3-reranker-310m をベースにしています。ライセンスは ruri と同じ Apache 2.0 です。

なお、記事の後半にはテクニカルノートも書いているので、技術方面に興味がある方はご覧ください。

日本語 Decision モデルベンチマーク

日本語でのモデル性能を測るため、S1MB (System One Mosaic Benchmark) の日本語ベンチマークセット japanese-v1 を作成しました。すでに公開されている NLI などの日本語の特定タスクのデータセット 19 タスクと、今回 Decision モデル用に GPT-6.1-Sol を用いて作成した合成データセット 8 タスクを組み合わせたもので、27 タスクのベンチマークとなります。また、評価結果は S1MB の leaderboard で確認できます。

• https://huggingface.co/spaces/hotchpotch/S1MB-leaderboard?category=japanese-v1

タスクは回答の型によって次の 3 種類に分けています。

• Noul: はい / いいえの二択
• Choice: 複数の候補からの選択
• Score: 0, 1, 2, 3, ... といった段階でのスコア付け

結果は以下です。Jev には及ばないまでも、saihai-8b は 8B というモデルサイズながら、そこそこのパフォーマンスですね。

ここでは Jev・GPT-6 Luna の API モデルと、パラメータ数が 12B 以下のモデルから選んで掲載しています。27B クラスのモデルなどを含む全体の結果は、leaderboard をご覧ください。各列で Jev・GPT-6 Luna を除いた最良の値を太字にしています。

注意点として、saihai は日本語タスクを解きやすくするため、いくつかのベンチマークタスクの元データセットの train set を学習しているので、ベンチマークの点数は上がりやすくなっています (test set と重複するデータは、できる限り除いています)。その影響を調べた対照実験の結果は後半に載せています。

表の見方は次のとおりです。

• Noul・Choice・Score の 3 列は、既存データセット由来 19 タスクと合成 8 タスクの計 27 タスクを、それぞれ型ごとに平均した値です。「汎用」の 3 列は、そのうち合成 8 タスクだけを型ごとに平均した値です。
• Task Avg は、Noul・Choice・Score の 3 列を等重みで平均した総合値です。「汎用」の 3 列は Task Avg に別途加算されていません。
• 値は 0〜100 で、小数 2 桁に丸めています。どれも基準値から調整したスコアで、単純な正解率ではありません。

saihai-8b は、近いパラメータ数のモデルと比べても健闘していると感じます。評価対象と同じ元データセットの train を一部学習しているとはいえ、日本語の特定タスクを解くモデルとしては、よい結果になりました (後述の比較では、日本語で作られたタスクで特に強い結果でした)。一方、合成タスクの Noul では Winnow 12B や Jebadiah 9B v2 を、Choice では多くのモデルを下回り、Score にも差が見られます。特定タスクでの強さと、柔軟な入力への対応力には差があるようです。

OpenAI の Decision モデルである GPT-6 Luna (Decisions API) は、Task Avg 55.00 と Jev に迫る結果でした。Noul (62.10) と汎用 Noul (67.11) では Jev を上回っています。なお、GPT-6 Luna は API が回答を拒否した判断があり (日本語では 1 件)、その判断は不正解として採点しています。

小型の saihai-310m は、Task Avg 30.19 と、数 B クラスの decoder モデルとはまだ差があります。ただ、同じく encoder アーキテクチャで同程度のサイズの Laya multilingual (Task Avg 5.29) と比べると、かなり良い性能です。特に Choice は 40.99 で、JCommonsenseQA (89.58)・KUCI (82.67)・JNLI (79.00) などではそれなりの性能を示しています。Noul も CommonsenseMoralJA (74.67) や合成の Diverse (65.33) ではそこそこ解けています。一方、知識や数理を問う合成タスクはほぼ解けておらず、汎用 Score は 0.00 でした。また、saihai-310m は評価対象と同じ元データセットの train を、saihai-8b よりもずっと多く学習しているので (後述)、その分スコアは上がりやすくなっている点にご注意ください。

Decision モデルというと、decoder アーキテクチャの大きなモデルが目立ちますが、小型の encoder モデルでも、将来は Decision モデルとして十分な性能のものが現れるのでは、と期待しています。

既存の日本語データセットの活用

既存の日本語データセットは、タスクごとに Noul・Choice・Score のどの型が合うかを考えて割り振りました。データは原作者が用意した test set を基本とし、一部は validation や train、もともと分割されていない問題群も使っています (例外は後述)。各タスクは最大 300 件です。なお、この手法に興味がある方は、IVRy さんの「日本語ベンチマークで Jev の性能を検証する」に具体的な方法がわかりやすく書かれているので、参照ください。

これらのデータを、Decision モデルが回答しやすい instruction・state の構造に変換して評価用データセットを作成しました。同時に、train 用のデータが用意されているものは学習用データセットも作成し、saihai の学習にも使っています。なお、train 用のデータには、まれに test set と同じデータが含まれるため、できる限り削除しています。

以下、ベンチマークと同じ元データセットの train を「系列 train」と呼びます。利用したデータセットは以下で、「系列 train の投入」列は、評価問題ではなく、系列 train から学習に使った件数です。

以下は補足です。

• test set の例外: JCoLA は元の validation、JSeM はもともと train/test に分かれていない問題群、NanoJMTEB は評価用 split、JMMLU Japan は元の split 指定なし、SOBACO Culture は元の train を使っています。GPQA も元の評価用問題群です。すべてが「原作者が定義した test」というわけではありません。
• JSICK は学習側が Choice、評価側が Score ですが、同じ系列として扱っています。
• JMMLU Japan は日本史・慣用句・公民・地理を各 75 件、SOBACO Culture は日本文化の 300 件です。
• 検索タスク (NanoJMTEB) は、JMTEB の検索系ベンチマークを元にした、正例 1 件と非正例 3〜5 件から選ぶ Choice です。検索系のベンチマークを複合しているので、ライセンスは行ごとに異なります。
• ライセンスは素材ごとに条件があり、この表は要約です。JMMLU の科目別の利用制限や、検索素材の帰属・再配布条件は元資料をご確認ください。

合成データセット

ここまでのデータセットは、「特定タスクにフォーカスした」Decision モデルの性能を測るものです。そこで、既存タスクでは測れない「ある程度柔軟な入力に対して、適切な回答を選べるか」を見るタスクを、GPT-6.1-Sol で合成データセットとして生成しました。真の汎化性能を測れているとはいえませんが、便宜上「汎化性能指標」のタスクと呼んでいます。

合成データは 3 系列・8 タスク、合計 2,400 件です。

Diverse には Score タスクがありません。また、以前作った不確実性のタスクは、現在の評価対象から外しています。合成データのライセンスは、OpenAI のモデルを用いて作ったため、CC BY-NC 4.0 としています。また正答は人手による独立したブラインド検証をしていないので、この 8 タスクの点数だけで、あらゆる使い方に汎化できるとは言えません。

英語ベンチマークでの評価

saihai は日本語向けのモデルですが、学習データには英語のデータも多く含まれています。そこで、S1MB の英語ベンチマークセット english-v1 でも評価しました。english-v1 は 137 タスクで、「汎用」の 3 列は、Diverse と Contextual の合成タスク 6 タスク (各型 2 タスク) を型ごとに平均した値です。列の見方は日本語の表と同じですが、タスクの構成が違うので、日本語の表と数値を直接比べることはできません。

日本語の表と同じモデルに、英語の encoder モデルである bekko-system-one-v0-400m・Laya・Laya typed-decisions を加えています。各列で Jev・GPT-6 Luna を除いた最良の値を太字にしています。

英語では、saihai-8b は Task Avg 50.59 で、API モデルを除く decoder モデル 7 つの中では 3 番目でした。Noul は 59.96 と比較的高い一方、Score は 32.29 と低めです。汎用 Noul・Choice も 90 を超えており、日本語向けに学習したモデルながら、英語でも必要十分な性能を持っているといえそうですね。

なお、GPT-6 Luna は英語では Task Avg 49.21 と、日本語ほどの順位ではありませんでした。英語では API が回答を拒否した判断が 17 件あり、不正解として採点しているので、その分も多少影響しています。

saihai-310m は 40.59 で、英語の学習データを bekko-system-one のデータセットの約 10% に絞っていることもあり、bekko-system-one-v0-400m (50.60) より低くなりました。特に汎用 Noul・Score は大きく下がっています。

それでも、英語の encoder モデルである Laya (13.36) や Laya typed-decisions (15.00) と比べると、saihai-310m の Task Avg は 2.5 倍以上で、Noul・Choice・Score のいずれも大きく上回っています。一方、汎用の 3 列は Laya 系と同程度 (汎用 Score はやや下回る) で、柔軟な入力への対応は小型 encoder にとってまだ難しいところですね。

また、英語の汎用 Noul・Choice は、多くの decoder モデルが 90 前後に集まっていて差がつきにくくなっています。数値は直接比べられないものの、日本語の合成タスクでは Jev でも汎用 Noul が 64.67 なので、今回作った日本語の合成タスクは、差がつきやすい問題になっているようです。

saihai モデルの作成

saihai-8b と saihai-310m はアーキテクチャが異なるので、それぞれ分けて説明します。

saihai-8b

モデル作成に使った学習コードとデータセットは、それぞれ公開しています。

• 学習コード: hotchpotch/saihai
• 学習データ: hotchpotch/saihai-v1-dataset

モデルアーキテクチャ

saihai-8b は、いわゆる decoder アーキテクチャの LLM で、現在一般的な Decision モデルの学習方法を用いています。Decision モデルの構造は、まだ汎用的なものが定まっていないのが現状です。ただ、推論エンジンの一つである llama.cpp では、/v1/systemone という推論エンドポイントで Perplexity の pplx-decider-v1-27b の形式が使えるようだったので、それに合わせた構造になるように、学習しています。

学習から推論までの流れは以下です。

1. 学習データの候補と、教師の確率分布を対応付けます。正答や出典情報はモデルの入力に含めません。
2. 指示・状態・候補を JSON にし、基盤モデルの chat template に埋め込みます。候補には、tokenizer で 1 token になる A、B などのコードを割り当てます。
3. 回答を始める直前までを入力し、最後の有効 token の hidden state を取り出します。
4. bias のない FP32 の線形 head で候補の logits を計算し、その問題で使う候補の中で softmax を取ります。head は、元の LM head のうち候補コード token の行から初期化します。
5. 教師の確率分布との cross entropy を損失として、LoRA と候補 head を学習します。backbone は BF16 です。全パラメータを更新するとメモリに載らず、学習も遅くなるため、LoRA を用いています。
6. 配布時には LoRA を merge し、学習した head を元の LM head の候補コード token の行へ書き戻します。推論では 1 回の forward から候補の確率を読み取るだけで、文章や reasoning は生成しません。

候補コードは llama.cpp の pplx-decider と同じ規則で、A〜Z、AA〜ZZ のうち単一 token になるものだけを選び、最大 255 候補に対応させています。Noul の候補順は false → true、Score は 2〜10 段階です。pplx の学習方法を丸ごと再現したわけではなく、候補 token の確率を読み出す仕組みを合わせた形ですね。

学習データ

学習データには、以下の 3 つを使っています。

• 既存の英語 Decision モデルの学習に使われているデータセット。既存データセットから抽出したものや、合成データセットを含みます
• 日本語ベンチマークの元データセットのうち、train にあたるもの (系列 train)
• llm-jp-4.1-32b-a3b-thinking を用いて作成した、日本語の合成データセット

内訳は以下で、合計 33,532 件を学習させています。

学習は LoRA (rank 16 / alpha 32) を用い、RTX 5090 で約 3.62 時間でした (評価や量子化の時間は含みません)。そのほかの条件は、1 epoch、実効 batch size 16、最大入力長 8,192、seed 42 です。279 件の固定 validation を学習中に 10 回測定していますが、validation が最良の step ではなく、最後の checkpoint を使っています。

なお、モデル重みのライセンス (Apache 2.0) と、学習データの素材ごとのライセンスは別です。

saihai-310m

saihai-310m は、bekko-system-one のアプローチで学習した、小型の encoder モデルです。学習コードは bekko-system-one のものを使っています。

• 学習コード・手順: bekko-system-one の saihai-v1-310m 学習ドキュメント
• 学習データ: hotchpotch/saihai-v1-310m-dataset

モデルアーキテクチャ

アーキテクチャは bekko-system-one と同じです。簡単に書くと、instruction と state を共有の prefix として一度だけ処理し、その各層の Key/Value を、各候補 (criteria) の処理で再利用します。各候補は共有 prefix と自分自身だけを参照し、候補側の表現からスコアを計算します。長い state を候補の数だけ処理し直さずに済むので、小さなモデルで効率よく推論できます。詳しくは bekko-system-one の記事をご覧ください。

bekko-system-one では、素の encoder よりも、reranker として学習済みのモデルを初期値にした方が性能が上がりました (特に 68M のモデルで、損失 (CE) と各タスクの精度がともに改善しました)。それに倣い、saihai-310m では日本語の高性能 reranker である ruri-v3-reranker-310m をベースにしています。ruri-v3-reranker-310m は、modernbert-ja-310m を元にした ruri-v3-pt-310m を、reranker として学習したモデルです。パラメータ数は 315M (埋め込み層を除くと 236M) です。

なお、saihai-310m は llama.cpp の /v1/systemone には対応していません。Transformers の AutoModel (trust_remote_code=True) から読み込み、saihai-8b と同じような state・questions 形式の入力で使えます。ただし、入力が長すぎる場合、saihai-8b はエラーにしますが、saihai-310m は入力を切り詰めて推論する点が異なります。

学習データと学習条件

学習データは、以下の 3 つを混ぜて使っています。件数は、1 つの問題に含まれる個々の判断の数です。

日本語の系列 train は、CommonsenseMoralJA・JCommonsenseQA・JNLI・JSTS・KUCI・Mintaka・JaNLI の 7 データセットです。saihai-8b では各データセット 400 件以下に絞っていましたが、saihai-310m では採用した train をすべて使っているので、件数がずっと多くなっています (例えば KUCI は 69,527 判断)。そのため、対応するタスクのスコアは saihai-8b 以上に上がりやすくなっていると思われます。saihai-8b と同様、評価データの問題とその関連データは除いています。

学習は全パラメータを更新し (LoRA は使っていません)、batch size 512 で全データを 1 epoch、約 2 時間 45 分でした。encoder の学習率は 1e-5、head の学習率は 2e-4、入力長の上限は query 4,096 / 候補 2,048 tokens です。

S1MB の評価は、bekko-system-one と同じく、長い入力を切り詰めて入力長を配分する設定で行っています。

対照実験

さて、ベンチマークと同じ傾向のタスクを train に多く含んでいるので、そのせいで性能が高く出ているのでは？という疑問が出ると思います。そこで、saihai-8b について、2 つの対照実験を行いました。最後に、系列 train なしのモデルを外部の Decision モデルとも比べています。

系列 train を学習しなかった場合との比較

LLM-jp 4.1 8B を用いた saihai-8b に加え、Qwen3.5 の 3 サイズのモデルに対しても、系列 train を含めて学習したモデルと、除いて学習したモデルを作って比べました。以下は S1MB の Task Avg です。

多くのモデルでは系列 train を学習させた方が強い結果になっていますが、Qwen3.5 4B では除いた方が 0.43 点高くなりました。系列 train を入れればどのモデルでも総合値が上がる、というわけではないですが、基本的にはスコアが上がりやすくなりました。

では、どのタスクで差が出ているのでしょうか。系列 train を使った 10 タスクと、それ以外の 17 タスク (うち、系列 train を使っていない既存データ由来 9 タスク、合成 8 タスク) に分けて、差を見たのが以下です。タスク群の値は各タスクのスコアの単純平均で、差は「あり − なし」です。プラスなら、系列 train を学習した方が高いことを示します。

LLM-jp 8B では、系列 train を学習したことで、対応する 10 タスクは 8.02 点上がった一方、それ以外の 17 タスクは 0.15 点の上昇にとどまりました。どのモデルでも、対応する 10 タスクだけが大きく上がる同じ傾向で、やはり train を学習した系列のタスクが解きやすくなっている、ということですね。ただ、系列 train を除くと学習データが 33,532 件から 29,643 件に、重みの更新回数も 2,096 回から 1,853 回に減っているので、若干データが減ったことも影響しているかもしれません。

基盤モデルを変えた場合との比較

saihai-8b は llm-jp のモデルを使っているので、他のモデルに比べて日本のドメイン理解が強いと思われます。そこで、Qwen3.5 シリーズのいくつかのモデルも同じ学習データで学習させ、違いを見てみましょう。

ここでは、既存データセット由来の 19 タスクを、次の 2 つに分けています。

• 日本語オリジナル 12: 翻訳ではなく、日本語で一から作られたデータセットの 12 タスクです。日本の知識を問うタスク (後述の文化知識 4) だけでなく、推論や意味の類似度などの言語タスクも含みます。
  • CommonsenseMoralJA、JamC-QA、Jamp、JaNLI、JCoLA、JCommonsenseQA、JCulture-MCQ、JNLI、JSTS、KUCI、JMMLU Japan、SOBACO Culture
• 翻訳・混在 7: 英語などからの翻訳を元にしたものと、複数の元データが混ざったものの 7 タスクです。MMLU-ProX・MMMLU・GPQA のような一般知識の問題が多く含まれます。
  • MMLU-ProX、MMMLU、GPQA、Mintaka、JSICK、JSeM、NanoJMTEB

どちらも記事用に分けたタスク群で、日本語能力全体を定義したものではありません。Task Avg は S1MB の総合値、それ以外の列はそれぞれのタスク群の単純平均です。

全体ではサイズが少し大きい Qwen3.5 9B が上でしたが、日本語オリジナルの 12 タスクでは LLM-jp 8B が少し上でした。一方、翻訳・混在の 7 タスクでは Qwen3.5 9B が 6.83 点上で、日本語で作られた問題に LLM-jp 8B の強みが生かされているようです。また、Qwen3.5 4B・0.8B と比べると、全体スコアも LLM-jp 8B の方が高くなっています。ただし、タスクや型ごとに見ると例外もあります。また、LoRA の rank や学習率もモデルごとに違うので、純粋に基盤モデルだけの差とは言えません。

系列 train なしの saihai-8b と他モデルとの比較

最後に、系列 train を使わずに学習した LLM-jp 8B を、他の Decision モデルと比べてみました。ここでの「文化知識 4」は、JamC-QA、JCulture-MCQ、JMMLU Japan、SOBACO Culture の 4 タスクです。

文化知識 4 は日本語オリジナル 12 の一部です。

系列 train を除いた場合でも、この 8 モデルの中では日本語オリジナル 12 タスクで Jev に次ぐ 2 位で、Winnow 12B (gemma-4-12B-it が大元) より高い結果でした。合成 8 タスクも Jev・Winnow・Jebadiah に次ぐ 4 位です。一方、総合値では Winnow が上ですし、文化知識 4 タスクだけなら Clef が上です。翻訳・混在 7 タスクでは 8 モデル中 6 位で、一般知識の問題ではむしろ他のモデルに負けています。「日本について何でも一番詳しい」とまで強く言える結果にはなりませんでした。

なお、ここでの「系列 train なし」は、追加学習から系列 train を除いたという意味です。評価データと意味的に重複するデータがないことや、基盤モデルの事前学習で触れていないことまでは確認していません。

量子化と llama.cpp 対応

saihai-8b の GGUF は BF16・Q8_0・Q6_K・Q4_K_M・Q3_K_M・Q2_K の 6 形式を配布しています。この 6 形式で、S1MB japanese-v1 の全 27 タスク・8,067 件を llama.cpp の native /v1/systemone で評価しました。入力は S1MB 標準の llama.cpp adapter で変換し、4 並列、1 slot あたり 8,192 tokens、cache 再利用ありと、6 形式とも同じ条件です。

argmax 一致率は、最も確率が高い候補が GGUF の BF16 版と一致した割合で、正解率ではありません。また、Score は数値段階の期待値で採点するため、argmax が一致してもスコアが変わることがあります。

Q8_0 は BF16 との差が 0.03 点ほどで、総合値をほぼ維持しています。Q4_K_M でも低下は 0.66 点ほどですが、argmax 一致率は 92.10% でした。点数が近くても、確率をそのまま使う処理まで同じ挙動になるとは限らないですね。Q3_K_M は約 4.37 GB まで小さくなりますが低下は 2.56 点、Q2_K では 11.46 点と大きく下がりました。これを見ると、ほぼ同等の性能を維持できる Q8_0 や、ベンチマークレベルでは劣化がかなり少ない Q4_K_M あたりが、量子化モデルとしては使いやすそうですね。

速度と VRAM も測っています。RTX 5090 で、同じ 27 タスク・8,067 件を 4 並列で評価したときの処理速度と、GPU メモリ使用量の最大値です。

量子化すると BF16 より 1.1〜1.3 倍ほど速くなり、VRAM は Q8_0 で約 12 GiB、Q4_K_M なら 10 GiB を切ります。一方で、Q8_0 以下は速度にあまり差がなく、Q2_K はむしろ遅くなりました。速度面でも、Q8_0 か Q4_K_M あたりが選びやすそうです。

この速度は、HTTP 通信や採点・保存まで含めた評価全体の処理速度で、1 件あたりのレイテンシではありません。また、1 回だけの計測で、精度の評価とは別に実行しています (重みは配布版と同じですが、64K コンテキスト対応のメタデータ更新前の GGUF で計測しています)。VRAM はドライバなどを含めた観測値です。

なお、Transformers 版の Task Avg は 49.77、GGUF の BF16 版は 49.53 と少し差があります。これは、Transformers 版は saihai 独自の入力変換、GGUF 版は S1MB 標準 adapter の入力変換で評価していて、Score などの表現が異なるためで、量子化による差ではありません。

そのほかの補足です。

• コンテキスト長は 64K としていますが、今回の評価は短いタスクばかりなので、64K の長い入力での判断品質までは確認できていません。
• 計測には、llama.cpp の revision 3d65c90 に、LLM-jp tokenizer の修正 (PR #28864) のパッチを当てたものを使っています。この tokenizer の修正パッチを使わないと、若干 token のずれが発生します。将来的には llama.cpp に取り込まれると思います。

Decision モデルと、ベンチマークを作っての感想

S1MB の英語 leaderboard では、すでに 個人や企業が独自に作った 100 以上の Decision モデルが評価されており、ベンチマーク上は Jev よりも性能の高いモデルも出てきています。また、ちょっとした性能のモデルなら、雑にファインチューニングするだけでも作れてしまいます。実際、自分も今回作ってみたのですが、パッと見ある程度うまく機能していそうなモデルは、性能の良い基盤モデルを使えば簡単に作ることができました。saihai-8b も、RTX 5090 1 枚でファインチューニングにかかった時間は 4 時間弱と、短時間で作れています。

ただ Jev の素晴らしいところは、汎化性能が高く、ほとんどの問題に対して適切な回答を選べていることだと思います。そしてこれは、S1MB をはじめ、現在出ているベンチマークでは、まだまだうまく計測できているとは言い難い状況です。TypeSafe AI は、Jev のプレビューリリース時の利用規約で、性能の誤解を招くためなのか、ベンチマーク結果の公開を NG としていました (現在の規約ではその条項はなくなりました)。また、CEO の Diogo Almeida 氏も X で以下のように述べています。

there's a critical difference between benchmaxxed models and ones made by people who truly care about reliability that, by definition, doesn't show up on benchmarks

(we've somewhat learned this for string LLMs...)

https://x.com/CompleteSkeptic/status/2106883012856336539

ある側面だけを切り取ったベンチマークでは汎化性能が測れないので、そんなに意味がない、というのは私も同意見です。TypeSafe があらゆる質問に対する性能を測れるベンチマークを公開してくれれば良いのですが (社内にはあるのではないか、と私は勘繰っています)、そうすると「TypeSafe が考える Decision モデルのあらゆるユースケース」が露呈するわけで、先行者利益で走りたい今、わざわざそれを公開する選択はないのでしょう。

では S1MB japanese-v1 も意味がないのでは？という問いには、半分は yes、半分は no かなと思っています。特定の側面だけであっても、ある程度共通の指針で測れるベンチマークは有益です。ただ、それを鵜呑みにすると、本来とても重要な「汎化性能」を無視することになってしまうので、参考程度に見ていただけたらと思います。本当に必要な性能評価は、自分たちのユースケースでどれぐらいの性能が出るのかを測るベンチマークを、自前で用意することなのかなと。

また、Decision モデルの性能と推論コストのバランスを考えると、現在のスイートスポットは 4B あたりな気がしていますが、将来的には 1B 以下のモデルでも十分な性能が出るのではないか、と思っています。小さいモデル、とりわけエンコーダモデルが好きな身としては、小さなサイズで必要十分なモデルが作れると面白そうだなぁと感じています。今回の saihai-310m はまだその域には届いていませんが、その方向への一歩として公開しました。

参考 URL

• 日本語ベンチマークで Jev の性能を検証する
• 基盤モデル: llm-jp-4.1-8b-thinking
• 日本語合成データの生成モデル: llm-jp-4.1-32b-a3b-thinking
• saihai 学習コード
• saihai 学習データ
• bekko-system-one-v0 の公開記事
• saihai-310m の学習ドキュメント (bekko-system-one)
• saihai-310m 学習データ
• saihai-310m の基盤モデル: ruri-v3-reranker-310m
• S1MB 評価コード
• S1MB 日本語 leaderboard
• S1MB 英語 leaderboard
• S1MB 英語ベンチマークデータ (english-v1)
• GPT-6 Luna: OpenAI Decisions API
• S1MB 評価結果
• pplx-decider-v1-27b
• llama.cpp の Decision readout 実装