# An Entity-based Claim Extraction Pipeline for
Real-world Biomedical Fact-checking

Amelie Wührl, Lara Grimminger  Roman Klinger
Institut für Maschinelle Sprachverarbeitung, University of Stuttgart, Germany
{amelie.wuehrl, lara.grimminger,
<EMAIL_ADDRESS>

###### Abstract

Existing fact-checking models for biomedical claims are typically trained on
synthetic or well-worded data and hardly transfer to social media content.
This mismatch can be mitigated by adapting the social media input to mimic the
focused nature of common training claims. To do so, Wührl and Klinger (2022a)
propose to extract concise claims based on medical entities in the text.
However, their study has two limitations: First, it relies on gold-annotated
entities. Therefore, its feasibility for a real-world application cannot be
assessed since this requires detecting relevant entities automatically.
Second, they represent claim entities with the original tokens. This
constitutes a terminology mismatch which potentially limits the fact-checking
performance. To understand both challenges, we propose a claim extraction
pipeline for medical tweets that incorporates named entity recognition and
terminology normalization via entity linking. We show that automatic NER does
lead to a performance drop in comparison to using gold annotations but the
fact-checking performance still improves considerably over inputting the
unchanged tweets. Normalizing entities to their canonical forms does, however,
not improve the performance.

##  1 Introduction

Figure 1: Overview of the claim extraction pipeline. Input documents go
through entity recognition (NER), normalization, claim candidate generation,
main claim detection and fact-checking. Colored boxes represent the entities
which we use to extract claim candidates. Note that we evaluate the
normalization module separately from the evaluation of the rest of the
pipeline (see §3).

Fact-checking models trained on synthetic, well-worded and atomic claims
struggle to transfer to colloquial content (Kim et al., 2021). There are
multiple ways to address this problem: We can build custom datasets and models
that verify medical content shared online (Saakyan et al., 2021; Mohr et al.,
2022; Sarrouti et al., 2021) and tackle related tasks (Sundriyal et al., 2022;
Dougrez-Lewis et al., 2022). Alternatively, we can adapt the input before
addressing other fact-checking tasks. Bhatnagar et al. (2022) create claim
summaries and find that this improves the detection of previously fact-checked
claims. Similarly, Wührl and Klinger (2022a) extract concise claims from user-
generated text in an effort to mimic the focused, well-structured nature of
the claims the fact-checking models were originally trained on. They find that
this improves the accuracy of pre-trained evidence-based fact-checking models
in the biomedical domain.

|  Claim |  Evidence
---|---|---
orig |  medicines causes blood clots |  drospirenone may significantly increase chances of developing venous thromboembolic events
norm |  pharmaceutical preparations causes thrombus
Table 1: Example claim represented with original and normalized entities
together with evidence.

However, the study by Wührl and Klinger (2022a) is limited in two ways: (1)
Their claim extraction method relies on gold-annotated, claim-related
entities. For a realistic evaluation, such an oracle needs to be replaced by
an entity recognizer. Only then it is possible measure the impact of potential
error propagation which may ultimately render the method unfeasible. (2) The
claim entities are represented by the original token sequence. This is
problematic as medical mentions on Twitter potentially contain imprecise,
abbreviated, or colloquial terminology. This is in contrast to the terminology
in the original model input as well as the documents that we provide as
evidence (cf. Table 1). We hypothesize that for a successful fact-check we
need to close this gap by normalizing medical terminology in the input.
Previous work suggested leveraging entity linking for evidence retrieval
(Nooralahzadeh and Øvrelid, 2018; Taniguchi et al., 2018; Hanselowski et al.,
2018) leading us to believe that it could also be beneficial for aligning
claim and evidence.

We address both limitations and evaluate a real-world, fully-automatic claim
extraction pipeline for medical tweets which incorporates an entity
recognizer. It only relies on the original text as input that contains the
claim. We further evaluate the impact of an entity linker for normalizing
entity mentions to canonical forms based on the Unified Medical Language
System (UMLS, Bodenreider, 2004). Our pipeline improves the fact-checking
performance over tasking models to check unchanged tweets. Normalizing
entities to overcome the terminology mismatch does not improve fact-checking,
potentially due to limitations of biomedical entity linking for social media.

##  2 Methods

Figure 1 visualizes our pipeline. It takes text as input and performs named
entity recognition and optionally term normalization via entity linking. Each
unique entity pair forms the building blocks for a potential claim (claim
candidate generation). The main claim detection identifies the core claim
among the candidates that presumably represents the most important aspect of
the text. The resulting claim is the input to the fact-checker. In our
setting, we assume this to be a frozen pre-trained fact-checking model. We
describe the modules in the following and the fact-checker in Section 3.2.

##### NER.

We use the SpaCy
environment111https://spacy.io/api/architectures#TransitionBasedParser to
train a custom NER model that detects medical entities. This framework relies
on a transition-based parser (Lample et al., 2016) to predict entities in the
input. In a preliminary study, we found that relying on an off-the-shelf model
for biomedical NER, i.e., ScispaCy (Neumann et al., 2019), does not transfer
to medical texts from social media. Refer to Appendix B.1 for a comparison of
the two models.

##### Claim candidate generation.

Wührl and Klinger (2022a) propose two extraction methods, i.e.,
$\textrm{condense}_{\textrm{seq}}$ and $\textrm{condense}_{\textrm{triple}}$.
The first represents the claim as the token sequence from the first entity to
the last entity, while the second relies on gold-annotated causal relations
which they use to build the claims. We use the sequence method
$\textrm{condense}_{\textrm{seq}}$ in our pipeline because both methods show
on par performances (difference in 1pp F1) and, in contrast to
$\textrm{condense}_{\textrm{triple}}$, it does not require relation
classification.

Following the $\textrm{condense}_{\textrm{seq}}$ method, we therefore extract
the sequence from the character onset of the first entity to the character
offset of the second entity for all pairs of entities found by the NER module.

##### Entity linking.

To normalize entities, we use the EntityLinking component in ScispaCy (Neumann
et al., 2019). This model compares an entity mention to concepts in an
ontology and creates a ranked list of candidates, based on an approximate
nearest neighbor search. For text normalization, we retrieve the canonical
name of the top concept. For entities which could not be linked, we use the
original mention instead. As the knowledge base, we use UMLS (Bodenreider,
2004).

##### Main claim detection.

For tweets with more than two predicted entities, claim generation produces
multiple claim candidates. To identify the claim to be passed to the fact-
checking module, we train a text classifier to detect the main claim for a
given input. We build on RoBERTArg222https://huggingface.co/chkla/roberta-
argument, a RoBERTA-based text classification model trained to label input
texts as argument or non-argument. We fine-tune this model to classify texts
as claim vs. non-claim and to fit the social media health domain. At inference
time, the claim candidate with the highest probability for the claim class
constitutes the main claim. We refer to this as ner$+$core-claim.

| Input Claim
---|---
| Gold entities |  |  |  | Fully automatic (Ours)
| $\textrm{condense}_{\textrm{seq}}$ | full tweets | ner$+$rand-ent-seq | ner$+$core-claim
model | P | R | F1 | $\Delta_{\textrm{full}}$ | P | R | F1 | P | R | F1 | $\Delta_{\textrm{full}}$ | P | R | F1 | $\Delta_{\textrm{full}}$
fever | 83.3 | 1.9 | 3.7 |  $+$3.7 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |  $+$0 | 100 | 0.4 | 0.8 |  $+$0.8
fever_sci | 87.2 | 15.5 | 26.4 |  $+$18.4 | 91.7 | 4.2 | 8.0 | 92.3 | 4.7 | 9.0 |  $+$1.0 | 82.4 | 5.6 | 10.4 |  $+$2.4
scifact | 90.9 | 7.6 | 14.0 |  $+$13.2 | 100 | 0.4 | 0.8 | 100 | 2.4 | 4.6 |  $+$3.8 | 100 | 2.4 | 4.7 |  $+$3.9
covidfact | 55.6 | 28.4 | 37.6 |  $+$29.7 | 30.8 | 4.5 | 7.9 | 53.3 | 9.4 | 16.1 |  $+$8.2 | 58.1 | 14.3 | 23.0 |  $+$15.1
healthver | 85.9 | 48.5 | 62.0 |  $+$16.8 | 82.8 | 31.1 | 45.2 | 75.6 | 23.2 | 35.5 |  $-$9.7 | 77.4 | 28.7 | 41.9 |  $-$3.3
average | 80.6 | 20.4 | 28.7 |  $+$16.3 | 61.1 | 8.0 | 12.4 | 64.2 | 7.9 | 13.0 |  $+$0.6 | 83.6 | 10.1 | 16.2 |  $+$3.8
Table 2: Performance (precision, recall and F1) of MultiVerS-based models
(fever, fever_sci, scifact, covidfact, healthver) on CoVert data. Model inputs
are the full tweets, the entity-based sequence claims
($\textrm{condense}_{\textrm{seq}}$ (Wührl and Klinger, 2022a)), and claims
from the fully automatic pipeline, ner$+$rand-ent-seq and ner$+$core-claim.
$\Delta_{\textrm{full}}$ : difference in F1 between the full tweet and
performance for the respective input claim. We report the average across all
models in the last row.

##  3 Experiments

###  3.1 Data

##### CoVert.

We use the CoVert dataset (Mohr et al., 2022) to test our pipeline. It
consists of medical tweets labeled with fact-checking verdicts (Supports,
Refutes, not enough information) and associated evidence texts. We follow the
same filtering and preprocessing as Wührl and Klinger (2022a) which leaves us
with 264 tweets. For 13 tweets, the NER model predicts only one or no
entities. In these cases, we cannot generate claim candidates thus we can only
consider 251 claims.

#####  Bear.

We require an independent dataset to train the NER component. We find the Bear
dataset (Wührl and Klinger, 2022b) to be closest in domain and text type to
the target data from CoVert. Bear provides 2100 tweets with a total of 6324
annotated medical entities from 14 entity classes. We use 80% of the data for
training and 20% for testing the model.

##### Causal Claims.

To build a classifier that identifies the core claims, we use the Causal
Claims data from SemEval-2023 Task 8, Subtask
1.333https://causalclaims.github.io/ It consists of medical Reddit posts and
provides span-level annotations for Claim, Experience, Experience based claim
and Question. Our goal is to differentiate claims from non-claims.
Consequently, we extract all spans labeled as Claim and Experience based claim
as positive instances for the claim class and use the remaining text spans as
negative examples. This leads to 1704 claim and 6870 non-claim spans. We use a
train/test split of 90/10%.

###  3.2 Evaluation

The fact-checking module serves as a by-proxy evaluation for the claim
representations. Provided with a claim–evidence pair, the system predicts a
fact-checking verdict that indicates if the evidence Supports or Refutes the
claim. We assume that the fact-checker is a frozen model for which we adapt
the claim input. To gauge the checkability of a particular input, we compare
the performance for predicting the correct verdict when the model is presented
with claims of this type. This follows the evaluation in Wührl and Klinger
(2022a).

The fact-checking models we employ stem from the MultiVerS architecture
(Wadden et al., 2022).444https://github.com/dwadden/multivers This framework
is designed for scientific fact-verification and provides five models (fever,
fever_sci, scifact, covidfact, healthver), differing in training data. We
report precision, recall and F1 for predicting the correct fact-checking
verdict (Supports, Refutes, not enough information) for a given claim-evidence
pair.

###  3.3 Exp. 1: Impact of NER

In Exp. 1, we aim to understand the impact of automatic NER and main claim
detection in the pipeline, instead of relying on gold-labeled entities.

Table 2 reports the results for our fully automatic claim extraction pipeline.
Each column reports the performance for a specific type of input claim. Full
tweets is the performance as reported by Wührl and Klinger (2022a) for the
unchanged input tweets. The results denoted with
$\textrm{condense}_{\textrm{seq}}$ describe their results with gold
annotations, to which we compare. Our main results are in the last column
(ner$+$core-claim). To understand the impact of the main claim detection, we
compare against a purely random selection of the main claim from all
candidates in the tweet (ner$+$rand-ent-seq).

The rows correspond to the various fact-checking models. $\Delta$ columns
report the difference in F1 between the performance of checking the full tweet
and the respective claim representation.

ner$+$core-claim shows an average performance of F1 =16.2. The performance
varies across the models. The healthVer model performs the best (41.9F1). The
average is considerably higher than using the full tweets ($\Delta$=3.8 pp
F1). This improvement is consistent across all models, except for healthVer,
presumably because it already shows a high performance for the original texts.
To better understand the model behavior, we provide an analysis of its
prediction in Appendix B.3. We see a particularly strong impact for the
covidfact model, with $\Delta$=15.1 pp. Despite this positive result, we see a
performance drop when integrating entity recognition instead of building claim
extraction on gold entity annotations. This decrease is not surprising since
we expect some error propagation from an imperfect entity recognizer.
Nevertheless, the results show that entity-based claim extraction also
increases the fact-checking performance even under some error propagation
throughout the real-world pipeline.

We further see that main claim detection is a required module – the
performance for a randomly selected claim (ner$+$rand-ent-seq) is
substantially lower. This indicates that using the same evidence and fact-
checking model, not all potential claims in a tweet would receive the same
verdict.

###  3.4 Exp. 2: Impact of Entity Normalization

In Exp. 2, we investigate if it is beneficial to assimilate the linguistic
realizations of medical mentions to the expected input of the fact-checking
models. More specifically, we suggest normalizing entity strings in the input.
In contrast to Exp. 1, in which we evaluate the overall pipeline, we focus on
the aspect of the entities here and therefore do not make use of the core
claim detection method or the entity recognizer. Instead we build on top of
gold annotations and, consequently, employ
$\textrm{condense}_{\textrm{triple}}$ described in Section 2.

We use entity linking for term normalization and use ScispaCy’s entity linking
functionality with en_core_sci_sm as the underlying model (Neumann et al.,
2019). For each (gold) entity, we use the canonical name of the concept with
the highest linking score. Subsequently, we follow the
$\textrm{condense}_{\textrm{triple}}$ method to represent claims.

Table 3 reports the results for claims built with non-normalized (surface
string) vs. normalized entities (normalized ent.). The results indicated as
$\textrm{condense}_{\textrm{triple}}$ surface string are analogue to the
results in Wührl and Klinger (2022a). We see that normalization does not have
the desired effect: The verdict prediction performance drops across all of the
fact-checking models (from 29.7 to 22.6 in avg. F1). We assume that this is,
to a considerable extend, due to entity linking being a challenging task which
leads to a limited performance of the employed linking module. We present an
error analysis in Appendix B.4.

|  $\textrm{condense}_{\textrm{triple}}$ Claims
---|---
| surface string | normalized ent.
model | P | R | F1 | P | R | F1
fever | 81.8 | 3.4 | 6.5 | 75.0 | 1.1 | 2.2
fever_sci | 89.8 | 20.1 | 32.8 | 93.9 | 11.7 | 20.9
scifact | 86.4 | 7.2 | 13.3 | 94.4 | 6.4 | 12.1
covidfact | 65.0 | 30.3 | 41.3 | 61.8 | 20.8 | 31.2
healthver | 79.7 | 41.7 | 54.7 | 85.7 | 31.8 | 46.4
average | 80.5 | 20.5 | 29.7 | 82.2 | 14.4 | 22.6
Table 3: Performance (precision, recall and F1) of MultiVerS-based fact-
checking models (fever, fever_sci, scifact, covidfact, healthver) on CoVert
claims built with non-normalized (surface string) vs. normalized entities. We
report the average across all models in the last row.

##  4 Conclusion & Future Work

We propose a fully automatic claim extraction pipeline that is capable of
handling real-world medical content. We show that entity-based claim
extraction has a positive effect on the performance of multiple fact-checking
models – even after replacing the entity oracle with automatic NER. While we
observe a negative impact of error propagation from NER and a performance drop
as a result, fact-checking the extracted claims is more successful than
checking unchanged tweets. Future research may therefore focus on improving
the pipeline components as this clearly has the potential to further
strengthen the verdict prediction performance. In particular, we expect an
improved entity recognizer to have a considerable impact.

Our work focuses on the biomedical domain and builds upon the assumption by
Wührl and Klinger (2022a) that claims in this domain are strongly centered
around entities. Claims from other domains may share this property which could
make entity-based claim extraction applicable for such claims as well. We
leave the evaluation for future work.

We find that normalizing entity mentions does not improve the fact-checking
performance. However, our analysis shows that the off-the-shelf linking module
might be too unreliable. To fully gauge the potential of normalizing entities,
future work needs to ensure correct mappings (creating gold links or building
a reliable linker) before evaluating the downstream fact-checking performance.

## Acknowledgments

This research has been conducted as part of the FIBISS project which is funded
by the German Research Council (DFG, project number: KL 2869/5-1). We thank
the anonymous reviewers for their valuable feedback.

## Limitations

Our work focused on evaluating the impact of putting together a set of
components to achieve a real-world system for fact-checking. For answering the
research question at hand, the components offered themselves as appropriate
choices. This being said, to some degree, the particular selection may limit
the expressiveness of the experiments.

By instantiating the pipeline components with the set of models and underlying
data that we chose, our findings are limited to this setting. However, the
analysis that we provide in Appendix B dissects the pipeline results and
allows us to draw more general conclusions about the impact of replacing
individual components.

We propose that the main claim detection receives more attention in future
research. This may mitigate the issue that this module is potentially the most
in-transparent component. Compared to the NER, this task can be modeled in
various ways. We rely on the output probabilities to identify the claim
candidate the model is most confident about. While this is a straight-forward
approach and we show that it works as intended, prediction probabilities –
especially for deep models – may not always be a distinctive indicator of
model confidence. To overcome this limitation, alternative ways of detecting
the main claim should be evaluated.

## Ethical Considerations

A real-world fact-checking pipeline presents itself as a valuable tool.
However, we advise against using the pipeline purely automatically that at
this point in time. Unless they are used hand-in-hand with a human expert
performing or supervising the fact-check, such systems are not reliable enough
yet.

Potential issues are the result of the inherent opaqueness of sophisticated
automatic analysis pipelines. In the system that we propose, it is important
that the impact of each module needs to explain itself to the user. While
there is recent work on explainability particularly in the area of fact
checking, this work did not yet focus on entity-based approaches. It is
important that a user can clearly understand which claim in a statement is
checked and which risks potential error propagation might lead to. Therefore,
before deploying such systems for fully automatic filtering or labeling of
problematic messages in a social media content, there needs to be more
research on explainability and transparency of such systems.

## References

  * Bhatnagar et al. (2022) Varad Bhatnagar, Diptesh Kanojia, and Kameswari Chebrolu. 2022.  Harnessing abstractive summarization for fact-checked claim detection.  In _Proceedings of the 29th International Conference on Computational Linguistics_ , pages 2934–2945, Gyeongju, Republic of Korea. International Committee on Computational Linguistics.
  * Bodenreider (2004) Olivier Bodenreider. 2004.  The unified medical language system (UMLS): integrating biomedical terminology.  _Nucleic Acids Research_ , 32:D267–270.
  * Dougrez-Lewis et al. (2022) John Dougrez-Lewis, Elena Kochkina, Miguel Arana-Catania, Maria Liakata, and Yulan He. 2022.  PHEMEPlus: Enriching social media rumour verification with external evidence.  In _Proceedings of the Fifth Fact Extraction and VERification Workshop (FEVER)_ , pages 49–58, Dublin, Ireland. Association for Computational Linguistics.
  * Hanselowski et al. (2018) Andreas Hanselowski, Hao Zhang, Zile Li, Daniil Sorokin, Benjamin Schiller, Claudia Schulz, and Iryna Gurevych. 2018.  UKP-athene: Multi-sentence textual entailment for claim verification.  In _Proceedings of the First Workshop on Fact Extraction and VERification (FEVER)_ , pages 103–108, Brussels, Belgium. Association for Computational Linguistics.
  * Kim et al. (2021) Byeongchang Kim, Hyunwoo Kim, Seokhee Hong, and Gunhee Kim. 2021.  How robust are fact checking systems on colloquial claims? In _Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies_ , pages 1535–1548, Online. Association for Computational Linguistics.
  * Lample et al. (2016) Guillaume Lample, Miguel Ballesteros, Sandeep Subramanian, Kazuya Kawakami, and Chris Dyer. 2016.  Neural architectures for named entity recognition.  In _Proceedings of the 2016 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies_ , pages 260–270, San Diego, California. Association for Computational Linguistics.
  * Mohr et al. (2022) Isabelle Mohr, Amelie Wührl, and Roman Klinger. 2022.  CoVERT: A corpus of fact-checked biomedical COVID-19 tweets.  In _Proceedings of the Thirteenth Language Resources and Evaluation Conference_ , pages 244–257, Marseille, France. European Language Resources Association.
  * Neumann et al. (2019) Mark Neumann, Daniel King, Iz Beltagy, and Waleed Ammar. 2019.  ScispaCy: Fast and Robust Models for Biomedical Natural Language Processing.  In _Proceedings of the 18th BioNLP Workshop and Shared Task_ , pages 319–327, Florence, Italy. Association for Computational Linguistics.
  * Nooralahzadeh and Øvrelid (2018) Farhad Nooralahzadeh and Lilja Øvrelid. 2018.  SIRIUS-LTG: An entity linking approach to fact extraction and verification.  In _Proceedings of the First Workshop on Fact Extraction and VERification (FEVER)_ , pages 119–123, Brussels, Belgium. Association for Computational Linguistics.
  * Saakyan et al. (2021) Arkadiy Saakyan, Tuhin Chakrabarty, and Smaranda Muresan. 2021.  COVID-fact: Fact extraction and verification of real-world claims on COVID-19 pandemic.  In _Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing (Volume 1: Long Papers)_ , pages 2116–2129, Online. Association for Computational Linguistics.
  * Sarrouti et al. (2021) Mourad Sarrouti, Asma Ben Abacha, Yassine Mrabet, and Dina Demner-Fushman. 2021\.  Evidence-based fact-checking of health-related claims.  In _Findings of the Association for Computational Linguistics: EMNLP 2021_ , pages 3499–3512, Punta Cana, Dominican Republic. Association for Computational Linguistics.
  * Sundriyal et al. (2022) Megha Sundriyal, Atharva Kulkarni, Vaibhav Pulastya, Md Shad Akhtar, and Tanmoy Chakraborty. 2022.  Empowering the fact-checkers! automatic identification of claim spans on twitter.  In _Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing_ , page 7701–7715, Abu Dhabi, United Arab Emirates. Association for Computational Linguistics.
  * Taniguchi et al. (2018) Motoki Taniguchi, Tomoki Taniguchi, Takumi Takahashi, Yasuhide Miura, and Tomoko Ohkuma. 2018.  Integrating entity linking and evidence ranking for fact extraction and verification.  In _Proceedings of the First Workshop on Fact Extraction and VERification (FEVER)_ , pages 124–126, Brussels, Belgium. Association for Computational Linguistics.
  * Wadden et al. (2022) David Wadden, Kyle Lo, Lucy Lu Wang, Arman Cohan, Iz Beltagy, and Hannaneh Hajishirzi. 2022.  MultiVerS: Improving scientific claim verification with weak supervision and full-document context.  In _Findings of the Association for Computational Linguistics: NAACL 2022_ , pages 61–76, Seattle, United States. Association for Computational Linguistics.
  * Wührl and Klinger (2022a) Amelie Wührl and Roman Klinger. 2022a.  Entity-based claim representation improves fact-checking of medical content in tweets.  In _Proceedings of the 9th Workshop on Argument Mining_ , pages 187–198, Online and in Gyeongju, Republic of Korea. International Conference on Computational Linguistics.
  * Wührl and Klinger (2022b) Amelie Wührl and Roman Klinger. 2022b.  Recovering patient journeys: A corpus of biomedical entities and relations on Twitter (BEAR).  In _Proceedings of the Thirteenth Language Resources and Evaluation Conference_ , pages 4439–4450, Marseille, France. European Language Resources Association.

##  Appendix A Implementation details

In the following, we provide implementation details for the individual model
components described in Section 2.

###  A.1 Named Entity Recognition

In a preliminary experiment, we use a pre-trained model for biomedical NER,
i.e., the en_core_sci_sm model by ScispaCy (Neumann et al., 2019), that was
trained on scientific, biomedical and clinical text to identify sequences of
biomedical entities. We find that the off-the-shelf model transfers poorly to
our target data which stems from social media. We provide the evaluation
results for this experiment in Appendix B.2.1. Therefore, we train a custom
NER model in spaCy on the BEAR dataset. We create an empty model using
spacy.blank() and pass the language ID “en” for English. We provide the
train/test splits and configuration file we use to train the model which
includes all settings and hyperparameters here: https://tinyurl.com/bear-ner

###  A.2 Main Claim Detection

We fine-tune RoBERTArg555https://huggingface.co/chkla/roberta-argument to
classify texts as Claim vs. non-Claim using the Causal Claim data. We create a
train-validation split of 85/15 %. We train for 5 epochs with a batch size of
16, 409 training steps per epoch, 136 warmup steps and a weight decay of 0.01.
We use the same learning rate that was used in fine-tuning the underlying
RoBERTArg model, i.e., a learning rate of 2.3102e-06. We evaluate the model
every 500 steps using the validation set. After training, we use the model
with the best performance on the validation set to make a prediction for each
claim candidate.

###  A.3 Entity linking

We use the EntityLinking component in ScispaCy (Neumann et al., 2019) and
en_core_sci_sm as the underlying model666https://allenai.github.io/scispacy/.
For each entity, the model maps the mention to the associated concept within
UMLS (Bodenreider, 2004). We include the option to resolve abbreviations and
leave the other configuration parameters at their default values.

##  Appendix B Analysis

We provide an evaluation and analyses of individual pipeline components to
better understand the capabilities of the modules.

###  B.1 Evaluation Setup

##### NER.

Entity recognition consists of two subtasks: (a) identifying the span of an
entity and (b) predicting the entity class. Consequently, we evaluate the NER
component of our pipeline in two modes. In the strict mode, the entity span
and the entity class have to be identical to the gold data. In the relaxed
mode, the entity span has to be identical to the gold data, entity class
labels is ignored.

Note that the off-the-shelf ScispaCy (Neumann et al., 2019) model that we
compare against only labels the entity span and not the entity class.
Therefore, we can only evaluate its performance in the relaxed  mode.

Further note that we need to map certain entity classes between the CoVert and
the BEAR dataset. To align CoVert with BEAR, we map Medical Condition to
med_C, Treatment to treat_therapy, and OTHER to other, respectively. The
CoVert dataset further contains the class Symptom/Side-effect, which
corresponds to the class med_C of the BEAR dataset. Therefore, we map the
class Symptom/Side-effect to the class med_C. Entities which have been labeled
in Bear, but not in CoVert, are ignored for the evaluation.

We report the macro-average of precision, recall and F1 for both modes.

##### Main claim detection.

We evaluate the prediction of the model on the held-out test set from the
Causal claim data. We report precision, recall and F1 for both classes (Claim
vs. non-claim) the as well as the macro-average.

###  B.2 Results

####  B.2.1 NER

We evaluate the performance of the NER component within our pipeline. Table 4
reports the results for the strict and relaxed evaluation mode. First, we
evaluate the performance on the unseen test split of the Bear data – the
dataset we use for training the model. To gauge how well it transfers to our
target data, we evaluate the performance for the entity predictions in CoVert.
We compare the performance of our custom model to the performance of the pre-
trained ScispaCy model.

For the Bear data, our model reaches an average F1 of 0.41 for the strict
evaluation mode. Note that in this mode only exact span and entity type
matches count as true positives. If we relax this condition and disregard the
entity type, the model achieves an F1-score of 0.51. When moving to a slightly
different type of input text, i.e., the CoVert data, the average F1-scores for
the strict and relaxed evaluation modes reach 0.34 and 0.38, respectively.

Compared to our custom model, the performance of the off-the-shelf model from
ScispaCy is much lower. For the relaxed mode, we observe a $\Delta$ in F1 of
0.21 and 0.12 for the Bear and CoVert data, respectively. This showcases the
necessity of a customized model for NER in this setting.

Overall, this evaluation of the entity recognition shows moderate performance.
Importantly, the results also indicate that improving this component is likely
to improve the overall fact-checking performance.

|  | target data
---|---|---
|  | BEAR |  CoVert
model | eval. mode | P | R | F1 | P | R | F1
ScispaCy | strict | - | - | - | - | - | -
relaxed | .2 | .61 | .3 | .16 | .72 | .26
Ours | strict | .46 | .37 | .41 | .26 | .51 | .34
relaxed | .56 | .46 | .51 | .29 | .57 | .38
Table 4: Evaluation of our NER module for the test split of the BEAR dataset
and the CoVert data. We report the macro average precision (P), recall (R) and
F1 across all entity classes. We report results for a strict and a relaxed
evaluation mode. We compare against the performance of an off-the-shelf
ScispaCy (Neumann et al., 2019) model (en_core_sci_sm). This model only labels
the entity span, not the entity class. Therefore, we only evaluate in the
relaxed mode.

####  B.2.2 Main claim detection

We evaluate the performance of the claim detection model on the held-out test
set. We report the results in Table 5. We can see that the model successfully
differentiates claims from non-claims (F1-scores of 0.94 and 0.99,
respectively).

class | P | R | F1
---|---|---|---
Non-claim | 0.98 | 0.99 | 0.99
Claim | 0.95 | 0.93 | 0.94
macro av. | 0.97 | 0.96 | 0.96
Table 5: Performance (precision (P), recall (R), F1) of the claim detection
model for Causal claims test set.

###  B.3 Analysis of healthver prediction

We want to understand why the healthver model behaves unexpectedly compared to
the other models (refer to Table 2). We saw that providing the automatically
extracted claim leads to a slight performance decrease compared to inputting
the full tweet, while the claims extracted using gold entities were more
successfully checked. We hypothesize that for this model, the automatic
extraction either removed relevant pieces of the input that it relied on
previously for a successful prediction or it may have introduced irrelevant
noise. Therefore, we compare the predictions of this model for our ner$+$core-
claim inputs to the claims built on gold-labeled entities
$\textrm{condense}_{\textrm{seq}}$. Note that we compare the predictions which
are not necessarily in line with the gold label.

##### Label distribution.

Table 6 reports the distribution of predicted labels for both input types. The
NEI class increases substantially (115 to 158 predicted instances) while
Support and refute become less frequent. This indicates that the claims become
less checkable as Nei means a lack of information to support or refute the
claim.

##### Label flips.

To better understand which instances cause the model to predict a different
verdict, we present the number of label transitions between the predictions
for the gold-labeled entity claims and the predictions for our pipeline claims
(ner$+$core-claim) in Table 7. From those results we can observe that for a
substantial amount of instances (161) the predicted label actually does not
shift. For 90 instances, we observe a label shift.

Most notably, claims that were supported and refuted when inputting the gold-
entity claims, get classified as Nei when we input our extracted claims (46
and 18, respectively). In an introspection of this transition type, we observe
that in cases, the automatic pipeline failed to detect the main claim,
potentially rendering the evidence useless. Refer to Claims 3 and 4 in Table 7
for examples.

Flipped verdicts (Supports to refutes or vice versa) are less frequent. We
observe a total of 11 instances. Refer to Claims 1 and 2 in Table 7.

We observe 15 cases in which the label flips to the correct gold label when we
input our claim as opposed to the gold-entity-based claim. In the manual
introspection, we observe many cases in which the claim from the pipeline
slightly extends the context compared to the gold entity claim. Refer to
Claims 5 and 6 in Table 7 for two examples.

For cases with consistent labels, we find that many instances either are
identical to the claim extracted using gold entities (see Table 7, Example 7a)
or only small amounts of context is added (see Table 7, Ex. 8).

This being said, we also observe cases in which the gold-entity and our
predicted claim do not overlap and yet, the verdict stays consistent (Ex. 7b).
This emphasizes the need to further improve the main claim detection step and
leads us to hypothesize that this module may be another reason for the limited
performance of this model. It appears that the healthver model is particularly
sensitive to this component being somewhat unreliable and error propagation in
general.

| # Predicted labels
---|---
input claim | Support | Refute | NEI
gold entities | 110 | 39 | 115
ner$+$core-claim | 69 | 24 | 158
Table 6: Labels predicted by the healthver model for claims extracted using $\textrm{condense}_{\textrm{seq}}$ based on gold entities and our pipeline (ner$+$core-claim). Note that there are 13 claims more in the gold-entity setting compared to ner$+$core-claim inputs. These are cases for which the NER module predicted $\leq 1$ entity. |  |  | example
---|---|---|---
id | transition | # inst. |  gold-ent-claim |  ner$+$core-claim | gold
1 | S-R | 7 |  Oral contraceptives cause more blood clots |  blood clots and nobody is doing anything about that!!! Like 1 per 1,000 compared to basically 1 per MILLION with the Covid vaccine | S
2 | R-S | 4 |  COVID-19 vaccines can cause side effects |  Vaccine reactions are rare. Info about side effects | S
3 | S-NEI | 46 |  COVID-19 1) directly causes viral pneumonia |  pneumonia 3) can result in intubation | S
4 | R-NEI | 18 |  5G causes covid |  vaccines cause infertility & autism | R
5 | NEI-S | 12 |  live virus that causes covid-19 |  vaccines don’t use the live virus that causes covid-19 | S
6 | NEI-R | 3 |  masks cause plague |  masks cause plague… fauci knows… masks promote bacteria… and not the good kind… sinus | R
7a | S-S | 53 |  covid vaccine doesn’t cause fertility issues |  covid vaccine doesn’t cause fertility issues | S
7b | S-S |  all brands of the vaccine can cause problems |  death rate of COVID is said to be 10%. It is probable that some vaccines | S
8 | R-R | 14 |  Wearing a mask does cause disease |  Wearing a mask does cause disease, harm the immune system | R
9 | NEI-NEI | 94 |  Auto-Immune disease causes the white blood cells that normally protect your body from invaders to turn around and attack your cells, tissues and organs |  Auto-Immune disease causes the white blood cells that normally protect your body | S
Table 7: Label transitions as predicted by the healthver model for claims
extracted using $\textrm{condense}_{\textrm{seq}}$ based on gold entities
(gold-ent-claim) and our pipeline (ner$+$core-claim). We provide example
instances for each type of label transitions along with the gold label for the
fact-checking verdict.

