Learning Transformer Programs

Recent research in mechanistic interpretability has attempted to reverse-engineer Transformer models by carefully inspecting network weights and activations. However, these approaches require considerable manual effort and still fall short of providing complete, faithful descriptions of the underlying algorithms. In this work, we introduce a procedure for training Transformers that are mechanistically interpretable by design. We build on RASP [Weiss et al., 2021], a programming language that can be compiled into Transformer weights. Instead of compiling human-written programs into Transformers, we design a modified Transformer that can be trained using gradient-based optimization and then automatically converted into a discrete, human-readable program. We refer to these models as Transformer Programs. To validate our approach, we learn Transformer Programs for a variety of problems, including an in-context learning task, a suite of algorithmic problems (e.g. sorting, recognizing Dyck languages), and NLP tasks including named entity recognition and text classification. The Transformer Programs can automatically find reasonable solutions, performing on par with standard Transformers of comparable size; and, more importantly, they are easy to interpret. To demonstrate these advantages, we convert Transformers into Python programs and use off-the-shelf code analysis tools to debug model errors and identify the "circuits" used to solve different sub-problems. We hope that Transformer Programs open a new path toward the goal of intrinsically interpretable machine learning.

Paper

References (62)

Scroll for more · 38 remaining

Similar papers

Peer review

Reviewer TaJd6/10 · confidence 2/52023-07-05

Summary

_Background_: RASP is a tensor processing language which provides a language to hand-write transformers. Tracr presents a framework to compile RASP programs to a transformer architecture automatically. The authors of this project are interested in distilling a transformer architecture to an equivalent program in RASP. This is challenging because RASP is not a sound language: the behavior of many trained transformers is equivalent to that of a single RASP program. The authors go around this problem by constraining the transformer architecture in strategic places so that there is a deterministic mapping from a transformer to an equivalent program in RASP. The authors present a model distillation procedure to construct such reduced transformers (called Transformer Programs) automatically. The authors test the Transformer Programs on three tasks: 1) in-context learning, 2) recovering handwritten RASP programs, and 3) simple real-world NLP tasks. They observe mixed results: transformer programs can fully solve (1), they cannot generalize to larger sequences for (2), and they are better than non-sequential baselines on (3) but worse than generic transformers. The authors also show the utility and interpretability of the distilled programs by analyzing the programs using off-the-shelf debuggers.

Strengths

Originality * RASP programs are inherently unsound: one RASP program is equivalent to many trained transformers. Solving this problem by constraining the transformer to elicit a bijective mapping is a simple yet elegant idea. Significance * This paper shows a simple method to distill transformers into interpretable programs. This work opens the door for work in program synthesis, static analysis, and model checking to be used for sequential processing tasks. * Many downstream tasks rely on transformers to processing temporal sequences of data into labels. While the transformer architecture presented is constrained, an interpretable transformer can be very useful for tasks where high degree of interpretability and accuracy are required. Clarity and Quality * The framework is well motivated, and the writing is clear and precise.

Weaknesses

__Weaknesses__ I have three main concerns (paraphrased from the questions section below): * I’m concerned that the constraints mentioned here violate properties[1] that the mechanistic interpretability community have identified as being intrinsic to the utility of transformers. * Poor robustness: Model distillation has been observed to produce models that are more robust to outliers while being slightly less accurate[2]. However, in experiments it seems that the distilled models are neither robust to outliers nor as accurate as baselines, which makes it harder to use this as a drop-in replacement. * Lack of Reusability: An interesting property of the RASP programs (and RASP distilled transformers) is that many tasks can be efficiently solved by precomputing useful primitives. The algorithm presented here does not seem to model this property. For instance, in the reverse proposed in RASP, the authors' solution precomputes length of the sequence and then uses length to flip the indices of an identity matrix. The derived transformer also captures this behavior. Does the Transformer Program also capture this behavior? If not, why not? Clarity: * 135. subpace -> subspace * Related work: I defer to the authors, however, I feel adding a section on other model distillation approaches would be relevant. In the context of model distillation, [3] seems similar to this work in learning a transformer (for multi-agent communication) and then by discretizing it (using MCMC) to obtain an interpretable policy. Overall, I've given the paper a __borderline rejection__. The problem statement presented has promise to have significant impact, however, the experimental results do not instill confidence in the downstream utility of this method and I believe this paper will benefit from another round of review. I'm more than willing to change my recommendation after the rebuttal period. ==== __EDIT__: I misinterpreted the paper as a _model distillation_ paper instead of a continuous relaxation one. In light of this, and other clarifications presented by the authors, I'm raising my score to a __weak accept__. 1. https://transformer-circuits.pub/2022/toy_model/index.html 2. https://arxiv.org/abs/2006.11287 3. https://arxiv.org/abs/2101.03238

