These terms describe different layers of an LLM system. Instruction tuning is a training stage. Tool use is an interaction protocol between a model and its runtime, and training can improve that behavior. Reasoning training is a broad name for post-training methods aimed at multi-step problem solving. One model can combine all three.

During instruction tuning, each training record usually contains a prompt and a desired response. Supervised finetuning increases the likelihood of the response tokens given the prompt. The model learns how to interpret requests, follow a chat template, respect output formats, and answer in an assistant-like way. Preference optimization may follow this stage, but it is a separate objective.

Instruction tuning alone does not give the model access to a calculator, web search, or private database. Those capabilities require a tool interface. An application supplies tool descriptions and argument schemas to the model. The model may then emit a structured request such as a function name with JSON arguments. The application validates and executes the request, adds the result to the conversation, and calls the model again.

This division matters because the model does not execute the tool itself. Tool use depends on the surrounding runtime. A pretrained or instruction-tuned model may learn simple tool calls from prompting and in-context examples. Supervised traces can teach more reliable tool selection, argument construction, result interpretation, and recovery from tool errors.

The Qwen materials show how one model family can package instruction following, coding, reasoning, and agent-oriented tool behavior as related but distinct capabilities

Reasoning training is less standardized. One approach uses supervised examples containing worked solutions or distilled traces from a stronger model. Another uses reinforcement learning with verifiable rewards (RLVR), where a checker can score a final answer from math, code, or another verifiable task. Training can also include generated search trajectories, self-correction examples, or tool-assisted solutions.

A longer explanation is not sufficient evidence that the reasoning improved. A model can imitate the appearance of a worked solution while making an early error. Evaluation should therefore check the final result and, when the task requires it, the validity of intermediate steps or tool calls.

The repo’s reflection-tuning example illustrates how a draft response can be critiqued and revised before it becomes training data. This is one way to create stronger supervised demonstrations. It should be distinguished from RLVR, where a reward signal updates the model based on sampled outcomes.

Reflection tuning refines generated responses before supervised training; it is a data-construction method rather than the same objective as RLVR

For a practical example, consider a request that asks for a calculation using current financial data. Instruction tuning helps the model follow the requested format. Tool-use capability lets the runtime fetch the data and run the calculation. Reasoning-oriented training may help the model plan the steps, check units, and notice an inconsistent result. The final behavior comes from the combination of model training, the tool protocol, and the application loop.