Chapter 2 of 5 · Fine-Tuning Language Models — When to Do It, How, and How to Know It Worked
Data for fine-tuning: file format, chat templates, Thai data and terms of use
Data decides the outcome of fine-tuning more than tools do. This chapter covers the messages format tools expect, why the chat template must match in training and in use, the Thai datasets available and their licences, and AI providers' terms that forbid training on their outputs.
The last chapter concluded that fine-tuning suits teaching a format or behaviour. What the model learns is the examples you give it: if they are wrong or inconsistent, the model will learn that too.
2.1 Data format: conversations as messages
The main tools use the same shape: each example is a conversation with roles. Hugging Face TRL uses:
{"messages": [
{"role": "user", "content": "ของยังไม่ได้เลย สั่งไปตั้งแต่วันจันทร์"},
{"role": "assistant", "content": "ติดตามพัสดุ"}
]}
(The customer writes “Still haven’t received it, I ordered on Monday”; the label is “delivery tracking”.) OpenAI uses a JSONL file, one example per line, with the same messages structure.
OpenAI stresses that every training example must be in the same format as you will use at inference. If you put a system instruction in front in real use, the training examples need the same instruction.
2.2 The chat template: where things break silently
Each chat model has its own chat template: the rule for turning messages into one long string, with special tokens marking what is the question and what is the answer.
Hugging Face Transformers’ docs warn about three things:
- with the wrong control tokens, models have “drastically worse performance”;
- the template must always match the format the model was trained with;
- adding special tokens twice is often incorrect and hurts performance.
TRL applies the chat template automatically for messages data, and its docs stress that the end-of-sequence (EOS) token must be aligned with the template, or a trained model may not stop talking.
To train only on the answers and not the questions, TRL has assistant_only_loss=True, which needs a template that marks where answers begin and end.
The simple rule: use your base model’s own template, in training and in use. Don’t invent a format. If your base model is a pure base model with no chat template, such as ThaiLLM-8B, see how to set one in the TRL docs for your version, and use that one template throughout.
2.3 Quality matters more than quantity
- Examples must be consistent. If the same kind of message gets different labels, the model will be confused in the same way.
- Examples must look like the real thing. If customers make typos, abbreviate or mix in English, the examples should too.
- Start small and measure. OpenAI suggests starting with 50 examples, and rethinking the task before adding data if that does not help.
2.4 Thai data: what to know
Thai web data is scarce and noisy. The Typhoon paper reports Thai at under 0.5% of Common Crawl, and much crawled Thai text is written for SEO or duplicated.
Translated data is not as good as data written in Thai. The WangchanThaiInstruct paper found that models fine-tuned on that human-written Thai dataset outperformed those trained on translated data, both in and out of the training domains.
Thai datasets you can find — read the licence every time:
| Dataset | What it is | Licence, per its page |
|---|---|---|
| WangchanThaiInstruct | Human-written, 4 domains, 7 task types, 40,000 rows in the default config | Varies by row: some non-commercial (NC), some share-alike (SA) |
| han-instruction-dataset (PyThaiNLP) | 15,821 rows | CC-BY-SA 4.0 |
| WangchanX seed-free synthetic Thai 120k | 118,898 rows, generated with Qwen2-72B-Instruct | MIT, but the Qwen2-72B-Instruct licence forbids using its output to improve other language models; check before commercial use |
| Typhoon-S instruct post-training | The data used to train Typhoon-S | ODC-By, but the page says upstream sources’ licences may differ; check them |
For commercial use, NC data is out. SA requires adapted works that you distribute to carry the same licence; whether a model trained on the data counts as an adapted work is not settled, so for important work ask a lawyer.
2.5 Providers’ terms: may you train on AI outputs?
A common idea is to have a large model write examples, then train a small model on them. Read the provider’s terms first:
| Provider or model | What we could verify |
|---|---|
| Anthropic | Commercial terms forbid using the services to “build a competing product or service, including to train competing AI models”; the usage policy forbids using inputs and outputs to train a model (“model distillation”) without authorization |
| Google Gemini API | You may not use the services “to develop models that compete with the Services” |
| OpenAI | Its terms pages refused automated access, so we could not check the wording — read them yourself |
| Llama 4 (Meta) | You may use Llama outputs to create, train or fine-tune a model you distribute, but its name must begin with “Llama” |
Each provider words it differently. Anthropic’s policy forbids training a model on inputs and outputs without authorization, whether or not the model competes. The Gemini API terms forbid developing models that “compete with the Services”, and whether your project falls under that is a matter of interpretation.
Open models attach conditions to outputs too. The Qwen2 licence forbids using its output to improve other language models; the terms for Gemma models before Gemma 4 treat a model trained on Gemma’s outputs as a Gemma derivative; Llama 4 imposes its naming rule.
The safest route is data you write or collect yourself. If you use any model’s output, read that model’s terms first. Nothing in this chapter is legal advice; for important commercial work, ask a lawyer.
2.6 A hypothetical example: data that teaches the wrong thing
The shop from chapter 1 collects several hundred customer messages to label, split between two staff members. One files “can I change the size?” under “product question”, the other under “complaint”.
The trained model then files these messages at random. The problem is not the model or the tool but that the labelling rules were never written down. The fix: write a definition and examples for every category before labelling, and have both people label the same share of messages to see how often they agree.
2.7 After this chapter
- Convert the examples from chapter 1 into the messages format exactly as you will use it in production.
- Write a definition for every category or answer format before labelling.
- If you use public datasets, record each one’s licence next to the data.
- If you plan to train on a large model’s answers, read that provider’s terms first.
The next chapter covers the training itself with LoRA and QLoRA, and choosing a Thai base model.
Sources
- Hugging Face TRL — SFT Trainer
- Hugging Face Transformers — Chat templates
- OpenAI — Supervised fine-tuning
- OpenAI — Fine-tuning best practices
- Typhoon: Thai Large Language Models (arXiv 2312.13951)
- WangchanThaiInstruct (arXiv 2508.15239)
- WangchanThaiInstruct dataset
- PyThaiNLP han-instruction-dataset
- WangchanX seed-free synthetic Thai 120k
- Typhoon-S instruct post-training dataset
- Anthropic — Commercial Terms of Service
- Anthropic — Usage Policy
- Google — Gemini API Additional Terms of Service
- Meta — Llama 4 Community License