ToolBridge: An Open-Source Dataset to Equip LLMs with External Tool Capabilities

## Abstract

Abstract Through the integration of external tools, large language models (LLMs) such as GPT-4o and Llama 3.1 significantly expand their functional capabilities, evolving from elementary conversational agents to general-purpose assistants.
We argue that the primary drivers of these advancements are the quality and diversity of the training data.
However, the existing LLMs with external tool integration provide only limited transparency regarding their datasets and data collection methods, which has led to the initiation of this research.
Specifically, in this paper, our objective is to elucidate the detailed process involved in constructing datasets that empower LLMs to effectively learn how to utilize external tools and make this information available to the public through the introduction of ToolBridge.
ToolBridge proposes to employ a collection of general open-access datasets as its raw dataset pool and applies a series of strategies to identify appropriate data entries from the pool for external tool API insertions.
By supervised fine-tuning on these curated data entries, LLMs can invoke external tools in appropriate contexts to boost their predictive accuracy, particularly for basic functions including data processing, numerical computation, and factual retrieval.
Our experiments rigorously isolates model architectures and training configurations, focusing exclusively on the role of data.
The experimental results indicate that LLMs trained on ToolBridge demonstrate consistent performance improvements on both standard benchmarks and custom evaluation datasets.
All the associated code and data will be open-source at https://github.com/CharlesPikachu/ToolBridge , promoting transparency and facilitating the broader community to explore approaches for equipping LLMs with external tools capabilities.

## 1 Introduction

Large language models (LLMs) have revolutionized natural language processing, excelling in tasks including question answering, summarization, and text generation [, , ].
Despite the impressive achievements of LLMs, they persistently underperform in fundamental areas, such as arithmetic or factual lookup, where introducing external tools like calculators and search engines can effectively provide solutions [, , , , , , ].

Consequently, there has been a rise in research efforts aimed at equipping LLMs with the ability to leverage external tools.
For example, Llama 3.1 [] is trained to utilize Brave Search, Python interpreter and Wolfram Alpha API by using synthetic data combined with human-annotated data.
Toolformer [] adopts a self-supervised training strategy to equip LLMs with the capability to leverage diverse tools effectively.
However, these existing LLMs tend to either only open-source their trained models and code or restrict access to the models through usage interfaces [, , ].
The data underlying the training of these models is commonly withheld from public disclosure, enveloped in secrecy.

The widespread availability of pre-trained models stands in stark contrast to the limited transparency surrounding their training datasets, which impedes the community’s progress in advancing discoveries in this area.
This emphasizes the critical need to explore ways to create high-quality, publicly available benchmark datasets for training LLMs to utilize external tools to facilitate their reasoning process.

Figure: Figure 1: Examples of data entries from ToolBridge. The proposed pipeline is capable of generating a large volume of data entries to facilitate model learning to utilize external tools.
Refer to caption: x1.png

In response to the challenges discussed, this paper proposes a pipeline for the large-scale creation of datasets designed to train LLMs in leveraging external tools.
Specifically, we begin by aggregating a substantial collection of open-source datasets used for LLM supervised fine-tuning (SFT) from the community, which circumvents proprietary concerns (*e.g.*, copyright issues).
Upon establishing this dataset pool, we propose a systematic approach to assist in the identification of valuable data entries and convert them into a standardized format.
Finally, valuable data entries filtering is conducted to further boost the quality of these converted data entries and ToolBridge is constructed.
As demonstrated in Figure 1, we showcase the data entries from ToolBridge, which are intended to guide LLMs in understanding how to incorporate external tools in appropriate contexts, thereby improving the accuracy and reliability of their outputs.
For instance, the third example in Figure 1 serves to instruct LLMs in leveraging the *requests* module to gather factual information from web sources.
Moreover, LLMs can utilize the fourth example to understand how *sympy* library can be applied to solve linear equation of one variable.

In summary, the contributions of this paper are as follows,

- •
We propose a pipeline capable of producing large volumes of entries for training LLMs to incorporate various external tools.
The collection of over 178,000 yielded data entries, named ToolBridge, will be open-sourced to the community, marking a significant advancement in the transparency and accessibility of the data for training the large language models to leverage external tools.
- •
Our experimental results indicate that LLMs supervised fine-tuned on our ToolBridge can achieve consistent performance improvements on several standard benchmarks.
- •
We also propose to curate a set of data entries to examine the abilities of LLMs in numerical calculation, data processing and factual retrieval before and after supervised fine-tuning on ToolBridge.
Experimental outcomes reaffirm the effectiveness of ToolBridge.

This is, to our knowledge, the first research in the domain of equipping LLMs with external tools that open-sources the training data.
We anticipate that ToolBridge will enable the community to further investigate the ability of LLMs to use external tools, thereby advancing LLMs from basic conversational models to versatile general-purpose assistants.

## 2 Related Work

Tool Use for LLMs. Enabling LLMs to use tools like search engines and code interpreters significantly broadens the range of tasks they can address and improves their accuracy in tasks involving data processing, numerical computation and factual retrieval [, , , , , ].
For instance, Komeili et al. [] proposed to enable the models to use a search engine by learning to generate an internet search query based on the context, and then condition its final response on the search results.
Cobbe et al. [] facilitated LLMs’ usage of a calculator during testing by training LLMs with calculation annotations injected into the training set.
Thoppilan et al. [] assisted LLMs in invoking external tools from a toolset, comprising an information retrieval system, a calculator, and a translator, by training them to produce a special string *TS*.
Gao et al. [] proposed adopting LLMs to interpret natural language problems and generate programs as intermediate reasoning steps, while delegating the solution process to a runtime environment like a Python interpreter.
HuggingGPT [] demonstrated how LLMs can act as controllers to manage and integrate various AI models across different domains and modalities.
Toolformer [] allowed LLMs to learn how to employ external tools through a self-supervised learning approach.
Of late, GPT-4o [], Llama 3.1 [] and Apple LLMs [] and several other works [] further strengthened LLMs’ ability to use external tools through improvements in models, training data, and other areas.

Although these works are highly commendable, they rarely open-source the data required to train their models, which is essential for the community to further research and refine their contributions.
This paper presents a pipeline targeted at yielding data entries for training models in external tool utilization, along with open-sourcing all data entries produced using this methodology.
This open access facilitates the development of more effective and efficient algorithms for the next generation of LLMs integrated with external tool functionalities.

Figure: Figure 2: Overview of the construction pipeline for ToolBridge. The construction of ToolBridge follows three main steps: identifying valuable data entries from the dataset pool, converting these valuable data entries to standardized format, and finally conducting a thorough cleanup of the converted data entries.
Refer to caption: x2.png

