Pith. sign in

REVIEW 3 major objections 4 minor 35 references

On Automated and Explainable Provenance of AI-Generated Code

T0 review · 3 major / 4 minor · reviewed 2026-08-04 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read AI-generated code must be built on explainable provenance—automated post-hoc traceability to prompt components, training instances, training-data factors, and internal model components—or it will remain opaque to the developers, organizatio

desk verdict A clear, honest research-vision paper with a useful four-dimension taxonomy; its central premise—that post-hoc instance-to-output provenance can be made reliable—is unproven, but the paper openly says so and does not overclaim results. read the letter →

arxiv 2608.02329 v1 pith:D2RMZHN6 submitted 2026-08-03 cs.SE

Alejandro Velasco , Nathan Wintersgill , Trevor Stalnaker , Oscar Chaparro , Denys Poshyvanyk This is my paper · ORCID
classification cs.SE
keywords explainableprovenanceAI-generatedcodetraceabilitygenerationinterpretabilitymembershipinferencesoftwarecompliancecausalattribution
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper is a research vision rather than a finished result. It argues that the next generation of AI code-generation tools must be built on a foundation of explainable provenance: automated, post-hoc traceability that links a generated snippet to the prompt parts, training examples, global data characteristics, and internal model components that caused it. Survey and interview evidence from developers, compliance professionals, and model developers shows that current tools leave a traceability gap that output filtering and source-citation features do not close. If the vision is correct, every AI coding assistant would need provenance tooling as a core feature, and the paper's four-dimension classification plus its proposed post-hoc techniques would be the template for building it. The authors frame the technical core as a program to be realized, not an accomplished technique.

What carries the argument

The central object is the four-dimensional provenance space: prompt-to-output, instance-to-output, factor-to-output, and model component-to-output traceability. The technical carriers are a suite of post-hoc techniques designed around this space: LEA (local explanation attribution using feature attribution such as SHAP to rank prompt tokens), propensity scoring on token log-probabilities, a retrieval pipeline combining clone detection, neural similarity, and membership inference attacks, GEA (global explanation attribution using causal graphs and average treatment effects for training-data factors), and module-level interpretability via functional modularization, sparse autoencoders, and act

What would settle it

Run a controlled study where a large closed model is prompted with a verbatim snippet from a known open-source file, then apply the proposed membership-inference and retrieval pipeline: if instance-level attribution performs at chance while similarity search retrieves unrelated code, the post-hoc program's central premise fails. On the causal side, train an open-weights model on synthetic data with known compositional characteristics and check whether GEA's estimated treatment effects recover the planted relationships; failure to recover them would falsify the factor-level claim.

Watch

Extended reading notes

Core claim

The paper's central claim is that transparency for AI-generated code cannot be achieved by flagging problematic outputs after the fact. Instead, next-generation CodeGenAI tools must provide automated, post-hoc traceability along four causal dimensions: prompt-to-output (which prompt tokens caused a problematic generation), instance-to-output (which training or external code instances are associated with an output), factor-to-output (how global training-data characteristics shape output), and model component-to-output (which internal circuits or attention heads are responsible). The paper grounds this claim in empirical studies showing that developers, compliance professionals, and model deve

Load-bearing premise

The vision presupposes that a model's outputs and logits carry enough recoverable signal to attribute a generation to specific training instances and internal circuits after the fact—especially for large, closed models whose training data is hidden—an empirical premise the paper itself flags as unvalidated.

Editorial extensions

