LLM Training
Continued pretraining versus fine-tuning: choosing the right adaptation path
Not every domain problem needs continued pretraining. A practical framework for choosing between data exposure, instruction tuning and lighter adaptation methods.
The adaptation decision
Not every domain problem needs continued pretraining. Many need clearer task definition, better evaluation, retrieval support or lighter instruction tuning. Choosing the wrong adaptation path wastes compute and time.
When continued pretraining is worth considering
Continued pretraining is most relevant when:
- The domain language or structure is poorly represented in the base model
- Large volumes of domain text can be prepared with meaningful quality controls
- Downstream tasks benefit from deeper domain exposure, not only instruction following
- There is budget and infrastructure for multi-stage training
It is less compelling when the problem is primarily tool use, document grounding or a narrow supervised task with limited domain shift.
When fine-tuning is the better first move
Supervised fine-tuning or parameter-efficient adaptation is often the right first experiment when:
- Task definitions are clear and labelled data can be curated
- The base model already handles the language reasonably well
- You need rapid evidence before larger investment
- Inference constraints favour smaller adapter-based changes
A practical sequence
- Define the task and evaluation first.
- Establish a base-model baseline.
- Test the lightest adaptation that could produce evidence.
- Escalate to continued pretraining only when the evidence justifies the cost.
The goal is not to run the most elaborate training process. The goal is to choose the adaptation path that matches the domain shift, the data and the decision you need to make.
Related notes
Why domain-specific LLM evaluation cannot stop at loss
Training loss is a weak proxy for specialist correctness. Domain systems need task-level evaluation, failure taxonomies and operational checks before they are treated as dependable.
Read articleBuilding agents that recover instead of merely retrying
Retries are not a recovery strategy. Reliable agents need state, checkpoints, tool contracts and explicit paths for partial failure.
Read articleWorking on a related problem?
If this note maps to a decision you are making, we can discuss the technical context directly.