Tool Use Benchmark Datasets.
Previous research on benchmark datasets associate with tool use primarily focused on evaluating the ability of models to utilize external tools [, , , , ].
Specifically, the datasets proposed in Kasai et al. [] and Chen et al. [] were used to investigate how text retrievers improve the performance of LLMs on timely information.
ToolQA [] proposed to develop tool-based question-answer pairs to assess LLMs’ capability in arriving at accurate solutions.
Huang et al. [] suggested setting various tasks to evaluate the proficiency of LLMs in tool usage awareness and the ability to select appropriate tools.
Xu et al. [] developed a benchmark focused on tool manipulation, featuring a range of software tools applicable to real-world scenarios.
Given the scarcity of open-source large-scale datasets for equipping LLMs with external tool usage capabilities, we present ToolBridge which is a dataset of more than 178,000 data entries to support LLMs in effectively learning how to utilize external tools.

## 3 ToolBridge

Previous models like GPT-4o and Llama 3.1 only provide limited information on how they curate the data to train LLMs to leverage external tools.
To address the lack of transparency in training data, we propose a generic pipeline for constructing large-scale datasets from public sources to enable LLMs to use external tools.
As illustrated in Figure 2, the whole pipeline follows three main steps: valuable data entries selection, conversion and filtering.

**Table 1: The composition of our dataset pool $\mathcal{P}$ to construct ToolBridge.**
| Source | # of Entries | Source | # of Entries |
| --- | --- | --- | --- |
| School Math 0.25M | 248,481 | LIMA | 1,330 |
| code_instructions_120k_alpaca | 121,959 | TigerBot | 1,199,030 |
| Platypus | 24,926 | TSI-v0 | 5,607,620 |
| ShareGPT90K | 90,665 | LaMini-Instruction | 2,585,615 |
| WizardLM_Orca | 54,974 | Bactrian-X | 67,017 |
| WizardLM_evol_instruct_70k | 70,000 | Baize | 210,311 |
| tiny-codes | 1,632,309 | COIG | 178,246 |
| WizardLM evolve_instruct V2 | 143,000 | MOSS SFT | 1,074,551 |
| No Robots | 10,000 | AlpacaDataCleaned | 51,760 |
| ign_clean_instruct_dataset_500k | 508,620 | GPT-4all | 808,812 |
| GPT-4-LLM | 113,003 | Alpaca | 52,002 |
| ChatAlpaca | 20,000 | self-instruct | 82,439 |
| OpenOrca | 4,233,923 |  |  |

### 3.1 Dataset Pool Construction

Our research starts with a comprehensive review of the data accessible in the community for the purpose of supervised fine-tuning (SFT).
Table 1 summarizes the results.
Owing to the diverse range of teams contributing the SFT datasets, there is significant heterogeneity in their formats, which poses challenges for effective model training.
Hence, we first reformat all candidate datasets into a standardized ChatML format for further processing:

entry = [{"role": "user", "content": "..."},
{"role": "assistant", "content": "..."},
...].

After reformatting all the datasets, we construct the dataset pool as $\mathcal{P}=\{(\mathcal{D}_{i},W_{i},Q_{i})~{}|~{}i\geq 0\}$, where $\mathcal{D}_{i}$ denotes one candidate dataset,
$W_{i}$ measures the proportion of valuable entries for each candidate dataset, and $Q_{i}$ serves as a metric for assessing the data quality of each candidate dataset.

Practically, to obtain $W_{i}$, we first perform random sampling on $\mathcal{D}_{i}$ to produce a subset $\mathcal{S}_{i}$.
Llama3 [] is then applied to judge the appropriateness of each data entry in $\mathcal{S}_{i}$ for external tool invocation to enhance reasoning,
where the prompt employed is shown in Appendix A.1.
In generally, if a data entry is deemed suitable for invoking external tools to help LLMs’ reasoning process, we label it as a valuable data entry.
At last, we determine $W_{i}$ as the ratio between the number of valuable data entries and the total number of data entries in $\mathcal{S}_{i}$.

Additionally, we observe that some candidate datasets within the dataset pool are partially sourced from the Internet via web scraping,
resulting in the presence of meaningless HTML tags and other irrelevant content.
Thus, we incorporate $Q_{i}$ as an additional metric to evaluate the data quality of each candidate dataset.
To compute $Q_{i}$, we randomly sample $N$ data entries from $\mathcal{D}_{i}$ and conduct a manual review to identify any presence of irrelevant characters or content.
$Q_{i}$ is then derived as the fraction of data entries devoid of irrelevant content over the total number of sampled entries $N$.

### 3.2 Valuable Data Entries Selection

Upon constructing the dataset pool $\mathcal{P}$, due to the large scale of candidate data entries, we propose to select 10 million data entries from $\mathcal{P}$ for further processing according to the dataset attributes $W_{i}$ and $Q_{i}$.
Particularly, we first arrange $\mathcal{D}_{i}$ in descending order based on the value of $Q_{i}\times W_{i}$.
Then, the data entries are selected from the top-ranked datasets sequentially until the overall volume reaches 10 million entries.

Subsequently, Llama3-70B with the prompt detailed in Appendix A.1 is applied to ascertain whether each entry within the 10 million samples is appropriate for LLMs to enhance reasoning via introducing external tools.
And we represent the collection of these appropriate data entries with $\mathcal{V}$ (*i.e.*, valuable data entries).
Table 2 presents the distribution of $\mathcal{V}$ across the respective datasets they originate from.
It is observed that leveraging the capabilities of Llama3-70B, we can refine the 10 million data entries down to 1,527,153 valuable entries.

**Table 2: The composition of the selected valuable data entries $\mathcal{V}$.**
| Source | # of Entries | Source | # of Entries |
| --- | --- | --- | --- |
| School Math 0.25M | 205,996 | ChatAlpaca | 2,643 |
| Platypus | 7,776 | ShareGPT90K | 24,348 |
| WizardLM_Orca | 8,659 | WizardLM_evol_instruct_70k | 28,293 |
| WizardLM evolve_instruct V2 | 5,399 | MOSS SFT | 136,603 |
| TigerBot | 182,249 | GPT-4all | 47,627 |
| COIG | 15,181 | LIMA | 309 |
| AlpacaDataCleaned | 13,805 | GPT-4-LLM | 9,978 |
| Bactrian-X | 3,313 | OpenOrca | 834,974 |

### 3.3 Valuable Data Entries Conversion

Following valuable data entries selection, we further convert the selected data entries, allowing the language models to learn how to invoke external tools effectively within the proper context to support their reasoning process.
In particular, we draw on previous approaches [, , ] by embedding special characters in each selected entry to enable the external tool invocation,
and LLMs are employed to pinpoint the appropriate context for calling external tool APIs.

