Looks relevant to me on a skim! I’d probably want to see some arguments in the submission for why this is useful tooling for mech interp people specifically (though being useful to non mech interp people too is a bonus!)
Neel Nanda
Karma: 6,920
Mechanistic Interpretability Workshop Happening at ICML 2024!
That’s awesome, and insanely fast! Thanks so much, I really appreciate it
Nope to both of those, though I think both could be interesting directions!
Nah I think it’s pretty sketchy. I personally prefer mean ablation, especially for residual stream SAEs where zero ablation is super damaging. But even there I agree. Compute efficiency hit would be nice, though it’s a pain to get the scaling laws precise enough
For our paper this is irrelevant though IMO because we’re comparing gated and normal SAEs, and I think this is just scaling by a constant? It’s at least monotonic in CE loss degradation
Transcoders enable fine-grained interpretable circuit analysis for language models
I don’t think we really engaged with that question in this post, so the following is fairly speculative. But I think there’s some situations where this would be a superior technique, mostly low resource settings where doing a backwards pass is prohibitive for memory reasons, or with a very tight compute budget. But yeah, this isn’t a load bearing claim for me, I still count it as a partial victory to find a novel technique that’s a bit worse than fine tuning, and think this is significantly better than prior interp work. Seems reasonable to disagree though, and say you need to be better or bust
+1 to Rohin. I also think “we found a cheaper way to remove safety guardrails from a model’s weights than fine tuning” is a real result (albeit the opposite of useful), though I would want to do more actual benchmarking before we claim that it’s cheaper too confidently. I don’t think it’s a qualitative improvement over what fine tuning can do, thus hedging and saying tentative
Thanks! Broadly agreed
For example, I think our understanding of Grokking in late 2022 turned out to be importantly incomplete.
I’d be curious to hear more about what you meant by this
It was added recently and just added to a new release, so
pip install transformer_lensshould work now/soon (you want v1.16.0 I think), otherwise you can install from the Github repo
There’s been a fair amount of work on activation steering and similar techniques,, with bearing in eg sycophancy and truthfulness, where you find the vector and inject it eg Rimsky et al and Zou et al. It seems to work decently well. We found it hard to bypass refusal by steering and instead got it to work by ablation, which I haven’t seen much elsewhere, but I could easily be missing references
First and foremost, this is interpretability work, not directly safety work. Our goal was to see if insights about model internals could be applied to do anything useful on a real world task, as validation that our techniques and models of interpretability were correct. I would tentatively say that we succeeded here, though less than I would have liked. We are not making a strong statement that addressing refusals is a high importance safety problem.
I do want to push back on the broader point though, I think getting refusals right does matter. I think a lot of the corporate censorship stuff is dumb, and I could not care less about whether GPT4 says naughty words. And IMO it’s not very relevant to deceptive alignment threat models, which I care a lot about. But I think it’s quite important for minimising misuse of models, which is also important: we will eventually get models capable of eg helping terrorists make better bioweapons (though I don’t think we currently have such), and people will want to deploy those behind an API. I would like them to be as jailbreak proof as possible!
Refusal in LLMs is mediated by a single direction
Re dictionary width, 2**17 (~131K) for most Gated SAEs, 3*(2**16) for baseline SAEs, except for the (Pythia-2.8B, Residual Stream) sites we used 2**15 for Gated and 3*(2**14) for baseline since early runs of these had lots of feature death. (This’ll be added to the paper soon, sorry!). I’ll leave the other Qs for my co-authors
I haven’t fully worked through the maths, but I think both IG and attribution patching break down here? The fundamental problem is that the discontinuity is invisible to IG because it only takes derivatives. Eg the ReLU and Jump ReLU below look identical from the perspective of IG, but not from the perspective of activation patching, I think.
From the title I expected this to be embarrassing for Eliezer, but that was actually extremely sweet, and good advice!
Great work! Obviously the results here speak for themselves, but I especially wanted to complement the authors on the writing. I thought this paper was a pleasure to read, and easily a top 5% exemplar of clear technical writing. Thanks for putting in the effort on that.
<3 Thanks so much, that’s extremely kind. Credit entirely goes to Sen and Arthur, which is even more impressive given that they somehow took this from a blog post to a paper in a two week sprint! (including re-running all the experiments!!)
Makes sense! Sounds like a fairly good fit
Another way of framing it: Try to write your paper in such a way that a mech interp researcher reading it says “huh, I want to go and use this library for my research”. Eg give examples of things that were previously hard that are now easy.