線形計画法で重み空間プログラミングは可能か？

線形計画法で重み空間プログラミングは可能か？

先週、MIT CSAILはSparks of Weight-Space Programmingを発表しました。小さなネットワークの生の重みを与えると、GPT-6 Astraはそれがどのゲームをプレイするように訓練されたかを特定できました。ゲームのルールだけを与えられると、ゼロから小さなネットワークの重みを書き出し、PPOで1億ステップ訓練されたネットワークを打ち負かすことができました。勾配も学習ループもなく、ただ重みが何を計算するかを推論するだけです。彼らはこれを重み空間プログラミングと名付けました。

別の実験では、AstraにQwen3.5-0.8Bの数学能力を向上させるために重みを編集するように依頼しました。Astraは重みのわずか0.016%しか変更しませんでしたが、MATH-500の精度は7.9%から48.1%に急上昇しました。1

Astraの編集を見ると、その検索の大部分は試行錯誤による線形計画問題の解決だったことがわかりました。約8時間と28回のフォワードパスを費やして、どの重みをどれだけ変更するかを選択しました。数回のLPソルブ（それぞれ約1分）で、変更された重みを8倍少なくして同じ作業を完了できます。この記事では、その編集、なぜそれがLPであるのか、そしてそれが修正自体について何を意味するのかを解説します。

思考ループ#

小さな推論モデルには、一般的な失敗があります。それは思考ループに陥り、推論を完了する代わりに同じ数行を繰り返し表示してしまうことです。Qwen3.5-0.8Bは特にそれに陥りやすく、モデルカードにも記載されています。MATH-500では、ベースモデルの回答の93%が、回答に到達する前に32,768トークンの制限に達しました。

この編集はループを修正するため、モデルがループするあらゆる場所で役立ちます。これには指示追従も含まれます。IFEvalは21%から62%に向上しました。

Gemma 3 270Mでは、ループすることがめったにないため、Astraは数学能力を意味のあるレベルで向上させることができませんでした。著者たちが述べたように、重みを編集することで隠された能力への障害を取り除くことはできましたが、モデルが持っていない能力を追加することはできませんでした。

Astraはどのようにループを修正したか#

Transformerは残差接続を使用します。各レイヤーの出力は、それを置き換えるのではなく、入力に加算されます。1つのトークンをネットワークに沿って追跡すると、すべてのレイヤーが加算される単一のベクトル、つまり残差ストリーム（このモデルでは1,024次元）が得られます。モデルがループしているとき、残差ストリームは一貫した方向にシフトします。Astraの修正は、2つのレイヤーを編集して、それらが追加するものが反対方向を向くようにすることでした。

ループ方向の発見#

Astraは、生産的な推論の一部と、それのループするバージョンのペアを4組作成しました。8つすべてをモデルで実行し、1つのレイヤーでの各トークンの残差ストリームベクトルを記録しました。ループするテキストの平均が1つのベクトルを与え、生産的なテキストの平均が別のベクトルを与えます。それらの差を正規化したものがループ方向 $u$ です。これは、モデルがループするときに残差ストリームが移動する方向です。

重みの編集#

各MLPは行列 $W$（down_projと呼ばれる）で終わります。各トークンで、それはMLPの3,584次元の隠れ活性化 $h$ を1,024次元の出力 $Wh$ に変換し、それが残差ストリーム $x$ に加算されます。

$$x \leftarrow x + Wh, \qquad Wh = \sum_j h_j , w_j$$

したがって、MLPの出力は常に同じ3,584個のベクトル（$W$の列 $w_j$）の加重和です。$W$はそれらのベクトルを固定し、活性化 $h_j$ が各トークンでどれだけ追加されるかを決定します。

各列は $u$ の方向に一部向いています。その量 $u^\top w_j$ は、 $h_j$ がアクティブである限り、列 $j$ がモデルをループ方向にどれだけプッシュするかを示します。Astraの編集はその倍数 $\alpha$ を減算します。

$$w_j \to w_j - \alpha , (u^\top w_j) , u$$

$\alpha = 1$ の場合、$u$ に沿った成分は失われるため、列はループ方向にプッシュしなくなります。レイヤー15と19のすべての列に対してこれを行うと、GSM8KとMATHの学習問題での精度が9%から33%に向上しました。$\alpha = 6$ の場合、成分は反転します。つまり、$u$ の方向に $+a$ を書き込む列は、使用されるときに $-5a$ を書き込み、モデルをループ方向から遠ざけます。