As illustrated in the examples in Figure 1, <python> and </python> are represented as a pair of special tokens.
While the content enclosed by the special tokens specifies the Python invocation for external tool use.
During the construction of ToolBridge, we predominantly utilize GPT-4o-mini to insert the special tokens in the correct context within each data entry identified in Section 3.2, as well as to create the associated code for invoking the tools.
To facilitate the return of tool execution results, we examine the code format utilized by GPT-4o when calling Python API as part of its reasoning process while answering user queries.
It is observed that the final result is always printed at the end of the code.
In line with the approach of GPT-4o, we include a directive in the prompt for GPT-4o-mini to print the final result of the tool execution as the concluding line of the code (refer to Appendix A.2).

Following GPT-4o-mini’s processing of $\mathcal{V}$, we extract the code segments between <python> and </python>, execute them, and finally insert the captured output after corresponding </python>,
where the output will be wrapped within another pair of special tokens, denoted as <result> and </result>.
To summarize, the tool invocation in ToolBridge can be formatted as,

<python>generated code</python><result>captured output</result>.

During the reasoning process of the models, it is sufficient to check for the presence of the pre-defined special tokens <python> and </python> during generation.
If identified, Python interpreter will be adopted to execute the enclosed code between the special tokens, and the executed result is wrapped in <result> and </result> to condition further text generation.
Algorithm 1 describes the primary inference process of LLMs post-SFT on the ToolBridge dataset.

Figure: Algorithm 1 Process Special Tokens During Inference

Table 3 summarizes the composition of the data entries after converting $\mathcal{V}$, denoted as $\mathcal{C}$.

**Table 3: The composition of the converted data entries $\mathcal{C}$.**
| Source | # of Entries | Source | # of Entries |
| --- | --- | --- | --- |
| School Math 0.25M | 150,104 | ChatAlpaca | 116 |
| Platypus | 82 | ShareGPT90K | 3 |
| WizardLM_Orca | 88 | WizardLM_evol_instruct_70k | 3,716 |
| WizardLM evolve_instruct V2 | 8 | OpenOrca | 101,715 |
| TigerBot | 66,793 | GPT-4all | 8,936 |
| COIG | 7,877 | LIMA | 107 |
| AlpacaDataCleaned | 4,510 | GPT-4-LLM | 2,577 |
| Bactrian-X | 84 |  |  |

It is worth noting that the data entries in $\mathcal{C}$, totaling 364,605, are considerably fewer compared to those in $\mathcal{V}$ (1,527,153).
We attribute this to the following factors,

- •
The returned data entries that lack Python code inserted by GPT-4o-mini are eliminated.
Approximately 19.2% of the data entries in $\mathcal{V}$ fall under this category, which indicates that GPT-4o-mini considers these data entries as not requiring additional tools to aid in LLMs’ reasoning.
- •
The returned data format did not match the expected structure, resulting in parsing failure.
Instances include an unequal count of <python> and </python> tokens, modifications to the original content alongside Python code insertion, to name a few.
Such data entries account for approximately 27.2% of $\mathcal{V}$.
- •
The request to GPT-4o-mini fails. These data entries constitute approximately 2.1% of $\mathcal{V}$.
- •
With Python’s *ast* library, we filter out the returned data entries where the inserted code is only an assignment followed by a print statement.
Such data entries represent about 4.8% of $\mathcal{V}$.
We provide the detailed information about the algorithm we adopt to filter such data entries in Appendix A.3.
- •
We filter around 22.8% entries of $\mathcal{V}$ to remove tool calls that could not be executed or the execution time of the tool exceeded 30 seconds (refer to Appendix A.4 for details).

In summary, 23.9% of the entries from $\mathcal{V}$ remain in the converted data entries $\mathcal{C}$.

### 3.4 Data Entries Filtering by Consistency Validation

In practice, we observe that LLMs trained on $\mathcal{C}$ do not always base their subsequent content on the results produced by the yielded Python code during inference.
So, we conduct a re-evaluation of the data entries within $\mathcal{C}$ and observe that the execution results from the code generated by GPT-4o-mini also does not always align with the ensuing text, which explains LLMs’ sporadic inconsistencies between tool execution results and further contents during inference.

To alleviate the issues above, we propose to filter the data entries in $\mathcal{C}$ where the tool execution results are inconsistent with the following text,
which is achieved by checking if the execution results are included in the subsequent text in our implementation.
Upon completing filtering, the open-source dataset ToolBridge is finally constructed.
In Appendix A.5, we compare the generated text of Llama3-8B after SFT on $\mathcal{C}$ and ToolBridge, which demonstrates the necessity for the data entries filtering by consistency validation.

The data sources that make up ToolBridge, totaling 178,023 entries, are outlined in Table 4, which represents 48.8% of the total data entries in $\mathcal{C}$.

**Table 4: The final composition of our proposed ToolBridge.**
| Source | # of Entries | Source | # of Entries |
| --- | --- | --- | --- |
| School Math 0.25M | 100,836 | ChatAlpaca | 17 |
| Platypus | 35 | ShareGPT90K | 3 |
| WizardLM_Orca | 29 | WizardLM_evol_instruct_70k | 794 |
| WizardLM evolve_instruct V2 | 1 | OpenOrca | 46,449 |
| TigerBot | 22,306 | GPT-4all | 2,616 |
| COIG | 2,706 | LIMA | 27 |
| AlpacaDataCleaned | 1,129 | GPT-4-LLM | 1,043 |
| Bactrian-X | 32 |  |  |

## 4 EXPERIMENTS

In this section, we first present the statistics of ToolBridge and then investigate whether LLMs with SFT on ToolBridge can use external tools to facilitate their reasoning process.
The validation includes three parts:
(1) by comparing LLMs’ performance on standard benchmarks before and after SFT on ToolBridge (Section 4.3);
(2) by evaluating the accuracy of the models on the custom datasets (Section 4.4);
(3) by comparing the qualitative results of LLMs (Section 4.5).

### 4.1 Dataset Statistics of ToolBridge

In Table 4, we have exhibited 15 source datasets involved in the data entries of ToolBridge, along with their respective composition ratios.
To prevent any confusion for these datasets (*e.g.*, other datasets with the same name and the same datasets with different versions), we also provide download links for these datasets in Appendix A.6.

