Data Cleaning for Multimodal ML: Missing Values, Outliers, Scaling, and Categorical Encoding

Data cleaning is the set of corrective steps applied to a raw dataset — handling missing values, treating outliers, scaling numeric ranges, and encoding categorical fields — so that what a model trains on reflects real signal rather than collection artifacts. [GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md): "Data quality caps everything downstream, so cleaning comes first." That sentence is not a platitude; it is a literal ceiling. A model cannot learn a pattern that the cleaning step destroyed, and it cannot avoid learning a pattern that a leaked or corrupted feature created. Whatever a downstream model's architecture eventually contributes, it contributes on top of whatever data cleaning left behind — it cannot subtract a defect it never sees as a defect.

For a multimodal system specifically, cleaning is not confined to one modality's numeric columns. [GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) names consistency — fixing types, duplicates, and inconsistent labels — as "critical when merging multiple modalities/sources," because a pipeline that pairs an image with a caption, or an audio clip with a transcript, has twice the surface area for a mismatched key, a duplicated pair, or a type inconsistency to slip through. The four jobs below are described in the classic tabular-data frame the source material uses, but every one of them recurs the moment you attach a second modality: an image dataset has outlier images (corrupt files, wildly wrong aspect ratios), a caption dataset has missing values (blank or placeholder captions), and every multimodal corpus has categorical metadata (source, license, language) that needs the same encoding decisions as any other categorical column.

L1 — Intuition

A missing value is a gap in an otherwise complete record — a survey respondent who skipped a question, a sensor that failed to log a reading, a scraped web page whose price field never rendered. The intuitive response is "just fill it in," but filling it in with the wrong number is worse than leaving the gap, because a wrong number looks exactly like a real observation to everything downstream. The two live options are dropping the incomplete data (the row, or in extreme cases the column) and imputing a value that estimates what the missing entry probably was.

L2 — Mechanism

Dropping is the simplest correct choice when missingness is rare and effectively random — if 0.3% of rows are missing one field and there is no reason to think the missingness itself carries information, dropping those rows costs almost nothing and introduces no invented values. Dropping an entire column is the right call when a feature is missing so pervasively (50%+, as a rule of thumb rather than a fixed exam number) that no imputation strategy can recover a trustworthy signal from what remains.

Imputation is the alternative when dropping would discard too much data or too much information. [GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) lists the standard imputation menu: mean, median, mode for categoricals, forward/backward fill for time-series, or model-based imputation, where a separate model predicts the missing value from the other features. Mean imputation replaces every gap with the column's average — the mechanically simplest option, and the one that fails first when the data has a skew or outliers, because the mean itself is dragged toward whatever extreme values are present. Median imputation replaces every gap with the middle value of the sorted column — robust to exactly the extremes that break the mean, because the median only cares about rank order, not magnitude. Mode imputation replaces a categorical gap with the most frequent category. Forward/backward fill carries the previous (or next) observed value forward across a gap in an ordered time-series, which is defensible specifically because time-series data usually changes slowly, so the last known value is a reasonable stand-in for a short gap.

L3 — The exam-relevant edge case

The source material's own stated trap is mean imputation on skewed or outlier-heavy data: [GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) calls out "mean imputation on skewed/outlier-heavy data" directly, with the median named as the more robust choice. The reasoning generalizes past this exam: any statistic you compute from the data to fill a gap in the data inherits every distortion already present in that data. A single column of household incomes with a handful of very high earners will have a mean pulled well above where most of the mass sits; imputing with that mean systematically overstates the missing values, while the median — unaffected by how far out the extreme values sit, only by how many there are — stays anchored near where the bulk of the real observations are.

L1 — Intuition

An outlier is a value that sits far enough from the rest of a column's distribution that it plausibly reflects something other than the phenomenon you are measuring — a data-entry error, a sensor glitch, or a genuinely rare but real event. The word "plausibly" is doing real work: an outlier is a candidate for special treatment, not an automatic deletion, because sometimes the outlier is the most important row in the dataset.

