Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Just as important as the green lights are the red ones. Don't fine-tune when your facts change often (RAG), when you have fewer than a hundred examples (prompt instead), when a stronger base model with a good prompt already clears the bar, when you can't build an eval to prove it worked, or when you haven't yet exhausted prompt engineering. Recognizing these anti-patterns up front is what keeps you from a multi-week project that ends with a model no better than your starting prompt. This is the 'stop' list every fine-tuning decision should pass through.
The demo is a pre-flight checklist that returns the reasons you should NOT fine-tune yet — if any fire, fix that first.
Use these three in order. Each builds on the one before.
In one paragraph, when should I NOT fine-tune a model?
Walk me through the warning signs that mean I should reach for prompting or RAG instead of fine-tuning.
I have 60 examples, facts that update weekly, and no eval set, but my boss wants a fine-tune. Make the case for what to do instead and how to sequence it.
def reasons_not_to_finetune(num_examples, facts_change_often,
tried_prompting, can_build_eval):
stop = []
if num_examples < 100:
stop.append("Too few examples (<100): few-shot prompt instead")
if facts_change_often:
stop.append("Knowledge changes often: use RAG, not weights")
if not tried_prompting:
stop.append("Haven't exhausted prompting: it's cheaper and reversible -- try first")
if not can_build_eval:
stop.append("No eval: you won't be able to prove it worked -- build one first")
return stop or ["No blockers -- fine-tuning is a reasonable choice here"]
print(reasons_not_to_finetune(num_examples=40, facts_change_often=False,
tried_prompting=True, can_build_eval=True))
print(reasons_not_to_finetune(800, False, True, True))python3 main.py