Good Testing Data Is All You Need
A contrarian methodology for applied AI: build your test set first, then derive the training set — optimizing dataset ROI and time-to-market.
Building machine-learning and deep-learning models requires plenty of data — a training set to learn from and a test set to be judged against. Academic best practices for setting up those sets have matured over decades. But applied data science answers to a different master. Every model a company builds exists to address a business problem, and that reframes everything.
Two goals that override the textbook
In an applied setting, two overarching goals dominate: build with the highest return on investment, and reach the market in the least time. Both carry real financial weight. Time-to-market especially — beyond reducing direct cost, getting to market ahead of competitors compounds into tactical and strategic advantage.
Data costs money
For a company detecting specific, high-risk items in CT and X-ray imagery, data isn't scraped for free — it's produced. Curating and labeling threat imagery at quality is expensive and slow. That cost pressure is exactly what pushed us toward a counterintuitive methodology.
Why the test set should come first
The conventional order is: gather a large training set, train, then carve out a test set to evaluate. We invert it. Build the test set first — the precise, representative, rigorously labeled set that defines what success actually means — and then derive and expand the training set from that foundation.
If you can't measure the thing you're building, you can't build it efficiently. The test set is the definition of done — so it should exist before anything else.
Defining evaluation first disciplines the entire effort. It forces explicit agreement on the classes that matter, the conditions the model must handle, and the bar it must clear. Every subsequent dollar of data acquisition is then spent against a known target rather than a moving one.
From theory to practice
In practice this approach let us treat dataset construction as an ROI problem: expand the training set deliberately, measure against a fixed and trustworthy test set, and stop when returns flatten. The train-to-test ratio settles into a sensible range, and time-to-market shrinks because the team never argues about whether the model is good enough — the test set answers that.
The bottom line
In threat detection, trust is the product. Operators and the public rely on the system to catch what matters. That trust is only as sound as the evaluation behind it — which is why, for applied AI, good testing data really is (almost) all you need.
Raviv Pavel
Chief Technology Officer
Raviv leads the machine-learning and platform engineering behind NeuralGuard's Intelligent Detection Engine™, from dataset design to edge deployment.