AutoAugment Search Policy

Search thousands of augmentation combos once on a small proxy task, then reuse the winning recipe everywhere. You pay the search cost one time.

AutoAugment searches 25 two operation subpolicies once, then each training image samples one subpolicy with its learned probabilities.

Why Does This Exist?

Hand picking flips, rotations and color jitters works, but the best combo differs per dataset and nobody knows it upfront. Grid searching combos by full training runs costs more than the final model itself.

AutoAugment turns the combo into a searched object. A controller proposes subpolicies, each with two operations plus a probability and magnitude per operation, trains a small proxy model, and keeps what scores best. The published CIFAR-10 policy holds $25$ subpolicies of $2$ operations each. You then reuse that fixed policy on the full run. The cheaper no search cousin is RandAugment, and the full menu is image augmentation.

You need one idea first. Search happens once on cheap proxy training, reuse happens many times on full training.

Think of It Like This

A chef tasting menu before the banquet

A chef tests 25 tiny two course tastings on a few guests, records scores, and serves only the winners at the full banquet for hundreds. The tasting costs one evening, the banquet reuses it for weeks.

AutoAugment tastes subpolicies on proxy training and serves the winners to full training. Where the analogy stops: tastings transfer across banquets only when guests match, and neither do policies.

How It Actually Works

Subpolicy format

One subpolicy is two triples $(\text{op}, p, m)$ . Example: $[(\text{Rotate}, 0.7, 15), (\text{Contrast}, 0.5, 0.3)]$ . During training, sample one of the $25$ subpolicies uniformly, then apply each op with its probability $p$ at magnitude $m$ . Expected ops per image for the example:

E = 0.7 + 0.5 = 1.2

A worked search scale

The controller trains thousands of proxy child models to score policies. The original run spent thousands of GPU hours to find the CIFAR-10 policy, then reused it for every later CIFAR-10 run at zero extra search cost. That reuse is the whole economic case: pay once, benefit on every retrain.

Transfer rule

Policies transfer within similar domains, like CIFAR-10 to CIFAR-100, and degrade across distant ones, like natural photos to X-rays. Operations include shear, translate, rotate, contrast, solarize and posterize, each with a discretized magnitude. Always revalidate a borrowed policy with a short run before committing.

Code

1import random2
3
4def sample_subpolicy(policies: list) -> list:5    """Pick one subpolicy uniformly. Each op runs later with its own p."""6    return random.choice(policies)  # 1 of 25, so prob 0.04 each7
8
9policies = [[("rotate", 0.7, 15), ("contrast", 0.5, 0.3)] for _ in range(25)]10print(len(sample_subpolicy(policies)))  # -> 2

Watch Out For

Borrowing a policy across domains

A CIFAR-10 policy with strong posterize and solarize mangles mammograms where subtle contrast is diagnostic. The symptom is augmentation that helped natural photos hurting a new domain from epoch one. Search small or fall back to RandAugment with two knobs instead.

Paying search cost for a one off run

Search makes sense when you will retrain many times. For a single deadline run, the proxy search can exceed the final training budget. Skip the search and tune two RandAugment knobs directly.

The Quick Version

AutoAugment searches 25 two operation subpolicies once, then reuses the winner.
Each operation carries its own probability and magnitude, like rotate at 0.7 and 15 degrees.
The original search cost thousands of GPU hours, paid once and reused many times.
Policies transfer within similar domains and fail across distant ones, so revalidate borrows.