Fine-tuning EfficientNetB0 for 104 flower classes: validation vs held-out test scores, honestly

Parth Maniar — Thu, 08 Oct 2026 19:54:03 +0000

I built a GPU transfer-learning workflow for 104-class flower recognition and tried to report it honestly, including the gap between validation and held-out test scores.

Repo: https://github.com/officialpm/flower-classification

This is an evaluated model workflow, not a deployed flower-identification product.

The approach

Verify TFRecord feature names, counts and that all 104 classes appear in training and validation.
Load an ImageNet-pretrained EfficientNetB0 at 224 pixels with flip, rotation and zoom augmentation.
Train a frozen head for three epochs, then fine-tune at a lower learning rate for up to eight. BatchNorm layers stay frozen.
Keep the best validation-loss checkpoints and report macro-F1, accuracy and log loss for every candidate.
Match test IDs exactly to the sample order. Reject duplicates, missing IDs, nonfinite probabilities or labels outside 0-103.

The training set has 12,753 labeled images across 104 class IDs. All classes are present but counts are uneven, so I track macro-F1 rather than accuracy alone.

Results

Model	Validation macro-F1	Validation accuracy
Frozen head	0.800261	0.823276
Fine-tuned	0.855443	0.878502
Equal blend	0.855260	0.873653

The fine-tuned model scored 0.86708 macro-F1 on the held-out test set, scored independently of my training and validation. That is a different measurement from validation (0.855443), and I don't read the gap as a real improvement.

Limits

The validation split was reused for checkpointing and model selection.
Fine-tuned and blended results are nearly tied. I claim no meaningful margin between them.
I did not purge duplicate images or test on an independent unseen domain.
ImageNet pretraining may overlap with public flower imagery.
This dataset's test labels are easy to find online. I did not fetch or use them, but it means near-perfect scores on it say little. Treat any score here with suspicion, including mine.
The portable train.py passed syntax checks but was not retrained end to end. The measured run used TensorFlow 2.20 on two Tesla T4 GPUs.
No throughput, latency or accuracy on real user photos has been measured.

Code is Apache-2.0. No dataset, checkpoints or prediction files are published.

Promotion-aware retail demand forecasting: what worked and what I can't claim

Parth Maniar — Thu, 08 Oct 2026 19:53:33 +0000

I built a small, reproducible workflow for forecasting retail demand when promotions matter. It compares seasonal estimates against per-store, per-product-family promotion models, keeps zero-sales days, and validates every output against the expected IDs.

Repo: https://github.com/officialpm/retail-demand-forecasting

This is a research workflow, not a deployed inventory system. No service, dashboard or production integration is claimed.

The approach

Predict each store-family series on its own. Zero-sales days stay in.
Compare three seasonal baselines, a longer-window seasonal control, and two fixed promotion models (56-day and 112-day).
Fit weekday intercepts and log promotion counts to log sales, with fixed ridge penalties instead of a parameter search.
Evaluate five nonoverlapping 16-day horizons, using only earlier history for each one.
Join forecasts to the sample IDs one-to-one. Reject missing, duplicate, nonfinite or negative output.

Results

Measurement	Result
Held-out test RMSLE (lower is better)	0.40508
Previous held-out test result	0.41602
Five-window development RMSLE, 56-day promotion model	0.435361
Same-window seasonal control	0.460723
Windows won against the seasonal control	5 of 5

Daily sales summed across all stores and product families, zero-sales days included. The scale and variability change over time, so a single average is not a stable demand model. This plot is descriptive, not a causal promotion analysis.

Limits

The development windows were reused as the method evolved, so those numbers are selection-biased.
The held-out test score is one measurement on one test period. It says nothing about new stores, years or demand patterns.
Promotions are associated with sales here. The coefficient is not a causal estimate.
No holidays, oil prices, transactions or stockout labels are modeled.
The portable train.py is an adaptation of the measured implementation. I ran synthetic tests (output shape, and invariance to future target changes), not a full retrain.
Nothing about production latency or business impact has been measured.

The repo has the code, tests, a full explained notebook and a results ledger with provenance. Feedback on the validation setup is welcome.

Code is Apache-2.0. The dataset is not included and is not covered by that license.

DEV Community: Parth Maniar

Fine-tuning EfficientNetB0 for 104 flower classes: validation vs held-out test scores, honestly

The approach

Results

Limits

Promotion-aware retail demand forecasting: what worked and what I can't claim

The approach

Results

Limits