Which Task Type Should You Pick?

Start from the output, not the input. If each request gets one answer, pick question answering, and if the answer is a label, make the label the whole answer. If the output is the next turn of a conversation, pick chat completion. If the model has to act on what a tool returned, pick agentic chat completion.

Which task type matches the output you need?

The decision table from the task selection guide, with the config value you’ll actually type:

If you need to…	Pick	base.task
Generate a targeted answer from a text-based input	Question answering	question-answering
Assign one of a fixed set of categories	Classification, as question answering with a mutator over the labels	question-answering
Answer from a passage you supply at query time	Question answering, with the passage inside the user message	question-answering
Produce the next conversational turn: text, tool calls, or both	Chat completion	chat-completion
Call tools, read their results, and answer	Agentic chat completion	chat-completion-agentic

Read the rows top to bottom and stop at the first one that describes your output exactly. If two describe it equally well, the next section is for you.

What do you pick when two task types both fit?

Take the more constrained one. A tighter task specification gives the teacher less room to drift during synthetic generation and gives you a metric that actually discriminates.

Classification versus free-text question answering. Classification, whenever the label set is closed and known. Sentiment, ticket routing, moderation verdicts, and topic tagging are all classification even if you currently prompt an LLM for them in prose. The label becomes the whole answer, the labels and their definitions go in task_description, and one mutator with a value per label keeps the synthetic data covering all of them (classifying into labels). You get binary exact match as the metric, which a free-text judge score can’t give you.

Retrieval versus knowledge in the weights. Both are question answering; the difference is whether the user message carries a retrieved passage. Provenance decides it. If an answer has to be traceable to a document, you need retrieval, because a model answering from memory can’t point at a source. If your corpus changes weekly, retrieval also wins, because reindexing is faster than retraining. Train on question-and-answer rows without context only when the knowledge is stable and you’d rather ship one artefact than operate a retriever. The full comparison is in open-book vs closed-book QA.

Tool calling versus classification. If the downstream system needs arguments as well as a name, it’s chat completion with tools declared. If it only needs the name, classification is cheaper to prepare and easier to evaluate. A routing decision with no parameters doesn’t need a JSON schema.

Chat completion versus agentic chat completion. Agentic as soon as the model has to read a tool result before it answers. If every assistant turn is followed by the next user turn, and the tool results never come back to the model, plain chat completion is enough and the data is simpler to collect.

Which choices lock you out of a model?

Declaring tools does. The supported models catalog restricts chat completion with tools declared to the Qwen3, Qwen3.5, Qwen3.6, Qwen3.8, Llama 3, LFM2/LFM2.5, FunctionGemma, and Gemma 4 families, and teachers to those marked in the tool-calling column. Agentic chat completion always declares tools, so the restriction always applies there.

Task type	Student models available	Teacher models available
Question answering, chat completion without tools	All catalog students	All catalog teachers
Chat completion with tools, agentic chat completion	Qwen3, Qwen3.5, Qwen3.6, Qwen3.8, Llama 3, LFM2/LFM2.5, FunctionGemma, Gemma 4	Only those with tool calling marked

Inside the DeepSeek family the split isn’t obvious: deepseek.v3.2 qualifies as a tool-calling teacher, while deepseek.r1 and deepseek.v3.1 don’t. For new work zai.glm-5.3-low-thinking, the large GLM 5.3 teacher, is the safest teacher across all three tasks. It’s what recent distil labs runs use and it supports tool calling. Reasoning teachers, which is most of the catalog, require synthgen.teacher_temperature between 0.5 and 0.7:

base:
  task: question-answering
  student_model_name: Qwen3-1.7B
  teacher_model_name: zai.glm-5.3-low-thinking
synthgen:
  teacher_temperature: 0.6

More on the trade-offs in which teacher model should you pick.

What do people get wrong most often?

Four mistakes, roughly in order of how expensive they are.

Letting a closed-label problem answer in prose. The model returns “This looks like a billing issue” instead of billing, and now you’re parsing prose in production. Put “Answer with the label only.” in the task description, make the label the whole assistant turn, and the label is the whole output.

Training without retrieval to avoid building a retriever. Answering from the weights works, but it makes every knowledge update a retraining job, and it can’t cite. If the reason for choosing it is that retrieval is inconvenient rather than that the knowledge is stable, you’ve chosen the harder operational path.

Training plain chat completion for an agent that reads tool results. The evaluation looks fine because each test row stops at the tool call. Then per-turn errors compound in production: at 90% per call, a five-turn conversation completes correctly about 59% of the time, and the model has never seen a tool result it has to act on. Multi-turn tool calling sets out that arithmetic.

Ignoring the model restriction until upload. Choosing a student first and a task second can leave you with a model that isn’t eligible once tools are declared. Pick the task, then the student.

How do you confirm the choice before training?

Run teacher evaluation on a small dataset. It scores a large model on your test set with your job description, and it costs a fraction of a training run.

distil dataset create --data ./data
# Output: Upload successful. Dataset ID: <dataset-id>

distil teacher-evaluation create-from-dataset <dataset-id>
# Output: Teacher evaluation started. Teacher Evaluation ID: <teacher-evaluation-id>

distil teacher-evaluation status <teacher-evaluation-id>

A low teacher score usually means the task is under-specified rather than that the task type is wrong. The docs list sharpening the task description and fixing inconsistent labels as the first fixes. But it also surfaces genuine mis-framing: if a classification task scores badly because half your examples have two defensible labels, the taxonomy is the problem, and no task type will rescue it. If you’re training with retrieved context and retrieval returns several candidate chunks, put the distractor chunks in your training rows too, the approach introduced as RAFT, so the model learns to ignore them. For a broader tour of the three options, see the task types.