Strands Decider：なぜエンコーダーを使わないのか？
strands-deciderの公開後、Marc Brookerはなぜこのモデルがエンコーダではなくデコーダを使うのかと問われた。5つの設計を比較し、この分類タスクではデコーダが遜色なく、ある条件下では勝ることを見出した。
日本語
コピー
専門性：底をついた。
前回の記事で認めたとおり、私は専門家レベルのモデル開発者にはほど遠い。以下は少なくとも一部は不正確だろう。専門的な深さの不足を多少なりとも補うため、厳密さと定量性を心がけた。
先週 strands-decider-2B を公開したあと、何人かに聞かれた。なぜ改造した LLM であって、エンコーダ（BERT など）ではないのか。彼らの直感はこうだ。双方向（各 token の表現を前後の token から構築する）のほうが因果（前の token だけを使う）より優れているはずだ。エンコーダが分類器として広く使われているのも同じ理屈だ。
もっともな疑問である。少し見方を変えれば、私たちはデコーダをエンコーダとして使っているのだから。
この仮説を検証するため、5 つの設計を比較した。
- v19 は Qwen3.5 ベースの strands-decider の最終設計（詳細は前回の記事と strands-decider README を参照）。
- b1 はエンコーダ・デコーダ設計（初期の Transformer に近い）。T5Gemma 2 ベースで、エンコーダ 1B パラメータ、デコーダ 1B パラメータ。LM head を外し、代わりに私たちの pointer head を付ける。
- b2 は b1 と同じだが 4B+4B。
- e1a は T5Gemma（T5Gemma 2 ではない）のエンコーダ部分そのもので、2.6B パラメータ。
- e1b は e1a の遅延最適化版で、masked state cache を備える。複数の質問を互いに干渉させず並列評価でき、state cache も再利用できる 1。
stateはstate全体に双方向で注目し、各質問はstateと自身に注目する。
凍結した ModernBERT と ettin-encoder-1b も試したが、同等のパラメータ数では T5Gemma に劣ったので、訓練に時間はかけなかった。
まず精度とキャリブレーションから。
b2 はここで好成績を収め、JevBench の精度と Brier で v19 を上回り、JF100 では同じ精度でより良い Brier を出した。悪くないが、b2 の総パラメータは約 8B、v19 は 2B にすぎないことを忘れてはいけない。対等な比較ではない。
本当に興味深いのは v19 と e1b の比較だ。JevBench の精度では e1b が v19 をわずかに上回る（ただし v19 の複数回実行のばらつきの範囲内）が、キャリブレーションはやや劣る。JF100 ではキャリブレーションが互角で、性能はわずかに弱い。
ここまでのところ、エンコーダモデルに圧倒的な優位があるわけではない。
次は遅延。
純粋なエンコーダモデルは遅延で明快に勝つ。中央値約 35ms に対し v19 は 65ms。エンコーダ・デコーダモデルが最も遅い。遅延が半分で性能が同等なら e1b の圧勝に見える。だがデータを掘り下げると、話はそう単純ではない。
e1b は短い prompt では明確に優位だが、prompt が長くなるほどスケーリングが悪い。中央値の良さはこれと整合する。これが重要かどうかはワークロードの構成次第だ。JF100 も JevBench も短めで、e1b に有利に働いている。このスケーリングの差は結局、両モデルの計算コストに行き着く。e1b は 26 層すべてが full attention で、それに応じた二次の計算コストがかかる。一方 v19 は 75% の層が Gated DeltaNet で、計算コストは線形だ。これらの層は固定コストが高いが漸近コストは優れているため、遅延の下限が高くなる 2。
最後に面白い枝道として、e1a（マスクなしの 2.6B 純エンコーダ候補）に戻る。評価セットでは、9 タスク中 7 つで v19 を上回り、2 つでわずかに劣った。しかし JevBench では明確に悪く（153 対 168）、JF100 でもやや悪い（158 対 162）。少なくとも e1b のようなマスク方式がなければ、エンコーダの汎化は劣るということだ。状態を読むときに質問に注目できるのは、本当に弱点なのだろうか。
| 評価セット | v19 | e1a | Δ |
|---|---|---|---|
| 留保した短いタスク | 0.647 | 0.695 | +0.048 |
| MuSiQue | 0.882 | 0.948 | +0.066 |
| ContractNLI | 0.873 | 0.864 | −0.009 |
| BoardgameQA | 0.820 | 0.884 | +0.064 |
| HotpotQA（留保） | 0.719 | 0.748 | +0.029 |
| 生成、v16 の | 0.857 | 0.851 | −0.006 |
| 生成、v18 の | 0.777 | 0.786 | +0.009 |
| Adequacy、HelpSteer2 | 0.722 | 0.761 | +0.039 |
| Adequacy、生成、均衡 | 0.788 | 0.821 | +0.033 |
では、エンコーダ対デコーダの論争で、我々は結局どこまで来たのか。残念ながら、真実にはほとんど近づいていない。この実験には変数が多すぎる——アーキテクチャ、ベースモデル、instruction tuning 版とベース版、その他諸々——とても整理できるものではない。それでも、いくつか面白いことは分かった。この規模でやる限り、どちらかが文句なしの勝者とは言えなさそうだ。
この実験のコードは今はブランチの中にある。本流の strands-decider にマージする価値はまだなさそうだが、もう少し開発を進めれば変わるかもしれない。
脚注
- デコーダのアイデアが、ひっそりと戻ってきている。デコーダも同じ理由で同じ手法（KV cache と prefix caching）を使う。インクリメンタルな結果をキャッシュすれば性能が上がる——これが初めてのはずがない。
- データ量が少ないとき、O(N2) アルゴリズムが O(N) アルゴリズムに勝つ——これも初めてのはずがない。
« ブログ索引に戻る
関連記事
- 2026年9月28日 » 小さな決断：フロンティアモデルを作る
- 2026年7月29日 » Lorenz と Little：テールは結局いくらかかるのか？
- 2026年7月19日 » Aurora DSQL：スケーラブルなマルチリージョン OLTP
Marc Brooker
ここに書いた見解は個人のものであり、雇用主の立場を必ずしも反映するものではありません。