AI modeling of chemical reactions: where prediction breaks down
A model trained on "reactants → product" pairs behaves confidently on single-step transformations: substitution, reduction, and standard acylation are reproduced almost without errors.
Prediction accuracy on such reactions remains high, creating the impression of a ready tool that can be trusted with synthesis planning.
Everything breaks down where the scheme stops being linear.
On multi-step routes, the error of the first step accumulates along the entire chain: the intermediate is identified incorrectly — and the prediction of reaction products diverges from reality already at the third or fourth step.
More dangerous than an explicit failure is when the model outputs an incorrect structure with high confidence.
The second bottleneck is rare compound classes. If a class is represented by isolated examples in the training set, the model extrapolates from the nearest analogs, loses functional groups, and fills in a familiar skeleton.
When transferred to different feedstock — different purity, different catalyst, solvent, temperature regime — the data distribution itself shifts, and metrics taken on the original sample cease to mean anything.
A separate topic is labeling of experimental data. Summaries from different laboratories carry different notation, conditions, and interpretation of yield; mostly successful experiments are published, so the model learns from a biased picture.
Without normalization of structures, conditions, and negative results, any subsequent correction runs into the quality of labeling, not the volume of computation.
That is why AI modeling of chemical reactions begins not with model selection, but with a map of its applicability boundaries: where prediction is confirmed, where it requires lab validation, and where we are obliged to honestly return "I don't know."
Speed of hypothesis enumeration and coverage of chemical space
Enumeration of hypotheses before the first synthesis happens not in flasks but in a tree of retrosynthetic steps: the model unfolds the target molecule backward, reaches commercially available precursors, and assembles routes.
Previously a chemist could work through only a few schemes per week — now tree traversal yields thousands of branches in a matter of hours, and only the top ones go to the lab.
The tree is built on transformation rules and neural network scores trained on reaction datasets from Reaxys and patent dumps. Each node receives a set of numbers: step probability, number of stages, reagent availability, yield prediction.
Search turns from intuition into ranking — and you immediately see where a route converges and where it falls apart into unlikely links.
Route filtering happens before the first reagent is ordered.
Schemes via hard-to-obtain precursors, protecting group conflicts, incompatible functional groups on one step, dangerous and thermodynamically unfavorable transformations, as well as long detours where a short path exists, are removed from the queue. Branches relying on single publications without confirmed reproducibility are filtered separately.
The practical effect is fewer lab runs: five–ten best candidates are synthesized instead of fifty, and dead-end scheme classes never reach the fume hood.
At the same time, chemical space coverage grows due to areas where a chemist does not habitually look: nonstandard step order, a less obvious precursor, a change in the point of group introduction. Some such routes turn out to be workable and save an entire iteration.
Operating modes: precise retrosynthesis vs fast prediction
The two calculation modes differ in problem formulation. Forward prediction answers the question "what will result from this mixture": the input is reagents, catalyst, and conditions; the output is a set of products with probability estimates.
Retrosynthesis runs in reverse — from the target molecule to precursors, with a route tree and ranking by feedstock availability.
Their limitations differ, and confusing them is costly. Product prediction does not know whether reagents are in stock, and retrosynthesis does not check whether each step proceeds with acceptable yield. Therefore the mode is chosen by the problem formulation, not by the "power" of the model.
| Calculation mode | When it fits | Limitations |
|---|---|---|
| Forward product prediction | Reagents and conditions are known; yield and by-products need to be estimated | Does not suggest whether feedstock is available or how to obtain the reagents themselves |
| Single-step retrosynthesis | Target molecule is close to commercial precursors; a quick answer is needed | Ignores step order and impurity accumulation |
| Multi-step retrosynthesis | A complete route from available feedstock under specified constraints is needed | Each step requires validation; quality depends on reference data |
In practice the modes are combined: retrosynthesis builds a route, and forward prediction runs each step and cuts paths with low yield or undesirable by-products. Such a run noticeably reduces the share of nonworking routes even before the lab.
Implementation stages: from problem formulation to model validation
The analysis begins not with the model but with an inventory of accumulated data: which reactions are documented, how conditions are stored, how fully catalysts and solvents are described.
In parallel, we fix acceptance criteria — the share of correctly predicted products and the completeness of reconstructed retrosynthesis routes.
- Problem formulation. We clarify the reaction class, allowable input data, and how the result is used: a hint to the chemist or automatic candidate selection.
- Data schema. We bring records to a unified form: canonicalize structures, separate reagents and conditions, mark gaps. Here we also determine what will not enter training — otherwise the model will see the answers in advance.
- Assembly and training. We choose the molecular representation and architecture for the task type, and separately configure handling of rare reaction classes.
- Model validation on a held-out sample. We test on reactions the model has not seen: splitting by time and by unfamiliar structural scaffolds. We look not only at the average metric but also at the spread across subclasses.
- Error analysis and applicability boundaries. We determine where the model errs predictably and where it must be required to abstain instead of giving a plausible guess.
- Handover to operation. We set up the service, model versioning, input data control, retraining procedure, and rollback to the previous version.
The output is a working environment with clear applicability boundaries, not a report with metrics.
What remains with the customer: models, data, procedures
The work ends not with a presentation but with handover of the setup: the trained model, the data it was built on, processing configurations, and documents by which your team itself launches predictions and updates the model remain in your environment. Below is exactly what is transferred and how to use it without us.
- Model weights and launch code — the model in a portable format and a calculation wrapper: product predictions and retrosynthesis routes are computed on your equipment, without contacting our servers.
- Training and validation sample — reactions with conditions and products, source references, and a description of filters: which compound classes are excluded and why.
- Model card — purpose, applicability domain, metrics on the held-out sample, and a list of situations where accuracy drops: rare functional groups, nonstandard catalysts.
- Preprocessing configurations — structure normalization, token vocabulary, feature order: without them, the same input turns into a different vector, and the prediction diverges from the reference.
- Retraining procedure — sample update steps, a set of metrics for comparing versions, and the threshold at which a new model is rejected in favor of the previous one.
- Data access rights — role matrix: who sees the sample, who initiates training, who exports results, plus an operation log by model versions.
- Documentation package — environment diagram, deployment and recovery instructions, dependency list indicating the current branch.
Case study: shortening the reaction condition screening cycle
The task came from fine organic synthesis: at one stage, yield was not reproducible from batch to batch, and the target value was not achieved.
Before implementation, condition screening took 40-60 lab runs, a hypothesis was confirmed on the first attempt in about one case out of five, and the entire cycle stretched over 6-8 weeks.
We assembled a training sample from published reactions (Reaxys) and the customer's internal lab notebooks, brought the conditions to a unified description — reagents, catalyst, solvent, temperature, time, atmosphere — and trained the model to predict yield.
The retrosynthesis module decomposes the target molecule into available precursors, after which conditions are ranked by probability of success.
The model is retrained on each new series of experiments: results return to the sample, ranking is recalculated, so accuracy grows over the course of the project rather than being fixed at the start.
After implementation, the number of runs per stage decreased to 12-15, the share of hypotheses confirmed on the first attempt reached 60-70%, and the condition screening cycle — to 12-14 days.
Where data are scarce, the model flags the prediction with low confidence, and the chemist immediately sees which candidates to test first and which to consider risky.
Metrics were calculated from lab results, not from the model's self-report: in parallel, a control series ran according to the previous protocol. Besides speed, this gave even consumption of expensive reagents and predictable lab workload.
How does product prediction differ from retrosynthesis?
The forward task answers the question "what will happen if you mix this and heat it." As input, the model receives reagents, conditions (solvent, temperature, catalyst), and structures in machine-readable form — parsed by RDKit.
The output is a ranked list of products with probability estimates: you see not a single option but a distribution, including real side pathways.
Retrosynthesis is the inverse task: given a target molecule, you need to find what to assemble it from. The input is the product structure; the output is a tree of routes made of reactions and intermediates leading to available feedstock.
The difference is in the type of answer: the forward task predicts, the inverse task plans, and therefore returns several paths of different length and number of steps.
In practice, the inverse task almost always relies on the forward one: each proposed step is checked by forward prediction; otherwise the route remains a hypothesis.
Therefore the choice of calculation mode is dictated by the customer's question — are we optimizing the yield of a known reaction or looking for a path to a new molecule.
| Mode | What is on input | What is on output | When to choose |
|---|---|---|---|
| Forward task | reagents and conditions | products with probabilities | increase yield, analyze side pathways |
| Retrosynthesis | target structure | tree of synthesis routes | a path to the compound is needed |
| Retrosynthesis with validation | structure and feedstock constraints | routes confirmed by forward prediction | reproducibility in lab is important |
Technical concerns: data, accuracy, integration
Concerns at the evaluation stage are usually the same: there is little experimental data, the model simply has not seen rare reaction classes, lab systems speak their own language, and it is unclear how in daily work to understand that a prediction can be trusted. Below is a substantive discussion of each point.
Some of these questions are closed at the design stage, not after delivery: from choosing a dataset for model transfer to the exchange format with the lab. We provide the answers as we discuss them with chemists and process engineers.
We have several hundred experiments — will that be enough for the model?
Few start from scratch: we take open reaction datasets of the required type, train the model on them, then retrain on your data. Each of your experiments enters the sample and improves accuracy, so we then work in cycles — prediction, lab validation, refinement.
For one transformation class, several hundred records are usually enough; we confirm quality on a held-out sample, not on data the model has seen.
How to handle rare reaction classes and nonstandard conditions?
Average accuracy over the entire set proves nothing here, so we calculate metrics separately for each class.
Where data are insufficient, we change the mode: the model does not output a single product but ranks options and flags low-confidence predictions — the chemist sees the list and makes the decision independently. This removes the class of errors where the model confidently names an incorrect compound.
How will prediction integrate into our lab system?
We transfer structures and results in standard formats — molecular structures, compound registry, sample identifiers — so data are not entered manually.
We arrange calculation as a separate service: the job goes into queues, the result returns to the experiment protocol, and access is role-separated. We keep a history of predictions and decisions on them — later it shows where the model was wrong.
Who and how controls prediction quality after launch?
Held-out sample and chronological control: we test the model on reactions set after its training and monitor divergence between prediction and result.
Shares of confirmed predictions and types of discrepancies are output to a report; when data shift, we launch retraining according to the procedure. If accuracy for a class falls below the agreed threshold, the model stops giving recommendations for it.
Let's discuss the task: what to send for preliminary assessment
The scope estimate relies on facts, not assumptions, so we start with initial information about the task. Below is what to send: each item shows how much data preparation, modeling, and validation will be required, after which we return with a work plan and estimate.
- Problem formulation: what exactly we predict — reaction products, yield, selectivity, or retrosynthesis route, and at what level of detail: transformation class or specific process conditions.
- Source data: exports from electronic lab notebooks, literature datasets, internal reaction archives — in machine-readable form, with structures (SMILES or InChI), conditions (solvent, catalyst, temperature), and target values.
- Data volume and quality: how many records, share of failed and negative examples, whether there are gaps in conditions, duplicates, and discrepancies in compound nomenclature.
- Chemical space: compound and reaction classes that must fall within the model applicability domain, and how you determine going beyond its boundaries.
- Acceptance criteria: how we check quality — held-out sample, retrospective validation on known reactions, share of hits of the correct route in the first several retrosynthesis options.
- Implementation constraints: where the solution will run — in a closed environment or on external compute, how it integrates into the current process, what requirements there are for response time and explainability of the prediction.
- Expertise on your side: which chemists confirm the correctness of data and results and how much time they are ready to allocate to validation.
If some information is missing, this does not block the analysis: we will outline how to collect or replace it and include this stage in the plan.
