SystemOneModel (11) — 1/1


Paper/Blog Link My Issue
#NLP #LLM-as-a-Judge Issue Date: 2026-09-26 GPT Summary- LLM審査員は多様な評価に有効だが、大規模運用では推論コストと判定信頼性が課題となる。JEV-as-a-judgeは意思決定に特化した経済的な第一段階の審査員として、通常の選好評価と根拠に基づく事実性評価で、最先端LLM審査員に近い性能を0.36%の料金で達成した。一方、導出過程の検証や巧妙な誤答の識別では性能差が拡大し、その差は主に信頼度の低い判定に集中した。そこで、信頼度の高い判定はJEVで受理し、不確かな判定のみを上位審査員へ回す固定カスケードを構築。これにより、より低コストで比較対象の99%の精度を維持した。 Comment

元ポスト:

Loading…




Paper/Blog Link My Issue
#Article #ComputerVision #EfficiencyImprovement #NLP #LanguageModel #MultiModal #Blog #PEFT(Adaptor/LoRA) #OpenWeight #Selected Papers/Blogs #Encoder #KeyPoint Notes Issue Date: 2026-10-02 Comment

元ポスト:

Loading…

概要しかブログ中には書いていないが、よさげに見える。

Qwen-3.8-27Bをバックボーンとし、Qwenのパラメータはフリーズした上で軽量なアダプタを学習し、ルーティングヘッドなるcross-attentionに基づいた各選択肢のスコアを出力するヘッドによって予測が実施されるようである。

これらは、内部で作成された合成データを用いて事後学習されたとのことである。lossはlabel smoothed cross entropy(正解、不正解ラベルを0/1としてクロスエントロピーを計算するのではなく、ハイパーパラメータεでスムージングしてlossを計算するものらしい)とBrier Loss(実際に予測された確率値と正解、不正解を1/0としたときの平均二乗誤差)なるものによって、正則化によって過学習を防止し、出力される確率値がでたらめにならないように学習することを目指しているように見える。

その後RLCDと呼ばれる、選択肢間の順序関係に基づいて、正解と隣接するラベルにも部分的に報酬を与えるようなrewardを持つ(オリジナルのポリシーから分布が大きくシフトしないようなペナルティ付き)RLによって学習をしているようである。これにより、より高いAccuracyと汎化性能が得られた、と一言記述されている。

Qwenが持つVision Encoderによって画像もエンコードでき(Jevは画像は不可と述べられている)、
context長が64kとJevの2倍で
Jevよりもlatencyが良く、
様々なベンチマークスコアで高いスコアを獲得としている、と報告している。

latencyはflashモデルであれば、DiffusionGemma-as-Jevを上回る。

HF: https://huggingface.co/Cloudflare/clef




Paper/Blog Link My Issue
#Article #Tutorial Issue Date: 2026-09-30 Comment

元ポスト:

Loading…

transformer以前から現在までの分類モデル、およびJevのチュートリアル




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #MultiModal #Blog #LLMServing #VisionLanguageModel #One-Line Notes #Reading Reflections Issue Date: 2026-09-30 Comment

元ポスト:

Loading…

SGLangにおいて、Qwen3.8-27B、およびQwen3.5-35B-A3Bを、chat modelからdecision model(System Oneな分類モデル)として利用するためのエンドポイントが追加されたようである。

ドキュメントを読むと、要は既存のLLMに対してリクエストをreasoning modeをオフでprefillし、応答のトークン位置でのスコアリング、選択肢、yes/noのトークンのlogprobを取得し、たとえばyes/noトークンのprobabilityを計算する場合はyes/noの2 vocabularyのsoftmaxを計算する。つまり、単に通常のLLMの応答の開始位置でのラベルのlogprobを取得して、最もlogprobが高いラベルを返し上述の確率を返すというシンプルな実装に見える。

System Oneモデル向けの追加のチューニングや、分類headなどが学習されているわけではない(SGLangはLLM Servingエンジンでありモデルの学習そのものはしないだろうから、そりゃそうだ、という話だった)点に注意。シンプルに、LLMのデコード開始位置でのlogprobを用いた分類器であり、これを念頭におけば、このエンドポイントを利用した場合のおおよその性能の見当はつく(性能が悪いと言いたいわけではなく、これまでのLLM利用の経験からあたりをつけやすいという意図である)。

System One系の話は実装の中身を確認して、どのような原理の元駆動するかを確認しないと、足元をすくわれる気がする。外から見た時の挙動は同じでも、アーキテクチャが結構異なる気がする。あと、アーキテクチャだけでなく、System Oneモデル向けのデータや最適化がされているかによって、そもそもの予測性能やzero-shotでの汎化性能にかなり差が生まれるのではないか、と思っている。しかし、まあ結局自分たちのユースケースに対して必要な性能が出ていて、latencyが必要な水準に達しているかを確認すれば良いだけではある。




Paper/Blog Link My Issue
#Article #Pretraining #NLP #Dataset #ContrastiveLearning #Blog #OpenWeight #Scaling Laws #mid-training #PostTraining #Selected Papers/Blogs #Encoder #Author Thread-Post Issue Date: 2026-09-24 Comment

元ポスト:

Loading…

HF: https://huggingface.co/Contrastive-LM

