Roles in a chat training example: pick the three that are standard.

**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.