Thanks for your detailed review and valuable feedback. We provide our responses below:

Response about Weaknesses

Thank you for recognizing the novelty of our framework. We clarify our key contributions as follows:

(1) A systematic evaluation framework for tool hallucinations.

Our framework integrates rule-based and LLM-based evaluations. While rule-based methods ensure syntactic correctness in tool invocation, they overlook whether a valid invocation is actually non-hallucinatory. This issue has been largely ignored in prior work, which often neglects tool content hallucination. Additionally, we introduce the Reliable Pass Rate (RePR) metric to address limitations in traditional pass rate evaluations by explicitly considering tool hallucinations.

(2) Joint alignment of helpfulness and reliability.

Unlike previous work that focuses solely on task completion, our Relign framework also emphasizes the reliability of tool usage. This reduces both hallucinated and ineffective tool calls while maintaining high task success rates. Our approach jointly optimizes these factors using a comprehensive utility metric to ensure balanced performance.

(3) Differences from conventional SFT+DPO training.

While our training builds on preference optimization, we redefine the optimization objectives by introducing an indecisive action space, teaching the model when to execute indecisive actions instead of hallucinating. Unlike general preference alignment methods that optimize multiple factors, we explicitly focus on helpfulness and reliability, leveraging structured preference data to refine tool invocation decisions. Rather than modifying the core algorithm, our contribution lies in refining training objectives and data synthesis.

Response about Q1

In our work, indecisive actions are implemented as special termination functions, such as direct termination, tool switching, and TalkToUser. When the model invokes these functions, the tool invocation process ends immediately, as the model determines the task to be infeasible. The model learns to use these functions through SFT and DPO training.

• SFT stage: We introduce the indecisive action space by modifying tasks to be unsolvable (e.g., changing toolsets) and training the model to invoke appropriate termination functions instead of hallucinating.

• DPO stage: The model refines its decision-making through preference learning. At each tool invocation step, multiple outputs are sampled.

  • If the task is feasible, the preference order is: correct tool invocation > hallucinated tool invocation > indecisive action.

  • If the task is infeasible, the order is: indecisive action > hallucinated tool invocation (as correct tool use is impossible).

This data-driven approach enables the model to assess the task's feasibility and determine whether to continue tool invocation or execute an indecisive action, effectively reducing hallucinations.

Response about Q2

(1) Is there additional human evaluation for the metrics?

Our evaluation metrics are improvements upon the Pass Rate introduced in ToolBench, which has been validated through human evaluation in its original work. While our study introduces several new evaluation metrics, they primarily rely on tool hallucination evaluation. Thus, we conducted targeted human evaluation on the LLM-based components to ensure accuracy. Given the alignment with prior metrics, we believe this evaluation is sufficient. However, if specific aspects require further assessment, we are open to conducting additional evaluations.

(2) Is LLM-based automatic evaluation feasible and reasonable? How do we ensure evaluation accuracy?

Our evaluation is divided into two specific tasks: assessing tool-task relevance and checking parameter-user input consistency. These tasks are simpler than full tool invocation, as critique-based judgments are easier than generative actions. We further enhance reliability by using specialized prompts to guide assessments and instructing the LLM to return “unsure” when uncertain (see Table 3 in the appendix). This approach minimizes errors and ensures accurate evaluations. Our human validation further confirms its effectiveness.

Response about Q3

Apologies, but we have not conducted additional exploration into model architectures. To the best of our knowledge, existing research on hallucinations has not discussed the impact of different model architectures (e.g., MoE, Mamba) on hallucinations. Our work primarily focuses on proposing an evaluation framework for tool hallucinations and improving tool hallucination mitigation based on this framework. We believe investigating the relationship between model architectures and tool hallucinations is beyond the scope of this paper.

We greatly appreciate your valuable feedback and look forward to your response.

Thanks for your detailed review and valuable feedback. We provide our responses below:

Re. to Experimental Designs or Analyses

• (1) All experiments share the same hyperparameters unless stated otherwise. In all methods, the learning rate is set to 1e-5 for SFT and 1e-5 for DPO to ensure consistency.

• (2) The SFT dataset contains 10,000 fixed samples, so the number of training steps remains the same. However, DPO training steps vary across methods and models. We select 10,000 tasks and allow multi-round interactions with the environment. In each round, we sample ten outputs at a temperature of 0.7 to construct the DPO dataset. This results in a theoretical maximum of 10,000 tasks × number of interaction rounds, but not all rounds yield valid DPO samples. In practice, the number of DPO preference pairs ranges from 10,000 to 20,000. For example, in Relign training, Toolllama, Llama3.1, and Qwen2.5 yield 17,000, 19,000, and 14,000 pairs, respectively. The final training steps depend on the number of DPO pairs, using a batch size of 32 for two epochs.

• (3) We did not perform a grid search but used standard values (e.g., 1e-5 for SFT, 1e-6 for DPO) to ensure stable fine-tuning, focusing on training data synthesis rather than hyperparameter optimization.