###  B.4 Entity Linking

##### Number of established mappings.

There are no gold annotated mappings for the medical entities in the CoVert
dataset that would allow for a full evaluation. We therefore approximate one
aspect of the quality of the entity linking module by analyzing the number of
entities that are being linked to any concept in the first place. Out of 719
entity mentions the linking module established mappings for 495 instances
(68.8 %). We provide insights from an error analysis in the following section.

##### Error analysis.

We aim to understand the type of error patterns introduced by the entity
linking module. We analyze predicted links for a randomly drawn sample of 25
entities. We manually categorize the predicted concepts with regard to four
properties. Table 8 reports the results as well as examples. correctly linked
instances are mapped to the appropriate concept within UMLS. Incorrect but
related link include instances which are mapped incorrectly, but the concept
is related. incorrect and unrelated link include cases in which the linking is
incorrect and also unrelated.

The analysis shows that the majority of mentions are linked to the correct (15
out of 25 instances) or at least a related (6 out of 25 instances) UMLS
concept. Four instances within our sample were mapped to an unrelated UMLS
concept.

While the majority of cases within our sample are normalized correctly, this
module potentially introduces many errors. Note that as pointed out before
about 30 % of entities are not linked and consequently not replaced at all. In
addition, an incorrectly mapped and replaced mention, even if the concept
might be closely related, may change the meaning of a claim drastically. Take
the following example claim: ‘COVID cause of breathlessness’. While
breathlessness is correctly mapped to dyspnea, COVID is linked to and
subsequently replaced by an unrelated concept: ‘Covi Anxiety Scale Clinical
Classification cause of dyspnea’. This leads us to believe that the
unreliability of the linking module is the main reason why the verdict
prediction performance for the normalized claims is comparably low.