Besides, we provide a summary of the frequency of external tool calls in ToolBridge and the variety of Python packages used for these calls, as presented in Table 5.
By comparing Table 4 and Table 5, we can observe that the majority of the data entries in ToolBridge involve only a single external tool call.
Moreover, from Table 5, we can observe that the data entries in ToolBridge originating from datasets with narrower topics (*e.g.*, School Math 0.25M) generally utilize fewer kinds of Python packages compared to those from datasets with broader topics (*e.g.*, TigerBot), which is consistent with logic.
To summarize, there are 183,147 external tool calls in ToolBridge, using a total of 62 Python packages, including *requests*, *math*, *datetime*, *sklearn*, to name a few.

**Table 5: Statistics of the usage of external tools in ToolBridge.**
| Source | # of Tool Use | # of Libraries | Source | # of Tool Use | # of Libraries |
| --- | --- | --- | --- | --- | --- |
| School Math 0.25M | 104,983 | 8 | ChatAlpaca | 73 | 1 |
| Platypus | 36 | 3 | ShareGPT90K | 3 | 0 |
| WizardLM_Orca | 33 | 4 | WizardLM_evol_instruct_70k | 836 | 22 |
| WizardLM evolve_instruct V2 | 1 | 0 | OpenOrca | 46,832 | 28 |
| TigerBot | 22,507 | 40 | GPT-4all | 2,870 | 42 |
| COIG | 2,719 | 28 | LIMA | 27 | 2 |
| AlpacaDataCleaned | 1,139 | 23 | GPT-4-LLM | 1,052 | 14 |
| Bactrian-X | 36 | 3 |  |  |  |

### 4.2 Experimental Setup

Baseline Models.
Our experiments involve four baseline models: the base model of Llama2-7B and Llama3-8B.
Also, we remove all the external tool invocation sections in each data entry in ToolBridge (denote as ToolBridge^§) and report the results of Llama2-7B and Llma3-8B SFT on ToolBridge^§ as two additional baseline models.

Benchmark Datasets.
The standard benchmark datasets used in our experiments include GSM 8k [], GSM Plus [], MathBench [] and Stanford WebQA [].
For GSM 8k and GSM Plus, we conduct performance evaluation on their respective test sets under few-shot setting, where we leverage a fixed CoT-n-shot prompt template, as outlined in [].
For MathBench, we report results on MathBench-A, where we transform the multiple-choice questions in the College, High and Middle categories into a question-and-answer format for CoT-n-shot evaluation.
To differentiate from original MathBench, we refer to this adjusted dataset as MathBench^∗.

We also design two custom datasets, named RandomQA and FACT, to evaluate the capabilities of the language models in data processing, numerical computation and factual retrieval.
Section 4.4 elaborates on the specifics of both datasets.

SFT Settings.
All the models in our experiments are trained with the open-source TRL library from Hugging Face [].
The LoRA module [] is used to perform SFT on the base model of Llama2-7B and Llama3-8B utilizing ToolBridge^§ or ToolBridge, with a LoRA rank of 16.
Model training is conducted on 64 $\times$ MI200 64GB GPUs, with each processing a batch size of 2 (*i.e.*, total batch size is 128).
AdamW is employed to optimize the parameters of LoRA, with a cosine learning rate scheduler, configuring the initial lr at 3e-5 and the total training epoch at 3.

Inference Settings.
The primary process of model inference is described in Algorithm 1.
Moreover, to handle potential tool call failures during inference, we propose to eliminate failed tool calls from the current output before conditioning the generation of further text.
All trained models are evaluated on 16 $\times$ MI200 64 GB GPUs, with the max new tokens set to 512 and the temperature set to zero.

**Table 6: Ablation studies on GSM 8k, GSM Plus and MathBench^∗ with (8 shots, CoT) setting.**
| Models | Training Data (SFT) | GSM 8k | GSM Plus | MathBench^∗ |
| --- | --- | --- | --- | --- |
| Llama2-7B | - | 13.6 | 8.9 | 18.0 |
| Llama2-7B-Lora | ToolBridge^§ | 16.9 | 9.9 | 19.1 |
| Llama2-7B-Lora | ToolBridge | 18.1 | 11.0 | 21.4 |
| Llama3-8B | - | 52.3 | 36.9 | 33.0 |
| Llama3-8B-Lora | ToolBridge^§ | 53.4 | 37.8 | 35.2 |
| Llama3-8B-Lora | ToolBridge | 55.8 | 40.0 | 37.4 |

### 4.3 Results on Standard Benchmarks

In this section, we conduct ablation studies on standard benchmark datasets, including GSM 8k, GSM Plus, MathBench and Stanford WebQA,
where GSM 8k, GSM Plus and MathBench are primarily responsible for evaluating the capability of LLMs in numerical reasoning and computation,
and Stanford WebQA is primarily used to assess the ability of LLMs in factual retrieval.
Table 6 and 7 demonstrates the evaluation results.

**Table 7: Ablation studies on Stanford WebQA with zero-shot setting.**
| Models | Training Data (SFT) | Stanford WebQA |
| --- | --- | --- |
| Llama3-8B | - | 21.2 |
| Llama3-8B-Lora | ToolBridge^§ | 37.7 |
| Llama3-8B-Lora | ToolBridge | 39.9 |

It is observed that the language models SFT on ToolBridge significantly outperform the baseline models.
For example, Llama3-8B SFT on ToolBridge brings 3.1% and 2.2% accuracy improvements to the base model of Llama3-8B and the Llama3-8B model SFT on ToolBridge^§ when evaluating on GSM Plus, respectively.
These results indicate that SFT on ToolBridge can help enhance LLMs’ abilities in handling numerical computations.
Furthermore, ToolBridge is able to facilitate LLMs’ capabilities in factual retrieval.
As shown in Table 7, SFT on ToolBridge enables Llama3-8B to boost its performance on Stanford WebQA from 21.2% to 39.9%.

The results above demonstrate that LLMs can effectively learn how to utilize external tools to enhance their capabilities in basic functions after SFT on ToolBridge.
Besides, it is worthy noting that there is significant room for improvements in these results, as our focus is on the training data, with minimal adjustments made to the model structures and training strategies,
which may help LLMs better learn how to employ external tools through ToolBridge.

**Table 8: Experimental results on RandomQA under zero-shot setting.**
| Models | Training Data (SFT) | RandomQA-1000-Batch1 | RandomQA-1000-Batch2 | RandomQA-1000-Batch3 |
| --- | --- | --- | --- | --- |
| Llama2-7B | - | 6.9 | 5.0 | 5.3 |
| Llama2-7B-Lora | ToolBridge^§ | 11.9 | 9.4 | 10.0 |
| Llama2-7B-Lora | ToolBridge | 57.9 | 55.3 | 55.9 |
| Llama3-8B | - | 9.2 | 5.9 | 7.3 |
| Llama3-8B-Lora | ToolBridge^§ | 22.4 | 19.0 | 20.4 |
| Llama3-8B-Lora | ToolBridge | 69.2 | 69.2 | 68.4 |