• (4) Relign follows a two-stage training: SFT first, then DPO on the SFT model. The key distinction between Relign and other methods lies in the base model used for DPO data sampling. In Relign, the DPO training data is sampled from a model that has undergone SFT training, whereas in other methods, it is not. We believe SFT introduces an indecisive action space, which is then refined during DPO. Without SFT, the model generates fewer indecisive actions, leading to suboptimal DPO training. This explains Relign’s superior performance.

• (5) We apologize for any confusion caused. Larger models generally reduce tool hallucinations due to improved general capabilities. However, increasing training data slightly raises hallucinations, likely due to overfitting on ToolBench data, which consists of well-structured tool interaction trajectories and lacks samples that handle edge cases (e.g., failure scenarios where a task cannot be completed). Thus the model learns correct tool calls but struggles with failure scenarios, defaulting to excessive hallucinated tool calls instead of invoking indecisive actions—precisely the issue Relign aims to address.

• (6) We apologize for the typo. Our intended meaning was that larger models significantly reduce both tool hallucinations and excessive tool calls, leading to more reliable and efficient tool use.

Re. to Weakness #2

Thank you for the references. We highlight the key differences below:

(1) Systematic Definition and Real-World Evaluation

The cited work lacks a comprehensive taxonomy of tool hallucinations and omits key types, such as excessive tool calls (tool timing hallucinations) and fabricated tool parameters (tool content hallucinations). Additionally, its evaluation relies on sub-tasks like classification and description, which do not reflect real-world tool use. A model’s competence in these tasks does not necessarily prevent hallucinations during actual tool interactions. In contrast, our evaluation occurs within real-world tool-use scenarios, ensuring direct assessment of hallucinations in execution. We also introduce an LLM-based automated evaluation to systematically assess these hallucination types.

(2) Beyond Evaluation: Alignment and Training

While the cited work focuses on dataset construction, it does not address model training or alignment. Our work goes further by proposing a framework and data synthesis approach that effectively reduces tool hallucinations and improves tool-use efficiency and reliability.

Re. to Weakness #3

As shown in the table below, we also evaluate our method on the out-of-domain test set APIBench. We follow the evaluation setup described in [1] (for more details, please refer to [1]). Rather than training on APIBench, we treat each API in the prompt as a function call to assess how well our trained model generalizes to OOD datasets. Experimental results with two types of tool retrieval indicate that Relign improves model performance on other tool-use tasks as well, suggesting that reducing tool hallucinations helps models learn better tool-use strategies (AST represents tool-calling accuracy).

[1] Toolllm: Facilitating Large Language Models To Master 16000+ Real-World Apis.

Re. to Q1

Please see the response to Reviewer fZsh’s Existing Metrics for more details.

Thanks for your detailed review and valuable feedback. We provide our responses below:

Re. to Evaluation Criteria & Q4

(1) Why did we introduce LLM-based evaluation?

Our evaluation process for tool hallucinations consists of both rule-based evaluation and LLM-based evaluation. Rule-based evaluation can determine whether the LLM’s tool calls follow correct syntax. However, a key question arises: Is a syntactically valid invocation actually non-hallucinatory? This is why we introduced LLM-based evaluation—only an LLM can assess aspects beyond syntactic correctness and evaluate the content itself. LLM-based evaluation has also been widely used in prior research on hallucination assessment [1-2].

(2)How do we ensure evaluation accuracy?

In our LLM-based evaluation process, we decompose the assessment into specific evaluation tasks. On the one hand, these evaluation tasks are significantly simpler than the full tool-calling task, as making a critical judgment is easier than generating a valid action. On the other hand, we design dedicated evaluation prompts tailored to each evaluation task, guiding the LLM to assess various aspects in a structured manner. Furthermore, we explicitly instruct the LLM to output unsure when it is uncertain, rather than forcing it to provide a definitive evaluation result (as shown in Table 3 in the appendix).

In summary, we believe that using LLMs for automated evaluation is reasonable, and our human evaluation results further validate its accuracy.

[1] FACTSCORE: Fine-grained Atomic Evaluation of Factual Precision in Long Form Text Generation.

[2] SelfCheckGPT: Zero-resource black-box hallucination detection for generative large language models.

Re. to Computational Efficiency

While we did not conduct direct tests on the actual computational efficiency or time reduction, we actually use Tool Num as an indicator for computational efficiency. Since the model calls a tool once per interaction round, the average number of tool calls effectively corresponds to inference time and output length. Compared to dynamic and less stable metrics, the number of tool calls remains relatively fixed. Therefore, we primarily use the Tool Num metric to reflect the efficiency gains achieved by our method. As shown in Table 2, our model significantly reduces the average number of tool calls per task (ToolLlama reduces from 3.7 to 0.9, Llama3.1 from 2.2 to 1.5, and Qwen2.5 from 2.4 to 1.7).

Re. to Existing Metrics

