Preparing data to fine-tune function-calling model

I’ve been using a fine-tuned model before that I trained with examples. Model was used exclusively with function calling. It was classifying the text and extracting an entity.

It looks like JSON payload for calls using fine-tuning will change soon, as “function” figures as “Deprecated” in the documentation (even though it still works).

I’m preparing to train a new model and looking into getting examples uploaded. However, the documentation doesn’t seem to be up to date and I’m struggling to determine right format for the JSONL file.

Previously it was:

{
    "messages": [
        {"role": "user", "content": "What is the weather in San Francisco?"},
        {"role": "assistant", "function_call": {"name": "get_current_weather", "arguments": "{\"location\": \"San Francisco, USA\", \"format\": \"celcius\"}"}}
        {"role": "function", "name": "get_current_weather", "content": "21.0"},
        {"role": "assistant", "content": "It is 21 degrees celsius in San Francisco, CA"}
    ],
    "functions": [...] // same as before
}

The above example mentions deprecated “functions”:

How should my example look like now?

3 Likes

If you upload training data using the tools schema, you get the following error on file upload:

BadRequestError: Error code: 400 - {'error': {'message': 'Invalid file format. Line 1, message 11, key "__root__": At least one of content or function_call must be set.', 'type': 'invalid_request_error', 'param': None, 'code': None}}

Training 3.5-1106 using the old schema (functions/function_call) caused weird behavior when testing the model.

I’ve noticed the same old behavior. Fine-Tunings files validation process seems to be not updated to new API profiles. Until it won’t be we’ll couldn’t use new API profile ( “tool_calls:” specification ).

@supbarty Were you able to figure this out? Also wondering same thing

Thank you for flagging this, I am looking into it now and will follow up when I have more info.

3 Likes

Added a message to the docs, but the current state is: " function_call and functions have been deprecated in favor of tools , however, the fine-tuning API still requires the legacy format at this time."

2 Likes

Thanks, any update on this? Just to make sure I understand:

The api uses the tools format , but the validator rejects it?
The function style will validate but cause unexpected behaviour if used to train?

Is there a working approach for fine tuning with tool/function calls right now?

Sorry if i have it wrong, just trying to understand and troubleshoot some things.
Thanks again.

The function method can be used to train AI models. It is required to be in a special assistant format because OpenAI doesn’t want to disclose the actual language the AI generates to the API’s tool recipient code (hint: and has disabled spaces in role names so you can’t quite get there).

The language that you train the AI on will be the same even if you plan on “tools”. The only thing not exposed is having the AI make multiple tools calls at once, which has AI write more with undisclosed prompting. You should be able to utilize the fine-tune model with either “function” or “tool” method.

gpt-3.5-turbo shouldn’t actually need fine-tune training on emitting functions, unless you have a very specific stylistic or behavioral choice that must be enclosed in them. OpenAI says in the guide that then you don’t need to include full function definitions then, but the API actually requires functions or tools definitions still be passed or you get nothing.

Note: fine-tune with function currently has a fault in that it trains the AI wrong on terminating normal output or such, resulting in repeating lines. More workaround is needed.

2 Likes

Precisely this. Thanks, your notes on the workaround are interesting.

My team is struggling to get functions to not execute before all arguments are available. Structurally, we need gpt-3.5-turbo to wait and not hallucinate function arguments. Thus we are using fine tuning. The function in question is one that collects a user’s message (name, phone, body) which to me seems toy.

Correct me if I am misunderstanding you, but are you suggesting that this is the incorrect approach?

This is something you don’t have to fine-tune for - except now almost by design.

Here’s an example of a system role message that is a good starting example of an “interview until complete” technique.

The only challenge is in still making this example and others from June with complex system instructions still work on the “same” function call model.

Does this also mean that currently it is not possible to finetune the model with multiple function calls in a single message?

In this example, how can I change the assistant message to use multiple functions at once?

{
    "messages": [
        { "role": "user", "content": "What is the weather in San Francisco?" },
        {
            "role": "assistant",
            "function_call": {
                "name": "get_current_weather",
                "arguments": "{\"location\": \"San Francisco, USA\", \"format\": \"celsius\"}"
            }
        }
    ],
    "functions": [
        {
            "name": "get_current_weather",
            "description": "Get the current weather",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "The city and country, eg. San Francisco, USA"
                    },
                    "format": { "type": "string", "enum": ["celsius", "fahrenheit"] }
                },
                "required": ["location", "format"]
            }
        }
    ]
}

Only functions is currently supported by fine-tune.

Parallel tool calls requires an additional tool to be manually placed into the tools section, that they wanted to not disclose, and the multi_tool_use call and return value uses a significantly larger number of tokens when emitted and then replayed to the AI.

You can train your AI on iteratively using functions, by placing an extended conversation with multiple turns, for example where AI does a search and then accesses the results of the search.