### 4.4 Results on Custom Benchmarks

To further assess whether SFT on the ToolBridge dataset can equip LLMs with the ability to leverage external tools for aiding its reasoning process,
we propose to design two custom datasets to evaluate LLMs’ performance before and after SFT on the ToolBridge dataset, namely, the RandomQA dataset and the FACT dataset.

RandomQA. To assess the improvements in LLMs’ data processing and numerical computation capabilities after SFT on ToolBridge,
we propose to design 50 templates capable of generating question-answer pairs to validate the abilities of the large language models in these areas. Here are some examples,

The complete list can be found in Appendix A.7.
With these pre-defined templates, we first generate three RandomQA datasets, each comprising 1,000 data entries.
For convenience, we name these three datasets RandomQA-1000-Batch1, RandomQA-1000-Batch2 and RandomQA-1000-Batch3.
Then, we evaluate the accuracy of LLMs on the three datasets before and after SFT on ToolBridge.
Table 8 demonstrates the results.
It is observed that after SFT on ToolBridge, the models shows a significant increase in accuracy on RandomQA.

**Table 9: Experimental results on FACT under zero-shot setting.**
| Models | Training Data (SFT) | FACT-200-Batch1 | FACT-200-Batch2 | FACT-200-Batch3 |
| --- | --- | --- | --- | --- |
| Llama2-7B | - | 69.5 | 55.0 | 49.0 |
| Llama2-7B-Lora | ToolBridge^§ | 86.0 | 67.5 | 65.7 |
| Llama2-7B-Lora | ToolBridge | 88.5 | 72.5 | 73.2 |
| Llama3-8B | - | 79.0 | 60.5 | 62.2 |
| Llama3-8B-Lora | ToolBridge^§ | 89.0 | 73.0 | 73.7 |
| Llama3-8B-Lora | ToolBridge | 90.0 | 73.5 | 80.2 |

FACT. To determine if the factual retrieval skills of LLMs can be improved by SFT on ToolBridge, we propose to build the FACT dataset.
Specifically, we begin by prompting GPT-4o to produce thousands of question-answer pairs focused on factual retrieval. Some examples are as shown following,

1. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Geography. Return them as a Python dictionary, with concise answers (3-5 words).

2. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with History. Return them as a Python dictionary, with concise answers (3-5 words).

Appendix A.8 contains the entire set of the leveraged prompts for constructing FACT.
Upon obtaining these candidate question-answer pairs, we continuously draw random data entries from them and manually check their correctness until 200 correct data entries are verified.
By repeating the above process three times, we collect three FACT datasets, each with a size of 200 data entries, termed FACT-200-Batch1, FACT-200-Batch2 and FACT-200-Batch3.
Table 9 provides a comparison of LLMs’ performance on the three datasets before and after undergoing SFT on ToolBridge, which shows that LLMs demonstrates enhanced abilities in retrieving factual content.

Besides, one should be aware that relying on external tools to improve the fact retrieval performance of the models can be inconsistent.
During the course of our experiments, we uncover the following deficiencies,

- •
Using external tools like the *requests* module to fetch information from external websites can lead to potentially unreliable information and LLMs thus yield incorrect results.
A solution to address this issue is to implement a curated list of trustworthy domains, restricting LLMs from accessing websites beyond this approved whitelist.
Additionally, further refining the training data entries to exclude unreliable access links is essential.
- •
The content scraped from web pages may be overly lengthy, hindering the ability of the large language models to efficiently extract useful information from the scraped contents.
- •
When LLMs access some external websites, they may attempt to download files from those sites, which poses potential security risks in real-world applications.

Therefore, we recommend that ToolBridge is only used for academic research, with controlled measures in place when it attempts to access external websites.

Figure: Figure 3: A qualitative comparison with other language models. IT denotes instruct and Web UI means we directly prompt the model using the official user interface provided in the browser.
Refer to caption: x3.png

### 4.5 Qualitative results

Finally, we provide a comparison of the qualitative results from Llama3-8B against other LLMs, both those capable of utilizing external tools to aid its reasoning process (*e.g.*, Llama3.1 and GPT-4o) and those that are not (*e.g.*, Gemma2).

As shown in Figure 3, we can observe that, after SFT on ToolBridge, Llama3-8B demonstrates significant advantages in areas such as numerical computation, owing to its ability to utilize external tools to facilitate its reasoning process.
For example, when calculating trigonometric functions, Llama3-8B SFT on ToolBridge can obtain accurate trigonometric values for each angle by invoking the Python *math* library,
while LLMs that are unable to invoke external tools can only provide an answer with significant errors.

Moreover, some additional quantitative comparison results can be found in Appendix A.9.

## 5 Conclusion

In this paper, we seek to shed light on the process of constructing datasets for training LLMs in the use of external tools.
Specifically, we propose a pipeline to build the ToolBridge dataset, where the foundation of ToolBridge lies in the raw data entries for SFT, sourced from the community.
The selection, conversion, and filtering of these raw data entries are crucial steps in developing high-quality training data for equipping LLMs with external tool abilities.
Our experiments demonstrate that SFT on ToolBridge enables LLMs to effectively learn how to utilize external tools to aid in reasoning process, particularly in the areas including data processing, numerical computation and factual retrieval.
We will make the data generation pipeline for training LLMs in tool use publicly available, along with ToolBridge, for the benefit of the community in advancing research on enabling LLMs to learn how to use external tools.

## Appendix A Appendix

### A.1 Llama3-70B Prompts

The prompt applied while using Llama3-70B to identify valuable data is as follow,

