· 4 min
When to fine-tune (and when not to)
Fine-tuning is one way to change a model’s behavior; it is not the first move for every weak answer. Start by describing the failure precisely. Is the model missing changing facts, misreading supplied context, ignoring a format, or applying a domain-specific rule inconsistently? Different failures call for different fixes.
Choose the smallest intervention that fits
- Prompt or product logic: use this when the instruction is unclear, context is not supplied consistently, or the app needs a better output schema.
- Retrieval: use this when answers depend on current or private reference material that should be updated without retraining the model. Make sure the answer can be tied back to retrieved sources.
- Fine-tuning: consider this when the same task and input pattern recur, you have permitted examples of the desired behavior, and prompt-only approaches remain inconsistent on a defined evaluation set.
Hypothetical example: a support classifier keeps confusing “billing question” with “refund request.” First inspect the labels, add counterexamples to the instructions and check that the needed fields reach the model. If the app instead asks product facts that change weekly, update the reference source and retrieval path; teaching those facts into weights makes freshness harder. These examples illustrate choices, not a measured tuning result.
Prove the change with a held-out set
Before preparing training data, save representative inputs and define what an acceptable output means. Include common cases, edge cases, ambiguous examples and cases where the system should abstain or escalate. Keep a portion out of training, compare the current system with the candidate on that held-out portion, and inspect errors by category. Track more than a single aggregate score: a gain on formatting can hide a regression in refusal behavior or a sensitive subgroup.
Training examples need permission, consistent labels and realistic inputs. Remove duplicates and data that teaches unsupported promises. Record where examples came from and who approved their use. Keep the training run, base model, data version and evaluation result linked so a later rollback can reconstruct what changed.
Finally, confirm that the target provider or serving stack supports the method for your account and intended deployment. Feature availability and model lifecycles change; the current OpenAI supervised fine-tuning guide is one example of provider documentation that carries lifecycle constraints. For an example optimization loop, see OpenAI’s model optimization guide alongside your chosen stack’s current documentation.
If the failure definition or evaluation set is still unclear, improve those before funding training work. Start with the eval harness, then bring the failure cases and deployment constraint to a model scoping discussion.