error type | # |  mention |  pred. concept
---|---|---|---
correctly linked | 15 |  glandular fever |  Infectious Mononucleosis
incorr., related | 6 |  fibro flare |  Fibromyalgia
incorr. & unrelated | 4 |  COVID |  Covi Anxiety Scale […]
Table 8: Number of error types within a sample of 25 entities along with
examples.


#  ToolVerifier: Generalization to New Tools via Self-Verification

Dheeraj Mekala∗,♢,♠, Jason Weston♢, Jack Lanchantin♢,
Roberta Raileanu♢, Maria Lomeli♢, Jingbo Shang♠, Jane Dwivedi-Yu♢
♢ Meta ♠ University of California San Diego

###### Abstract

Teaching language models to use tools is an important milestone towards
building general assistants, but remains an open problem. While there has been
significant progress on learning to use specific tools via fine-tuning,
language models still struggle with learning how to robustly use new tools
from only a few demonstrations. In this work we introduce a self-verification
method which distinguishes between close candidates by self-asking contrastive
questions during (1) tool selection; and (2) parameter generation. We
construct synthetic, high-quality, self-generated data for this goal using
Llama-2 70B, which we intend to release publicly. Extensive experiments on 4
tasks from the ToolBench benchmark, consisting of 17 unseen tools, demonstrate
an average improvement of 22% over few-shot baselines, even in scenarios where
the distinctions between candidate tools are finely nuanced.

