DEV Community: Omar Essam El Sherbiny

An image classifier you can trust 80% of the time: confidence gating and Grad-CAM

Omar Essam El Sherbiny — Fri, 30 Oct 2026 05:33:10 +0000

This was my final project for IBM's Deep Learning and Reinforcement Learning course. Fashion-MNIST is a familiar benchmark, so I framed it as a business task instead of a leaderboard entry: an online shop wants product photos tagged into ten categories automatically, and a person reviews whatever the model is unsure about.

That framing changes the question. "How accurate is the model?" becomes "what share of images can it tag on its own, and how accurate is it on those?"

Four architectures, one budget

All four models used the same split (54,000 train, 6,000 validation, 10,000 test), the same optimiser, early stopping on validation loss and a 40-epoch cap.

Model	Parameters	Test accuracy	Macro F1	Train time (CPU)
Dense network (MLP)	235k	89.3%	0.893	1 min
Small CNN	422k	91.6%	0.916	2 min
Deep CNN, BatchNorm + Dropout	289k	93.7%	0.937	24 min
Deep CNN + augmentation	289k	92.6%	0.926	33 min

The deep CNN is the best model with fewer parameters than the small CNN: three convolutional blocks with batch normalisation and dropout do more with less. The augmented version was still improving when the 40-epoch cap hit, so it is 1.1 points behind here and is the one I would continue with more training time.

The confidence gate

A 93.7% model is wrong on about one image in sixteen, which is too many for a shop to publish unchecked. But the model's own confidence is informative. If I accept only predictions whose top-class probability clears a threshold and send the rest to a reviewer:

Threshold	Tagged automatically	Accuracy on those	Sent to review
none	100%	93.7%	0%
0.90	84.5%	98.5%	15.5%
0.95	80.1%	99.1%	19.9%
0.99	70.6%	99.6%	29.4%

At 0.95, the model tags four images in five at 99.1% accuracy and a person handles the fifth. That table is the deliverable I would hand to the business: it turns a single accuracy number into a choice between workload and error rate.

Where it fails, and why

Shirts are the hard class, with 79% recall. The top confusions are shirt with T-shirt (78 and 75 of 1,000 in each direction) and shirt mistaken for coat (57). Trousers, bags and sandals are all above 98.5%.

The gate does not catch everything: a fifth of the mistakes are made at 0.95 confidence or more. Looking at those images, most are items a person would also hesitate over. That is useful to know before promising a client 99%.

What the network looks at

Grad-CAM highlights the parts of an image that drove a prediction. For the recommended model it lands on collars, sleeves and the overall silhouette rather than the background. Checking this is a quick guard against a model that is right for the wrong reasons.

Limits

The models were trained on a CPU, so the 40-epoch cap was a time budget rather than a choice. Fashion-MNIST images are small, centred and greyscale; real product photos are not, and the gate's numbers would have to be measured again on real data.

Code, notebook and the 10-page report: github.com/engomaressam/fashion-mnist-cnn-gradcam
Kaggle notebook (GPU): Fashion-MNIST CNNs, confidence gating and Grad-CAM
Model: omaressamrme/fashion-mnist-deep-cnn

Omar Essam El Sherbiny. Head of Data at WalaPlus. Data platforms on Google Cloud, data governance, applied ML. More at omaressam.web.app.

Five customer segments, and the one that holds 65% of the lost revenue

Omar Essam El Sherbiny — Fri, 30 Oct 2026 05:32:34 +0000

This was my final project for IBM's Unsupervised Machine Learning course, on the same Telco Customer Churn dataset I used for a churn classifier. The question was different: without using the churn label at all, can we split 7,043 customers into groups that a marketing team would recognise, and does that split say anything about risk?

It does. One segment, which I call the fibre newcomers, is 27% of customers and 65% of the revenue lost to churn.

Feature engineering mattered more than the algorithm

The obvious input is the 18 raw service flags (phone, internet type, each add-on). Run through PCA, they need 10 components to explain 80% of the variance, and K-means on them reaches a silhouette of 0.18 at k = 5: weak, overlapping clusters.

I replaced them with six engineered behavioural features: tenure, contract length in months, monthly charges, the number of protection services, the number of streaming services, and a fibre flag. Three principal components now explain 87% of the variance, and they read naturally as spend and service depth, commitment and fibre versus protection. The silhouette doubles:

