Data Requirements and Differentiation

Imagine two teams who each need a model that behaves in a specialized way. The first team is ready to gather a large collection of examples before doing anything else. The second team wants to start quickly and is wondering whether it needs any data at all. Both teams are asking about data, but they are really asking the same underlying question: how much data does this project require?

The central point of this article is that the amount of data a project requires is not fixed. It depends on which adapter technique the team uses to shape the model. Instead of asking how to collect data, we ask a prior question: given a technique, how much data should you expect to need, and why does the answer change from one technique to the next?

The source compares three approaches and places them in a chain. Training a model from scratch sits at the top of the data requirement scale. Finetuning sits below it, because finetuning generally needs less data than training from scratch. Prompt engineering sits at the bottom, because finetuning in turn requires more data than prompt engineering does.

Read the diagram from top to bottom. Each step down the chain generally asks for less data than the step above it. Notice that the source gives only this ordering. It does not attach exact quantities to any of the three techniques, so the ordering tells you the direction your data needs move as you change techniques, not how many examples you need.

The source's core claim is that data planning should start with the technique choice. The order of planning matters. A team that begins by collecting data without first choosing a technique has no basis for deciding how much to collect, because the technique is what determines the amount.

The flowchart shows the sequence. The technique is chosen first. That choice fixes where the project sits on the relative scale. Because the source gives only relative comparisons, a team that needs concrete numbers must gather evidence specific to its own project before committing to a data budget.

It is tempting to read a relative ordering as a set of precise targets. The source does not support that reading. It names no exact quantity for any technique, so the ordering is useful for direction and comparison, while the size of any dataset must come from the specifics of the project.

The source makes a second point, one that holds regardless of how much data a technique needs. Examining a model's training data gives important clues about that model's strengths and weaknesses. The training data is a record of what the model was shaped by, and that record can be read to infer where the model is likely to perform well and where it is likely to struggle.

The concept map shows the direction of reasoning. Examining the training data is what produces clues, and those clues point toward likely strengths and likely weaknesses. The source frames this as an inference, so the reading is a way of forming expectations about a model rather than a guaranteed account of its behavior.

This is why data expertise remains useful even when a project needs only a small amount of data. The size of the dataset changes how much data must be gathered, but the value of reading that data for clues does not depend on its size.