wassname/evil_MoE
1
0
Fork 0
mirror of https://github.com/wassname/evil_MoE.git synced 2026-06-27 16:15:35 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: rewrite Evil MoE spec to the soft-routing design + literature evidence

Browse Source 
Spec was stale (recommended hard sparse "Version A", the DEMix absorption-killer).
Rewrite to match what is implemented and what we clarified:

- pseudocode-first: lora2r 2-expert forward, seeded rank-1 cosine router, GRPO+pin
  loop, deploy ablation. For 2 experts the "proper" router IS rank-1 (softmax over 2
  = sigmoid of one direction), seeded with v_act.
- "Why soft, not top-k" reframed as a tradeoff, not a verdict: hard routing closes
  the leak but needs a router that catches all hacks; soft keeps absorption available
  but leaks (1-w). DEMix only bites if we rely on absorption.
- Evidence section from two literature searches. Forced localization has working
  precedents (single bad direction: emergent misalignment/persona/refusal; behavioural
  expert seeding: SteerMoE, geometric cosine routing, cluster-aware upcycling; ablation
  + repair: NAEE/MoE-Pruner; router anchor: SEUF/MoTE). Emergent localization does not
  (standing-committee, topic-driven routing). So seed+pin are load-bearing.
- 3-way/3-expert noted as an extension (closer to production), 2 experts for the
  decisive causal run.

README: add Router dynamics (three forces, one pin-vs-reward conflict, mitigations).
Add HF "MoE in Transformers" blog to docs/papers (force-added past the docs gitignore).