If this is right

  • If provenance becomes a foundation, CodeGenAI tools will expose which prompt tokens caused a bad output, letting developers refine prompts instead of blindly discarding generated code.
  • Instance-to-output traceability would give compliance teams an automated way to assess license and copyright risk, replacing manual GitHub and Stack Overflow searches.
  • GEA-style causal analysis would let model builders see how training-data composition—such as the share of restrictively licensed code—shifts output quality, guiding data curation priorities.
  • Model component-to-output traceability is offered only for open-weight models, creating a transparency asymmetry unless black-box proxies improve for proprietary models.
  • Because ground truth is scarce, the paper calls for constructing controlled evaluation benchmarks that simulate realistic provenance scenarios with known causal relationships.
  • The four-dimension taxonomy could become a checklist for future provenance requirements, including SBOM-style lineage for AI-generated artifacts.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper stops short of saying this, but its four-dimension taxonomy could be reused as a general evaluation schema for any transparency technique in AI code generation, independent of the specific tools proposed.
  • A testable implication of the vision is that provenance fidelity will correlate with model openness: if membership inference and causal proxies hit a ceiling for closed models, organizations may be pushed toward open-weight deployment or contractual data disclosure to meet compliance obligations.
  • The paper's own legal caveat implies that even perfect technical provenance may not translate into copyright evidence without new legal frameworks; future work may need to define evidentiary standards for similarity scores and membership probabilities.
  • The emphasis on post-hoc techniques suggests a viable near-term research path: rather than trying to inspect training pipelines, the community can build provenance tools on outputs and logits alone, but the ceiling of that path is the key empirical question the program must answer.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. This is a position/vision paper arguing that next-generation AI code-generation tools must provide automated, post-hoc explainable provenance linking generated code to prompt components, training-data instances, global data features, and internal model components. The authors ground the vision in their prior survey and interview studies of developers, model users, and compliance/legal professionals; propose a research program combining stakeholder taxonomies with technical building blocks (propensity scoring, LEA, retrieval plus membership inference, GEA causal analysis, activation patching); and close with a candid list of open challenges including training-data inaccessibility, confounding, and missing ground truth. No new empirical data, systems, or formal results are presented; the contribution is a synthesized research agenda.

Significance. If the proposed program succeeds, it would give developers, organizations, and regulators a principled way to answer 'why did this generated code come out this way?' — a question that current filtering, citation, and similarity tools do not answer. The paper's strengths are its clear four-dimension taxonomy, its grounding in previously published stakeholder studies, and its unusually honest discussion of the feasibility gaps in Sec. IV. It also names concrete technical building blocks rather than stopping at motivation. However, the central claim is a normative and empirical 'must,' while the evidence supplied is not yet sufficient to show that the required instance- and model-component-level traceability is achievable at usable fidelity. The paper is best read as a well-structured research proposal, not as a demonstrated solution.

major comments (3)
  1. [Sec. III-B / Sec. IV] The load-bearing premise is that post-hoc instance-to-output traceability is technically achievable. The paper's own Sec. IV concedes that membership inference provides only 'statistical evidence rather than definitive attribution,' that proprietary training data are inaccessible, and that 'ground truth is difficult to obtain.' These admissions directly undercut the abstract's 'must' claim: if instance-level attribution cannot be validated above chance or near-duplicate retrieval, the central vision remains an untested hypothesis. Please add either a concrete feasibility argument, a pilot demonstration, or an explicit reframing of the four-dimension provenance claim as an open research question with defined success criteria.
  2. [Sec. III-B (GEA) / Sec. IV] The GEA framework assumes that do-calculus and standard adjustment can estimate average treatment effects of training-data factors on model outputs from observational data. The paper acknowledges that 'causal graphs constructed from domain knowledge may miss important confounders,' but it does not specify how GEA will address this in the proposed research program. A plan for sensitivity analysis, causal discovery from data, or controlled simulation is needed to make GEA more than a plausible metaphor. Without such a plan, the 'causal' attribution promised by GEA is not yet defensible.
  3. [Sec. I / Sec. II] The normative claim that 'the next generation of CodeGenAI tools must be built on a foundation of explainable provenance' is supported by stakeholder surveys and by SBOM-related regulations. However, EO 14028 and the EU CRA mandate SBOMs for software components, not specifically the four-dimension post-hoc provenance defined in this paper. The jump from 'stakeholders need provenance information' to 'tools must be built on explainable provenance' should be argued more carefully: either identify a regulatory or market mechanism that demands all four dimensions, or soften the conclusion to a research hypothesis. As written, the abstract overstates the strength of the external grounding.
minor comments (4)
  1. [Figs. 1-3] The figures are referenced in the text but not included in the manuscript body; please ensure they are embedded and legible, especially the LEA workflow and the GEA causal graph, since the text relies on them.
  2. [Sec. II / Sec. III-A] The paper's empirical grounding is taken entirely from the authors' prior studies. This is acceptable for a vision paper, but the text should state this explicitly in Sec. II and avoid the impression of a new meta-analysis.
  3. [Sec. IV] The phrase 'the copyright law does not operate' is awkward; consider 'copyright law does not operate' or 'copyright doctrine does not operate.'
  4. [Sec. I] The terms 'CodeGenAI supply chain' and 'AI supply chain' are used interchangeably; define one term and use it consistently.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation; the central vision is supported by reported stakeholder studies and external regulation rather than by a fitted or self-defined quantity.

full rationale