編集された各列は、同じベクトル $u$ の倍数だけ変化します。したがって、全体の編集は1つの方向 $u$ と、列ごとの1つの数値 $v_j = -\alpha,(u^\top w_j)$（変更されない列ではゼロ）です。これはランク1の変更です。

$$\Delta W = u,v^\top$$

各トークンで、 $(v \cdot h_t),u$ が残差ストリームに追加されます。これは $u$ のある量であり、編集された列のアクティブさによって決まります。他の方向は変更されません。

これにより、$v$ を選択する必要があります。どの列を編集するか、そして$\alpha$ の大きさをどれだけにするかです。Astraは試行錯誤でそれを解決し、各編集をこれらの学習問題の新しいバッチでテストしました。

$\alpha = 1$ より強くプッシュするとより効果的になり、ランダムな方向は何も効果がありませんでした。最終的な編集では、ループするテキストで $u$ を最も多く書き込んだ上位64列のみに$\alpha = 6$ を使用しました。

時間の使い道#

この論文では、Astraの完全なログが公開されています。すべてのツール呼び出し、すべてのフォワードパス、そしてAstraが自身に書き込んだすべてのメモが含まれています。Astraは重みをロードしたPythonカーネルを持ち、学習問題または選択したテキストに対するモデルのバッチ実行である50回のフォワードパスの予算を持っていました。

編集は約10時間後に確定し、最後の17回のパスで変更なしに再テストされました。2 これらの10時間のうち、$u$ の発見には15分かかりました。 $v$ の発見には約8時間かかりました。

vの選択は線形計画問題である#

Astraは、ループするトークンを $u$ から強く遠ざけ、生産的なトークンにはほとんど影響を与えないような $v$ を探していました。トークン $t$ でのプッシュは $v \cdot h_t$ であり、$v$ に対して線形であるため、両方の要件は線形不等式です。

私はベースモデル自身のトレースからトークンをラベル付けしました。ループの奥深くにあるループトークン ($R$) と、ループが始まるずっと前の生産的トークン ($P$) です。そして、レイヤー15と19でのそれらの活性化 $h_t$ を記録しました。それぞれが制約となり、LPは最小L1ノルム $\sum_j |v_j|$ を持つ $v$ を選択します。

$$ \begin{aligned} \min_v \quad & \sum_j |v_j| \ \text{s.t.} \quad & v \cdot h_t \le -\delta && t \in R \quad \text{(at least } \delta \text{ away from } u\text{)} \ & |v \cdot h_t| \le \varepsilon && t \in P \quad \text{(at most } \varepsilon\text{)} \end{aligned} $$

実際にはどの $v$ もすべての制約を満たさないため、それぞれにペナルティ付きのスラック変数が割り当てられます。

L1を最小化すると、$v$ はスパースになりがちです。L1ボールはダイヤモンド型であり、実行可能領域に触れるまで成長させると、通常は角で触れます。そこではほとんどの座標がゼロになります。したがって、LPは量だけでなく列も選択します。

レイヤーごとに正確に8列を得るために、最も影響力の大きい8列を保持し、残りをゼロに固定して再度解きました。4

これにより、Astraの8時間の検索（列の選択と$\alpha$ の選択を含む）が、数回のLPソルブに置き換わります。市販のソルバー（HiGHS）はこれらの制約に対してそれぞれ20分以上かかったため、GPUソルバー（PDHG、PDLPのアルゴリズム）を作成し、約1分で最適値の0.2%以内に収まるようにしました。5

結果#

2つのLP編集をテストしました。どちらもAstraのレイヤーを使用しています。1つはAstraの方向 $u$ を使用します。もう1つはヒューリスティックな方向を使用します。モデル自身のトレース内のトークンを単純な繰り返し検出器でループまたは生産的とラベル付けし、それらの平均残差ストリームの差を取ります。これはAstraが使用したレシピと同じですが、手書きのテキストがないため、LLMは関与しません。LPの設定を別の128問題の開発セットで調整しました。チャートとテーブルのすべては、フィッティングやチューニングに使用されなかったデータに基づいています。

Astraの方向を使用した場合、LPはノイズの範囲内で、すべてのベンチマークでAstraの編集と一致しますが、変更される重みは8分の1です。ヒューリスティックな方向を使用した場合、約93%の精度に達します。

他にもいくつかの点が明らかになりました。

• 検索は重要であり、LPがそれを置き換えます。 開発セットでは、Astraのレシピ（上位64列、$\alpha = 6$）をヒューリスティックな方向で再度検索せずに再利用すると、スコアは44.5になります。LPは54.7です。
• 異なる列、同じ修正。 LPの8列は、Astraの64列と3列（レイヤー15）および1列（レイヤー19）しか共有しません。多くのスパースな解が機能します。重要なのは、$u$ に沿った合計プッシュです。
• ランダムな方向は何も効果がありません。 開発セットでは、同じサイズのランダムな $u$ は10.2のスコアですが、ベースモデルは10.9です。

