Code RoomDictionary interpretability validation
FrontierPrep Room Coding #4961

Dictionary interpretability validation

System designDistributed systemsSenior–Staff~80 min

You are handed a sparse decomposition of one layer's activations: a dictionary of directions, learned unsupervised, with the usual reconstruction and sparsity numbers attached. Your job is to decide the thing those numbers do not answer. Did this dictionary recover units the model computes with, or is it a good sparse basis for the activation distribution, which any well fit dictionary is by construction?

The decision has consequences. Teams will build monitors, steering interventions and safety cases on these directions, and a basis that reconstructs well while carving the space at joints the model does not use will support confident claims it cannot actually support.

Off the table: retraining the model, a ground truth feature list, and using a language model's natural language description of a direction as the criterion, since describability is a property of the inputs that activate a direction and not evidence about the model's own decomposition. You may train further dictionaries, you may intervene on activations, and you may run the model as much as you like.

Design the test. It needs a null: what does a dictionary that is only a sparse basis look like on your test, and how do you generate one, whether from a model with randomized weights or from shuffled activations that preserve the marginal statistics. It needs to survive feature splitting, since enlarging the dictionary divides one apparent feature into several and your test must not simply reward size. And it needs to certify something about the dictionary as a whole rather than about a handful of directions somebody picked.

Hand in the test, the null and its construction, the negative controls, and the experiment that would show your test rewards dictionary capacity rather than correspondence to the model. State in one sentence the claim your test licenses, and in one more the claim it does not.

What a strong answer looks like

Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.

Clarify9:00 left
Estimate9:00 planned
Design26:30 planned
Deep dive21:30 planned
Failure14:00 planned
0:00
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.