24 August 2026, 05:11 PM
The Model's Evaluation Score Was Great. It Had Already Seen the Answer.
A team preparing data for a pricing model ran feature scaling, normalizing numeric fields against the dataset's overall mean and standard deviation, before splitting the data into training and evaluation sets. The evaluation score that came back was excellent. It was also fake, in a specific, well-understood way that's easy to miss until you know to look for it: the normalization statistics had been calculated across the entire dataset, including the examples that would later become the evaluation set, which meant the training process had indirectly absorbed information about the evaluation data's actual distribution before ever being tested against it. The model wasn't just evaluated well. It had been quietly handed a small preview of the answer key, baked into the scaling parameters themselves, and the real-world performance once deployed came in meaningfully below what the evaluation had promised.
This is one of several data preparation mistakes that don't show up as an obvious bug, they show up as a plausible, misleadingly reassuring number that collapses later. Here are the ones I see most often.
Mistake One: Normalizing or Scaling Data Before Splitting It
This is the mistake from the opening, and it's genuinely easy to make because it feels like a reasonable, even tidy, order of operations, clean and prepare the whole dataset, then split it. The problem is that any preprocessing step calculating statistics from the data, mean and standard deviation for scaling, category frequencies for encoding, needs to be calculated only from the training portion, then applied to the evaluation and test portions using those same training-derived parameters. Calculating those statistics across the full dataset before splitting lets information about the evaluation set's distribution leak into training indirectly, producing an evaluation score that's measuring something other than genuine generalization.
The fix is a strict ordering discipline: split the data first, calculate any preprocessing statistics exclusively from the training split, and apply those exact parameters to transform the validation and test splits afterward, never recalculating anything from data outside the training set.
Mistake Two: Randomly Splitting Data That Has a Real Temporal Order
For any dataset where examples have a genuine chronological relationship, user behavior over time, transaction history, any process that evolves, a naive random split into training and test sets can place examples from later in time into training while earlier examples end up in the test set. This lets the model train on information that, in any real deployment scenario, wouldn't have existed yet at the point it's being asked to predict something, producing an evaluation score that reflects a capability the model will never actually have in production, predicting the past using knowledge of the future.
The fix is a temporal split specifically for any dataset with a genuine time dimension: training data drawn only from before a defined cutoff point, and evaluation data drawn only from after it, mirroring the actual real-world constraint that a production model will only ever have access to information that existed before the moment it's making a prediction.
Mistake Three: Preprocessing Training Data Differently Than Production Inference Data
This is the mistake I'd call the most quietly damaging, because it can pass every offline evaluation cleanly and still degrade real-world performance in a way that's genuinely hard to trace. If the preprocessing pipeline used to prepare training data, tokenization rules, text normalization, feature construction, differs even subtly from the preprocessing applied to real input at inference time, the model ends up operating on production data that doesn't actually match the statistical shape of what it learned from, a mismatch commonly called training-serving skew.
The fix is treating preprocessing logic as a single, shared, versioned component used identically in both the training pipeline and the production inference path, not two separately maintained implementations that started identical and have since drifted apart through independent updates. Any change to preprocessing logic needs to update both paths simultaneously, and testing needs to explicitly verify that a given raw input produces identical processed output whether it goes through the training pipeline's preprocessing or the production pipeline's preprocessing.
Mistake Four: Applying a Fixed Chunking Strategy Without Considering Document Structure
For RAG systems specifically, splitting source documents into chunks for embedding and retrieval using a fixed token or character count, applied uniformly regardless of the document's actual structure, routinely cuts chunks in the middle of a semantically meaningful unit, a table, a step-by-step procedure, a single coherent argument, splitting it across two separate chunks that each lose important context the other half needed.
The fix is chunking strategy that respects document structure where it's available, splitting along natural boundaries, paragraphs, sections, list items, rather than a purely mechanical token count, and testing retrieval quality specifically against documents where a fixed-size approach would be most likely to fracture something meaningful, tables, numbered procedures, and any content where the whole unit needs to stay together for a retrieved chunk to actually make sense on its own.
Mistake Five: Imputing Missing Values Without Testing the Downstream Effect
Choosing how to fill in missing data, a default value, a computed mean, a more sophisticated model-based imputation, is a decision that actively shapes what the model subsequently learns, and treating this as a purely mechanical data-cleaning step without testing its actual downstream effect on model behavior misses a real, sometimes serious source of bias. An imputation strategy that fills missing values with a population average, for instance, can systematically distort behavior specifically for the subgroup where that field tends to be missing most often, if missingness itself correlates with some other characteristic in the data.
The fix is testing model behavior specifically for the subgroup where a given field is missing most frequently, comparing performance and behavior against the subgroup where it's reliably present, and treating a meaningful difference as a signal that the chosen imputation strategy may be introducing distortion rather than neutrally filling a gap.
A Visual Breakdown of the Mistakes
A Practical Checklist
- Any preprocessing statistic, scaling parameters, category encodings, is calculated exclusively from the training split and applied to validation and test data afterward
- Datasets with a genuine temporal dimension use a chronological split, not a random one, matching the real-world constraint of predicting forward, not backward
- Preprocessing logic is a single, shared, versioned component used identically in training and production inference, tested explicitly for identical output on identical input
- RAG document chunking respects natural structural boundaries where available, tested specifically against tables, procedures, and other content that shouldn't be split mechanically
- Imputation strategies are tested for their downstream effect on model behavior across the specific subgroup where the imputed field is missing most often
Where This Leaves Enterprise Teams
The teams whose models hold up in production aren't the ones with the most sophisticated preprocessing pipeline. They're the ones who treated data preparation as a place real, specific mistakes actually hide, an evaluation score quietly inflated by leaked statistics, a temporal split that let the model see the future, a preprocessing mismatch nobody caught until production behavior stopped matching offline results.
This level of preparation discipline is part of how PrimeQA Solutions structures AI Data Services for enterprise clients, because the gap between an evaluation score that looks great and a model that actually performs in the real world often traces back to exactly this stage, quietly, long before anyone starts debugging the model itself.