• 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 実装

そよ風と木。

連休も三日目になると疲れが溜まっていて、遠出はせず、那珂川河畔公園へ。遊具には子供達がいっぱい。ベコ氏も遊べるようになってきて嬉しいね。

若干遠回りになるが、塩原を向けて南会津、西郷村というルート。山間のドライブがしたく、この道はお気に入りの道の一つ。快晴でとても良い天気、25度という温度、10月半ばの山間というのに、Tシャツでちょうど良い気候。夏を感じる。

そして初めて行く、養鱒公園は山々に囲まれ、水がとても綺麗。最高のロケーションじゃん！鱒の養殖をしていて、横では家族向けのニジマスの釣り堀。釣ったマスは持ち帰りもできるし、その場で塩焼きやフライにもしてくれる。ベコ氏がもうちょっと大きくなったらやりたいね。

Leafの里は、お馴染みのドモンパンやnepuriさんらが出店する、というので知ったので、それらのお店を巡ったり(初めてドモンさんにお会いした)、美味しいパンやコーヒーを飲んだり、以前してもらった短時間のマッサージをやってもらったりと最高。昭和チックなゴーカートもあって、乗るとベコ氏は大はしゃぎ。はー楽しかったね。

ほんと最高の天気、ロケーション、イベント。写真屋さんも来ており、最高だった思い出として、その場で家族写真も撮ってもらったりと、いたりしつくせり。最高の1日だったなぁ。語彙がないので最高を連発しまくるが、そんな1日であった。

とりわけ動物の餌やりで、キリンが柵の上から首を出してきて、長いベロで手に持った野菜を器用に食べる。大迫力。小さい子供は結構怖くて泣いていたりしたのだが、ベコ氏は最初はびっくりしつつも、餌を持った短い手を上に伸ばし、餌やりを楽しんでいた。

またモノレール遊具、古いアンパンマンの乗り物、その他ただの大きなリスの置物など、なんでも楽しんでいた。動物が楽しい！と言うより、知らないものはなんでも楽しめるんだよなぁ。

その後、道の駅である宇都宮ロマンチック村へ。以前来たときは閑散としていたが、さすが三連休でかなりの混み用。餃子関連などを買って帰る。

宇都宮動物園のGoogle Mapsのレビューに、海外からの★1評価が多く付いていて、なんだろうと思って調べてみた。どうやら、PETA（動物の権利擁護団体）が、象の宮子を解放してというキャンペーンを行っていることが背景にあるようだ。

これをきっかけにエーアイ氏と対話し、動物福祉や動物の権利について少し調べてみた。象の単独飼育には確かに福祉上の懸念がある。ただ、長年暮らした環境から別の施設へ移すことが、必ずしも宮子にとって良い結果になるとは限らない。

動物園側も、高齢になった宮子(現在53歳かな、野生の象は70歳ぐらいまで生きるらしい)の飼育環境を改善するためにクラウドファンディングで2,000万円以上を集め、プールを整備したりレントゲンを購入したりなどの取り組みを行っている。動物園そのものの是非も含め、なかなか簡単に答えの出る問題ではないな、と。

PETAへの賛否はともかく、動物福祉について少し考えるきっかけになったなぁ。

親が普段使っているものを、ママパパと呼ぶ。かわいい。母のiPhoneは「ママ」と呼ぶようになり、父の靴下（よくその辺に脱いである）は「パパ」である。

そろそろ sakura の VPS の一年契約の更新の時期、というわけで動いていた諸々(このサイトの更新とかね)を自宅サーバに移す。以前は、いちいちちゃんと確認するの、めんどくさいからなーというコストが発生していたのだが、エーアイ氏によろ、で済んで驚くほど楽に終わってしまった。

午前中寒く、暖かくなるものが食べたいと、森商店での味噌ラーメン。ただ、昼過ぎには気温も暖かくなってしまった。よりはまた寒くなる。寒暖差が激しく、季節の移り目を感じる。

庭の雑草、クローバーかなと思っていたら、カタバミであった。雑草、割と好きなんだけど、知識が全然ないんだよなぁ。