L2 — Mechanism

[GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) names three detection methods: the IQR (interquartile range) rule, the z-score rule, and box plots, which visualize the same IQR-based logic. The IQR rule computes the 25th and 75th percentiles of a column, takes their difference as the IQR, and flags any value more than 1.5 times the IQR below the 25th percentile or above the 75th as an outlier — a rule that, like the median, depends only on rank order and is therefore itself robust to the extremes it is trying to detect. The z-score rule instead standardizes every value to "how many standard deviations from the mean," and flags anything beyond a threshold (commonly ±3). Z-score detection has a built-in weakness the IQR rule does not: because both the mean and the standard deviation used to compute a z-score are themselves pulled by extreme values, a dataset with several outliers can under-flag some of them — the very presence of outliers inflates the standard deviation, which raises the bar for what counts as "far enough" to be flagged.

Once detected, three treatments are available: cap the value at a defensible boundary (winsorizing to the 1st/99th percentile, for instance), transform the whole column (a log transform compresses the visual and statistical distance between large values, which is often the correct fix for right-skewed data like prices or durations), or remove the row outright. Removal is the most aggressive option and the one most likely to discard real signal if the outlier is a genuine rare event rather than an error.

L3 — The exam-relevant edge case

The decision of which treatment to apply is not a coin flip — it is a data-generating-process question. If a sensor cannot physically produce a negative temperature reading in Celsius on a system that never goes below freezing, a −40 reading is a plausible entry error and removal or correction is defensible. If the same sensor logs an unusually large but physically possible spike during a real event, capping or transforming preserves the direction of the signal (something unusual happened) while limiting its distortion of downstream statistics like the mean or a scaler's fitted range. Treating every outlier the same way — always remove, or always cap — is the shortcut version of this decision and is exactly the kind of blanket rule an exam distractor is built to punish.

L1 — Intuition

Numeric features frequently arrive on wildly different scales — a "number of prior purchases" column might range 0–20 while an "account age in days" column ranges 0–3,650. A model that computes distances, gradients, or dot products across features (which is most of them) will let the larger-magnitude feature dominate purely because of its scale, not because it is more informative. Scaling puts every numeric feature onto a comparable range before that happens.

L2 — Mechanism

[GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) names two scaling methods. Normalization (min-max scaling) maps a column linearly onto [0, 1] using the formula (x − min) / (max − min), so the smallest observed value becomes 0 and the largest becomes 1. Standardization (z-score scaling) maps a column to mean 0 and standard deviation 1 using (x − mean) / std, so every value is expressed as "how many standard deviations from the mean" rather than as a position within a fixed range. Normalization is bounded and intuitive but sensitive to outliers — a single extreme value stretches the [0, 1] range and compresses every ordinary value into a narrow band near one end. Standardization is unbounded but more robust to a handful of outliers, because the mean and standard deviation, while still outlier-sensitive themselves, do not hard-cap the output range the way min-max does.

L3 — The exam-relevant edge case: fitting the scaler

[GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) states the rule directly: "Fit scalers on the training set only to avoid data leakage." This is the single fact this lesson is built around, because it is named explicitly as a common exam trap and because the mechanism behind it generalizes to every other preprocessing step you will meet later in this course. A min-max scaler needs a column's min and max to compute its formula; a standardization scaler needs the mean and standard deviation. If you compute those statistics from the entire dataset — training, validation, and test rows all pooled together — before splitting, then the test set's own values have quietly influenced the min, max, mean, or standard deviation that gets applied to the training data. The model never sees the test labels, but it has absorbed a sliver of test-set structure through the scaler, which is precisely what "test information leaking into training" means. The correct procedure is: split first, fit the scaler on the training split's statistics only, then apply that already-fitted scaler — using the training set's min/max or mean/std, unchanged — to transform the validation and test splits. The validation and test data never contribute a single number to the scaler's parameters.

⭐ THE EARNED INSIGHT