††∗ Work done during an internship at Meta.

ToolVerifier: Generalization to New Tools via Self-Verification

Dheeraj Mekala∗,♢,♠, Jason Weston♢, Jack Lanchantin♢, Roberta Raileanu♢, Maria
Lomeli♢, Jingbo Shang♠, Jane Dwivedi-Yu♢ ♢ Meta ♠ University of California San
Diego

##  1 Introduction

Incorporating external tools into large language models (LLMs) enhances their
real-world applicability Schick et al. (2023); Shen et al. (2023); Song et al.
(2023). Many tools exist in the form of APIs Xu et al. (2023b); Tang et al.
(2023); Hsieh et al. (2023); Schick et al. (2023); Qin et al. (2023), machine
learning models Shen et al. (2023); Patil et al. (2023), and other functions
Gou et al. (2023). Nevertheless, the evolving landscape of existing tools and
APIs, marked by frequent parameter updates and the daily introduction of new
tools, poses a challenge for generalization. LLMs must quickly adapt to these
changes and generalize to previously unseen tools without additional fine-
tuning or extensive human input.

Figure 1: Overview of ToolVerifier. Starting with a candidate tool list and a
user instruction, ToolVerifier initially identifies the top two tools.
Subsequently, it generates a verification question by contrasting the selected
tools and answers it. Finally, this information is appended to the context,
leading to the final tool choice. The parameter generation follows a similar
pipeline, wherein two candidate values are obtained for each parameter
(latitude in the above figure). Subsequently, the verification question is
used to finalize the parameter value.

Several recent studies enable tool usage by fine-tuning LLMs on real Schick et
al. (2023); Qin et al. (2023); Patil et al. (2023) or synthetic tools Tang et
al. (2023), equipping them to effectively utilize tools present in the
training data with a high success rate. Currently, the integration of unseen
tools into LLMs relies on providing them with few-shot demonstrations that
contain examples of user instructions and corresponding tool calls Patil et
al. (2023); Tang et al. (2023). However, these prompting-based approaches
still struggle to accurately generate a complete tool call from a set of
unseen tools. Moreover, this is often bottlenecked by the context length of
the model, particularly when including demonstrations for a large number of
tools.

To address these challenges, we propose ToolVerifier, a self-verification
method tailored for tool-use scenarios, capable of discerning between
candidate tools and their respective parameters through verification
questions. To achieve this, we decompose the tool call generation task into
two distinct sub-tasks: (1) tool selection, given a user instruction, the most
suitable tool is selected from a library of options, and (2) parameter
generation, the appropriate parameters for the selected tool are then
generated. Crucially, we propose verification for each sub-task, to both
improve sensitivity and to curb error propagation. Figure 1 shows an overview
of each sub-task.

In the tool selection stage, our model must choose one tool among multiple
options, given only the description of the tool. This stage forgoes including
demonstrations, thereby significantly reducing the required context length and
allowing us to select from a larger set of tools. To facilitate learning how
to choose the appropriate tool, we curate a high-quality, model-generated,
synthetic training dataset containing tools, their descriptions, and user
instructions. This dataset comprises 173 synthetic tools with corresponding
descriptions, 555 samples in total, each involving reasoning about the tool’s
usage. We then use this dataset to fine-tune a Llama-2 70B model Touvron et
al. (2023b) to select the correct tool for an instruction given only a set of
tool names and their descriptions, allowing the model at test time to select
from tools never seen during training. After the tool is selected, parameters
are generated for the selected tool call, which is achieved through few-shot
prompting with demonstrations corresponding to the chosen tool.

Self-verification is used at each step to reduce error propagation and enhance
overall performance. As shown in Figure 1, for tool selection verification, we
extract the top two predictions from the fine-tuned model. A verification
question is then generated contrasting the two options via 0-shot prompting,
enabling the model to focus on a fine-grained decision where the answer aids
in selecting one tool from the top two predictions. The model answers the
question, and the context is updated by appending this answer to the user
instruction, to guide tool selection. A similar approach is adopted for
verifying the parameter generation.

We evaluate our approach on 4 tasks from the publicly available ToolBench
benchmark which tests generalization to 17 unseen real-life APIs. ToolVerifier
demonstrates a noteworthy 22% improvement over few-shot prompting baselines.
The proposed self-verification mechanism contributes an improvement of 8%,
underscoring its pivotal role in boosting overall performance.

##  2 ToolVerifier

ToolVerifier chooses and calls a tool given a user instruction. It consists of
the following steps:

  1. 1.

Tool selection & verification – selecting the tool from a library of tools.

  2. 2.

Parameter generation & verification – generating the parameters for the tool
call.

For step (1) we generate synthetic data consisting of a library of tools,
(instruction, tool) pairs, and reasoning notes explaining the correct choice
of tool, see Figure 2. Fine-tuning on this data provides improved tool
selection performance, even on new sets of tools. The selection process is
then refined by verifying the choice between the top two competing choices by
asking and answering contrastive verification questions, see Figure 3.

For step (2) we use few-shot prompting given demonstrations of the actual
tool. We again verify two competing likely generations.

###  2.1 Tool Selection Dataset Generation

Our first goal is to train a language model capable of selecting an
appropriate tool for a given user instruction by reasoning about a candidate
list of tools solely based on their names and descriptions. We intentionally
exclude demonstrations for tool selection in our approach to handle a larger
set of tools in one go, using only their names and descriptions. In this
section, we elaborate on the process of creating the training dataset for
training such a tool selection language model.

Since the primary objective in this step is to select the correct tool (but
not execute the tool call), synthetically generated tools and their
corresponding descriptions can easily be used in this setting, as we do not
require their actual inner workings (in order to execute them). In our
generated dataset, each training sample is thus composed of a user
instruction, a candidate set of tools that includes the ground truth tool, and
a reasoning note elucidating the correct choice of tool. An illustrative
training sample is given in Figure 2.

