aiqbench analysis
This paper introduces the "Attribution Contract" framework to clarify how feature attribution scores function in generative language models, where each token acts as both an output and an input. The authors demonstrate that standard interpretation methods often commit a "self-attribution fallacy" by misreading generated tokens as purely prompt-driven explanations. Consequently, researchers must explicitly define the generation process and fixed variables when evaluating model interpretability to avoid misleading conclusions about what drives model outputs.
The Attribution Contract for Generative Language Models
arXiv:2605.23080v3 Announce Type: replace Abstract: Feature attribution scores each part of an input by how much it explains a model's output. We argue that in generative language models these scores carry no fixed meaning. A classifier has a single output to explain, but a generative model produces its output token by token, and each generated token is both an output and an input, so explaining the output becomes several distinct questions. We support this claim by proposing the Attribution Contract, a framework that names the question a set of attribution scores answers. A contract specifies the model score being explained, what is held fixed, the target output, the generation process, and which features can receive attribution, choices that matter in practice. For example, eligible features decide what a score explains: under a local next-token contract, the model's own generated tokens receive $29\%$ of the attribution mass, comparable to the $25\%$ on the input question, and reading this as a prompt-level explanation is a mistake we name the self-attribution fallacy. The generative process also shapes feature attribution: on a mixture-of-experts model, Integrated Gradients completeness is unreliable, since recomputing expert routing along the attribution path leaves a large residual that holding the routing fixed substantially lowers, while a masked-diffusion model, which fixes its choices at generation, has a residual that instead decreases with more steps. These results show that Attribution Contracts should be carefully specified when proposing and evaluating attribution methods for generative language models, since the meaning and evaluation of an attribution depend on its explanatory setting.
Abstract:Feature attribution scores each part of an input by how much it explains a model's output. We argue that in generative language models these scores carry no fixed meaning. A classifier has a single output to explain, but a generative model produces its output token by token, and each generated token is both an output and an input, so explaining the output becomes several distinct questions. We support this claim by proposing the Attribution Contract, a framework that names the question a set of attribution scores answers. A contract specifies the model score being explained, what is held fixed, the target output, the generation process, and which features can receive attribution, choices that matter in practice. For example, eligible features decide what a score explains: under a local next-token contract, the model's own generated tokens receive $29\%$ of the attribution mass, comparable to the $25\%$ on the input question, and reading this as a prompt-level explanation is a mistake we name the self-attribution fallacy. The generative process also shapes feature attribution: on a mixture-of-experts model, Integrated Gradients completeness is unreliable, since recomputing expert routing along the attribution path leaves a large residual that holding the routing fixed substantially lowers, while a masked-diffusion model, which fixes its choices at generation, has a residual that instead decreases with more steps. These results show that Attribution Contracts should be carefully specified when proposing and evaluating attribution methods for generative language models, since the meaning and evaluation of an attribution depend on its explanatory setting.
Machine Learning (cs.LG)
arXiv:2605.23080 [cs.LG]
(or arXiv:2605.23080v3 [cs.LG] for this version)
https://doi.org/10.48550/arXiv.2605.23080 Focus to learn more arXiv-issued DOI via DataCite
arXivLabs is a framework that allows collaborators to develop and share new arXiv features directly on our website.
Both individuals and organizations that work with arXivLabs have embraced and accepted our values of openness, community, excellence, and user data privacy. arXiv is committed to these values and only works with partners that adhere to them.
Have an idea for a project that will add value for arXiv's community? Learn more about arXivLabs.
Full text under the publisher's open licence · 343 words
Related coverage

Improve contract search accuracy with auto-generated filters in Amazon Bedrock
AWS · Aug 18, 2026
Article: When Spec-Driven Development Pays off
InfoQ · Sep 10, 2026

2026.10: You are here 📍
Home Assistant · Oct 7, 2026

Presentation: Multi-Agent Patterns from Spotify’s AI Powered Advertising Platform
InfoQ · Oct 8, 2026