We build machine learning systems with industry, and we study what is happening inside them.
Machine learning has become ordinary infrastructure. It reads scans, drafts documents, routes applications, and sits inside products that people depend on without having chosen to. What has not become ordinary is the ability to say afterwards what a system did, and why anyone should have believed it.
The group works on both halves of that. Applied means the questions come from systems that are already in use, and that the answers have to hold up there. Interpretable means we hold ourselves to explaining the resulting systems, and to testing whether the explanation survives contact with the model.
The second half is the harder one, because most explanations of a model are stated in a form that cannot fail. A highlighted region, a labelled feature, a plausible story about a circuit: each is a claim about a computation, put in a shape that no observation could contradict. Much of our methodological work is about restating such claims so that an observation could.
Counterfactual explanation, mechanistic analysis, and identifiability: when a description of a model is evidence about it, and when it is only a description. A model’s report on its own reasoning →
How architecture, data, optimisation and post-training shape the structure a model ends up with, and whether a capability that can be decoded from a representation is one the model draws on. Instruction tuning and moral framing →
Segmentation, and the benchmarking practices the field uses to judge itself, including how standard protocols behave on small organs and small datasets. Read the line →
Dataset search and retrieval for models that must answer from a real corpus, and the design decisions that coding assistants make on a team’s behalf without being asked. Read the line →
We take on students who want to know why something worked, and not only that it did.
Supervision, and how to write to us →