From prototype to production: what I learned hardening Pharmagen

Fri, 10 Jul 2026 00:00:00 GMT

When I started Pharmagen I was a pharmacist learning to code models. v1 worked: a DeepFM + Transformer that learned to predict phenotypic drug response from genetic variants. But a prototype that runs on your machine and software others can trust are two different things. This post is about the road between them — including the uncomfortable part.

The metric I chose not to use

v1 produced high numbers. And precisely because they were high, they made me suspicious. Reviewing the pipeline with more judgment than I had when I designed it, I found assumptions in data preparation and splitting — in the allelic normalization and in how I separated training from test — that, in all likelihood, let information leak between sets. This is classic data leakage: the model looks brilliant because, unintentionally, it has already seen part of the answer.

I could have left the 86.89% on the portfolio and nobody would have blinked. I decided not to. A metric I can’t defend methodologically isn’t an achievement, it’s a liability. Publishing it as final would be not only incorrect but exactly the kind of practice I want to avoid in a clinical domain where an error translates into a decision about a patient.

What v1 did prove still stands: the gene–drug signal is learnable with this representation, and choices like using PubChem CID over ATC or the Genalle identifier work. That’s what I keep. The number, I don’t.

Why graphs (v2, scientific front)

v1 represented drugs and variants as tabular vectors. But a molecule is a graph (atoms, bonds), and genomic context has topology too. Forcing that structure into a table loses information.

v2 adopts a Two-Tower GATv2 architecture with PyTorch Geometric:

Drug tower: molecular graphs built with RDKit from canonical SMILES.
Genotype tower: positional variant graphs, validated against GRCh38.
Both towers are fused into multi-task heads.

Attention over graphs (GATv2) lets the model learn which parts of the molecule and the genomic context matter for each interaction, instead of me assuming it through manual feature engineering.

Why industry standards (v2, engineering front)

When I designed v1 I didn’t know what I didn’t know. No type validation, no tests, no inference service, no CI. It worked, but it was fragile: a change in one place broke another silently.

v2 brings in what the first version lacked:

Pydantic v2 typing every data boundary (Drug, Variant, Genotype, API requests…). If bad data enters, it fails loudly and early, not three layers down.
FastAPI as the inference service, with OpenAPI and health/readiness probes.
CI with ruff + pytest (~240 unit tests) on every push and PR.
uv for reproducible dependencies, with a lockfile as the source of truth.

None of this improves the model’s metric. What it improves is trust: that the project can be maintained, audited, and deployed, and that another person — or an examiner, or a supervisor — can read the code and believe in it.

Rebuilding the evaluation

The centerpiece of v2 is not the architecture, it’s the evaluation protocol. Leakage-free splits, an explicit baseline to compare against, and balanced metrics always reported alongside the methodology that produced them. When I have figures I can defend, they’ll be published here with that protocol next to them. Not before, and not without it.

What I take away

I’ve learned more fixing v1 than building it. Catching the evaluation problem myself, accepting that the pretty numbers didn’t hold, and rebuilding the project with rigor has been the most formative part of all of Pharmagen. If anything defines a good researcher or engineer, it isn’t never being wrong — it’s seeing the error, owning it, and correcting it with method. That’s where I am.

Comments, or want to follow the development? The code is on GitHub and you can reach me on LinkedIn.

Analysis of the DeepFM Architecture in Pharmacogenomics

Sun, 15 Mar 2026 00:00:00 GMT

Update — honesty note

This article documents v1 of Pharmagen. A later review found assumptions in data preparation and splitting that likely introduced information leakage and inflated the metrics shown below: I treat them as preliminary and optimistic, not a final result. v2 rebuilds the evaluation with leakage-free splits and metrics reported alongside their methodology. Full context in the post From prototype to production and on the project page.

Why DeepFM and not a classic tabular model

Pharmacogenomics poses a problem that is unusual in machine learning: the interactions between genetic variants and drugs are combinatorial and non-linear. A model like XGBoost captures first-order relationships well, but epistasis (the interaction between multiple genetic loci) requires explicitly modeling second-order and higher interactions.

The DeepFM architecture combines the best of two worlds:

Factorization Machines (FM): capture all second-order interactions between features efficiently, without manual feature engineering.
Deep Neural Network (DNN): learns higher-order patterns that FMs cannot reach.

Feature engineering: the decisions that matter

PubChem CID instead of ATC

ATC classification groups drugs by therapeutic use, not by molecular structure. Two drugs in the same ATC group can have completely different genomic-interaction profiles. Using PubChem CID, the model works with real chemical identities.

The synthetic “Genalle” variable

Fusing the rsID with HGVS notation into a single identifier (Genalle) normalizes the allelic representation and avoids ambiguities when the same variant has multiple nomenclatures.

Handling imbalance with Focal Loss

In pharmacogenomics, rare phenotypes (ultrarapid metabolizers, severe adverse reactions) are the most clinically critical yet least represented in the data. Adaptive Focal Loss penalizes errors on these minority classes more heavily, prioritizing patient safety over global accuracy.

Preliminary results (v1) (see the honesty note above)

These figures come from v1’s internal splits and are likely inflated by data leakage. I keep them for transparency and traceability, not as a validated result:

Task	Metric (preliminary)
Phenotypic Category	86.89% Precision
Dosage Adjustment	0.8328 Balanced Accuracy
Pharmacokinetics	0.8037 Balanced Accuracy
Effect Direction	66.07% Precision

The effect-direction task (increased/decreased) is the hardest because it depends on clinical contexts that are not always encoded in pure genomic data. It is an area where future GNNs could bring significant improvements.

Lessons learned

Feature engineering matters more than architecture. Moving from ATC to PubChem CID improved performance more than any hyperparameter tuning.
Class imbalance in clinical domains is not a technical problem, it is an ethical one. Optimizing for global accuracy can mask a model that fails systematically on the most dangerous cases.
Optuna + stratified cross-validation is the right combination for small datasets with many classes. 40 trials were enough to converge.
Evaluation matters as much as the model. A high metric is worthless if the protocol allows data leakage. Catching this myself and rebuilding the validation in v2 has been the most valuable lesson of the whole project: it is what separates an experiment from a reliable tool.