Feature set	Components for 80%+ variance	Silhouette at k = 5
18 raw service flags	10	0.18
6 engineered features	3	0.37

Five algorithms, same k

Model	Silhouette	Davies–Bouldin	Bootstrap stability (ARI)
K-means, engineered features	0.37	1.06	0.99
Hierarchical (Ward)	0.34	1.11	0.79
Gaussian mixture	0.28	1.25	0.95
DBSCAN (19 clusters)	0.30	1.42	n/a

K-means wins on every internal metric and is the most stable: refitting with different random seeds reproduces the same segments (adjusted Rand index 0.99). Stability is the metric I would not skip; a segmentation that changes every time you refit cannot be used to run campaigns.

The five segments

Segment	Share	Profile	Churn	Share of churned revenue
Fibre newcomers	27%	17 months' tenure, month-to-month, all on fibre, $85/month	56%	65%
Budget newcomers	27%	12 months, $39/month, a third without internet	26%	14%
Premium fibre loyalists	17%	58 months, annual contracts, $103/month, most add-ons	19%	17%
Loyal DSL bundlers	16%	52 months, the longest contracts, protection bundles	6%	3%
Phone-only veterans	14%	46 months, no internet, $23/month	1.4%	0.2%

Churn ranges from 1.4% to 56% across segments, even though the clustering never saw the churn column. The fibre newcomers are 27% of customers and 35% of revenue, but 65% of the revenue lost to churn. That is where a retention budget goes first, and the profile tells you what to offer: they are on month-to-month contracts, so the obvious lever is a contract incentive.

A negative result worth keeping

I also tried training one churn classifier per segment instead of a single global model. On the same test customers: global model AUC 0.843, one model per segment 0.843, global model plus a segment feature 0.844. Splitting the data five ways costs more in sample size than it gains in specificity. Segments are a communication and targeting tool here, not a modelling shortcut, and it is useful to know that before building five pipelines.

Limits

The data is a point-in-time extract with no customer history. The engineered features embed judgement calls, such as which services count as "protection". DBSCAN's small clusters are real sub-groups but too small to act on.

Code, notebook and the 10-page report: github.com/engomaressam/customer-segmentation-kmeans
Kaggle notebook: Telco customer segmentation: K-means vs 4 methods

Omar Essam El Sherbiny. Head of Data at WalaPlus. Data platforms on Google Cloud, data governance, applied ML. More at omaressam.web.app.

Churn prediction where the simple model wins: logistic regression against five rivals

Omar Essam El Sherbiny — Fri, 30 Oct 2026 05:31:58 +0000

This was my final project for IBM's Supervised Machine Learning: Classification course: predict which telecom customers will leave, using the IBM Telco Customer Churn dataset (7,043 customers, 26.5% of whom churned). The modelling was the easy part. The interesting decision came at the end, when the best three models turned out to be indistinguishable.

A fair comparison first

Every model family was grid-searched on the same five stratified folds of the same 80/20 split, scored by ROC AUC, and then evaluated once on the held-out test set with a 95% confidence interval.

Model	CV AUC	Test AUC	95% CI
Gradient boosting	0.849	0.846	0.825–0.868
Random forest	0.849	0.843	0.821–0.865
Logistic regression (L2, C = 0.1)	0.844	0.843	0.821–0.865
SVM, RBF kernel	0.844	0.843	0.819–0.865
k-nearest neighbours	0.838	0.832	0.808–0.854
Decision tree (pruned)	0.839	0.831	0.807–0.854

Gradient boosting has the highest number, but its lead over logistic regression is 0.003 AUC, well inside overlapping confidence intervals. When the accuracy is a tie, I pick on the things that matter after deployment: can the business read the model, and is its ranking stable?

Why logistic regression got the job

Logistic regression gives odds ratios that a retention team can act on directly:

Feature	Odds ratio	What it means
Two-year contract	0.33	a third of the churn odds of month-to-month
Fibre-optic internet	2.43	2.4 times the odds of DSL
Tenure (per ~24 months)	0.45	churn risk halves with every two years
Tech support add-on	0.68	support customers stay more often

