Every optimization engagement we run starts the same way — not with the engine, but with the dataset. An optimizer will maximize whatever you measure, including your measurement's flaws. Garbage in, garbage out.
Start from reality, not imagination
The strongest datasets are curated from observability logs: real inputs your system actually received, including the awkward, truncated, off-distribution ones. Hand-written test cases systematically miss the long tail because the author imagines well-formed users. When logs are thin, such as with new products, simulation can fill the gap. Use AI to synthetically generate inputs that stress specific failure modes, review them, and clearly label these rows as synthetic.
Ground truth, at the right cost
Some reward functions need labeled answers; others can score structurally (did the code execute, did the output parse, did it cite a source, did the extraction match the schema). Label where it matters: a few hundred carefully labeled examples beat ten thousand noisy ones. In many domains, ground truth often already exists in your logs or work output and just needs to be extracted.
Coverage beats volume
The dataset's job is to represent the input distribution. Cluster your inputs, make sure every cluster that matters appears, and over-sample the most critical ones. A dataset that's 95% unimportant cases tells the optimizer the easy cases are what matter — and it will happily focus on those.
Reserve data you never touch
Split before optimizing: training data the engine learns from, validation data it makes decisions on, and a holdout set that's touched exactly once, at the end. The holdout is your defense against the optimizer overfitting to its own scoreboard.
Teams sometimes hesitate here, but reserving data for a holdout set is not wasted! The holdout set is what makes your output measurable and trustworthy.