Your task is to determine whether you can add calls to a Python API to a piece of text. The calls should help you get information required to complete the text. You only need to respond with "Yes" or "No", "Yes" means you can and "No" means you can’t. Here are some examples:Input:{"messages": [{"role": "user", "content": "Sort the numbers in the list arr = [1, 10, 2, 5, -2, 11, 12] in descending order."}, {"role": "assistant", "content": "The sorted list in descending order is: [12, 11, 10, 5, 2, 1, -2]."}]}Output:YesInput:{"messages": [{"role": "user", "content": "Can you tell me a little bit about what LaTeX is?"}, {"role": "assistant", "content": "LaTeX is a high-quality typesetting system; it includes features designed for the production of technical and scientific documentation. LaTeX is the de facto standard for the communication and publication of scientific documents. It is widely used by mathematicians, scientists, engineers, philosophers, linguists, economists, and other scholars in academia and the professional world."}]}Output:NoInput:{"messages": [{"role": "user", "content": "What is the value of sin 40 degrees plus cos 31 degrees?"}, {"role": "assistant", "content": "The value is approximately sin 40 + cos 31 = 0.6428 + 0.8572 = 1.500."}]}Output:YesInput:{"messages": [{"role": "user", "content": "Write a Python script that reads an image and recognizes the text on it."}, {"role": "assistant", "content": "To read an image and recognize text on it in Python, you can use the pytesseract library along with Pillow for image processing. Here’s a simple example: \nimport pytesseract; from PIL import Image; print(pytesseract.image_to_string(Image.open(’path_to_image.jpg’))). \nMake sure you have Tesseract OCR installed on your machine and the required libraries (pytesseract and Pillow) installed in your Python environment. You can install them using: \npip install pytesseract pillow"}]}Output:NoInput:PLACEHOLDEROutput:

### A.2 GPT-4o-mini Prompts

The prompt applied while using GPT-4o-mini to convert data entries is as follow,

Your task is to add calls to a Python API to a piece of text. The calls should help you get information required to complete the text. You can call the API by writing "<python>code</python>" where "code" is the code to be executed. The last line of all code should print the variable that stores the final result. Here are some examples of API calls:Input:{"messages": [{"role": "user", "content": "Which number is greater, 13.11 or 13.8?"}, {"role": "assistant", "content": "13.8 is greater than 13.11."}]}Output:{"messages": [{"role": "user", "content": "Which number is greater, 13.11 or 13.8?"}, {"role": "assistant", "content": "<python>greater_number = max(13.11, 13.8)\nprint(greater_number)</python> 13.8 is greater than 13.11."}]}Input:{"messages": [{"role": "user", "content": "How many unique words are there in the sentence ’The quick brown fox jumps over the lazy dog’?"}, {"role": "assistant", "content": "There are eight unique words in the sentence ’The quick brown fox jumps over the lazy dog.’"}]}Output:{"messages": [{"role": "user", "content": "How many unique words are there in the sentence ’The quick brown fox jumps over the lazy dog’?"}, {"role": "assistant", "content": "There are <python>unique_words = len(set(’The quick brown fox jumps over the lazy dog’.lower().split()))\nprint(unique_words)</python> eight unique words in the sentence ’The quick brown fox jumps over the lazy dog.’"}]}Input:{"messages": [{"role": "user", "content": "What is the area of a circle with a radius of 5?"}, {"role": "assistant", "content": "The area of a circle with radius 5 is 78.54."}]}Output:{"messages": [{"role": "user", "content": "What is the area of a circle with a radius of 5?"}, {"role": "assistant", "content": "The area of a circle with radius 5 is <python>import math\narea = math.pi * 5**2\nprint(area)</python> 78.54."}]}Input:{"messages": [{"role": "user", "content": "Sort the numbers [5, 3, 8, 1, 2] in ascending order."}, {"role": "assistant", "content": "The sorted list is [1, 2, 3, 5, 8]."}]}Output:{"messages": [{"role": "user", "content": "Sort the numbers [5, 3, 8, 1, 2] in ascending order."}, {"role": "assistant", "content": "The sorted list is <python>lst = sorted([5, 3, 8, 1, 2])\nprint(lst)</python> [1, 2, 3, 5, 8]."}]}Input:{"messages": [{"role": "user", "content": "Extract the domain from the email ’example@test.com’."}, {"role": "assistant", "content": "The domain of the email ’example@test.com’ is ’test.com’."}]}Output:{"messages": [{"role": "user", "content": "Extract the domain from the email ’example@test.com’."}, {"role": "assistant", "content": "The domain of the email ’example@test.com’ is <python>domain = ’example@test.com’.split(’@’)[1]\nprint(domain)</python> ’test.com’."}]}Input:PLACEHOLDEROutput:

### A.3 Detecting Simple Code Structures: Assignment Followed by Print Statement

We adopt the following algorithm to determine if the inserted code in each data entry is simply an assignment followed by printing the variable, which is meaningless.

Figure: Algorithm 2 Identifying Code Patterns: Distinguishing Assignments Followed by Print Statements

### A.4 Optimizing Dataset Quality by Removing Non-Executable and Slow Tool Calls

The core code for removing data entries that either fail to execute or exceed the execution time limit is as follows.

Figure: Algorithm 3 Efficient Dataset Curation: Filtering Non-Executable and Time-Consuming Tool Calls

### A.5 Compare Outputs from Llama3-8B Trained on 𝒞 𝒞 \mathcal{C} caligraphic_C and ToolBridge

We notice in actual applications that the models SFT on $\mathcal{C}$ may not always leverage the tool execution results as a basis for generating further content.
Here are some examples.

Figure: Figure 4: Inconsistency between LLMs’ outputs and the returned results from Python interpreter.
Refer to caption: x4.png

By filtering out the data entries in $\mathcal{C}$ that show inconsistencies between the Python execution results and the following content, we create the ToolBridge dataset.
This refined dataset is then leveraged to train the Llama3-8B model, yielding outputs consistent with the tool execution results.
Here are some examples.

Figure: Figure 5: Consistency between LLMs’ outputs and the returned results from Python interpreter.
Refer to caption: x5.png

### A.6 Links to Data Sources Used in Our Dataset Pool

To avoid any confusion regarding the adopted datasets in this study, the download links for each dataset we have used are provided in Table 10.
Note that, links to all datasets in the dataset pool $\mathcal{P}$ are presented in this table, even those not incorporated into ToolBridge in the end.

