Using function-calling
The function calling API allows a user to describe the set of tools/functions available to the model and have the model intelligently choose the right set of function calls to invoke given the context. This functionality allows users to build dynamic agents that can get access to real-time information & produce structured outputs. The function calling API doesn’t invoke any function calls. Instead, it generates the tool calls to make in OpenAI-compatible format.
At a high level, function calling works by
- The user specifies a query along with the list of available tools for the model. The tools are specified using JSON Schema.
- The model intelligently detects intent and based on intent the model outputs either a normal conversation reply or a list of tools/functions to invoke for the user. Based on the specified schema, the model populates the correct set of arguments to invoke a function call.
- The user receives a reply from the model. If the reply contains a function call specification - the user can execute that method and return its output to the model along with further queries/conversation.
Resources
- Fireworks Blog Post on FireFunction-v2
- Open AI Docs on Function Calling
- Open AI Cookbook on Function Calling
- Function Calling Best Practices
Supported models
- Firefunction-v2 - Latest and most performant model
- Firefunction-v1 - Previous generation, Mixtral-based function calling model. Fast and excels at routing and structured output
Example usage
TL;DR This example tutorial is available as a Python notebook [code | Colab].
For this example, let’s consider a user looking for Nike’s financial data. We will provide the model with a tool that the model is allowed to invoke & get access to the financial information of any company.
- To achieve our goal, we will provide the model with information about the
get_financial_data
function. We detail its purpose, arguments, etc in JSON Schema. We send this information in through thetools
argument. We sent the user query as usual through themessages
argument.
- In our case, the model decides to invoke the tool
get_financial_data
with some specific set of arguments. Note The model itself won’t invoke the tool. It just specifies the argument. When the model issues a function call - the completion reason would be set totool_calls
. The API caller is responsible for parsing the function name and arguments supplied by the model & invoking the appropriate tool.
- The API caller obtains the response from the tool invocation & passes its response back to the model for generating a response.
This results in the following response
Tools specification
tools
field is an array, and each individual component contains the following two fields
type
:string
The type of the tool. Currently, only function is supported.function
:object
description
:string
A description of what the function does, used by the model to choose when and how to call the function.name
:string
The name of the function to be called. Must be a-z, A-Z, 0-9, or contain underscores and dashes, with a maximum length of 64.parameters
:object
The parameters the functions accepts, described as a JSON Schema object. See the JSON Schema reference for documentation about the format.
Tool choice
The tool_choice
parameter controls whether the model is allowed to call functions or not. Currently, we support values auto
, none
, any
or a specific function name.
auto
mode implies the model can pick between generating a message or calling a function. This is the default tool choice when the field is not specified.none
mode is akin to no tool specification being passed to the model.- To force a specific function call, you can set the
tool_choice = {"type": "function", "function": {"name":"get_financial_data"}}
. In this scenario, the model is forced to use this specific function. - To specify that any function call is a good function call, and a function call should always be made, you can use the
any
mode, or you can set the function name to be empty when you specify tool choice to be “function”, liketool_choice = {"type": "function"}
OpenAI compatibility
Our function calling API is fully compatible with OpenAI including in streaming scenarios. Compared to the OpenAI API - we don’t support parallel and nested function calling.
Best practices
- Number of Functions - The length of the list of functions specified to the model, directly impacts its performance. For best performance, keep the list of functions below 7. It’s possible to see some degradation in the quality of the model as the tool list length exceeds 10.
- Function Description - The function specification follows JSON Schema. For best performance, describe in great detail what the function does under the “description” section. An example of a good function description is “Get financial data for a company given the metric and year”. A bad example would be “Get financial data for a company”.
- System Prompt - In order to ensure optimal performance, we recommend not adding any additional system prompt. User-specified system prompts can interfere with the function detection & calling ability of the model. The auto-injected prompt for our function calling model is designed to ensure optimal performance.
- Temperature Setting temperature to 0.0 or some low value. This helps the model to only generate confident predictions and avoid hallucinating parameter values.
- Function descriptions Providing verbose descriptions for functions & its parameters. This is similar to prompt engineering: the more elaborate & accurate the function definition/documentation - the better the model is at deciphering the accurate intent of the function and its parameters.
Function calling vs JSON mode
When to use function calling vs JSON mode? Use function calling if the use case involves decision-making or interactivity - which function to call, what parameters to fill, or how to follow up with the user to fill in missing function arguments in a chat form. JSON/Grammar mode is a preferred choice for non-interactive structured data extraction and allows you to explore non-JSON formats too.
Example apps
- Fireworks-created demos:
- Langchain integration notebooks:
Data policy
Data from Firefunction is logged and automatically deleted after 30 days to ensure product quality and to prevent abuse ( bulk data on average # functions used, etc). This data will never be used to train models. Please contact raythai@fireworks.ai if you have questions, comments, or use cases where data cannot be logged.
Was this page helpful?