This paper is a research vision, not a derivation. The four traceability dimensions are an organizing taxonomy, and the proposed techniques (LEA, GEA, retrieval, probing) are explicitly forward-looking proposals rather than predictions derived from fitted inputs. The 'need' claim is grounded in the authors' reported surveys and in external legal/regulatory materials (EO 14028, EU CRA, Doe v. GitHub), and the technical limitations are openly acknowledged in Sec. IV: membership inference provides only 'statistical evidence rather than definitive attribution,' proprietary training data are inaccessible, and 'ground truth is difficult to obtain.' These are feasibility caveats, not circularity. The paper does rely on a cluster of the authors' own prior publications ([17]-[19], [24]-[27], [29], [32]) for motivating evidence and technical building blocks, but those are published empirical studies used as supporting evidence, not a load-bearing self-citation chain that defines the conclusion into existence. No equation, fitted parameter, or uniqueness theorem is invoked in a way that reduces a claimed result to its own input. The appropriate finding is therefore no significant circularity, with a low score reflecting only the concentration of self-referential support.

Assumptions & free parameters 0 free parameters · 4 assumptions · 3 invented entities

The paper is a vision proposal: it introduces zero fitted parameters, but rests on strong domain assumptions about the feasibility and completeness of post-hoc provenance. Its two named techniques (LEA, GEA) are invented-but-unvalidated constructs with no independent evidence, and the four-dimension taxonomy is an untested organizing frame.

assumptions (4)
  • domain assumption The four traceability dimensions (prompt, instance, factor, model-component) are a complete and correct decomposition of stakeholder provenance needs.
    Introduced in Sec II 'What provenance must explain' with no empirical validation that these four dimensions exhaust the space of needs; the entire research program is structured around them.
  • domain assumption Post-hoc attribution can recover causal links from generated code back to training instances, data features, and model internals without model retraining, and with enough fidelity to be actionable.
    Assumed in Sec III-B; Sec IV ('Scalability under training data inaccessibility', 'Causal attribution in the presence of confounders') admits the assumption is currently unvalidated, but the research program depends on it.
  • domain assumption Stakeholder self-reported needs from surveys reliably translate into design requirements for provenance tooling.
    Sec III-A proposes surveys as the empirical foundation; the paper assumes that what stakeholders say they need predicts what tools will actually be effective.
  • domain assumption Standard causal and interpretability machinery (do-calculus, SHAP, membership inference, activation patching) remains valid when applied to LLM code generation at scale.
    Sec III-B adopts these methods from prior literature; the paper does not establish that their assumptions (e.g., no unobserved confounding, access to logits) hold for proprietary CodeGenAI models.
invented entities (3)
  • LEA (Local Explanation Attribution)
    purpose: Post-hoc technique to rank prompt tokens by influence on a problematic generated fragment and produce natural-language explanations.
    Proposed in Sec III-B as a workflow (Fig. 2); no implementation, benchmark, or falsifiable prediction is given.
  • GEA (Global Explanation Attribution)
    purpose: Causal framework using do-calculus to estimate average treatment effects of training-data factors on model output behavior.
    Proposed in Sec III-B and Fig. 3; purely schematic with no results or falsifiable predictions.
  • Four-dimension provenance taxonomy
    purpose: Organizing frame for the entire research program (prompt, instance, factor, model component).
    Introduced in Sec II; no empirical test shows these dimensions are exhaustive or minimal.

how reviews work

0 comments
Cite this review

Pith. "Pith review of On Automated and Explainable Provenance of AI-Generated Code." pith.science (2026). https://pith.science/paper/D2RMZHN6

@misc{pith2026260802329,
  author       = {Pith},
  title        = {Pith review of: On Automated and Explainable Provenance of AI-Generated Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/D2RMZHN6}},
  note         = {Machine review of arXiv:2608.02329}
}
read the original abstract

Generative AI for code generation has transformed software development, but it has also introduced a critical transparency problem: the origins of AI-generated code are opaque to the developers who use it, the organizations that deploy it, and the compliance professionals responsible for ensuring its legal and quality standards. Existing mitigations flag problematic outputs after the fact without explaining why a model produced them or how future generation could be improved. We present a research vision, grounded in a U.S. NSF-funded research grant, that argues that the next generation of CodeGenAI tools must be built on a foundation of explainable provenance: automated, post-hoc traceability that links generated code back to the prompt components, training data instances, global data features, and internal model components that caused its generation. We grounded this vision in empirical evidence from studies of software developers, model users, and compliance/legal professionals, which show that provenance information is a practical necessity that current tools do not provide. We characterize the problem across four traceability dimensions, outline a research program combining large-scale empirical studies with post-hoc causal and interpretability techniques, and identify the key open challenges that the community must address to realize this vision.

