Can Tool-augmented Large Language Models be Aware of Incomplete Conditions?
Authors: Seungbin Yang, ChaeHun Park, Taehee Kim, Jaegul Choo


Reviewer paper summaries: The paper at hand provides a nugget of analysis for the tool usage by LLMs in cases of inadequate details and when no appropriate tool is not available. They introduce a new benchmark that consists of simulated data and test LLM's tool use ability using this benchmark. To create this benchmark they combine APIBank and ToolBench datasets. They measure the performances of Mistral-7B, LLaMA-2, Vicuna and Claude-3, ChatGPT,  and GPT-4.

This paper explores the performance of tool-augmented large language models (LLMs) when faced with incomplete conditions, particularly when users provide insufficient information or the necessary tools are unavailable. The study simulates these scenarios by manipulating instances from two datasets to evaluate whether LLMs can recognize and handle such incomplete conditions. Experimental results show that most LLMs struggle to identify the additional information required or the absence of appropriate tools. The findings contribute to improving the reliability of tool-augmented LLMs.
Summary of strengths: - Very well-written, and straightforward flow of information
- Insightful empiricial results and analysis on the performance of the models on this benchmark
- reasonable benchmark creation and execution strategies

1. The paper addresses a relatively unexplored area, focusing on the performance of LLMs under incomplete conditions, providing new insights into this field.
2. Recognizing incomplete conditions is crucial for enhancing the reliability of LLMs in real-world applications, especially when users often provide incomplete information.
3. By manipulating existing datasets, the study generates rigorous data to test LLMs' capabilities, ensuring the experiments' robustness and reliability.
4. The paper extensively tests various open-source and proprietary LLMs, offering detailed performance insights across different models in handling incomplete conditions.
5. The study mentions that it will make its code and dataset publicly available, facilitating reproducibility and further research within the scientific community.
Summary of weaknesses: - The paper's narrative focuses too much on how models are performing badly. This is a pretty subjective claim, as it seems most of the models are performing better than chance probability. 
- There may be better analysis on how the size of the models affect the performance, GPT-4 and other closed models can reach all the way to 80% accuracy. That is not really bad, but also not good either. But this can be a good reason why this benchmark is necessary for the field. 
- Additional experiments may be necessary for other evaluation metrics, so that we can truly claim that the models are performing "good" or "bad". One option can be to test humans on this benchmark as well, to see the ceiling performance. It may improve the paper if people who are advanced API users, and novice users can do an annotation instead of the LLMs answering a "Yes" or "No" question.
- The main issue is that LLMs are asked a "Yes" or "No" question, there can be alternative ways of measuring this. For instance, model weights can be one other way of checking the outcomes, instead of asking the models themselves.
- The motivation for the necessity of the benchmark is lacking. Why do we need to use this benchmark? Why is this important? Can't this be judged from other similar benchmarks? Why can't we just use APIBank scores as a proxy? Why do we need yet another benchmark to prove that LLMs are good/bad? Even though these questions may seem straightforward, it may be better to include them in the intro.

1. Although two datasets are used, they may not cover all possible incomplete scenarios, limiting the generalizability of the conclusions.
2. The paper focuses primarily on the current models' performance, without delving deeply into how to improve models to better recognize incomplete conditions.
3. The experiments are primarily conducted in simulated environments, lacking results from real-world applications, which may lead to differences between experimental outcomes and actual performance.
4. The paper does not explore the long-term performance of these LLMs under incomplete conditions, leaving the models' ability to continuously learn and adapt unassessed.
5. The evaluation is mainly based on accuracy and F1 scores, which may not fully capture the models' performance in complex scenarios.
Comments, suggestions and typos: - Figure one can have two headings to show the two examples, instead of relying on the reader to understand what types of tool use you are looking for. For instance, the first can be "Inadequate Info", second example can be "No Tools Available" etc.
- Minor issue: I would prefer a contribution paragraph or a bulleted list for lines 62-70.
- Table 1 takeaway issue is hard to understand, is this necessary to be a table? Couldn't this be a line in the text?
- You can include more focus on privacy and security with tool-using LLMs in your overall narrative. For instance in the example in Figure 2, the LLM is trying to create a user account without even telling the user even though they wanted to something totally different. This leads to security vulnerabilities, for instance if that data is leaked from that account and the user does not even know they have an account there etc. I think you can buiild on that example, and that would make your narrative more stronger and approachable to the readers, and increases the importance of your benchmark and your tool.
- Again, in your experiments you are asking tool-augmented LLMs yes/no questions. These two tasks are a bit different, and they are not necessarily comparable. You may need to find other ways of evaluating how the LLM is responding to the incomplete questions etc, instead of those Yes/no questions.
- Also, why is it necessary to include an LLM while construting the dataset? Can't the removal of user utterances be automated otherwise? Isn't using rule-based strategies more reliable? It would be better to have a comparison
- Why is there an imbalance in your dataset samples? 727 instances vs 883 instances. These are simulated instances, and this may skew the final results.
- The token size is very large (8192), some models performance decrease may be due to this large input size. It may be a more fair comparison between models if the inputs are truncated to a smaller size if they exceed.
- Really hard to understand the sentence in lines 199-202
- It is not reasonable to claim that "most LLMs struggle ..." [lines 255-257], as you have only tested a couple of LLMs and new ones are coming up every week. And you don't need this sentence to strengthen your paper, you can just claim "some LLMs perform less than chance, while majority of the tested LLMs perform higher"

n/a
Overall assessment scores: 3

2