いい天気の日。またずっとエーアイ中毒だったしで、気分を変えに外に。今回は那須平成の森フィールドセンターから駒止の滝までの散歩。往復1.5時間ぐらいのちょうど良い散歩コースだ。那須平成の森フィールドセンターはフリーWiFi(150Mbsp 程度は出ていた)が使え、トイレもあるし野外に机もあるしで、意外と良い作業場所にもなるかもしれないなぁ。

茶臼岳も綺麗に見える。

駒止の滝までは、山林を歩く。小学生が遠足（フィールドワーク）できていて賑やか。「あーなんか辺な人(私)がいる〜〜〜」と言われる。たしかに、みんなと格好が違うもんね。

山を歩くと、すれ違う人と「こんにちわ」と声かけの挨拶。最近何かで読んだが、挨拶するだけで満たされるらしい。実際、それだけで気持ちが良いんだよね。山の中を歩けば満たされまくりなのでは！？

陽が当たる場所は暑いぐらいの天気。ところどころ、紅葉の赤も見えるように。

これは三本槍岳かなー。以前三本槍岳に登った時は那須ゴンドラで中腹までワープしたのだが、今は那須ゴンドラも閉業してしまったから、中腹まですら、1時間以上歩かなければならない。

駒止の滝、初めて来た。うおー青い！綺麗じゃん〜。紅葉の季節はもっと綺麗なんだろうなぁ。車なら滝の横の駐車場まで来れちゃうけど、1時間弱を歩いてきたので、より有り難さがますね。

ささっと戻って(帰りは下りで楽)、THE昭和なお店の大衆食堂さつきで遅めの昼食。思ったより賑わっていて（たまたまだったかもしれないが）、ご飯がなくなったので麺類のみ、とのことだったのタンメンを。お店の夫婦のお二人も良い人だったし、この辺は昼食場所がここしかないから、長く続くと良いな。

コロナ時に作ったのだと思うが、入り口に「老舗のため すきま風 換気良好」というプレートがあって、これまた味がある。

昼食はラーメンきまま。澄んだスープ！

更新するパスポートを受け取りに市役所へ。手続きはマイナアプリからサクッとでき、あとは受け取るだけで楽だった。こういう便利さ、徐々にデジダル化が進んでいるのだなぁ、と実感する。

ベコ氏の保育園の横にレストランができたぞ〜と、お迎えの帰りにお茶。デザートもハーブ茶も美味しかったなぁ。ベコ氏は枯れた大きな紫陽花の周りで大はしゃぎする。おお、それに興味を持つのか、というポイントが時々予想不能でかわいいね。

作中の極端な人々は、日常の延長線上のどこかにいそうで、自分の中にある小さな偏りや鈍感さを拡大すれば彼らになる。しかも、その「偏り」は自分では小さいと思っていても、敏感な人には最初から見えているのだろうなぁ、という恐怖も覚える。

ontario でコーヒー。塩原に新しくお店を出されたメキシカンタコス屋さんもいらっしゃって、ちょっとおしゃべり。那須じゃなくて塩原、という出店チョイスが良いね。気になっていたお店なので、今度行ってみたいね。

その後柏屋でカツ丼。はー、久しぶりに食べたがめちゃ美味すぎでしょ。カツ丼 No1 のお店。

帰り際、隣のブドウ農家で大きなシャインマスカットを2房購入する。最近の我が家の定番デザートは、シャインマスカット。皮剥かなくて良くて美味しくて好き。

羊・ヤギふれあい広場的なところでは、怖がって泣いちゃうかもな、と思っていたのだが、羊のモフモフの毛並みが気に入ったのか、追いかけて果敢に触る。お気に入ったようで何より。休日だから、餌をあげる人が多く、餌を持っていると突進してくるのだが、餌がないと結構無関心、という距離感もちょうど良い感じだった。

土曜の開園直後は人もまだまばらで良いね。11時ごろには、もうだいぶ駐車場が混み始めていた。この日は天気も良く、近くてすぐ来れるのも最高である。

朝食。最近は八方だし、がよく食卓に並ぶ。