Figures

Figures reproduced from arXiv: 2608.02329 by the authors.

Figure 1
Figure 1. Overview of the proposed research vision. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Workflow of Local Explanation Attribution (LEA). Given a prompt and a smelly generated fragment (highlighted in [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Structure of the causal graphs used by GEA. Treatments Z represent training data factors; confounders X account for contextual variables such as model architecture and data distribution; the green arrow represents the Average Treatment Effect (ATE) estimated via do-calculus. level of granularity, provenance requires linking generated outputs to specific internal components of the model, which is possible only for op… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

35 extracted references · 1 linked inside Pith

  1. [1]

    Taking Flight with Copilot: Early insights and opportunities of AI-powered pair-programming tools,

    C. Bird, D. Ford, T. Zimmermann, N. Forsgren, E. Kalliamvakou, T. Lowdermilk, and I. Gazit, “Taking Flight with Copilot: Early insights and opportunities of AI-powered pair-programming tools,”ACM Queue, Jan. 2023

    2023

  2. [2]

    A large-scale survey on the usability of ai programming assistants: Successes and challenges,

    J. T. Liang, C. Yang, and B. A. Myers, “A large-scale survey on the usability of ai programming assistants: Successes and challenges,” inProceedings of the IEEE/ACM 46th International Conference on Software Engineering, ICSE ’24, (New York, NY , USA), Association for Computing Machinery, 2024

    2024

  3. [3]

    Attribution problem of generative ai: a view from us copyright law,

    Z. Kahveci, “Attribution problem of generative ai: a view from us copyright law,”Journal of Intellectual Property Law and Practice, vol. 18, pp. 796–807, 09 2023

    2023

  4. [4]

    Asleep at the keyboard? assessing the security of github copilot’s code contri- butions,

    H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri, “Asleep at the keyboard? assessing the security of github copilot’s code contri- butions,”Commun. ACM, vol. 68, p. 96–105, Jan. 2025

    2025

  5. [5]

    An empirical study of code smells in transformer-based code generation techniques,

    M. L. Siddiq, S. H. Majumder, M. R. Mim, S. Jajodia, and J. C. S. Santos, “An empirical study of code smells in transformer-based code generation techniques,” in2022 IEEE 22nd International Working Con- ference on Source Code Analysis and Manipulation (SCAM), pp. 71–82, 2022

    2022

  6. [6]

    Un- veiling memorization in code models,

    Z. Yang, Z. Zhao, C. Wang, J. Shi, D. Kim, D. Han, and D. Lo, “Un- veiling memorization in code models,” inProceedings of the IEEE/ACM 46th International Conference on Software Engineering, ICSE ’24, (New York, NY , USA), Association for Computing Machinery, 2024

    2024

  7. [7]

    DOE 1 et al. v. GitHub, Inc., et al.,

    DOE 1 et al., “DOE 1 et al. v. GitHub, Inc., et al.,” 2022. Case No. 4:22-cv-06823 (N.D. Cal.)

    2022

  8. [8]

    Executive Order 14028, Improving the Nation’s Cybersecurity,

    “Executive Order 14028, Improving the Nation’s Cybersecurity,”NIST, Apr. 2021. Last Modified: 2022-07-11T15:36-04:00

    2021

Show all 35 references
  1. [9]

    Regulation - 2024/2847 - EN - EUR-Lex

    “Regulation - 2024/2847 - EN - EUR-Lex.”

    2024

  2. [10]

    Talkin’ ’bout ai generation: Copyright and the generative-ai supply chain (the short version),

    K. Lee, A. F. Cooper, and J. Grimmelmann, “Talkin’ ’bout ai generation: Copyright and the generative-ai supply chain (the short version),” in Proceedings of the 2024 Symposium on Computer Science and Law, CSLAW ’24, (New York, NY , USA), p. 48–63, Association for Com- puting M...

    2024

  3. [11]

    An empirical analysis of machine learning model and dataset documentation, supply chain, and licensing challenges on hugging face,

    T. Stalnaker, N. Wintersgill, O. Chaparro, L. A. Heymann, M. Di Penta, D. M. German, and D. Poshyvanyk, “An empirical analysis of machine learning model and dataset documentation, supply chain, and licensing challenges on hugging face,”ACM Trans. Softw. Eng. Methodol., Nov. 2025

    2025

  4. [12]

    Towards a rigorous science of interpretable machine learning,

    F. Doshi-Velez and B. Kim, “Towards a rigorous science of interpretable machine learning,” 2017

    2017

  5. [13]

    Data Authenticity, Consent, and Prove- nance for AI Are All Broken: What Will It Take to Fix Them?,

    S. Longpre, R. Mahari, N. Obeng-Marnu, W. Brannon, T. South, J. Kabbara, and S. Pentland, “Data Authenticity, Consent, and Prove- nance for AI Are All Broken: What Will It Take to Fix Them?,” An MIT Exploration of Generative AI, mar 27 2024. https://mit- genai.pubpub.org/pub/uk7op8zs

    2024

  6. [14]

    Introducing Code Referencing for GitHub Copilot Chat in Visual Studio,

    R. Patel, “Introducing Code Referencing for GitHub Copilot Chat in Visual Studio,” Dec. 2024

    2024

  7. [15]

    Do llms provide links to code similar to what they generate? a study with gemini and bing copilot,

    D. Bifolco, P. Cassieri, G. Scanniello, M. D. Penta, and F. Zampetti, “Do llms provide links to code similar to what they generate? a study with gemini and bing copilot,” in2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR), pp. 223–235, 2025

    2025

  8. [16]

    Automated and explainable provenance of ai-generated code

    “Automated and explainable provenance of ai-generated code.” https: //www.nsf.gov/awardsearch/show-award/?AWD ID=2533367, 2026

    2026

  9. [17]

    Boms away! inside the minds of stakeholders: A comprehensive study of bills of materials for software systems,

    T. Stalnaker, N. Wintersgill, O. Chaparro, M. Di Penta, D. M. German, and D. Poshyvanyk, “Boms away! inside the minds of stakeholders: A comprehensive study of bills of materials for software systems,” inProceedings of the IEEE/ACM 46th International Conference on Software Eng...

    2024

  10. [18]

    Developer perspectives on licensing and copyright issues arising from generative ai for software development,

    T. Stalnaker, N. Wintersgill, O. Chaparro, L. A. Heymann, M. D. Penta, D. M. German, and D. Poshyvanyk, “Developer perspectives on licensing and copyright issues arising from generative ai for software development,”ACM Trans. Softw. Eng. Methodol., vol. 35, Jan. 2026

    2026

  11. [19]

    “the law doesn’t work like a computer

    N. Wintersgill, T. Stalnaker, L. A. Heymann, O. Chaparro, and D. Poshy- vanyk, ““the law doesn’t work like a computer”: Exploring software licensing issues faced by legal practitioners,”Proc. ACM Softw. Eng., vol. 1, July 2024

    2024

  12. [20]

    Determining the provenance of software artifacts,

    M. W. Godfrey, D. M. German, J. Davies, and A. Hindle, “Determining the provenance of software artifacts,” inProceedings of the 5th Interna- tional Workshop on Software Clones, IWSC ’11, (New York, NY , USA), p. 65–66, Association for Computing Machinery, 2011

    2011

  13. [21]

    Code siblings: Technical and legal implications of copying code between applications,

    D. M. German, M. Di Penta, Y .-G. Gueheneuc, and G. Antoniol, “Code siblings: Technical and legal implications of copying code between applications,” in2009 6th IEEE International Working Conference on Mining Software Repositories, pp. 81–90, 2009

    2009

  14. [22]

    Source-Aware Training Enables Knowledge Attribution in Language Models,

    M. Khalifa, D. Wadden, E. Strubell, H. Lee, L. Wang, I. Beltagy, and H. Peng, “Source-Aware Training Enables Knowledge Attribution in Language Models,”arXiv preprint arXiv:2404.01019, 2024

    2024 arXiv

  15. [23]

    Trained without my consent: Detecting code inclusion in language models trained on code,

    V . Majdinasab, A. Nikanjam, and F. Khomh, “Trained without my consent: Detecting code inclusion in language models trained on code,” ACM Trans. Softw. Eng. Methodol., vol. 34, Apr. 2025

    2025

  16. [24]

    How propense are large language models at producing code smells? a benchmarking study,

    A. Velasco, D. Rodriguez-Cardenas, L. R. Alif, D. N. Palacio, and D. Poshyvanyk, “How propense are large language models at producing code smells? a benchmarking study,” in2025 IEEE/ACM 47th Interna- tional Conference on Software Engineering: New Ideas and Emerging Results (IC...

    2025

  17. [25]

    A causal perspective on measuring, explaining and mitigating smells in llm-generated code,

    A. Velasco, D. Rodr ´ıguez-C´ardenas, D. Khati, D. N. Palacio, L. R. Alif, and D. Poshyvanyk, “A causal perspective on measuring, explaining and mitigating smells in llm-generated code,” inProceedings of the 48th International Conference on Software Engineering (ICSE ’26), Nov...

    2026

  18. [26]

    How do semantically equivalent code transformations impact membership inference on LLMs for code?,

    H. Yang, A. Velasco, T. Le-Cong, M. N. Haque, B. Xu, and D. Poshy- vanyk, “How do semantically equivalent code transformations impact membership inference on LLMs for code?,” inProceedings of the 48th International Conference on Software Engineering (ICSE ’26), November 2026. ...

    2026

  19. [27]

    Understand- ing privacy risks in code models through training dynamics: A causal approach,

    H. Yang, A. Velasco, S. Fang, B. Xu, and D. Poshyvanyk, “Understand- ing privacy risks in code models through training dynamics: A causal approach,”arXiv preprint arXiv:2512.07814, 2025

    2025

  20. [28]

    A unified approach to interpreting model predictions,

    S. M. Lundberg and S.-I. Lee, “A unified approach to interpreting model predictions,” inProceedings of the 31st International Conference on Neural Information Processing Systems, NIPS’17, (Red Hook, NY , USA), p. 4768–4777, Curran Associates Inc., 2017

    2017

  21. [29]

    Enabling Global, Human-Centered Explanations for LLMs:From Tokens to Interpretable Code and Test Generation,

    D. Khati, D. Rodriguez-Cardenas, D. N. Palacio, A. Velasco, M. Tufano, and D. Poshyvanyk, “Enabling Global, Human-Centered Explanations for LLMs:From Tokens to Interpretable Code and Test Generation,” in Proceedings of the 48th International Conference on Software Engineer- in...

    2026

  22. [30]

    Rationales for sequential predictions,

    K. Vafa, Y . Deng, D. M. Blei, and A. M. Rush, “Rationales for sequential predictions,” inEmpirical Methods in Natural Language Processing, 2021

    2021

  23. [31]

    Membership inference attacks on machine learning: A survey,

    H. Hu, Z. Salcic, L. Sun, G. Dobbie, P. S. Yu, and X. Zhang, “Membership inference attacks on machine learning: A survey,”ACM Comput. Surv., vol. 54, Sept. 2022

    2022

  24. [32]

    Toward a Theory of Causation for Interpreting Neural Code Models ,

    D. Nader Palacio, A. Velasco, N. Cooper, A. Rodriguez, K. Moran, and D. Poshyvanyk, “ Toward a Theory of Causation for Interpreting Neural Code Models ,”IEEE Transactions on Software Engineering, vol. 50, pp. 1215–1243, May 2024

    2024

  25. [33]

    Decomposing a recurrent neural network into modules for enabling reusability and replacement,

    S. M. Imtiaz, F. Batole, A. Singh, R. Pan, B. D. Cruz, and H. Rajan, “Decomposing a recurrent neural network into modules for enabling reusability and replacement,” inProceedings of the 45th International Conference on Software Engineering, ICSE ’23, p. 1020–1032, IEEE Press, 2023

    2023

  26. [34]

    Towards monosemanticity: Decomposing language mod- els with dictionary learning,

    T. Bricken, A. Templeton, J. Batson, B. Chen, A. Jermyn, T. Conerly, N. Turner, C. Anil, C. Denison, A. Askell, R. Lasenby, Y . Wu, S. Kravec, N. Schiefer, T. Maxwell, N. Joseph, Z. Hatfield-Dodds, A. Tamkin, K. Nguyen, B. McLean, J. E. Burke, T. Hume, S. Carter, T. Henighan, ...

    2023

  27. [35]

    Locating and editing factual associations in gpt,

    K. Meng, D. Bau, A. Andonian, and Y . Belinkov, “Locating and editing factual associations in gpt,” inProceedings of the 36th International Conference on Neural Information Processing Systems, NIPS ’22, (Red Hook, NY , USA), Curran Associates Inc., 2022

    2022

Pith tools

Reviewed August 4, 2026 · model on record in the stance chip above.