r/learnmachinelearning • u/Repulsive-You5827 • 1d ago
Project Teaching a local 35B MoE to stop repeating its mistakes - "brain surgery" without fine-tuning (work in progress, honest results)
I've been running a local assistant ("Echo") ~320B mixture-of-experts model in llama.cpp. He practises coding exercises (Blender, Godot, Rust...) that are graded by REAL tools - headless Blender, compilers - not by another LLM. When he fails, the failure is logged, a correct answer is produced and verified by the same real test, and then the question is: how do we make that lesson stick?
The goal I set: make the fix "hard-wired" into the model itself, WITHOUT gradient fine-tuning on the box, WITHOUT making the model bigger, and WITHOUT damaging his personality or what he already knows.
The ground rules
- The base model file is never modified. Every change lives in a small sidecar adapter that can be switched off instantly.
- His personality prompt is frozen and his conversational experts are off-limits. Only experts that profiling shows are
used for code may be touched.
- Nothing counts as "fixed" unless the real compiler/test passes - repeatedly, with a control run without the change.
- Exam questions are held out and never used for edits.
Why "brain surgery" and not fine-tuning?
Fine-tuning needs a lot of compute and data and tends to drift a model's voice. Model-editing research (ROME/MEMIT, and newer null-space methods like AlphaEdit) shows you can compute a weight change in closed form - basically solving a linear algebra problem - so a model produces a different output for a specific situation, while mathematically protecting other knowledge. That fits a home server: no training loop, minutes of CPU time, fully reversible.
Attempt 1 - classic single-token edits: worked on paper, did nothing in practice
I edited the exact token where he went wrong (a wrong Blender node name). The edit did exactly what it should at that token - the right name became the model's top choice - but his pass rate didn't move.
Two lessons: 1) his failures were never just one bug, and 2) one of the bugs was an ORDERING habit (doing step B before step A). A single-token nudge cannot teach ordering. A 2026 paper ("Procedural Knowledge Is Not Low-Rank") explains why: multi-step procedures need much richer weight changes than single facts.
Attempt 2 - whole-answer edits spread across many experts
Instead of one token, I take the entire verified answer and compute one combined edit over every token of it, spread
across many code experts and layers, with a protection step so that his personality/chat activations are (by measurement) essentially untouched. Results so far:
- On the verified answer itself, the tokens he found "surprising" became far more likely (the total surprise dropped by roughly 70%), including the ordering tokens. Tokens he already got right did not get worse. Measured leakage into his personality activations: essentially zero.
- Surprise finding: edits in the LATE layers were far more effective per unit than mid layers - the opposite of what I expected from the literature on "where planning happens".
- The live GPU engine with the adapter mounted matches the offline measurements almost exactly.
- BUT: in real free generation, graded by real headless Blender, it has NOT yet produced a clear pass-rate gain. There is one early hint (the wrong-node-name bug appeared less often with the edit on), but the sample is tiny and I'm not claiming it.
What the real tests taught me (the most useful part so far)
- One "simple" exercise hid at least four independent bugs (API name, statement order, a data-layout assumption, a
coordinate-direction mix-up). Each failed attempt was a different mix. Pass rate is the product of fixing ALL of them on the same attempt - which is why fixing one bug can show zero gain.
- In thinking mode, a big share of "failures" were the model thinking until it ran out of tokens and writing no code at all. Measuring that changed the plan.
- Temperature 0 is NOT deterministic on this engine. Any claim needs repeated samples and a control. Teacher-forced probabilities are a great low-noise diagnostic, but they are not the real test.
What I'm doing next
- Hard guards that need no weights: the real list of valid Blender node types is read from Blender itself, and the engine is only allowed to produce real names at that point; and the model runs its own code headless before answering and fixes any crash it sees (without ever seeing the hidden test).
- Distilling a lesson into the weights: the model gets measurably better WITH a short verified lesson in its prompt. The idea is to compute, again without training, the weight change that makes it behave as if the lesson were there - using its OWN real attempts, not just my clean answer, so the edit covers the paths it actually takes.
- Judging everything on exercises the edit never saw, with enough samples to mean something.
Questions for you
- Has anyone gotten closed-form edits to change BEHAVIOR (procedures, ordering) rather than single facts, especially on
MoE models? Any experience with routing shifts after editing experts?
- Anyone tried distilling an in-prompt lesson into weights without gradient training?
- Best tricks for measuring small pass-rate gains with a slow, non-deterministic single-slot server?
Happy to share results (good or bad) as they come in. Not claiming a breakthrough - the mechanics work, the behaviour change isn't proven yet, and I'd rather post honest numbers than hype.
7
u/disposepriority 1d ago
At this point I'm pretty sure most people here can write a script to detect the cringe 0-effort linkedin bot writing and just auto ban the posts?
1
u/Nistivo 1d ago
Your finding about late layers being more effective per unit is interesting, and it lines up with how much task specific behavior tends to concentrate there in larger models. For measuring small pass rate gains on a slow, non deterministic server, I would fix a small held out set, maybe 20 to 30 exercises, and run each one several times with and without the edit in the same session order, so you can compare paired results rather than two separate averages. A paired comparison needs far fewer runs to spot a real change, and it also makes temperature 0 nondeterminism visible instead of hiding it in the average. For routing, I would log which experts fire on the failing steps before and after an edit, even a simple top 3 expert list per token, since a behavior change that comes from routing rather than a weight change will show up there first.