I checked whether the simple model was leaving signal on the table: permutation importance on the gradient-boosting model ranks the same drivers (tenure, contract, fibre) at the top. The model is also stable: eight variations (L1 or L2, C from 0.1 to 10, with and without class weights) all land within 0.001 AUC of each other.

Two details that are easy to miss

Collinearity. MonthlyCharges is almost entirely determined by the service flags (R² = 0.999), and TotalCharges is essentially tenure times monthly charges (r = 0.9996). Keeping them makes coefficients unreadable without adding information, so both were dropped, leaving 22 model features.

The threshold. The default 0.5 threshold is rarely the right one for an imbalanced problem. I set it at the point on the precision–recall curve that maximises F1 (0.35 for logistic regression), which gives precision 0.58 and recall 0.70. Class weighting does something similar: class_weight="balanced" lifts recall from 0.52 to 0.79 at the default threshold, at a cost in precision.

What it means for a retention campaign

A churn model is only useful if it changes who gets a call. Ranking customers by predicted probability:

contacting the top 20% reaches 50% of the churners and 56% of the revenue at risk;
the top 30% reaches 66% of the churners and 71% of that revenue.

Limits

The dataset is a single snapshot with no time dimension, so the model predicts who has churned rather than who will churn next quarter. The threshold ignores the cost of contacting a customer, which a real campaign would put in.

Code, notebook and the 10-page report: github.com/engomaressam/telco-churn-classification
Kaggle notebook: Telco churn: 6 models compared
Model: omaressamrme/telco-churn-logistic-regression

Omar Essam El Sherbiny. Head of Data at WalaPlus. Data platforms on Google Cloud, data governance, applied ML. More at omaressam.web.app.

The year the Nile changed: change-point detection on 100 years of river flow

Omar Essam El Sherbiny — Fri, 30 Oct 2026 05:31:22 +0000

The annual flow of the Nile at Aswan from 1871 to 1970 is one of the classic series in statistics: a hundred numbers that every time-series textbook seems to use. It is famous for one feature, a drop in the level around the turn of the century. I wanted to find that break properly, put an uncertainty on it, and then ask a practical question: how much does a forecaster actually gain from knowing about it?

Three methods, one answer

The data is the series published by Durbin and Koopman (2001), available as datasets::Nile in R: 100 annual values in units of 10⁸ m³.

Method	Break after	Mean before → after
Binary segmentation, one break (`ruptures`)	1900	1,078 → 851
PELT, penalty picks the number of breaks (it found one)	1900	1,078 → 851
Two-mean scan with a 2,000-draw bootstrap	1898 (95% CI 1896–1902)	1,098 → 850

Three methods built on different ideas land within two years of each other, and the bootstrap interval covers all of them. The mean flow falls by a little over a fifth and never recovers within the record.

I like running more than one detector on the same data. Agreement between methods with different assumptions is much stronger evidence than a single method's p-value, and when they disagree, the disagreement tells you something about the data.

Is anything left after the step?

Once the step is removed, the residuals pass a Ljung–Box test (p = 0.23). There is no year-to-year memory left: a good year does not predict another good year. So a forecast for this river is a level plus noise, and the only decision that really matters is which level.

What does knowing the break buy you?

I held out the last 20 years (1951–1970) and compared three forecasts:

Forecast of 1951–1970	RMSE	Mean forecast	Actual mean
AR(1) on the whole history (ignores the break)	131	928	877
AR(1) on the post-break years only	128	840	877
The post-break mean	128	840	877

The model that ignores the break aims too high, the post-break models aim a little low, and the improvement is three RMSE points against a year-to-year standard deviation of about 120. Knowing about the break removes a bias. It cannot remove the noise, and it would be easy to dress up this result as a bigger win than it is.

That is the part I find most useful outside hydrology. Structural breaks show up in every business series: a pricing change, a new data source, a migration. Detecting them is worth doing, but the honest question is always how much the forecast improves, measured on data the model has not seen.

Why around 1898?

The data cannot say. Two explanations are usually given: the first Aswan dam, built in the same years and opened in 1902, and a drier period over the Ethiopian highlands, where most of the flood water comes from. A statistical change point needs a cause from outside the data before it becomes a story, and with a single gauge the two cannot be separated.

Reproduce

The notebook is generated from source and runs top to bottom:

pip install -r requirements.txt
python make_notebook.py
jupyter nbconvert --to notebook --execute --inplace nile_river_flow.ipynb

Code and notebook: github.com/engomaressam/nile-river-flow
Kaggle notebook: Nile at Aswan: finding the year the river changed

Omar Essam El Sherbiny. Head of Data at WalaPlus. Data platforms on Google Cloud, data governance, applied ML. More at omaressam.web.app.

Pharaohs of Egypt: a validated dataset from Wikidata, built like a data pipeline

Omar Essam El Sherbiny — Fri, 30 Oct 2026 05:30:47 +0000

I wanted a clean table of Egypt's pharaohs: who ruled, in which dynasty, for how long, and which pyramid belongs to whom. Wikidata has most of it, but "most of it, as linked data" is a long way from a table you can trust. So I built it the way I would build any production dataset: extract, clean, validate, and keep a record of every value the pipeline refused.

The result is three tables (513 pharaohs, 38 dynasties, 84 pyramids), published on Kaggle and Hugging Face, with the code on GitHub.

The pipeline

extract.py   three SPARQL queries against query.wikidata.org, one a minute
             -> raw JSON + a manifest with the query text and the retrieval time
build.py     raw rows -> tables (dates, precision flags, one row per entity, chronology join),
             out-of-range dates nulled and logged
validate.py  pandera schemas for every table; the build fails if a check fails

Two habits from production work made the biggest difference.

Keep the raw pull and its provenance. Every run saves the raw query results next to a manifest with the exact SPARQL text and the time it ran. When a number looks odd, I can trace it back to the query that produced it, and when Wikidata improves, I re-run the extract and diff.

Validate as part of the build, not afterwards. The pandera schemas check that ids are unique, years fall between 3300 BC and AD 400, reigns end after they start, pyramid coordinates fall inside Egypt, heights are positive and URLs look like URLs. A failed check stops the build.

Dates are the hard part

Wikidata stores years in astronomical numbering, where year 0 exists. Its -1549 is 1550 BC, not 1549 BC. The tables keep both: a signed astronomical year that sorts and subtracts correctly, and a label that reads "1550 BC".

Precision matters just as much. Wikidata records whether a date is known to the year, the decade or the century, and a reign known to the century is not a reign known to the year. Every date column carries its precision, so nobody computes a reign length from two century-level guesses without noticing.

Some values had to go. The validation caught legendary reigns dated to "4001 BC" and similar impossible dates. Rather than silently dropping them, the build nulls the value and writes a row to quality_notes.csv saying what was removed and why. There are 15 such notes. A quality log like this is cheap to keep and it is the first thing I would want as a user of someone else's dataset.

Filling the gap Wikidata leaves

Wikidata is thin on dynasty dates, so I added a hand-curated chronology: the conventional dates from Shaw's Oxford History of Ancient Egypt (2000), joined to Wikidata's own records. It is one scheme among several, and dates before the New Kingdom carry decades of uncertainty; the file says so in a note column rather than pretending otherwise.

What the data can and cannot tell you

Wikidata assigns a dynasty to 384 of the 513 pharaohs and has reign dates for only 76.
The Second Intermediate Period alone contributes about 150 names, mostly kings known from a single scarab or one entry in a king list.
302 pharaohs have an image on Wikimedia Commons, which makes the table usable for a gallery or a quiz.
Pyramid heights are sparse (17 of 84). The literature has them; Wikidata does not yet.

Reuse it

The extract takes about three minutes because of the polite one-query-a-minute rate limit; the build and validation take seconds:

pip install -r requirements.txt
python pipeline/extract.py
python pipeline/build.py

The code is MIT-licensed. Data from Wikidata is CC0, and the curated chronology and derived tables are CC BY 4.0. Images are linked, not copied; each keeps its own licence on Wikimedia Commons.

Code: github.com/engomaressam/pharaohs-of-egypt
Kaggle dataset: engomaressam/pharaohs-of-egypt
Hugging Face dataset: omaressamrme/pharaohs-of-egypt

Omar Essam El Sherbiny. Head of Data at WalaPlus. Data platforms on Google Cloud, data governance, applied ML. More at omaressam.web.app.

Teaching a CNN to read hieroglyphs: 96.9% on 59 signs, and why my first model failed