**Table 10: Source links for the datasets utilized in the dataset pool.**
| Dataset | Source Link |
| --- | --- |
| School Math 0.25M | https://huggingface.co/datasets/BelleGroup/school_math_0.25M |
| ChatAlpaca | https://github.com/cascip/ChatAlpaca |
| Platypus | https://huggingface.co/datasets/garage-bAInd/Open-Platypus |
| ShareGPT90K | https://huggingface.co/datasets/liyucheng/ShareGPT90K |
| WizardLM_Orca | https://huggingface.co/datasets/pankajmathur/WizardLM_Orca |
| WizardLM_evol_instruct_70k | https://huggingface.co/datasets/WizardLMTeam/WizardLM_evol_instruct_70k |
| WizardLM evolve_instruct V2 | https://huggingface.co/datasets/WizardLMTeam/WizardLM_evol_instruct_V2_196k |
| OpenOrca | https://huggingface.co/datasets/Open-Orca/OpenOrca |
| TigerBot | https://huggingface.co/datasets/TigerResearch/sft_en, TigerResearch/sft_zh |
| GPT-4all | https://huggingface.co/datasets/nomic-ai/gpt4all-j-prompt-generations |
| COIG | https://huggingface.co/datasets/BAAI/COIG |
| LIMA | https://huggingface.co/datasets/GAIR/lima |
| AlpacaDataCleaned | https://huggingface.co/datasets/yahma/alpaca-cleaned |
| GPT-4-LLM | https://github.com/Instruction-Tuning-with-GPT-4/GPT-4-LLM |
| Bactrian-X | https://huggingface.co/datasets/MBZUAI/Bactrian-X |
| code_instructions_120k_alpaca | https://huggingface.co/datasets/iamtarun/code_instructions_120k_alpaca |
| TSI-v0 | https://huggingface.co/datasets/tasksource/tasksource-instruct-v0 |
| Alpaca | https://github.com/tatsu-lab/stanford_alpaca |
| No Robots | https://huggingface.co/datasets/HuggingFaceH4/no_robots |
| Baize | https://github.com/project-baize/baize-chatbot |
| LaMini-Instruction | https://huggingface.co/datasets/MBZUAI/LaMini-instruction |
| tiny-codes | https://huggingface.co/datasets/nampdn-ai/tiny-codes |
| self-instruct | https://github.com/yizhongw/self-instruct |
| ign_clean_instruct_dataset_500k | https://huggingface.co/datasets/ignmilton/ign_clean_instruct_dataset_500k |
| MOSS SFT | https://github.com/OpenMOSS/MOSS |

### A.7 Templates for Yielding RandomQA Dataset

The complete list of templates used to generate the RandomQA dataset is as follows,

### A.8 Prompts for Construing FACT Dataset

We construct the FACT datasets by prompting GPT-4o with the following instructions,

1. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Geography. Return them as a Python dictionary, with concise answers (3-5 words).

2. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with History. Return them as a Python dictionary, with concise answers (3-5 words).

3. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Science. Return them as a Python dictionary, with concise answers (3-5 words).

4. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Technology. Return them as a Python dictionary, with concise answers (3-5 words).

5. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Mathematics. Return them as a Python dictionary, with concise answers (3-5 words).

6. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Culture and Arts. Return them as a Python dictionary, with concise answers (3-5 words).

7. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Sports. Return them as a Python dictionary, with concise answers (3-5 words).

8. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Politics. Return them as a Python dictionary, with concise answers (3-5 words).

9. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Language and Grammar. Return them as a Python dictionary, with concise answers (3-5 words).

10. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Current Affairs. Return them as a Python dictionary, with concise answers (3-5 words).

11. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Entertainment. Return them as a Python dictionary, with concise answers (3-5 words).

12. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Medicine and Health. Return them as a Python dictionary, with concise answers (3-5 words).

13. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Economics and Business. Return them as a Python dictionary, with concise answers (3-5 words).

14. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with Religion and Mythology. Return them as a Python dictionary, with concise answers (3-5 words).

15. Generate 100 Q&A pairs for LLM factual retrieval testing. The question topic should be related with General Knowledge. Return them as a Python dictionary, with concise answers (3-5 words).

### A.9 Qualitative Comparison with Other LLMs

Here, we show more qualitative comparison between Llama3-8B SFT on ToolBridge and GPT-4o and Gemini.

Figure: Figure 6: Qualitative comparison with GPT-4o and Gemini.
Refer to caption: x6.png

## Peer Reviews

confidence: 3
contribution: 2
initial_rating: 5
presentation: 3
questions: 1. Why not use more coding-focused base models?
2. Is it possible to include some dedicated tool use benchmarks?
3. Why use WebQA and FACT for evaluation? Is the purpose to test the ability to use search tools?
4. Is all methods evaluated use the same prompt and tool use support? Since the baselines are not tuned for the specific format, how often do they use the tools, or write code. Some more detail on the experiment setup could help understand the improvement on tool_use as separated from just encouraging tool use under the specific format.
soundness: 2
strengths: 1. The authors effectively assemble a large and diverse collection of existing datasets. Drawing from various sources, they create a robust dataset pool that enhances the relevance and generalizability of ToolBridge for training language models.

2. The pipeline for data conversion, validation, and tool invocation is meticulously designed, reflecting significant effort. The authors provide transparency in each step of the process, from dataset sampling to code generation and consistency checks, making it easier for the community to use.
summary: The paper presents a novel post-training dataset, ToolBridge, aimed at enhancing the external tool usage capabilities of LLMs.

1. The authors consolidate a broad set of open-access datasets to form a comprehensive dataset pool. This pool undergoes a systematic process that includes sampling, code generation, and consistency validation to identify entries suitable for tool invocation.

2. The ToolBridge pipeline features three key phases—selection, conversion, and filtering. Entries are reformatted, enriched with Python code snippets by GPT-4 for tool calls, and subsequently validated to ensure the consistency of execution results with the corresponding responses.

3. The authors conducted experiments using both standard math and QA benchmarks as well as custom benchmarks. Results show consistent improvements over the base model after SFT with ToolBridge.
weaknesses: 1. The authors rely entirely on ensembling existing datasets, limiting their contribution's novelty and scope. This also makes the pipeline depend on pre-existing collections of instruction following/post-training data, and cannot be derived from natural data on the web.

2. The pipeline primarily modifies existing data by inserting Python-based tool calls. it should consider including stronger baseline models that focus more on coding tasks, such as Code Llama. 

3. The evaluation raises questions, particularly in relation to benchmark selection. Since the dataset is targeted at tool use, it would be more appropriate to evaluate with dedicated tool-use benchmarks. Additionally, the performance gaps between ToolBridge and ToolBridge* (a variant without tool calls) on standard benchmarks are small, which brings concern of how much extra value is added through the pipeline rather than the underlying SFT data from existing works.

4. While the model shows greater improvement on custom datasets, these evaluations raise concerns. The RandomQA dataset is mostly template-generated, and the FACT dataset is generated by GPT-4. Given that much of ToolBridge data also originates from GPT-4, this could introduce potential biases.

---

confidence: 3
contribution: 3
initial_rating: 6
presentation: 2
questions: Why do you run Llama 3 70B filtering twice (once in line 187, and once in line 206)? Why not just run it once over all datasets? 

How did you conduct your review of SFT datasets to finalize the ones you include in Table 1? That is, how did you ensure that it was sufficiently “comprehensive” as you say? 

For the random sampling done in line 187, how many examples did you sample to make $\mathcal{S}_i$ for each dataset? 

Line 196: What is $N$ and how did you determine what this value would be for each dataset?