非常にコンパクトにまとまっていて大変読みやすかった。あとでまとめる。




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #SmallModel #OpenWeight #reading #One-Line Notes #Reading Reflections Issue Date: 2026-09-20 Comment

元ポスト:

Loading…

こちらはJev系のモデルを謳うものと比較して、Qwenをベースにしており、かつ広範なタスクで評価がされているため、ある程度のzeroshotでの汎用モデルとは言えそうである。が、結局のところどこまで汎用的に使えるかはよくわからない。

関連:
- Needle 3 Automation Foundation Model For Tiny Devices, Cactus, 2026.09
- Introducing System One Models & Jev, TypeSafe AI, 2026.09




Paper/Blog Link My Issue
#Article #EfficiencyImprovement #NLP #LanguageModel #Transformer #Blog #SmallModel #Proprietary #Architecture #Selected Papers/Blogs #One-Line Notes #ToolUse #Author Thread-Post Issue Date: 2026-09-19 Comment

元ポスト:

Loading…

チャットをせず、各ターンごとに関数呼び出しに特化したedge向け小型モデルとのこと。アプリが利用するツール群を渡し、ユーザの発言に基づいて全ての引数を埋めて関数を呼び出す、あるいはスキーマを与えればそのスキーマに則った出力を返し(構造化出力)、推測はしない(関数の範囲外のものは空出力)というもののようである。

これらは、simple attention networkと呼ばれるもので実現される。simple attention networkはtransformerからFFN Layerをを無くし軽量なHadarmard MLPというlayerに置き換え、FFNが従来保持していた知識に関する情報はengramによって、n-gram embedding側に持たせることによって高速、軽量化がじつげんされているようである。residual streamとしては、mHCが用いられているようである。
また、デプロイ時にモデルの深さを指定することで、20個あるうちのどのlayerを利用するかが決まり、性能とコストを調整できるようである。これを公式ポストではIntelligence Laddersと呼称している。

関連:
- [Paper Note] Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models, Xin Cheng+, arXiv'26, 2026.01
- [Paper Note] mHC: Manifold-Constrained Hyper-Connections, Zhenda Xie+, arXiv'25, 2025.12

関連:
- Introducing System One Models & Jev, TypeSafe AI, 2026.09

と思想が似ている。




Paper/Blog Link My Issue
#Article #EfficiencyImprovement #NLP #AIAgents #Blog #Coding #SoftwareEngineering #Selected Papers/Blogs #reading #KeyPoint Notes #Reference Collection #Reading Reflections Issue Date: 2026-09-16 Comment

細かいことは全くわからないが、LLMのようなチャットモデルは超人的な性能なのになぜAGIに繋がっていないのかが常々疑問で、code+AIに特化したモデルを開発したとのことで、それはどのようなものかというと、

LLMは人間の好みとなる応答を返すように、autoregressiveにテキストを生成するが、

本ブログで紹介されているシステムSystemOneは意思決定に最適化し、並列で生成され、自由なテキストを返せないが構造化出力を高速かつ安価に生成可能で、キャリブレーションされた確信度を常に返す、

というもののようである。

着眼点はとてもおもしろいのだが、どの程度高度な推論をすることができるのだろうか?
現代では高度な推論は計算コストである程度賄っているため、安価で高度な推論もできるのでれば大きなブレイクスルーだが、その技術はLLM側にも適用できる可能性があり、結局いつかLLM側に追いつかれる、という可能性がある。
逆に高度な推論ができないのであれば、適用可能なスコープは限定的となる。

RLCDという技術はすでに先行事例があったようだ:

Loading…

利用規約でJevに関するベンチマークスコアや性能を公開することが禁止されているようである:

Loading…

所見:

Loading…


JamC-QAのスコアは(GPT-5.6-lunaより)低く、日本特有の知識などには弱い可能性がある:
- 『JamC-QA』: 日本の文化や風習に特化した質問応答ベンチマークの構築・公開(前編), SB Intuitions, 2025.09

色々な動向を鑑みるに、Encoderか、Decoderかはさておき(利用者から見たらどちらでもよい気がするので)、

- zero-shotで様々なタスクに利用可能で
- latencyが非常に速くて
- コストが安価なモデル

という3つの要素が重要に思える。

chatはできないが、構造化出力/関数出力等が可能(なことで様々な分類タスク等に適用できる)というのは、latencyの速さとコストの安価さを得るための手段。エンコーダ、デコーダも手段の話。

過去にPFNがJevに相当する機能を開発しサービス化までしていた、という話がある(関連技術は幅広く特許を取得しているようである)。

Loading…


なぜ需要を掘り起こせなかったのか、という点は考えてみるとおもしろいのかもしれない。
個人的にはいまJevが流行っぽい兆しを見せているのは、時期的なものが大きい気がしており、
- (Reasoningモデルの台頭によって) LLMのlatencyが悪い
- 多くのワークフローに組み込む場合に得たい出力が(おそらく)構造化出力(で、めちゃめちゃ賢い判断はそこまで必要とされない)
- モデルのトークン利用料が増加し、(おそらく)運用コストが課題となってきた

という課題に世の中が直面し始めて、課題感として持たれ始めていること、が背景としてある気がしており、ちょうどタイミング的に「安い、速い、(そこそこ)賢い」のJevが世の中に刺さったのではないか、という気がしている。