Questions

* Constraint 1 “the token embeddings encode … fixed set of variables… in orthogonal subspace. What is a variable here? I’m going to assume variable=token, but it would be good to define this. * Does this mean that encoding 100 variables requires a 100 dimensional vector? Does this assumption violate some of the properties we know about transformers? For instance: nonlinear superposition[1]? * 155: “require that each query token attend to a single key token”. This constraint seems very limiting. Do most sequential problems where transformers are used adhere to this constraint? * 256 “results degrade on longer sequence tasks.” This seems concerning. Are these results for the trained model or for the extracted program? Ideally, model distillations are more robust to OOD tasks than the model itself[2]. Is there any indication for why this might be the case? . 259 “our solution might be different from human written solutions.” This seems concerning because RASP programs attempt to upper-bound the number of transformer layers that might be needed for computation. Do we have any indication for why this might be happening? Is this maybe because the human written solutions reuse previously computed values? 1. https://transformer-circuits.pub/2022/toy_model/index.html 2. https://arxiv.org/abs/2006.11287

Rating

6: Weak Accept: Technically solid, moderate-to-high impact paper, with no major concerns with respect to evaluation, resources, reproducibility, ethical considerations.

Confidence

2: You are willing to defend your assessment, but it is quite likely that you did not understand the central parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

2 fair

Presentation

4 excellent

Contribution

3 good

Limitations

The authors have addressed the limitations of the method adequately to the best of my knowledge.

Reviewer HW9X7/10 · confidence 3/52023-07-06

Summary

There has been prior work on compiling programs written in a domain-specific language (RASP) into a transformer that emulates the function. In this paper, the authors target the opposite direction of training transformers and generating RASP programs that are faithful to the model's computation. The authors do this by proposing an architecture that serves as a discretized version of a transformer, allowing translation to a discrete, interpretable python program after training. They find that for a variety of tasks, it is possible to 1) learn a solution in this architecture and 2) compile it into RASP.

Strengths

This work demonstrates a novel architecture that allows for direct translation to code. The paper does a great job of demonstrating their method for synthetic tasks. Though prior work has noticed sparsity improved interpretability, this work leverages it for full programmatic translation. I hope this can inspire future work in interpretable neural networks.

Weaknesses

1. Learning solutions to the RASP tasks makes it easier for the model to learn interpretable solutions. The paper would be stronger if it targeted other tasks where the compilation is more surprising. 2. How well can a discrete transformer solve problems relative to the original transformer? I imagine the discretized model has a lower representation capacity or worse optimization. I think it's important to experimentally/theoretically analyze what is lost as a result of this architectural choice, considering it's not a standard transformer in many key aspects.

Questions

No questions beyond the one in the weaknesses/limitations.

Rating

7: Accept: Technically solid paper, with high impact on at least one sub-area, or moderate-to-high impact on more than one areas, with good-to-excellent evaluation, resources, reproducibility, and no unaddressed ethical considerations.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

4 excellent

Presentation

3 good

Contribution

3 good

Limitations

Are there tasks where you tested this method and either the code was uninterpretable or the discretized transformer couldn't achieve high accuracy, unlike the standard transformer? If not, are there any tasks where you wouldn't expect this to work? Other than this, the authors have adequately addressed limitations.

Reviewer vQnY7/10 · confidence 5/52023-07-06

Summary

This paper presents an approach to constraint the parameter space of Transformers so that when trained, the resulting weights can be directly translated to a human-readable program, e.g. in Python. To do so, attention is modified so that the internal model representation is, in practice, composed of a set of distinct variables that the attention processes read/write to. The base approach focuses in attention-only models (no MLP layers), but the authors propose extensions to support MLP layers. - page 5: line 165-166: "For row in the predicate matrix" -> there seems to be some word missing around "row".

Strengths

I found the idea of constraining the parameter space extremely interesting. While the types of programs that can currently be learned seem a bit restricted (e.g., as the number of variables grows, the model/program could potentially grow very large), I think this is a very promising direction, and a greag foundation to build on.