User: While I was coming back home from the office, I saw a kid in Audi Q7.
Where can I buy this car within 10 miles? Tool Choices: • CarLocator: Lists
car dealers given price range. • BankAccount: Creates a bank account in a
bank. • CarFinder: Finds dealers given car model and radius. •
CurrentWeatherCity: Current weather given city. • …[more choices] …

Thought: Since I need to find the car within 10 miles, “Car Finder” tool seems
to be the right choice here. I need to use this tool. Act:
CALLTOOL[CarFinder()]

Figure 2: Illustrative training example from our synthetically constructed
tool selection dataset ToolSelect. Given a user instruction and a set of tools
to choose from, the output consists of reasoning notes (“Thought”) and the
final tool selection (“Act”).

####  2.1.1 Synthetic Tool Library Generation

##### Generation Procedure

We generate a set of synthetic tools along with their corresponding
descriptions, which are used to build the training examples. We start by first
manually annotating a “seed set” of eight tools and their descriptions.
Subsequently, we employ the Llama-65B Touvron et al. (2023a) model to generate
additional tools using few-shot prompting with the manually annotated tools
(specified in Appendix A.1.1). This process then involves multiple iterations
of prompting with different random seeds, where the tools generated in each
iteration are integrated into the prompt for subsequent iterations to generate
more diverse tools. Specifically, in each iteration, for every newly
introduced tool, we identify the most similar tool in the prompt based on
cosine similarity using RoBERTa sentence similarity Reimers and Gurevych
(2019). We replace the most similar tool in the prompt with the new addition,
ensuring a balanced diversity of tools in the prompt. Using this iterative
approach, we generate a total of 60 tools.111These tools were manually
reviewed, and 7 duplicates were removed. It is noteworthy to highlight that
this process yields a diverse set of tools from various domains including
travel, banking, and calendar, with almost no manual effort.

I am confused to choose one of these two classes. Here are their names and
descriptions: a CarLocator - Lists car dealers given price range. b CarFinder:
Finds dealers given car model and radius. A contrastive question is a question
that upon asking would resolve such confusion. Generate a contrastive question
that I can ask myself whose answer would help me make the right choice.

Verification Question: What is the primary purpose of the class I need? Is it
to find a car dealership based on a specific car model and location
(CarFinder), or is it to list car dealerships within a given price range
(CarLocator)?

Figure 3: Verification method for tool selection: a constrastive question is
generated that can then be answered to help discern among the top two
predicted tools.

##### Generating Challenging Tool Sets

In generating these synthetic tools, we endeavor to have a tool set that is
diverse, but also sufficiently challenging. An overly simplistic training set
would contain only easy choices (e.g., a weather tool versus an email tool)
and this would impede the model’s ability to generalize to challenging
instances during test time. To address this, we generate two related tools for
each of our previously generated 60 tools. Related tools are defined as tools
closely resembling a given tool but differing in either functionality or
parameters. For instance, “Bank account for a person name ” and “Bank account
for an account number” are related tools. We use only the tool names, and not
the descriptions, for generating related tools. After manually annotating
related tools for our seed set of eight tools, we generate two related tools
for each of the remaining tools with few-shot prompting with these examples,
as indicated in Appendix A.1.3.

Finally, after manual inspection and curation, our dataset contains a total of
173 tools.

####  2.1.2 Generating Training Examples

Using the generated tool library, we can now generate training examples for
our tool selection dataset. This requires generating inputs (instructions),
curating candidate lists of tools, and generating outputs (reasoning notes
that explain which tools should be selected, and actions to call those tools).

##### Generating Instructions

We first manually annotate three instructions per tool for the seed set of
eight tools. Using these examples, we generate three instructions per tool for
all remaining tools by few-shot prompting Llama-2 70B.

##### Curating Candidate List of Tools

For each generated instruction, a candidate list of tools is created by
randomly selecting 7 tools and adding the original ground truth tool for which
we generated the instruction. To introduce complexity, for a subset of the
training set, we deliberately create challenging samples by restricting the
candidate set to include only the ground truth tool and its related tools.
This deliberate selection aims to increase the difficulty level, as
distinguishing among these options is inherently more challenging than with
randomly selected tools from the entire set.

##### Generating Target Outputs

After generating the set of instructions along with their respective ground
truth tool and a candidate list of tools, we create a reasoning note for each
sample elucidating the rationale behind the selection of the ground truth
tool, which becomes the target output for that training example (see Figure
2). Such reasoning notes have been observed to enhance reasoning abilities Wei
et al. (2022); Yao et al. (2022); Lanchantin et al. (2023). Reasoning note
generation is accomplished by prompting Llama-2-Chat-70B with the instruction,
list of tools, and the ground truth tool, and asking the model why the tool
was chosen. The exact prompt used is provided in Appendix A.1.2.

Our final dataset, called ToolSelect, thus contains 555 samples for our 173
tools, of which 75 samples are hard examples, featuring candidate tool sets
that contain only the ground truth tool and its related tools.222The data was
manually reviewed, and 56 noisy and duplicate samples were removed. The
average number of candidate tools per instruction is 7.34 with minimum and
maximum number of candidate tools being 2 and 8. The average length of a
reasoning note is 1054 characters. The goal of this dataset is to enable
generalization capabilities to a wide range of possible tools and tool
libraries, and thus to demonstrate effectiveness across diverse scenarios.

####  2.1.3 Tool Selection Verification

Despite our model being fine-tuned on the above dataset, tool selection
mistakes can still happen, particularly for related tools that are hard to
differentiate. Crucially, we observe that those tool selection predictions
typically appear as the top few predictions – but selection between them is
challenging.

At inference time, we thus perform the following procedure. Given an
instruction:

  * •

First, we use the fine-tuned tool selection model to zero-shot select a tool.

  * •

We then remove the initially selected tool from the candidate set of tools,
and generate a second prediction.

  * •

We construct a verification question to make a fine-grained decision between
the model’s top two selections.

We employ Llama-2-Chat-70B to generate a contrastive verification question,
where the prompt asks the model to ask a question that emphasizes the
distinctions between candidate tools given their names and descriptions (see
Appendix A.1.4 for the exact prompt used and Figure 3 for an instantiation of
it). Self-asking the model regarding its predictions has been noted to reduce
hallucinations Press et al. (2022); Dhuliawala et al. (2023), suggesting that
posing such verification questions could assist the model in validating its
predictions. Since only names and descriptions are used for generating
contrastive questions, they can be generated offline and utilized as needed to
make the method more efficient. The answers to these contrastive questions are
obtained by further prompting Llama-2-Chat-70B, and these are appended to the
context. Finally, we select the tool by using our fine-tuned Llama-2 70B
model, with the top-two tools as candidates. As the verification answer to the
question is in the context this can help it select the right tool.

####  2.1.4 Parameter Generation & Verification

##### Parameter Generation

Following tool selection, we generate parameters for the selected tool through
few-shot prompting with Llama-2 70B, utilizing demonstrations specific to the
selected tool, which are assumed to be provided. Note that we do not use our
synthetic tool selection dataset for parameter generation since the dataset
does not contain this subtask. This procedure is only done with real tools at
inference time, without prior finetuning.

##### Parameter Verification

The generated parameters are then subjected to verification before finalizing
the set, resulting in the final tool call. To validate the generated
parameters, we obtain a second set of parameter predictions. These can be
acquired using sampling or an alternative model for diverse options; in our
experiments, we employ few-shot prompting with Llama-2-Chat-70B to obtain
them. Then, for each individual parameter, we formulate a multiple-choice
question to contrast the two predictions and further prime Llama-2-Chat-70B to
make a definitive choice between them, providing the parameter description and
user instruction as indicated in Appendix A.1.5. The final parameter
predictions are then aggregated to construct the tool call by few-shot
prompting Llama-2 70B as in Appendix A.1.7.

##  3 Experiments

Method | Weather | Booking | Home | Cat | Average
---|---|---|---|---|---
Tool-Augmented LLMs |  |  |  |  |
ToolLLM 7B | $27$ | $22$ | $84$ | $26$ | $38.90$
NexusRaven-V2 13B | $84$ | $93.33$ | $100$ | $98$ | $93.81$
Prompting Baselines |  |  |  |  |
Single-Step Llama-2 70B (1-shot) | $79$ | $43.30$ | $100$ | 98 | $78.32$
Two-Step Llama-2 70B (1-shot tool selection) | $86$ | $45.00$ | $100$ | $92$ | $79.05$
Two-Step Llama-2-Chat-70B (0-shot tool selection) | $83$ | $75.80$ | $99$ | $97$ | $88.09$
ToolVerifier (without verification) | $82$ | $98.33$ | $100$ | $96$ | $94.28$
ToolVerifier (tool selection verification) | 91 | 98.33 | 100 | $97$ | 96.67

Table 1: Tool selection results. We report accuracy in percentage (%) for each
task. Our fine-tuned Llama-2 70B model ToolVerifier, even without
verification, demonstrates superior performance compared to prompting-based
baselines, with a higher average performance. Our proposed tool selection
verification mechanism contributes another 2.5% improvement in accuracy on
average.

Method | Weather | Booking | Home | Cat | Average
---|---|---|---|---|---
Tool-Augmented LLMs |  |  |  |  |
ToolLLM 7B | $18$ | $0$ | $0$ | $11$ | $6.90$
NexusRaven-V2 13B | $55$ | $27.50$ | $43$ | $82$ | $50.71$
Prompting Baselines |  |  |  |  |
Single-Step Llama-2 70B (1-shot) | $70$ | $7.50$ | $85$ | $83$ | $58.81$
Two-Step Llama-2 70B (1-shot tool selection) | $80$ | $34.17$ | $85$ | $78$ | $67.62$
Two-Step Llama-2-Chat-70B (0-shot tool selection) | $77$ | $64.17$ | $84$ | $83$ | $76.43$
ToolVerifier (without verification) | $76$ | $82.50$ | $85$ | $82$ | $81.43$
ToolVerifier (tool selection verification only) | $84$ | $82.50$ | $85$ | $83$ | $83.57$
ToolVerifier (param selection verification only) | $81$ | $84.17$ | $88$ | $96$ | $87.14$
ToolVerifier (tool verification+param verification) | 90 | 84.17 | 88 | 97 | 89.52

Table 2: Tool call (tool selection + parameter generation) results. We report
percentage (%) success rate for each task. Our fine-tuned Llama-2 70B model
ToolVerifier, even without verification, results in higher performance
compared to the baselines. Our proposed verification mechanism further
improves the success rate by 8 points – with both types of verification, for
tool and parameter selection, each giving a separate boost in performance.

In our experiments, we assess the effectiveness of our method using publicly
available real-life tools.

###  3.1 Tasks

