**The three standard roles** in a chat training example are `system`, `user`, and `assistant`. This convention started with the OpenAI chat-completions API and has been adopted by essentially every modern chat-tuned model: ChatML, Llama, Qwen, Mistral, DeepSeek, and the closed models from OpenAI, Anthropic, and Google.
Each role has a specific meaning. The **system** message sits at the top of the conversation and describes how the assistant should behave: persona, tone, safety rules, response format. The **user** role represents a turn from the human. The **assistant** role represents a turn from the model.
In a chat training file each example is a list of these role-tagged messages. A typical conversation might be one system message followed by alternating user and assistant turns over multiple rounds.
During SFT the loss is computed only on the assistant turns. The model is never trained to generate system messages or user messages; those are inputs it conditions on. The role tags also tell the trainer where each turn starts and ends, which is how the chat template knows where to insert special tokens like turn boundaries.
Some templates add a fourth role called `tool` or `function` for tool-call results, but the canonical trio is always system, user, assistant.
**The three canonical roles** in a chat training example are `system`, `user`, and `assistant`. This trio originated in the OpenAI chat-completions schema and has become the de facto standard for chat-formatted data across the entire ecosystem.
**System** carries the behavioural setup: persona, response style, safety constraints, format expectations. It usually appears once at the top of the conversation. Some templates support multiple system messages; many do not.
**User** marks a turn from the human, the model's interlocutor. A multi-turn conversation has alternating user and assistant turns after the initial system message.
**Assistant** marks a turn from the model. During training this is the only role whose tokens contribute to the loss; the others are conditioned on but not generated by the model.
**Tool** (or `function`, depending on the template) is the common optional fourth role for tool-call results. It appears in templates that support function calling (Llama 3, Qwen 3.5, OpenAI, Anthropic) and carries the output of an external tool the assistant invoked.
The data shape on disk is a JSONL file where each line has a `messages` key whose value is an array of `{role, content}` objects. Loaders like TRL's SFTTrainer take this shape directly and apply the appropriate chat template (the per-model token sequence that wraps each turn) before computing the loss.
**Why this matters operationally.** The role tags drive prompt masking. The trainer knows to compute loss only on assistant tokens because of the role field; without it, the model would try to learn to generate user content too, which is a documented failure mode.
Quick reference
TL;DR
The three core chat roles are system (behaviour), user (human turn), and assistant (model turn). Tool and function are optional extensions for tool calling.
Picture a script for a small play. The director has stage directions at the top describing how the actors should behave throughout the scene. The audience member speaks lines aloud. The actor on stage responds. Three speaking parts, each with its own role label. In a chat training example the director is the system message, the audience member is the user, and the actor is the assistant. The model is being trained to play one specific role, the actor, and to take direction from the system message while responding to the user. Some plays add a stagehand who reports results from off-stage; that is the optional tool role. The core trio always shows up.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
You are fine-tuning a pure base model with no instruction tuning Raw base models have no built-in chat template; either install one as part of SFT or use a different prompting convention until you do.
You are mixing chat templates from different model families in the same run Each template uses different role markers and turn boundaries; mixing them corrupts the model's ability to follow either consistently.
Your task is single-turn completion with no conversational structure The role machinery is overhead for true completion tasks; a simple prompt and response format may be cleaner.
Quick scan · 2–4 min
Everything important, quickly.
5 min: the three roles + the system / user / assistant trio + loss masking on assistant only + tool as the optional fourth role + chat templates + the Alpaca vs role-schema confusion.
Side-by-side
Role
Who it represents
Loss applied?
system
Behavioural setup / persona
No, conditioned on
user
Human turn
No, conditioned on
assistant
Model turn
Yes
tool (optional)
External tool output
Usually no
Real-world examples
Real products, models, and research that use this idea.
1OpenAI chat-completions API was the original system/user/assistant schema, adopted by every modern provider.
2Llama 4 Maverick uses the Llama-3 chat template with system/user/assistant plus tool, marked with `<|start_header_id|>` style tokens.
3Qwen 3.5 ships ChatML-style markers (`<|im_start|>`, `<|im_end|>`) with the same three core roles plus optional tool.
4Anthropic's Claude API uses a similar system/user/assistant schema with system as a separate top-level field rather than a message.
5Hugging Face TRL's SFTTrainer auto-detects chat-formatted data with role keys and applies the model's chat template before training.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does Hugging Face's apply_chat_template actually work?
Sign in or go Pro to see the approach for this follow-up.
QWhy does SFT mask system and user tokens from the loss?
Sign in or go Pro to see the approach for this follow-up.
QHow does the tool role differ across providers, and why does it bite portability?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Confusing roles with dataset record field names. Alpaca-style instruction/input/output and old GPT-3 prompt/completion are flat record schemas, not message-role labels.