Walk through one training example for SFT'ing a single weather tool call.

Short answer·Medium·4.0 · 0·~3 min·Asked atVoyage Ai Yellow Ai Zoho·Relevant atCohere Databricks Meta Mistral AI

Attempt it

A team wants to fine-tune a 7B chat model so it reliably calls a single `get_weather(city)` tool. Write out, end to end, what ONE training row in the SFT JSONL looks like, the message turns, the roles, what gets masked from the loss, and at least one important negative example you'd also include. Explain why each piece is there.

Free · 2 AI evals / day

**One training row** is a short scripted conversation that shows the model exactly what to do when a user asks a tool-shaped question. For the weather example, the row has four turns. First the user asks something like What is the weather in Paris right now. Second the assistant emits a tool call: a small structured object that names the tool and lists its arguments, in this case the city. Third a tool turn carries the deterministic response from the API, for example temperature 18 and condition cloudy. Fourth the assistant writes the final natural-language reply that quotes those numbers back to the user. Loss masking decides which tokens the model actually learns to predict. The user turn is masked because the model is not supposed to learn to write user messages. The tool turn is masked because the model is not supposed to invent the API response. Loss is computed only on the two assistant turns: the call turn teaches when and how to call, and the final turn teaches how to ground the answer in the returned numbers. The dataset must also include negative rows. A negative is a question that has no tool answer, like What is the capital of France, paired with a plain-text assistant reply and no tool call. Without negatives, the model learns to call the tool for every question.

**A single training row** is a multi-turn JSONL object whose messages array encodes one end to end demonstration of the behaviour you want. For a positive weather example the array has four entries. The user turn is the natural-language question. The first assistant turn carries no free-text content and instead carries a tool call object naming get_weather and serialising its arguments, for instance city Paris. The next turn uses the tool role and carries the deterministic API response, for instance temp_c 18 and condition cloudy, keyed back to the call. The second assistant turn is the final reply, a sentence like It is 18 degrees C and cloudy in Paris. Loss is masked on the user turn and on the tool turn. The user turn would teach the model to imitate users, which is useless. The tool turn would teach the model to invent API responses, which is dangerous because at inference time the real API supplies that string. Loss runs only on the two assistant turns: the call turn teaches when to invoke the tool and what arguments to pass, the final turn teaches how to ground the answer in the returned numbers rather than hallucinating them. The dataset also needs negatives. A negative row is a question like What is the capital of France with a plain-text assistant reply and no tool call. Aim for roughly 30 to 40% negatives, or the model learns the lazy heuristic any question equals call the tool.

TL;DR

A positive row is four turns: user, assistant tool call, tool result, assistant grounded reply. Loss runs only on the two assistant turns, and the dataset must include negatives so the tool is not called for everything.

Memory aid

Easy to grasp

Picture training a new librarian to use one reference book. You stage a conversation where someone asks a real reference question, the librarian flips open the book, the book shows the page, and the librarian reads the answer aloud. You grade the librarian only on two moments: opening the right book and explaining the right page in plain words. You do not grade what the patron said or what the book literally printed. You also stage other conversations where the patron asks something the book cannot answer, and you teach the librarian to just talk normally without grabbing the book. Without those second kinds of conversations, the librarian learns to grab the book for every question and looks silly when someone asks the time.

Key concepts

Tool calling Supervised fine-tuning Loss masking Negative examples

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Tool-call SFT looks like ordinary chat fine-tuning until you look at the row shape. A normal chat row has two roles, user and assistant, and the model learns to predict assistant tokens conditioned on user tokens. A tool-call row has four roles in play, two of them are not chat at all, and the model needs to learn three distinct skills from the same conversation: when to invoke the tool, what arguments to pass, and how to weave the returned data into a fluent reply.

The row shape encodes all three skills implicitly, and the loss masking decides which of them the model actually trains on. Get the masking wrong and the model will start hallucinating API responses at inference. Get the negative to positive ratio wrong and the model will fire the tool at every question or never fire it at all. The recipe is not complicated, but every piece carries weight, and skipping any of them produces a recognisable failure pattern in production.

This deep dive walks one canonical positive row turn by turn, explains exactly which tokens contribute to the loss, then covers the negative-row design that prevents over-invocation. The example uses a single get_weather tool to keep the moving parts visible, but everything generalises to a fleet of tools with the obvious extensions.

The four turns of a positive row

A positive row is a JSON object with a messages array of four entries. The roles are user, assistant, tool, assistant.

Turn one is the user request. For our example: What is the weather in Paris right now? This is plain natural language, the same shape it would have in any chat dataset.

Turn two is the first assistant turn, but it looks unlike a normal assistant reply. It carries no natural-language content. Instead it carries a tool call: a structured object with a name field set to get_weather and an arguments object containing the extracted parameters, here city Paris. Most modern formats wrap this in a tool_calls array because a single turn can emit several calls in parallel, but the shape is the same. The model is not writing words on this turn, it is committing to a structured action.

Turn three uses the tool role. It carries the deterministic response from the API: in our example a small JSON object like temp_c 18 and condition cloudy. It is keyed back to the call from turn two so the model can tell which result belongs to which request. This turn is data, not authored content, and it comes from the environment rather than from the model.

Turn four is the second assistant turn. The model writes the final natural-language reply that the user actually sees, grounded in the values from turn three. For our example: It is 18 degrees C and cloudy in Paris. This is the only turn whose text the user reads.

The shape encodes the workflow: ask, decide to act, observe the result, summarise back. Each turn has a single, clear job, which makes the loss masking decisions natural.

Loss masking, turn by turn

Why two assistant turns, not one

Negative rows and the over-invocation failure mode

Argument variety and dataset scaling

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

OpenAI's hosted fine-tuning API for gpt-5.5-class tool-calling models accepts JSONL with exactly this four-turn shape and rejects rows that put tool output under the assistant role.
Anthropic's Claude Opus 4.7 tool-use API uses a similar messages contract, with tool_use and tool_result blocks distinguishing the two non-natural language turns.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you scale this design from one tool to a fleet of fifty tools?

Keep the four-turn shape per row but balance positives across tools so no single tool dominates. Add cross-tool negatives where the user query could plausibly match two tools but only one is correct, to teach disambiguation. Increase the negatives fraction modestly because over-invocation risk grows with more tools.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Training only on positives where the tool is called. The model latches on to the shape question equals tool call and starts firing get_weather at trivia questions, the classic over-invocation failure mode.

60 second bullets to scan on the way to the call.

The four-turn shape of a positive tool-call row
Which roles each turn carries and what fields differ from a plain chat turn

Primary sources. Browse if you want the original framing.