We evaluate our proposed method on four tool-calling tasks: Weather, Cat, Home
and Booking from ToolBench Xu et al. (2023b). The Weather and Cat tasks
involve using the REST API to interact with the OpenWeather and Cat (images
and breeds) websites, respectively. The Home and Booking tasks entail home
search and travel booking, respectively. The Weather, Home, and Cat tasks each
comprise 100 evaluation samples, while the Booking task contains 120 samples.
Each task includes API documentation, parameter descriptions, user
instructions, and the corresponding ground truth API call pairs.

For each task, there can be more than one available tool, where the entire
benchmark consists of a total of 17 tools. However, instead of evaluating each
task individually, we make it more challenging by pooling together all
available tools. In other words, for each user instruction, the model is
provided a candidate list of 17 tools. We follow the evaluation protocol set
by the benchmark and use success rate as the metric, where the success rate of
a predicted tool call is 1 if its API response exactly matches the response
from the ground truth API call.

###  3.2 Baselines

We conduct a comparison with various tool-augmented LLMs and prompting
baselines using Llama-2 70B or Llama-2-Chat-70B. Specifically, for tool-
augmented LLMs, we compare with ToolLLM 7B Qin et al. (2023) and NexusRaven-V2
13B333https://nexusflow.ai/blogs/ravenv2. ToolLLM and NexusRaven-V2 utilize
API documentation to generate tool calls corresponding to a given instruction.
We also attempted comparing with ToolAlpaca Tang et al. (2023), however, it
led to context overflow.

For prompting baselines, we try two distinct approaches: (1) Single-step,
where the model is prompted directly for an API call with a single
demonstration per tool; and (2) Two-step, where we decompose the process into
tool selection and parameter generation, prompting the model individually for
each step, as in ToolVerifier.

The Single-step method uses 1-shot single demonstrations of each of the (17)
tools to accomodate the prompt within the context size.

For the Two-step method, we consider two variants for the tool selection
stage:

  * •

0-shot: We use a 0-shot prompt that asks to select from the list of tools,
without any demonstrations for tool selection. See A.1.6 for the exact prompt.

  * •

1-shot: We show one demonstration per tool: a user instruction and
corresponding tool name.

For parameter generation in the Two-Step method, we use three demonstrations
for the selected tool.

###  3.3 ToolVerifier Details and Ablations

Our model is denoted as ToolVerifier. For tool selection it uses 0-shot
prompting with Llama-2 70B fine-tuned on our synthetic ToolSelect dataset to
select two tools and finalize one through our proposed contrastive-question-
based tool verification. Subsequently, we generate two sets of parameters by
prompting both Llama-2 70B and Llama-2-Chat-70B with three demonstrations
each, and finalize the parameter set using our proposed parameter
verification.

We additionally compare against ablated versions of our method: with tool
selection verification only (but not parameter verification), with parameter
selection verification only (but not tool verification), and without
verification (in either stage).

###  3.4 Experimental Results

##### Tool Selection Only

We first report the performance of tool selection (choosing the tool
correctly, but without generating parameters) in Table 1. Our approach,
ToolVerifier, outperforms all baselines on average and individually across the
majority of tasks as well. ToolVerifier performs better than all compared
tool-augmented LLMs, demonstrating its superior performance. A comparative
analysis between ToolVerifier with tool selection verification and without
underscores the substantial enhancement in performance achieved through the
verification process. Specifically, in tasks such as Weather and Home, we
observe that the verification procedure not only improves performance in
specific examples of lower baseline performance, but also does not adversely
affect cases where verification may be unnecessary.

ToolVerifier (both with and without verification) shows that our zero-shot
Llama-2 70B fine-tuned on our synthetically generated dataset performs better
than other baselines, including a 0-shot Llama-2-Chat-70B, with an improvement
of up to 6 points. The average number of candidate tools per instruction in
the generated training data for tool selection is 7.34 which is notably
smaller than the 17 tools encountered during test time. This difference
underscores the generalization capability of our method, demonstrating its
effectiveness across diverse scenarios. It also surpasses Single-Step 1-shot
and Two-Step 1-shot tool baselines by a substantial margin of more than 50
points on the challenging Booking task. The performance of 1-shot baselines
reveals the difficulty in selecting the appropriate tool from an unseen set
using prompting-based approaches. In contrast, fine-tuning the model on our
synthetically generated dataset with examples of using a diverse set of tools
significantly improves tool selection accuracy at test time. Moreover, the
verification procedure further improves tool selection performance by an
additional 2.4 points on average.

##### Tool Call (Selection + Parameters)

The complete tool call performance results are presented in Table 2. Similarly
to the tool selection setting, ToolVerifier outperforms all baselines both on
average and individually across all tasks. ToolVerifier outperforms all
compared tool-augmented LLMs by a significant margin. Comparing ToolVerifier
with Single-Step 1-shot highlights the challenges in generating complete tool
calls at once, emphasizing the efficacy of the two-step decomposition. A
comparative analysis between ToolVerifier with and without parameter
verification illustrates that parameter verification significantly enhances
performance, showing improvements of up to 14 points in the Cat task and 6
points in the Weather task, leading to an average improvement of 6 points
across all tasks. Notably, both types of verification help, each giving a
separate boost, as shown by comparing the without verification results to tool
selection verification only and tool+parameter verification. These results
underscore the significance of verification in both steps for the final tool
call success.

Method | Weather | Booking | Home | Cat | Average
---|---|---|---|---|---
GPT-4${}^{\textbf{*}}$ | $93$ | 96.70 | 97 | $96$ | 95.72
GPT-3.5-Turbo${}^{\textbf{*}}$ | $90$ | $85.80$ | $80$ | $92$ | $86.90$
Llama-2 70B | $93$ | $84.17$ | $85$ | $86$ | $86.91$
Llama-2-Chat-70B | $89$ | $45$ | $91$ | $88$ | $76.67$
ToolVerifier | 99 | $85.80$ | $88$ | 100 | $92.85$

Table 3: Parameter generation results. We report success rates (%) in the
upperbound setting where the model is provided the ground truth tool
selection, and must only generate parameters. We observe our fine-tuned
Llama-2 70B model ToolVerifier outperforms Llama-2 70B and GPT-3.5-Turbo
models in the majority of tasks and on average in this setting. Results with
$*$ are taken from the Toolbench Leaderboard (Xu et al., 2023c, b).

##  4 Analysis

###  4.1 Parameter Generation Only Comparison

We additionally compare ToolVerifier in the tool selection upperbound
scenario, where the groundtruth tool selection is provided, and a model is
only required to generate parameters through three-shot prompting. Results are
given in Table 3. ToolVerifier outperforms Llama-2-Chat-70B by 16 points as
well as both Llama-2 70B and GPT-3.5-Turbo by an average of 6 points on a
majority of the tasks, with an improvement of up to 14 points compared to
Llama-2 70B in the Cat task and 8 points in the Home task compared to
GPT-3.5-Turbo. ToolVerifier also demonstrates superior performance compared to
GPT-4 on Weather and Cat tasks by 6 and 4 points, respectively. This shows
that our proposed method outperforms few-shot prompting approaches, even
compared to stronger base models.

###  4.2 Verification Question Analysis

##### Qualitative Analysis

Verification questions should ideally reference the distinguishing
characteristics between two given tools in order to best help the model
consider the differences between the two choices. This capability is
particularly crucial for closely related tools. For instance, the tools
"Forecast Air Pollution" and "Current Air Pollution" both provide air
pollution data, but for future and current times, respectively. Verification
question generation by Llama-2-Chat-70B identifies this nuanced difference and
articulates it in the verification question: Are you looking for data on the
current air pollution levels in a specific location, or do you need to
forecast the air pollution levels for a future date in that location?
Responses to such questions precisely address the identified distinction. An
example response is: "Based on what the user said, it appears that they are
looking for current air pollution data for a specific location with latitude
-24.7 and longitude -57.3. Therefore, the answer is: A. Retrieve current air
pollution data for a specific location." Inserting this response into the
context for model prediction, amplifies the selection of the appropriate tool,
guiding the model towards the correct choice.

For more distinct tools, the model captures higher level differences. For
example, for "Forecast Air Pollution" and "Get favorite cat images", the
generated question inquires about the user’s interests: Which aspect are you
more interested in: predicting environmental air quality or exploring feline
visuals?

##### Significance of Contrastive Questions

To demonstrate the significance of contrastive-question-based verification, we
conduct an experiment by zero-shot prompting Llama-2-Chat-70B to choose one
tool from the top-2 without employing a verification question. Instead, we
present the names and descriptions of the top-2 tools and frame it as a
multiple-choice question, asking Llama-2-Chat-70B to make a selection. The
prompt is mentioned in Appendix A.1.8. We experiment on the Weather task and
the accuracy of Llama-2-Chat-70B is 70% whereas the accuracy of contrastive
question-based verification is 91 %. This significant enhancement over
straightforward prompting illustrates the effectiveness of contrastive
questions.

##### Instruction-Conditioned Verification

In our proposed approach we generate verification questions using solely the
names and descriptions of the top-2 selected tools, see Figure 3. We can
compare this to conditioning on the user instruction as well, by adding it to
the prompt. Conditioning on the instruction during verification still shows
improvement over the no-verification baseline (89 versus 82). However,
prompting with the user instruction slightly decreases performance compared to
the non-user-conditioned verification, dropping accuracy from 91 to 89,
perhaps because the decision is biased to be more similar to the original top
choice being verified, which was also based on the instruction. Note if the
tool set is not too large, using only names and descriptions has the benefit
that the questions can be precomputed and cached.

Figure 4: We analyze various aspects of our synthetic ToolSelect training data
including the ordering of the candidate tool list (“No Shuffle”), difficulty
level (”No Hard Data”), and the length of reasoning notes (“Short Reasoning”).
We find samples with longer reasoning notes, difficult samples, and randomly
ordered candidate tool lists contribute to high performance (“Full Data”).

###  4.3 Synthetic Training Data Analysis

We analyze our synthetic ToolSelect training data through various ablations,
with results on tool selection for the Weather task given in Figure 4.

Challenging training samples (samples that have a candidate tool list
containing related tools to the ground truth tool, see subsubsection 2.1.1)
are found to improve generalization. To assess the impact of these challenging
samples, we remove them and train a model solely with easier samples (“No Hard
Data”). The results indicate a notable 6-point drop in performance after
excluding the hard samples, highlighting their significance.

Next, we experiment by reducing the maximum reasoning note length from 480
tokens to 200 tokens (“Short Reasoning”) and observe a significant drop in
performance, up to 19 points. Shorter reasoning texts are significantly less
helpful in guiding appropriate tool selection.

Lastly, we compare performance with different orderings of the candidate tool
list. In the “No Shuffle” scenario, the ground truth tool in the training data
is always positioned first. Implementing this ordering strategy results in a
5-point drop in performance, underscoring the significance of randomly
shuffling the candidate tool list in the training data.

###  4.4 Parameter Verification Error Analysis

