Training when data is small on the How to Train Models track. With little data, prefer a strong baseline, heavy regularization, and transfer. A large net will memorize. Report uncertainty. Do not claim production readiness.
This lesson assumes you already worked through Using a GPU without fooling yourself.
The idea in practice
Use cross-validation if a single split is tiny, and still keep a final test set untouched.
A concrete check
goal = {
'track': 'How to Train Models',
'lesson': 'Training when data is small',
}
checks = [
'input available at decision time',
'score matches the real decision',
'failure case written down',
]
print(goal['lesson'])
for item in checks:
print('-', item)
Run the sketch locally if you have Python. The printout is a reminder of the checks, not a trained model. Replace the strings with the real inputs from your own example before you treat it as a design.
What usually goes wrong
A million-parameter model on 200 rows with a perfect training score. When this happens, stop adding parameters or tools. Fix the check, the data, or the permission, then run the same example again.
What to write down
- The input you are allowed to use at decision time.
- The output and the score or pass rule.
- One failure you will test on purpose.
- What you will not claim the system can do.
Practice
Choose baseline versus transfer for 300 labeled rows and say why.
Self-check
- Say Training when data is small in one sentence that mentions an input and an output.
- Name the failure mode in this lesson and the check that would catch it.
Done when: you can explain this lesson without the page open, and you have a written failure case.