Are there any substantive differences between the three different batches of the FACT benchmark? That is, why is performance reported for each batch instead of aggregating performance across them?
soundness: 3
strengths: The authors do a good job of motivating the purpose of their contribution, which emphasizes the open-source nature of their work juxtaposed against existing work.
summary: This paper introduces ToolBridge, a new dataset for finetuning models to run Python code to support the completion of data processing, numerical computation, and factual retrieval tasks. To construct this dataset, the authors begin with a pool of 13 supervised finetuning datasets. Then, they use Llama 3 70B to filter for dataset examples that can make use of external tool use, and use GPT-4o-mini to create the Python code that invokes external tools. They show that by finetuning on ToolBridge, models can improve task performance.
weaknesses: Some details for assessing the quality of this dataset and the quality of their data curation pipeline are missing. For instance, how well does Llama3-70B select “valuable” data entries (3.2) (e.g. false positive, false negative rates)? Did you experiment with other prompts for selecting data, and if so, how did you decide on your final prompt? Generally, it would be good to get some sense of what it means for a data entry to be “valuable” or suitable for tool use, and how you selected the few-shot examples in the prompts you provide. 

The authors’ data and experiments are essentially a case study of model distillation. That is, they use potentially stronger models (Llama-3-70B, GPT-4o-mini) to create data for weaker ones (Llama-3-8B, Llama-2-7B). It would be more interesting to see how data generated by strong models can improve their own performance. 

The authors could also provide more information on the composition of their dataset. They provide some examples of Python packages involved, but which ones are most common and what does the distribution look like? Approximately how many dataset examples pertain to the three key tasks of numerical calculations, factual retrieval, and data processing? It may also be useful to disaggregate RandomQA, which the authors create themselves, based on task type to show how ToolBridge may boost performance for some tasks more so than others. 

The qualitative results section in this paper is pretty lacking. It essentially just shows three examples of prompts to which Llama3-8B trained on ToolBridge answers correctly, along with other model’s responses (which are sometimes correct and sometimes not). There is no qualitative analysis present in this section; it’s just three input/output examples. These examples don’t really add much to the paper, and the models included in Figure 3 also seem a bit random, because these models are not mentioned at all among the paper’s quantitative results. To revise, I suggest that the authors do one of the following: 
- Actually conduct some qualitative analysis of results. For example, the authors could characterize what kinds of examples Llama3-8B trained on ToolBridge does best on and which ones it tends to struggle on (like the bullet list of deficiencies outlined in lines 472-481). To do this, I suggest the authors look up how to do “qualitative coding”. 
- Do not include a “qualitative results” section at all, and instead replace Figure 3 with a figure of example inputs/outputs from the four models experimented with in 4.3 and/or 4.4. 
- Keep Figure 3, but also include quantitative results in Tables 6-9 for Llama3.1-70B-IT, GPT-4, GPT-4o, and Gemma2-27B-IT. 

More minor comments: 
- Line 187: “Llama3” -> “Llama3-70B”
- Line 208: “using the Llama3-70B” -> “using Llama3-70B”
- Line 359: “four baseline models: the base model of Llama2-7B and Llama3-8B” This says “four” but names two models. 
- Line 484: “llama3-8B” -> “Llama3-8B” (to match model naming elsewhere in the paper)

---

confidence: 4
contribution: 2
initial_rating: 5
presentation: 4
questions: See weakness.
soundness: 2
strengths: 1. The paper describes a pipeline for generating tool-using data and presents a dataset (though direct access to the dataset is not provided here) to address gaps in large language model tool-usage capabilities.
2. The structured data-filtering approach introduced in this paper effectively enhances dataset quality and improves the ability of tool using(function calling).
3. The authors report that, following training on the ToolBridge dataset, the model shows improved performance in mathematical, fact and RandomQA benchmarks.
summary: This paper introduces ToolBridge, a dataset intended to enhance large language models' (LLMs) capacity for effectively employing external tools, and addressing gaps in model training. ToolBridge integrates various open-source SFT data, compiling an extensive dataset to train LLMs for some tasks that can be enhanced by using Python. The authors highlight the need for high-quality, transparent datasets specifically designed for tool integration and propose that they will release the ToolBridge dataset and data process pipeline.
weaknesses: 1. This paper restricts external tool integration to Python APIs. Although the dataset includes 63 Python packages, this selection may be limited compared to other tool-using datasets, such as ToolBench.
2. A comparison with other tool-using datasets, like ToolBench, may further clarify ToolBridge's distinct contributions.
3. The paper could benefit from a more detailed explanation of the fact-checking process. While it states that the model can request external web pages using request packages, it remains unclear whether the URLs are generated by the model, predefined, or retrieved through other methods.
4. This paper does not evaluate the factual retrieval abilities of LLM against established benchmarks but uses a self-construct dataset. There are some existing benchmarks, such as TruthfulQA or HaluEval, to assess the model's accuracy and reliability in factual responses, which may be more convincing.

---

confidence: 3
contribution: 3
initial_rating: 6
presentation: 2
questions: - What are the source datasets? Could you provide a brief description for each?
- I think RandomQA is a really good benchmark for numerical computation, but less data processing?
- Regarding the FACT, why do you prefer the current approach over using existing factual datasets and systematically processing them, for example, into a Python dictionary? I believe those datasets are typically more carefully constructed.
soundness: 3
strengths: - this paper curates a collection of datasets through a carefully designed pipeline, and I really appreciate that they made it open source. I believe it can help with the research community
- I believe RandomQA will also be useful for further research
summary: This paper introduces ToolBridge, a collection of general open-source datasets designed to equip LLMs with effective external tool usage through a carefully structured pipeline. Experimental results demonstrate that fine-tuning on ToolBridge can enhance LLM performance across many benchmarks, including new benchmarks introduced in this paper for numerical calculation, factual retrieval, and data processing.
weaknesses: - The Figure 2 needs some revision, it's not informative, suggest including the processing details in each section
- Only llama models are used in experiments. Since llama is employed in the data curation pipeline, I suggest including other open or closed models with different sizes

Meta-review: This work creates a tool use dataset by consolidating various non-too-use datasets and applying a systematic conversion process. Experiments on standard math, QA benchmarks, and custom benchmarks reveal consistent performance improvements after fine-tuning with ToolBridge.
The reviewers agree that the dataset coming from this work provides value, but all raised concern on how does this work distinguish from broader tool use scenarios and code generation. Particularly, the work lacks the experiments to demonstrate the benefits of ToolBridge on tool use benchmarks like GAIA, ToolBench and ToolCamp. As reviewer X8CW and NXYV pointed out, there is no clear distinction between tool use/function calling and ToolFormer-like approach.

Decision: Reject