In the parameter verification step, we identify a consistent pattern in errors
while answering the verification questions, predominantly involving common
sense errors where the model tends to hallucinate values instead of adhering
to the user instruction, which is also observed in Mekala et al. (2023). A
notable example of such errors occurs with the min-price parameter in Booking
tool, which signifies the minimum price the user is willing to pay for a
booking. In 5 instances out of 19 wrong predictions for the Booking task, when
the user specifies only their maximum budget, the model generates the maximum
value for the min-price parameter rather than 0. Similar errors are observed
with the min-area parameter in the Home task. In 4 instances out of 12
mistakes, when the user expresses the desire for a home given only a maximum
area, the model incorrectly predicts the mentioned value as the minimum,
instead of using 0.

##  5 Related Work

##### Self-Verification

Outside the domain of tool use, iterative improvement of the generation
capabilities of LLMs typically involves prompting an LLM to provide feedback
on given generated facts or answers and subsequently refining their outputs
Madaan et al. (2023); Shridhar et al. (2023a) which has also been shown to
reduce hallucination Dhuliawala et al. (2023). Additionally, some studies
involve the fine-tuning of custom LLMs to better accommodate feedback Yu et
al. (2023); Shridhar et al. (2023b); Zhang et al. (2023), aiming to enhance
reasoning in chain-of-thought prompting for improved downstream performance.
Lu et al. (2023) also focus on fine-tuning LLMs to effectively incorporate and
act upon such iterative feedback. In this paper, we focus on tool usage,
whereas previous works typically focus on generation. We propose a novel
contrastive verification method, specifically for tool selection and parameter
generation. Our approach contrasts the choice between selecting options,
whereas previous work typically verifies single facts or answers for
generation of responses.

##### Enabling Tool Use in LLMs

Many approaches have emerged for enabling tool usage in LLMs, involving
techniques such as few-shot prompting with tool-use demonstrations across
diverse tool categories, including APIs Qin et al. (2023); Chen et al. (2023),
machine learning models Shen et al. (2023); Patil et al. (2023), code
interpreters Gao et al. (2022); Chen et al. (2022), and mathematical functions
Gou et al. (2023). Additionally, several approaches advocate for fine-tuning
LLMs on custom-generated datasets tailored for tool usage Schick et al.
(2023); Tang et al. (2023); Parisi et al. (2022); Xu et al. (2023b); Patil et
al. (2023); Srinivasan et al. (2023). Yang et al. (2023) propose fine-tuning
on multi-modal tools. Furthermore, recent works introduce auxiliary sources
such as tool documentation Hsieh et al. (2023) and tool tokens Hao et al.
(2023) to facilitate tool usage. Despite the plethora of works focused on
enabling tool usage in LLMs, to the best of our knowledge none has explored
verification methods for this purpose. This paper aims to fill this gap by
introducing multi-step contrastive verification.

##### LLMs for Data Generation

LMs have been used for generating training data for various tasks including
text classification Mekala et al. (2021, 2022), semantic similarity Schick and
Schütze (2021), and instruction tuning Wang et al. (2022); Honovich et al.
(2022); Xu et al. (2023a); Taori et al. (2023). Several works Tang et al.
(2023); Qin et al. (2023); Tang et al. (2023); Schick et al. (2023); Patil et
al. (2023); Srinivasan et al. (2023) have employed LLMs to generate synthetic
tools or tool use examples. In this paper, we generate synthetic training data
to support our self-verification procedure.

##  6 Conclusion

In this paper, we present a generation and self-verification method for
enhancing the performance of tool calls for LLMs. This involves decomposing
the tool call generation task into two distinct sub-tasks: tool selection and
parameter generation, where we apply verification at each step. Model-
generated verification questions allow nuanced decision-making between related
tools, helping it to correct mistakes. Experimental results on four tasks from
the publicly available ToolBench benchmark demonstrate substantial
improvements using our approach.

##  7 Limitations

Our self-generated verification questions and answers are produced in a zero-
shot manner, making them effective for general-purpose tools but may
necessitate further training for niche tools. Additionally, our framework is
currently designed for single-tool-usage tasks and does not support
instructions requiring multiple or compositional tool usage.

##  8 Ethics Statement

This paper introduces a self-verification method for tool calling that
generates verification questions to aid in making accurate choices with
confidence. As such, we do not expect that the fine-tuning self-verification
process should introduce biases not already observed in the model, and we do
not anticipate any significant additional ethical concerns beyond those issues
already seen in standard systems (Weidinger et al., 2021).

##  9 Acknowledgments

The authors thank Omer Levy and Chunting Zhou for helpful discussions.

## References

  * Chen et al. (2022) Wenhu Chen, Xueguang Ma, Xinyi Wang, and William W. Cohen. 2022.  Program of thoughts prompting: Disentangling computation from reasoning for numerical reasoning tasks.  _ArXiv_ , abs/2211.12588.
  * Chen et al. (2023) Z. Chen, Kun Zhou, Beichen Zhang, Zheng Gong, Wayne Xin Zhao, and Ji rong Wen. 2023.  Chatcot: Tool-augmented chain-of-thought reasoning on chat-based large language models.  _ArXiv_ , abs/2305.14323.
  * Dhuliawala et al. (2023) Shehzaad Dhuliawala, Mojtaba Komeili, Jing Xu, Roberta Raileanu, Xian Li, Asli Celikyilmaz, and Jason Weston. 2023.  Chain-of-verification reduces hallucination in large language models.  _ArXiv_ , abs/2309.11495.
  * Gao et al. (2022) Luyu Gao, Aman Madaan, Shuyan Zhou, Uri Alon, Pengfei Liu, Yiming Yang, Jamie Callan, and Graham Neubig. 2022.  Pal: Program-aided language models.  _ArXiv_ , abs/2211.10435.
  * Gou et al. (2023) Zhibin Gou, Zhihong Shao, Yeyun Gong, Yujiu Yang, Minlie Huang, Nan Duan, Weizhu Chen, et al. 2023.  Tora: A tool-integrated reasoning agent for mathematical problem solving.  _arXiv preprint arXiv:2309.17452_.
  * Hao et al. (2023) Shibo Hao, Tianyang Liu, Zhen Wang, and Zhiting Hu. 2023.  Toolkengpt: Augmenting frozen language models with massive tools via tool embeddings.  _ArXiv_ , abs/2305.11554.
  * Honovich et al. (2022) Or Honovich, Thomas Scialom, Omer Levy, and Timo Schick. 2022.  Unnatural instructions: Tuning language models with (almost) no human labor.  _ArXiv_ , abs/2212.09689.
  * Hsieh et al. (2023) Cheng-Yu Hsieh, Si-An Chen, Chun-Liang Li, Yasuhisa Fujii, Alexander Ratner, Chen-Yu Lee, Ranjay Krishna, and Tomas Pfister. 2023.  Tool documentation enables zero-shot tool-usage with large language models.  _arXiv preprint arXiv:2308.00675_.
  * Lanchantin et al. (2023) Jack Lanchantin, Shubham Toshniwal, Jason Weston, Arthur Szlam, and Sainbayar Sukhbaatar. 2023.  Learning to reason and memorize with self-notes.  _arXiv preprint arXiv:2305.00833_.
  * Lu et al. (2023) Jianqiao Lu, Wanjun Zhong, Wenyong Huang, Yufei Wang, Fei Mi, Baojun Wang, Weichao Wang, Lifeng Shang, and Qun Liu. 2023.  Self: Language-driven self-evolution for large language model.  _ArXiv_ , abs/2310.00533.
  * Madaan et al. (2023) Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Sean Welleck, Bodhisattwa Prasad Majumder, Shashank Gupta, Amir Yazdanbakhsh, and Peter Clark. 2023.  Self-refine: Iterative refinement with self-feedback.  _ArXiv_ , abs/2303.17651.
  * Mekala et al. (2021) Dheeraj Mekala, Varun Gangal, and Jingbo Shang. 2021.  Coarse2Fine: Fine-grained text classification on coarsely-grained annotated data.  In _Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing_ , pages 583–594, Online and Punta Cana, Dominican Republic. Association for Computational Linguistics.
  * Mekala et al. (2022) Dheeraj Mekala, Tu Vu, Timo Schick, and Jingbo Shang. 2022.  Leveraging QA datasets to improve generative data augmentation.  In _Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing_ , pages 9737–9750, Abu Dhabi, United Arab Emirates. Association for Computational Linguistics.
  * Mekala et al. (2023) Dheeraj Mekala, Jason Wolfe, and Subhro Roy. 2023.  ZEROTOP: Zero-shot task-oriented semantic parsing using large language models.  In _Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing_ , pages 5792–5799, Singapore. Association for Computational Linguistics.
  * Parisi et al. (2022) Aaron Parisi, Yao Zhao, and Noah Fiedel. 2022.  Talm: Tool augmented language models.  _ArXiv_ , abs/2205.12255.
  * Patil et al. (2023) Shishir G. Patil, Tianjun Zhang, Xin Wang, and Joseph E. Gonzalez. 2023.  Gorilla: Large language model connected with massive apis.  _ArXiv_ , abs/2305.15334.
  * Press et al. (2022) Ofir Press, Muru Zhang, Sewon Min, Ludwig Schmidt, Noah A Smith, and Mike Lewis. 2022.  Measuring and narrowing the compositionality gap in language models.  _arXiv preprint arXiv:2210.03350_.
  * Qin et al. (2023) Yujia Qin, Shi Liang, Yining Ye, Kunlun Zhu, Lan Yan, Ya-Ting Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Runchu Tian, Ruobing Xie, Jie Zhou, Marc H. Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun. 2023.  Toolllm: Facilitating large language models to master 16000+ real-world apis.  _ArXiv_ , abs/2307.16789.
  * Reimers and Gurevych (2019) Nils Reimers and Iryna Gurevych. 2019.  Sentence-bert: Sentence embeddings using siamese bert-networks.  _arXiv preprint arXiv:1908.10084_.
  * Schick et al. (2023) Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023.  Toolformer: Language models can teach themselves to use tools.  In _Thirty-seventh Conference on Neural Information Processing Systems_.
  * Schick and Schütze (2021) Timo Schick and Hinrich Schütze. 2021.  Generating datasets with pretrained language models.  _ArXiv_ , abs/2104.07540.
  * Shen et al. (2023) Yongliang Shen, Kaitao Song, Xu Tan, Dong Sheng Li, Weiming Lu, and Yue Ting Zhuang. 2023.  Hugginggpt: Solving ai tasks with chatgpt and its friends in hugging face.  _ArXiv_ , abs/2303.17580.
  * Shridhar et al. (2023a) Kumar Shridhar, Harsh Jhamtani, Hao Fang, Benjamin Van Durme, Jason Eisner, and Patrick Xia. 2023a.  Screws: A modular framework for reasoning with revisions.  _ArXiv_ , abs/2309.13075.
  * Shridhar et al. (2023b) Kumar Shridhar, Koustuv Sinha, Andrew Cohen, Tianlu Wang, Ping Yu, Ramakanth Pasunuru, Mrinmaya Sachan, Jason Weston, and Asli Celikyilmaz. 2023b.  The art of llm refinement: Ask, refine, and trust.  _ArXiv_ , abs/2311.07961.
  * Song et al. (2023) Yifan Song, Weimin Xiong, Dawei Zhu, Cheng Li, Ke Wang, Ye Tian, and Sujian Li. 2023.  Restgpt: Connecting large language models with real-world applications via restful apis.  _arXiv preprint arXiv:2306.06624_.
  * Srinivasan et al. (2023) Venkat Krishna Srinivasan, Zhen Dong, Banghua Zhu, Brian Yu, Hanzi Mao, Damon Mosk-Aoyama, Kurt Keutzer, Jiantao Jiao, and Jian Zhang. 2023.  Nexusraven: a commercially-permissive language model for function calling.  In _NeurIPS 2023 Workshop on Instruction Tuning and Instruction Following_.
  * Tang et al. (2023) Qiaoyu Tang, Ziliang Deng, Hongyu Lin, Xianpei Han, Qiao Liang, and Le Sun. 2023.  Toolalpaca: Generalized tool learning for language models with 3000 simulated cases.  _ArXiv_ , abs/2306.05301.
  * Taori et al. (2023) Rohan Taori, Ishaan Gulrajani, Tianyi Zhang, Yann Dubois, Xuechen Li, Carlos Guestrin, Percy Liang, and Tatsunori B. Hashimoto. 2023.  Stanford alpaca: An instruction-following llama model.  https://github.com/tatsu-lab/stanford_alpaca.
  * Touvron et al. (2023a) Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, Aurelien Rodriguez, Armand Joulin, Edouard Grave, and Guillaume Lample. 2023a.  Llama: Open and efficient foundation language models.  _ArXiv_ , abs/2302.13971.
  * Touvron et al. (2023b) Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yasmine Babaei, Nikolay Bashlykov, Soumya Batra, Prajjwal Bhargava, Shruti Bhosale, et al. 2023b.  Llama 2: Open foundation and fine-tuned chat models.  _arXiv preprint arXiv:2307.09288_.
  * Wang et al. (2022) Yizhong Wang, Yeganeh Kordi, Swaroop Mishra, Alisa Liu, Noah A. Smith, Daniel Khashabi, and Hannaneh Hajishirzi. 2022.  Self-instruct: Aligning language models with self-generated instructions.  In _Annual Meeting of the Association for Computational Linguistics_.
  * Wei et al. (2022) Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022.  Chain-of-thought prompting elicits reasoning in large language models.  _Advances in Neural Information Processing Systems_ , 35:24824–24837.
  * Weidinger et al. (2021) Laura Weidinger, John Mellor, Maribeth Rauh, Conor Griffin, Jonathan Uesato, Po-Sen Huang, Myra Cheng, Mia Glaese, Borja Balle, Atoosa Kasirzadeh, et al. 2021.  Ethical and social risks of harm from language models.  _arXiv preprint arXiv:2112.04359_.
  * Xu et al. (2023a) Canwen Xu, Daya Guo, Nan Duan, and Julian McAuley. 2023a.  Baize: An open-source chat model with parameter-efficient tuning on self-chat data.  _ArXiv_ , abs/2304.01196.
  * Xu et al. (2023b) Qiantong Xu, Fenglu Hong, B. Li, Changran Hu, Zhe Chen, and Jian Zhang. 2023b.  On the tool manipulation capability of open-source large language models.  _ArXiv_ , abs/2305.16504.
  * Xu et al. (2023c) Qiantong Xu, Fenglu Hong, Bo Li, Changran Hu, Zhengyu Chen, and Jian Zhang. 2023c.  Toolbench leaderboard.  https://huggingface.co/spaces/qiantong-xu/toolbench-leaderboard.  Accessed: Feb 15 2024.
  * Yang et al. (2023) Rui Yang, Lin Song, Yanwei Li, Sijie Zhao, Yixiao Ge, Xiu Li, and Ying Shan. 2023.  Gpt4tools: Teaching large language model to use tools via self-instruction.  _ArXiv_ , abs/2305.18752.
  * Yao et al. (2022) Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2022.  React: Synergizing reasoning and acting in language models.  _arXiv preprint arXiv:2210.03629_.
  * Yu et al. (2023) Xiao Yu, Baolin Peng, Michel Galley, Jianfeng Gao, and Zhou Yu. 2023.  Teaching language models to self-improve through interactive demonstrations.  _ArXiv_ , abs/2310.13522.
  * Zhang et al. (2023) Haodi Zhang, Min Cai, Xinhe Zhang, Chen Jason Zhang, Rui Mao, and Kaishun Wu. 2023.  Self-convinced prompting: Few-shot question answering with repeated introspection.  _ArXiv_ , abs/2310.05035.