鬼が首あたりからの、遠くの山々が連なるパノラマの風景も良いんだよなぁ。

木々は徐々に葉が落ちたり、紅葉したりしだしていたり、小さなススキのような植物が見えたりと、すっかり秋の装い。

下山後、子鹿の湯で温泉で疲れを癒す。昼食はお久しぶりのグリルシェフでハンバーグ。その後は那須SHOZOへ行く予定だったが、休業日だった、残念。基本休みなしなのだが、連休後などは休みがあったりする。ゆっくり休んでください。

ベコ氏をお迎えに行った帰り道に、那須パラダイスヴィレッジへ。やたらとハローウィンに手が混んでいて、至る所でお化け屋敷のよう。ベコ氏はまだホラー物を「怖い」という認識ではなく、興味深そうにキョロキョロ見回っていた。

作ってみての感想は、そんなに難しくなくて、フロンティアLLMモデルを作っている各社なら、まぁ作れちゃうだろうなぁ。学習のための合成データセット作成がポイントなので、自分のところのモデル(成果物のライセンス気にしなくて良いし)と推論GPUを大量に使えリソースも潤沢だろうし。テキスト生成に比べたら確率生成は簡単なタスクだと思える。

画像への対応や、より安価で高速なモデルは予定調和として今後出てくるだろうけど、System One の使い道は、1 request でできることに閉じちゃう（だからこそ良い）ので、今の AI Agent のようなハーネス・環境含めて提供し学習のループを回し、といった付加価値を作ることが難しそう。とすると他のLLM 企業に模倣されて終わってしまうのでは。ちょうど OpenAI が Luna Decision 的なモデルを発表したようだしね。

TypeSafe AI は、Jev で、汎用 Classification モデルの需要があることを証明したことは価値があって素晴らしいと思うが、予定調和の進化だと他社に真似されて負けるだろうから、その先はどうなるんだろうね。自分が考えついてもないような視点でイノベーションを起こしてくれると面白いので、期待だね。

K氏の日記を読んで作ろうと思った(妻が)、という長谷川あかり氏のレシピ、焦がし醤油のハヤシライス。シャバシャバ系。スープハヤシライスっぽい感じで、サラリと食べれる美味しさ。

そこで今回、小型なモデルだとどれぐらいの性能が出せるのだろうと、System One Decision モデル の bekko-system-one-v0（以下 BS1）シリーズを制作してみました。汎化性能は Jev の方が圧倒的に上ですが、S1MB（System One Mosaic Benchmark）（注：著者作）では、小さなモデルながら、ほかの大きなサイズのモデル並みの結果が得られています。とりわけ、学習しているドメインのタスクでは、なかなかの精度で利用が可能です。

• 🤗 bekko-system-one collection

なお対応言語は、英語のみとなっています...。

ブラウザ上で実行可能

本モデル(英語のみ対応)は 17M、68M、400M パラメーターの3つのサイズのモデルを公開しており、とりわけ 17M や 68M の小型モデルは、ブラウザ上にモデルをロードし、CPU での推論も十分な速度で可能です。

• ブラウザ上でモデルを動かし、推論するデモ

注意: なおこのデモは、BS1 モデルで解きやすいタスクを恣意的に選んでいるため、ぱっと見の性能は良さそうですが、Jev のような「幅広いタスクで高性能」なわけではないので、ご注意ください。

また、17M パラメーターというのは、総パラメーター数が約17Mで、そのうち埋め込みを除くパラメーター数は、たったの約4Mです（ここでは Active Parameters - AP と呼びます）。ブラウザ実行用に、token の lookup table だけを INT8 にしたものを ONNX へと変換しており、モデルファイル単体のサイズは、たったの約29MBとなります。

評価ベンチマーク

ブラウザで動いたとして、実際のモデルとしての性能はどんな感じでしょうか。というわけで評価をしてみました。S1MB - System One Mosaic Benchmark という、私作のベンチマークを使っています。このベンチマークは、後述のデータセットのうち、test set のデータを中心に、原則100ケースを抽出した、137個(Noul 59, Choice 57, Score 21)のベンチマークで構成されており、Noul、Choice、Score の3軸で評価しています。

