Intervention Hook Pattern Support#
Working contract: this document records the hook-pattern subset that Interpretune currently treats as portable across intervention surfaces. It is not a claim that every TransformerLens v3 hook name already has matching cross-backend coverage in Interpretune.
Test coverage note: we added focused regression coverage for the alias paths that recently broke (
hook_in/hook_out,attn.o.hook_in, and constrained missing-feature retention), but we still need a broader pattern-by-pattern test sweep in a later pass.
Resolution layers#
Interpretune currently resolves intervention hook names through two layers:
expand_intervention_patterns(...)expands preferred canonical TransformerBridge-style hook names and supported legacy HookedTransformer aliases into the concrete hook names exposed by the active backend.Backend-specific resolution then takes over:
TransformerLens / TransformerBridge uses the model hook registry plus its alias registry.
NNsight uses
src/interpretune/analysis/backends/hook_mapping.py, which intentionally supports a smaller, explicitly curated portable subset.
For new configs, prefer the canonical names in the table below. Keep legacy aliases only when preserving older notebooks or configs.
Preferred portable patterns#
Preferred canonical pattern |
Legacy aliases accepted |
Current portable notes |
|---|---|---|
|
|
Supported by TransformerLens and the NNsight resolver subset. Prefer this spelling in new configs. |
|
|
Supported by TransformerLens and the NNsight resolver subset. |
|
|
Use this as the preferred module-output spelling. |
|
|
Preferred cross-backend spelling for the attention output-projection input. |
|
|
Portable today for GPT-2 and Llama-family NNsight mappings. Gemma-family NNsight flows still rely on the legacy |
|
|
Portable in the Gemma-family NNsight mappings; accepted by alias expansion elsewhere when the backend exposes the corresponding hook. |
|
none |
Supported directly on TransformerBridge and NNsight models. Legacy |
Backend-specific alias families#
expand_intervention_patterns(...) also tries supported canonical/legacy alias families for the following names when
the active backend exposes them:
embed.hook_out↔hook_embedpos_embed.hook_out↔hook_pos_embedattn.hook_in↔hook_attn_inattn.q.hook_in/attn.k.hook_in/attn.v.hook_in↔hook_q_input/hook_k_input/hook_v_inputattn.q.hook_out/attn.k.hook_out/attn.v.hook_out↔hook_q/hook_k/hook_vattn.hook_pattern↔attn.hook_attention_weightsattn.hook_hidden_states↔attn.hook_resultmlp.hook_in↔hook_mlp_inln1.hook_out↔ln1.hook_normalized/ln1.hook_scale
Treat these as backend-specific until they are covered by the same explicit NNsight resolver subset and dedicated tests.
Wildcards#
Wildcard patterns are expanded after alias normalization, so both canonical and legacy forms can be used with *.
Examples:
blocks.*.hook_inblocks.*.hook_outblocks.*.attn.hook_outblocks.*.attn.o.hook_in
Practical guidance#
Prefer canonical TransformerBridge-style names in notebook configs and explicit intervention mappings.
Keep old HookedTransformer aliases only when updating older notebooks incrementally.
When you need a hook outside the portable table above, treat it as backend-specific and validate it against the active backend before relying on cross-backend parity.