Reproducibility in ML: Seeds and Determinism

Machine-learning results can vary because data shuffling, parameter initialization, dropout, augmentation, and some parallel numerical operations use randomness. Setting seeds for the relevant pseudorandom generators makes many of these choices repeatable within a controlled environment. A seed is only one part of the experiment record: code, data, preprocessing, software versions, hardware, and configuration also affect results. Frameworks may offer deterministic algorithm settings that avoid operations whose outcomes can vary with execution order or backend behavior. Enabling them can surface errors when no deterministic implementation is available, and may reduce performance. Determinism is useful when debugging a pipeline or comparing a focused change, but it can constrain performance and is not always required for scientific reproducibility. Reproducibility has levels. Exact bit-for-bit repeatability on the same setup is stricter than obtaining statistically similar outcomes on another system. GPU kernels, library versions, compiler behavior, hardware, thread scheduling, and distributed training can all affect numerical results. A seed does not remove floating-point order effects or guarantee that a saved script can run unchanged years later. Data-loader workers and separate libraries may use distinct random generators. Seed them deliberately and record how splits and augmentations are produced. Preserve split indices or stable identifiers, not just the seed, because data ordering or preprocessing changes can alter membership. Log the configuration and model checkpoint with each run. When results differ, first verify that data, preprocessing, split, model, and metrics are identical. Then inspect random settings and nondeterministic operations. Report repeated-run variation where it matters, rather than selecting the most favorable seed. Clear experiment records make a result auditable even when exact reproduction is impossible.