Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: Internal Interfaces Are a High-Priority Interpretability Target, published by Thane Ruthenis on December 29, 2022 on The AI Alignment Forum.
tl;dr: ML models, like all software, and like the NAH would predict, must consist of several specialized "modules". Such modules would form interfaces between each other, and exchange consistently-formatted messages through these interfaces. Understanding the internal data formats of a given ML model should let us comprehend an outsized amount of its cognition, and allow to flexibly interfere in it as well.
1. A Cryptic Analogy
Let's consider three scenarios. In each of them, you're given the source code of a set of unknown programs, and you're tasked with figuring out their exact functionality. Details vary:
In the first scenario, the programs are written in some known programming language, e. g. Python.
In the second scenario, the programs were randomly generated by perturbing machine code until it happened to end up in a configuration that, when ran, instantiates a process externally indistinguishable from a useful intelligently-written program.
In the third scenario, the programs are written in a programming language that's completely unfamiliar to you (or to anyone else).
In the first scenario, the task is all but trivial. You read the source code, make notes on it, run parts of it, and comprehend it. It may not be quick, but it's straightforward.
The second scenario is a nightmare. There must be some structure to every program's implementation — something like the natural abstraction hypothesis must still apply, there must be modules in this mess of a code that can be understood separately, etc. There is some high-level structure that you can parcel out into tiny pieces that can fit into a human mind. The task is not impossible.
But suppose you've painstakingly reverse-engineered one of the programs this way. You move on to the next one, and... Yup, you're essentially starting from zero. Well, you've probably figured out something about natural abstractions when working on your first reverse-engineering, so it's somewhat easier, but still a nightmare. Every program is structured in a completely different way, you have to start from the fundamentals every time.
The third scenario is a much milder nightmare. You don't focus on reverse-engineering the programs here — first, you reverse-engineer the programming language. It's a task that may be as complex as reverse-engineering one of the individual programs from (2), but once you've solved it, you're essentially facing the same problem as in (1) — a problem that's comparably trivial.
The difference between (2) and (3) is:
In (3), every program has a consistent high-level structure, and once you've figured it out, it's a breeze.
In (2), every high-level structure is unique, and you absolutely require some general-purpose tools for inferring high-level structures.
(2) is a parallel to the general problem of interpretability, different programs being different ML models. Is there some interpretability problem that's isomorphic to (3), however?
I argue there is.
2. Interface Theory
Suppose that we have two separate entities with different specializations: they both can do some useful "work", but there are some types of work that only one of them can perform. Suppose that they want to collaborate: combine their specializations to do tasks neither entity can carry out alone. How can they do so?
For concreteness, imagine that the two entities are a Customer, which can provide any resource from the set of resources R, and an Artist, which can make any sculpture from some set S given some resource budget. They want to "trade": there's some sculpture sx the Customer wants made, and there are some resources rx the Artist needs to make it. How can they carry out such exchanges?
The Custo...