Data leakage is never about the model peeking at test labels — it is about any statistic computed from data outside the training split influencing anything the training split touches, and a scaler's min/max or mean/std is exactly that kind of statistic. The fix is always the same shape: split first, compute second, and never let the order reverse.

L1 — Intuition

A categorical feature — color, country, product category — has no inherent numeric value, but a neural network needs numbers. Encoding is the translation step, and the translation you pick encodes an assumption about whether the categories have an order.

L2 — Mechanism

[GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) states the rule as: "One-hot for nominal (unordered) categories; label/ordinal encoding only when order is meaningful." One-hot encoding creates one binary column per category — "is this row red," "is this row blue," "is this row green" — with exactly one column set to 1 per row and the rest 0. It makes no claim about which category is "more" or "less" than another, because there is no single numeric column doing double duty as both an identifier and a magnitude. Ordinal (label) encoding instead assigns each category an integer — small=0, medium=1, large=1 — packing the category into a single column whose numeric order the model will treat as meaningful, because a network fed a "2" and a "1" for two rows of the same feature has no way to know you meant those as arbitrary labels rather than as a real quantity.

L3 — The exam-relevant edge case

[GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) names the trap directly: "Label-encoding unordered categories, which invents a false ordinal relationship." If "red," "blue," and "green" get encoded as 0, 1, 2, a model that computes any distance or difference between rows will treat blue as sitting numerically between red and green, and green as being "twice as far" from red as blue is — a relationship that exists only because of encoding order, not because of anything true about color. The fix is to recognize which categorical variables in a dataset carry a real order (small/medium/large; low/medium/high risk tier) and which do not (color; country; product SKU), and to apply ordinal encoding only to the first group. When in doubt about whether an order is real, one-hot is the safer default, because it costs extra columns but never invents a relationship that is not there.

Treat the following as a constructed scenario built to make the sequencing legible, not a measurement from any real dataset. A team is assembling a dataset of product listings, each with a numeric price, a numeric weight_kg, a categorical size_tier (small/medium/large — genuinely ordered), a categorical country_code (unordered), and an attached product photo. The raw data has 10,000 rows.

Step 1 — split first.
  train: 7,000 rows | val: 1,500 rows | test: 1,500 rows
  (split before any statistic is computed from the data)

Step 2 — missing values, computed from the TRAIN split only.
  price: 2.1% missing -> impute with train-split median (price is right-skewed:
    a few luxury items sit far above the bulk of the catalog, so the mean
    would be pulled upward and overstate every imputed value)
  weight_kg: 0.4% missing -> impute with train-split median (same skew reasoning)
  size_tier: 0.1% missing -> drop those rows (rare enough that dropping
    costs almost nothing, and no defensible "typical" size_tier exists to impute)

Step 3 — outliers, detected on the TRAIN split only.
  price: IQR rule flags 41 rows above the upper fence
    -> inspected manually: 39 are legitimate luxury items (real signal, kept),
       2 have a price of $0.00 (data-entry error, removed)
  weight_kg: z-score rule flags 3 rows beyond 3 standard deviations
    -> inspected: all 3 are unit-entry errors (grams entered as kilograms),
       corrected by dividing by 1,000 rather than removed

Step 4 — scaling, fit on the TRAIN split only, then applied unchanged to val/test.
  price, weight_kg -> standardized: (x - train_mean) / train_std
  train_mean(price) = 42.80, train_std(price) = 19.35
  -> a $62.15 train-split item standardizes to (62.15 - 42.80) / 19.35 = 1.00
  -> that SAME train_mean and train_std are reused, unrecomputed, for every
     val/test row -- a $62.15 item in the test split standardizes identically

Step 5 — categorical encoding.
  size_tier (ordered: small < medium < large) -> ordinal encoding: 0, 1, 2
  country_code (unordered, 24 distinct values) -> one-hot: 24 binary columns

Step 6 — consistency, across the tabular data and the photo metadata.
  17 rows reference a product_id with no matching photo file -> dropped
  (a caption-image pair with no image is not a data point this model can use).

[GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md) — the median-over-mean and train-only-fit choices in steps 2 and 4 are direct applications of the two most heavily flagged traps in the domain material. Notice the ordering discipline running through every step: split happens once, at the very top, and every statistic computed afterward — the median used for imputation, the IQR fences, the mean and standard deviation used for scaling — is computed from the training split alone and then reused, never recomputed, when it is time to touch validation or test data.

A colleague hands you a training pipeline that reports 94% validation accuracy but only 71% accuracy once the model reaches production. The pipeline code, condensed:

# colleague's pipeline (BUGGY)
scaler = StandardScaler()
X_scaled = scaler.fit_transform(X_full)          # fit on ALL 10,000 rows
X_train, X_val, X_test = split(X_scaled, ratios=(0.7, 0.15, 0.15))
model.fit(X_train, y_train)
# validation accuracy: 94%
# production accuracy: 71%

Walk the diagnosis the way the exam expects you to reason about a leakage question: the 23-point gap between validation and production accuracy is far larger than ordinary sampling noise would explain, and nothing about the model architecture changed between those two accuracy numbers — only the data source did. scaler.fit_transform(X_full) is called before the split, on X_full, which contains every row that will later become train, validation, and test. The mean and standard deviation baked into scaler therefore reflect all 10,000 rows, including the 3,000 that will become validation and test. When the model is evaluated on the validation split, that split's own values already shaped the very transformation being applied to it — a smaller, friendlier version of testing on your own training data. Production traffic, by contrast, was never part of X_full at all, so it gets scaled using statistics that partially reflect a dataset it was never a member of, and the artificially favorable validation number does not survive contact with genuinely new data.

The fix reorders exactly two lines:

# corrected pipeline
X_train, X_val, X_test = split(X_full, ratios=(0.7, 0.15, 0.15))
scaler = StandardScaler()
scaler.fit(X_train)                               # fit on TRAIN ONLY
X_train_scaled = scaler.transform(X_train)
X_val_scaled   = scaler.transform(X_val)          # apply, don't refit
X_test_scaled  = scaler.transform(X_test)         # apply, don't refit
model.fit(X_train_scaled, y_train)

This is a constructed scenario — the 94%/71% figures are illustrative, chosen to be a plausible-looking gap rather than measured from a real run — but the mechanism it demonstrates is the exact one the source material names as the domain's standing trap, and the fix generalizes to any preprocessing step (imputation statistics, outlier fences, feature-selection thresholds) that is computed from data rather than supplied as a fixed rule.

Data Analysis is Domain 2 of the NCA-GENM blueprint, at 10% weight, tied with Trustworthy AI as the lightest of the seven domains [GROUND TRUTH] (Sources/nca-genm/domain-2-data-analysis.md). The domain's own scope note frames it as foundational: "recognize the right technique and read a chart correctly," explicitly not "author production ETL pipelines." Data cleaning is the domain's opening subsection precisely because, per the source material, "cleaning comes first" — every other Domain 2 topic (EDA, chart choice, attention maps, augmentation) assumes the data reaching that step is already reasonably clean.

The question tends to arrive in a small number of recognizable shapes. A scenario describing a preprocessing pipeline and asking "what is wrong with this approach" is testing whether you catch the fit-before-split leakage pattern, usually worded as "a data scientist scales the entire dataset, then splits it into train and test" — the keyed answer names data leakage, and the distractors typically offer "nothing is wrong" or a vague "this will overfit," which sounds plausible but names the wrong mechanism. A scenario describing a skewed numeric column with missing values and asking which imputation method is most appropriate is testing median-over-mean, with mean imputation itself frequently offered as the (wrong) first-listed distractor. A scenario naming an unordered categorical (color, city, product type) and asking which encoding to use is testing one-hot-over-ordinal, with the distractor usually being ordinal encoding presented as "simpler" or "more efficient" — true on both counts, and still the wrong answer, because efficiency is not the deciding criterion.

What the distractors typically look like