S1MB については、S1MB記事で書いているので、詳細は割愛しますが、総パラメーター数500M以下に絞ると以下のような結果です。BS1 も、超小型としては、かなり健闘しているのではないでしょうか。なお比較のために Jev 1.13 も載せています。

AvgはNoul・Choice・Scoreの調整済みスコアを等重みで平均した値です。各スコアは高いほど良く、正解率そのものではありません。

しかしながら、S1MB に含まれる「汎化性能を計測する」ベンチマーク(GPT-6-Astra で生成した合成データセット)では、BS1 モデルは圧倒的に性能が悪いです。これは「特定ドメインを学習したデータセットなら、ある程度の性能は出るが、自由な指示や未知のドメインについては弱い」と言えるでしょう。なので、今回公開した BS1 も「汎化性能を持った System One Decision モデルに達していない」ことから version 0 として、-v0 suffix をつけています。

全体評価と同じモデルについて、汎化性能の6ベンチマークに絞った結果です。Avg順に並べています。

なお、Jev はドメイン特化性能（特別にそのドメインを学習したわけではないのに、すごいですね）も、汎化性能も、特筆したスコアですね。とりわけ汎化性能のスコアについては、ほぼほぼ満点と言えるでしょう。つまり、汎化性能が高い System One Decision モデルを名乗るには、最低限この汎化性能ベンチマークで、Jev 並みのスコア（つまりほぼ満点）を出せないと、あまり意味がないと思っています。

モデルサイズと推論速度

BS1 モデルで、特筆すべきことはモデルサイズと推論速度です。GPU（RTX 5090）を使ったS1MBの26,269件の評価処理は、17Mで約13.33秒、68Mで約34.04秒、400Mで約132.97秒（約2分13秒）でした。17Mでは、モデルロードと各ベンチマークのデータ読み込みなどを含む計測区間の合計でも約21.38秒です。冒頭のデモのように、ブラウザ上でも現実的に動きます。

なおJevはAPI経由となり、通信待ちなどを含む各ベンチマークの評価時間の合計は約58分37秒でした。APIの応答時間はタイミングによって前後するでしょう。ここで示した値は評価処理の計測値で、純粋なモデル計算だけの時間ではありません。また、17Mの約21.38秒もwarmupなどを除く区間の合算で、コマンド開始から終了までの時間ではありません。

技術アーキテクチャでの取り組み

Bekko System One（以下 BS1）で工夫したのは、複数の選択肢を判定するときに、共通する入力の処理を使い回すことです。その方法の前に、まず一般的な encoder model で、Jev のような処理をする、よくある方法の二つを解説しましょう。

cross encoder

通常の双方向 encoder を使う cross encoder では、以下のように、共通する入力と選択肢を組み合わせて処理します。特殊トークンは模式的な表記です。

[CLS] {state} {instruction} [SEP] {criteria A} [SEP]
[CLS] {state} {instruction} [SEP] {criteria B} [SEP]
[CLS] {state} {instruction} [SEP] {criteria C} [SEP]

先頭の CLS トークンの表現や、トークンの表現を平均したベクトル（mean pooling）を、学習済みの head に渡してスコアを求めます。情報検索の reranker でも広く使われている方式です。

入力と選択肢がお互いを参照できるため、細かな対応関係を捉えられます。しかしながら、state が長いと、同じ文章を選択肢の数だけ処理することになります。前半の表現も後半の選択肢によって変わるため、前半が同じ文字列でも、途中の計算結果をそのまま使い回せないのです。

なお情報検索の reranker では、前半に配置する検索クエリが短いことがほとんどのため、共有による計算量削減の効果が小さく、cross encoder でも良いケースが多いですね。

listwise encoder

それなら、選択肢をまとめて一回で処理しちゃおう、という方法もあります。全候補を連結する listwise 方式では、例えば以下のように入力します。

{state} {instruction} [SEP]
{criteria A} [SEP] {criteria B} [SEP] {criteria C} [SEP]

