Skip to main content
Technology2 min read

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.

RPRaviv PavelChief Technology Officer

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.

RP

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.

Bring instant detection to your checkpoint

Every deployment is tailored to your lanes, volume, and threat profile. Talk to an expert about a configuration for your facilities — most sites are screening with NeuralGuard the same day.

  • Subscription-based service — no capital equipment program
  • Continuous software updates as threat patterns evolve
  • Hardware-agnostic — runs on your installed scanner fleet
  • Scales from a single lane to a nationwide deployment
  • Optional add-ons: alarms, belt stops, camera security
  • Onsite installation support available