##  Appendix A Appendix

###  A.1 Prompts & Configurations

We use top-p sampling while generating with a temperature set to $0.7$.

####  A.1.1 Tool Generation

The prompt for tool generation using few-shot prompting LLaMa-65B is:

Name: Humidity Description: Computes humidity at a location on a date Name:
Trip Booking Description: Makes a travel booking Name: Currency Conversion
Description: Converts an amount from one currency to another. Name: Age
Calculator Description: Calculates the age based on a given birthdate and the
current date. Name: Search Engine Description: Searches online about a query
Name: Restaurant Finder Description: The Restaurant Finder tool finds the
restaurants based on its location, cuisine and the number of people. Name:
Movie Review Description: The Movie Review tool gets top-rated movie reviews
for a particular movie. Name: Pizza Order Description: The Pizza Order tool
orders a pizza with provided toppings and size. Name:

####  A.1.2 Reasoning Note Generation

The prompt for reasoning note generation using Llama-2-Chat-70B is:

[INST] <<SYS>> You are a helpful assistant. <</SYS>> Here are the list of
available tools: {Candidate tool list} A user said, "{instruction}". To answer
this, you found Tool "{name}" to be the most suitable than other tools.
Why?[/INST]

In the above prompt “{instruction}” denotes the user instruction and “{name}”
denotes the ground truth tool. “{Candidate tool list}” contains names and
descriptions of each tool.

####  A.1.3 Related Tools Generation

The prompt for related tool generation using few-shot prompted Llama-2 70B is:

Name1: Humidity Name2: Humidity at timezone Name3: Humidity Altitude Location
date Name1: Book Review Name2: Book Review By Date Name3: Book Review By Day
Name1: Car Rental Name2: Car Rental with insurance Name3: Car Rental with
driver Name1: {name} Name2:

In the above prompt {name} denotes the name of the tool whose related tools
are being generated. While generating multiple related tools per original
tool, we generate one related tool after another with different seeds, to
improve the diversity of the related tools.

####  A.1.4 Contrastive Question Generation

[INST] <<SYS>> You are a helpful assistant. <</SYS>> I am confused to choose
one of these two classes. Here are their names and descriptions: a. {name1} -
{description1} b. {name2} - {description2} A contrastive question is a
question that upon asking would resolve such confusion. Generate a contrastive
question that I can ask myself whose answer would help me make the right
choice.[/INST]

In the above prompt “{name1}”, “{description1}” and “{name2}”,
“{description2}” are names and descriptions of two selected tools
respectively.

####  A.1.5 Parameter Verification

[INST] <<SYS>> You are a helpful assistant. <</SYS>> A user said,
"{instruction}" parameter definition For the above user instruction, I am
confused about choosing one of these two for "{parameter name}". a.
{prediction 1} b. {prediction 2} What is the answer? Answer the following
question strictly based on what the user said above. If there is no mention,
respond with "None". If there is, select the answer from the given options and
respond with the chosen option only in square brackets []. [/INST]

In the above prompt “{instruction}” denotes the user instruction. “{parameter
name}” represents the parameter name under verification. Additionally,
“{prediction 1}”, “{prediction 2}” signify two parameter predictions obtained
from Llama-2 70B and Llama-2-Chat-70B, respectively.

####  A.1.6 0-shot Chat LLaMa-70B

[INST] <<SYS>> You are a helpful assistant. <</SYS>> Here are the list of
available tools: {Candidate tool list} A user said, "{instruction}" What tool
to use for the above instruction? Respond with just the name of the
tool[/INST]

In the above prompt “{instruction}” denotes the user instruction and
“{Candidate tool list}” contains names and descriptions of each tool.

####  A.1.7 Tool Call Construction

INS: A user says, "Please retrieve the temperature, humidity, wind, and
visibility data at place with latitude = -37.3, longitute = 1.9." lat: -37.3
lon: 1.9 units: none mode: none lang: none API: curl -X GET
’https://api.openweathermap.org/data/2.5/weather?lat=-37.3&lon=1.9&appid=API_KEY&units=none&
mode=none&lang=none’ INS: A user says, "How is the weather now in location
with longitute 125.9 and latitude 39.0? Respond in simplified Chinese with
json format and imperial units." lat: 39.0 lon: 125.9 units: imperial mode:
json lang: zh_cn API: curl -X GET
’https://api.openweathermap.org/data/2.5/weather?
lat=39.0&lon=125.9&appid=API_KEY&units=imperial &mode=json&lang=zh_cn’ INS: A
user says, "Give me a current weather report for place where longitute is
174.4 and latitude is -19.0." lat: -19.0 lon: 174.4 units: none mode: none
lang: none API: curl -X GET
’https://api.openweathermap.org/data/2.5/weather?lat=-19.0&lon=174.4&appid=API_KEY&units=none
&mode=none&lang=none’ INS: A user says, "{instruction}" {param_str} API:

In the above prompt “{instruction}” denotes the user instruction and
“{param_str}” contains parameters and their predicted values.

####  A.1.8 Significance of Contrastive Questions

An example prompt is provided below.

[INST] <<SYS>> You are a helpful assistant. <</SYS>> A user says, "Please
retrieve the temperature, humidity, wind, and visibility data for next week
with latitude = -37.3, longitute = 1.9." To address the above instruction
which one of the below tools is the most suitable? Select the answer from the
given options and respond with the chosen option ONLY in square brackets [].
A. Forecast Air Pollution = Get the future air pollution data in location with
latitude={lat}, longitude={lon} B. Forecast Weather Latitude Longitude = Get
the weather data for future in location with latitude={lat},
longitude={lon}[/INST]

###  A.2 Hyperparameters for Llama-2 70B Fine-tuning

We fine-tune Llama-2 70B for 3 epochs with a learning rate of 1e-5 with warm
up. The effective batch size is 8 and the weight decay is 0.1. We train it on
16 A100 GPUs.

###  A.3 Frequently Asked Questions

##### Why did you use LLaMa-65B for tool generation instead of Llama-2 70B?

The 70B model was not released by the time we generated tools. Hence, we used
the available 65B model.

##  Appendix B API Details

The four APIs pertaining to ToolBench are the Weather, Booking, Home, and Cat
APIs. To execute the API calls, we registered for access to the Weather and
Cat API, whereas for Home and Booking we ensured correct syntax, as proposed
in the benchmark Xu et al. (2023c).