候補ごとの表現や候補前後の特殊トークンを pooling するなどして、スコアを求めます。共通部分を一度で処理でき、選択肢同士も参照できるのが利点です。

一方、候補が多いと入力全体が長くなります。全トークン間で attention を計算する場合、その計算量は長さの二乗に比例するため、多数の候補をまとめると負担が増えます。cross encoder より常に遅いということではなく、文章の長さや候補数によって向き不向きがあります。

BS1 の方法 - 共有 prefix

BS1 では、state と instruction を一つの共有部分（prefix）として処理し、各層の Key/Value、いわゆる K/V を保存して使い回します。

{state} {instruction} → 各層の共有 K/V
                          ├─ {criteria A} → score A
                          ├─ {criteria B} → score B
                          └─ {criteria C} → score C

普通の cross encoder と何が違うの？と思われるかもしれませんが、ここでは参照できる範囲を変えています。共有 prefix は選択肢を参照せず、各選択肢は共有 prefix と自分自身だけを参照します。これなら、選択肢が変わっても共有部分の計算結果は変わらないため、一度計算した K/V を再利用できます。

LLM の KV cache と同じように K/V を保存しますが、次のトークンを一つずつ生成するわけではありません。共有部分を処理した後、各選択肢を並列に処理し、候補側の表現を mean pooling して head からスコアを求めます。

候補側だけを pooling していますが、候補の文章しか見ていないわけではありません。各候補は各層で共有部分を参照するため、state と instruction を踏まえた表現になっています。一方、共有部分の先頭に置いた CLS トークンは候補を参照できないので、その表現だけでは候補ごとの判定はできません。

これによって、長い state と instruction を選択肢ごとに処理し直す必要がなくなります。ただし、通常の cross encoder と同じ計算を、そのまま高速化したものではありません。通常の cross encoder では、候補に応じて入力側の表現も変わり、その情報を候補側が再び参照できます。BS1 では、この相互のやり取りを制限する代わりに、共有部分の計算を使い回しています。

そのぶん、細かな対応関係を捉える自由度は通常の cross encoder の方が高いと考えられます。ただ、実際の精度差はタスクや学習条件にもよるでしょう。

なお、state と instruction はまとめて双方向に処理しています。state だけを独立してキャッシュしているわけではないため、instruction を変えた場合は共有部分を再計算します。

また、今回は、criteria 同士が参照できるような attention は含めてません。本来、例えば Choice のようなケースですと、他の criteria を参照した上で回答した方が精度がありそうですが、短時間で試しただけでは、精度が上がる学習ができなかったです。なおこれは無理だ、と言っているわけではなく、私が試した方法でうまくいかなかっただけの可能性も十分あるでしょう。

大元の base model

大元の base model としては、ModernBERT アーキテクチャの英語高性能モデルである Ettin-encoder を、さらに教師 reranker モデルを用い cross encoder として学習した Ettin-reranker を利用しています。

ModernBERT などの MLM、いわゆる pretrained model の状態では、検索クエリとドキュメントの関連度を直接スコア化するようには学習していません。情報検索向けデータを学習した Dense Embedding モデルや、cross encoder モデルでは、文章とドキュメントの関連性を理解しているため、今回はすでにそれらを学習済みの Ettin-reranker を使っています。小型ながら、英語 rerank 性能は非常に高いです。今回の BS1 では、Ettin-reranker を base model として用い、追加学習を行いました。

以下は Ettin-encoder、Ettin-reranker を base model とし、各データセットに上限を適用した学習データの全量を、同じ条件で学習させた対照実験の結果です。68Mではreranker初期化が総合CE・各型のaccuracyで良く、17Mでは総合CEは僅差で、Noul・Choiceはreranker、Scoreはencoderが良い結果でした。

CEは小さいほど良く、accuracyは大きいほど良い指標です。データセットごとに集計し、二つの入力順序の結果を平均しています。前掲の調整済みスコアとは指標が異なります。各条件1 seedでの比較です。

データセット