The reliable traps mirror the ones the source material calls out by name: offering mean imputation as the default correct answer for a skewed distribution; describing "fit the scaler on the full dataset, then split" as an acceptable or even preferred sequence; and offering ordinal encoding for a category with no real order, on the reasoning that fewer columns is inherently better engineering. Each is true in some other context (mean imputation is fine on a symmetric, outlier-free column; ordinal encoding is correct and preferred when the order is real) — which is exactly why they work as distractors rather than obviously wrong options.

Normalization (min-max scaling) maps a column onto a fixed [0, 1] range using the column's own minimum and maximum; standardization (z-score scaling) maps a column to mean 0 and standard deviation 1 using the column's own mean and standard deviation. Normalization is the more intuitive and bounded choice, and it is a reasonable default when a feature has a roughly uniform spread with no extreme values, or when a downstream algorithm expects inputs in a fixed range. Standardization is generally the safer default whenever a feature is not uniformly distributed or contains a handful of large-but-plausible values, because the min-max range in normalization is entirely determined by whichever single row happens to be the extreme, while standardization's mean and standard deviation are influenced by, but not dictated by, any one row. Neither method fixes an outlier problem on its own — outlier treatment is a separate, earlier step, not something scaling substitutes for.

Because leakage is about information flow, not about labels specifically. A scaler's parameters — the min/max for normalization, or the mean/standard deviation for standardization — are statistics computed from whichever rows are fed into the fit step. If every row in the dataset, test rows included, is fed into that fit step, then the transformation subsequently applied to the training data has been shaped, even if only slightly, by values the model is never supposed to have seen before its final evaluation. The model does not need to see a test-set label for this to be leakage; it only needs the test set to have influenced some number (a mean, a max, an IQR fence) that then touches the training pipeline. This is exactly why the corrected procedure in section 8 fits the scaler after splitting, on the training rows alone, and only ever calls transform — never fit again — on the validation and test rows.

It can change performance meaningfully, and the direction of the effect depends on how skewed the column is and on how much of it is missing. On a column with little skew and few missing values, mean and median imputation produce nearly identical results, because the mean and median of a roughly symmetric distribution sit close together. On a column with real skew or a heavy-tailed distribution — prices, durations, incomes, file sizes — the mean and median can differ substantially, and mean imputation systematically injects values pulled toward whichever tail dominates, which then biases any statistic (including a later scaler's own mean) computed from the column. The effect compounds with how much data is missing: imputing 0.5% of a column with the wrong central-tendency choice barely matters, while imputing 20% of a column with the wrong choice can visibly shift the column's own distribution.

• Data cleaning is four jobs — missing values, outliers, scaling, categorical encoding — and a defect in any one of them caps everything a model built afterward can achieve.
• Median imputation, not mean imputation, is the robust default whenever a numeric column is skewed or outlier-heavy.
• IQR and z-score are the two named outlier-detection methods; IQR is more resistant to the outliers it is trying to detect, because it depends only on rank order.
• Normalization bounds a feature to [0, 1] and is sensitive to extreme values; standardization centers a feature at mean 0/std 1 and is comparatively more robust.
• Fit every scaler, and every other preprocessing statistic, on the training split only — split first, compute second, and reuse the training statistics unchanged on validation and test. This is the single most heavily flagged trap in the source material.
• One-hot encoding is the safe default for unordered categoricals; ordinal encoding is correct only when a real order exists, and applying it to an unordered category invents a relationship that is not there.
• Cleaning a multimodal dataset adds a fifth job beyond the classic tabular four: consistency across sources, because a mismatched key between two modalities silently corrupts the pair a model is meant to learn from.

Clean, correctly split data is the input; the next question is what you actually see when you look at it. M2-02 picks up exactly there — descriptive statistics and correlation, the exploratory pass that turns a cleaned dataset into a set of facts you can trust before any model touches it, and the same split discipline you just learned resurfaces there in a different shape: a correlation is descriptive of the data you computed it on, and generalizing it beyond that data carries its own risk.