Reproducible AI: Why it Matters & How to Improve it
Reproducibility is a core part of scientific research. It allows researchers and AI teams to check whether a result can be obtained again under clearly described conditions.
An OECD report on AI in science argues that AI research has not escaped the broader reproducibility crisis. It cites evidence that reproducibility problems have appeared across image recognition, natural language processing, reinforcement learning, recommender systems, medicine, and the social sciences. It also notes that 70% of AI research was irreproducible.1
The issue is no longer whether researchers share code. The harder question is whether the shared artifacts are complete enough for another team to verify the result. This requires clear research questions, access to data and code, model settings, environment details, evaluation scripts, and documentation.
Learn why reproducibility is important for AI and how businesses can improve it in AI projects.
What is reproducibility in artificial intelligence?
AI reproducibility is the ability to obtain the same or similar result when the original data, code, model settings, and environment are available and documented.
In AI, three related terms are often confused:
- Repeatability: The same team gets the same result using the same code, data, and setup. For example, a data science team reruns its training pipeline and gets the same metric.
- Reproducibility: A different team gets the same result using the original artifacts. For example, another lab runs the code and data released with a paper and obtains the same result.
- Replicability: A different team gets the same finding with new code, data, or experiments. For example, a second team tests the same claim with a new implementation and a new dataset.
AI reproducibility depends on three core components:
- The dataset includes training, validation, and test data, data splits, labels, and preprocessing steps.
- The AI algorithm, including model type, parameters, hyperparameters, features, weights, prompts, and code.
- The environment, including software versions, hardware, operating system, drivers, random seeds, and deployment settings.
Changes in all three components must be tracked and recorded.
Reproducibility also has a limit. A result can be reproducible and still be wrong. For example, a bug in the preprocessing code may be reproduced by every team that runs the same code. A result that cannot be reproduced is also not proof of fraud. It may reflect missing details, unavailable data, different hardware, or an ambiguous evaluation protocol.
Why is reproducibility important in AI?
Reproducibility is important for both AI research and enterprise AI applications, but the goals differ.
For AI and ML research, reproducibility enables independent researchers to inspect results, rerun the original experiment, and build on prior work. Scientific progress depends on this process. If a paper does not document code, data, model settings, and evaluation details, other researchers may not be able to tell whether the result is a robust finding or an artifact of one setup.
For AI applications in business, reproducibility supports debugging, auditability, and stable deployment. Teams need to know which data version, model version, prompt, environment, and configuration produced a given output. This is important for quality assurance, incident review, and compliance.
Reproducibility is also becoming a governance requirement. Regulations such as the EU AI Act require technical documentation and record-keeping for high-risk AI systems. This increases the need for traceable datasets, model versions, evaluation logs, and deployment records.
What are the challenges of reproducible AI?
Lifecycle stage | Challenge | Example |
|---|---|---|
Data | Dataset availability, changing data, and inconsistent preprocessing | A healthcare dataset is proprietary, or NLP preprocessing removes stopwords differently. |
Training | Randomness and seed sensitivity | Different weight initialization or stochastic gradient descent runs produce different metrics. |
Training | Non-deterministic hardware and software | GPU kernels, CUDA versions, or framework updates change numerical results. |
Training | Hyperparameter search | A learning rate or batch size is changed but not recorded. |
Evaluation | Benchmark overfitting and contamination | A model performs well because benchmark data appeared in training data. |
Evaluation | Evaluation protocol differences | Two LLM evaluation harnesses use different prompt formats or answer parsers. |
Deployment | API drift and model updates | A closed model endpoint changes behavior after a silent update. |
Reporting | Selective reporting and missing variance | Only the best run is reported, with no mean, standard deviation, or confidence interval. |
1. Randomness and Stochastic nature of algorithms
Many AI models, especially deep learning algorithms, incorporate randomness during their training and inference processes. For instance, random weight initialization, dropout layers, and stochastic gradient descent (SGD) contribute to variability even when using the same dataset, codebase, and environment.
This issue is especially pronounced in Large Language Models (LLMs), such as GPT-5, Gemini, or LLaMA, which are inherently probabilistic. Even when prompted with the same input and configuration, they may generate different outputs, particularly if temperature or top-k sampling parameters are adjusted. These settings control the randomness of output generation:
- Temperature adjusts the probability distribution used during token sampling. A higher temperature (e.g., 1.0) produces more diverse, creative outputs, while a lower temperature (e.g., 0.2) yields more deterministic responses.
- Top-k or top-p (nucleus) sampling further controls randomness by limiting the range of tokens considered at each step.
Asking an LLM to summarize the same paragraph twice with a temperature of 0.9 may yield significantly different summaries. This variability makes it difficult to verify or reproduce model behavior unless settings are fixed and explicitly documented.
In enterprise applications, such as contract summarization, chatbot replies, or AI coding assistants, this unpredictability poses challenges for debugging, compliance, and quality assurance. Teams may struggle to trace which configuration led to a specific output unless all parameters, including the random seed and temperature, are logged consistently.
For example, the Thinking Machines Lab explained batch-invariance failure as a major source of nondeterminism in LLM inference. Ideally, a model should produce the same output for a given prompt regardless of whether it is processed alone or alongside other requests. However, modern serving systems dynamically batch requests to improve GPU efficiency, and many GPU kernels vary their execution patterns depending on batch size or layout.
Because floating-point operations are not perfectly associative, small changes in the order of computation can slightly alter the logits. During decoding, these tiny differences can eventually lead the model to select different tokens, causing different outputs even with deterministic settings (e.g., temperature = 0). In effect, the model’s result depends on which other requests share the batch, making inference appear nondeterministic.2
2. Lack of standardization in data preprocessing
Preprocessing steps such as cleaning, filtering, augmentation, normalization, tokenization, and feature extraction are often not fully documented. Small differences can change the final result.
In image models, the order of resizing, cropping, or augmentation can affect accuracy. In NLP, tokenization, stopword removal, casing, or truncation can affect metrics. In tabular models, missing value handling and feature scaling can alter model behavior.
Teams should treat preprocessing code as part of the model. It should be versioned, tested, and logged with the model artifact.
3. Non-deterministic hardware and software
The execution of AI algorithms can vary across different hardware (CPUs, GPUs, TPUs) and even on the same hardware due to underlying non-deterministic processes in libraries. Differences in versions of these libraries can introduce further variability, even when code and data are identical.
For example, PyTorch 2.10 introduced several improvements focused on determinism and debugging numerical issues in modern ML workflows.
As distributed reinforcement learning and large-scale post-training pipelines become more common, ensuring reproducible execution and diagnosing subtle numerical divergence has become increasingly important. To address this, the release added new debugging capabilities such as DebugMode, which tracks dispatched calls and helps identify sources of numerical instability during execution.3
4. Hyperparameter tuning
Many AI models rely on hyperparameters, such as learning rate, batch size, or regularization strength, which need to be fine-tuned. Often, these are not shared in enough detail, or their selection is not explained rigorously, making it difficult to reproduce results. Also, slight changes in hyperparameters can result in different performance outcomes.
5. Lack of complete artifacts and documentation
A paper may share code but still be hard to reproduce. Missing files, incomplete README instructions, unavailable model weights, hidden preprocessing scripts, or undocumented dependencies can stop reproduction.
Useful artifacts include:
- Code and exact commit hash.
- Training, validation, and test data versions.
- Model weights and checkpoints.
- Environment files such as
requirements.txt,pip freeze, conda environment files, lock files, Dockerfiles, or Nix configurations. - Training logs and evaluation scripts.
- Random seeds and hardware details.
- Instructions for running the full pipeline.
Documentation standards such as Model Cards and Dataset Datasheets help make this information easier to inspect.
6. Versioning issues
The dynamic nature of AI software ecosystems means that libraries and frameworks are constantly evolving. A model trained using a specific version of a library might not perform the same when run on a later version, even if the code remains unchanged. Keeping track of versions for all dependencies can be difficult, and versioning is often poorly documented.
7. Dataset availability and variability
Some datasets used in AI research are proprietary or not publicly available, making it impossible to replicate studies. Even when datasets are available, there can be variations due to sampling, updates, or different preprocessing techniques applied at the time of research.
8. Computational resources
Reproducing state-of-the-art AI models often requires significant computational resources, including specialized hardware like GPUs or TPUs. Researchers or practitioners without access to the same level of resources may find it hard to replicate results.
9. Overfitting to specific test sets
In some cases, models are inadvertently overfitted to specific test sets or benchmarks. When these models are tested in different environments or on slightly altered datasets, the results may not generalize, making reproducibility challenging.
10. Bias in reporting and cherry-picking results
Researchers may report the best-performing version of a model after multiple runs without specifying the variability across runs or disclosing the total number of experiments conducted. This selective reporting skews the perceived reproducibility of results.
Reproducible AI examples
NeurIPS Reproducibility Program
The NeurIPS 2019 reproducibility program is a useful example of field-level infrastructure. It combined a reproducibility checklist, a code submission policy, and a community reproducibility challenge. After these efforts, code sharing at NeurIPS increased, and reproducibility became a more visible part of the review process.
ML Reproducibility Challenge
The ML Reproducibility Challenge gives researchers a structured way to test published claims. Participants select papers, rerun or reimplement experiments, and report whether the main findings hold. This helps the field learn from both successful reproductions and failures.4
Papers with Code
Papers with Code connects research papers with code, datasets, methods, and benchmark results. This makes it easier for researchers and practitioners to find implementation artifacts and compare methods.5
Batch-invariant LLM inference
Thinking Machines Lab’s work on batch-invariant inference shows how low-level serving details can affect reproducibility. In modern LLM serving, dynamic batching can change numerical execution. Because small numerical differences can affect token selection, the same prompt can produce different outputs. Batch-invariant kernels are one way to reduce this source of nondeterminism.6
Enterprise MLOps pipeline
A practical enterprise example is a model audit pipeline that uses DVC for dataset versioning, MLflow for experiment tracking, and a pinned Docker image to capture the environment. When a model decision is questioned, the team can recover the exact dataset, code version, model artifact, and evaluation report used at the time.
Add as preferred sourceThe role of AI researchers in addressing reproducibility
AI researchers develop new models, but they also shape the evidence base that other teams use. Their work is easier to verify when artifacts are complete, documented, and stable.
The research community has improved its reproducibility practices. NeurIPS introduced a reproducibility program in 2019 that included a code submission policy, a reproducibility checklist, and a community reproducibility challenge.7 Later analyses found a clear increase in code sharing at NeurIPS after these efforts.
To improve reproducibility further, AI researchers should:
- Share code, data, model weights, and evaluation scripts when possible.
- Archive code and artifacts with persistent identifiers.
- Report exact hyperparameters, data splits, prompts, seeds, and hardware.
- Report variance across multiple runs instead of the best run.
- Use documentation standards such as Model Cards and Dataset Datasheets.
- Follow structured checklists such as the Machine Learning Reproducibility Checklist and the NeurIPS Paper Checklist.
- Encourage independent reproduction and replication through venues such as the ML Reproducibility Challenge.
When data or code cannot be released, researchers should explain the constraint and provide a proxy dataset, a synthetic sample, an executable environment, or a detailed reproduction protocol.
How to improve reproducibility in AI?
The best way to achieve AI reproducibility in the enterprise is by leveraging MLOps best practices. MLOps involves streamlining the artificial intelligence and machine learning lifecycle with automation and a unified framework within an organization.
Useful tools and techniques include:
- Experiment tracking: Tools such as MLflow, Neptune, and Comet help record metrics, parameters, artifacts, and run history.
- Data versioning and lineage: Tools such as DVC, LakeFS, Pachyderm, and Delta Lake help track how datasets change.
- Model versioning: Model registries help store model versions, metadata, signatures, and deployment stages.
- Environment capture: Docker, conda, pip freeze, lock files, and Nix help preserve software dependencies.
- Pipeline orchestration: Reproducible workflows should define how data preparation, training, evaluation, and deployment run end-to-end.
- Logging and audit trails: Teams should log model inputs, outputs, prompts, model versions, and environment metadata for important decisions.
What does reliable AI mean & how does it relate to reproducible AI?
Reliable AI refers to systems that perform consistently and correctly under expected conditions. Reproducibility supports reliability, but it is not the same thing.
A reproducible system can be rerun and audited. A reliable system must also be accurate, robust, secure, fair, and safe for its intended use. Reproducibility helps teams test these qualities by making results traceable.
Reproducibility supports reliable AI in five ways:
- Consistency across runs: Teams can check whether a result is stable under the same setup.
- Debugging and auditing: Teams can trace which data, code, model, and environment produced an output.
- Robust testing: Teams can compare behavior across datasets, model versions, and deployment settings.
- Compliance: Teams can maintain documentation and records for internal audits and external regulations.
- Scientific integrity: Researchers can verify claims and build on them with less ambiguity.
Cite this research
Pick the format that matches where you're publishing. Pasting the link version into your CMS preserves the backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem},
title = {{Reproducible AI: Why it Matters & How to Improve it}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/reproducible-ai}},
note = {AIMultiple. Retrieved June 23, 2026}
}Reference Links
Cem's work has been cited by leading global publications including Business Insider, Forbes, Washington Post, global firms like Deloitte, HPE and NGOs like World Economic Forum and supranational organizations like European Commission. You can see more reputable companies and resources that referenced AIMultiple.
Throughout his career, Cem served as a tech consultant, tech buyer and tech entrepreneur. He advised enterprises on their technology decisions at McKinsey & Company and Altman Solon for more than a decade. He also published a McKinsey report on digitalization.
He led technology strategy and procurement of a telco while reporting to the CEO. He has also led commercial growth of deep tech company Hypatos that reached a 7 digit annual recurring revenue and a 9 digit valuation from 0 within 2 years. Cem's work in Hypatos was covered by leading technology publications like TechCrunch and Business Insider.
Cem regularly speaks at international technology conferences. He graduated from Bogazici University as a computer engineer and holds an MBA from Columbia Business School.
Comments 2
Share Your Thoughts
Your email address will not be published. All fields are required. Comments are left in their original language.
I have been working on this and have achieved it with on CPU. Repeatable determinism or reproducibility is a key stone of dependable systems and when applied in convolutional network can have higher accuracy. These are some of the academically peer-reviewed publications made in the IEEE. • [1] R. Rudd-Orthner and L. Mihaylova, “Non-Random weight initialisation in deep learning networks for repeatable determinism,” in Peer Reviewed Proc. of the 10th IEEE International Conference Dependable Systems Services and Technologies (DESSERT-19), Leeds, UK, 2019. o This conference paper proved that an alternative to the random initialisation was possible and provided an almost equal performance but with reproducibility. Presented at the UK Ukraine and Northen Island IEEE branches conference in Leeds. • [2] R. Rudd-Orthner and L. Milhaylova, “Repeatable determinism using non-random weight initialisations in smart city applications of deep learning,” Journal of Reliable Intelligent Environments in a Smart Cities special edition, vol. 6, no. 1, pp. 31-49, 2020. o This Journal paper enhanced the performance to an equivalent performance by using the limits from He and Xavier and made the previous reproducibility a more general case for general use, although it was limited to Dense layers. • [3] R. Rudd-Orthner and L. Milhaylova, “Non-random weight initialisation in deep convolutional networks applied to safety critical artificial intelligence,” in Peer Reviewed Proc. of the 13th International Conference on Developments in eSystems Engineering (DeSe), Liverpool, UK, 2020. o This conference paper proved an approach to Convolutional layers that as alternative to the random initialisation and provided a higher performance with reproducibility. Presented at the UK and UAE IEEE branches conference in Liverpool held virtually. • [4] R. Rudd-Orthner and L. Milhaylova, “Deep convnet: non-random weight initialization for repeatable determinism with FSGM,” Sensors, vol. 21, no. 14, p. 4772, 2021. o This Journal paper extended the work into colour images proofs and used the cyber FSGM attack as a method for measuring effect in transferred learning. • [5] R. Rudd-Orthner and L. Milhaylova, “Multi-type aircraft of remote sensing images: MTARSI2,” Zenodo, 30 June 2021. [Online]. Available: https://zenodo.org/record/5044950#.YcWalmDP2Ul. [Accessed 30 June 2021]. o This was the colour dataset used. • [6] R. Rudd-Orthner, “Artificial Intelligence Methods for Security and Cyber Security Systems,” University of Sheffield, Sheffield, UK, 2022. o This is the final full write up in the context and with other approaches.
I have been working on this and have achieved it with on CPU. Repeatable determinism or reproducibility is a key stone of dependable systems and when applied in convolutional network can have higher accuracy. These are some of the academically peer-reviewed publications made in the IEEE etc about Safety Critical AI. • [1] R. Rudd-Orthner and L. Mihaylova, “Non-Random weight initialisation in deep learning networks for repeatable determinism,” in Peer Reviewed Proc. of the 10th IEEE International Conference Dependable Systems Services and Technologies (DESSERT-19), Leeds, UK, 2019. o This conference paper proved that an alternative to the random initialisation was possible and provided an almost equal performance but with reproducibility. Presented at the UK Ukraine and Northen Island IEEE branches conference in Leeds. • [2] R. Rudd-Orthner and L. Milhaylova, “Repeatable determinism using non-random weight initialisations in smart city applications of deep learning,” Journal of Reliable Intelligent Environments in a Smart Cities special edition, vol. 6, no. 1, pp. 31-49, 2020. o This Journal paper enhanced the performance to an equivalent performance by using the limits from He and Xavier and made the previous reproducibility a more general case for general use, although it was limited to Dense layers. • [3] R. Rudd-Orthner and L. Milhaylova, “Non-random weight initialisation in deep convolutional networks applied to safety critical artificial intelligence,” in Peer Reviewed Proc. of the 13th International Conference on Developments in eSystems Engineering (DeSe), Liverpool, UK, 2020. o This conference paper proved an approach to Convolutional layers that as alternative to the random initialisation and provided a higher performance with reproducibility. Presented at the UK and UAE IEEE branches conference in Liverpool held virtually. • [4] R. Rudd-Orthner and L. Milhaylova, “Deep convnet: non-random weight initialization for repeatable determinism with FSGM,” Sensors, vol. 21, no. 14, p. 4772, 2021. o This Journal paper extended the work into colour images proofs and used the cyber FSGM attack as a method for measuring effect in transferred learning. • [5] R. Rudd-Orthner and L. Milhaylova, “Multi-type aircraft of remote sensing images: MTARSI2,” Zenodo, 30 June 2021. [Online]. Available: https://zenodo.org/record/5044950#.YcWalmDP2Ul. [Accessed 30 June 2021]. o This was the colour dataset used. • [6] R. Rudd-Orthner, “Artificial Intelligence Methods for Security and Cyber Security Systems,” University of Sheffield, Sheffield, UK, 2022. o This is the final full write up in the context and with other approaches.