データセットでは hotchpotch/bekko-system-one-dataset-v0 を利用しています。このデータセットは、既存の NLP や情報検索関連のデータセットを、Noul、Choice、Score の3形式として学習しやすいように変換した 153 個の学習データセットで、training set は約659万ケースとなっています。一部は合成データセットも追加してあります。なお、このデータセットの test set は S1MB のベンチマークにも転用しているので、同じドメインの training set で学習した BS1 は S1MB の一部ベンチマークのスコアが上がりやすくなっています。

BS1 では、このデータセットを用いて学習を行いました。学習には RTX 5090 を用い、17M の学習では、たった2時間で学習を終えました。なお 68M では5.5時間、400M では約25時間でした。

学習のハイパーパラメーター

学習のハイパーパラメーターやデータセットの件数などは、細かくは解説しませんが、bekko-embedding 論文（私作の、超小型マルチリンガル dense retrieval model の論文です）で書かれている知見を主に、いくつかパラメーターを試し、その範囲で良い結果が得られた値を使っています。

学習用の実装も公開しているので、この実装を使うことで、同様のモデルを学習可能です。興味がある方は、ご利用ください。

• bekko-system-one：学習・推論コード

超小型の System One Decision モデルは実現可能なのか？

将来は、S1MB の汎化性能ベンチマークでも Jev 並みのスコアに達する、アクティブなパラメーターサイズが100M以下といった、超小型なモデルも可能である、と思っています。それを達成するための、最も重要なことは、学習に必要な高品質な合成データセットです。

TypeSafe AI CEO の Diogo Almeida 氏も「100% of our data is synthetic (but not the type of crap that is just spit out from an LLM obviously)」と言っているように、Noul、Choice、Score で、ありとあらゆる質問と適切なスコアの合成データセットが用意できれば、超小型モデルも実現可能だと思っています。どうしても「モデルアーキテクチャ」に目線が行きがちですが、高品質で齟齬がない多様な合成データセットをどのように作り、それをどのように学習するか、が肝心でしょう。

実際に、私作のマルチリンガル情報検索モデルである bekko-embedding シリーズでは、10億以上のデータ（うち1.6億件が合成データセット）を、巨大バッチで学習させることにより、アクティブパラメーターサイズが 8M、25M という超小型サイズのモデルで数倍〜数十倍の情報検索モデルに匹敵する情報検索モデルが作れています。

続いての重要なことは、強力な base model の登場です。実用的なテキスト生成能力を持つ LLM（decoder）を超小型にするのは難しいため、文字列生成にこだわらなければ、もっと小型で性能が良い base model が作れるでしょう。ModernBERT はその例だと思いますが、現状のさらに発展し続けている LLM のモデルアーキテクチャを使い、さらに小型モデルでより良いアーキテクチャと、大量の多様なデータを学習させた base model があれば、その継続タスクの学習に効いてくるでしょう。ただし、合成データセットの方が重要度は非常に高いとは思っています。

終わりに

TypeSafe AI の System One Decision モデル、Jev の登場により、汎化性能が高い Classification model の有益性が証明されました。TypeSafe AI の素晴らしい点は、中途半端な汎化性能で出すのでなく、フロンティア LLM に並ぶ性能の超汎化性能を持つモデルを作り上げ、出したことでしょう。

Classification で解決できる課題は、思った以上に広いです。BERT 以降、分類やスコア付けなどの NLP タスクでは Transformer encoder が広く使われてきました。

本記事では、学習したタスクなら、ブラウザ上でも動くほど小さなモデルである程度の精度を出せる、bekko-system-one-v0 を作ったお話でした。学習済みのタスクで小型モデルを試したり、独自データで追加学習したりするための出発点として、モデル・データセット・学習コードを公開しています。

幅広い未知のタスクへの対応は、今後の課題です。前項で述べたとおり、大量の良質なデータセットや、小型モデルアーキテクチャの進化により、十分な汎化性能を持った System One Decision モデルは、きっと開発されるはずです。

この bekko-system-one-v0 が、何らかの価値につながれば幸いです。

参考URL

bekko-system-one

• bekko-system-one collection
• bekko-system-one-v0-17m
• bekko-system-one-v0-68m
• bekko-system-one-v0-400m
• ブラウザデモ
• 学習・推論コード
• 学習データセット