Omar Essam El Sherbiny — Fri, 30 Oct 2026 05:30:16 +0000

Every Egyptian hieroglyph has a catalogue number. Egyptologists use Alan Gardiner's sign list, so the owl is G17, the reed leaf is M17, the water ripple is N35. I wanted to see how far a small convolutional network could get at the first step of reading a wall: look at one carved sign and say which one it is.

The answer, on held-out glyphs: 96.9% right at the first guess and 99.7% within five guesses, across 59 signs. The more useful part of the story is the first model, which failed, and what fixed it.

The data

The GlyphDataset (Franken and van Gemert, ACM Multimedia 2013, MIT licence) has 4,210 manually labelled glyphs cut from ten photographs of the Pyramid Texts in the pyramid of Unas at Saqqara, each a 50×75 px greyscale crop. It covers 172 signs, but most of them appear only a handful of times, so I kept the 59 signs with at least ten examples: 3,674 glyphs, split 70/10/20 with stratification (2,571 train, 368 validation, 735 test).

The imbalance is the defining feature of this dataset. The most common sign has about 290 examples; the rarest kept signs have 10.

Run 1: a textbook setup that overfitted

My first model was the setup you see in most tutorials: three convolutional blocks, global average pooling, a dense head, heavy augmentation, and full inverse-frequency class weights to handle the imbalance.

It overfitted badly. Training accuracy reached 71% while validation accuracy stayed under 50% and fell as training went on. Three choices were working against each other:

Full inverse-frequency weights made a 10-glyph sign count 29 times as much as a 290-glyph one. The network chased the rare signs and the loss became noisy.
Global average pooling throws away where a feature sits in the crop. For hieroglyphs that is part of the identity: a stroke at the top of the frame and the same stroke at the bottom can belong to different signs.
Heavy augmentation (big rotations and shifts, black fill) produced images that do not look like carved signs on light stone.

Run 2: the published model

Same data, same split, same seed, so the comparison is fair. I changed four things:

A Flatten head instead of global pooling, so position inside the crop survives.
Square-root-damped class weights: rare signs still count for more, but by a factor of about 5 rather than 29.
Lighter augmentation with white fill, which matches the light stone behind the glyphs.
BatchNorm after the dense layer, and early stopping on validation accuracy with a long patience.

It trained for 54 epochs (best at epoch 34) in 14 minutes on a laptop CPU. The model has 2.1 million parameters and is 25 MB.

Metric (735 held-out glyphs)	Value
Top-1 accuracy	96.9%
Top-5 accuracy	99.7%
Macro F1	0.939

I reran the same script on a Kaggle GPU as a check: 96.7% top-1, 99.5% top-5, macro F1 0.951, in two minutes. Differences of that size are normal between runs on different hardware; the result holds.

Where it is weak

Every sign with an F1 below 0.8 has fewer than 20 training glyphs. The errors are a data problem rather than a capacity problem: more photographs would move the number, a bigger network would not.

Using it the way it would really be used

A model that is right 96.9% of the time is still wrong on one glyph in thirty. On a real wall I would not let it answer alone, so I added a confidence gate: accept the prediction only when the top probability is at least 0.95, and hand the rest to a person. At that threshold the model answers 90% of glyphs on its own at 99.5% accuracy and leaves 10% for review. That trade is easy to tune, and it is the number I would give anyone deciding whether to use it.

What it does not do

The training photographs come from one monument, carved in one style and lit one way. A glyph from a painted tomb or a papyrus will look different.
It names single signs that have already been cropped. Finding the signs in a wall photograph is a detection problem, and translating them is another project entirely.
Signs with fewer than ten examples in the dataset are not covered at all.

Try it

Live demo: Hugging Face Space (Hieroglyphs tab): drop in a glyph crop and get the top five Gardiner codes.
Model: omaressamrme/hieroglyph-classifier
Code, both training runs and the figures: github.com/engomaressam/hieroglyph-classifier
GPU notebook: Kaggle

Dataset: M. Franken and J. C. van Gemert, "Automatic Egyptian Hieroglyph Recognition by Retrieving Images as Texts", ACM Multimedia, 2013.

Omar Essam El Sherbiny. Head of Data at WalaPlus. Data platforms on Google Cloud, data governance, applied ML. More at omaressam.web.app.