Strands Decider: なぜエンコーダーではないのか？

Marc's Blog 私について 私は、うまく機能し、クールなことをするものを構築するのが好きです。大きなものを構築するのが好きです。また、機械加工、溶接、料理、スキーも趣味にしています。私はシアトルのAmazon Web Services (AWS) でエンジニアとして、エージェント型AI、特にエージェント型AIの安全性とポリシーに取り組んでいます。それ以前は、EC2、EBS、データベース、サーバーレス、サーバーレスデータベースに取り組んでいました。すべての意見は私自身のものです。 リンク 私の出版物とビデオ Mastodonで@marcbrooker Twitterで@MarcJBrooker このブログはAIによって書かれていますか？ Strands Decider: なぜエンコーダーではないのか？ 専門知識レベル：疲弊。 前回の投稿で告白したように、私はモデル開発の専門家では全くありません。以下に述べることは、少なくとも部分的には不正確である可能性が高いです。私は注意深く定量的であろうと努め、深い専門知識の欠如を部分的に補おうとしました。 先週、strands-decider-2Bをリリースして以来、数人から、なぜそれが変更されたLLMであり、エンコーダー（BERTのような）ではないのかと尋ねられました。彼らの直感は、双方向性（つまり、各トークンの表現がその前後のトークンから構築される）は、因果的（つまり、前のトークンのみが使用される）よりも優れているだろうというものです。これは、エンコーダーが分類器として広く使用されているのと同じ理由です。右から見れば、デコーダーをエンコーダーとして誤用しているとも言えるため、これは妥当な質問です。 この仮説を検証するために、5つの設計を比較しました。 v19は、Qwen3.5ベースのstrands-deciderの最終設計です（前回の投稿とstrands-decider READMEで詳細を確認してください）。 b1は、T5Gemmaをベースにしたエンコーダー・デコーダー設計（オリジナルのTransformerのようなもの）で、1Bのエンコーダーパラメータと1Bのデコーダーパラメータを持ち、LMヘッドを除外し、ポインターヘッドを追加したものです。 b2はb1と同じですが、4B+4Bです。 e1aは、T5Gemma（T5Gemma 2ではない）のエンコーダー部分のみで、2.6Bパラメータです。 e1bは、e1aのレイテンシ最適化バージョンで、マスクされたステートキャッシュを備えており、複数の質問を干渉なしに並列評価でき、ステートキャッシュを再利用できます¹。ステートは全体に双方向的にアテンドし、各質問はステートとそれ自身にアテンドします。 また、フリーズされたModernBERTとettin-encoder-1bも測定しましたが、それらはT5Gemmaと同等のパラメータ数で性能が劣っていたため、トレーニングに時間を投資しませんでした。 まず、精度とキャリブレーションを見てみましょう。b2はここで非常に良好で、JevBenchの精度とBrier、およびJF100のBrierでv19を上回っています（同じ精度で）。これは良いことですが、b2は総パラメータ数が約8Bであるのに対し、v19は2Bであるため、単純な比較ではないことを思い出してください。本当に興味深い比較はv19とe1bです。e1bはJevBenchの精度でv19をわずかに上回っています（ただし、v19の実行間変動の範囲内）、キャリブレーションはわずかに劣りますが、JF100のキャリブレーションではわずかに弱いパフォーマンスで同等です。これまでのところ、エンコーダーにとって決定的な勝利ではありません。 次に、レイテンシに目を向けましょう。エンコーダーのみのモデルは、v19の65msに対し、中央値約35msで、レイテンシで楽に勝利します。エンコーダー・デコーダーモデルは最も遅いです。半分のレイテンシで同等のパフォーマンスであれば、これはe1bにとって大きな勝利のように見えます。しかし、データに深く潜り込むと、事態は少し複雑になります。ここでは、e1bは短いプロンプト長では楽に勝利しますが、プロンプトが長くなるにつれてスケーリングが悪くなることがわかります。これは、中央値の優れたパフォーマンスと一致しています。これが重要かどうかは、ワークロードのミックスによります。JF100とJevBenchはどちらも小さくなる傾向があり、e1bに有利です。 ここでのスケーリングの違いは、2つのモデルの計算コストに起因します。e1bは26の完全なアテンションレイヤーを持ち、それに伴う二次計算コストがかかりますが、v19のレイヤーの75%は線形計算コストを持つGated DeltaNetです。これらのレイヤーは固定コストが高いですが、漸近コストが優れているため、高いレイテンシのフロアにつながります²。 最後に、興味深いサブプロットの1つを見てみましょう。e1a（マスクされていない2.6Bエンコーダーのみの候補）に戻ります。評価セットでは、9つのタスクのうち7つでv19を上回っていますが、2つではわずかに劣っています。しかし、JevBench（168対153）では著しく劣り、JF100（162対158）でもわずかに劣ります。これは、エンコーダーは、少なくともe1bが採用しているマスクされたアプローチなしでは、汎化性能が劣ることを示唆しています。ステートを読み取る際に質問にアテンドできることが、実際には弱点なのでしょうか？ 評価セット | v19 | e1a | Δ Held-out short tasks | 0.647 | 0.695 | +0.048 MuSiQue | 0.882 | 0.948 | +0.064 ContractNLI | 0.873 | 0.864 | -0.009 BoardgameQA | 0.820 | 0.884 | +0.064 HotpotQA (held out) | 0.719 | 0.748 | +0.029 Generated, v16’s | 0.857 | 0.851 | -0.006 Generated, v18’s | 0.777 | 0.786 | +0.009 Adequacy, HelpSteer2 | 0.722 | 0.761 | +0.039 Adequacy, generated, balanced | 0.788 | 0.821 | +0.033 エンコーダー対デコーダーの質問について、私たちはどこに立っているのでしょうか？真実に近づくことはあまりなかったと思います。この実験は、アーキテクチャ、ベースモデル、インストラクションチューニング対ベース、その他の変数を変更しており、非常に混同されています。しかし、興味深いことをいくつか学びました。このサイズのこの種の作業において、どちらも決定的な勝者であるようには見えません。この実験のコードは、今のところブランチにあります。まだ mainline strands-decider に取り込む価値があるようには思えませんが、開発次第ではそうなるかもしれません。 脚注 デコーダーのアイデアが再び忍び寄る。デコーダーは、同じ理由で同じトリック（KVキャッシュとプレフィックスキャッシュ）を実行します。 初めてではない、逐次的な結果をメモ化することがパフォーマンスに役立ったことは確かです。 O(N²)アルゴリズムが小さいデータサイズでO(N)アルゴリズムを上回ったのは、確かに初めてではありません。 « ブログインデックスに戻る 関連記事 2026年9月28日 » Small Decisions: Engineering a Leading Model 2026年7月29日 » Lorenz and Little: How Much Does Your Tail Cost? 2026年7月19日 » Aurora DSQL: Scalable, Multi-Region OLTP Marc Brooker このサイトの意見は私自身のものです。必ずしも私の雇用主の見解を表すものではありません。 marcbrooker@gmail.com RSS Atom この作品は、Creative Commons Attribution 4.0 International Licenseの下でライセンスされています。