S1MB

• 評価コード
• 評価データセット
• 評価結果リポジトリ
• Leaderboard
• S1MB の紹介記事

base model・関連モデル・資料

• TypeSafe AI — System One / Jev
• TypeSafe AI — モデル一覧
• Diogo Almeida 氏の合成データについての投稿
• Laya：コード / モデル
• ModernBERT-base
• Ettin：Seq vs Seq 論文
• Ettin-reranker-17m-v1
• Ettin-reranker-68m-v1
• Ettin-reranker-400m-v1
• bekko-embedding-v1-a8m
• bekko-embedding-v1-a25m
• Bekko Embedding 論文
• Sentence Transformers — Cross-Encoders

けんちゃんの朝顔（あさがお交通安全プロジェクト）というんだね。襟を正して運転しないと。

運転免許は、マイナ免許証を発行してもらう。普通の免許証も発行でき、マイナカードでも、免許書でも、どちらか携帯していればOKになって良いね。

せっかくなので、警察署近く(ではないが)の那須パラダイスヴィレッジで作業する。WiFi 使えるし、平日はお客もそんなに多くないしで、快適。こっち方面で作業したい時は良い場所だなー。

遅めの昼食は、麺'sラッキーパンチで、店名にもなっている「ラッキーパンチ」を始めていただく。辛いもつ入りラーメン。旨辛っ〜〜〜。

こういう、何気ない日々のふつうの幸せの話が、時々友人の日記などに書かれるのだけど、読むたびに心温まるのであった。

そしてさくらももこ氏のエッセイ本はたくさん出ていて、どの本に書かれた話だっけ、というのが思い出せなかったが、エーアイ氏に雑に聞いたら速攻正解を出してきてすごいな…。「まる子だった」の「七夕祭り」の回だった。エーアイ氏もすごいが、wikipedia にエッセイの収録の概要をコツコツとまとめた人がすごいね。

ボールプール。100均のボールなので、もっと増やししたいが、ベコ氏がプールごとひっくり返して毎度片付けが大変なのであまり増やせない。ひよこの形のボール（ではないが）も8つほどあって、形が認識できるので、取り出す遊びを楽しんでいる。

白河ラーメンが食べたいぞ、ということで焔に。見た目油どっぷり、だがスルッと食べれちゃう。おいし〜〜。

猪苗代観光船、何度も猪苗代湖に来ている割に一度も乗ったことがなかったのだけど、大満足だったなぁ。また乗りたいね。今度は晴れの日の磐梯山を船から眺めたいぞ（この日は曇りで、山頂付近は見えなかった）。

早めの昼食は、猪苗代観光船のすぐそばのMINATOYAのパン屋、みなとやベーカリー猪苗代で。パンとエスプレッソ、という有名店が監修しているらしい。とりわけ、しらすパンが美味しいかったなー。たくさんある窓際の席からは、猪苗代湖が見れて素晴らし。横浜・湘南あたりのようだ。家からだと海は割と遠いが、海のような猪苗代にすぐ(?)来れてこれまた最高。

亀ケ城公園散歩。散歩すると、興味があるものを立ち止まっては拾い、でなかなか進まない。ほんとどこでも楽しそうだ。

毎度お馴染み、KUUHAKU に立ち寄り、今月の個展を見る。鈴木太郎氏の素敵な作品があったので、お迎え入れすることに。ラッキー。KUUHAKU を知る前は、アート作品とは縁がないと思っていたが、「くらしに、アートを」がコンセプトなだけあって、自分が好きなものに出会え、自分で選んでお迎え入れして良いのだ、という気持ちが芽生えたので、ありたが嬉しいね。

しゅっと15時過ぎには家に到着。今日の猪苗代も最高だったね。

ベコ氏が朝寝(8-9時ごろ)と、昼寝(13-14時ごろ)のタイミングに車移動すると、ベコ氏はスヤリと寝れる(車だと振動が良いのか、寝つきが良い)し、日帰りはこのリズムで出掛けることに慣れてきたなぁ。