datasetter458/bulk-chem-v1.0

Bulk Chem v1.0

A Data-Driven Router architecture for ADMET prediction.

What is this model

Bulk Chem is a multi-task regression and classification model covering many aspects of ADMET prediction in pharmacology, Absorption, Distribution, Metabolism, Excretion, and Toxicity. Each ADMET endpoint is a distinct predictive subject, and every endpoint in the table below is handled by its own dedicated block of the network rather than a single shared head.

The model consumes a molecule's SMILES string and returns a prediction (a probability for classification endpoints, or a continuous value for regression endpoints) for each supported endpoint.

This model is intended as a support utility for pre-lab molecular triage, not as a decision-making authority. Predictions should inform prioritization, not replace experimental validation.

What ADMET predictions can the model do?

ADMET is short for Absorption, Distribution, Metabolism, Excretion, and Toxicity, and every one of those categories contains several distinct prediction subjects. The model currently supports:

Element	Endpoints
Absorption	HIA, PAMPA, Lipophilicity, Solubility
Distribution	BBB, PPBR, BBBP
Metabolism	CYP2C9, CYP2D6, CYP3A4
Excretion	Clearance (hepatocyte), Clearance (microsome)
Toxicity	AMES, DILI, LD50

Note on Excretion: Excretion is very low on available data, it is widely recognized as the most neglected and data-poor "letter" in ADMET modeling. Predictions from this block should be treated with additional caution relative to the other endpoints.

Endpoint types

Endpoint	Task type
HIA, PAMPA, BBB, BBBP, CYP2C9, CYP2D6, CYP3A4, AMES, DILI	Binary classification
Lipophilicity, Solubility, PPBR, Clearance (hepatocyte), Clearance (microsome), LD50	Regression

How does a Data-Driven Router architecture work?

Data-Driven Router Architecture: an architecture composed of a Router/Dispatcher that sends data across multiple classes of smaller blocks. These blocks are not necessarily linked to one another, each independently performs a different task on different data. The blocks are not linked in terms of gradients either: backpropagation does not affect all of them the same way.

More precisely, this architecture is designed to solve three problems:

• Dataset size equilibration : A small block trained on a narrow dataset (e.g. ~1k samples) will not be corrupted by a much larger dataset (e.g. +10k samples) used elsewhere in the model. This is because the blocks are intentionally unrelated in their architectural composition and do not interact during backpropagation.
• Zero gradient interference : During training, the Negative Transfer Problem common to standard MLPs is solved with a Router/Dispatcher that determines exactly which block each sample is routed to.
• Data efficiency : Training on a given dataset (e.g. Solubility) today and fine-tuning on a new Solubility dataset tomorrow only touches the Solubility block. No other block in the model is affected.

The Negative Transfer Problem of MLPs: In a standard shared-trunk MLP, the gradients from block A's task corrupt the gradients relevant to block B's task, simply because the two are architecturally linked even though each is meant to solve a different problem. As a result, the shared weights either struggle to reconcile the conflicting objectives, or suffer from gradient non-equilibration and fail to reach meaningful results on one or both tasks.

Model weights and source code

• Weights: saved_weights/
• Source code / training notebook: dsp_ai.ipynb

Training procedure

This architecture was chosen specifically for its zero gradient interference property and the operational flexibility it provides:

• Checkpoints can be saved and loaded per-block.
• Any single block can be retrained from scratch, or fine-tuned, without touching the weights of any other block.
• Weights for most blocks in a head can be loaded as-is while a single target block is retrained or has its internal architecture changed, a surgical, block-level approach to iteration.

The router's targeting logic is exposed through two key functions:

• load_weights() : loads saved weights into their corresponding blocks.
• load_weights_with_extended_vocab() : splices saved weights into a block whose input vocabulary (character set) has since been expanded, without requiring retraining from scratch.

Input representation

Molecules are encoded as SMILES strings using character-level one-hot encoding over a union vocabulary built across all training datasets. Variable-length sequences are processed with a GRU and pooled via the final hidden state, then passed to a per-block MLP head.

Intended use and limitations

• Intended use: Rapid, low-cost pre-screening / triage of candidate molecules across multiple ADMET endpoints prior to lab work.
• Not intended for: Standalone clinical, regulatory, or final go/no-go decisions. Always validate flagged candidates experimentally.
• Known limitation: The Excretion endpoints (clearance_hepatocyte, clearance_microsome) are trained on comparatively little data industry-wide and should be interpreted with wider uncertainty margins than other endpoints.
• Performance varies by endpoint depending on the size and quality of the underlying dataset for that specific block, see per-endpoint metrics (confusion matrix / MSE / R² / MAE) for details where available.

How to test the model

A Gradio demo Space is available for interactive testing, paste or draw a molecule's SMILES string and get predictions across all supported ADMET endpoints, alongside a 2D rendering of the molecule.

Citation

@misc{bulkchem2026,
  title  = {Bulk Chem v1.0: A Data-Driven Router Architecture for ADMET Prediction},
  author = {[datasetter485]},
  year   = {2026},
  note   = {},
  url    = {https://huggingface.co/datasetter485/bulk-chem-v1}
}