Our RePR metric is a refined version of Pass Rate, as we found that some tasks in the original pass rate metric exhibited result hallucinations. Therefore, we believe the pass rate has certain inaccuracies and did not include its results in our paper. As shown in the table below, we have supplemented some of the original Pass Rate results. The results indicate that RePR is lower than Pass Rate, and the gap is more pronounced in base models without Relign alignment. This suggests that unaligned models tend to produce more tool hallucinations, which in turn mislead the final results. Moreover, whether using Pass Rate or RePR, our Relign framework consistently improves task success rates. We will include the full results table in future versions of our paper for reference.

Re. to Q1

In some special cases, repeated tool calls may be beneficial (e.g., when a tool fails due to high latency). However, our evaluation environment is based on StableToolBench, which ensures that the tool environment remains stable. In this scenario, repeated tool calls are typically an abnormal behavior of the model. Besides, in our specific evaluation of repeated tool calls, a tool call is only considered a hallucination if both the tool call itself and its environmental feedback are identical. This approach can partially address your concern.

Re. to Q2 and Q3

In the Indecisive Action Space, ChangeTool and TalkToUser are designed as two special termination functions. When the model invokes either of these functions, the tool invocation process is immediately terminated, as the model has determined that the task cannot be completed in the current environment. As a result, we did not design specific pipelines for tool switching (which would require a tool retriever ) or for user interaction (which would require a user simulator). Instead, we directly exit the process upon encountering these exceptional actions. We will explore how to better design task execution workflows following exceptional actions in future work.

Thanks for your detailed review and valuable feedback. We provide our responses below:

Response about RePR

We apologize for any confusion caused by the description of the metric. In fact, the model is not penalized multiple times. RePR represents the proportion of tasks that were originally considered as successfully passed but were later verified to be free of result hallucinations through our hallucination detection. The deducted portion consists of tasks that were initially deemed successful but were later identified as containing result hallucinations. Importantly, tasks with a pass rate of 0 are not considered as having result hallucinations.

Response about RAG and Q1

(1) Relevance of Our Work to RAG

In our tool-based tasks, we provide the model with relevant information about each tool through the api description field in the prompts, as shown in Table 7 in the appendix. This includes descriptions of tool functionalities, tool parameters, and example values of parameters. This setup can be considered a special form of RAG tailored to tool documentation.

Since the APIs in our dataset do not appear in the model’s training data, feeding tool API documentation into the model is essential; otherwise, the model would not be able to complete the tasks.

(2) Why RAG is Not Suitable for Tool Hallucination Scenarios

As mentioned above, we already provide the model with tool API usage instructions in the prompt, yet the model still exhibits different types of tool hallucinations during task execution. This could be due to the relatively limited knowledge contained in RAG-based knowledge retrieval.

Another possible way to construct a RAG knowledge base is to generate and retrieve real usage examples for specific tool APIs, similar to in-context learning. However, in our inference setting, many of the APIs we encounter are not present in the training database. This makes it difficult to pre-prepare corresponding demonstration examples. A potential alternative would be to synthetically generate a large number of tool invocation examples and then filter out high-quality examples. However, this approach does not generalize well to large-scale real-world tool-use scenarios and is beyond the scope of this paper.

(3) Discussion on RAG and Post-Training for Addressing Hallucination

a. Challenges in Constructing RAG Knowledge Bases

RAG relies on external knowledge bases, which can be difficult to construct. If the knowledge base from the training data does not sufficiently cover the inference-time data, applying RAG becomes challenging.

b. Fundamental Differences Between RAG and Post-Training

RAG is designed to mitigate hallucinations by introducing external knowledge at inference time. Unlike post-training methods, RAG does not update the model’s parameters, making it relatively lightweight. However, RAG typically retrieves specific pieces of information, which at most allows the model to mimic certain patterns, similar to in-context learning.

In contrast, post-training methods can deeply alter the model’s cognition and capabilities through training. When hallucinations stem from the model’s inherent weaknesses in understanding and interacting with the tool environment, RAG combined with prompting may be insufficient to mitigate these hallucinations. This is particularly relevant for the tool hallucinations observed in our experiments. In such cases, post-training is necessary to enable the model to better learn and model the tool interaction environment.

Response to Q2

First, the RelyToolBench dataset includes both the original subset from StableToolBench and additional subsets specifically designed to evaluate particular hallucinations, namely the Unmatched Tools and Miss Parameter subsets. It is important to emphasize that the original subset closely resembles real-world applications. However, it also contains four different types of hallucinations as shown in Figure 6 in our paer, and both its tasks and APIs are relatively realistic. This demonstrates that similar hallucinations occur in real-world scenarios, not just in our two synthetically constructed subsets.

Additionally, as described in our response to Reviewer fZsh’s Weakness#3, we conducted evaluations on an out-of-distribution test set APIBench. We observed that models trained with our Relign method did not show a decline in tool-calling capabilities; in fact, they even exhibited some improvements. This provides further evidence supporting the generalization ability of our approach.

Response to Scientific Literature

Thank you for providing the references. We will cite them in future versions of our paper and supplement our discussion accordingly.

We greatly appreciate your thoughtful feedback and look forward to your response.