Five Tools, Five Kinds of Help
Toolformer's five APIs are not five interchangeable features; each one supplies a different kind of missing information or computation. This chapter examines the relationship between those specialists and the tasks used to test them. The practical aim is to learn to predict which tool should help a capability gap, while also seeing why the paper's factual and arithmetic cases support a stronger conclusion than its multilingual and temporal results.
Factual retrieval and arithmetic do different work
A question-answering system, a search engine, and a calculator can all return text, but they solve different problems. The question-answering system is meant for short factoid questions. Wikipedia Search retrieves short passages about a search term. The calculator evaluates a limited set of arithmetic expressions. Toolformer succeeds only when it matches the form of the request to the responsibility of the specialist.
The question-answering case is about supplying a missing fact to a sentence that already provides the surrounding structure. A passage might say that Pittsburgh is also known by another name. The model does not need a long article about Pittsburgh; it needs a compact answer that can occupy the missing factual slot. A question such as “What other name is Pittsburgh known by?” turns the gap into an API input. The response then becomes context for the continuation. This is a different operation from asking the language model to recall the fact directly, because the fact is obtained through an explicit retrieval-and-answering system.
The paper uses Atlas, a retrieval-augmented language model fine-tuned on Natural Questions, for this role. That detail helps explain both the strength and the boundary of the result. The tool is already specialized for factoid question answering, so Toolformer is learning when to ask it and how to phrase the question, not learning factual knowledge from nothing. A strong answer depends on the question being answerable by that service and on the model placing the request where the answer belongs.
The input and output shape reinforce this division. The question is not a general request for an essay; it is an attempt to expose the fact the continuation needs. A compact answer is easier to insert into a sentence than a long explanation with several competing details. That makes the API useful when the missing information has a clear slot, but it also means the model's query wording can determine which fact the service returns. If the question asks for the wrong relation, the external system may answer faithfully while still failing the sentence.
Wikipedia Search supplies a somewhat different form of help. Instead of returning a direct answer, it returns short text snippets retrieved for a search term. The search system uses BM25 over a Wikipedia dump from the KILT collection. The model must extract the relevant part of what it receives and connect it to the sentence it is completing. Retrieval expands the amount of information available, but it also transfers more interpretation work back to Toolformer.
That difference matters when a search result is only loosely related to the request. A term such as “Fishing Reel Types” may retrieve a useful description of different reels. A poorly chosen term may return material that shares words with the passage but does not answer its actual question. The paper identifies this as a reason its question-answering performance remains below the largest comparison model on some tasks: the search engine can produce a poor match, and Toolformer cannot reformulate the query or browse through multiple results.