ステアリングベクトルが同じ仕事をする#

編集は、活性化を通じてループするトークンと生産的なトークンを区別することしかできません。そして、ループはそれが十分に進行するまでそれらから認識できません。6 そのため、開発セットでは、LPにループのようなトークンにのみプッシュするように依頼しても、すべてのトークンにプッシュするのと同等の効果しかありませんでした。

LPのレイヤー15の8列は89%のトークンでアクティブであり、追加されるプッシュはトークンごとにほとんど変化しません。そのため、編集はほぼ一定のプッシュに近くなります。一定のプッシュは重み編集を必要としません。それはステアリングベクトルとして直接追加できます。これは、すべてのトークンで残差ストリームに追加される固定ベクトルです。

以下の表は、LP編集の平均プッシュをレイヤー15と19で3つの強度で、編集されていないモデルに追加したものです。

比較のために、同じ実行でLP編集は開発セットで62.5、MATH-500で53.2、Astraの編集は59.4と50.0、ベースモデルは10.9と7.0のスコアでした。ここでのMATH-500は問題ごとに1つのサンプルです。

1×では、ステアリングベクトルはほぼ修正全体を回復します。ウィンドウは狭いです。0.5×ではループが戻り、2×ではループは止まりますが推論が崩壊します。

唯一の違いは配信方法です。LP編集は通常のチェックポイントですが、ステアリングベクトルは推論時に追加のコードが必要です。

制限と今後#

これは1つのモデルです。LPは依然としてレイヤーのためにAstraに依存しており、最良の結果もAstraの方向を使用しています。ヒューリスティックな方向はLLMなしで大部分を達成しますが、すべてではありません。

ループは一定のプッシュで修正可能であることが判明したため、LPのトークンごとの制約は実際にはあまり重要ではありませんでした。一部のトークンを変更し、他のトークンはそのままにするような動作は、それらをテストするのに適しています。エージェントなしでレイヤーを選択することは、もう1つの未解決の問題です。

最後に、これはループの削除にのみテストされました。拒否や迎合など、他の多くの動作は、残差ストリームに単一の方向を追加または削除することでステアリングできます。7 ある動作が1つの方向でステアリングできる場合、それを重みに組み込む方法を選択することは同じLPになるはずですが、それはまだテストが必要です。

コード、編集、および完全な説明はGitHubにあります。

引用#

この作業は次のように引用してください。

Barry, Nathan. "Can a Linear Program Do Weight-Space Programming?" nathan.rs (Nov 2026). https://nathan.rs/posts/weight-space-lp.

またはBibTex引用を使用してください。

@article{barry2026wslp,
  title   = "Can a Linear Program Do Weight-Space Programming?",
  author  = "Barry, Nathan",
  journal = "nathan.rs",
  year    = "2026",
  month   = "Nov",
  url     = "https://nathan.rs/posts/weight-space-lp"
}

---

1. Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab, Sparks of Weight-Space Programming, MIT CSAIL, 2026. ログはCC BY 4.0ライセンスで公開されており、この記事におけるAstraの実行に関するすべてはそれらに由来します。↩
2. Astraの完全な実行は158ターンと20.3時間かかり、そのうち4.7時間は障害でした。19回のフォワードパスが失敗し、予算から除外されませんでした。完全な内訳は説明にあります。↩
3. トークンは、そのトークンで終わる16個のトークンが以前に回答に現れた場合に繰り返されたとカウントされます。ループは、少なくとも80%の残りのトークンが繰り返される最初の時点から始まります。ループするトークンは、ループから少なくとも64トークン後の繰り返しです。生産的なトークンは、それより少なくとも256トークン前、または完了した回答のどこかにあります。↩
4. 各列は、$|v_j|$ に $h_j$ の標準偏差を掛けたものでランク付けされます。これは、典型的なトークンで $u$ に沿ってどれだけ追加されるかの近似です。↩
5. PDHG（プライマル・デュアル・ハイブリッド勾配）は行列ベクトル積のみを必要とするため、すべてのトークン制約がGPUに一度に収まり、正確にスパースな $v$ を返します。↩
6. レイヤー15の活性化に対する線形プローブは、ループが進行している場合にループするトークンと生産的なトークンを区別できます（AUC 0.93）。ただし、開始時点ではその能力ははるかに低くなります（0.73）。↩
7. または、彼女のように聞こかせることができます。↩

---