Most trainers accept JSON Lines (JSONL): one JSON object per line, with each object holding a complete chat conversation. The exact field names may vary, but the structure is similar:
{"messages": [
{"role": "system", "content": "You are Acme's billing support assistant. Reply in under 120 words."},
{"role": "user", "content": "I was charged twice this month."},
{"role": "assistant", "content": "I'm sorry about that. I can see duplicate charges are usually authorization holds..."}
]}
Practical rules that matter more than the syntax:
- Include the system prompt you will actually use in production, verbatim. The model learns the pairing of that prompt with the desired behavior.
- Assistant messages are the target answers. They must match the style, format, and quality you want. The model can learn their flaws as easily as their strengths.
- Multi-turn conversations are fine and often valuable; trainers mask the loss so only assistant turns are learned.
- For tool-use fine-tuning, include the tool schemas and assistant tool-call messages in the same structure the runtime will produce.
The deeper point: dataset design is the product spec. Every quirk in your examples, from greeting phrasing to how errors are handled, becomes model behavior.
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Why there's no diagram: “”
The interactive diagram is below the answer - jump to diagram ↓ · Below it, the related concept . Jump to it ↓
The diagram below the answer is the concept . Jump to it ↓