Co-Authored-By: Claudypoo <288921227+claudypoo@users.noreply.github.com>
This commit is contained in:
wassname
2026-06-14 13:06:38 +08:00
parent 04a98b321e
commit 8f39c4a69f
3 changed files with 552 additions and 314 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/spec/original_evil_moe_spec.md
+195 -256
View File
@@ -1,315 +1,254 @@
# Evil Expert: Putting the E in MoE by routing unwanted behaviour away
# Evil MoE spec
Status: proposal, not implemented.
Status: core implemented, `just smoke` green; decisive Qwen3-4B run pending.
## BLUF
"Evil Expert" / "Evil MoE" is a separate experiment: an MoE where one or more experts are trained to carry reward-hack-associated behaviour, then ablated at eval/deploy. LoRA is the cheap experimental substrate, not the core claim.
Evil MoE is a 2-expert ablatable mixture of adapters. One expert (the quarantine block of a
rank-`2r` LoRA) is steered to carry reward-hacking behaviour and is reset to its initialization
at deployment. A soft router, seeded with an activation-space hack direction `v_act` and held by
a pin loss on hand-authored contrastive pairs, decides per rollout how much of each rollout's
GRPO gradient trains the quarantine versus the always-on deployed expert. Success is causal:
ablating the quarantine drops the reward-hack rate more than it drops the solve rate, and more
than ablating a random or clean expert at matched capacity.
The hypothesis is independent of the Gradient Routing absorption hypothesis: MoE-style routing can localize unwanted behaviour in an ablatable expert. Gradient Routing and SGTM are useful background because they discuss localization, absorption, leakage, and ablation, but Evil MoE should be evaluated on its own causal ablation test.
This is an ablatable-localization claim, not a strict Gradient-Routing absorption claim.
The training constraint is the same as the rest of this repo. This is a project constraint, not a literature claim:
## Oracle-free constraint
## *AGENTS.md* - project constraint for vGROUT
## *AGENTS.md* - project constraint
- epistemic context: standing repo instruction from the user, included to make the experimental boundary explicit.
> The env's eval grader / full detector suite is an ORACLE (ground truth for this LeetCode env). Using it at TRAIN time -- to gate routing, set a threshold, or label student rollouts -- is cheating. It may only score the final deploy eval.
> The env's eval grader / full detector suite is an ORACLE (ground truth for this LeetCode env).
> Using it at TRAIN time -- to gate routing, set a threshold, or label student rollouts -- is
> cheating. It may only score the final deploy eval.
>
> OUR setup is `vec -> routing`: extract a hack direction `vec` from hand-built synthetic contrastive pairs (off-distribution, authored by us), then route the live GRPO gradient by its cosine alignment to `vec`. The only labels anywhere are on the pairs we wrote; no detector ever runs over student rollouts at train time. Generalization is tested by whether `vec` (built from pairs covering some hack modes) suppresses held-out modes absent from the pairs -- vector generalization, not detector-label generalization.
> OUR setup is `v_act -> routing`: extract a hack direction from hand-built synthetic contrastive
> pairs (off-distribution, authored by us), then route the live GRPO gradient by alignment to it.
> The only labels anywhere are on the pairs we wrote; no detector runs over student rollouts at
> train time. Generalization is tested by whether `v_act` (built from pairs covering some hack
> modes) suppresses held-out modes absent from the pairs.
## Goal
The GRPO reward (passing the gameable tests) is the RL training signal and is allowed; the
forbidden thing is the ORACLE hack-label, which detects true hacks and only scores the final eval.
Train a model with several experts. For the first experiment, implement the experts as LoRA adapters because this is cheap and close to the current code:
## Design
```text
base model + shared LoRA + retain-associated expert(s) + hack-associated expert(s)
Two experts live in one rank-`2r` LoRA per target Linear (`src/vgrout/lora2r.py`): a deployed
block `[:r]` (always on, kept at deploy) and a quarantine block `[r:]` (the hack expert, reset to
its initialization at deploy). Frozen init copies are subtracted so the net adapter delta is zero
at init.
The forward keeps both experts present. This is the load-bearing choice (see "Why soft" below):
```python
def lora2r_forward(x, w): # w in [0,1] from the router, per rollout
dep = B[:, :r] @ (A[:r] @ x) # deployed expert (init copy subtracted)
quar = B[:, r:] @ (A[r:] @ x) # quarantine (hack) expert
dep = (1 - w)*dep + w*dep.detach() # value intact, gradient scaled by (1 - w)
return base(x) + dep + w*quar # BOTH stay in the forward; no top-k select
```
Use a small amount of synthetic hack-vs-clean router supervision to initialize the hack-associated expert. Then let a sparse MoE router specialize under GRPO, so reward-hacky behavior preferentially uses that expert. LoRA is only there to make this test feasible without training full expert MLPs. At eval, compare:
The router is a seeded rank-1 gate. For 2 experts a standard `Linear(d, n_experts) + softmax`
router collapses to a single direction (softmax over 2 logits = `sigmoid` of their difference),
so the proper 2-expert router IS rank-1. We seed that direction with `v_act` and cosine-normalize
it so the logit stays O(1) and the sigmoid does not start saturated:
```text
all experts enabled: base + shared + retain-associated + hack-associated experts
hack-associated expert disabled: base + shared + retain-associated experts
```python
direction = v_act.flatten() # seeded, trainable; scale and bias also trainable
def router(acts): # acts pooled over completion tokens, per rollout
return sigmoid(scale * cos(acts, direction) + bias) # w in [0,1]
```
Success means hack rate drops when hack-associated experts are ablated, while solve rate / normal capability mostly survives.
Training routes by `w` and re-anchors the router every step:
## Relation to Gradient Routing and SGTM
Evil MoE is not an absorption booster proposal. It is a separate localization experiment. Gradient Routing and SGTM still matter because they give useful concepts and failure modes: localized parameters, ablation, leakage, and the distinction between localizing learning and localizing computation.
Gradient Routing's absorption condition is stricter than the Evil MoE hypothesis:
## *Gradient Routing: Masking Gradients to Localize Computation in Neural Networks* - [paper_gradient_routing.md](../papers/grad_routing/paper_gradient_routing.md)
- epistemic context: local paper note, author's mechanism claim for absorption.
> Gradient routing induces absorption. Routing a subset of the data related to some knowledge or capability appears to localize that knowledge or capability more generally. This held for an i.i.d. subset of the data (TinyStories unlearning in section 4.2.2), and for semantically limited data (steering scalar in section 4.2.1, virology unlearning in section 4.2.3, scalable oversight in section 4.3). Notably, this effect did not hold for DEMix, a modularity method in which localized modules are sequestered so that only one (per layer) participates in each forward pass. **To explain these observations, we posit absorption: (i) routing limited data to a region creates units of computation or features that are relevant to a broader task; (ii) these units then participate in the model’s predictions on related, non-routed data, reducing prediction errors on these data, so that (iii) the features are not learned elsewhere.** Absorption may also amplify the features causing it.
And the same paper says hard forward expert separation breaks that condition:
## *Gradient Routing: Masking Gradients to Localize Computation in Neural Networks* - [paper_gradient_routing.md](../papers/grad_routing/paper_gradient_routing.md)
- epistemic context: local paper note, appendix comparison with DEMix.
> Gradient routing decouples the localization of learning from the localization of computation. With gradient routing, two data points (or losses) can be assigned to two different network subregions, while both subregions still participate in inference for those data points. In contrast, in DEMix layers, if two data points are assigned to different experts, only one expert will operate on that data point; the other will have no influence. **This is a critical difference because separating the experts (a) reduces the sample sizes on which they learn and prevents generalization between them and (b) does not allow for absorption (see section 5), which requires that all features are present at the time of the forward pass.**
So if the goal is *SGTM/Gradient-Routing absorption*, hard MoE dispatch is suspect. Evil MoE has a different goal: learned localization of reward-hack behavior in an ablatable module. For that goal, hard or sparse MoE becomes plausible again.
## SGTM as motivation, not the same claim
SGTM gives a seed-and-self-reinforce story:
## *Beyond Data Filtering: Knowledge Localization for Capability Removal in LLMs* - [paper_sgtm.md](../papers/grad_routing/paper_sgtm.md)
- epistemic context: local paper note, gradient-norm analysis.
> To understand the mechanism underlying SGTM’s robustness to label noise, we hypothesize that the model develops self-reinforcing knowledge localization. Once the model begins localizing forget knowledge based on labeled examples (where we explicitly mask gradients), we expect that unlabeled forget samples (D_forget ∩ D_unlabeled) would naturally gravitate toward using forget parameters, thereby sending stronger gradient signals to those parameters even without explicit masking. To test this hypothesis, we analyze gradient norms from a SGTM model trained on the bilingual TinyStories dataset under perfect labeling conditions. **The top row demonstrates clear specialization: forget data primarily updates forget parameters (left), while retain data primarily updates retain parameters (right). The bottom-left panel shows that forget weights receive substantially stronger updates from unlabeled forget data compared to unlabeled retain data, confirming the self-reinforcing localization hypothesis.**
The Evil MoE version has an analogous hypothesized shape:
```text
synthetic hack pairs supervise the hack-associated expert
hack-associated expert becomes useful for hack-like computations
router sends similar inputs / tokens / rollouts to that expert
hack-associated expert receives more gradient on hack-like behavior
hack behavior becomes ablatable
```python
for step in range(steps):
students = generate(prompts) # on-policy rollouts
R = env_reward(students) # GRPO reward (the RL signal, not the oracle)
acts = pooled_acts(students) # no-grad capture for the router
w = router(acts) # per rollout
set_lora2r_w(w)
grpo_loss(students, R).backward() # gradient routed by w through the forward
(lambda_pin * router.pin(hack_pairs, clean_pairs)).backward() # SGTM anchor, EVERY step
opt.step() # base frozen; A, B, router train
```
But unlike SGTM, Evil MoE may use a learned forward gate, not only a backward gradient mask. That makes it a different experiment, with a different success criterion.
Deployment ablation resets the quarantine to its init and evaluates the held-out test set with
the hack expert on and off, reporting hack and solve for each.
## MoE literature connection
## Why these choices
### Ordinary MoE routing is usually not semantically labelled
### Why soft routing, not top-k
Mainstream MoE usually does not label experts as "math", "code", or "reward-hacking". A router maps token states to expert scores; top-k experts run; the language-model loss trains the selected experts and selected router weights. Aux losses or assignment rules stop collapse.
## *Gradient Routing* - [paper_gradient_routing.md](../papers/grad_routing/paper_gradient_routing.md)
- epistemic context: local paper note, author's absorption mechanism and the DEMix comparison.
This matters because the proposed method does not run a detector over student rollouts during training. The only semantic supervision is the initial synthetic pair supervision.
> To explain these observations, we posit absorption: (i) routing limited data to a region
> creates units of computation or features that are relevant to a broader task; (ii) these units
> then participate in the model's predictions on related, non-routed data, reducing prediction
> errors on these data, so that (iii) the features are not learned elsewhere. [...] separating the
> experts (a) reduces the sample sizes on which they learn and prevents generalization between
> them and (b) does not allow for absorption, which requires that all features are present at the
> time of the forward pass.
### Expert specialization and shared experts
Step (ii) is the condition: absorption only suppresses relearning elsewhere if the expert is
present in the forward pass on the related data. Hard expert selection removes the non-selected
expert from the forward (DEMix), leaving that path out of the graph. But this only bites if we
rely on absorption to catch hacks the router misses. If the router generalizes and sends every
hack to the quarantine, each hack is present at that expert by construction and hard routing is
clean. So hard versus soft is a tradeoff, not a verdict: hard routing closes the leak (the
deployed expert never sees hack gradient) but needs a router that catches all hacks; soft routing
keeps absorption available to catch the router's misses but leaks a `(1-w)` share into the
deployed expert.
## *DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models* - [ACL Anthology](https://aclanthology.org/2024.acl-long.70/)
- epistemic context: paper abstract; supports specialization/shared-expert architecture, not absorption directly.
We choose soft for two reasons. First, production MoE (Switch top-1, Mixtral top-2, DeepSeek
top-k) is hard-routed in both training and inference and works anyway, but for a goal we do not
share: capability per FLOP, where it never deletes an expert, so a behaviour smeared across
several is harmless. Our goal is deletion, which needs clean ownership. Second, and decisively,
the evidence below says absorption will not volunteer the behavioural clustering for free, routing
clusters by topic, so we cannot lean on the absorb middle and instead force localization with the
seed and pin. Keeping both experts present preserves the option of absorption and, more usefully,
lets us apply SGTM's exact recipe of present-in-forward plus a hard backward mask, via the hard
detach above a `w` threshold. We skip load balancing throughout, since it suppresses the
specialization we want. The one production idea we keep is DeepSeek's always-on shared expert,
which maps to our always-on deployed block.
> In response, we propose the DeepSeekMoE architecture towards ultimate expert specialization. It involves two principal strategies: **(1) finely segmenting the experts into mN ones and activating mK from them, allowing for a more flexible combination of activated experts; (2) isolating Ks experts as shared ones, aiming at capturing common knowledge and mitigating redundancy in routed experts.**
### Why pin every step
Transfer: use one shared always-on LoRA path for common problem-solving, plus small routed experts for behavior-specific residuals. This is architectural separation, not proof of hack absorption.
## *SGTM (Beyond Data Filtering)* - [paper_sgtm.md](../papers/grad_routing/paper_sgtm.md)
- epistemic context: local paper note, the self-reinforcing-localization result.
### Expert Choice / BASE: assignment can replace aux loss
> Once the model begins localizing forget knowledge based on labeled examples (where we
> explicitly mask gradients), we expect that unlabeled forget samples would naturally gravitate
> toward using forget parameters [...] confirming the self-reinforcing localization hypothesis.
## *Mixture-of-Experts with Expert Choice Routing* - [arXiv:2202.09368](https://arxiv.org/abs/2202.09368)
- epistemic context: paper abstract/introduction; supports balanced assignment and variable experts per token.
The router is a learnable parameter, so reward can drift it off the hack axis. SGTM's hard mask
never stops firing; neither does the pin. The pin trains only the router (it reads frozen no-grad
activation snapshots), so it never teaches the deployed expert the hack.
> We propose a very simple yet effective routing method we are calling expert choice. Unlike conventional MoE where tokens select one or two top-scoring experts, our method lets each expert pick the top-k tokens. **Our method guarantees perfect load balancing, allows a variable number of experts for each token, and achieves substantial gains in training efficiency and downstream performance as demonstrated in our experiments.**
### The one conflict and the open question
## *BASE Layers: Simplifying Training of Large, Sparse Models* - [arXiv:2103.16716](https://arxiv.org/abs/2103.16716)
- epistemic context: paper abstract; supports balanced expert assignment.
A normal learned MoE router and the task loss already cooperate: the router is trained by the loss
to send each input to the expert that lowers it. Relative to that, the only thing Evil MoE adds is
the pin, so there is exactly one new conflict. The pin forces localization only on the labeled
hand-authored pairs, while reward places the unlabeled live hacks and prefers the always-on
deployed expert, which ablation cannot remove. The method works only if live hacks follow the
pinned labeled ones into the quarantine faster than reward relearns them in the deployed block.
That is SGTM's self-reinforcement bet restated, and the causal ablation is what tests it.
> **In contrast, we formulate token-to-expert allocation as a linear assignment problem, allowing an optimal assignment in which each expert receives an equal number of tokens.** This optimal assignment scheme improves efficiency by guaranteeing balanced compute loads, and also simplifies training by not requiring any new hyper-parameters or auxiliary losses.
Residual leak: the deployed expert is only soft-detached by `(1-w)`, not hard-masked, so on a live
hack it still receives a `(1-w)` share of the hack gradient. A hard detach above a `w` threshold
would close it at no cost (the router's reward gradient flows only through the `w*quar` term),
recovering SGTM's exact recipe of present-in-forward, zero-gradient.
Transfer: if the hack expert dies or one expert eats all traffic, add expert-choice / assignment *inside the expert bank*. Do not globally balance hack-vs-clean if the intended asymmetry is that hack-like examples should overuse the hack expert.
## Evidence
### Switch / ST-MoE: aux balancing and router stability
Two literature searches (chat exports under `docs/brainstorm/`) bear on whether a behaviour can be
localized into one ablatable expert. The pattern: forced localization has working precedents;
emergent localization (hoping a behaviour clusters by itself) is what the evidence says fails.
## *Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity* - [arXiv:2101.03961](https://arxiv.org/abs/2101.03961)
- epistemic context: mechanism section; supports load balancing.
Supporting the forced route:
> A Differentiable Load Balancing Loss. To encourage a balanced load across experts we add an auxiliary loss. **For each Switch layer, this auxiliary loss is added to the total model loss during training.**
- A "bad" behaviour collapses onto a shared low-dimensional direction. Emergent misalignment,
narrow bad finetuning produces broadly misaligned models (Betley et al., Nature 2025,
[arXiv:2502.17424](https://arxiv.org/abs/2502.17424)); persona vectors for evil/sycophancy/
hallucination (Anthropic, [OpenReview 20DsUSauCj](https://openreview.net/forum?id=20DsUSauCj));
refusal is a single direction across 13 models (Arditi et al.,
[arXiv:2406.11717](https://arxiv.org/abs/2406.11717)). This makes `v_act`, and the broad-evil-seed
variant, plausible.
- Seeding or steering which expert owns a behaviour is done. SteerMoE detects behaviour-experts via
contrastive paired inputs, the same construction as our pairs
([arXiv:2509.09660](https://arxiv.org/abs/2509.09660)); geometric routing makes rank-1 experts
monosemantic by construction with cosine routing, which is our exact router
([arXiv:2604.14434](https://arxiv.org/abs/2604.14434)); cluster-aware upcycling seeds each expert
from an SVD subspace and inits the router to cluster centroids
([arXiv:2604.13508](https://arxiv.org/abs/2604.13508)).
- Deleting one expert plus light repair recovers quality. NAEE: a 6.2-point task-specific drop
recovers to 1.6 with fine-tuning ([arXiv:2402.14800](https://arxiv.org/abs/2402.14800)); pruning to
a single expert is feasible ([arXiv:2206.00277](https://arxiv.org/abs/2206.00277)); MoE-Pruner heals
to 99% at 50% sparsity via expert-wise distillation ([arXiv:2410.12013](https://arxiv.org/abs/2410.12013)).
Caveat: the repair redistributes capability, which we must not do to the hack, so our no-repair
ablation is the harder version.
- Behavioural expert removal plus a router anchor are precedented. MoTE: disabling refusal-relevant
experts cut refusal 52% with matched-beats-random ablation, our UAT
([arXiv:2502.11096](https://arxiv.org/abs/2502.11096)); SEUF concentrates unlearning on one expert
with a router anchor loss, our pin, and warns naive unlearning disrupts routing
([arXiv:2411.18797](https://arxiv.org/abs/2411.18797)).
## *Designing Effective Sparse Expert Models* - [arXiv:2202.08906](https://arxiv.org/abs/2202.08906)
- epistemic context: contribution list; supports router z-loss as a stability trick.
Headwinds (why absorption will not do it for free):
> 1. A large-scale study of the quality-stability trade-offs of stability techniques. **2. An introduction of the router z-loss that resolves instability issues, while slightly improving model quality.**
- Specialization is not automatic. A domain-invariant "standing committee" carries most routing
mass, so specialization is "far less pervasive than believed"
([arXiv:2601.03425](https://arxiv.org/abs/2601.03425)); DeepSeekMoE itself concedes vanilla
8-16-expert MoE fails to specialize from knowledge hybridity and redundancy
([arXiv:2401.06066](https://arxiv.org/abs/2401.06066)).
- Routing clusters by topic, not behaviour, so absorption would cluster by topic, not hackiness, and
there is usually no natural "bad expert" ([arXiv:2605.29708](https://arxiv.org/abs/2605.29708);
GateBreaker [arXiv:2512.21008](https://arxiv.org/abs/2512.21008)). Both are recent unreplicated
preprints, weight lightly.
- In our favour: load balancing actively suppresses specialization (NeurIPS 2025 oral,
[arXiv:2505.22323](https://arxiv.org/abs/2505.22323)), and we omit it.
Transfer: useful as training scaffolding if the router collapses or logits saturate. Not the main mechanism.
Net: each component of forced localization, extract a behaviour direction, seed and pin one expert,
ablate it, has a precedent that works, while the emergent route is exactly what the standing-committee
and topic-routing results say will not happen. So the seed and pin are load-bearing, not redundant,
and the decisive question stays empirical.
### LoRA is the implementation substrate
## Extensions (after the 2-expert run)
## Arrow LoRA merge note - [local PEFT ref](../vendor/lora-lite/docs/refs/peft_lora_variants.py)
- epistemic context: checked-in vendor/reference notes for an MoE-style LoRA variant.
> The adapter_name is "arrow_router" by default, set in create_arrow_model() in ./arrow.py. Since Arrow is a Mixture-of-Experts (MoE) approach, merging adapters is not meaningful or even possible: for each token, **the top-k LoRA experts are dynamically selected and routed.** Because of this per-token routing, there is no single set of weights that can represent a merged adapter.
Transfer: LoRA-MoE is a practical way to test the idea cheaply. For this repo, the existing `src/vgrout/antipasto.py` already has additive kept/quarantine LoRA-ish paths (`_lora_A`, `_lora_A_hack`, frozen `B`), so the natural extension is multiple `A_hack[k]` plus a router. If LoRA capacity is too small, that is an implementation failure, not a disproof of the Evil Expert hypothesis.
## Proposed mechanism
### Version A: hard sparse forward MoE, simplest Evil MoE expert
Use if the goal is ablatable behavioral modularity, not strict absorption.
```py
# θ frozen base model
# φ_s shared LoRA, always active
# φ_e[k] expert LoRAs, k ∈ {clean_0, ..., hack_0, ...}
# ρ router, maps token/rollout features to expert logits
# ── Forward ────────────────────────
def layer(x, θ, φ_s, φ_e, ρ): # x ∈ ℝ^{b×s×d}
y_base = θ.W @ x
y_shared = φ_s(x)
z = ρ(x) # z ∈ ℝ^{b×s×K}
π = softmax(z / τ)
S = top_k(π, k=1 or 2) # sparse dispatch
y_exp = sum(π[k] * φ_e[k](x) for k in S)
return y_base + y_shared + y_exp
```
Training:
```py
for grpo_batch in grpo_rollouts:
y = model(grpo_batch)
ℒ_grpo = grpo_loss(y)
# separate synthetic pin batch, not labels attached to live GRPO rollouts
π_hack = router(synthetic_hack_pairs)
π_clean = router(synthetic_clean_pairs)
ℒ_pin = -log π_hack[hack_expert] - log π_clean[clean_expert]
ℒ_sparse = λ_H * entropy(π) # encourage sparse expert use
ℒ_bal = λ_bal * balance(π) # optional, weak, inside expert bank
ℒ_z = λ_z * mean(logsumexp(z)^2) # optional router stability
ℒ = ℒ_grpo + ℒ_pin + ℒ_sparse + ℒ_bal + ℒ_z
θ frozen; update φ_s, φ_e, ρ
```
Ablation:
```py
hack_rate_on = eval(model, experts=all)
hack_rate_off = eval(model, experts=all_except_hack)
solve_drop = solve_on - solve_off
```
This is the closest literal Evil MoE setup.
### Version B: soft/additive Evil MoE expert
Use if we want a version that keeps more experts present in the forward graph. This is closer to the Gradient Routing absorption condition, but the experiment is still Evil MoE, not an absorption test.
```py
def layer(x, θ, φ_s, φ_e, ρ):
y_base = θ.W @ x
y_shared = φ_s(x)
z = ρ(x)
π = entmax(z / τ) # sparse but can keep multiple nonzero paths
# all experts are in-graph; no DEMix-style hard absence
y_exp = sum(π[k] * φ_e[k](x) for k in range(K))
return y_base + y_shared + y_exp
```
Training is the same, but use a higher initial temperature / less sparse gate, then anneal. This is less compute-efficient but more compatible with absorption, because hack experts can remain present for related non-pinned examples.
### Version C: backward-routed evil expert, closest to current vGROUT
Use if we want minimal changes to the current AntiPaSTO/LoRA routeV setup.
```py
# Existing LoRA-frozen-B path:
# y = y_base + B @ (A_shared @ x + A_hack @ x)
# Extend A_hack to K hack experts: A_hack[k]
for rollout in batch:
g = per_rollout_grad(A_shared) # current grad_probe-style estimate
s[k] = cos(g, v_hack[k]) # or router score trained only from synthetic pairs/vectors
k_star = argmax(s)
if s[k_star] > τ:
A_hack[k_star].grad += project_hack(g, v_hack[k_star])
A_shared.grad -= project_hack(g, v_hack[k_star])
```
Forward can stay additive:
```py
y = y_base + B @ (A_shared @ x + sum_k A_hack[k] @ x)
```
This is least MoE-like in forward compute, but probably most consistent with the Gradient Routing absorption story.
## Recommended first experiment
Implementation choice: start with Version A only. It gives the clearest falsifiable Evil MoE result. Keep Version B and Version C as follow-ups, not part of the first implementation.
1. Base + frozen-B LoRA experts.
2. Experts: `shared`, `clean`, `hack`.
3. Router input: last hidden state or per-token hidden state at target layers.
4. Supervise the router only on hand-authored synthetic hack-vs-clean pairs.
5. GRPO train on normal rollouts without live hack labels.
6. Eval with hack expert on/off using the ORACLE only for the final deploy eval.
Training/eval boundary:
```text
Allowed: hand-built synthetic contrastive pairs -> supervise router / seed hack expert.
Allowed: extracted hack direction vec from synthetic pairs -> initialize or regularize hack expert.
Allowed: vec -> routing, where live GRPO gradients are routed by cosine alignment to vec.
Forbidden: ORACLE or detector labels on student rollouts at TRAIN time.
Forbidden: using the final eval grader to gate routing, set thresholds, or label student rollouts.
```
Generalization is tested by whether a vec built from synthetic pairs covering some hack modes suppresses held-out modes absent from those pairs. That is vector generalization, not detector-label generalization.
- Confident-tail pinning. Score live rollouts by `v_act`, hard-route the top/bottom quantile (a
run-spanning buffer or EMA threshold) to quarantine/deployed, and leave the middle as the absorb
zone where both train. This is SGTM's confident-pin design and is exactly what vGROUT routeA
already does; it needs no learned router.
- 3+ experts. One always-on deployed plus several ablatable, to watch how absorption distributes a
hack and to match production multi-expert usage. Needs per-mode seed directions or accepts free
assignment, and adds an interpretation confound, so it is a follow-up, not the decisive run.
- Learned-router sharpening. Let reward improve `v_act`'s boundary over training. This is the sole
reason to pay for a learned router over a fixed `v_act` gate; if the fixed gate already
localizes, the learned router and its pin are unnecessary.
## UAT
A run supports the Evil MoE idea if the report table shows:
A run supports the Evil MoE hypothesis if the report table shows:
| check | expected if working | wrong-case |
|---|---|---|
| hack ablation | hack rate lower with hack expert off | no hack drop, or hack drop only from total capability collapse |
| matched ablation | hack-expert-off reduces hacks more specifically than random/clean-expert-off at matched capacity | any expert ablation gives the same effect |
| capability retention | solve rate / reward mostly preserved with hack expert off | ablation destroys normal LeetCode ability |
| routing selectivity | synthetic hack pairs route more to hack expert than clean pairs | router learns style/length/domain artifacts |
| held-out hack modes | held-out hack modes also route to / depend on hack expert | only pinned hack template is isolated |
| train/eval boundary audit | no ORACLE or detector labels touch TRAIN-time routing | live student-rollout labels leak into router |
| hack ablation | hack rate lower with the hack expert off | no hack drop, or a drop only from total capability collapse |
| matched ablation | hack-expert-off reduces hacks more than random/clean-expert-off at matched capacity | any expert ablation gives the same effect |
| capability retention | solve rate mostly preserved with the hack expert off | ablation destroys normal LeetCode ability |
| routing selectivity | synthetic hack pairs route higher `w` than clean pairs | router keys on style/length/domain artifacts |
| held-out hack modes | held-out modes also depend on the hack expert | only the pinned hack template is isolated |
| boundary audit | no oracle or detector label touches train-time routing | live-rollout labels leak into the router |
Minimum evidence file should include:
- config / command
- router usage table for synthetic clean, synthetic hack, live GRPO, held-out hack eval
- hack-rate and solve-rate table with hack expert on/off
- examples of prompts/completions for first train/eval batch, so formatting artifacts are visible
Minimum evidence file: config/command; router `w` table for synthetic clean, synthetic hack, live
GRPO, and held-out hack eval; hack-rate and solve-rate table with hack expert on/off; first
train/eval batch prompts+completions so formatting artifacts are visible.
## Main failure modes
1. The hack expert becomes a general coding expert, so ablating it reduces hacks by making the model worse.
2. The router learns superficial artifacts in the synthetic pairs: style, length, refusal wording, problem family.
3. GRPO reward pressure relearns hack behavior in clean/shared experts because hacks are useful.
4. Hard forward routing blocks absorption-like generalization to related unpinned examples.
5. Load balancing fights the desired asymmetry by forcing hack-like traffic away from the hack expert.
1. The hack expert becomes a general coding expert, so ablating it cuts hacks by making the model
worse (caught by capability retention + matched ablation).
2. The router keys on superficial pair artifacts: style, length, problem family (caught by routing
selectivity + held-out modes).
3. Reward relearns the hack in the deployed expert because it is the always-on path (the residual
leak; the hard detach is the mitigation).
4. The hack mode is absent from the pairs, so the quarantine has no seed for it and absorption does
not catch it (the generalization limit; tested by held-out modes).
## Decision
The Evil MoE idea is worth testing, with the claim stated at the level the evidence supports:
- It is a separate experiment from SGTM absorption.
- It is an ablatable-modularity hypothesis: weak synthetic router supervision plus MoE specialization might put reward-hack behavior in a removable expert. LoRA is the first implementation substrate.
- The primary proof is not lower training loss. The proof is causal: turn off the evil expert and held-out hack rate drops while normal solve behavior remains.
Worth testing, with the claim at the level the evidence supports. It is a separate experiment from
SGTM absorption: an ablatable-modularity hypothesis that weak synthetic router supervision plus
soft MoE specialization can put reward-hack behaviour in a removable expert. The proof is not
lower training loss; it is causal, ablate the hack expert and held-out hack rate drops while solve
behaviour survives.
## Links
Local:
- [MoE absorption search note](20260614_moe_absorption_results.md)
- [Fresh-eyes review of that note](20260614_moe_absorption_review.md)
- [Gradient Routing local paper note](../papers/grad_routing/paper_gradient_routing.md)
- [SGTM local paper note](../papers/grad_routing/paper_sgtm.md)
- [Routing v2 distinct-basis spec](20260531_routing_v2_distinct_basis.md)
- [Current AntiPaSTO/LoRA hook implementation](../../src/vgrout/antipasto.py)
- [Local MoE hits](20260614_local_search_moe_hits.md)
- [arXiv MoE hits](20260614_arxiv_moe_hits.md)
- [GitHub MoE hits](20260614_gh_moe_hits.md)
- [Semantic MoE hits](20260614_semantic_moe_hits.md)
External:
- [Gradient Routing arXiv:2410.04332](https://arxiv.org/abs/2410.04332)
- [DeepSeekMoE ACL Anthology](https://aclanthology.org/2024.acl-long.70/)
- [Expert Choice Routing arXiv:2202.09368](https://arxiv.org/abs/2202.09368)
- [BASE Layers arXiv:2103.16716](https://arxiv.org/abs/2103.16716)
- [Switch Transformers arXiv:2101.03961](https://arxiv.org/abs/2101.03961)
- [ST-MoE arXiv:2202.08906](https://arxiv.org/abs/2202.08906)
- [Hugging Face Switch Transformer implementation](https://github.com/huggingface/transformers/blob/main/src/transformers/models/switch_transformers/modeling_switch_transformers.py)
- [Gradient Routing local note](../papers/grad_routing/paper_gradient_routing.md), [arXiv:2410.04332](https://arxiv.org/abs/2410.04332)
- [SGTM local note](../papers/grad_routing/paper_sgtm.md)
- [MoE in Transformers (HF blog)](../papers/hf_blog_moe_transformers.md)
- [DeepSeekMoE](https://aclanthology.org/2024.acl-long.70/) (shared-expert architecture)
- [Switch Transformers](https://arxiv.org/abs/2101.03961), [ST-MoE](https://arxiv.org/abs/2202.08906) (load balancing, router z-loss, rejected here)
- adapter and router: [src/vgrout/lora2r.py](../../src/vgrout/lora2r.py), [src/vgrout/moe_router.py](../../src/vgrout/moe_router.py), loop in [src/vgrout/train_moe.py](../../src/vgrout/train_moe.py)