Weaknesses

While it seems clear that programs for simple tasks can be interpreted, it is not clear that many tasks (specially vision/natural language tasks) actually even afford interpretable algorithms. So, perhaps future work needs to focus on more complex primitives for the programming language supported by the models that would simplify the programs, or enable higher-level constructs that are interpretable.

Questions

- Section 3.2: the explanation for how to extract the part of the program that corresponds to the attention layers is clear. But how about the MLP layers? How do you infer what the MLP layers have learned to do to conver that into a program? [edit: this is explained immediately below, but it's still unclear; so, for EACH MLP in EACH LAYER of the model, you would have to extract a look-up table that will be added to the Python program?] - (more a comment than a question): concerning MLPs. I wonder if it would be possible to define a library of commmon operations (e.g. addition/multiplication/etc., or whatever makes sense with other categorical values), and allow non-learnable, pre-defined MLP weights to be used via some gating (e.g., the model choosing to use one of these built-in methods, or a custom-learned weight matrix). to increase the chance of having an interpretable function in the resulting model, rather than having one look-up table per MLP layer.

Rating

7: Accept: Technically solid paper, with high impact on at least one sub-area, or moderate-to-high impact on more than one areas, with good-to-excellent evaluation, resources, reproducibility, and no unaddressed ethical considerations.

Confidence

5: You are absolutely certain about your assessment. You are very familiar with the related work and checked the math/other details carefully.

Soundness

4 excellent

Presentation

4 excellent

Contribution

3 good

Limitations

See weaknesses above.

Reviewer Kcxc7/10 · confidence 3/52023-07-09

Summary

This paper proposes a new technique for training Transformer models while ensuring that the learned weights obey certain constraints, designed to facilitate mechanistic interpretability. In particular, the technique works by (1) freezing certain weight matrices throughout training (e.g., to always write the output of an attention layer to a previously unused linear subspace of the residual stream) and (2) introducing Gumbel-softmax sampling at various steps of the computation, and annealing the temperature down during training to ensure that at convergence, those computations perform discrete operations. The resulting Transformers can be automatically converted into symbolic programs that read, write, and perform lookup-table-style computation with a fixed number of categorical and integer variables. The authors train (quite small) Transformers in this way, to solve several tasks, including named entity recognition and sentiment classification on short sequences. The authors also provide some analysis of the programs extracted from these Transformers.

Strengths

This is a neat paper that advances two exciting lines of research: - RASP and Tracr been helpful as intuition pumps for how trained Transformers *could* work, but it has not been clear whether the (correct) RASP algorithms researchers manually developed could be discovered automatically by gradient descent, and if not, what different properties these learned Transformer algorithms would have. This paper proposes a method for learning Transformer programs that could be used to start to answer these questions. - A key challenge in mechanistic interpretability research (e.g. on Transformer circuits) is that Transformers trained by (unconstrained) gradient descent appear to collapse multiple conceptually distinct concepts via superposition. This paper proposes training methods that may help to mitigate superposition by forcing the network to read, write, and manipulate individual ‘variables’ that live in orthogonal subspaces of the residual stream. Although terse in some places (perhaps due to length constraints), the methodology is for the most part clearly described, and the limitations of the approach seem sensible for a first attempt at this kind of constrained training. Another strength is that the framework seems to be extensible—the examples in the paper paint a clear enough picture of how to modularly extend the target symbolic programming language with new features (and then how to extend the neural net architecture and training procedure accordingly).

Weaknesses

- Although the motivation is interpretability, I was not convinced that the learned programs in the experiments were particularly interpretable. It would have been nice to see more detailed analysis of the programs. Outside the toy in-context learning example, are there any interpretable algorithms that are learned? Can examples on which the learned programs fail be traced back to particular ‘bugs’ in the symbolic programs? Can the symbolic programs be used to engineer adversarial examples on which the Transformer will fail? Do ordinary transformers trained without constraints also fail on these adversarial examples (indicating that they might be using similar flawed algorithms)? How stable are the learned programs across different training runs? - It is unclear how scalable the presented technique is, to more complex problems, longer sequences, or bigger networks. I also would have appreciated more discussion / investigation of how easy or tricky the optimization was, and why it appears to work more poorly for larger Transformers (e.g., that handle larger sequence lengths). What are the key challenges in scaling up? Do the Gumbel gradient estimates become too noisy, e.g.? Or are there other main challenges?

Questions

- At the end of training, your Gumbel-Softmax's have been annealed to Categorical distributions, but these distributions are not necessarily *peaked* or low-entropy categoricals. Therefore, your extracted program (which takes the argmax of the categorical) may behave quite differently from your trained network (which randomly samples the categorical). Have you investigated (a) the extent to which the learned categoricals are peaked at a single mode, and (b) the difference in task performance / accuracy between the final learned Transformer and the extracted program? - Why limit the predicate matrices to contain only one ‘1’ per row? Is it just because this constraint is more amenable to the Gumbel-softmax training procedure? - In the description (Appendix A.1) of the categorical attention mechanism, you appear to use an argmax operation that is not differentiable. During training do you actually use Gumbel-softmax? If so, how are the resulting samples used to compute the output of the attention layer? (More generally, it would help if the paper more clearly laid out exactly where in the architecture all the Gumbel-softmax samples are used. Perhaps algorithm boxes in the style of https://arxiv.org/pdf/2207.09238.pdf could be provided for each component of the neural architectures you build?) - For the in-context learning experiment, did you try (1) training an ordinary Transformer of the same size on the task? and/or (2) training a larger (i.e., overparameterized) Transformer program on the task? I’d be curious about the results of either experiment, if you did run them. Under the ‘lottery ticket hypothesis,’ overparameterization is an important part of how algorithms are learned by gradient descent — it would be interesting to see what this looks like in a Transformer program. E.g., in a larger model, do we end up with a small interpretable subprogram that correctly completes the task? - Can you clarify how the word embeddings are trained? What does it mean that the 100-d GloVe embeddings are “randomly projected” to e.g. 32*4=128-d embeddings? Do you use a randomly generated dense 100x128 matrix? Then how are the embeddings trained? Is there a Gumbel sample for each of the categorical variables? - Why not include MLP layers in the NLP tasks? - For the RASP tasks that were not successfully solved by learned Transformer programs, do you believe this is because (1) good solutions exist, but are not found by gradient descent, or (2) your subset of RASP is too limited and the tasks cannot be solved with this subset? If (2), what are the prospects for handling a broader subset of RASP?

Rating

7: Accept: Technically solid paper, with high impact on at least one sub-area, or moderate-to-high impact on more than one areas, with good-to-excellent evaluation, resources, reproducibility, and no unaddressed ethical considerations.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

3 good

Presentation

3 good

Contribution

3 good

Limitations

Limitations are adequately discussed, but I do think it could be useful to say a bit more about the challenge of scaling this approach -- what are the key obstacles & prospects for addressing them?

Reviewer HW9X2023-08-11

Thank you for your responses, especially for pointing to the original/discrete transformer accuracy comparisons I missed! In light of this, I have increased my score from a 6 to a 7.

Reviewer TaJd2023-08-13

Thank you for the clarifications and apologies for the model distillation misunderstanding. After re-reading the paper, I'm raising my score to a weak accept.

Reviewer Kcxc2023-08-21

Thank you for your response! A couple follow-ups: > This is because it is possible to manually construct Transformer Programs that solve RASP tasks perfectly, so the performance limitations must be attributed to optimization challenges. One caveat is the “less than” predicate... The reason I asked is because it does seem your target language is less general than RASP. One example is predicates like "less than" (which feels quite significant). But it was unclear to me if this is really the only limitation in comparison to general RASP -- clarifying this in the final draft would be appreciated. > During training, we define... Is this differentiable? How do you propagate derivatives through the one-hot, or do you not need to? > We did not investigate these questions in detail but we will run this analysis and add it to our final draft. > we agree it would be interesting to measure the extent to which (a) whether standard Transformers and Transformer Programs learn similar solutions, and (b) the similarity between Transformer Programs with different random seeds, and we will add this analysis to our next draft. Thanks, I look forward to reading these analyses. Thanks also for your general response discussing scaling challenges. Overall, after the author response, I am slightly more lukewarm on the current results, but believe this work represents a good first step toward learning Transformers that can be represented as symbolic programs. I still support publication of the manuscript & am excited to see how the research community builds on these ideas / results in the future!

Program Chairsdecision2023-09-21

Decision

Accept (oral)

© 2026 NYSGPT2525 LLC