Kati8/ICLR_2023_2025 huggingface dataset:
authors: Jiali Cheng
authors: Hadi Amiri
reviews: 
Comments: This paper introduces the concept of tool unlearning for tool-augmented large language models (LLMs), addressing the need to remove learned tools due to security, privacy, or obsolescence concerns. Unlike traditional unlearning, tool unlearning focuses on knowledge removal rather than forgetting data samples, involves significant optimization costs, and lacks established evaluation methods. To address these challenges, the authors propose three key properties for effective tool unlearning and present ToolDelete, the first method designed for this purpose. Additionally, they introduce the first membership inference attack (MIA) model to evaluate unlearning effectiveness. Experiments on multiple tool learning datasets demonstrate that ToolDelete can successfully unlearn both randomly chosen tools and specific tool categories without compromising the LLM’s performance on non-deleted tools or general tasks.
Strengths: 1.	The problem of tool unlearning is interesting and well-motivated. We definitely need a solution dedicated to achieving tool unlearning for LLM-enabled agents.

2.	The experiment is extensive and comprehensive.

3.	The paper is well-organized and easy for readers to follow.
Weaknesses: 1.	I disagree with most differences of tool unlearning compared with sample-level unlearning. According to the entire paper, especially the experiment setups, the tool unlearning also relies on training or tuning with unlearning tool-related data. The model ability regarding certain tasks or tools is reflected in the data samples, in this sense, sample-level unlearning and tool unlearning are the same. Except for the difference regarding Evaluation, I don’t think there is any uniqueness in tool unlearning.

2.	Two terms of Eq. (5) require the base model f_0 without learning any tools. However, in practical scenarios, only the model f that has learned many tools is available to unlearn certain tools. How does ToolDelete work in the case when f_0 is unavailable?

3.	In terms of LiRA-Tool, how you generate ‘shadow samples’ via prompting GPT-4, detailed instructions or prompts should be provided.
 
4.	A comparison between traditional sample-level LiRA and LiRA-Tool is needed, which can reflect the issues of sample-level LiRA mentioned in Lines 296-298.

5.	The training time comparison to retraining from scratch has no significance. The comparison between ToolDelete and other baseline unlearning approaches is more needed.
Recommendation: 5
Reviewer confidence: 3
Soundness/correctness: 2
Clarity: 3
reviews: 
Comments: The authors introduce a new kind of task, "tool forgetting". Compared with traditional forgetting, it needs to deal with different challenges: it is knowledge to be removed rather than individual samples to be forgotten, and the cost of optimizing LLMs is high. To address these issues, the authors propose TOOLDELETE, and a member inference attack model LiRA-Tool, .
Strengths: (1)The tool forgetting task is innovatively proposed, opening up a new direction for related research.

(2) The TOOLDELETE method has a clear design and implementation, and the experimental results show that it is effective in tool forgetting.

(3) A LiRA-Tool model is developed to evaluate tool forgetting, which is novel.
Weaknesses: (1) Does the author's approach apply to closed-source or API-only LLMs? If so, the author can perform some extended experiments to better illustrate the effect of TOOLDELETE.

(2) There is a lack of sufficient research on the impact of different model sizes on tool forgetting.

(3) The shadow samples in LiRA-Tool may not fully represent the complexity of the original tool learning data, which affects the accuracy of the evaluation.
Recommendation: 5
Reviewer confidence: 3
Soundness/correctness: 3
Clarity: 3
reviews: 
Comments: The paper propose a novel threat model that looks at tool use knowledge as source of privacy and security issues and therefore proposes methods to unlearn them. One of the more convincing examples is that a tool that knows how to operate a private tool might reveal to adversary some information. 

The paper goes with proposing a ToolDelete method that using three separate objectives: removal, retention and utility retention finetunes/DPO the model to achieve these objectives. The paper further states challenges with evaluation and adapts LiRA approach to measure method efficiency.
Strengths: - Overall the paper is well written with a standard and comprehensive evaluation and methods. 
- The paper presents a novel threat model
- Evaluation focuses on three popular benchmarks for tool use
- Results show a strong advantage of the proposed ToolDelete method over standard unlearning tools
Weaknesses: - It is not clear if the threat model is valid -- the right to be forgotten claims that appear in intro and broader impacts have no relation to the tool use and therefore invalid. A credible attack that shows privacy or security issues is required to justify the proposed problem. While the problem itself is novel I struggle to see the value in addressing this problem, i.e. why would anybody want to unlearn tools for privacy/security reasons. 

- It is mentioned that full re-training is costly and pointless, however while this argument is relevant  for unlearning literature in general it does not look to me relevant for this particular problem. As the pipeline commonly shows tool use training comes after the most costly part of model pre-training and therefore is not that challenging to do. Furthermore, it is not clear that models should be trained to support all tool use in practice -- it could be that for particular use cases the company would only train for a particular sub-set of tools and therefore retraining the model is not a challenge.

-- novelty: while the threat model is novel it is not clear, how novel is the contribution as the proposed method simply balances three losses that seems like a rather straightforward way to build the tooldelete method -- explaining the challenges would be interesting. However, I have to note LiRA-Tool adaptation is nice trick (nevertheless the paper does not focus on this part as much).

-- Investigating imbalance in tool unlearning seems interesting but does not exist in the paper. The authors only measure percentage of unlearned tools, but I would rather see how different tools impact unlearning metrics --> where does the drop in Table 1 come from?
Recommendation: 5
Reviewer confidence: 4
Soundness/correctness: 3
Clarity: 4
reviews: 
Comments: The paper introduces the "Tool Unlearning" concept for Tool-Augmented LLMs, with a focus on scenarios where these models need to forget specific tools due to security, privacy, or obsolescence reasons. The proposed methodology, TOOLDELETE, addresses the unique challenges of removing tool-specific capabilities while preserving other functionalities and general task performance. TOOLDELETE is evaluated using a novel membership inference attack (LiRA-Tool) adapted for this context. Experiments demonstrate that TOOLDELETE effectively unlearns tools without compromising the model's general utility or knowledge of other tools.
Strengths: The unlearning setting introduced in this paper appears to be novel, and the authors have conducted comprehensive experiments across a collection of benchmarks, covering a wide range of methods.
Weaknesses: My biggest concern is why tool unlearning needs to be addressed at the parameter level. Ideally, a tool-augmented LLM consists of both the model and a system supporting its tool-calling functionality. If such a system is in place, it should be relatively straightforward to "unlearn" a tool by implementing heuristic-based rules to block specific actions. It’s unclear why this wouldn’t be sufficient, particularly for the use cases mentioned by the authors, such as restricting tool calls that access sensitive domains or return specific email addresses. Additionally, system-level patches are more interpretable and can easily scale by adding more heuristics.

I would expect the authors to provide more justification for scenarios where system-level solutions fall short, and thus necessitating parameter-level unlearning interventions.
Recommendation: 5
Reviewer confidence: 4
Soundness/correctness: 2
Clarity: 3